Failing RK MakeCredentials test in v1.6.42

[Gerard Green]

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]

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.