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

Sam Whited sam at samwhited.com
Tue May 9 20:46:50 UTC 2017

Fair warning, I'm not fully up to date on this discussion, but I was
asked to drop some notes from the room earlier into the thread so here
I am, this message from Daniel appears to be a good place to start.

On Thu, Apr 27, 2017 at 10:56 AM, Daniel Gultsch <daniel at gultsch.de> wrote:
> as mentioned several times in various MUCs I don't think a client side
> solution is actually going to improve the situation PARS attempts to solve.

I agree.

> So here is the outline of a proposal for a server side verification/pre
> authentication.
> * Clients subscribe to private PEP node. (See XEP-0223 on how to make a pep
> node private)
> * One client (the first client that ever wants to create a token) generates
> a 32 byte secret key and uploads that key into the node (base64)

This all still requires a lot of business logic on the client, and
means that the client must understand the token format which restricts
us to a single type of token. I think this could maybe be further
simplified by moving almost all the business logic to the server and
letting the clients effectively act as a dumb layer into data managed
by the server. 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

This flow allows the token format to be opaque to both clients, and
partially opaque to the server (they do need to be able to find the
other server, but after that the token can contain any other
information, eg. an hmac which the server can verify it signed, or a
nonce which the server looks up in the database).

This is vaguely similar to one of the OAuth2 flow or to JWT where you
can have a number of arbitrary claims (but only one or two of them are
known in advance and required and tokens may be signed or looked up in
a database depending on the policy of the service issuing the tokens).


More information about the Standards mailing list