You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
The text was updated successfully, but these errors were encountered:
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.
@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: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
?The text was updated successfully, but these errors were encountered: