Intent to Prototype: 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

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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

Will be debuggable by usual devtools tooling for JavaScript.

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

N/A (Not yet implemented)

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175677674586112

[Reilly Grant]

Is this proposal compatible with the deprecation of third-party cookies and partitioned storage? Since credentials are origin-bound, what credentials are available to a frame on origin A embedded under origin B?

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
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/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com.

[Stephen Mcgruer]

To clarify - WebAuthn credentials are already available for reading in a cross-origin iframe, as long the "publickey-credentials-get" permission policy is set. So the question probably stands for WebAuthn in general, rather than just this change to allow creation as well?

I'm cc-ing agl@ as the expert here, but my understanding is that WebAuthn credentials (aka passkeys) are unpartitioned, but require sufficient user interaction/consent that they are considered compatible with the deprecation of third-party cookies and unpartitioned storage. A frame on origin A embedded under origin B can request (via credentials.get()) its unpartitioned passkey, but the user will at minimum* see and have to confirm a UI that indicates that they are identifying themselves to origin A, and will usually have to interact with an authenticator flow (e.g., TouchID, or a password prompt) as well.

* At minimum because WebAuthn always requires something called 'user presence' which might just have a UI where the user can click to confirm, but almost always is used with the stronger 'user verification' which does an authentication flow.

[Rick Byers]

Note FedCM, PaymentRequest and Storage access API effectively all follow this policy too. 3PCD doesn't block cross-origin information sharing, it just requires user consent (and hopefully understanding) for doing so. These patterns all seem strictly stronger in terms of transparency and control than eg. the widespread behavior around popup windows and redirects which are the main way federated sign-in is still done on the web without 3PCs. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae12e1MvWouhD5qZRCQsRaG_h_bXjC%2B0yeUfB4uHX4xww%40mail.gmail.com.

[Reilly Grant]

That all makes sense to me. I was just hoping to find it explained somewhere.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome