чт, 12 сент. 2019 г. в 13:43, Dave Cridland <d...@cridland.net>: > There is nothing particularly wrong about this. Some of it (the token > management stuff) does belong in a XEP, though we have ways of doing this > already (XEP-0399, and to some extent, XEP-0397), that I think are > sufficiently close as to not really need anything radically different. > > The token mechanism itself, being a SASL mechanism, is however entirely out > of scope for the XSF to standardize - that would need to go through the IETF. > In this instance, it's a straightforward copy of PLAIN - whether it needs a > different mechanism at all is an interesting question and one I do not have > the capability to answer, but the Kitten group at the IETF might well have > opinions.
This is not so. This proposal is not a 'copy of PLAIN', it just uses PLAIN and is built on top of it. We do not consider XEP-0397 as a viable alternative to this because this XEP is about managing sessions and revoking access from lost/compromised devices, and for removing the necessity to store the password on the device. Also, we have different views on all this 'stream resumption' stuff - we're generally going in an orthogonal direction with 'state restoration' approach. 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: - a user is not protected against password leak, authenticated user session can't be broken with suggested mechanics - concurrent devices do not receive any notification on newly issued tokens - key revocation does not result in session cancellation Differently to 399, we suggest: - a token is issued by a server, not by a client (that also removes risks associated with using a malicious client, ) - a session is linked to a client and can be revoked at any time - it is forbidden to connect with one toked using different devices - forbid connections without auth tokens > But I'm entirely sold on the need for "something like this", and would be > very grateful if you look at '399 and '397, as well as CLIENT-KEY and HT-* > over at the IETF, and if you'd like to take over '399 I'd appreciate it. We did look at these. 397 has a very different intent, and 399 suffers from key issues described above. Fixing these will result in a XEP identical to the current proposal. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
