Every time a user registers a passkey, something travels along with the passkey registration that is quite useful: a UUID that identifies exactly which type of password manager or security device created the credential.
That UUID is called an AAGUID. Here is what one looks like:
fbfc3007-154e-4ecc-8c0b-6e020557d7bd
This particular AAGUID means Apple Passwords, the password manager built into iPhone, iPad, and Mac. A different AAGUID would tell you it was, for example, a YubiKey, or Google Password Manager, Windows Hello or Proton Pass. The AAGUID travels with every passkey registration, and with the right lookup table, it turns a meaningless UUID into a human-readable name.
Let's jump into the details. Why they're useful, the great open source library that maps them to names, and how PlainKey uses them so your users get automatic, readable passkey labels without you writing any extra code.
What an AAGUID is
AAGUID stands for Authenticator Attestation GUID. "Authenticator" is the term for whatever creates and stores the passkey: your iPhone's built-in password manager, a YubiKey plugged into a laptop, Google Password Manager on Android, and so on. The AAGUID is a unique identifier for that authenticator's make and model: think of it as a product ID baked into every passkey the authenticator creates.
It is embedded in the attestation data that comes back from the browser's credentials API. But should you do anything with it? Yes, we think so.
A couple of things worth clarifying:
Every passkey from the same authenticator type shares the same AAGUID. Every credential created in Apple Passwords on any Apple device has the same AAGUID. It identifies the software or hardware model, not the individual device. The AAGUID for Apple Passwords is always fbfc3007-154e-4ecc-8c0b-6e020557d7bd.
Some authenticators send the zero AAGUID. 00000000-0000-0000-0000-000000000000 is a valid AAGUID that means "I am not telling you who I am." Some authenticators use this by choice. When you see it, there is nothing to look up and no way to determine the authenticator type.
The open source lookup list
A raw UUID is not useful on its own. To go from fbfc3007-154e-4ecc-8c0b-6e020557d7bd to "Apple Passwords", you need a lookup table.
The community-maintained passkey-authenticator-aaguids is a JSON file mapping AAGUIDs to human-readable names and optional icons. It is updated regularly as new authenticators come to market and covers over a thousand authenticators as of mid-2026.
The lookup list looks like this:
{
"fbfc3007-154e-4ecc-8c0b-6e020557d7bd": {
"name": "Apple Passwords",
"icon_light": "...",
"icon_dark": "..."
},
"ea9b8d66-4d01-1d21-3ce4-b6b48cb575d4": {
"name": "Google Password Manager",
"icon_light": "...",
"icon_dark": "..."
}
}
Using it in a backend is simple: at registration, extract the AAGUID from the response, look it up in the list, and store the resolved name alongside the credential. But remember, quite a few passkeys will have the zero AAGUID; in those cases you cannot identify the authenticator type.
Why this matters for your users
Consider a user who has registered three passkeys: one in Apple Passwords on their iPhone, one in LastPass on their laptop, and one on a YubiKey they carry as a backup. How you label these has a significant impact on whether the user can actually manage them. Note that a label is not an inherent part of passkeys, and not part of any spec. It is just a convenient way to identify the authenticator type for the user, typically in a user settings panel.
No labels. Many implementations show nothing useful: Imagine if you have registered three passkeys and the service only shows "Passkey" for all of them. You cannot tell which is which, and if you wanted to remove one of them - good luck guessing!
OS and browser labels. Some services record the browser and operating system at registration time, producing something like "macOS Chrome" as a label. However, this only tells the user when and where they happened to register, not what the passkey actually is. It could be that they actually stored their passkey in the 1Password password manager, and labeling the passkey "macOS Chrome" is then very misleading because they might as well be using that passkey on a Windows machine in Firefox the next day.
AAGUID labels. With a simple AAGUID lookup as your application registers a new passkey, the three anonymous passkeys could instead become "Apple Passwords", "Proton Pass", and "YubiKey 5 NFC". The user immediately knows what each one is. This is much more manageable and user friendly.
PlainKey handles labeling passkeys automatically from AAGUID's
PlainKey does the AAGUID lookup at the point of registration. When a user registers a passkey on your site, PlainKey resolves the AAGUID against a local copy of the community list and stores both the raw AAGUID and the resolved name on the credential (we call it the authenticator type).
That authenticator type name also becomes the initial label. A passkey created in Apple Passwords shows up in your credential list as "Apple Passwords", with no code on your part.
Users can rename their labels at any time (if you let them that is, using our APIs and SDKs) to something personal like "Work laptop" or "Spare key". But they start from something recognisable rather than a blank field.
Every credential PlainKey returns includes both fields:
{
id: "87e03816-41bc-4328-8b85-0f815d169fc2",
aaguid: "fbfc3007-154e-4ecc-8c0b-6e020557d7bd",
authenticatorType: "Apple Passwords", // resolved at registration, static
label: "Apple Passwords", // user-editable, you just use our API to let them update.
// ...
}
authenticatorType reflects what was resolved at registration and never changes. label is user-editable.
Getting started
If you are looking to add passkeys to your web app with automatic AAGUID lookup, PlainKey handles all the time-consuming stuff around passkeys for you. That includes credential storage, challenge generation, signature verification, and AAGUID lookup out of the box. You can start out for free for a small amount of passkey registrations, so it's easy to get started.