uv option key true to an authenticator that is not advertising uv in getInfo option ID will fail with CTAP2_ERR_UNSUPPORTED_OPTION

[ve7jtb]

{
  "description": "Tests is user verification set to true is accepted in MakeCredential.",
  "error_message": "The user verification option (true) was not accepted.",
  "id": "make_credential_option_uv_true",
  "observations": [
    "A prompt was expected, but not performed. Sometimes it is just not recognized if performed too fast.",
    "The failing error code is `CTAP2_ERR_UNSUPPORTED_OPTION`."
  ],
  "result": "fail",
  "tags": [
    "Client PIN"
  ]

For non bio devices (not advertising "uv" in getInfo options) sending the "uv" option key generates a CTAP2_ERR_INVALID_OPTION error in CTAP2.0 and CTAP2.1. This test should only be applied to authenticators advertising the "uv" optionID.

In CTAP2.0 a uv option key in the request will always generate a CTAP2_ERR_INVALID_OPTION for non bio keys.

In CTAP2.1 if no PUAT is provided and the uv option key is true the authenticator generates CTAP2_ERR_INVALID_OPTION for non bio keys.

[kaczmarczyck]

In the latest review draft for CTAP 2.1, the spec says:

Note: Use of this "uv" option key is deprecated in CTAP2.1. Instead, platforms SHOULD create a pinUvAuthParam by obtaining pinUvAuthToken via getPinUvAuthTokenUsingUvWithPermissions or getPinUvAuthTokenUsingPinWithPermissions, as appropriate.

I thought uv in CTAP 2.0 meant any type of uv? It reads

user verification: Instructs the authenticator to require a gesture that verifies the user to complete the request. Examples of such gestures are fingerprint scan or a PIN.

Are you saying the PIN above is intended only for security keys with keyboards?

I agree this tests needs to be updated for CTAP 2.1 because of the above deprecation. For CTAP 2.0, why is setting up a PIN and then sending uv not okay for non-biometric devices?

[kaczmarczyck]

Please see #99 in comparison. There uv is used for biometry only. Is this working as intended?