w3c
privacy implications of cross-origin iframe
Is this intended to support signing in to one relying party when that party is embedded on a different site? Are users supposed to distinguish which party they are signing into when they do this? That seems extremely ripe for confusion. It could be useful for tracking users across sites if the user is trying to sign in to Site A without realizing that what they are doing is providing their cross-origin identifier for Tracker B.
In what way are passkeys partitioned when accessed by a cross-origin embedded iframe?
(This issue includes several questions because the reviewer (that @npdoty guy) wasn't entirely confident in reading the spec on the exact implications, and the rest of the Privacy WG thought it was potentially very concerning, but couldn't be certain based on the reviewer's uncertainty.)
This item was raised and discussed by the Privacy WG as part of this privacy review: https://github.com/w3cping/privacy-request/issues/162
Is this intended to support signing in to one relying party when that party is embedded on a different site?
Yes, the primary use case is a payment service provider embedded in a merchant checkout flow.
In what way are passkeys partitioned when accessed by a cross-origin embedded iframe?
There is no concept of partitioning in WebAuthn, as there is nothing to partition.
Are users supposed to distinguish which party they are signing into when they do this?
Both origins are provided to the user. The omnibox shows the top frame, and the WebAuthn client UI shows either the calling origin (the iframe's origin) or the RP ID.
My understanding is that it isn't partitioned, that the user is provider a persistent identifier to embedded origin B (the same key that they use when interacting with Site B in a non-embedded context). So the user may think they are signing into Site A but actually be providing a cross-origin connection to their identity on Site B. Based on discussion with the Working Group, it sounded like this was the intended behavior, and that it was up to the user agent to clearly communicate what's happening to the user, and up to the user to interpret the UI, notice that the dialog UI shows a different origin from the URL bar and make sure they want to connect their activity on Site A to their activity on Site B.
This seems dangerous to users and likely to be confused. I'm not sure if user agents realize what they're signing up to communicate to users. It seemed like in discussion with the Working Group that maybe this could be documented in the spec, either now or in the future, to document the risk and clarify the responsibility.