webauthn
webauthn copied to clipboard
w3c
adds Related Origin Requests
Adds the Related Origin Requests feature (explainer)
- Updates "Create a New Credential"
- Updates "Use an Existing Credential"
- Adds a new subsection: "Using Web Authentication across related origins"
- Adds a new definition for "Origin Label"
- Updates "Validating the origin of a credential"
- Updates "enum ClientCapability"
Resolves #1372
Is there any considerations to "non https origins", like a browser extension?
Our use case may be niche, but I'll share it:
As a Bitwarden user, you can self-host your server. For example, i can host my vault and data on "vault.andersaberg.com", but still use the bitwarden clients (browser, ios, android, native desktop) to access my data. You simply configure your client to go to your self-hosted domain for the auth and api calls.
Would the bitwarden extension be able to use a passkey, bound to "vault.andersaberg.com", if there is a "vault.andersaberg.com/.well-known/webauthn"-file proclaiming "bitwarden.com", or a browser extension ID to be an associated domain? I'm guessing yes, if the extension has host permission on that domain (vault.andersaberg.com)?
I have the same question for mobile apps - but I don't think anyone here can respond to that.
Would the bitwarden extension be able to use a passkey, bound to "vault.andersaberg.com", if there is a "vault.andersaberg.com/.well-known/webauthn"-file proclaiming "bitwarden.com", or a browser extension ID to be an associated domain? I'm guessing yes, if the extension has host permission on that domain (vault.andersaberg.com)?
@abergs (and @nsatragno) can the extension dynamically change its identifier (locally) after install based on the vault configuration? (https://lists.w3.org/Archives/Public/public-webauthn/2023Dec/0078.html)
https://github.com/w3c/webauthn/pull/2040/commits/e4f24d9b3d1ec57f2dad79d6c210285699f4bda8 should address the issue where a new origin is added to the well-known that matches an existing label, but the max label count was already hit (e.g. adding an additional ccTLD origin).
Some code to prove out the updated algorithm: https://gist.github.com/timcappalli/58d3d345a4173effea63f2c5d31fbf3e
(On second thought, maybe the linked definition of SLD only accounts for a single top domain segment, not multiple ones like .co.uk. Whatever the appropriate term for this may be, what I mean is the "eTLD+1 - eTLD" segment described in the draft as "Split domain into labels and let label be the right-most one.". This is the interpretation of SLD used by the psl NPM package referenced in the example code.)
@emlun this was discussed on the last call. The preference was to put all the work on the client and keep the well-known simple for RPs.
Hello, I have some feedback regarding the minimum supported limit of five origins.
Amazon appears to have at least 17 TLDs that serve customers (rather than redirect customers to .com). Authentication occurs without redirecting to the .com origin. Should Amazon adopt related origins and somehow overcome the issue of prior passkey registrations on a localized TLD, they would be constrained by the five origin limit. Perhaps a limit of 20 would be more appropriate?
Here's the list I processed:
ae,ca,co.jp,co.uk,com,com.au,de,eg,es,fr,in,it,nl,pl,sa,se,sg
There may be more co.{cctld} and similar com.{cctld} that I missed.
I have no affiliation with Amazon. They just seemed to be an interesting use case for this specification change.
@LeviSchuck The label described in the algorithm (if I've followed it correctly through my own local testing) would resolve to amazon on all of their owned TLDs, which counts as a singular entry towards the limit. I assume it was designed specifically with this use-case in mind.
I'd love to see this confirmed (or refuted) by one of the authors, but my read was that you'll only run into the limit if you're authenticating across a lot of wildly different domains (such as how signing in to Google often sends you to youtube.com)
The algorithm is indeed focused more on the part after the TLD, a.k.a. the "label". So long as all 17 of those TLDs use amazon before them then the current algorithm defined in this PR will handle those just fine.
Thank you for replying @Firehed ! @MasterKale helped me understand what a label means outside of this thread.
I can think of no other case where
- Identity pools are shared across many origins, and
- A consistent authentication origin is not used for each identity pool.
The limit of 5 labels seems fine.
From the perspective of decentralized network user authentication, the /.well-known/webauthn file is like providing hackers with a complete target list.
Therefore, it is hoped that from the "PublicKeyCredentialCreationOptions" before creating credentials at registration, it can be defined whether origin verification is required. If it is not required, the browser should be informed that any domain can pass the verification.
The right to publicly disclose the origins list should be entrusted to the users who make use of it, and hopes that it will be given due attention.
Therefore, it is hoped that from the "PublicKeyCredentialCreationOptions" before creating credentials at registration, it can be defined whether origin verification is required. If it is not required, the browser should be informed that any domain can pass the verification.
No domain is required to populate that file. The existing RP ID validation rules still apply and, if satisfied, no .well-known request will be made.
