AAGUID 查询

What an AAGUID is

When an authenticator creates a passkey, the authenticator data of the registration carries a 16-byte AAGUID — the Authenticator Attestation GUID that names the model, not the device: every YubiKey 5 with the same firmware reports the same value (WebAuthn Level 3, §6.5.1). Passkey providers that sync credentials, such as password managers and platform authenticators, often report an AAGUID of their own too, and an authenticator that does not want to identify itself reports all zeros — which is also what browsers send whenever the relying party asks for attestation "none". Older U2F security keys have no AAGUID; they are identified by the key identifier of their attestation certificate — a forty-digit hex value this page does not send, since it cannot be told apart from a secret — and UAF authenticators by an AAID of the form xxxx#xxxx, which the lookup accepts. Search U2F keys by model name instead.

An AAGUID on its own is a claim. Only an attestation statement whose certificate chains to the vendor's root proves that the response came from that model; the WebAuthn inspector verifies the statement, and the roots it must chain to are exactly what this lookup returns.

The FIDO Metadata Service

The FIDO Alliance publishes one signed document — the metadata BLOB — with an entry for every authenticator its vendors registered: the FIDO Metadata Service 3, specified in FIDO Metadata Service v3.1. Each entry holds a metadata statement — the model's name in several languages, its icon, the protocol family and firmware version, the attestation types it produces, how it protects keys and how it connects — the attestation root certificates its attestations chain to, and a list of status reports.

The status reports are the part to act on. FIDO_CERTIFIED_L1, L2 and their plus variants record the certification level reached; UPDATE_AVAILABLE says newer firmware fixes a problem; and the compromise statuses — USER_VERIFICATION_BYPASS, ATTESTATION_KEY_COMPROMISE, USER_KEY_REMOTE_COMPROMISE, USER_KEY_PHYSICAL_COMPROMISE and REVOKED — mean authenticators of the affected versions must no longer be trusted. A relying party that enforces an authenticator policy is expected to check the current status at every registration.

How the BLOB is verified

The BLOB is a JSON Web Token of about ten megabytes. Before a single entry is shown, it is checked the way the Metadata Service specification prescribes for relying parties (§3.1.7): the JWS signature against the signing certificate in its header; that certificate's chain up to GlobalSign Root CA - R3, a root built into the site rather than downloaded; the certificate revocation lists of every certificate in that chain; and the BLOB's serial number and nextUpdate date. A BLOB that fails any step is not used at all.

The download happens on our server, from the Metadata Service's own address and through the same guarded path every server-side download on this site uses, and the verified BLOB is kept in memory until its nextUpdate day — never longer than a day, because the Alliance reissues it whenever a status report changes. Answers for one authenticator are cached under the BLOB's serial number, so a new BLOB means fresh answers. The BLOB itself is not stored or redistributed: the Metadata Service's terms of use bind whoever downloads it, and they are shown with every result.

What the lookup cannot tell you

Not every authenticator is registered. Many passkey providers and platform authenticators are absent from the Metadata Service, so "not found" is common and says nothing bad about the model. Certification is voluntary, too: an entry may describe an authenticator that was never certified. And the metadata describes a model, not the response in front of you — whether that response really comes from such an authenticator is decided by verifying its attestation statement against the roots listed here.