"Error: UV only authenticators are not yet supported!" in MakeCredential tests, with a UP only authenticator

[ghislaindemael]

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

• [X] I SOLEMNLY SWEAR THAT I HAVE SEARCHED DOCUMENTATION AND WAS NOT ABLE TO RESOLVE MY ISSUE

  What protocol are you implementing?

• [X] CTAP2.1

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

• [X] Security Key / FIDO2 / U2F authenticators

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

v1.7.16 || CTAP2.1

What is the OS and the version are you running?

For desktop tools

• [X] Windows (Windows 11, Build 22621)

Issue description

Hi !

Currently building a BLE Authenticator, I passed the getInfo step, and thus the next part is the implementation of the MakeCredential requests and responses.

My authenticator is a USB dongle that may check UP, but may not distinguish users (at least, easily). Thus, my getInfo options are the following :

"options": { "plat": false, "rk": false, "up": true, "makeCredUvNotRqd": true }

When launching the "MakeCredential Response" tests, I have the following steps in the Console : [CTAP2.1] Reset: ---> Sending CTAP CMD... 07 undefined ... [CTAP2.1] Reset: <--- Received successful response {statusCode: 0, type: "Reset", cborResponse: undefined, cborResponseStruct: undefined, cborBuffer: Uint8Array(0), …} [CTAP2.1] GetInfo: ---> Sending CTAP CMD... 04 ... [CTAP2.1] GetInfo: <--- Received successful response {statusCode: 0, type: "GetInfo", cborResponse: {…}, cborResponseStruct: {…}, cborBuffer: Uint8Array(105), …} [CTAP2.1] Generating test PUAT...

In the main window :

At this point, the tools terminates its actions. Nothing is sent to the authenticator.

I started by searching the error in the source code, but it returned no results :

Since no request leaves the Tools for the Authenticator, I tried to debug this error using the Platform Actions for authenticatorMakeCredential. As "uv" is set to false and it doesn't seem the Tools prefer enforcing user verification (Visibly at least), we can skip to paragraph 1.2 which states :

2. Otherwise, implying the authenticator is not presently protected by some form of user verification, or the Relying Party wants to create a non-discoverable credential and not require user verification (e.g., by setting options.authenticatorSelection.userVerification to "discouraged" in the WebAuthn API), the platform invokes the authenticatorMakeCredential operation using the marshalled input parameters along with the "uv" option key set to false and terminate these steps. This tells us it is supposed to invokes the authenticatorMakeCredential operation, however, as said before, no BLE buffer is sent to the Authenticator.

This also happens for each of the tests of the MakeCredential Request test group.

However, when launching the GetAssertion Request or GetAssertion Response test groups, the operation is invoked : and is received by the authenticator :

Why is operation invoked in the GetAssertion tests, but not in the MakeCredential ones ? Aren't they built the same way ?

Sincirely, Ghislain

[iirachek]

@ghislaindemael

Why is operation invoked in the GetAssertion tests, but not in the MakeCredential ones ? Aren't they built the same way ?

There was a small bug with this set of tests in v1.7.16 when using configurations similar to yours, and it caused MakeCred tests to behave incorrectly. Can you try the v1.7.17 (released a few days ago) and see if the problem persists?

The GetAssertion and MakeCredential tests use similar logic, but have difference in test preparation steps since the latter required additional checks to account for makeCredUvNotRqd.

[ghislaindemael]

@iirachek

I switched to v1.7.16 on the 21st, so I wasn't aware of the new version.

However, I'm unable to test this case, as the v1.7.17 Tools are not able to connect to my BLE auth. The scan is infinite.

Here are some screenshots of v1.7.16 and v1.7.17 after 30 seconds of scanning, I can provide a video if necessary.

Should I open a new GitHub issue for this issue ?

[iirachek]

@ghislaindemael

My mistake - packaged the build incorrectly. Reuploaded the v1.7.17 with working Bluetooth module.

[ghislaindemael]

Buffers are sent properly now, thanks !