I'm not wild about forcing everyone to run auth list-providers before auth strip, especially because this is likely to be a flow carried out during extreme stress/urgency after a security incident. My naive suggestion is to make providers provider a "shortname" like sms, totp, etc, but I'm sure there's an obvious reason not to do that. This also means that we can't provide a documentation example like bin/auth strip --type sms or similar.

"Specify either specific providers"

"which provider to strip"

"strip all providers"

Ok this one should actually be "factors".

Do ProviderConfigs have a status that we could set to disabled instead?

Thinking about potential advantages of non-destructive deletes:

• Maaaaaaaybe it's a good idea to require that all factor configs must be globally unique across all of history? I'm thinking of something like 1) install decides to strip everyone's SMS MFA factors because an attacker was playing social engineering games and took control of a subset of employee phone numbers, 2) one of those users with a compromised phone doesn't know it yet, 3) user gets forced on next login to configure SMS and naively puts their compromised phone number back in. This attack is (mostly?) defeated by forcing the user to pass an SMS MFA check before marking that provider as active. This is obviously contrived, and not letting anyone reuse a phone number would screw up lots of expectations about recovering from a breach like this anyway, so maybe ignore all this(?). (But as a note, UI-wise it'll be important to separate "Add SMS number to my Settings" from "enable SMS as an MFA provider" anyway).

• We could add a DisableProviderConfigTransaction that would log the dastardly user that stripped everyone's factors through malice, but if you already have access to bin/auth you can alter the DB anyway.

• Provides better post-mortem audit-ability in a nebulous hand-wavy way by being able to answer the question "who had which providers enabled" at any point in time.