Agent card discovery

What this check verifies

The Signature Agent Card is optional metadata describing the agent behind a Web Bot Auth deployment, defined in the web-bot-auth registry draft (draft-meunier-webbotauth-registry). It is separate from the JWKS directory and has no fixed well-known path: it is linked from the site or directory, or listed in a registry.

This check covers whether the checker found a card at all. The card has no standard link relation yet, so discovery is best effort: the checker reads the directory’s Link header for a web-bot-auth-specific relation, and if that finds nothing it fetches the site homepage and scans its <link> tags. The first matching URL is fetched.

What it finds determines the result:

• A card that carries Web Bot Auth fields (such as jwks_uri, keys, client_name, or rfc9309-compliance) is accepted, and the per-field card checks run against it.
• A document that has none of those fields is treated as not a Web Bot Auth card and is ignored, with a note. This is what happens when the link points at an A2A or MCP agent card (see below).
• No card found at all is recorded as an advisory note.

This check is advisory in every outcome. Finding no card, or finding the wrong kind, lowers the score slightly and raises a warning, but it never caps the grade and never changes the verdict. A directory with valid keys is VALID with no card at all.

Why it matters

The card is the metadata layer over the keys: it says who the operator is, why the agent visits, and how it behaves. Without it, all a site operator has is the keys, which prove identity but say nothing else. Discovery is the step that decides whether any of that metadata is available to check.

The distinction from other agent cards matters here. Many sites publish a /.well-known/agent-card.json, but that is usually an A2A (Agent2Agent) or MCP agent card: a different standard that describes an agent’s skills and interfaces, with fields like name, skills, and supportedInterfaces, and no cryptographic keys. It is not a Web Bot Auth Signature Agent Card. The checker does not chase the generic agent-card link relation, and if it does fetch a document that turns out to have that shape, it recognises it and does not grade it as a Web Bot Auth card.

How to fix it

To make a card discoverable, publish it and link to it with a web-bot-auth-specific link relation, either in the directory’s Link response header or in a <link> tag on the homepage. For example, as a Link header on the directory response:

Link: <https://example.com/agent-card.json>; rel="signature-agent-card"

Then confirm the linked document is a Web Bot Auth card: it should carry fields such as jwks_uri, client_name, or rfc9309-compliance. A document with only name, skills, and supportedInterfaces is an A2A or MCP card and will be ignored. If you intend to publish both, keep them at separate URLs and link each with its own relation.

References

• The web-bot-auth registry draft (draft-meunier-webbotauth-registry) defines the Signature Agent Card.
• What is a Signature Agent Card? explains the card and how it differs from an A2A or MCP agent card.
• How grading works explains why card checks are advisory.