Failing RK MakeCredentials test in v1.6.42

37 views
Skip to first unread message

Gerard Green

unread,
Feb 21, 2022, 10:50:14 PMFeb 21
to fido...@fidoalliance.org

Hi,

I'm running the "CTAP2.1 Authenticator - Options: Resident Key" tests on my device;
P-1 passes
P-2 and P-3 skip because my authenticator has a display
P-4 fails.
When I look at the MakeCredentials message I receive I see

{
  1: h'e7710b73826bf273bf5ee085b8727da3e16de9ce063cd16b40c58ff42c8c7920', 
  2: {"id": "soothewait.pw", "name": "The Example Corporation with fake domain!"}, 
  3: {"id": h'a70ab05a1d43bc0972e732ba867b35f469d849f811e6466a6dc68f7dcc7dca39', "name": "josiah...@satsumakiwi.sv", "displayName": "Josiah Turman"}, 
  4: [{"alg": -7, "type": "public-key"}], 
  7: {"rk": true}
}

My device returns CTAP2_ERR_OPERATION_DENIED.

I feel like the MakeCredentials message should have pinUvAuthParam and pinUvAuthProtocol fields. Step 7 of the MakeCredentials algorithm seems to confirm this.

The MakeCredentials message in P-1 does contain both pinUvAuthParam and pinUvAuthProtocol fields.

Am I misunderstanding this?

kind regards
Gerry

John Bradley

unread,
Mar 3, 2022, 2:05:19 PMMar 3
to FIDO Dev (fido-dev), gerr...@gmail.com
If you have a display, you may also be advertising in getInfo that you support internal UV in options.  

In that case, it should be following CTAP2.1 and getting a PUAT before doing the make credential.  

It might be following the CTAP2.0 logic of sending uv true in options and not getting a PIAT.  However,  only rk is set in options (0x07).  

So assuming that there is some form of UV set on the device you are correct in returning an error.  

I have a slightly different problem with that test.

{1: h'590ED5E24FFE522EA398CB00A17829A13478EBB62940427126C41FEEB3356747', 2: {"id": "affordmurky.et", "name": "The Example Corporation with fake domain!"}, 3: {"id": h'C8A9B199F851BB19F9441B022D0C55CB8FF874DFE4FAD0BD7D4926C91876E6AC', "name": "pereg...@bananastraw.uz", "displayName": "Peregrin Tuk"}, 4: [{"alg": -7, "type": "public-key"}, {"alg": -8, "type": "public-key"}, {"alg": -35, "type": "public-key"}], 7: {"rk": true}, 8: h'33287C3A58B49AE1827706E146E6A7F833A00C6C363BDB4AD31CDD8F1E781C87', 9: 2}

On a non-bio authenticator, it is detecting pin protocol 2 and getting a PUAT.  

The problem I seem to have is that over NFC the authenticator is not power cycled between make operations thus consuming the TUP on the first make credential causing an error on the second make credential due to the CTAP2.1 requirement of one TUP per operation.  

So yes this test needs more work.
Reply all
Reply to author
Forward
0 new messages