Conditional creation incompatible with `uvInitialized` semantics in Chapter 7?

[arianvp]

https://w3c.github.io/webauthn/#sctn-createCredential says

The client MUST set BOTH requireUserPresence and requireUserVerification to FALSE when options.mediation is set to conditional unless they may explicitly performed during the ceremony.

However then that means that uvInitialized is set to FALSE in the credential record according to https://w3c.github.io/webauthn/#reg-ceremony-create-credential-record

which means that the credential created may not be used for authentication

When this is false, including an authentication ceremony where it would be updated to true, the UV flag MUST NOT be relied upon as an authentication factor.

https://w3c.github.io/webauthn/#abstract-opdef-credential-record-uvinitialized

This feels like it is in contradiction with each-other. The whole idea of conditional creation is that we automatically create a passkey for subsequent log ins. However this is incompatible with the uvInitialized semantics from my reading?

[emlun]

which means that the credential created may not be used for authentication

When this is false, including an authentication ceremony where it would be updated to true, the UV flag MUST NOT be relied upon as an authentication factor.

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:

17. Determine whether user verification is required for this assertion. User verification SHOULD be required if, and only if, pkOptions.userVerification is set to required.
    If user verification was determined to be required, verify that the UV bit of the flags in authData is set. Otherwise, ignore the value of the UV flag.

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

[arianvp]

Sorry I didn't make myself completely clear. I understand it can still be used as a posession factor. What I mean is that it can not be used as the Sole authentication signal.

Do I then understand correctly that a passkey added through conditional create will needs to be used at least one more time in combination with a password after registration before we can use it as the sole factor for sign in?

That seems to be in contradiction with the flow the explainer originally tried to describe. Namely automatically create a passkey during password login so that next time you dont need to enter a password. But at this point we don't know anything about the passkey's capability of UV. So on next login someone uses the passkey and has UV set to 1. UVinitinalized is still false so we need to ask for a second authentication factor (the users password) and only then can we set UVinitinalized to true.

That means that with the conditional create flow a person needs to enter their password twice?

Once before the key is automatically created. And another time on subsequent login where we haven't proven yet that the key is suitable to be used as the sole method.

Therefore, updating uvInitialized from false to true SHOULD require authorization by an additional authentication factor equivalent to WebAuthn user verification.

Which isn't as smooth as it was originally intended I think?

[arianvp]

Like. This flow would only be smooth if I set uvInitialized = true immediately during registration regardless of the fact that registration returned UV = false but this seems like a security hole. As it allows for the scenario you describe where Bob can set a PIN on Alice's key

I just don't understand how the UX of conditional create as described in the explainer and in for example https://developer.chrome.com/docs/identity/webauthn-conditional-create should work with these constraints in mind

The chrome blog post only says the following:

The registration response returns both "User Presence" and "User Verified" as false, so the server should ignore these flags during credential verification.

Which doesn't really help . What does ignore mean? That I just set uvInitialized to true unconditionally ? But how do I then avoid Bob taking Alice's key and setting a PIN that Alice doesn't know and then sign in to Alice's account?

[emlun]

Good points! @pascoej any thoughts on this?

I think it could be reasonable for conditional registration to return UV=1 if the client checked some authentication factor "equivalent to WebAuthn user verification" while it "recently mediated an authentication". For example: if a password manager was used to autofill a password and then do the conditional registration, and the passphrase/key/biometric/etc for the password vault is the same that the password manager would use for passkey UV, then I think you can argue those are "equivalent" and you could reasonably set UV=1 in the conditional registration. I have not thought about how something like that could be expressed in spec language, though.

[pascoej]

I think the idea with UV=0 is that we shouldn't re-use the recent authentication and RPs using conditional create should have some special handling for these upgrade registrations to handle UV=0. This also aligned nicely with where I recall we landed with regard to #2034 and #2021.