[Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Jonas Wielicki jonas at wielicki.name
Wed May 10 17:41:50 UTC 2017


On Dienstag, 9. Mai 2017 15:46:50 CEST Sam Whited wrote:
> The flow I envision (which may be similar to what was
> in PARS originally?) is as follows:
> 
> 1. Client 1 asks its server for a PARS token
> 2. The server returns an opaque token to Client 1
> 3. Client 1 shares the token with Client 2 out of band (QR code, NFC,
> email, website, etc.)
> 4. Client 2 sends the token to their server
> 5. Their server decodes the token and extracts the address of client
> 1's server (at least part of the token must be in a standard format
> and carry this information)
> 6. Client 2's server sends a presence subscription request to Client
> 1's server which authorizes or denies the request based on the
> validity of the token

The basic idea sounds sensible. Two things:


First of all, this makes it impossible for clients to perform PARS without 
server support, i.e. it depends on operators upgrading/extending servers to 
work.


Secondly, since Client 2 needs to know of the protocol in any case, can we 
maybe elide the server of Client 2 from the equation? Then the usability of 
tokens doesn’t depend on the server of Client 2 but only on the client.

That would work by simply embedding something into the <presence 
type="subscribe"/> or combining a <presence type="subscribed"/> (intentional 
'd') with an <iq/> with the token to the server of the Client 1.


kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170510/5fd8c620/attachment.sig>


More information about the Standards mailing list