related origins enables sharing across relying parties

[npdoty]

Although Credential IDs and credential public keys are necessarily shared with the WebAuthn Relying Party to enable strong authentication, they are designed to be minimally identifying and not shared between Relying Parties.

But they are designed to specifically be shared with any related origin, which could include hundreds of other relying parties if they are collaborating.

Related origins don't seem to be mentioned in any privacy considerations. How could this feature be abused? Can origin lists be updated over time? Will the origins actually be related companies, or just colluding? Will the user know that if they use their passkey on this totally differently named and branded site that it will provide hard proof that it's the same user on what seems to be a totally different site? Will silent access be allow for related origins if a user asked to stay signed in? Enabling cryptographically-verified identity-sharing between many origins is a substantial privacy risk, with the potential for unwanted cross-site recognition.

How does this feature relate to every other web proposal for related websites? For example, it seems to have fewer restrictions, substantive protections than the first-party sets proposals. Should websites that use one related-origins feature use the same list of origins as they do in the other related-origins features?

We were also confused about the exact implications of registrable origin labels (vs eTLD+1, or other known concepts).

Setting a minimum of 5 and no maximum is confusing. Why 5? Leaving it ambiguous doesn't seem to help interoperability. Having a minimum but no maximum doesn't seem to help privacy. (It seemed like implementations were converging on 5 as just both floor and ceiling?)

This item was raised and discussed by the Privacy WG as part of this privacy review:
w3cping/privacy-request#162

[timcappalli]

Responses from @timcappalli @kreichgauer @nsatragno @MasterKale

---

How could this feature be abused?

The main concern here would be user identification across (seemingly) unrelated sites. As with cross-origin iframes, this is heavily mitigated by WebAuthn being mediated with browser UI.

Can origin lists be updated over time?

Yes. Note that since requests to the lists aren't credentialed and are made by the WebAuthn client itself, it's not practical for e.g. a tracking network to customize the list for a given client.

Will the origins actually be related companies, or just colluding?

Nothing about Related Origins enforces a relationship between the entities that are specified in .well-known.

Will silent access be allowed for related origins if a user asked to stay signed in?

In general, WebAuthn does not allow silent usage of credentials. User presence is required.

How does this feature relate to every other web proposal for related websites?

Given the very specific and single purpose usage in the context of WebAuthn, we felt it was not appropriate to share sets with other use cases.

Should websites that use one related-origins feature use the same list of origins as they do in the other related-origins features?

Websites should only use related origins for very specific use cases, namely hosting sign in pages in different domains for the same site. E.g. site.com and site.ca are the same site, but have different domains.

We were also confused about the exact implications of registrable origin labels (vs eTLD+1, or other known concepts).

Not all entities use the same registerable domain across eTLDs. Acquisitions, for example, may see a singular corporate entity wanting to support auth with a single passkey across completely different domains. The use of registerable origin labels in Related Origins offers flexibility for use cases like this.

Why 5? (referring to the minimum of 5 origins) Having a minimum but no maximum doesn't seem to help privacy. (Implied question: Why is there no maximum?)

We should probably limit it to exactly five. Five was chosen to be small enough so that clustering large amounts of unrelated sites in the related origins file wasn’t possible.

Will the user know that if they use their passkey on this totally differently named and branded site that it will provide hard proof that it's the same user on what seems to be a totally different site?

It’s unclear what the user attack scenario is here when the five-label limit reduces the number of domains that colluding entities can orchestrate tracking across. Given the other mitigations detailed above, it is believed that attackers are less likely to perceive Related Origins as a useful cross-domain tracking mechanism.

/cc @simoneonofri @nadalin