Re: [webauthn] Refer to options for the user verification check (#1718)

@agl Ah I see now, so a potential attack here is a non-conformant client, pretending that the authenticator doesn't support user verification, when it really does, in case of `userVerification` set to `"preferred"`. A conformant client would always ask for user verification in such a case, as specified in the client's [Create](https://www.w3.org/TR/webauthn-2/#sctn-createCredential) and [Get](https://www.w3.org/TR/webauthn-2/#sctn-getAssertion) specifications.

In this case I believe the description of [`"preferred"`](https://www.w3.org/TR/webauthn-2/#dom-userverificationrequirement-preferred) should be adjusted, because it currently reads:

> `preferred`: This value indicates that the [Relying Party](https://www.w3.org/TR/webauthn-2/#relying-party) prefers [user verification](https://www.w3.org/TR/webauthn-2/#user-verification) for the operation if possible, but will not fail the operation if the response does not have the [UV](https://www.w3.org/TR/webauthn-2/#uv) [flag](https://www.w3.org/TR/webauthn-2/#flags) set.

I believe the `will not fail` should be changed to `may not fail`. A mention of client policy would also be good here.

Additionally I believe that the [Registering a New Credential](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-registering-a-new-credential) and [Verifying an Authentication Assertion](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-verifying-assertion) relying party operations should be expanded with a step to determine whether user verification is _effectively_ required (similar to the `Create`/`Get` operations). This would look something like this:

> 14. Let `userVerification` be the effective user verification requirement for credential creation as follows:
>
>     If `options.userVerification`
>     - is set to `"required"`: Let `userVerification` be `true`
>     - is set to `"preferred"`: Let `userVerification` be determined by client policy, taking into account further information gathered from the response [be more specific, what information can the relying party use here?]
>     - is set to `"discouraged"`: Let `userVerification` be `false`
> 15. If `userVerification` is `true`, verify that the [User Verified](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#concept-user-verified) bit of the [flags](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#flags) in authData is set.

This also makes it clear that it's relying party policy, but only in the `"preferred"` case.

If that sounds okay then I can propose a PR.

-- 
GitHub Notification of comment by infinisil
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1718#issuecomment-1128023604 using your GitHub account


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

Received on Monday, 16 May 2022 18:56:15 UTC