-
Notifications
You must be signed in to change notification settings - Fork 220
Description
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