- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Feb 2025 17:24:14 +0000
- To: public-webauthn@w3.org
> [...] am I just fortunate that _those_ authenticators are offering this protection, whereas it's not required that they do so? Yes, sort of. Resident (discoverable) keys usually require UV implicitly - certainly when you invoke `get()` with an empty or unspecified `allowCredentials`, most authenticators require UV before revealing existence of a credential. CTAP2 security keys typically do not require UV when `get()` is invoked with non-empty `allowCredentials`, unless the credential was created with the `credProtect` extension set to `credentialProtectionPolicy: "userVerificationRequired"`. But platform authenticators often require UV even if not requested by the RP. > Are you saying either of the following? I'm saying that at least for external security keys, the PIN and biometric configuration applies to the security key as a whole rather than to individual credentials. So you could register two of your fingerprints, or two people could know the PIN and could each register one or two fingerprints on the same security key. All of those count as valid "user verification", and the configuration may change over time, so `UV: 1` in the registration might mean that Alice entered her PIN, `UV: 1` in one assertion might mean Alice presented her fingerprint, `UV: 1` in a second assertion might mean Bob entered the PIN because he also knows it, and `UV: 1` in a third assertion might mean Alice (or Bob) presented a different fingerprint which was registered on the security key after the second assertion (using some security key management tool like `chrome://settings/securityKeys`, not via the WebAuthn API). So yes: "the authenticator might let me **UV** with the other different credential", because UV on security keys is not per-credential, it's a global configuration for the security key as a whole. Other authenticators (e.g., smartphones) might handle the credential/UV life cycle differently, but the above behaviour is allowed by the spec. > Moreover, if I have two separate credentials (thumb and pointer) set up, whichever one I UV with, _THAT_ dictates what the response will be, and the credential ID that comes back with it, and the userHandle in it. Huh, I wasn't aware that some authenticators register the biometric feature with an individual credential rather than the authenticator as a whole. > If I try to do a create() with the same user.id as I had previously set up, to like "add" a biometric factor to it, it ends up "replacing" the biometric factor in that same credential. Like, it might have been my thumb first, and now it's my pointer finger. But my thumb no longer works. `create()` can't edit an existing credential. It's likely that you're instead seeing this as a consequence of: > As a side note, I also am seeing that authenticators do not allow me to create separate credentials on the same authenticator with the same user ID / userHandle in it. They enforce a uniqueness on that field's value. Yes, authenticators de-duplicate on `(RP ID, userHandle)` pairs as duplication keys. This is as intended. So if your authenticator associates particular biometric features with individual credentials, then it would be expected that one no longer works after overwriting the credential it was associated to. Does that help? -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2266#issuecomment-2679163684 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 February 2025 17:24:15 UTC