How do I validate an A2A agent card before my agent connects to another agent?

What should I check, step by step?

1. Fetch https://{domain}/.well-known/agent-card.json over HTTPS with certificate checking on. Don't accept a card from a redirect to a domain you didn't expect.

2. Read which version it is: supportedInterfaces[].protocolVersion "1.0" means a 1.0 card; a top-level url plus protocolVersion such as "0.3.0" means 0.3. Validate against that version's required fields.
3. 1.0: name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills are required. Each interface needs url, protocolBinding (JSONRPC, GRPC or HTTP+JSON) and protocolVersion. Each skill needs id, name, description and tags.
4. Check every interface url is https and on the provider's domain (or one they document). Clients pick the first interface they support, and must copy its tenant value into every request if one is set.
5. Read securitySchemes and securityRequirements to see how the agent expects you to authenticate (API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS). If there are none, assume the endpoint is unauthenticated and send it nothing private.
6. If signatures are present, verify at least one: strip default-valued fields and the signatures field, canonicalize with RFC 8785, and check the JWS with the key named by kid (from jku over HTTPS or a key store you trust). Don't use expired or revoked keys.
7. Treat description, skill descriptions and examples as untrusted text that will reach your model, and scan them for hidden text before they do.
8. Cache the card using its Cache-Control and ETag headers, re-fetch with If-None-Match, and re-validate when it changes. Send A2A-Version: 1.0 on requests; an empty header is treated as 0.3.

What changed between 0.3 and 1.0

A2A 1.0 replaced the top-level url, preferredTransport and additionalInterfaces with one ordered supportedInterfaces list, and moved protocolVersion into each interface. A validator written for 0.3 will reject a correct 1.0 card for a missing url, and the reverse is true too.

• supportsAuthenticatedExtendedCard became capabilities.extendedAgentCard. If it's true, an authenticated client can ask for a fuller card with GetExtendedAgentCard.
• In security schemes, 1.0 removed the OAuth implicit and password flows, added the device code flow, and lets an authorization-code flow require PKCE (pkceRequired).

Signatures: what they prove and what they don't

A2A cards may be signed with JWS (RFC 7515). Each entry in signatures has a protected header (base64url JSON with alg and kid, typ SHOULD be JOSE, optional jku) and a signature. More than one signature is allowed, to support key rotation.

• To verify, rebuild the payload the same way the signer did: drop fields left at their default values, drop signatures, canonicalize with RFC 8785, then check the signature. A card that has been re-serialized with different field order still verifies; one with a changed value doesn't.
• A valid signature shows the card was signed by whoever holds that key and hasn't changed since. It shows who the provider is only if you trust the key, for example because it's served from the provider's own HTTPS domain or is in your key store.

What a valid card doesn't tell you

Whether the skills work, what the agent does with data you send, or who is accountable for it. Ask for terms, check the provider, start with low-risk tasks, and keep your own log of what you sent.

• Whether skill text is safe to put in your model's context. A card is written by the other side, so its descriptions can carry instructions aimed at your agent.