Intent to Ship: WebOTP API

[Sam Goto]

Contact emails

go...@chromium.org, s...@chromium.org 

Explainer

Link to Explainer

Spec

 Link to Spec.

Tag Review

Link to a Tag Review.

Summary

Websites rely on phone number verification as a critical step of sign-in, sign-up and payment flows. In user acquisition funnels, every improvement in conversion rates meaningfully impacts the bottom line of companies (e.g. return on investment of ads). 

This API enables web sites to verify phone numbers programmatically, via receiving one time passwords (OTPs) through SMS to increase conversion rates by decreasing user friction (copy/paste).

Through its experimentation, we have observed a 10-15% uplift of conversion rates for partners with an API that clearly fits the existing deployment. From that experiment, we have observed clear signs of demand coming from web developers of all sorts: large and small, from emerging markets or otherwise.

It is clear to us the browser ecosystem (e.g. Safari’s one-time-code) is sensitive to the friction involved in verifying phone numbers for users and the criticality in reducing it to increase conversion rates and support acquisition funnels, so we think that there is a path for plausible interoperability.

Link to Intent To Prototype in blink-dev discussion

Link to Intent To Experiment and Origin Trial Developer Feedback summary

Is this feature supported on all six Blink platforms?

Our current implementation intercepts text messages received by the user's Android device. The API was designed to admit a desktop implementation, which would rely on synchronizing messages received by the user's phone(s) (early exploration here). We'd prefer to make this API available now on Android, given the level of complexity involved in making it work across devices and the demand from the ecosystem (e.g. there is a larger representation of mobile users from emerging markets).

Demo

Link to Demo

Risks

Interoperability and Compatibility

The WebOTP API provides a combination of API and UX that aims at decreasing user friction. It is broken into two parts: (a) a client side JS API and (b) transport specific format, in this case, conventions around formatting SMS messages.

We see a great deal of convergence and desire to collaborate on (b) with Safari (example of collaborative work) and a neutral but open investigation on the specific formulation we picked for (a). From Mozilla, we got a variety of negative signals around the premise of SMS-based authentication itself and no clear signals about the proposed API itself.

• Edge: no signals

• Firefox: negative signals around the premise (using SMS), no clear signal regarding API

• Safari: Positive Signal regarding SMS convention and Neutral Signal regarding imperative API

• Web / Framework developers: positive signals

Ergonomics

We expect phone number acquisition, via <input autocomplete=”tel”> to be used in combination. We also expect <input> elements to be used in combination with the imperative API. Hence, extra thought was put into how that would go.

Activation

From a return on investment perspective, the API meaningfully increases conversion rates of acquisition funnels (10-15%) while having a very incremental deployment cost that can be retrofitted into existing OTP verification systems and flows directly. It also requires no user behavioral change. 

From this baseline, we expect that various UI frameworks will continue to develop specialized components that take advantage of the JS API, and server-side ecosystems that develop libraries for sending properly formatted SMS messages, lowering the cost further.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi

The tests were originally here but were accidentally recently ported out of the WPT directory into here during our switch to the credential management API. We are porting them back and they will show up here WPT.

Entry on the feature dashboard

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

[Mounir Lamouri]

Hi Sam,

Thanks for the thorough intent to ship. I was wondering if you could give some more information about the plausible path to interoperability. It seems that Safari and Chrome agreed on how these SMS should be formatted but not on the API, with Safari going with a declarative approach and Chrome with an imperative approach. How do you see this evolving? Is there any path where both browsers would use a similar API? Will Chrome potentially support both approaches? or are we asking websites to deal with this interop issue knowing that it's solvable given the common SMS format?

Thanks,

-- Mounir

--
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-yifq71_jxFZ7JD_vG_QHe7ODGTOsAnoRZrYE-efa6XNA%40mail.gmail.com.

[Sam Goto]

On Thu, Mar 26, 2020 at 1:55 PM Mounir Lamouri <mlam...@google.com> wrote:

Hi Sam,

Thanks for the thorough intent to ship. I was wondering if you could give some more information about the plausible path to interoperability. It seems that Safari and Chrome agreed on how these SMS should be formatted but not on the API, with Safari going with a declarative approach and Chrome with an imperative approach.

Good question.

 

How do you see this evolving? Is there any path where both browsers would use a similar API?

I believe so. Let me expand that below.

 

Will Chrome potentially support both approaches?

Possibly. 

We have some of the declarative approach already implemented, but needs more polishing. I can see a world where we support both approaches if we desire to.

Coming from the other end, we designed the imperative API in close collaboration with Apple (e.g. we initially designed it as a SMS Retriever API, navigator.sms.receive()) and moved to a OTP-specific API primarily based on the interest to interoperate. Their official stand on the imperative API is a neutral one, so it is hard to make a prediction, but I think it is also plausible that they may look into the imperative API further down the road (specifically, because I believe that the infobar UX will lead to higher conversion rates compared to autocomplete keyboard accessories). 

 

or are we asking websites to deal with this interop issue knowing that it's solvable given the common SMS format?

Interoperating on the SMS format is a huge step forward Safari has been very proactively about it (it materially improves their browser). In some ways, I think it also signals a desire to collaborate, but that's just my personal extrapolation based on the good experience I'm having working with them.

[sligh...@gmail.com]

I'm recused on this intent, but eventual layering was something we explicitly designed for here.

On the SMS format, there is a clear forward-compatible story which means that sites don't ever have to do more than they would to support our initial release if/when we remove site attribution tokens.

Regards

Thanks,

-- Mounir

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Yoav Weiss]

LGTM1

Thanks for the detailed explainer and through work pushing this.

This seems like a fundamental capability that will help users have safer logins than they do today, and the OT results indicate that it's a major improvement.

The common SMS format with Apple also provides hope for future interoperability.

On Tue, Mar 31, 2020 at 6:10 PM <sligh...@gmail.com> wrote:

I'm recused on this intent, but eventual layering was something we explicitly designed for here.

On the SMS format, there is a clear forward-compatible story which means that sites don't ever have to do more than they would to support our initial release if/when we remove site attribution tokens.

Regards

On Friday, March 27, 2020 at 7:22:21 AM UTC-7, Sam Goto wrote:

On Thu, Mar 26, 2020 at 1:55 PM Mounir Lamouri <mlam...@google.com> wrote:

Hi Sam,

Thanks for the thorough intent to ship. I was wondering if you could give some more information about the plausible path to interoperability. It seems that Safari and Chrome agreed on how these SMS should be formatted but not on the API, with Safari going with a declarative approach and Chrome with an imperative approach.

Good question.

 

How do you see this evolving? Is there any path where both browsers would use a similar API?

I believe so. Let me expand that below.

 

Will Chrome potentially support both approaches?

Possibly. 

 

We have some of the declarative approach already implemented, but needs more polishing. I can see a world where we support both approaches if we desire to.

Just to clarify - this isn't included in the current intent, right?

 

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/c3e04ecd-1b75-41ed-a95d-81dc6345440e%40chromium.org.

[Mike West]

LGTM2.

I'm happy to see the results of origin trials and feedback from developers and other vendors incorporated in this API. It's much more tightly focused than it was at its inception, and IMO has chosen the highest-value portion of the original proposition.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgi_y5jWybc8%3D_nT-TdJ7tN%3Drde4zv0U_jEqQLCT1ocZg%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dd4-TDbX7_zUx7ARRCNYZ-TKidiNbMq6UDa7f8VkSGceg%40mail.gmail.com.

[Sam Goto]

Thanks Yoav, Mike and Chris much appreciated for the thoughtful review!!! 

Thanks Alex for all the support and help through this process!

[Sam Goto]

On Tue, Mar 31, 2020 at 9:36 AM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM1

Thanks for the detailed explainer and through work pushing this.

This seems like a fundamental capability that will help users have safer logins than they do today, and the OT results indicate that it's a major improvement.

The common SMS format with Apple also provides hope for future interoperability.

On Tue, Mar 31, 2020 at 6:10 PM <sligh...@gmail.com> wrote:

I'm recused on this intent, but eventual layering was something we explicitly designed for here.

On the SMS format, there is a clear forward-compatible story which means that sites don't ever have to do more than they would to support our initial release if/when we remove site attribution tokens.

Regards

On Friday, March 27, 2020 at 7:22:21 AM UTC-7, Sam Goto wrote:

On Thu, Mar 26, 2020 at 1:55 PM Mounir Lamouri <mlam...@google.com> wrote:

Hi Sam,

Thanks for the thorough intent to ship. I was wondering if you could give some more information about the plausible path to interoperability. It seems that Safari and Chrome agreed on how these SMS should be formatted but not on the API, with Safari going with a declarative approach and Chrome with an imperative approach.

Good question.

 

How do you see this evolving? Is there any path where both browsers would use a similar API?

I believe so. Let me expand that below.

 

Will Chrome potentially support both approaches?

Possibly. 

 

We have some of the declarative approach already implemented, but needs more polishing. I can see a world where we support both approaches if we desire to.

Just to clarify - this isn't included in the current intent, right?

Right, not included.

[Sam Goto]

On Tue, Mar 31, 2020 at 9:10 AM <sligh...@gmail.com> wrote:

I'm recused on this intent, but eventual layering was something we explicitly designed for here.

On the SMS format, there is a clear forward-compatible story which means that sites don't ever have to do more than they would to support our initial release if/when we remove site attribution tokens.

On app hashes, with the guidance from Alex, we think we found a good middle ground that is a good balance between interoperability and UX. I realize that I forgot to report back to the larger group of where we converged, but here it goes:

https://github.com/WICG/WebOTP/issues/4#issuecomment-606730942 

 

TL;DR; no more app hashes, UX gets mediated by the OS instead.

[paulj...@chromium.org]

At the privacy review for this intent to ship we discussed that this API will encourage sites to start collecting phone numbers more, which are PII and universal join keys. The explainer is right that the point of collection is the right place to deal with this, but since this API is likely to encourage that collection we’d like to see a mitigation in place when this ships. One suggestion was to warn users about how phone numbers can be used to track them either before auto-fill provides their phone number to a form or when Chrome detects that the user is entering their phone number manually.

At risk of derailing this conversation, we are also curious if you thought of any ways to anonymize phone numbers in a way that preserves the security properties sites are looking for. But this seems like it could be a separate conversation.

[Sam Goto]

Ok, just to report back on this thread / comment.

On Fri, Apr 10, 2020 at 8:14 AM <paulj...@chromium.org> wrote:

At the privacy review for this intent to ship we discussed that this API will encourage sites to start collecting phone numbers more, which are PII and universal join keys. The explainer is right that the point of collection is the right place to deal with this, but since this API is likely to encourage that collection we’d like to see a mitigation in place when this ships. One suggestion was to warn users about how phone numbers can be used to track them either before auto-fill provides their phone number to a form or when Chrome detects that the user is entering their phone number manually.

We met with Paul/Brad and Alex Russel and reached a common understanding on how best to proceed here. The plan of record is to move forward with launching WebOTP in M84 (currently in the beta channel, coming to stable on the 16th of July) and quickly follow up with mitigations for phone number acquisition (two quick wins seems to be (a) collect UKM data on phone number autofill and (b) break down auto filling into multiple classes and require an extra user gesture to autofill telephone numbers).

No action required from this group, but just wanted to report back on the resolution here.