As mentioned in the WebAuthn Level 2 editor's draft at https://w3c.github.io/webauthn/#sctn-iframe-guidance, functionality to get credentials from a cross-origin iframe should be enabled if the iframe has the allow="publickey-credentials-get" attribute/value pair. Other browsers implementers have implemented this capability and my group sees a relevant use case for this in our product.
Agreed This is important for Paments and a number of other use-cases. It should be part of WebAuthn level 2 support.
WebKit on Cocoa platforms (and possibly other platforms too) block cookies for cross-site resources by default. All other state and storage is partitioned per first-party site. Whatever this support entails must not regress the privacy protections we already have in place. One way of resolving this is to tie it to the Storage Access API.
It would also be good to know if cross-origin but same-site would be sufficient since that is currently not a privacy boundary.
I'm curious about what allowing WebAuthn within a cross-origin i-frame might reveal. The dialog messages show what site is requesting the WebAuthn panel.
For example, if we implement this and site1.com embeds a google.com webauthn login page, the dialog would show "google.com" is asking to login.
I have seen some discussion of the embedded document obtaining information about the state of the embedding page via if certain calls pass/fail (therefore obtaining information about the i-frame's allow property) here: https://www.w3.org/TR/permissions-policy-1/#privacy-expose-policy . But we already implement several feature policies for camera, fullscreen, microphone, etc in https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/FeaturePolicy.cpp . I don't see anything anything special about WebAuthn where we might want to restrict the use further.
The Storage Access API is the only shipping way to request a cross-site identity and the prompt tells the user that their activity may be tracked by the requesting party if they grant access.
Cross-site WebAuthn would have to convey the same information since as soon as the user is identified, that identity can be shared with the first party website or stored by the third-party in first-party storage.
This is not the same as asking for permission to use device features such as camera. This is about user identity and linking of user identity across websites.
See WebKit's tracking prevention policy: https://webkit.org/tracking-prevention-policy/
I don't see the change being asked for here as providing any special way of of transmitting information between the embedded document and the embedder, even if it's cross-origin. All the current restrictions on communication between the embedding document and the embedded document would still apply.
The webauthn spec specifies that Web Authentication should be disabled in i-frames with a feature policy to allow it here: https://www.w3.org/TR/webauthn-2/#sctn-iframe-guidance
If a cross-origin embedded site needs to convey information after authentication, they would still need to use existing mechanisms to do it.
(In reply to email@example.com from comment #7)
> I don't see the change being asked for here as providing any special way of
> of transmitting information between the embedded document and the embedder,
> even if it's cross-origin. All the current restrictions on communication
> between the embedding document and the embedded document would still apply.
> The webauthn spec specifies that Web Authentication should be disabled in
> i-frames with a feature policy to allow it here:
> If a cross-origin embedded site needs to convey information after
> authentication, they would still need to use existing mechanisms to do it.
It's not about transmitting. It's about cross-site access to user IDs.
Today, in shipping WebKit, there is no automatic or invisible way to know a user identity in a cross-site iframe unless it has already been established. Such iframes have to call the Storage Access API on a user gesture in their iframe to request access to cookies. The Storage Access API prompt will inform the user that granting access means their activity may be tracked by the requesting party on this first-party website.
Once a cross-site iframe has access to a user identity it can use regular means to share that identity with the first-party, other third-parties, or with itself in the form of a third-party script running in the first-party context. The most common method is postMessage.
The privacy boundary is to make sure cross-site resources cannot identify the user without the user understanding the potential tracking risk involved. Allowing cross-site WebAuthn without informing the user of that risk would create a loophole in how we try to make sure users understand the privacy implications of their choices.