Hi folks, For context, there is an update to XEP-0388 (SASL2) pending:
PR: https://github.com/xsf/xeps/pull/1214 HTML: https://dyn.eightysoft.de/final/xep-0388.html HTML (diff): https://matthewwild.co.uk/uploads/xep-0388-diff.html As per policy, we're bringing any substantial discussion to the mailing list. Nevertheless, you'll find an initial review by Dave (original author of the XEP) at the above link. We have quite a few prototype implementations of (many of) the new changes already in Prosody, Conversations, Monal, Gajim and Siskin. The main changes that I'm interested in are the following: 1) Advertisement of supported "inline" features One of the initial premises of SASL2 was that you would be able to negotiate various other things at the same time as authenticating. For example, this quote from the original XEP: "In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests." To make it easier to talk about, I generally refer to this feature as "inlining" (which is different to pipelining, another similar method to reduce round-trips). While implementing, I quickly realised that the server supporting SASL2 and also supporting XEP-0198 is not enough information to determine that the server supports negotiating XEP-0198 inline within SASL2. For this reason we added the <inline> element within the SASL2 stream feature element. This <inline> lists the features that are supported for SASL2 inlining. An example of this can be found here: https://dyn.eightysoft.de/final/xep-0388.html#example-2 It's important to stress that, despite calling out XEP-0198 and Bind 2 in the changelog and text, this is intended for example purposes only. There is no intention to increase the scope of XEP-0388 to cover which specific protocols can be negotiated (in fact this is the whole reason for introducing <inline/> as an extension point). Therefore, the exact rules for handling inlining of features are to be specified elsewhere. For example, there is a proposed update to XEP-0198 for exactly this: https://github.com/xsf/xeps/pull/1215 I have also submitted an update proposal for XEP-0386 Bind 2, which uses <inline> to advertise support (it will need to be revised if <inline> is not accepted). 2) <user-agent> One thing that has always frustrated me with our current authentication flow is that things like per-device credentials were impossible to do (securely). It's possible for e.g. PLAIN that a server could iterate through a list of acceptable passwords. But this doesn't work for more advanced mechanisms such as SCRAM. The same issue applies to token authentication, if we want to support fancier mechanisms such as Florian's HT-* proposal. We solved this by adding a stable client identifier. Its value and lifetime are client-chosen, but it allows the server to scope credentials to a specific client. This allows per-device credentials, more advanced authentication flows, and finally opens up the door to being able to view and manage what clients currently have access to your account (something that is invisible when all you have is a single password shared across all your clients). It also provides a foundation for many other advanced features, such as the server being able to associate things like push registrations to specific clients, and therefore stop pushing data to client developer push services if you no longer use their client (although we already attempt such cleanup, it's pretty hacky and unreliable right now). As well as the client identifier, the element optionally allows the client to include software and platform name. This can be used for diagnostic purposes ("what is this client that always fails to connect?") as well as allowing the server to provide more information to users about what is accessing their account. Now, there are some other changes in this update. My reading of Dave's review is that features related to specific mechanisms (such as the SCRAM upgrade) are out of scope for this document. I think I agree with that assessment. Likewise, channel binding is already covered by XEP-0440 and individual mechanisms. It would be good to keep this XEP as a mechanism-agnostic framework. Finally, I'm on the fence about one thing: switching the task syntax from base64 data to XML (and separately, dropping the <continue>/<next> framework). I'll start a separate thread about this, as it probably needs more discussion and this email is long enough already. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
