Glossary · Verification

Resolution envelope

Q: How do I request the JSON instead of the HTML card?

Send Accept: application/json to https://www.agenid.com/a/ . An unknown identifier returns 404 agent_not_found as JSON.

Updated 2026-09-23

Every AgenID identifier resolves at https://www.agenid.com/a/<agenid>. Browsers receive a Verification Card; a client that sends Accept: application/json receives the resolution envelope, the machine-readable form of the same resource.

The envelope is built to be checked, not believed. It includes the proof check result, a check for each assertion, the highest level that is currently valid, and pointers to both places the operator's key can be fetched.

Definition

The resolution envelope is the canonical JSON document AgenID returns for an agent identifier: the manifest, its operator-signed ManifestProof, per-assertion checks, the highest currently-valid level and key-discovery pointers, packaged so a verifier can re-check everything offline.

Also known as: AgenID envelope, canonical resolution response

How it relates to AgenID

The envelope is the resolver's output in the protocol. A verifier recomputes the manifest digest, confirms the ManifestProof binds it, and re-runs the Ed25519 check over RFC 8785 canonical bytes. The registry cannot forge an operator signature, so a tampered envelope fails that check.

Identifiers have the shape of the spec's example, agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y. Paste any registered identifier into /verify to see its envelope checked.

The key-discovery pointers name both sources for the operator key: the registry copy at GET https://www.agenid.com/v1/keys/<key-ulid> and the operator's own /.well-known/agenid/keys.json.

Why it matters

A registry that only returns an answer asks you to trust it. The envelope moves the decision to the verifier: a service can compute the level itself from the checks that passed instead of taking a field on faith.

The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet.

What it does not mean

A valid envelope says which operator key signed which statements about which agent. It does not say those statements are true, and it does not say what the agent is allowed to do. Identity and permission are separate questions.

Frequently asked questions

How do I request the JSON instead of the HTML card?

Send Accept: application/json to https://www.agenid.com/a/<agenid>. An unknown identifier returns 404 agent_not_found as JSON.

Can I verify an envelope without contacting AgenID again?

Yes. After fetching it once, the signature and digest checks run offline. Fetching the operator's key from its own domain is the one further step.

Should I trust the level field?

Treat it as a convenience. Compute the level yourself from the assertions that verified.

What agenid.com issues today

The reference deployment at agenid.com issues DECLARED and L1_REGISTERED only. L2_DOMAIN_VERIFIED and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved by the specification and is not issuable at all.

Identity is not permission

Which agent is acting and who declared it is one question. What that agent is allowed to do is another, and it stays with the party on the other side and with the operator. Protocol v1.1.1 defines no signed authorization object.

how-it-works

How it works: scenarios