AAIF · v1.0 announced March 2026; donated to LF in 2025; joined AAIF 2026

Agent2Agent (A2A) Protocol

A2A v1.0 (AAIF / Linux Foundation)

Related protocolVendor / protocol (not an RFC)Identity + Authn + AuthzAgent-specificField guide

If someone says 'p2p' meaning agent-to-agent communication, they often mean A2A. If they say 'p2p' next to AAuth, they more often mean AAuth's two-party / identity-based mode (no AS). Both uses appear in the wild — this site treats them as distinct.

At a glance

Problem: Independent agents, built on different stacks, need a common way to discover skills, authenticate, delegate tasks, and exchange results across organizational boundaries.
Identity / authn / authz: Communication protocol with declared authentication schemes. Identity of an agent is the Agent Card (optionally signed). Request authentication is ordinary HTTP schemes (API key, Basic/Bearer, OAuth 2.0, OIDC, mTLS) advertised on the card — A2A does not replace OAuth or AAuth.

Actors

A2A client agent
A2A server agent
Optional enterprise AS

In one board · A2A

The card is a catalog, not a login

Server agent
→ Publishes skills + securitySchemes →
/.well-known/agent-card.json
Client agent
→ Whatever the card advertised →
Server agent

Agent Card

Optional JWS is a wax seal on the catalog — tamper evidence. It does not authenticate the next JSON-RPC call.

OAuth / mTLS / API key

Request auth is ordinary HTTP, obtained however securitySchemes says. Often a Bearer pass from some AS.

Wrong cousins: AAuth identity-based p2p (signed HTTP, no Agent Card) and did:peer (pairwise, not globally fetched). A2A §7.6.3 — do not forward caller credentials in-band down the chain.

A2A v1.0 is a task protocol (AAIF / Linux Foundation), not an RFC. Auth is out of band relative to the task messages. Four doors.

The gap for agents

Independent agents, built on different stacks, need a common way to discover skills, authenticate, delegate tasks, and exchange results across organizational boundaries. A2A v1.0 (AAIF / Linux Foundation; v1.0 announced March 2026) is that task protocol. It is not an identity protocol and not AAuth.

Actors and trust boundaries

A2A client agent and A2A server agent. Identity of an agent is the Agent Card (optionally signed JWS with RFC 8785 canonicalization) — tamper evidence of the card, not request authentication. Request authentication is ordinary HTTP schemes advertised on the card (API key, Basic/Bearer, OAuth 2.0, OIDC, mTLS). Credentials are obtained out of band unless an extension negotiates in-band — and in-band credential exchange across chains of A2A agents exposes those credentials to each hop.

Authorization models are agent-defined (user, role, project, tenant, custom). The protocol requires that list/get/cancel operations be scoped to the authenticated caller; it does not prescribe the model. Extended Agent Cards are only after authentication and MUST NOT leak extra skills to anonymous callers.

Mechanics

Server publishes /.well-known/agent-card.json. Card fields include identity, skills, supportedInterfaces, securitySchemes / security (OpenAPI-shaped: apiKey, http, oauth2, openIdConnect, mutualTLS). OAuth2SecurityScheme has flows (authorizationCode, clientCredentials, implicit and password deprecated, deviceCode) and optional oauth2MetadataUrl (RFC 8414, TLS required). Client picks a supported interface, sends A2A-Version, authenticates with a declared scheme, then tasks over JSON-RPC, gRPC, or HTTP+JSON.

Get Extended Agent Card requires authentication using a public-card scheme. In-task authorization can pause a task (TASK_STATE_AUTH_REQUIRED) for out-of-band credentials. Implicit and password OAuth flows are deprecated on the card.

Agent Card (/.well-known/agent-card.json)from spec: Quoted: JSON metadata — identity, skills, interfaces, securitySchemes. Optional JWS is card integrity, not request auth.
securitySchemes / OAuth2SecuritySchemefrom spec: Quoted: HTTP schemes plus OAuth2/OIDC/mTLS. oauth2MetadataUrl is RFC 8414. implicit and password flows deprecated.
A2A-Versionfrom spec: Quoted protocol version header using Major.Minor (e.g. 1.0). Patch numbers MUST NOT drive negotiation.

Step-by-step flows

Flow 1

Discover, authenticate out of band, task

1
Client GETs /.well-known/agent-card.json. Optionally verifies JWS.
2
Client selects a security scheme from the card (e.g. OAuth authorization code or mTLS).
3
Out of band: obtain the credential (OAuth 2.1 at oauth2MetadataUrl, present a cert, …).
4
Client calls a supported interface with A2A-Version and the credential.
5
Optional: Get Extended Agent Card once authenticated; replace the cached public card for this session.
6
Tasks flow. List/Get/Cancel MUST be scoped to this caller. If AUTH_REQUIRED, obtain more credentials out of band (or via a negotiated extension).

Do not confuse this with AAuth identity-based access: A2A still often uses OAuth client-credentials bearer tokens. Do not confuse it with did:peer: there is no pairwise DID here unless you layer one yourself.

Identity vs authentication vs authorization

Communication protocol with declared authentication schemes. Identity of an agent is the card URL/contents (and optional signature). Authentication is the HTTP scheme on the request. Authorization is the server agent's own model plus whatever the OAuth token encoded. A2A does not replace OAuth, OIDC, AAuth, or WIMSE.

How it composes

OAuth 2.0
Card-advertised OAuth. Obtain tokens however the flow says, then attach them.
OAuth 2.1
Do not use the card's deprecated implicit/password flows; use code+PKCE or client credentials.
OpenID Connect Core
openIdConnect security scheme on the card.
mTLS sender-constrained tokens
mutualTLS scheme on the card.
MCP authorization
MCP is host-to-tool OAuth; A2A is agent-to-agent tasks. An A2A server might also be an MCP server; the auth stacks can coexist.
AAuth
AAuth could theoretically be a custom security scheme, but v1.0 does not define one. Different problem (HTTP caller identity vs task protocol).
Transaction Tokens
Not in v1.0. Usage profiles exist as separate I-Ds.
did:peer
Different p2p: pairwise DIDs, not Agent Cards.

What bites agent implementers

Signed card ≠ authenticated request
A valid JWS on the card proves the card was not tampered with. Every request still needs a scheme from securitySchemes.
In-band credentials across hops
Section 7.6.3 warns that in-band credential exchange can pass secrets through every A2A agent in a chain. Prefer out-of-band.
Authorization scoping
List Tasks MUST NOT leak other callers' tasks. Check authz before queries that would reveal existence.
Deprecated OAuth flows on cards
If a card still advertises implicit or password, do not use them. That is RFC 9700 plus the A2A schema's own deprecation.

Stability — what you can ship

A2A v1.0 is the first stable spec (announced March 2026), donated to the Linux Foundation (2025) and under AAIF (2026). Not an RFC. v0.3 remains relevant for migration. IBM's Agent Communication Protocol merged into A2A (August 2025). https://a2a-protocol.org/v1.0.0/specification/

Catalog claims (short form)

Agent Card: JSON metadata: identity, skills, interfaces, securitySchemes. Signing is tamper evidence, not request auth.

Implementer notes

v1.0 is the first stable spec; v0.3 remains relevant for migration. IBM's Agent Communication Protocol merged into A2A (August 2025). Auth is out-of-band relative to task messages: obtain the OAuth token however your scheme says, then attach it. Do not confuse A2A with AAuth; one is how agents talk, the other is how HTTP callers prove identity and get grants.

Relationship to others

Primary sources

A2A v1.0 specificationhttps://a2a-protocol.org/v1.0.0/specification/
AAIF project pagehttps://aaif.io/projects/agent2agent