Signed Agent Card

Problem

A plain capability card is just a JSON document at a URL, and anything can serve one. Nothing stops a hostile party from publishing a card that claims another organisation's identity and skills, or from tampering with a card in transit, so a client that trusts the card at face value can be steered into delegating work or credentials to an impostor. Discovery needs a way to check that a card truly came from the domain it claims, without a central registry vouching for every agent.

Solution

Add a signature to the agent card. The publisher signs the card's canonical content with a key whose authority traces to the domain that issued it — for example a JWS signature the consumer can validate against the issuer's published key — and embeds the signature in the card. A consuming agent that fetches the card first canonicalises and verifies the signature: a card whose signature is missing, malformed, or not traceable to the claimed issuer is rejected before any binding. Only a card that verifies is trusted enough to drive endpoint selection, capability binding, and credential delegation. Because the proof travels in the card, verification needs no central broker, and each consumer checks authenticity independently.

When to use

• Agents from different organisations discover and bind to each other without a pre-shared trust relationship.
• A consuming agent delegates tasks or credentials based on a fetched capability card.
• Impersonation or tampering of the discovery descriptor is a realistic threat.