5 Feb
2025
5 Feb
'25
8:35 a.m.
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' />