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

Sam Whited sam at samwhited.com
Wed May 10 19:02:42 UTC 2017


On Wed, May 10, 2017 at 1:41 PM, Daniel Gultsch <daniel at gultsch.de> wrote:
> 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.

That's fair; to me anything more than a simple query to ask for a
token and insert it into some sort of payload feels like more than
what a client should be doing, but I'm ont stuck on that point.

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

That's fair, I was thinking this would be entirely up to the server,
but it would also need to advertise that it supported revocation, and
clients would need some sort of "revoke this token" IQ as well. It
does mean that we have to define more wire format.

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

PEP requires storage on the server too (not necessarily permanent of
course, but depending on the implementation this could share a data
store with PEP too; again, that woudl all be up to 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.

I like this a lot.

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

I suppose this is where I'm torn; I'm not completely against making
this a client-only protocol, but in general I think things like this
should be handled as much by the server as possible.

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

The other downside, and what I'm most concerned about, is that this
limits the spec to being used in the scope of servers that operate on
the individual-account model where you have a personal account which
you add friends on. Service operators who maintain their own services
which are self-branded (I'm not sure what to call that) but
interoperate with the XMPP network may want to impose restrictions on
how people can add eachother to their roster, eg. tokens might be
issued only for specific users without hitting the database to do
lookups (HMAC), or only for n-uses (hit the database have a counter),
etc. Supporting multiple token policies seems more desirable to me
than making this a client-only protocol personally.

—Sam


More information about the Standards mailing list