Note that, to verify the hash, the input needs to be identical: a single space out of place or difference in punctuation or capitalization is enough to break it.

The committed identity as described at https://en.wikipedia.org/wiki/Template:Committed_identity envisions more than just a word or phrase. It wants the input to also contain contact information, and then the "op" is supposed to use that information to contact the requester and verify they're really the one making the request. I see the current version also suggests including some random data, to the point where you're going to basically be saving a .txt file with your identity data and you could probably just put your scratch codes in the file instead.

If the user is expected to remember it, its probably brute forcible (especially if its a publically stored sha-512). If users were able to reliably do this, we wouldnt need 2FA, we would just use passwords

I'm tempted to decline this, but maybe others feel differently.

1. First, regarding the technical aspect, I believe this is outside of the scope of this extension. E:OATHAuth is meant to provide common two-factor authentication systems for account login, not to implement new account recovery techniques such as a committed identity. Something like a secret passphrase with a committed identity that a user can use to reset their account with belongs in its own extension. In other words, the functionality of the Special:CommittedIdentities page and everything associated with it seems entirely independent technically and implementation-wise (as opposed to policy-wise) from this extension. For example, let's say the we decide to implement a committed identities page, but the community or WMF or even we agree that it should only be used to reset their password and not their 2FA (which is an entirely reasonable policy), then it has no ties to OATHAuth at all.
2. Second, regarding the policy aspect, having a committed identity of any sort defeats the entire purpose of 2FA, which is to require a user to provide something they know as well as something they have. A committed identity is something they know, so you're defeating the requirement that the user has some sort of physical or virtual token that cannot be (at least easily) stolen electronically or socially engineered. As Brad mentioned, the intention is maybe to have a bit more than that, where a user provides contact information in their hash that is then verified, but I really wonder what contact information would be sufficient. Email? Well then they can just use password recovery. Snail mail? The WMF isn't going to send physical letters to users with temporary passwords. Phone? They should have their 2FA anyway at that point (I know there's are situations where a phone breaks, so a phone number can still be used to verify, but it's not the best security, and still requires somebody to call the user).

In the end, I still feel like, for most accounts (with the exception of important privileged ones, where the user would be personally identified to the WMF anyway), it is not worth it sacrificing the security of 2FA and the time of either community members or WMF employees for an ephemeral username.

Based on https://en.wikipedia.org/w/index.php?title=Template_talk:Committed_identity/Archive_1&oldid=723285534#Get_rid_of_this if we're going to officially support this type of system, we should at least do it properly e.g. with PGP rather than the existing system enwiki seems to advocate.

The point of this is to avoid users getting locked out of their accounts because their phones or generating devices gets broken or stolen or run out of scratch codes. I mentioned the enwiki template as a visual example, but it's just an example. The root of the problem still persist IMHO.

In T150947#2803202, @Parent5446 wrote:

In the end, I still feel like, for most accounts (with the exception of important privileged ones, where the user would be personally identified to the WMF anyway), it is not worth it sacrificing the security of 2FA and the time of either community members or WMF employees for an ephemeral username.

I'm thinking on those senior accounts, but the identification process changed some time ago. We now just sign a Legalpad document with our usernames and it's all done.