Intent to Ship: WebOTP API: cross-device support

[Yi Gu]

Contact emails

yi...@chromium.org, go...@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

Intent to Ship: WebOTP API

Intent to Ship: WebOTP API: cross-origin iframe support

 

Blink component

Blink>WebOTP

Search tags

webotp, web 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]

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]

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]

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]

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]

Excellent, this is exactly what I was asking for. Emulating having received an OTP code through DevTools sounds great. Thanks!

[一丝]

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.

[Yi Gu]

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]

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

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

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2f995091-2a32-f40a-79ac-e70aa52f206f%40gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8qDhb-dypT0t52cBWjgNX2v%3DgCMw1X6xF-xAy0CKLgVA%40mail.gmail.com.

[Yi Gu]

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.