[Standards] Proposed XMPP Extension: Authorization Tokens

Dave Cridland dave at cridland.net
Mon Sep 16 12:49:41 UTC 2019

On Mon, 16 Sep 2019 at 13:01, Andrew Nenakhov <
andrew.nenakhov at redsolution.com> wrote:

> чт, 12 сент. 2019 г. в 16:28, Dave Cridland <dave at cridland.net>:
> >> As for XEP-0399, well, in all honesty, it looks to be just a vague
> >> unfinished sketch of a badly needed XEP with key issues not solved at
> >> all:
> >
> >
> > You're welcome to help finish it.
> Suggested XEP-0399 is based on a new SASL method which is not widely
> used nor implemented anywhere (to our knowledge). And it is more
> concerned with the auth method itself.

Well, only in as much as it happens to be designed around one particular
token mechanism. Expanding that to cover more is fine by me.

> Our suggestion is basically PLAIN auth with a very simple
> implementation. Overall, the main idea of our XEP is not SASL method
> per se, but session management by use of tokens.
OK, but currently it defines a SASL mechanism.

> >> forbid connections without auth tokens
> > You can't do that, since otherwise a user cannot authenticate initially.
> The XEP does not impose any restrictions on initial auth methods. In
> the beginning a client authenicates itself and is issued a token on
> request, after which a server works with this session as with a
> session with a token, which could be later revoked in a regular way.
> This restriction means that if a client authenticated itself with a
> client and did not issue itself a token, a server should drop it,
> because a user can not manage such session.
At what point do you drop the session? Before it sends messaging? Or do you
want a mandatory step after (initial) authentication?

How are you intending to handle existing clients, which don't yet
understand tokens?

> Anyway, we've thought about all of this on a weekend. Our suggestion
> is really not about authentication method, it should probably be made
> neutral towards them. This means that section 4 (Authentication) of
> our XEP should be removed, and XEP should be rewritten. Support for
> session management with XEP-0399 and other auth methods can then be
> done as a separate XEP.
I'm not sure I understand what this would look like, but I'm happy to wait
and see.

> >> - concurrent devices do not receive any notification on newly issued
> tokens
> > That's a trivial addition if you want it. In fact, we could just to a
> "current tokens" PEP node if we wanted, though it'd need to be private of
> course.
> You see, many things in messaging are 'trivial' and can be done rather
> easily. But for some reason no one bothered to do them in XMPP for
> decades.¯\_(ツ)_/¯
That's a little harsh to someone who designed, implemented, specified, and
published a token-based system. If anyone thought it was missing something,
I was and remain open to suggestions.

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

More information about the Standards mailing list