SMS OTP Retriever / SMS verification / Sign up API

[dbaron]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: SMS OTP / SMS verification / Sign up API (depending on which of the below links you follow)
• Specification or proposal URL: WICG spec, Chrome Status page, WICG Discourse page, Explainer
• Mozillians who can provide input (optional): @jcjones @martinthomson and probably others (please @-mention more)

This is something that Google folks are working on that it would be good if we had an opinion on.

[marcoscaceres]

Safari on iOS solves for this without needing an API. If you have an input focused, and you get an SMS, the keyboard automatically finds the code in an SMS and you can just tap it to fill it in.

I don't think what's being proposed is bad tho, and maybe would be nice to just have a "otp" autocomplete type for inputs in HTML... but I believe Safari is able to handle this without needing to make any changes to the platform, so I'm not convinced we need a new API for credential management (plus SMS is not very secure).

[hober]

Our proposal is/was autocomplete=one-time-code. Safari supports this value, and IIRC falls back on heuristics if it's not present.

[marcoscaceres]

Awesome! thanks for the pointer @hober.

[hober]

FYI, autocomplete=one-time-code is now specced in HTML.

[mikewest]

@marcoscaceres: It might be worth taking a look at the thread in whatwg/html#4586 for some of the rationale behind the more complex approach @samuelgoto, et al. have proposed.

[marcoscaceres]

Thanks @mikewest. Will follow along :)

[dbaron]

I think whatwg/html#4586 (comment) makes two good points (which I repeat with some of my own interpretation added):

• autocomplete=one-time-code doesn't appear to be implementable on Android without requesting permission to read all of a user's SMS messages, which is probably a non-starter for most browsers
• as far as I can tell, autocomplete=one-time-code is just as vulnerable to a phishing attack as username and password fields are. While the value of SMS OTP/2FA is really in preventing the replay of old passwords rather than preventing phishing, it seems like doing something that helps prevent phishing would be valuable.

So then there's the question of whether it's better to do this feature 100% in markup (which requires a bit of user intervention to perform the autofill) or whether to make it an API that could be implemented with less user intervention. (The user intervention may, however, be useful as a consent mechanism, and might in fact be the clearest sort of consent mechanism.)

[dbaron]

Also cc @mnoorenberghe

[samuelgoto]

Apologies for the late reply, but I tried to break things down into multiple orthogonal dimensions here to help me clarify what I have as a mental model:

whatwg/html#4586 (comment)

For example:

autocomplete=one-time-code doesn't appear to be implementable on Android without requesting permission to read all of a user's SMS messages, which is probably a non-starter for most browsers

It is not entirely clear to me why that might be the case.

[dbaron]

It is not entirely clear to me why that might be the case.

That was my interpretation of what I read in whatwg/html#4586 (comment)

[samuelgoto]

That was my interpretation of what I read in whatwg/html#4586 (comment)

I tried to clarify this a bit more here, with pointers to the underlying OS APIs:

whatwg/html#4586 (comment)

autocomplete=one-time-code doesn't appear to be implementable on Android without requesting permission to read all of a user's SMS messages, which is probably a non-starter for most browsers

I don't believe this is the case. I do think that a declarative autofill=one-time-code should be possible without the over-permissive read all of user's SMS messages permission.

[dbaron]

Oh, right -- so a declarative API would still be possible, assuming that the constraints on the format of the SMS message were still met.

Also, thanks, whatwg/html#4586 (comment) is a useful separation.

---

One other comment from @ekr was the question of whether it's desirable or undesirable that the SMS format be human readable. It seems like an alternative, with different tradeoffs (between phishing and edge-case usability) would be to have an SMS message format that's not human-readable. This (hopefully?) makes it harder to trick a person into pasting the code into a phishing site (or maybe not), but might make edge cases (bad connectivity / timeouts / etc.??) worse.

---

In any case, I'd be interested in opinions from @annevk and @martinthomson as well -- and hopefully we can try to come to some sort of conclusion sooner rather than later.

[martinthomson]

I like @annevk's comment on the bug, but no matter how true that is, it isn't really a position we can stand on, because SMS OTP is very common and maybe a tiny bit better than not having it. If the goal is to improve usability, this is a fine idea.

The model that iOS appears to use is one based on inference. The form field indicates an interest in a OTP. The keyboard (which might reasonably be given access to SMS) is responsible for retrieving codes, not the application itself. Until a code is picked, I hope that the application/site doesn't get any info.

The weakness here is that it relies on inference to a high degree. OTP SMS are not regularly formatted in any way because they are designed for humans. And humans being involved is a big part of the fallback story.

Yes, we could insist on a new media type for SMS messages that were intended to be routed directly to sites. That could include an origin and a tag, plus maybe even some crypto to ensure that only the origin who wanted the message could get it (whoa!). But that would not be as good as WebAuthn, and it wouldn't even reach everyone. The nice thing with SMS is that I can use the codes on my desktop browser too, even if it doesn't do that SMS forwarding thing that some systems support. Anything we do to make the messages unreadable to humans is going to make those setups worse.

So I would say that the inference is basically acceptable. We might improve the situation by providing additional constraints, like the OTP message having to include the name of the server, but it doesn't seem like a good idea to let sites pick a template.

I don't think that access to the SMS is entirely necessary, but you could provide a much more limited access if this were the only use case you had in mind. Mike's suggestion to hash or sign the message is an interesting one, but it isn't necessary. You can have the site provide a hash of the message before it asks for it. That proves that it already knows what it was going to send. It's the other type of one-time password. That way, you don't have to worry about polluting messages with gibberish. Think <input type=text sms-message-hash=sha-256:blah>. That could even be filled without any interaction at all if you were willing to have the entire SMS sent in the field (a separate hidden field might do for this purpose).

[mnoorenberghe]

I don't really have much to add to this since it's not clear to me that we will implement OTP support using SMS and so I haven't looked into the feasibility of implementing such a thing. If we were to help the user with OTP I suspect we would start with more secure solutions first (e.g. TOTP) and by the time that ships SMS OTP usage may be low enough that we won't worry about SMS.