Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

Contact emails

smcg...@chromium.org

Explainer

None

Specification

https://w3c.github.io/webauthn/#publickey-credentials-create-feature

Summary

This feature allows web developers to create WebAuthn[0] credentials (that is, "publickey" credentials, aka passkeys) in cross-origin iframes. Two conditions are required for this new ability: 1. The iframe has a publickey-credentials-create-feature permission policy. 2. The iframe has transient user activation. This will allow developers to create passkeys in embedded scenarios, such as after an identity step-up flow where the Relying Party is providing a federated identity experience. [0]: https://w3c.github.io/webauthn/

Blink component

Blink>WebAuthentication

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is only minor interoperability risk if other browsers do not adopt this change. In a browser that does not support credential creation inside a cross-origin iframe, attempting to call navigator.credentials.create results in an asynchronous-but-immediate error message indicating that creation cannot happen. This means that a developer can create a fallback flow of: 1. Have some button for the user, e.g. "register passkey", in the iframe 2. When the user clicks it, attempt to create a credential 3. If it fails due to an incompatible browser, instead use the click to open a pop-up window in which one *can* do the registration - a much poorer user flow but one that works.

Gecko: No signal

WebKit: No signal No formal signal, but note that folks from Apple were against the proposal when discussed in the WebAuthn WG

Web developers: Positive developer feedback on https://github.com/w3c/webauthn/issues/1656 (one example - https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). No known negative developer feedback

Other signals:

Security

To avoid malicious iframes from creating credentials (attempting to trick the user in some way), this feature requires both (a) a new permission policy set on the frame, and (b) a user gesture (so the user must click or interact with the iframe in some way).

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Existing devtools support suffices for this feature

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

Yes

In review: https://github.com/web-platform-tests/wpt/pull/43729 (Chrome Dev passes 5/5 added tests)

Flag name on chrome://flags

None

Finch feature name

WebAuthAllowCreateInCrossOriginFrame

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

Shipping on desktop	122
DevTrial on desktop	122

Shipping on Android	122
DevTrial on Android	122

Anticipated spec changes

Already landed in the spec, no remaining changes expected.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175677674586112

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Stephen Mcgruer]

API owners: It wasn't clear to me if I should still be formally requesting signals from WebKit and Gecko in the case of a change to an API (WebAuthn) where the change has been ratified + landed by the associated Working Group. The change is in some ways 'minor', but in other ways it is significant new behavior (allowing use of part of the API in cross-origin iframes, where it wasn't allowed before) and so perhaps requesting signals is warranted? Let me know please :D

[Mike Taylor]

I think erring on the side of requesting a signal here is a good idea. :)

--
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/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%40mail.gmail.com.

[Stephen Mcgruer]

Sounds great:

https://github.com/WebKit/standards-positions/issues/304

https://github.com/mozilla/standards-positions/issues/964

Will update if we get any reply :)

[Stephen McGruer]

Fyi; I've retargeted this launch to M123 since it seems clear it won't get the necessary Blink approvals in time for M122 (which has already branched).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

It would be great to get an official response from WebKit and Mozilla to make sure we understand their position, but I don't think we should block further on it. I understand why they might have concerns given their engine's preference for embeds being anonymous. In Chromium we've been consistent in working to preserve personalized / authenticated embeds (and so the rich composition of web pages) where we can ensure it doesn't conflict with our privacy goals around clear user transparency and control over sharing of information (fenced frames being the most obvious example). We know that avoiding popups and redirects helps reduce drop-off in any authentication or commerce flow, and combined with Stripe's public statement of support, I'm convinced this is a valuable capability. 

Everything else looks great to me, so LGTM1

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/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%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/b090cb3c-ac2a-4080-a583-6d77f60e5d79n%40chromium.org.

[Yoav Weiss (@Shopify)]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%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+unsubscribe@chromium.org.

[Mike Taylor]

LGTM3