Intent to Implement: SMS OTP Retriever API

[Sam Goto]

Contact emails

go...@chromium.org, jsb...@chromium.org, rei...@chromium.org, s...@google.com, ay...@google.com

Explainer

Link to explainer and WICG thread.

Design doc/Spec

Not yet available. Will update this thread when ready. There is a comparable API on Android and an early prototype for Chrome in development.

Summary

The SMS Retriever API gives developers the ability to programmatically read SMS messages that are delivered to the user’s phone that are addressed to their origin (via a special formatting convention, details here), eliminating a manual step for one-time passwords (OTPs).

Motivation

Developers use phone numbers for a variety of use cases (see a more in-depth analysis here). In the process, it is often required that phone numbers be verified, which is typically done via sending a one-time password (OTP) via SMS which must then be manually entered by the user (e.g. copy/paste).

Native applications have access to a programmatic API that enables them to read specific SMSes that are addressed to them through a formatting convention, skipping the need for a manual user interaction, decreasing user friction (i.e. fewer steps) and increasing conversion rates (e.g. users abandoning signup flow due to problems switching apps and copying/pasting).

Currently, web apps are forced to implement a manual user flow, which requires the user to be directed to the native SMS app and back to their web app with the code.

In this proposal, we are looking into exposing a Web API that enables web apps to make this process more seemingless.

Risks

Interoperability and Compatibility

Edge: no public comment on web facing API

Firefox: no public comment on web facing API

Safari: implements an autofill type that enables OTP mediation. No public comment on imperative API.

Web / Framework developers: no public comment on web facing API.

Ergonomics

> Are there any other platform APIs this feature will frequently be used in tandem with?

Nothing immediate comes to mind. The exact materialization of the API is still to be formed, but as a reasonable starting point, take the Android imperative API which is fairly self-contained.

> Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

Nothing immediately comes to mind.

Activation

> Will it be challenging for developers to take advantage of this feature immediately, as-is?

We got a substantial amount of support from web developers to narrow this gap with native applications, especially in emerging markets, so we don’t expect to be challenging for developers to adopt this feature.

> Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes, we expect significant documentation and outreach and / or libraries to play a big role.

There is a well established ecosystem around this API on native apps (e.g. frameworks for sending SMS, validated privacy/security trade-offs, etc) which we are intending to reuse as much as possible.

Debuggability

Developers can manually debug/trigger this feature on any phone that can receive SMS (e.g. it requires a mobile line / phone number).

Because it is both expensive and unreliable to use the mobile carrier, It would be helpful if devtools allowed simulating the mobile network on mobile devices, etc. It **can** be tested manually, but it is not as convenient (e.g. one has to wait X number of seconds, etc).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature can be implemented natively on Android through the Android GMS APIs. On desktop (Windows, macOS, Linux and Chrome OS), for logged in users, we are contemplating making a remote procedure call between the user’s desktop Chrome instance and the user’s Android/mobile Chrome instance to gather the contents of the SMS (automating what would have happened manually - a user would manually switch from the desktop to the phone and manually enter the code).

Is this feature fully tested by web-platform-tests?

Tests will be added as WPT where possible.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5873577578463232

Requesting approval to ship?

No

[PhistucK]

As far as I remember, the previous attempt(s) to implement this were shut down (or maybe just discouraged?) due to the low security of SMS (the team did not want to express support for such a low security mechanism). Has this changed?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-y4%2BYvVueLovB3HbtFrO6SrQkw-HquJsBZg_P%2BfpvpEnA%40mail.gmail.com.

[Reilly Grant]

On Thu, Apr 18, 2019 at 11:35 AM PhistucK <phis...@gmail.com> wrote:

As far as I remember, the previous attempt(s) to implement this were shut down (or maybe just discouraged?) due to the low security of SMS (the team did not want to express support for such a low security mechanism). Has this changed?

This question is answered in the explainer: https://github.com/sso-google/sms-otp-retrieval#why-are-we-telling-developers-to-use-phone-numbers-they-can-be-hijacked-change-ownership-used-to-track-users-etc

[Jochen Eisinger]

For reference, this is the previous thread: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sa5Tvr4QyWI/Pk_ohqbpBAAJ

Another question that was raised back then: will this be an Android only API, or are there plans for desktop / iOS?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMaqQq%3DO7dNg5faK-Z-BF22mLQWJ6CXASMGR0yXFMwBB7w%40mail.gmail.com.

[Reilly Grant]

On Mon, Apr 22, 2019 at 1:47 AM Jochen Eisinger <joc...@chromium.org> wrote:

For reference, this is the previous thread: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sa5Tvr4QyWI/Pk_ohqbpBAAJ

Another question that was raised back then: will this be an Android only API, or are there plans for desktop / iOS?

[Daniel Vogelheim]

Sam, please file for privacy + security reviews when ready.

Off-hand, I'm not seeing any pressing concern, and I very much like the idea that any origin can only "see" SMSs that are intended for it. Still, there's clearly some privacy/security impact here, so a review would be in order.

(The only specific concern I have it that the formatting convention (origin + app-dependent value) comprises only publicly known info, which allows any sender to send SMS to any origin, regardless of whether the origin is set up to deal with untrusted SMS or not. This might aid with phishing.)

(Nitpick: I think your link to "formatting convention" is wrong. I assume you meant this, 2nd example.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-y4%2BYvVueLovB3HbtFrO6SrQkw-HquJsBZg_P%2BfpvpEnA%40mail.gmail.com.

[Sam Goto]

On Wed, Apr 17, 2019 at 5:22 PM Sam Goto <go...@chromium.org> wrote:

Contact emails

go...@chromium.org, jsb...@chromium.org, rei...@chromium.org, s...@google.com, ay...@google.com

Explainer

Link to explainer and WICG thread.

Design doc/Spec

Not yet available. Will update this thread when ready. There is a comparable API on Android and an early prototype for Chrome in development.

Just to report back on this thread, per process, but here is the design doc that was left blank when I sent this out. 

Still early / drafty, but firm enough that it could use a round of early feedback / suggestions / recommendations / guidance.

[Sam Goto]

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, as well as renamed from SMS Receiver API to WebOTP API to reflect the intent, as well as have implementation well under way (example). 

   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

 

On Wed, Apr 17, 2019 at 5:22 PM Sam Goto <go...@chromium.org> wrote:

[Domenic Denicola]

From: Sam Goto <go...@chromium.org>

>   We cleaned up our https://github.com/samuelgoto/WebOTP/blob/master/README.md to reflect that as well as a http://samuelgoto.github.io/WebOTP, as well as renamed from SMS Receiver API to WebOTP API to reflect the intent, as well as have implementation well under way (https://chromium-review.googlesource.com/c/chromium/src/+/2018331). 

>
>   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.

Hey Sam,

This sounds like a great outcome, getting real-world feedback and balancing concerns to improve the API.

That said, do you think the spec you've written is sufficiently detailed for other engines to implement the API? It seems very bare to me, and not at the level that would meet the bar for an Intent to Ship. There we usually require something of sufficient detail that we could achieve interoperability, if other browsers decide to follow and implement as well.

I would suggest working on a full specification, preferably with review from others who have written specs, before going for an Intent to Ship.

[Sam Goto]

On Wed, Feb 12, 2020 at 7:20 AM Domenic Denicola <d...@domenic.me> wrote:

From: Sam Goto <go...@chromium.org>

>   We cleaned up our https://github.com/samuelgoto/WebOTP/blob/master/README.md to reflect that as well as a http://samuelgoto.github.io/WebOTP, as well as renamed from SMS Receiver API to WebOTP API to reflect the intent, as well as have implementation well under way (https://chromium-review.googlesource.com/c/chromium/src/+/2018331). 
>
>   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.

Hey Sam,

This sounds like a great outcome, getting real-world feedback and balancing concerns to improve the API.

That said, do you think the spec you've written is sufficiently detailed for other engines to implement the API? It seems very bare to me, and not at the level that would meet the bar for an Intent to Ship. There we usually require something of sufficient detail that we could achieve interoperability, if other browsers decide to follow and implement as well.

Oh, yeah, absolutely, I was putting that (and other things) into the bag of "once we wrap things up" :)

[Domenic Denicola]

From: Sam Goto <go...@chromium.org>

> Oh, yeah, absolutely, I was putting that (and other things) into the bag of "once we wrap things up" :)
 

Ah awesome, sorry for misinterpreting!

[Sam Goto]

No worries :) I'll start with you once I have something less embarrassing to share :)

Just to give everybody a sense of timeline, I'm thinking we'll be able to "wrap things up" somewhere around end of Q1 (e.g. finish up implementation, go through another round of feedback from partners, coordination with other browser vendors, WPT tests, etc).

[ayush.va...@quikr.com]

Hi Sam,

We were using the SMS OTP Retriever API in our website's login and signup flows, and saw increased versions.

I can see that the Origin Trial ended on 11th March, and since then the feature has stopped working.

Is there any way we can still use the feature?

[Sam Goto]

On Mon, Mar 16, 2020 at 9:39 AM ayush.vashishtha via blink-dev <blin...@chromium.org> wrote:

Hi Sam,

We were using the SMS OTP Retriever API in our website's login and signup flows, and saw increased versions.

I can see that the Origin Trial ended on 11th March, and since then the feature has stopped working.

Is there any way we can still use the feature?

Hi Ayush,

   Great to hear that the SMS OTP Retriever API was constructive to your business. The goal of the origin trial was largely accomplished and we don't have much experimentation further to make. We are working towards launching the API as our next step which would allow you to use it going forward. Unfortunately, that means that there will be a gap/time where the API won't be available to your users for a few milestones. I'm sorry for the disruption, but it is part of the origin trial / launch process.

 

   I'll keep you posted as this goes along.

   I'm CC-ing Eiji here in this thread, which can help you through this process too.

   Sam

On Wednesday, February 12, 2020 at 11:40:22 PM UTC+5:30, Sam Goto wrote:

On Wed, Feb 12, 2020 at 10:06 AM Domenic Denicola <d...@domenic.me> wrote:

From: Sam Goto <go...@chromium.org>

> Oh, yeah, absolutely, I was putting that (and other things) into the bag of "once we wrap things up" :)
 
Ah awesome, sorry for misinterpreting!

No worries :) I'll start with you once I have something less embarrassing to share :)

Just to give everybody a sense of timeline, I'm thinking we'll be able to "wrap things up" somewhere around end of Q1 (e.g. finish up implementation, go through another round of feedback from partners, coordination with other browser vendors, WPT tests, etc).

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/408ce011-e66d-4bfa-b279-d40e90d3109e%40chromium.org.