[jcranmer]

There is value in using PLAIN inside of TLS instead of SCRAM-* methods. If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext. So if you were state-of-the-art 20 years ago and used CRAM-MD5, and then you wanted to upgrade to SCRAM-SHA-1 when that came out... you don't have a good migration story, since the password storage has the information needed to validate CRAM-MD5 but not SCRAM-SHA-1, and there's no way to regenerate the information for SCRAM-SHA-1 without the plaintext password.

But if the authentication server gets the plaintext password, it can validate it against the old CRAM-MD5 storage, see that it matches, and then update the storage to SCRAM-SHA-1 on the fly. The entire process is invisible to the user, who gets a security upgrade in the process.

There's another class of use-cases, where a service needs to authenticate a user based on a token from another service. But for this, it's better to dispense with passwords entirely and instead go to something like Kerberos, where the authentication service gives you tokens in lieu of any password information.

[jimis]

> If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext.

I consider this an advantage. I know how the password is stored, and if the service wants to update the storage, than it has to ask me to reset my password. If it doesn't ask me so, how can I know that they are up to date?

> The entire process is invisible to the user, who gets a security upgrade in the process

or never gets a security upgrade, and he has no idea.