Solo: AuthenticatorData extensions not conforming to CTAP2 canonical CBOR encoding form

[aseigler]

When sending a MakeCredential request with hmac-secret extension present and set to true, the Solo response extensions CBOR encoded bytes are A26B686D61632D736563726574F56B6372656450726F7465637401, which is {"hmac-secret": true, "credProtect": 1}. The keys in the map are presented out of order per the CTAP2 canonical CBOR encoding form rules (https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding).

Currently this is preventing new Solo FIDO registrations against Microsoft's Azure AD and consumer services. @timcappalli has additional information.

[timcappalli]

FIDOError[13:14:37] authenticator_data.cc:72 CBOR decoding of authenticator data extensions failed (Map keys must be strictly monotonically increasing based on byte length and then by byte-wise lexical order.) from A26B686D61632D736563726574F56B6372656450726F7465637401

[timcappalli]

The registration process for Microsoft Account and AAD will fail with the following message:

We encountered an issue setting up your security key. We couldn't verify your identity or you are using private mode. Please ensure you are not in a private browsing window and please try again.

[conorpp]

Thanks for reporting!

I've fixed this in the 4.1.0 release, and is covered under new tests introduced here https://github.com/solokeys/fido2-tests/pull/49.

Could you please check it and see if there's still an issue?

[timcappalli]

Working with AAD! Thanks for the quick fix @conorpp!

[aseigler]

I wonder why the AAGUID is all zeroes? That's odd.

[aseigler]

Worked great on consumer and corporate registration endpoints!