Should your relying party request attestation at passkey registration, and what does verifying it buy?

## What attestation is At registration the authenticator can return, alongside the new public key, a signed statement about itself: this key was generated inside a device of this model, under these protections. That statement lives in the `attestationObject`, and the model is named by the `aaguid` in the attested credential data. What you ask for is set by the attestation conveyance preference in the creation options, and the choice is genuinely a judgment call rather than a security ratchet. | conveyance | what you receive | what you then owe | |---|---|---| | `none` | no statement worth verifying; the client may replace it and zero the `aaguid` | nothing | | `indirect` | a statement the client may have anonymised on the way through | a verification path, with weaker model certainty | | `direct` | the authenticator's own statement, as produced | per-format verification and a maintained trust store | | `enterprise` | a statement that may carry a unit-level identifier, where the platform permits it | all of the above, plus a policy for handling an identifier that follows a device | ## What a verified statement proves - **The model.** This key came from a device of the kind the `aaguid` names. - **That the key was generated there.** Not imported, not fabricated by software claiming to be that model. - **Nothing about the human.** Attestation is not user verification and not identity proofing. The person holding the authenticator is exactly as unknown as they were before. - **Nothing that persists.** A credential does not become revocable by you because you learned its model. ## What it costs 1. **A verification path per attestation statement format.** Each format has its own signature layout, its own certificate handling, and its own set of trust anchors. All of them must stay correct, because a verification path that fails open is worse than none - it produces a policy decision on evidence nobody checked. 2. **A trust store you have to maintain.** Authenticator metadata moves: new models appear, certificates roll over, some units get flagged. A trust store that was accurate at launch and never touched since silently degrades into a list that rejects new hardware and accepts revoked hardware. 3. **Privacy considerations.** An attestation certificate unique to one unit would make a device trackable across every site that asks, which is why authenticators commonly share one certificate across a large batch and why clients are permitted to anonymise the statement. 4. **A registration path that can now fail for reasons the skipper cannot fix.** A perfectly good roaming key from an unlisted model is turned away by a policy nobody remembers writing. ## The question that decides it **Do you have a decision that changes based on the model?** If the answer is no, the entire chain above is machinery feeding nothing, and the honest default is `none`. The answer is yes in a narrow set of cases: a regulated requirement that credentials sit on certified hardware; a managed fleet where the organisation issues the authenticators and wants to refuse anything else; an insurance or audit obligation that names the device class. All three share a shape - **someone outside engineering has written down which authenticators are acceptable**, and that document is what the trust store implements. For a quota reporting service whose skippers register whatever they own - the wheelhouse tablet's built-in authenticator, a roaming key in a dry bag, a phone in a waterproof pouch - there is no such document, and inventing one would reduce enrolment for no measurable gain. ## The trap in deferring the decision It is tempting to request `direct`, store the statement, and decide later. Two things spoil it. Storing an unverified statement and verifying it later means every existing registration was accepted on evidence nobody checked, so the policy you eventually write applies to nothing you already hold. And if you requested `none` the model evidence is not merely unverified, it is gone - the client may have replaced the statement and zeroed the `aaguid`, so the registration cannot be re-examined at all. The defensible positions are therefore the two ends: request `none` and accept that a model policy is permanently off the table for the credentials you already have, or request and verify properly from the first registration because you already know the policy exists. The middle - request it, store it, never verify it - gets you the cost of both and the benefit of neither.