Incorrect handling of 'preferred' user verification.

[zelch]

Specifically, it is handling 'preferred' as 'required'.

By my reading of the Webauthn spec, the handling of 'preferred' depends of the definition of 'Protected by some form of User Verification'.

Per the spec, this requires that the support be both supported and enabled.

In 6.1.1, the text at the beginning describes the case where user verification is 'required' and not present.

It then describes the process flow, I draw some attention to 6.1.1, 1.1 where things start to go wrong in the described flow, though I will definitely note that the text at the beginning says 'In other words, this is only a brief sketch of plausible platform behavior.'

If the authenticator is protected by some form of user verification, or the Relying Party prefers enforcing user verification (e.g., by setting options.authenticatorSelection.userVerification to "required", or "preferred" in the WebAuthn API

In 6.1.1, 1.1.2.2 we get to the point where the code is following the described flow... But the described flow simply does not handle this case.

The request says that user verification is 'preferred', the device has support for clientpin, however clientpin is not configured on the device.

This is currently handled in fido2/client.py, class _Ctap2ClientBackend, function _should_use_uv, on line 470.

In this code, it looks at both if uv is supported, and if uv is configured.

If user verification is REQUIRED, or if user verification is preferred and supported, or if 'alwaysUv' is set by the device, then it fails if uv is not configured for the device.

I propose that the uv_supported check be removed entirely, and in the if statement we replace:

            or (
                user_verification == UserVerificationRequirement.PREFERRED
                and uv_supported
            )

with

            or (
                user_verification == UserVerificationRequirement.PREFERRED
                and uv_configured
            )

This would, I believe, be both compliant to the spec, and would work for the fairly common case where user verification is preferred, but not required, and a user with a Yubikey 5 has not configured a PIN.