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

Why is the JavaScript API tightly bound to SMS? #22

Closed
hober opened this issue Mar 4, 2020 · 1 comment
Closed

Why is the JavaScript API tightly bound to SMS? #22

hober opened this issue Mar 4, 2020 · 1 comment

Comments

@hober
Copy link

hober commented Mar 4, 2020

@dbaron, @hadleybeeman, and I took a look at w3ctag/design-reviews#391 today in our Wellington F2F. We have a variety of feedback, of which this issue is one.

In the JavaScript API, navigator.credentials.get() takes an options dictionary that specifies that the desired credential is a one-time-code, and that it comes over SMS:

navigator.credentials.get({otp: {transport: ["sms"]})

This is in contrast to autocomplete=one-time-code, which does not specify the source of the one-time-code. It could be from SMS, from a TOTP app, or from some other source. The author of the page doesn't have to say where the code comes from. This seems to us a simpler API to code to than the JavaScript API, that is perhaps more resilient to changes in the site's authentication mechanisms. The Rule of Least Power suggests we should prefer the simpler approach that solves the same use case.

Why tie the JavaScript API to SMS like this? Why not follow autocomplete=one-time-code?

@hober hober changed the title Why is the Imperative API tightly bound to SMS? Why is the JavaScript API tightly bound to SMS? Mar 4, 2020
@samuelgoto
Copy link
Collaborator

samuelgoto commented Mar 19, 2020

We are exploring how to make email verifications work in collaboration with email providers and we are seeing how it is going to be key for a browser to know where to expect the OTP to be coming from.

That is, if the OTP can come from multiple sources, and listening / engaging with those sources isn't cheap / trivial (e.g. communicating with an email provider or expecting an SMS from the cellular network), a browser benefits from knowing where it is expecting to come from to make informed decisions.

Because this API needs to be forward compatible when / if we introduce other transport mechanisms (e.g. email is looking like the most likely), we thought adding transports to the API bit at the moment would enable us to add more in the future.

I hope this explains sufficiently, but I can certainly go on more about how far we are getting into verification of email addresses and provide much more details that is informing this specific bit of the API.

I'm going to close this since I believe I answered your question, but feel free to re-open if you need further clarification or information or need me to act on anything, and I'd be happy to course correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants