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

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