Expose AAGUID of non-attested Passkey

[bdash]

Is your feature request related to a problem? Please describe. It's desirable for a web service to be able to give a meaningful default name to a passkey that a user registers (https://web.dev/articles/webauthn-aaguid). Many authenticators provide their AAGUID for this purpose, even when the RP does not request authentication. When combined with the data from https://github.com/passkeydeveloper/passkey-authenticator-aaguids, this allows a service to label a passkey with a meaningful name, such as "iCloud Keychain" or "Chrome on Mac" . This makes it easier for a user to manage multiple passkey registrations.

Describe the solution you'd like Add pub aaguid: Aaguid, to Passkey.

It might need a scary comment warning that it should only be used for informational purposes, and that attestation should be used if it is necessary to verify the type of authenticator being used.

Describe alternatives you've considered You can presumably get this if you use attestation, but I have no need for attestation.

Additional context Add any other context or screenshots about the feature request here.

[Firstyear]

Non-attested passkeys don't provide an AAGUID so we have nothing to expose here (in fact, browsers actually strip it when they perform nav.cred.get() ). There is a w3c issue for this here https://github.com/w3c/webauthn/issues/2157 and I think there was another one somewhere, but I can't find it right now.

[bdash]

Both Chrome and Safari return a valid AAGUID when a platform authenticator is used even if no attestation is requested. Chrome has been doing this for many years now (https://issues.chromium.org/issues/40599384) and Safari followed suit a couple of years ago (https://github.com/WebKit/WebKit/commit/711e9d271fec39992f5febf9d1968fe45b1a955d).

[micolous]

Yeah, this is about get, not create. create gets it from authdata. However, this is all a big mess.

Chromium Touch ID

Chromium has two different AAGUIDs for Touch ID, one for Chrome, and one for others:

https://source.chromium.org/chromium/chromium/src/+/main:device/fido/mac/util.mm;l=42-49;drc=eb870ca623bbf44ab46971ba32851e7b3234771a

There's also two paths with Chromium's Touch ID support:

• the original Chromium applet which runs on the security co-processor, stored locally
• macOS platform WebAuthn APIs, stored in iCloud Keychain

It's not clear to me which one this AAGUID is for... it smells like it could be both.

From a user experience perspective, you could say it's "Touch ID", but then if a user registered a credential with Touch ID in Chrome using its applet (rather than platform APIs), they couldn't then use that to sign in with Safari on the same machine.

There's also Google Password Manager, which is a synchronised credential manager.

Use cases for AAGUIDs

There's two use cases for an AAGUID:

• "The RP wants to be able to identify the user's authenticator, so they can label it for the user."

  This feels like it would be better served by authenticatorDisplayName, but this was removed from the spec in favour of the AAGUID.

  An RP could have a registration ceremony which prompts the user to label their security key. This allows the user to give it a more meaningful name, like "Alice's keychain" or "backup key", instead of "Security Key by Yubico NFC".

  This also helps for cases like:

  • A user has more than one authenticator of the same model
  • A user has an authenticator which shares the AAGUID with another authenticator (eg: some Token2 authenticators are rebadged Feitian authenticators, and many authenticators models share AAGUID even when offering different transports and form factors)
  • A user enrols multiple credentials in a synchronised credential manager, one for their own use, and one which is in a shared store.

  In short, while pre-filling labels is nice-to-have, relying on the AAGUID alone can result in nonsense.

• "The RP wants to be able to identify the user's authenticator, so that they can check the model against an allow / deny list."

  For example, an organisation may require that authenticators meet a particular security certification criteria, or from particular manufacturers (eg: if they are centrally issued to employees).

  The only way to do that securely is with attestation.

  Providing a non-attested path to get the AAGUID risks a library user consuming the non-attested path in a security-sensitive context. webauthn-rs tries to avoid offering these sorts of dangerous APIs.

  An RP might try to use the AAGUID to enforce the use of a particular synchronised credential manager. That is not possible to attest cryptographically (so doesn't really restrict anything), and is more of a nuisance to the user.

The "community-driven list of AAGUIDs" is pretty damning, and I think makes a good case for restoring the authenticatorDisplayName parameter:

• no need to maintain a database of synchronised credential managers - new software works straight away
• no need to need RPs to update their lists
• as it's provided by the browser/platform, it handles user language preferences automatically
• clearly intended for "display" and not usable in a security-critical context

I've noted my thoughts on the WebAuthn issue tracker. But otherwise, I think using AAGUIDs is a lot of work for marginal gain.