Is your feature request related to a problem? Please describe.

There is no means to verify the integrity of an AgentCard. It is not possible for a party to attest to the content of an AgentCard.

Consumers of AgentCards may require the ability to know that an AgentCard is unchanged from when it was retrieved from a particular source, such as from a registry.

Consumers of AgentCards may require that AgentCards are vetted by a trusted source.

Describe the solution you'd like

Allow AgentCards to contain signatures. This allows consumers to verify that the content of an AgentCard is unchanged since the signature was added. Signatures should be presented in a well-known format: I propose JSON Web Signatures (JWS). This allows verifiers to leverage pre-existing libraries for performing verification.

Signatures should cover the content of the AgentCard and also be contained by the AgentCard. That is, an AgentCard should get signatures field that contains a list of signatures. This allows the AgentCard to be passed around as a single document that includes information sufficient to verify the integrity.

For a more complete description of the solution, see: #199 (comment)

Describe alternatives you've considered

• Signatures via HTTP headers: there exists a standard for HTTP message signing. This could be used to return signatures for an AgentCard when served by an AgentCard endpoint. However, the signatures are not then contained within the AgentCard data and are tied to the transport mechanism (HTTP). We'd prefer a self-contained solution.

• Out-of-band signing: we could define a separate process for retrieving signatures of an AgentCard. This could be protocol-defined, where verifiers understand the specific means of retrieving known signatures for an AgentCard, such as from the rekor ledger offered by Sigstore. This allows great flexibility, but increases the burden on verifiers to understand external systems.

• AgentCard JWTs: rather than attaching signatures to an AgentCard, we could instead treat an AgentCard as a JWT. This format is similar to the proposal, however it inverts the relationship between AgentCard and signature: rather than an AgentCard containing a signature, the JWT contains the AgentCard. This eliminates the need to define a specialized process for producing signing input, however it bifurcates the serving format for signed and unsigned AgentCards. This means every consumer must concern themselves with whether an AgentCard is served as a JSON payload or as a JWT -- we either introduce a separate means of serving AgentCard JWTs, which increases the surface area of the protocol, or we require every implementer to handle both formats.

• Sign at registries: we could omit signatures from AgentCards, but expect that in production scenarios AgentCards are served via a registry that packages AgentCards with signatures. This effectively removes signing from the core A2A protocol and puts it off onto other registry/discovery protocols. We believe signing is a valuable feature, and so standardizing it via the core A2A protocol is appropriate.

Additional context

See #199.

Code of Conduct

• I agree to follow this project's Code of Conduct