[webauthn] Add a note about `appid` extension not compatible with related origin requests (#2312)

jaiminbhatt7 has just created a new issue for https://github.com/w3c/webauthn:

== Add a note about `appid` extension not compatible with related origin requests ==
For RPs that previously supported U2F API and later migrated to WebAuthn, it is expected that their customers can have a combination of credentials: old credentials created using U2F APIs and new credentials created using WebAuthn. 

Now for business reasons, if the RP needs to support new domains through related origin then there are some compatibility issues here that aren't clearly called out in spec (not 100% sure if the spec should call this out). As an example, credentials registered on `product.example.com` using U2F are not allowed on `product.com` as per AppID extension but WebAuthn related origin allows this. We noticed that browsers are correctly throwing `SecurityError` in such scenarios but it is very difficult troubleshooting this. Upon further investigation, we found that this is expected based on https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html#determining-if-a-caller-s-facetid-is-authorized-for-an-appid.

> All Web Origins listed MUST have host names under the scope of the same least-specific private label in the DNS, using the following algorithm:
Obtain the list of public DNS suffixes from https://publicsuffix.org/list/effective_tld_names.dat (the client MAY cache such data), or equivalent functionality as available on the platform.
Extract the host portion of the original AppID URL, before following any redirects.
The least-specific private label is the portion of the host portion of the AppID URL that matches a public suffix plus one additional label to the left.
For each Web Origin in the TrustedFacets list, the calculation of the least-specific private label in the DNS MUST be a case-insensitive match of that of the AppID URL itself. Entries that do not match MUST be discarded.

Starting this issue to discuss how to better handle this scenario. I'd like to suggest adding note about this in the spec and having browsers return more detailed error message 



Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2312 using your GitHub account


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

Received on Thursday, 10 July 2025 22:05:45 UTC