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.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to