Intent to Ship: WebOTP API: cross-device support

153 views
Skip to first unread message

Yi Gu

unread,
Jun 18, 2021, 12:12:06 PM6/18/21
to blink-dev

Contact emails

yi...@chromium.orggo...@chromium.org

Explainer

https://github.com/WICG/web-otp/blob/master/explainer.md

Specification

https://wicg.github.io/web-otp/

API spec

Yes

Design docs

https://docs.google.com/document/d/1SlIaRlH0WEvvLMtQJZMuwZbH5bRs6SCPlxXwwnJQHMU/edit?

Summary

The WebOTP API reduces user journey friction during phone number verification. Currently it's only available on Android.


We plan to bring this feature to desktop Chrome users. Note that:

1. No API or specification change in this project.

2. The cross-device support requires Chrome Sharing which is based on Chrome Sync. i.e. it's only available for Chrome users who have signed in with their Google credentials.

3. Users can always memorize the code and submit it manually as they do today.


Related I2S

 

Blink component

Blink>WebOTP

Search tags

webotpweb otp

TAG review

API: https://github.com/w3ctag/design-reviews/issues/391
Cross-origin support: https://github.com/w3ctag/design-reviews/issues/604

TAG review status

Issues addressed

Risks



Interoperability and Compatibility


Edge: No signal

Gecko: Negative signals around the premise (using SMS), no clear signal regarding API

WebKit: Positive Signal regarding SMS convention and Neutral Signal regarding imperative API. No signal regarding using this API in cross-origin frames. Note that Mac users can already do cross-device phone number verification if they have turned on iMessage auto-sync.

Web developers: Positive for using this API

Activation

To use this API on desktop, developers just need to do the same as they use it on mobile.


Security

https://docs.google.com/document/d/1SlIaRlH0WEvvLMtQJZMuwZbH5bRs6SCPlxXwwnJQHMU/edit#heading=h.wmugkl634lye



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

Yes [1, 2]

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1015645

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1183062

Sample links

https://web-otp-demo.glitch.me/

Link to entry on the Chrome Platform Status

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

Mike West

unread,
Jun 21, 2021, 5:26:34 AM6/21/21
to Yi Gu, blink-dev
From a web platform perspective, the mechanics of transferring an OTP token from one device to another is not web-exposed, but a property of the user agent. I think the only visible change here is an extension of the WebOTP API's exposure from mobile platforms to desktop as well. That sounds pretty reasonable to me, but would like to better understand some of the details:

Am I correct in assuming that that exposure happens for all users, not just for users who have chosen to enable Sync in Chrome? Presumably it will also be exposed for Chromium embedders that don't (yet) support any kind of device-to-device transfer? What behavior will developers see in those cases? Will the promise reject after some timeout? Or just hang forever?

Thanks!

-mike


--
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/CACh2XCP8zM5VXP7roAcxFBKWZh5Ns2cH7rpwj%3DAi-G58WVtTHg%40mail.gmail.com.

Mathias Bynens

unread,
Jun 21, 2021, 7:42:02 AM6/21/21
to Yi Gu, blink-dev
The Intent* email template includes a “Debuggability” section, which is missing in this case. How should web developers be able to debug this new functionality through DevTools? See https://goo.gle/devtools-checklist for context.

On Fri, Jun 18, 2021 at 6:12 PM 'Yi Gu' via blink-dev <blin...@chromium.org> wrote:
--

Yi Gu

unread,
Jun 21, 2021, 8:00:56 AM6/21/21
to Mike West, blink-dev
Hi Mike,
Thanks for the questions!

- Am I correct in assuming that that exposure happens for all users, not just for users who have chosen to enable Sync in Chrome?
Right. Although users don't need to turn on Sync (only sign-in is required).

- Presumably it will also be exposed for Chromium embedders
Yes. This API will be exposed to clients that do not support this feature including non-Chrome browsers and  Chrome browsers without a signed-in account.

- What behavior will developers see in those cases? Will the promise be rejected after some timeout?
Yes. The promise will be rejected after some 4 mins which is consistent with the behavior on Android. Given that this feature has a natural fallback - users can always memorize the code and enter it on desktop manually like they do today, calling the API without a resolved promise won't affect the verification flow.

Yi Gu

unread,
Jun 21, 2021, 8:07:49 AM6/21/21
to Mathias Bynens, blink-dev
Hi Mathias,

Unfortunately some parts of this API cannot be tested through DevTools because it requires receiving SMS on the phone. We are requesting to emulate such behavior in DevTools (tracked here).
p.s. This is not desktop specific. We need the same functionality on Android WebOTP as well.

Yi

Mathias Bynens

unread,
Jun 22, 2021, 2:47:20 AM6/22/21
to Yi Gu, blink-dev
Excellent, this is exactly what I was asking for. Emulating having received an OTP code through DevTools sounds great. Thanks!

一丝

unread,
Jun 22, 2021, 8:38:42 AM6/22/21
to blink-dev, Mathias Bynens, blink-dev, Yi Gu
If WebOTP can directly add the copy verification code feature in the notification message, I think it will be more friendly. In Huawei mobile phones, a "Copy Verification Code"(复制验证码) button will be added directly to the SMS notification.

Digression: Does Chrome have plans to implement autocomplete="one-time-code"? I think it will be simpler and more friendly for developers.
120502E3-9923-4F6E-8EF1-5154C8978956.png

Yi Gu

unread,
Jun 22, 2021, 11:58:34 AM6/22/21
to 一丝, blink-dev, Mathias Bynens
Hi 一丝,

--- If WebOTP can directly add the copy verification code feature in the notification message, I think it will be more friendly.
I suppose different OEMs use different Messages and it's hard for Chromium to integrate this API with such non-browser components.
In addition, cross-device WebOTP is for desktop verification. i.e. the code is supposed to be submitted on the desktop. Copying the OTP doesn't seem to help users unless they are able to sync the clipboard to the desktop.

--- Does Chrome have plans to implement autocomplete="one-time-code"? 
We have been suggesting using `autocomplete="one-time-code"` when using WebOTP. Meanwhile we are investigating the tradeoff of using the declarative API. One major concern is that it's gated by users focusing on the input field. e.g. the OTP won't be suggested until a user selects the input field and starts to type. This may be too late to assist users to reduce friction because it's likely that they have already copied / memorized the code by then.

Daniel Bratell

unread,
Jun 24, 2021, 3:46:32 PM6/24/21
to Yi Gu, 一丝, blink-dev, Mathias Bynens

LGTM1

I like that this API becomes more cross platform, though for many vendors it will be hard to implement in a meaningful way. In a future I would like to see this functionality implemented in a way that disconnects the feature from the Chrome browser, making it more useful and more reliable.

Making the implementation less dependent on the browser might require platform support so I do not expect such a change to happen soon, but it would be great if you could communicate such a request to relevant platform people.

/Daniel

Chris Harrelson

unread,
Jun 24, 2021, 3:47:39 PM6/24/21
to Daniel Bratell, Yi Gu, 一丝, blink-dev, Mathias Bynens

Yoav Weiss

unread,
Jun 25, 2021, 2:57:59 AM6/25/21
to Chris Harrelson, Daniel Bratell, Yi Gu, 一丝, blink-dev, Mathias Bynens

Yi Gu

unread,
Jun 25, 2021, 8:33:14 AM6/25/21
to Yoav Weiss, Chris Harrelson, Daniel Bratell, Yi Gu, 一丝, blink-dev, Mathias Bynens
Thank you all :)

-- In the future I would like to see this functionality implemented in a way that disconnects the feature from the Chrome browser, making it more useful and more reliable
Absolutely. We'll continue exploring new possibilities to extend this feature.
Reply all
Reply to author
Forward
0 new messages