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

Daniel Gultsch daniel at gultsch.de
Wed May 10 19:29:50 UTC 2017

2017-05-10 21:02 GMT+02:00 Sam Whited <sam at samwhited.com>:

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

Oh yes the normal revocation after being used would be handled by the
server. But I was thinking of a 'this token got leaked by accident and now
the user wants to invalidate it' kind of scenario.

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

Just to be clear; When I say client-only I only mean this as a fallback.
The default and preferred method would be to have this handled by the
server. And I can imagine a prosody module for this would have like 10
lines of code and see pretty fast adoption.

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

This probably speaks to a broader point of who we are making extensions for
and who is our target audience and is a very theoretical question that goes
way beyond discussing this particular extension.
IMHO the hypothetical service operators who maintain their own service
which are self-branded are very welcome to step forward now and try to get
their use case covered but keeping them in mind without knowing who they
are is a waste of time.
If we can agree (we don't necessarily have to) that my approach is simpler
and easier to implement and covers *our* use case I don't see why would
should add complexity for users who don't even bother to read the mailing

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

More information about the Standards mailing list