Re: [webauthn] related origins enables sharing across relying parties (#2319)

Responses from @timcappalli @kreichgauer @nsatragno @MasterKale 
<hr>

> 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 

-- 
GitHub Notification of comment by timcappalli
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2319#issuecomment-3222127520 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 26 August 2025 00:21:02 UTC