Re: [webauthn] Add AAGUID to credProps (#2157)

I don't think this is a good idea.

If the goal for an RP to be able to label which synchronised credential manager or hardware authenticator the user has enrolled in a key management UI, then `authenticatorDisplayName` ([which was removed from the spec](https://github.com/w3c/webauthn/issues/2187)) is much simpler and safer.

With a display name attribute, there RPs do not need to resort to [unofficial "community-driven" lists of synchronised credential managers](https://github.com/passkeydeveloper/passkey-authenticator-aaguids) (and keep them updated) or deal with AAGUID re-use by hardware authenticators[^1].

Passing AAGUIDs over non-attested channels is an unsafe interface, because an RP could erroneously check as authenticator against an AAGUID allow/deny list _without_ cryptographic verification. As synchronised credential managers typically lack attestation, there is no way to safely set up an allow/deny list which _also_ allows them.

By comparison, a display name attribute has clear intent - that it's for display, not security-critical purposes.

A synchronised credential manager could also add some free-text metadata to the display name, such as the name of the vault the credential is stored in.

However, an RP _should_ allow a user to add arbitrary labels for their registered credentials its UI. That way, the user can give it a name which is meaningful to them, like "work laptop dock", "my keychain" or "backup key in safe" instead of being stuck with "Security Key by AuthenticatorCo® NFC Biotronic® FIPS Edition".

[^1]: There are certified hardware authenticators in the FIDO MDS where vendors use the same AAGUID for multiple models of keys (eg: one with USB only, one with USB + NFC, one with USB + BTLE) and even rebadge other vendors' keys without changing the AAGUID.

-- 
GitHub Notification of comment by micolous
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2157#issuecomment-3055222263 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 July 2025 03:28:14 UTC