- From: Matthew Miller via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 20:14:24 +0000
- To: public-webauthn@w3.org
This is an interesting proposal for me because there are aspects of it that can make usernameless into a really slick new account creation flow. The current problem with usernameless is that `user.name` and `user.displayName` are required values when calling `.create()`, but if you don't know those because it's a new user you haven't collected that information from then you have to use a generated value for those and then, now, use `signalCurrentUserDetails()` afterwards to hopefully update the credential. Lots of opportunities for things to go wrong when orchestrating this flow. But if the value for `user.name` and `user.displayName` can be provided by the new user up front then that second step can be skipped entirely. This could hypothetically get new account creation down to two clicks and passkey account protections are taken care of. That said, based on the explainer there's a _lot_ of complexity that'd come with the proposed changes: > ### Handling existing accounts > Relying parties should try to avoid a situation where they call this API when the user already has an account, e.g. by using [immediate mediation](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation) on page load. There is unfortunately no way around the fact they will need to handle the case where a user already has an account, and the browser just created a passkey for them. > > Relying parties can detect this situation by comparing the user's identifier (email or phone number) with their user database on response. To remediate the situation, one option is to use the [signal API](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer) to delete the passkey that was just created with signalUnknownCredential, then prompt the user to sign in with their preferred method. Opting into this new behavior would also require opting into immediate mediation and use of signal APIs? That's a lot of implementation complexity for RPs and opportunities for abuse if an RP doesn't get every step implemented correctly. The proposed changes to `PublicKeyCredentialCreationOptions` also represent new combinations of WebAuthn options that RP's need to make sure they're calling correctly. What should `user.name` and `user.displayName` be set to when `requirePlatformBackupEligibleCredential` is present? What if `residentKey: "required"` isn't also set? These are new potential footguns that make the already complex WebAuthn into something even trickier to make sense of. Not that I don't think these are worth discussing... The one aspect I might push back on the most is the proposed addition of `requirePlatformBackupEligibleCredential`, in particular because it represents a stronger guarantee of the attributes of the credential: > Setting this field will give relying parties a guarantee that they can rely on just having the passkey for authentication. We as a WG have seen many attempts in the past to add stricter authenticator selection rules for the sake of RPs wanting to pre-select authenticators with desired capabilities (device-bound-only, synced-only, etc...) for more predictable browser-side UX. Over time we've designed things like Hints that are suggestions more than requirements because we've seemingly collectively agreed that WebAuthn should continue it's "bring your authenticator" user-centric model of operation. A new entry in `authenticatorSelection` with a guaranteed outcome like what's described in the explainer would require re-litigating those past discussions and likely come to the same outcome (i.e. it would get shot down.) To reiterate, I think this proposal is worth further discussion. I do support breaking this up into two proposals, though, so that the fate one of part of the proposal won't necessarily determine the fate of the other. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2336#issuecomment-3357973859 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 October 2025 20:14:25 UTC