Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMS OTP Retriever / SMS verification / Sign up API #152

Open
dbaron opened this issue Apr 24, 2019 · 9 comments

Comments

Projects
None yet
5 participants
@dbaron
Copy link
Member

commented Apr 24, 2019

Request for Mozilla Position on an Emerging Web Specification

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

@dbaron dbaron added the wicg label Apr 24, 2019

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Apr 25, 2019

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.

Screen Shot 2019-04-25 at 11 21 02 AM

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

This comment has been minimized.

Copy link

commented Apr 26, 2019

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

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

Awesome! thanks for the pointer @hober.

@hober

This comment has been minimized.

@mikewest

This comment has been minimized.

Copy link

commented May 2, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented May 2, 2019

Thanks @mikewest. Will follow along :)

@dbaron

This comment has been minimized.

Copy link
Member Author

commented May 7, 2019

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

This comment has been minimized.

Copy link
Member Author

commented May 7, 2019

Also cc @mnoorenberghe

@samuelgoto

This comment has been minimized.

Copy link

commented May 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.