#604: Support WebOTP API and origin-bound one time code in cross-origin iframes

Visit on Github.

Opened Jan 28, 2021

HIQaH! QaH! TAG!

I'm requesting a TAG review of supporting WebOTP API and origin-bound one time code in cross-origin iframes.

The WebOTP API gives developers the ability to programmatically read one time codes from specially-formatted SMSes addressed to their origin to reduce user friction. The origin-bound one time code format is supported in Chrome and Safari. WebOTP API is supported in Chrome (TAG review, I2S).

In the initial launch of the API, we deliberately ignored the cross-origin iframe support. Post launch, we are trying to add such support to address feature requests from the web developer community (e.g. Shopify, iCloud) and improve interoperability.

Links for the general WebOTP API:

Links for cross-origin support:

  • Chrome implementation design doc
  • Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/WICG/sms-one-time-codes/issues/4
  • GitHub repo: url
  • Tests: wpt
  • Primary contacts (and their relationship to the specification):
    • @samuelgoto (editor, Google) @hober@(Editor, Apple), @yi-gu (Chrome implementation), @erynofwales (Safari implementation)
  • Organization(s)/project(s) driving the specification: Google, Apple

Further details:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: We like to ship this in Chrome M90
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):

You should also know that...

The implication of the proposed modification:

  • Developers need to send SMS that complies with the updated format for cross-origin usage

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2021-03-22

Minutes

Ken: they are shipping it... I think it's quite sensible. Safari implements the formart.

Dan: it's a delta but it changes a security boundary so ... should bear analysis...

Ken: it's im response to an issue filed by Tess.

Hadley: it's a big change. Also tess is listed as one of the contacts

Ken: one of the parts is SMS one time codes - extension to text message - they are looking at different options. Then WebOTP part is google only. The cross-origin part seems to be in the SMS format.

Hadley: the issue ken linked to also talks about cross-origins. Feels very first party sets-y to me.

Peter: this more about like double-keying cache or cookes - only works in this iframe when it's embedded in this origin.

Ken: the SMS contains a one time password and you only want to auto-deliver it to the proper recipient. They want to extend it so that the iframe can actually get it

Hadley: so the SMS would include both.

Peter: the browser would see it and auto-fill it.

Dan: if the sms contains both - double keyed - then it's a one time thing, the intetion is to streamline the OTP process when you're using SMS, so it seems to me that it's reasonable. Maybe mark as proposed closed?

Ken: it says it's been discussed with Safari as well- sounds good.

Hadley: me too. point of trust has to be the user agent - that feels like the right place to put the trust.

Dan: and it doesn't rely on an allowlist, which is good

Amy: related issue in wicg - commen about web pages don't use reseouce hints because [performance]...

Tess: but they have to do that work do generate the speculation rules...

Amy: i had questions on where the heuristics come from on deciding which links to preload. I think there is a privacy & security thing - might reval info - an origin could game the rules to reveal as much data as possible. Will leave a comment