Add a new input type for verification codes

[alejsanc]

A verification code sent by SMS is increasingly used as double authentication. To enter this code and make it not visible it is common to use a password input. When the browser sees a password input it thinks it is a user password and gives you the opportunity to save the password. To avoid this, a new "verification-code" input could be used.

<input type="verification-code"/>

[dbaron]

Some prior work in this space:

• WebOTP API: See specification, MDN, TAG review, Chrome Status, Mozilla position discussion.
• autocomplete=one-time-code: HTML PR, further HTML issue, MDN.

[gregwhitworth]

@alejsanc any reasons that the autocomplete solution provided by @dbaron won't suffice?

[lukewarlow]

@alejsanc is there anything further you'd like to add or can I go ahead and close this issue?

[lukewarlow]

Ah rereading this I guess the request is for a way to hide the contents of an input that isn't type password. Which I think is a valid request. But probably better directed to the CSSWG directly.

w3c/csswg-drafts#6788 mentions something similar (more about toggling the obfuscation of password inputs)

I would like to say that the context of this request is odd though. Why does a one time code need obscuring on entry? Anyone looking of their shoulder shouldn't have enough time to enter this code in a useful manner regardless of whether they can see it?

[gregwhitworth]

The CSSWG is not the correct location for this but WHATWG.

Why does a one time code need obscuring on entry?

+1 from me but honestly this would be easy to implement by merely duplicating the majority of password outside of the various namings.

[lukewarlow]

I thought csswg for a new "input-obscure" property. But yeah for a whole new input type it'd be whatwg

[alejsanc]

I would like to say that the context of this request is odd though. Why does a one time code need obscuring on entry? Anyone looking of their shoulder shouldn't have enough time to enter this code in a useful manner regardless of whether they can see it?

Both by computer and manual means, the user can be stopped before using the code and give the attacker time. In general, the more barriers the attacker has, the better.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.