On Wed, 5 Feb 2025 at 15:35, Stephen Paul Weber <singpol...@singpolyma.net> wrote: > > >I don't think FAST is tied to any particular SASL mechanisms? That's why we > >duplicate mechanism discovery as part of FAST, which is the main thing I'm > >talking about here. > > Ok, so, a concrete proposal for an alternative to the current design which I > think would work for FAST and also for other things such as app passwords: > > When requesting a FAST token, return the token and also a SASL authcid value > to go along with it. Then when doing authentication in the future, this > authcid will select which credential to check against (the FAST token) > instead of using a custom mechanism (the <fast/> tag).
The authcid is how we convey the authenticating username. > This solves one of the two warts in a way that works with SASL instead of > reinventing it. > > Now, as for the duplicate mechanisms thing, I don't personally see why this > is needed at all at this point. A token is a password and thus should work > with any password-supporting SASL mechanism (HT-*, SCRAM, PLAIN, etc). > However, in case we want to still allow servers to not implement FAST for > every relevant SASL mechanism they support, I would suggest this change. > Instead of: The problem is that for some mechanisms and authentication backends, the server needs to know what kind of credentials are being used up-front. In an ideal world, I think we would have SASL able to encode this information. Specifically, there are two things the server needs to know: 1) The type of credential being used (password, FAST token, bearer token, etc.) 2) In some cases, some identifier of the credential being used (when the same user has multiple credentials of the same type, common with tokens) In many cases (1) can be hackily inferred from the mechanism - e.g. just assume that SCRAM is always a password, and that HT is always a FAST token. However I don't think this is a future-proof design, and there are cases where a mechanism may be useful for multiple credential types. For (2) we currently use the SASL2 client id (a single user may have multiple FAST tokens, because they have multiple devices). Again, it would be great if SASL had this concept built-in, but it does not right now. The FAST protocol was designed the way it was in order to work around these constraints. I agree that the protocol could be more elegant if we were to change the SASL layer to accommodate some of its requirements. But I also think that what we have is fine and future-proof. Regards, Matthew _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
