Architecture
The layered stack
The five specs are not a menu, they are a stack. Each layer is only meaningful because the layer beneath it holds. Read this page to understand why the order matters.
How is trust turned into scoped access, safely?
How much should I trust it, and can I prove it offline, with cached keys?
Who is this agent, and is it really them?
OpenA2A AIM (Agent Identity Management), the reference platform for identity, ATX verification and runtime authorization.
Explore →Layer 1, Identity: who is this?
Everything starts with a name you can verify. did:opena2aprovides the name, a decentralized identifier that resolves, over HTTPS, to a DID Document containing the agent's public key; today the reference resolver returns the registry's signing key for every DID, not the agent's own key. AIP provides the proof: a challenge-response handshake where the agent signs a random nonce, so that claiming an identity and holding it are different acts.
Why identity must come first
Trust placed in an unverified name is worthless. If an agent can simply assert “I am acme/billing,” every trust signal above it can be spoofed. The signature over a fresh challenge is what makes the whole tower stand up.Layer 2, Trust: how much, and provably?
Once an identity is proven, the question becomes how much to trust it. ATX is the answer in physical form: a signed, self-contained credential, the TLS certificate for agents, that packages identity, scan results, capabilities and a behavioral profile, and expires after seven days. Critically, it is verified locally: a relying party checks the signatures against cached keys and a cached revocation list, with no authority on the request path once the cache is warm.
ATP is the protocol around that credential, how it is issued, distributed, revoked, and, above all, logged. Issuance and revocation events are appended to an RFC 6962 Merkle log; the Registry publishes signed tree heads and inclusion and consistency proofs that anyone can fetch and check; no monitor outside OpenA2A runs today. The tree is the same structure that underpins Certificate Transparency, and the act of trusting is itself made auditable.
Layer 3, Authorization: what may it touch?
Trust is not permission. A perfect, highly-trusted ATX says who an agent is and how it behaves, it is never, by itself, a key to your database. AAP is the layer that turns trust into scopedaccess, and it does so with one defining rule: the credential must never enter the agent's reasoning context. The agent emits an abstract grant:// reference; a local broker verifies the ATX, applies a default-deny policy, and runs the operation behind a trust boundary, returning only the result.
The trap this avoids
An agent that can read a secret can be talked into leaking it. By keeping the secret entirely behind the broker, even a fully hijacked agent can exfiltrate only a grant name and a result, nothing reusable.The spine, AIM, and where the rest runs
The five specs above are paper. OpenA2A AIM (Agent Identity Management) is the reference implementation for the identity and trust layers: the platform that mints keypairs and provider-scoped identifiers and verifies them (AIP), obtains and verifies the credentials the OpenA2A Registry issues (ATX), and keeps its own audit log and trust history. When a developer writes secure("my-agent"), AIM is what answers. The rest runs beside it: did:opena2a DIDs are minted and resolved, and the ATP trust authority and transparency log run, in the OpenA2A Registry; the AAP grant:// broker is a library in Secretless, not yet reachable from its shipped daemon, with AIM supplying the developer surface (@agent.perform_action) and 5-step fine-grained authorization.
The dependency, stated plainly
- Authorization is only safe because trust is verifiable.
- Trust is only meaningful because identity is proven.
- Identity is only useful because it is cryptographic, not asserted.
Remove any layer and the ones above it collapse into security theater. That is the whole argument for treating these as a stack rather than a grab-bag of features.