4 Feb
2025
4 Feb
'25
1:37 p.m.
I guess that depends a lot on what exactly your vision
for "app
passwords" is but if they don’t renew themselves and aren’t
necessarily requested via XMPP you can just use SASL2 with PLAIN for
example and already get the 0rtt parts.
Yes, with PLAIN is what I do now, but no way to use SCRAM for example which
is the whole issue.
(I actually have a deployment where we use PLAIN anyway
and thus never
felt the need to use FAST after we got SASL2+Bind2)
Generally for me the purpose of FAST is to stop storing passwords on client
devices, but I understand everyone has their own use case.
I mean FAST is really just a thin wrapper around a
family of SASL
mechanisms so I don’t get the point that it is too narrowly defined
around those mechanisms.
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.