Bug 222240 - [WebAuthn] Using WebAuthn within cross-origin iframe elements
Summary: [WebAuthn] Using WebAuthn within cross-origin iframe elements
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-02-20 16:40 PST by Mathieu Perreault
Modified: 2021-10-28 11:58 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Perreault 2021-02-20 16:40:28 PST
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.
Comment 1 Radar WebKit Bug Importer 2021-02-27 16:41:13 PST
<rdar://problem/74830748>
Comment 2 login Llama 2021-03-03 10:15:29 PST
Agreed This is important for Paments and a number of other use-cases.  It should be part of WebAuthn level 2 support.
Comment 3 John Wilander 2021-10-28 09:23:20 PDT
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.
Comment 4 John Wilander 2021-10-28 09:24:12 PDT
It would also be good to know if cross-origin but same-site would be sufficient since that is currently not a privacy boundary.
Comment 5 j_pascoe@apple.com 2021-10-28 11:09:34 PDT
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.
Comment 6 John Wilander 2021-10-28 11:25:38 PDT
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/
Comment 7 j_pascoe@apple.com 2021-10-28 11:46:43 PDT
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.
Comment 8 John Wilander 2021-10-28 11:58:03 PDT
(In reply to j_pascoe@apple.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:
> 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.

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.