Why passkey provenance matters for user management
Passkeys let users create multiple credentials for a single account, which is good for resilience: if one passkey is lost, another can still sign the user in. The trade-off is that account settings pages end up listing several passkeys, and users need a way to tell them apart when they want to rename or remove one.
Best practice for relying parties is to show supplementary metadata alongside each listed passkey, such as creation date or last-used date. But those dates alone often aren't enough for a user to recognise a credential at a glance. Letting users name passkeys at creation time is another option, though in practice many don't bother. Ideally the system should automatically generate a descriptive name.
Browsers expose a user agent string that can be used for this purpose, but on platforms like Android, iOS, or desktop browsers with extension support, third-party password managers can create passkeys too. In those cases the user agent doesn't reliably indicate who actually provisioned the credential. The solution is to look at the AAGUID in the credential data instead.
Reading AAGUID from the credential
The AAGUID is a unique identifier for the model of authenticator that created a credential — not the individual device, but the type. It travels inside the authenticator data portion of a public key credential during registration.
Because the AAGUID maps to a specific authenticator model, an RP can use it to determine which provider generated a given passkey. For example, a passkey created on Android via Google Password Manager comes back with the AAGUID "ea9b8d66-4d01-1d21-3ce4-b6b48cb575d4", and the relying party can annotate its passkey list accordingly.
Building the AAGUID-to-provider lookup
To translate an AAGUID into a readable provider name, an RP can consult a community maintained repository of AAGUIDs. That registry includes the provider name and an SVG icon data URI for each AAGUID on the list.
Most WebAuthn server libraries already surface the AAGUID after a registration ceremony. Here is an example of server-side registration code using SimpleWebAuthn:
// Import a list of AAGUIDs from a JSON file
import aaguids from './aaguids.json' with { type: 'json' };
...
// Use SimpleWebAuthn handy function to verify the registration request.
const { verified, registrationInfo } = await verifyRegistrationResponse({
response: credential,
expectedChallenge,
expectedOrigin,
expectedRPID,
requireUserVerification: false,
});
...
const { aaguid } = registrationInfo;
const provider_name = aaguids[aaguid]?.name || 'Unknown';
With the provider name in hand, an RP can improve its passkey management UX by labelling each entry with something like "Google Password Manager" instead of an opaque credential ID, making it much easier for users to identify the passkey they want to act on.
