AAGUID is always zero'd out during registration and authentication

[zfLQ2qx2]

I am using a YubiKey 5c with the webauth.io demo app, I am requesting direct attestation, however the AAGUID field is always zero'd out. The expected value is ee882879-721c-4913-9775-3dfcce97072a per https://support.yubico.com/hc/en-us/articles/360016648959-YubiKey-Hardware-FIDO2-AAGUIDs

I'm not sure if this is a bug or if I am going something incorrectly.

[zfLQ2qx2]

I updated to the latest version of the library and applied the fix from issue 72 to get the webauthn.io demo working again, still getting AAGUID zero'd out on both flows.

Then I ran some tests with https://webauthn.me/debugger and it looks like we are not setting attestation correctly because I can toggle the value on webauthn.me and duplicate both the 0'd out and correct vaules.

I will debug that more tomorrow.

[zfLQ2qx2]

I verified that the webauthn.io demo is passing through the attestation parameter and that the AAGUID is being returned in the navigator.credentials.create response (I see it in hex dump). I'm going to have to start debugging the library now. I see one place where it looks like the address of a local variable is being returned from a function, I suspect that is the issue.

[zfLQ2qx2]

I figured out what https://webauthn.me/debugger was doing differently, they had userVerification set to "preferred" by default and that results in AAGUID being populated instead of all zeros. It looks like the AAGUID id is also present in the certificate that the yubikey sends, so that is where I saw it in the raw data.

[infinisil]

I also ran into this, turns out that Firefox just doesn't implement CTAP2 yet, which is apparently needed for the aaguid to be set. The bug that tracks this is https://bugzilla.mozilla.org/show_bug.cgi?id=1530370

[arianvp]

In the case where this happens Firefox will set the attestation format to fido-u2f by the way. So you can detect this beforehand.

Also see https://github.com/duo-labs/webauthn/blob/master/protocol/attestation_u2f.go#L22

It is expected behaviour that the AAGUID is all zeroes by the Webauthn sepc when the format is fido-u2f

Sugggesting to close this as "working as expected"

[james-d-elliott]

This is controlled by the protocol.ConveyancePreference, if set to direct it will require the AAGUID is sent or it will reject the attestation unless the attestation type is fido-u2f. I've personally tested this in Firefox and it seems to function. That being said as pointed out by Arian, if the attestation format is fido-u2f then it's expected all zeroes, as CTAP1 has no concept of AAGUID (see step 4):

https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#u2f-authenticatorMakeCredential-interoperability