Re: [webauthn] Conditional creation incompatible with `uvInitialized` semantics in Chapter 7? (#2295)

> which means that the credential created may not be used for authentication
> 
> > When this is false, including an [authentication ceremony](https://w3c.github.io/webauthn/#authentication-ceremony) where it would be updated to true, the [UV](https://w3c.github.io/webauthn/#authdata-flags-uv) [flag](https://w3c.github.io/webauthn/#authdata-flags) MUST NOT be relied upon as an [authentication factor](https://pages.nist.gov/800-63-3/sp800-63-3.html#af).

That is not what this text was intended to mean. The credential certainly can be used for authentication as a possession factor. The thing here is that much like a WebAuthn credential as a whole is "trust on first use" (TOFU), the `UV` flag is _also_ a TOFU attribute on its own.

The first time the RP sees `UV=1` for a given credential, that is _not_ (from that RP's point of view) a guarantee of a successful second authentication factor, because that second authentication factor had not yet been established with this RP. The first time the RP sees `UV=1` for a credential, all that says is that _some_ user has set up _some_ UV method on that authenticator.

For example: Alice has a CTAP2 security key without a PIN set. She registers this security key on `example.org` still without a PIN set, and then leaves the security key unattended on her desk. Bob takes Alice's security key and sets a PIN on it. He then uses it to authenticate as Alice to `example.org`, which sets `userVerification: "preferred"`. Bob knows the PIN, so the UV succeeds. This is the first time `example.org` sees `UV=1` with this credential, and this `UV=1` clearly does not mean that it was Alice that performed this UV. Contrast this with if Alice had set a PIN and authenticated (or registered) with UV before Bob got hold of the security key: then the RP would be assured that whenever it sees `UV=1` for the second or later time, it's Alice that performed that UV (unless Alice has shared the PIN with someone, thereby authorizing them to operate her account on her behalf).

Only _after_ seeing the first registration/assertion with `UV=1` can the RP be assured that the second and subsequent times it was the _same_ user (or one authorized by the original user) that performed UV during that assertion ceremony.

So I don't think there's any contradiction or incompatibility here, but evidently it is unclear. I think it would be appropriate to at least mention this in step 17 of [ยง7.2. Verifying an Authentication Assertion](https://w3c.github.io/webauthn/#sctn-verifying-assertion):

>17. Determine whether [user verification](https://w3c.github.io/webauthn/#user-verification) is required for this assertion. [User verification](https://w3c.github.io/webauthn/#user-verification) SHOULD be required if, and only if, pkOptions.[userVerification](https://w3c.github.io/webauthn/#dom-publickeycredentialrequestoptions-userverification) is set to [required](https://w3c.github.io/webauthn/#dom-userverificationrequirement-required).
>  If [user verification](https://w3c.github.io/webauthn/#user-verification) was determined to be required, verify that the [UV](https://w3c.github.io/webauthn/#authdata-flags-uv) bit of the [flags](https://w3c.github.io/webauthn/#authdata-flags) in authData is set. Otherwise, ignore the value of the [UV](https://w3c.github.io/webauthn/#authdata-flags-uv) [flag](https://w3c.github.io/webauthn/#authdata-flags).

Do you have any other suggestions on how we could make this clearer?

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2295#issuecomment-2881700960 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 14 May 2025 22:10:05 UTC