Chrome extensions will be able to claim WebAuthn site RP IDs

Dear web people,

For a while now Chrome extensions pages have been able to claim a unique Web
Authentication <https://w3c.github.io/webauthn> relying party identifier
matching their origin, taking the form of chrome-extension://id.

Starting on Chrome M122 (stable release scheduled around Feb 20th, but you
can try it now <https://www.google.com/intl/en_ca/chrome/canary/>),
extension pages will also be able to claim all relying party identifiers
that origins they have host permissions for can claim. This will follow the
same rules as usual, with permissions over a certain origin allowing
claiming parent domains of that origin up to and including eTLD+1
<https://w3c.github.io/webauthn/#relying-party-identifier>.

There are two exceptions:

   - Extensions will not be allowed to claim an RP ID that is unique to
   another extension, even if they have host permissions over them.
   - Extensions will not be able to claim RP IDs believed to be eTLDs. In
   practice, these are PSL <https://publicsuffix.org/> entries and
   single-component origins, even if they have host permissions over them.

Here are some examples for an extension with id `id1`:

Host Pattern                      RP ID                     Allowed?
<no host permissions>             chrome-extension://id1    Yes
http://localhost/                 localhost                 Yes
https://*.com/                    example.com               Yes
https://example.com/              example.com               Yes
https://*.example.com/            subdomain.example.com     Yes
https://subdomain.example.com/    example.com               Yes
https://*.subdomain.example.com/  example.com               Yes
<all_urls>                        chrome-extension://id2    No
http://example.com/               example.com               No
https://example.com/              subdomain.example.com     No
https://example.com/              com                       No
<all_urls>                        com                       No
https://com/                      com                       No
https://maybetld/                 maybetld                  No

This should not fundamentally change the security and privacy properties of
WebAuthn, as extensions with host permissions can already script pages
running on those hosts and thus claim the same relying party identifiers.
Additionally, the origin passed to the authenticator to be signed over on
the client data json will match the extension origin, and not the site.

We hope this change will make crafting sign-in and sign-up experiences
using passkeys on extension pages a lot easier, leveraging the existing
permission model as an alternative to the asset-link model that was
proposed earlier <https://github.com/w3c/webextensions/issues/238>.

Happy hacking,
-- 
Nina Satragno
she/they