- From: Kyle Simpson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Feb 2025 16:44:38 +0000
- To: public-webauthn@w3.org
@emlun Thank you! But I'm quite confused by two of your statements. > the userVerification parameter is set per ceremony, not per credential (this is a common point of confusion). I appreciate this clarification, but it frustrates me that this doesn't match my testing. Just now, I tried this again to make sure I know what I am seeing. I setup a passkey (with all the *required UV* settings I indicated earlier in this thread) on windows (stored in Windows Hello). The response came back and told me that it was a resident key, and that UP and UV were both used. I then tried an assert with that same credential (specified by credential ID), but where I set `mediation: "silent"` and `userVerification: "discouraged"` -- trying to *disable* / *avoid* the UP/UV requirement I setup the credential with -- but indeed, my authenticator still required UV. And in fact, the response flags came back saying both UP and UV were used. Then I did the *same* steps on an Android device, and got the exact same results. In other words, I was *unable*, with this testing anyway, to circumvent the UV/UP "requirement" from registration while doing an assert. Is there something I missed here? Or am I just fortunate that *those* authenticators are offering this protection, whereas it's not required that they do so? ---- > there is no guarantee that "the same human user affirmatively presents the same biometric factor", only that "some authorized human presents some authentication factor authorized at the time". I'm even more confused by this one. Are you saying either of the following? - I might setup two fingerprints in a SINGLE credential (and get JUST ONE specific credential ID back for both) on an authenticator, and whichever one of those I use in an assert, my response would report the same credential ID (and thus, the same userHandle)? - I might setup two different credentials (one fingerprint for each) on the same authenticator, each with its own unique credential ID, but that if I try to assert with one credential ID, the authenticator might let me **UV** with the other different credential, but yet STILL RETURN the credential ID (and thus userHandle) that I initially requested? I am not seeing *either* of those scenarios, even remotely, in my testing. What I am seeing is that the authenticators enforce a strict one-to-one relationship between a biometric factor and the credential it is registered against -- again, on the same authenticator. If I set up two fingerprints on the same authenticator, I will *always* get two different credentials, with different credential IDs. 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. 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. 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. -- GitHub Notification of comment by getify Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2266#issuecomment-2679048117 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 16:44:38 UTC