An A2A Agent Card helps you shortlist an agent, not approve it

Decide what the card actually establishes

Suppose a remote agent advertises document summarization. Its card lists an interface and carries a signature. That is enough to investigate a possible integration; it is not enough to send production documents. The A2A definition describes an Agent Card as a manifest of identity, capabilities, skills, communication methods and security requirements. It calls skills a largely descriptive concept.[1]

Keep five questions separate: where to find the card, whether the declared interface fits your client, whose key authenticates the metadata, what your client is permitted to see, and whether the agent can do the intended work. Signing addresses metadata integrity; authenticated extended-card access controls disclosure to the client.[2] The workload decision needs evidence beyond those mechanisms.

Choose discovery for the relationship you have

A2A lists well-known URLs, registries and direct configuration as ways to find cards.[2] Extended access and signing are separate controls: a privately configured card can be signed, and a well-known endpoint can require authentication.[2][3]

Servers must make a card available; that does not require every card to be anonymously exposed at the well-known URL.[2][3] For a fixed known counterparty, direct private configuration can be sufficient. It avoids a catalog but leaves updates and reconfiguration to the integration. A registry helps when candidates change, at the cost of registry maintenance and policies that need their own scrutiny.[3] Neither route is intrinsically more trustworthy.

Signing is optional in A2A, although clients SHOULD verify at least one signature before trusting a card.[2] A consumer can impose a stricter signature requirement as its own policy. An unsigned card is not automatically nonconforming, and a private address is not automatically trusted.

Check the interface layout before constructing a request

The pinned definition requires name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes and skills; required arrays must be nonempty.[1][2] Provider details and signatures are not required top-level fields.[1] These are contract requirements, not evidence that any selected server implements them correctly.

Use the ordered supportedInterfaces list to select the first transport your client supports, then use that entry's URL. Each entry declares url, protocolBinding and protocolVersion.[1][2] AgentCard.version is the agent version, not the interface's A2A protocol version.[1] If the selected interface sets tenant, copy it exactly into requests; omit it when absent.[2] The definition describes tenant as a routing identifier, not an authorization credential.[1]

The migration guide names capabilities.extendedAgentCard and GetExtendedAgentCard as the current counterparts of supportsAuthenticatedExtendedCard and agent/getAuthenticatedExtendedCard; protocolVersion now belongs to each interface.[5] Do not build a current request from an older tutorial's top-level fields.

One source inconsistency matters for authentication: extended-card prose refers to AgentCard.security, while the pinned definition and rendered table define securitySchemes and securityRequirements.[1][2][4] Use the defined fields when describing the card, and confirm the selected implementation's authentication contract rather than inventing a security field.

Verify the metadata and establish whose key it is

A2A signs a canonical representation of the card using JSON Web Signature (JWS). It requires RFC 8785 JSON canonicalization after field-presence handling and excludes signatures from the payload.[2] This is not a recipe to delete every false or empty value. Unset optional fields are omitted; explicitly set optional defaults and required fields are retained; other default-valued fields are omitted.[2] The source example retains explicitly present streaming: false and pushNotifications: false while omitting empty non-required extensions.[2]

The signature object requires protected and signature strings and permits an unprotected header.[1] In the protected header, kid identifies a key and jku may locate a JSON Web Key Set. A2A recommends secure key retrieval, permits a trusted key store and multiple signatures for rotation, and forbids expired or revoked keys for verification.[2] Those rules do not establish a universal deployed revocation service.

RFC 7515 requires the key-management technique to authenticate the public key's origin; otherwise, the signer is unknown.[6] If the only basis for accepting a key is the candidate's own jku, a successful cryptographic check establishes a match to that key, not an independently approved business identity. Integration policy should establish the expected provider-to-key binding through an independently trusted channel or an existing approved record. HTTPS key retrieval does not itself decide whether that domain is the intended counterparty.

A signature does not conceal card contents or establish freshness or successful skill execution.[1][2][6] This analysis performed no cryptographic check. A supplied signature, or an abbreviated signature in documentation, must not be reported as a completed verification.

Keep extended metadata within the client's permission scope

When capabilities.extendedAgentCard is true, GetExtendedAgentCard can return a complete AgentCard, not a patch. It MUST require authentication and validate permissions before disclosing privileged information; content may differ by client identity or authorization level.[2] The HTTP binding is GET /extendedAgentCard, with /{tenant}/extendedAgentCard as an additional binding. The request message has an optional tenant routing field, not an embedded credential field.[1] Use the selected interface's binding and base URL rather than guessing an endpoint.

Restricted access is not a safe place to put secrets. The normative guidance says extended cards SHOULD NOT contain exploitable sensitive information such as internal service URLs or unmasked credentials.[2] More metadata describes what a client may discover; it does not certify the remote agent's quality.

General card caching uses SHOULD-level guidance for HTTP Cache-Control, ETag and conditional requests, without a universal cache lifetime. Extended-card replacement is SHOULD-level guidance for the authenticated session or until the card version changes, alongside invalidation guidance.[2]

For an integration, confirm that cached metadata remain within the authenticated identity, authorization and relevant tenant boundaries. Re-evaluate or invalidate copies when those boundaries or the relevant version change. One client's privileged response should not become a shared anonymous cache. This is a proposed scope check, not an A2A requirement for a particular private, no-store or Vary header recipe. An ETag match does not establish provider identity.

Completed hypothetical: choose a first evaluation candidate

Hypothetical, unexecuted example. An integration owner needs a summary of a non-sensitive supplier document, with source references a human can check. Every candidate property below is a scenario assumption. No card was retrieved, signature verified, authenticated session opened or document sent.

B gets the first evaluation slot because of the assumed independent relationship evidence, not its private location or richer card. A can return to the shortlist once the expected provider/key binding is established and the current card is successfully verified under that accepted key. That still would not approve A for production.

The choice can reverse if A gains equivalent identity evidence while B lacks a compatible interface or cannot contain metadata within the permitted scope. For either candidate, the next workload evaluation would check whether summary claims trace back to the supplied document and whether unsupported claims or material omissions occur. Suitable permissions and data/service terms also remain necessary. These are proposed criteria; no evaluation or success rate is reported here.

Separate the shortlist decision from production adoption

• Choose a discovery route that fits the relationship: direct configuration for a fixed counterparty, broader discovery for changing candidates. Identify who maintains updates.
• Record the selected interface URL, binding, protocol version, tenant when present, declared skill and media types. Confirm compatibility rather than treating a version label as conformance evidence.
• Establish the intended provider independently. If using signatures, require an accepted key origin, the actual verification result and a way to handle key rotation, expiration or revocation.
• Confirm which identity may retrieve and use extended metadata, and how cached copies stay within that identity's permissions and relevant tenant scope.
• Require separately authorized evidence for the intended workload and applicable privacy/service terms before production. Keep candidates on hold when identity or permission evidence is missing.

The recommendation should change with concrete evidence: a trusted provider/key binding can remove an identity hold; an incompatible interface can remove a candidate; inadequate permission or cache separation can block privileged use; relevant workload results can support or reject adoption. A registry with documented admission and refresh policies may be more useful than static configuration when the candidate set changes.

The documentary sources establish no deployed SDK or card compliance, registry interoperability or prevalence, workload performance, price or customer outcome. They also do not measure whether this selection process reduces risk. Use the card to narrow the search, then obtain the separate evidence required for the decision you are about to make.