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

[Yi Gu]

Contact emails

yi...@chromium.org, go...@chromium.org

Explainer

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

Specification

Origin-bound one-time codes delivered via SMS

WebOTP

API spec

Yes

Design docs

https://docs.google.com/document/d/1dR-5-1O3SqAbQCRj_cBaQ7nQD5YlWzExcusmPcO2Xqs/edit?usp=sharing

Summary

The WebOTP API (shipped in M84: launch bug, I2S) gives developers the ability to programmatically read OTP from SMSes that are delivered to the user’s phone that are addressed to their origin to reduce user friction.

In the initial launch of the API, we deliberately ignored the cross-origin iframe support. Post launch, to address such feature requests from partners (Shopify etc.) and also improve interoperability, we are proposing to support WebOTP in cross-origin iframes with

- an updated string on the permission dialog that includes the information of both the top frame and the cross-origin iframe (user facing)

- a new permissions policy that allows the top frame to enable the feature (developer facing)

- an updated SMS format that includes the domain of the cross-origin iframe (developer facing)

Blink component

Blink>WebOTP

Search tags

webotp, web otp

TAG

Reviewed: https://github.com/w3ctag/design-reviews/issues/604

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

While Safari does not implement the imperative WebOTP API directly (they use a declarative API), we share the same SMS format. Safari raised the initial request of using sms-one-time-code in nested frames to support third party or a separate service run by the same party. Cross-origin iframe support was included in their launch of the declarative API. However the sms format related spec was not landed and we believe that there was room for improvement regarding how iframe is specified in the SMS. Therefore we proposed / drove consensus on a solution that addresses our concerns and also preserves backwards compatibility for Safari.

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

WebKit: Positive (https://github.com/WICG/sms-one-time-codes/issues/4)

Web developers: Lacking of cross-origin frame support blocks some partners (especially payment related sites) from adopting the API. We have received requests from them from different channels. 

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

Yes.

Tracking bug

https://crbug.com/1136506

Launch bug

https://crbug.com/1169375

Sample links

https://output.jsbin.com/gilusuq/quiet

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Tuesday, March 23, 2021 at 8:10:46 PM UTC+1 Yi Gu wrote:

Contact emails

yi...@chromium.org, goto@chromium.org

Explainer

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

Specification

Origin-bound one-time codes delivered via SMS

WebOTP

API spec

Yes

Design docs

https://docs.google.com/document/d/1dR-5-1O3SqAbQCRj_cBaQ7nQD5YlWzExcusmPcO2Xqs/edit?usp=sharing

Summary

The WebOTP API (shipped in M84: launch bug, I2S) gives developers the ability to programmatically read OTP from SMSes that are delivered to the user’s phone that are addressed to their origin to reduce user friction.

In the initial launch of the API, we deliberately ignored the cross-origin iframe support. Post launch, to address such feature requests from partners (Shopify etc.) and also improve interoperability, we are proposing to support WebOTP in cross-origin iframes with

- an updated string on the permission dialog that includes the information of both the top frame and the cross-origin iframe (user facing)

- a new permissions policy that allows the top frame to enable the feature (developer facing)

Is the permission on or off by-default?

[Yi Gu]

It's off by default. i.e. top frame needs to explicitly specify the "otp-credentials" policy via HTTP Header or iframe allow attribute.

On Thu, Mar 25, 2021 at 4:33 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tuesday, March 23, 2021 at 8:10:46 PM UTC+1 Yi Gu wrote:

Contact emails

yi...@chromium.org, go...@chromium.org

[Daniel Bratell]

I'd primarily suggest this as a part of a security review, but I note that the idea is to try to explain the concept of a nested web page to a user. My impression is that that particular ship has sailed. It is too complicated and technical to rely on any user making a proper informed decision.

Have you run this past the security people already? And how not-good would it be if people willy nilly accepts this permission?

/Daniel

--
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/CACh2XCPOJBxC_Tk1LK5_27kN1VBJH_EcxGhfjYHGa-4hJpL%3DHQ%40mail.gmail.com.

[Chris Harrelson]

Hi,

Please email webkit-dev per bit.ly/blink-signals. 

Web developers: Lacking of cross-origin frame support blocks some partners (especially payment related sites) from adopting the API. We have received requests from them from different channels. 

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

Yes.

Tracking bug

https://crbug.com/1136506

Launch bug

https://crbug.com/1169375

Sample links

https://output.jsbin.com/gilusuq/quiet

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

--
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/CACh2XCPOJBxC_Tk1LK5_27kN1VBJH_EcxGhfjYHGa-4hJpL%3DHQ%40mail.gmail.com.

--
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/62914319-dbee-d380-1bd7-6fc7b20947e6%40gmail.com.

[Yi Gu]

Thanks Daniel for the question.

The top level frame has no access to the phone number or the OTP via the API. We did go through security review. Given the clear boundary between the two frames as well as the opt-in permissions policy model, the proposed changes in this I2S are approved by security.

In addition, we spent lots of time working with Permissions and UX team to come up with an appropriate string to inform users regarding which origin they are interacting with and the implications of that. Meanwhile we are exploring possible improvements to see whether it makes sense to show only the iframe origin to reduce confusion.

Users can always choose to deny if they don’t feel comfortable with the formulation or the iframe itself. Like in the general non-iframe WebOTP, users can decline the automated flow and manually enter the OTP from messages app.

[Yi Gu]

Please email webkit-dev per bit.ly/blink-signals. 

Done: https://lists.webkit.org/pipermail/webkit-dev/2021-March/031759.html

[Alex Russell]

Looks like no response there in a few weeks. I'm recused on this one, but thing it should be unblocked for 91.

[Yoav Weiss]

LGTM1

This seems like a reasonable addition to WebOTP - enabling 3P iframes to get extra confidence that the (logged in) user is indeed who they think they are.

Regarding the notion of explaining nested iframes to users - that's indeed tricky ground, but I'm confident y'all can make it work in this limited context.

IMO in this context, 3Ps won't be able to "spam" users (as they don't have their phone numbers to SMS them, hopefully), and sites are not likely to enable that permission other for legitimate reasons (e.g. payment 3Ps)

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bfa13b62-bffe-45ae-bf67-423b2824407fn%40chromium.org.

[Mike West]

This delta to the existing WebOTP API LGTM3.

That said, I believe there are still some ongoing internal conversations around the prompt's strings with the permissions team and UI folks. From a platform perspective, this seems fine to ship so long as you have agreement on a comprehensible prompt.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-7%3DTo-Ft2HGYd2WBG2bCddiKiOOihvqFQq6rsePe%2B%3Dqw%40mail.gmail.com.

[Yi Gu]

Thank you all!

Permissions, T&S and UX teams have been very supportive with possible improvements to this API and we will continue working on it.