So, from what I can tell, what this XEP introduces is the ability to fetch a token after authenticating that can be used for subsequent authentication attempts, and the goal is to reduce the initial time to log in.
I am not convinced that this particular approach, as presented, is the solution. Issues: 1) The Kitten WG released RFC 7628 (https://tools.ietf.org/html/rfc7628) a few months ago for a standard OAuth SASL mechanism (named OAUTHBEARER). That should be recommended instead of X-OAUTH (if this really is an OAuth system). However, given that this XEP is specifying a success response for this X-OAUTH mechanism, is this XEP intending to define a new SASL mechanism? 2) The semantics of 'access' and 'refresh' tokens here are different than the semantics used by OAuth, which left me confused for a while. That is, the 'access' tokens used here are simply one-time-use tokens, and 'refresh' tokens are multiple-use tokens (potentially 'refreshed' by the issuance of a new token after each use). The OAuth semantics of using a refresh token to generate a new access token are not in play here, because a refresh token can be used directly for authentication without any access tokens generated. I'm not sure if bringing in the term OAuth is appropriate for this XEP (using tokens doesn't automatically mean it is OAuth). 3) This does not really decrease the initial authentication and subsequent stream setup time. It is still using the full SASL process, so time wise it is exactly the same as PLAIN. It is exactly one round trip faster than SCRAM-SHA-1. It does use less hashing, which I agree can have a noticeable delay in some browsers; however, the derived materials generated during SCRAM-SHA-1 can be cached to significantly reduce the calculation time for subsequent logins, and also serve as a secure replacement for the plaintext password (which is also revokable by the server using a new salt). One of the primary use cases I would have for this system would be web-based clients, where frequent disconnects can make the initial start up time painful. For applications where a web-based XMPP client is intended to only speak to a particular XMPP server, using OAUTHBEARER is the better solution, as the web client is likely to also need a traditional OAuth token for accessing other HTTP APIs. It would also be usable for the very first authentication attempt, not limited to subsequent sessions. Integrating this sort of token authentication with XEP-0198 would be the bigger win, because then SASL could be skipped entirely along with the initial stream setup (like how we can use BOSH with pre-binding). The stream management ID could easily be a JWT or equivalent token that would be sufficient for authentication. The missing piece would be allowing the <resumed/> element to include a new ID value (I'm not sure why it currently returns the 'previous' ID without allowing a new ID). /Lance
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
