WebOTP API

[samuelgoto]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: SMS Receiver API
• Specification URL: not yet available
• Explainer (containing user needs and example code)¹: explainer
• GitHub issues (if you prefer feedback filed there): issues
• Tests: WPT
• Primary contacts (and their relationship to the specification): @samuelgoto, @sso-google

Further details:

• Relevant time constraints or deadlines: [please provide]
• I have read and filled out it here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is:

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[dbaron]

A few quick questions:

• It seems like one piece of the security model here is that it's OK if the SMS ends up going to the wrong tab at the correct origin. Is that correct? That seems like it's fine for usage that's login-related, but might be (maybe?) more problematic for cases where the SMS is being used as a second factor to authorize a specific action. Are there cases where SMS is or might be used that way?
• I didn't see anything in the examples about how the site would figure out what hash it needs to put in the text message so that it gets routed to the browser. Presumably this would need to be a somewhat flexible API so that it would support mechanisms across different operating systems and browsers?
• the explainer references GMS core which I guess is a reference to Google Mobile Services but doesn't explain how that's relevant

I'd also note that there's been somewhat extensive discussion of this in mozilla/standards-positions#152.

[torgo]

Looks like the link to the assessment of the privacy questionnaire is a blank document.

[samuelgoto]

Thanks for the feedback @dbaron ! Replies inline!

It seems like one piece of the security model here is that it's OK if the SMS ends up going to the wrong > tab at the correct origin. Is that correct?

That's a correct interpretation of the proposal. It is currently implemented in "registration order", so SMSes are delivered in the order in which they were requested ("one SMS message per request").

That seems like it's fine for usage that's login-related, but
might be (maybe?) more problematic for cases where the SMS is being used as a second factor to
authorize a specific action.

Wouldn't app developers be using action-specific OTPs to avoid the confusion? That is, isn't it the case that, in the current status of the world, app developers already have to deal with the multi-tab / multi-task scenario and the race conditions that can occur here, regardless of whether the SMS is received programatically or manually?

Are there cases where SMS is or might be used that way?

Not that I'm aware of.

Interestingly, in the current proposed formulation, the entirety of the SMS is handed back to the developer (which generated it in the first place), so a lot of extra information can be embedded there. For example, one could use:

Your OTP for buying your item is 123!
For: https://example.com/buy_stuff.php?OTP=123

And use the following for logging in:

Thanks for logging in! Your OTP for logging in is 456!
For: https://example.com/signin.php?OTP=456

The message is entirely opaque for browsers, which only checks whether the For: footer in the SMS matches the origin that has requested it (to protect the same origin boundary).

I didn't see anything in the examples about how the site would figure out what hash it needs to put in
the text message so that it gets routed to the browser. Presumably this would need to be a somewhat
flexible API so that it would support mechanisms across different operating systems and browsers?

From a server-side formatting convention, we think that it suffices to specify a For attribute (with a URL as a value) that browser use to route the message (e.g. rather origins match).

Long term, we don't believe Android is going to need the app hash to route messages to browsers, so there isn't any proposal to expose the hash (or templates) from a Web API perspective.

the explainer references GMS core which I guess is a reference to Google Mobile Services but doesn't > explain how that's relevant

Correct, GMS core is referring to Google Mobile Services and it is relevant because it is the low level operating API that browsers would use (on Android) to access SMS and that dictates much of the server-side formatting conventions aspects of this API:

https://developers.google.com/identity/sms-retriever/overview

Does that clarify?

I'd also note that there's been somewhat extensive discussion of this in mozilla/standards-positions#152.

I am in that thread and am trying to respond as much as I can. Is there a specific comment / concern that hasn't been addressed that you'd like to bring up to our attention (more generally, but also more specifically anything that relates to this TAG review)?

[lknik]

Hello,

The proposal requires a security and privacy assessment, and the questionnaire filled.

Notably it would be necessary to see through these (among others):

• It seems you would need clear permissions for this use
• I don't think http/https is the main security issue here
• Possible risk of bypassing multifactor auth with this automated scheme?
• I don't think that fingerprinting/etc is the main privacy risk here
• Risk of private SMS hijacked by an origin? (i.e. fingerprinting aside, what about the privacy aspect of actual content of SMS)

[torgo]

@samuelgoto we are just picking this up at our Tokyo f2f. We're unclear as to the current thinking regarding permissions? If you are not considering an additional permission request, can you describe what the mitigation is against potential abuse? The security & privacy self check seems to be missing. If you have not yet filled this out, can you please take a look at the new privacy & security self-check we just published?

If the intended use of this is as a general replacement for log in, we are a bit concerned that this means service providers will always have the phone number (and therefore be able to correlate user's identity with their telecom provider)? This could be concerning from a privacy perspective. It's not that this is a new thing. It's been possible using existing technologies to ask for a user's phone number and then ask them to enter a code that is sent to them by SMS. The issue is that use of this API would make it so much easier to do this that you might risk this becoming the only means of authentication. Is that issue being discussed at all and if so do you have any thoughts on mitigation?

[torgo]

@samuelgoto if you are going to be at TPAC maybe we can see if we can have a chat there? /cc @hober

[samuelgoto]

hey @torgo i'm unfortunately not going to be at TPAC :( i'm in tokyo today if that's an option to you i'd love to chat!

[samuelgoto]

Answering your questions inline:

@samuelgoto we are just picking this up at our Tokyo f2f. We're unclear as to the current thinking regarding permissions?

Ah yes, totally my fault here, I need to fill out the security/privacy questionnaire. Will report back here, but before I do let me try to answer these questions in an unstructured form.

If you are not considering an additional permission request, can you describe what the mitigation is against potential abuse?

I think the latest thinking from our internal privacy / security reviews is that some sort of permission prompt is required. We are still experimenting with a variety of permission models, each with their own trade-off. You can see here the variations that we are exploring:

https://github.com/samuelgoto/sms-receiver#alternatives-considered

Our intuition at this point is that this may work best, but we feel like we are very much early in the process learning what works best, so we do expect a significant amount of iteration on the right permission UX.

Does that answer this question?

The security & privacy self check seems to be missing. If you have not yet filled this out, can you please take a look at the new privacy & security self-check we just published?

Yep, will do.

If the intended use of this is as a general replacement for log in, we are a bit concerned that this means service providers will always have the phone number (and therefore be able to correlate user's identity with their telecom provider)?

I don't think "the intended use of this as a general replacement for log in" represents well the goals. It is noted today in our explainer as a non-goal.

This could be concerning from a privacy perspective. It's not that this is a new thing. It's been possible using existing technologies to ask for a user's phone number and then ask them to enter a code that is sent to them by SMS. The issue is that use of this API would make it so much easier to do this that you might risk this becoming the only means of authentication.

Is that issue being discussed at all and if so do you have any thoughts on mitigation?

I don't think we have put much thought into this. I think it is a very good observation, I just don't have anything off the top of my head right now other than it is deliberately marked as a non-goal, but I see your point about second order and unintended consequences, so let me circle this around and get back to you with a well thought out position.

[samuelgoto]

Hey all, just wanted to cross post this here and report back on how things are developing here on my side (also, changed the title of this issue to reflect it).

===

Hey all,

Just wanted to report back on the progress we made here in this API since we initially proposed and to give a sense of where we are at.

We recently ran an origin trial with fairly good results giving us confidence about the space. Generally, origin trial participants were happy with the cost / benefit trade-off and were able to measure / quantify the impact of the adoption of the API in their user base.

We found (from internal reviewers, partners and other browser vendors), however, that we could tighten up the security/privacy/ux properties of the feature (while still capturing most of the desirable use cases) if we constrained the API to a specific use case, namely fetching one time passwords.

With that in mind, we have been working towards reshaping the API from a lower level SMS transport mechanism to a higher level OTP fetching mechanism, constraining its usage but tightening up privacy/security and UX, which seemed like the right trade off to us.

We cleaned up our explainer to reflect that as well as a draft of a spec (go easy on this one, really drafty :)), as well as renamed from SMS Receiver API to WebOTP API to reflect the intent, as well as have implementation well under way.

Having said all that, we are planning to send an intent to ship momentarily once we wrap things up, so we could use eyeballs sanity checking and making sure we didn't let anything else fall through the cracks.

Thanks,

Sam

[samuelgoto]

I don't think we have put much thought into this. I think it is a very good observation, I just don't have anything off the top of my head right now other than it is deliberately marked as a non-goal, but I see your point about second order and unintended consequences, so let me circle this around and get back to you with a well thought out position.

Ok, just trying to report back on this too. Answers below.

If the intended use of this is as a general replacement for log in, we are a bit concerned that this means service providers will always have the phone number (and therefore be able to correlate user's identity with their telecom provider)?

The intent here is certainly not to offer this as a general replacement for log in.

SMS OTPs can be used to help verify phone numbers, which is the extent that this API is designed to help.

For the most part, WebAuthn can offer much tighter security / privacy properties.

This could be concerning from a privacy perspective. It's not that this is a new thing. It's been possible using existing technologies to ask for a user's phone number and then ask them to enter a code that is sent to them by SMS. The issue is that use of this API would make it so much easier to do this that you might risk this becoming the only means of authentication. Is that issue being discussed at all and if so do you have any thoughts on mitigation?

Yeah, agreed that any global identifier makes collusion between parties possible. Emails have the same challenge. Obfuscated user ids too.

There is a larger discussion about global identifiers happening at this level, but nothing concretely affecting this specific proposal whose intention is to reduce friction (rather than decrease usage of global identifiers).

I think I empathize with your point about making more global identifiers (namely, phone numbers) more available, but I don't share the sentiment that moving the needle in either direction on that goal directly depends on the outcome for this API proposal (i.e. in practice, web apps can and will continue verifying phone numbers through SMS regardless of this API, e.g. safari has launched phone number verification some time ago without any major un-anticipated consequences as far as we can tell from where we are standing).

So, yeah, acknowledged about the risk here of promoting more global identifiers (which are bad), but, yeah, I think that the trade-offs are well balanced in terms of user benefits / risks.

Does that answer your question?

[samuelgoto]

Just wondering: is there anything else actionable on my side? I'm sure I'm forgetting something procedurally, but just wondering if you could help me identify what other artifacts I could provide that would help you make a more informed determination.

[dbaron]

@hober, @hadleybeeman and I are looking at this in a breakout at our Wellington face-to-face.

@hober just filed WICG/web-otp#18 and WICG/web-otp#22, I filed WICG/web-otp#19, and @hadleybeeman filed WICG/web-otp#20.

I'd also note (as mentioned in WICG/web-otp#19) that I was looking to see how that privacy difference was described in the security and privacy questionnaire... and I didn't see any filled-out version of the security and privacy questionnaire for this spec.

[dbaron]

One other question: I noticed the spec draft (which is still pretty skeletal) says:

[Exposed=(ServiceWorker,Window),
 SecureContext]
interface OTPCredential : EventTarget {
};

I'm curious if the exposure on ServiceWorker here was intentional, and if so, what the implications are, especially around the relationship of the use of this API to user interaction. If it is intentional, it seems worth discussing further in the explainer.

[pwnall]

@dbaron I suspect the SW bit is a copy-paste accident. We have Exposed=Window in the Chrome prototype.

[samuelgoto]

@dbaron yep, purely some bad copy pasting :) here it goes:

https://wicg.github.io/WebOTP/#OTPCredential

[Exposed=Window, SecureContext]
interface OTPCredential : Credential {
    readonly attribute DOMString code;
};

[samuelgoto]

Thanks for the feedback @dbaron and all!

I looked through these issues and resolved all of them providing more clarity and information where it was lacking. I don't think I found any disagreement nor anything that you'd want me to act on, so I closed and resolved them, but feel free to re-open in case my answers aren't satisfying.

• JavaScript API can't be used for polyfilling autocomplete=one-time-code in practice WICG/web-otp#18
• privacy differences between declarative and imperative forms of API WICG/web-otp#19
• Permissioning, user consent, and the Imperative API WICG/web-otp#20
• The polyfill example wont work in safari WICG/web-otp#21
• Why is the JavaScript API tightly bound to SMS? WICG/web-otp#22

Some of these I feel may be due to the explainer being a bit long and lack of clarity in it, which is totally my fault, so if you want me to jump into a video call and walk you through a demo and where we are at, I'd be happy to.

Thanks again for all of the great feedback, Sam

PS Anything else you'd like me to act on that I may be missing?

[samuelgoto]

I'd also note (as mentioned in WICG/web-otp#19) that I was looking to see how that privacy difference was described in the security and privacy questionnaire... and I didn't see any filled-out version of the security and privacy questionnaire for this spec.

Done. Thanks for bringing up!

[samuelgoto]

One other question: I noticed the spec draft (which is still pretty skeletal) says:

Yep, I think it was fair to call the spec "skeletal" :) Done, I cleaned it up and it is "less skeletal" at the moment, although there is still a lot more to be done and polished, but otherwise could use another round of reviews:

https://wicg.github.io/WebOTP

Feedback welcomed here.

[torgo]

There's a lot of active discussion about the advantages and disadvantages of competing proposals in this space. We don't feel we should steer that in any particular direction. We're not overly happy that there seems to be one approach to this being pushed by one implementer where competing proposals exist and could lead to better interoperability. We'd prefer to see a multi-vendor path forward here. However, we appreciate the standardisation of the wire format for the SMS across implementations.