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). 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: <request-token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP'/> We do (insersection of server and client supported mechanisms): <request-token xmlns='urn:xmpp:fast:0'> <mechanism>SCRAM-SHA-1</mechanism> <mechanism>HT-SHA-256-ENDP</mechanism> </request-token> And the server will select a supported one to bind to the token: <token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP' expiry='2020-03-12T14:36:15Z' token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' />