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' />
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
