Should credentials requested with attestation=none include an AAGUID?

[pascoej]

As per processing in https://w3c.github.io/webauthn/#CreateCred-async-loop, the AAGUID is zeroed out if a none attestation is given. However, at least for the platform authenticator, WebKit is the only one to actually perform this step. The other implementations do not zero out the AAGUID and we have gotten requests to stop zeroing it out.

Should we change the spec to not zero out the AAGUID in the steps stating:

credentialCreationData.attestationConveyancePreferenceOption’s value is ... Otherwise ... Replace the AAGUID in the attested credential data with 16 zero bytes.

?

[pascoej]

There are in flight discussions regarding this, but I plan to make a PR removing the language. At least for platform credentials in case we need it.

[nsatragno]

From the f2f: Chrome will likely still zero out the aaguid for security keys, as SKs can stuff persistent identifiers in them. It would be nice for the Apple platform authenticator to have a non-zero aaguid though (:

[irew]

This would be helpful for 3rd party passkey providers that wish to convey this identity to the RP for UX purposes. Dashlane is currently providing an AAGUID no matter the attestation request.

[agl]

Assign to @agl: update spec to say zero out only for non-platform authenticators. Think about enterprise attestation.

[nicksteele]

@nicksteele to open PR

[pascoej]

I think https://github.com/w3c/webauthn/pull/2150/files fixes this.

[zacknewman]

Both #2058 and #2150 should fix this. #2058 fixes this more directly as it addresses the AAGUID part; however #2150 addresses the attestation part but only when self attestation is used. #2146 raises the possibility that all platform authenticators should retain their attestation and not just ones that use self attestation; however the PR I sent was conservative and only applies to self attestation. It would be easy to change #2150 so that all attestations are left alone for platform authenticators, but I wanted feedback from others before doing so.

[zacknewman]

The PR I sent was purely about consistency but not about agreement with this new change. As a WebAuthn user, I would like my privacy choices to be respected regardless of what an RP thinks. Worst case, an RP can abort the ceremony if I do not consent to provide an AAGUID forcing me to not use that RP or knowingly provide information I would rather keep private because I desire to be a user so badly.

Currently web browsers like Firefox ask for user consent when registering a new credential iff "none" AttestationConveyancePreference is not requested in order to balance usability and user privacy (i.e., a user-consent prompt is only shown when necessary). With this change, a user that was not asked for consent will always provide AAGUID when using a platform authenticator. This means privacy-respecting user agents at best will have to adapt to always asking for consent even when "none" is requested and use that response to dictate if AAGUID should be replaced even for platform authenticators or ask for consent after receiving the response from an authenticator in the event AAGUID is not all-zero in order to reduce how often consent must be asked.

Perhaps the spec should require user agents to at least ask for user consent when AAGUID is not all-zero restoring the user's right to choose?

[nicksteele]

I think this doesn't have to be a firm requirement, just that the the authenticator SHOULD include the AAGUID. This change was being made, as per some discussion at TPAC, with the expectation that we'll be removing authenticatorDisplayName from credProps, and allow RPs to use the AAGUID to determine the display name of the authenticator. I would say that privacy-conscious authenticators and clients should continue to zero out the AAGUID, and were probably not filling out authenticatorDisplayName if it was requested anyhow.

I would say that a user doesn't have to consent to something that they could potentially obscure, either by using a fake AAGUID (aka lying) or by zeroing it out, and we should continue to only push for additional consent in the presence of attestation.

[zacknewman]

I would say that a user doesn't have to consent to something that they could potentially obscure, either by using a fake AAGUID (aka lying) or by zeroing it out

How can I zero out an AAGUID? Do platform authenticators provide the ability to artificially set an AAGUID? Clearly I cannot zero out the AAGUID in the response since that would invalidate the signature.

and we should continue to only push for additional consent in the presence of attestation.

To be clear, you mean "push for additional consent in the presence of attestation for roaming authenticators", correct? By including the AAGUID, consent should not be asked for at all even in the presence of attestation for platform authenticators since it's not asked or respected in good faith (i.e., it's a façade):

• No attestation is requested and no consent is asked: AAGUID is included.
• Attestation is requested, consent is asked, consent is rejected: AAGUID is still included.

As a user, I have zero faith in the system since you are including AAGUID no matter what even when I explicitly do not give my consent. If you are suggesting that when consent is asked (due to attestation being requested) and subsequently rejected, AAGUID should not be included even for platform authenticators; then that's "proof" AAGUID is something a user should be able to control which in turn implies consent should always be requested even without attestation since AAGUID is involved.

The only way I could resolve any of this is if attestation is somehow more "revealing" than an AAGUID which I'm not sure I'm sold on since for many attestations the root CA certificate is publicly known and can likely be re-derived in the presence of an AAGUID at which point having the AAGUID essentially means having the attestation (from a privacy perspective).