Hi, without trying to rehash what Matthew said I just wanted to give my +1 to everything he said.
Inline + User-Agent good. Very skeptical on forbidding PLAIN and the dependency on channel binding. I don’t yet have on opinion on the tasks issue. cheers Daniel On Tue, Oct 18, 2022 at 4:02 PM Matthew Wild <mwi...@gmail.com> wrote: > > 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. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
