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

Daniel Gultsch daniel at gultsch.de
Wed May 10 18:41:03 UTC 2017

Hi Sam,

thank you for you feedback.

2017-05-09 22:46 GMT+02:00 Sam Whited <sam at samwhited.com>:

> > * 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.

The business logic consists of a definition on how to convert a timestamp
into a sequence of bytes and hmacing that with a secret key from a PEP
node. That's it. (And converting that to base64.) Different people might
have different definitions on 'a lot' but too me that's not a lot.

> 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

What you are describing is what I would call the logic re-imagination or
the logic transformation of current PARS into a server side PARS. I was
carrying around similar ideas for a while. What's missing in your proposal
is by the way a way to invalidate a token. (Which in my approach would be
handled by pushing a new secret into the PEP node.)

However what you are describing is a fairly complex client-server protocol
(at least two commands for retrieving and invalidating the keys) that also
requires permanent storage on the server.

My proposal based on PEP and a commonly defined 'algorithm' for creating
and validating the tokens is a deliberately dumbed-down alternative that
uses an existing server side storage and an existing c2s protocol (PEP) for
invalidating previous tokens.

With the added benefit (but not the main reason I came up with that) that
it can still act as a client-only XEP. (Which seems to be important to
Georg as he doesn't believe (beside the compliance tester saying otherwise
:-) ) that servers will implement that in time.)

The only downsides I see - but are willing to accept - that this will limit
us to multi-use tokens that only expire after a set amount of time and not
a set amount of usages. And that the creation validation schema has to be -
as Sam points out - carefully defined. However I think this can be made a
lot less error prone by including an example in the XEP that shows the
algorithm with all it's steps. (Take timestamp X -> convert it into bytes
(show the bytes) -> use this key (show the key) hmac that (show the output)
-> base64 that (again show that in the example)
This way implementors can verify their own implementation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170510/2d0cd058/attachment.html>

More information about the Standards mailing list