google passkey registration fail on windows 10

[sandeep kumar]

Hello,

When I tried to register my external USB biometric authenticator with google passkey on windows 10  (version 10.0.19045.3208), it fails to register but it can register if I use windows 11. 

I tried to observe USB logs and find that authenticatorMakeCredential command has rk option missing when working on windows 10, but the same is true when used on win 11.

The authenticatorGetInfo command has same response with rk option set as "true" to announce that device supports it.

To validate if rk option missing on win 10 is the issue, I forced RK option as true for authenticatorMakeCredential command, in my device firmware, and yes it can work with that.

Could somebody let me know if they have observed same issue and how to overcome this. The device is following the instructions from platform on how the credential is to be created.

Thanks,

Sandeep

[sandeep kumar]

Hello,

Does anybody observe similar situations?

Thanks,

Sandeep

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7b946ed4-1a7c-4785-91d2-cb84e6a1ff50n%40fidoalliance.org.

[Robert Hartman]

Sandeep.

When you said...  "I tried to register my external USB biometric authenticator with google passkey on windows 10  (version 10.0.19045.3208), it fails to register"  ; where do you see the failure?  Is the failure being seen from the server?

I believe Windows 10 uses Microsoft Webauthn API Version 2 and Windows 11 uses Microsoft Webauthn API Version 3/4

I would start by looking at the input to WebAuthnMakeCredential.

In both API Level 2 and API Level 3/4 the  WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS structure contains...

    // Optional. Require key to be resident or not. Defaulting to FALSE;
    BOOL bRequireResidentKey;

API Level 4 added

    // Optional. Prefer key to be resident. Defaulting to FALSE. When TRUE,
    // overrides the above bRequireResidentKey.
    BOOL bPreferResidentKey;

In your implementation,  what are the values being passed into the WebAuthnMakeCredential API for Win 10 and Win 11 for the WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS  fields mentioned above? Also in your implementation what version are you specifying for the  DWORD dwVersion in the WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS option structure for both OS's.

Using your USB monitor, can you see if the rk option is  going to the  authenticator and is it being set properly (for both OS's).

After the investigation of the input,  I would look at the result of the WebAuthnMakeCredential API call (which is the WEBAUTHN_CREDENTIAL_ATTESTATION ) and the HRESULT.

I assume the HRESULT from the API  is  S_OK.

Microsoft introduced a BOOL bResidentKey in the WEBAUTHN_CREDENTIAL_ATTESTATION structure for its WebAuthn API Level 3.

This  bResidentKey value should be present in the response for WebAuthnMakeCredential for Windows 11 and missing in Windows 10 responses. You may want to check the response DWORD dwVersion in the returned WEBAUTHN_CREDENTIAL_ATTESTATION for both your Windows 10 and Windows 11. 

The actual resident key response is sent back to the relying party in the clientExtensionResults dictionary.

https://www.w3.org/TR/webauthn-2/#sctn-authenticator-credential-properties-extension ... It will look similar to 

"clientExtensionResults": {

    "credProps": {“rk”:true/false}

  }

Since Windows 10 uses Microsoft Webauthn API Version 2,  and that api version does not support the bResident key field in the WEBAUTHN_CREDENTIAL_ATTESTATION structure, I would expect credProps[rk]  to be missing in the response to the relying party or if rk is present it would be false

Windows 11 should have a value for bResidentKey defined in the WEBAUTHN_CREDENTIAL_ATTESTATION return structure and the value of  rk should be returned in the JSON response.

Hope that helps a little

[sandeep kumar]

Hi Robert,

Thank you for your response.

I monitored the USB bus log and then reconstructed the makeCredential commands on win 11 and win 10 platforms, where I observed that rk option is set as true for win 11 but is absent on win 10.

I see the response for makeCredential is good in USB logs and no error was reported, so I believe it, must be some failure on the server side. I am not sure how can I capture it.

Thanks,

Sandeep

[Robert Hartman]

For the Windows 10 issue of not setting the rk option, maybe it is  related to  the  bRequireResidentKey member of the WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS structure not being set to TRUE.  I assume it is set correctly. 

You may have to check with Microsoft to see what's going on with Windows 10.  It may be that Windows 10 doesn't support this option, but I assume it would because the bRequireResidentKey is  the OPTIONS structure for API Level 2.  

What kind of application is the client application - the application making the WebAuthnMakeCredential call?

At some point in the MakeCredential ceremony,  the client application should take the result of the WebAuthnMakeCredential api and convert it to JSON and send that to the relying party.  Also, while creating the JSON, the client application may need to add the clientExtensionResults dictionary - this dictionary contains the credprops[rk] response.  credprops is an extension processed by the client.   I assume the response is all JSON 

If  the client application is a browser, then developer mode (F12) will show you the JSON result.

If it is a 3rd party application then you will need to ask them to check if the clientExtensionResults is being added to the response.

If the application is adding the clientExtensionResults dictionary with the credprops[rk] result; then you may be able to peg the issue on the relying party. 

Good Luck.