[Standards] Proto-XEP: Pre-Authenticated Roster Subscription
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards