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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
