- From: Nina Satragno <nso@google.com>
- Date: Wed, 13 Dec 2023 17:21:20 -0500
- To: public-webauthn@w3.org
- Cc: public-webextensions@w3.org, public-webauthn-adoption@w3.org
- Message-ID: <CAGisG_jDTzbxzV79Gvmy3Qo=XCYDGh3Z7=N-GoFCcPWmvqxRFQ@mail.gmail.com>
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
Received on Wednesday, 13 December 2023 22:21:40 UTC