- From: Mitar via GitHub <noreply@w3.org>
- Date: Wed, 09 Jul 2025 21:54:30 +0000
- To: public-webauthn@w3.org
mitar has just created a new issue for https://github.com/w3c/webauthn: == Add excludeUsers to prevent creation of new keys for known users == ## Use case The use case is simple. Having an app with one button "Sign-in with passkey". If user does not have an account with their device, one is created for them. If they do have, they are signed-in. No username, no user ID. User authenticated by having access to the device and being able to use it to do the authentication flow using WebAuthn. User account on the RP side is created after authenticating for the first time. This is the why residential/discoverable keys are great. The only issue currently is, you or user can override them by accident if RP does a "create" call when key is in fact present. The point is, why would username be required, if one has (discoverable) credential ID to determine the user account on the RP side. It works great. Except for the "override by accident" situation. ## Prior proposals * https://github.com/w3c/webauthn/issues/1749 - proposing `exists` to check if key exists * https://github.com/w3c/webauthn/issues/1568 - proposing `getOrCreate` to create a key only if does not already exist, otherwise returning the key ## Description I realized that all this could be achieved by having new `excludeUsers` member of `PublicKeyCredentialCreationOptions`, which would work similar to [`excludeCredentials`](https://www.w3.org/TR/webauthn/#dom-publickeycredentialcreationoptions-excludecredentials), only that instead of providing a list of credential IDs, one would provide list of user IDs for which credentials should not be created for. This would allow to do "create if not exists" semantics of the call for residential/discoverable keys if you use same user ID in both `excludeUsers` and `PublicKeyCredentialUserEntity`. I think this proposal is easier to implement than creating whole new API calls like `exists` and `getOrCreate` and do have better privacy implications. Implementations can reuse user flows from `excludeCredentials`, only they would be checking user IDs instead of credential IDs. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2309 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 July 2025 21:54:31 UTC