Closed nagreme closed 10 months ago
yackermann
commented
12 months ago @nagreme if your authenticator report alwaysUv: false, then it means that it supports alwaysUv, but it is disables.
Set alwaysUv to undefined if you do not support it.
absent the authenticator does not support the Always Require User Verification feature.
nagreme
commented
12 months ago @herrjemand My authenticator supports alwaysUv and I am indicating the state of it in the GetInfo correctly.
I am saying that the credProtect tests should not enable alwaysUv (set to true via toggleAlwaysUv subcmd of AuthrCfg) before running because it alters the behaviour they are expecting causing some tests to fail.
BryanJacobs
commented
11 months ago I can confirm that it's currently impossible to pass the CredProtect tests with an authenticator that:
The test suite does, indeed, enable alwaysUv before running CredProtect tests and then forget to use a PIN.
iirachek
commented
10 months ago This issue should be resolved in the latest v1.7.16 update.
nagreme
commented
10 months ago This is fixed in the 1.7.16 release but now the makeCred tests are failing because no PIN is being set in the test setup after the authenticator reset 😅
By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.
If you have privacy concerns, please email conformance-tools@fidoalliance.org
FIRST PRE CHECK
What protocol are you implementing?
NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.
What is your implementation class?
Specifically an NFC Smart Card
What is the version of the tool are you using?
1.7.14
What is the OS and the version are you running?
For desktop tools
Issue description
In 1.7.14 (also in 1.7.11), if the authrCfg option is present and set to true in the getInfo, the conformance tool will send an authenticatorConfig toggleAlwaysUv command in the setup for the credProtect tests, even when the alwaysUv option is already false in the getInfo.
If alwaysUv is initially false (authrCfg and uv options are true), this causes tests P-2 and P-3, which are expecting one or both respectively of the getAssertion requests they send to return an error, because they are checking credProtect policy levels that require UV at least in some circumstances, to instead complete successfully and fail the test.
If alwaysUv is initially false (authrCfg is true and uv option is false) then P-1 and P-2 end up failing because they expect successes but the authenticator is being told to use a UV that is not yet configured.
In comparison the same tests are passing in 1.7.10 under the same circumstances because the toggleAlwaysUv command is absent.
What was the purpose of adding this toggleAlwaysUv command in the more recent versions of the tool? Can this be removed or adjusted to only disable alwaysUv when it's initially true?