Skip to main content
Agent Identity

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

Agent2Agent (A2A) Protocol (A2A v1.0 (AAIF / Linux Foundation)) is Related protocol, v1.0 announced March 2026; donated to LF in 2025; joined AAIF 2026. 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

How A2A (Agent2Agent) works

Animated sequence · A2A

A2A — Is the Agent Card a login?

The card is a catalog, not a login

A2A is how agents talk: Agent Cards, skills, tasks. Fetch the card, read securitySchemes, then HTTP to the advertised endpoint. Authentication is declared on the card and obtained out of band. A signed card is tamper evidence, not a request credential. This is not AAuth p2p.

Client agentsends
Server agentgets
Enterprise AS

Now · 1/6· Discover· A2A v1.0You are here

Client agent→Server agent·GET /.well-known/agent-card.json — do not skip the card

The client fetches the Agent Card from the server agent. This GET is discovery, not login.

Why The card is how you learn the advertised URL, skills, and securitySchemes. Calling a guessed endpoint without reading the card is not A2A.

Take the catalog off the door before you try to order.

  • Agent Card from the spec
  • /.well-known/agent-card.json from the spec

Solid = from the spec

Step 1 of 6: client to server. GET /.well-known/agent-card.json — do not skip the card A2A v1.0
Speed
ShareLinkedInX

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. Fetch the card; read securitySchemes; call the advertised endpoint.

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.

Hop list

Sequence above; this list is the same hops for reading and search. Each row is one message.

  1. 1

    Client agent→Server agentA2A v1.0GET /.well-known/agent-card.json — do not skip the card

  2. 2

    Client agent→Client agentA2A v1.0Reads securitySchemes, skills, and the advertised endpoint URL

  3. 3

    Server agent→Client agentA2A v1.0Optional JWS on the card — wax seal on the catalog, not a login

  4. 4

    Client agent→Enterprise ASOAuth 2.1If the card says OAuth/OIDC, obtain a token out of band

  5. 5

    Client agent→Server agentA2A v1.0HTTP to the advertised endpoint: authenticated A2A operation + A2A-Version

  6. 6

    Server agent→Client agentA2A v1.0Server agent handles the task and responds

01

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.

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. did:peer is a third meaning.

02

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.

03

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.

04

Step-by-step flows

Flow 1

Discover, authenticate out of band, task

  1. 1

    Client GETs /.well-known/agent-card.json. Optionally verifies JWS.

  2. 2

    Client selects a security scheme from the card (e.g. OAuth authorization code or mTLS).

  3. 3

    Out of band: obtain the credential (OAuth 2.1 at oauth2MetadataUrl, present a cert, …).

  4. 4

    Client calls a supported interface with A2A-Version and the credential.

  5. 5

    Optional: Get Extended Agent Card once authenticated; replace the cached public card for this session.

  6. 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.

05

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.

06

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.

07

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.

08

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.

Related

Specs

Deployment patterns

Flows

Compare

Primary sources