What an AID proves — and what it doesn't

Five minutes. Read this before you copy a middleware.

An AID is a signed statement by a registry. When you verify one and it comes back valid, you have learned exactly three things, and nothing more.

What it proves

1. A registry countersigned some verification facts at a date. The signature (both halves of it, §5.1) says: this registry, with this key, issued this document at validFrom. The facts inside are the ones the registry checked at that moment, and no others.
2. The credential is not revoked — to the age of the evidence you accept. The status list (H4) tells you whether the registry has set the revocation bit. That answer is only as fresh as your last fetch; the protocol's floor is 60 seconds, and your policy sets the rest (§8, fresh=).
3. The level derived from those facts. trustLevel is not declared by the agent; it is recalculated from what was verified (§2). At L0 that means: a person we did not verify, representing an entity we did not confirm.

What it does not prove

• That whoever presents it controls it. An AID is a public document. Anyone can fetch anyone's from GET /v1/aids/{did} and present it to you. Proving control is the holder proof over a receiver challenge (ATP/1 step 2), and the challenge endpoint is not enabled yet. Until it is, verification identifies the credential, not the caller.
• How the agent will behave. An AID states what was verified, how, against which source and when. It never guarantees present or future conduct (DPV-02).
• Anything about the organization at L0 or L1. legalName is self-declared until L2. The SDK exposes this as principal.verificationStatus; treat "self-declared" as a label the holder typed.
• Anything a receiver did not ask for. No scope check, no intent, no policy — those are ATP's job, not the credential's.

The holder proof is in deployment: the challenge endpoint returns 503 today. Follow it at /planned#challenge-endpoint.

The one sentence to keep

Identification is not authorization. A valid AID lets you say which agent a request claims to be, log it, rate it, route it. To decide whether it may do something, you need the holder proof and your own admission policy — that is the Agent Trust Protocol (/protocol, normative in §8).

Next: How verification works · Verify a credential offline · Publish your admission policy