Start here
A five-minute orientation
If you read nothing else, read this page. It frames the problem, names the five specs, and gives you a reading order. Everything else is detail.
The one-sentence version
OpenA2A gives every AI agent a verifiable identity, a portable proof of trustworthiness, and a way to use credentials it can never actually see, re-using the cryptography that already secures the web.
The mental model
Think of an agent the way your browser thinks of a website. Before it trusts a site, it checks a certificate, signed by an authority, logged in public. OpenA2A is that same chain of reasoning, rebuilt for agents that act on your behalf.Why the web's existing tools aren't enough
Passwords identify people. TLS certificates identify servers. Neither was designed for software that reasons in natural language and can be persuaded. An agent can be talked into misusing access it legitimately holds, or into leaking a secret that sits in its context. So OpenA2A adds three things on top of familiar crypto:
- Identity that can be challenged, prove you hold the key, don't just claim a name.
- Trust that travels, a signed credential a verifier checks offline, in milliseconds.
- Authorization that withholds the secret, the agent gets the result of an action, never the credential behind it.
The five specs, in plain language
What is this agent called, and how do I look it up? A W3C DID method where did:opena2a:<type>:<id> resolves over HTTP to a signed DID Document, so any verifier can fetch an agent's public key and trust endpoints.
Which agent is this, what can it do, and should I trust it? An open standard for creating cryptographic agent identities, declaring capabilities, proving key possession via challenge-response, and computing a 9-factor trust score.
Can I verify this agent's trust offline, in milliseconds? A signed, self-contained, 7-day credential, the TLS certificate for agents, encoding identity, scan results, capabilities and behavior, verifiable locally with no callback to any authority.
How are trust statements issued, logged, audited and revoked? The protocol that issues, verifies, distributes and revokes trust assertions, recording every one in an RFC 6962 Merkle transparency log that anyone can audit.
How does an agent use a credential it must never see? An authorization layer where an agent emits an abstract grant:// reference and a local broker resolves scoped access, so no secret, token, or backend name ever enters the model's context.
Where do all these specs actually run? The reference platform that mints identities, issues credentials, runs 5-step authorization and keeps the audit trail, the working implementation of AIP, ATX, ATP, AAP and did:opena2a.
How can an agent be attacked, and is each threat real? A MITRE ATT&CK-style catalog of 61 techniques across 9 attacker tactics, each tagged by real-world evidence and mapped to detection checks, lab scenarios and controls.
How do tools detect injections and exposed AI infrastructure? An open, YARA-style detection-signature format for AI prompt injections and exposed agent infrastructure, shareable rules any scanner can run.
What behavior must an agent promise, and can we audit it? Defines what goes in an agent's SOUL.md governance file: 9 behavioral domains, 72 controls and 3 conformance levels. Also known as OASB-2 (behavioral domains 11-19).
Does a security tool actually catch agent attacks? 222 attack scenarios across 10 categories that measure a security tool's detection coverage against agent threats, ATT&CK-Evaluations style, mapped to MITRE ATLAS and OWASP.
How do you observe an agent's authorization decisions? Nine proposed OpenTelemetry attributes (agent.*, fga.*) that put agent identity, trust signals and authorization outcomes into standard traces, metrics and logs.
How they fit together, end to end
Here is the whole lifecycle of an agent that wants to read a database, told as one story. Each step belongs to one spec.
- 1did:opena2aThe agent gets a nameIdentity
It is registered and assigned a DID like did:opena2a:agent:acme/billing, an identifier that resolves to a public key.
- 2AIPIt proves the name is its ownIdentity
A verifier sends a random challenge; the agent signs it with its private key. Claiming a name and proving it are now different things.
- 3ATXIt receives a credentialTrust
At build time it is scanned and issued a signed, 7-day ATX credential that bundles its identity, scan results, capabilities and behavior.
- 4ATPThe credential is loggedTrust
Issuance is appended to a public, tamper-evident transparency log, so the act of trusting is itself auditable.
- 5ATXAnyone verifies it offlineTrust
A relying party checks the signature and expiry locally in ~2ms, no callback to any central server on the hot path.
- 6AAPIt’s granted scoped accessAuthorization
To read the database it emits grant://orders-db. A local broker verifies the ATX and resolves a scoped credential, which never enters the agent’s context.
- 7AIMAll of this actually runsImplementation
AIM is the reference platform that mints the identity, issues the ATX, enforces the 5-step authorization, and keeps the audit trail.
Suggested reading order
Follow the layers bottom-up: did:opena2a → AIP → ATX → ATP → AAP, then AIM to see it implemented. Prefer analogies? Jump to Mapped to PKI & the web.