Closed Treeston closed 1 year ago
Hi,
If the device does not support native UV, and requires a client PIN, I am expecting this operation to fail with FIDO_ERR_PIN_REQUIRED, allowing me to query the user for a PIN and retry.
Per the CTAP2.0 specification that your device should adhere to: if the "uv" option was specified and set to true and the device doesn’t support built-in UV, it should return FIDO_ERR_UNSUPPORTED_OPTION
(CTAP2.1 authenticators return some other error code). It would seem that, unfortunately, your authenticator does not comply with the specification, and the bug report should be filed with the manufacturer.
For reference, this is the request sent to the authenticator (per the debug output above):
{1: "example.com", 2: h'0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20', 5: {"up": true, "uv": true}}
You could work around this using fido_dev_{supports,has}_{pin,uv}()
if you'd like to determine what user verification method to use before firing off the assertion request.
Thanks for the swift response!
Am I understanding you correctly that the uv
option (controlled by fido_assert_set_uv
) only controls device-native UV such as biometrics or on-authenticator PIN pad, but not a PIN entered on the client device? I.e., if I am looking to authenticate to a device without native UV, using a client PIN, I should not include the uv
option?
Yes, that's correct.
What version of libfido2 are you using?
libfido2.so.1.12.0
What operating system are you running?
Ubuntu 20.04 LTS
Does the problem happen with different authenticators?
Unknown
Please include the output of
fido2-token -L
.fido2-token -L
Please include the output of
fido2-token -I
.fido2-token -I
I am creating an assertion for a relying party which requires user verification. To this end, I call
fido_assert_set_uv
withFIDO_OPT_TRUE
before issuingfido_dev_get_assert
.If the device does not support native UV, and requires a client PIN, I am expecting this operation to fail with
FIDO_ERR_PIN_REQUIRED
, allowing me to query the user for a PIN and retry.Instead, the operation completes with
FIDO_OK
after a user presence test is passed. Unsurprisingly, the returned credential does not haveUV (0x40)
set, and will be rejected by the relying party.Minimal example, using a previously-created, discoverable test credential for brevity.
(The issue also arises when specifying the accepted credential ID explicitly.)
stdout output
FIDO_DEBUG stderr output