Failing RK MakeCredentials test in v1.6.42

Skip to first unread message

Gerard Green

Feb 21, 2022, 10:50:14 PMFeb 21


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": "", "name": "The Example Corporation with fake domain!"}, 
  3: {"id": h'a70ab05a1d43bc0972e732ba867b35f469d849f811e6466a6dc68f7dcc7dca39', "name": "", "displayName": "Josiah Turman"}, 
  4: [{"alg": -7, "type": "public-key"}], 
  7: {"rk": true}


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

John Bradley

Mar 3, 2022, 2:05:19 PMMar 3
to FIDO Dev (fido-dev),
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": "", "name": "The Example Corporation with fake domain!"}, 3: {"id": h'C8A9B199F851BB19F9441B022D0C55CB8FF874DFE4FAD0BD7D4926C91876E6AC', "name": "", "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
0 new messages