agenticweb.wiki

Signature Agent Card (Web Bot Auth registry)

Last checked · 45 primary sources

This page covers the IETF individual Internet-Draft "Registry and Signature Agent card for Web bot auth" (draft-meunier-webbotauth-registry), which defines the JSON Signature Agent Card format (built on OAuth Client ID Metadata Documents and RFC 7591 client metadata with a web_bot_auth extension object) and a newline-delimited Registry format for discovering Web Bot Auth entities [1][2]. For the underlying IETF webbotauth Working Group request-signing and key-directory protocol (draft-ietf-webbotauth-httpsig-protocol), see Web Bot Auth. For the cryptographic HTTP signature mechanism, see HTTP Message Signatures. For the OAuth client identity document format reused by the card, see OAuth Client ID Metadata Document (CIMD).

Overview

1. Problem Statement and Architectural Scope

The base IETF Web Bot Auth protocol (draft-ietf-webbotauth-httpsig-protocol-00) and RFC 9421: HTTP Message Signatures enable an automated HTTP client to cryptographically sign requests and point verifiers to a key directory (/.well-known/http-message-signatures-directory), proving which key holder sent a request [11][35][43]. However, a cryptographic key directory alone does not provide a standardized, machine-readable description of the operator's identity, contact channels, crawl purpose, robots.txt product token, or expected request rate, nor does it define a portable list format for discovering many signed bots across platforms and curators [1][29].

In draft-meunier-webbotauth-registry-04 (draft-meunier-webbotauth-registry-04 - Registry and Signature Agent card for Web bot auth, published 27 October 2026), Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), and Thibault Meunier (Cloudflare) define two complementary artifacts — the Signature Agent Card and the Registry [1][2][4]:

"This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using HTTP Message Signatures for bots publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry, the same namespace used by OAuth Client ID Metadata Documents, extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members." [1]

Section 1 (Introduction) explains why ad-hoc User-Agent strings, IP lists, and out-of-band documentation pages are insufficient for signature agents and why the specification builds directly on the OAuth Client ID Metadata Document (CIMD) (draft-ietf-oauth-client-id-metadata-document-02) [41] and OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) [42] parameter namespace [1]:

"Signature Agents are entities that originate or forward signed HTTP requests on behalf of users or services. They include bots developers, platforms providers, and other intermediaries using [PROTOCOL]. These agents often need to identify themselves, and establish trust with origin servers. Today, the mechanisms for doing so are inconsistent: some rely on User-Agent strings (e.g. MyCompanyBot/1.0), others on IP address lists hosted on file servers (e.g. https://curated-bots.com/ ips.json), and still others on out-of-band definitions (e.g. documentation on docs.example.com/mybot). This diversity makes it Guerreiro, et al. Expires 30 April 2027 [Page 3] Internet-Draft Registry and Signature Agent card for We October 2026 difficult for operators and origin servers to reliably discover and share a Signature Agent's purpose, contact information, or rate expectations." [1]

"The OAuth Client ID Metadata Document [CIMD] already defines a resolvable identity: a client_id that is an HTTPS URL dereferencing to a JSON metadata document. This document reuses it. A Signature Agent Card takes the client metadata parameters that [CIMD] draws from [DCR], and adds bot-specific information in a single web_bot_auth object. An existing Client ID Metadata Document is therefore a valid Signature Agent Card." [1]

2. Evolution Across Revisions -00 through -04 (September 2025 – October 2026)

A frequent source of confusion in secondary summaries is that the wire format and discovery path of the Signature Agent Card changed substantially between revisions -00/-02 and -03/-04 [1][3][5][7][8][34]:

  1. Revisions -00 (5 September 2025) and -01 (20 October 2025) — Flat Extension of the Key Directory:
  2. Initially authored by Maxime Guerreiro and Thibault Meunier (-00) [5], with Ulas Kirazci joining in -01 [6], the early drafts modeled the Signature Agent Card as an extension of the HTTP Message Signatures Directory (/.well-known/http-message-signatures-directory) with all metadata fields and the keys array at the top level [5][6][29]: > "Web Bot Auth M. Guerreiro Internet-Draft T. Meunier Intended status: Informational Cloudflare Expires: 9 March 2026 5 September 2025 Registry and Signature Agent card for Web bot auth draft-meunier-webbotauth-registry-00 Abstract This document describes a JSON based format for clients using [DIRECTORY] to advertise information about themselves. This document describes a JSON-based "Signature Agent Card" format for signature agent using [DIRECTORY] to advertise metadata about themselve. This includes identity, purpose, rate expectations, and cryptographic keys. It also establishes an IANA registry for Signature Agent Card parameters, enabling extensible and interoperable discovery of agent information." [5]
  3. Revision -02 (26 May 2026) — Separation of jwks_uri and ips_uri plus Registry Endpoints:
  4. Revision -02 introduced jwks_uri (to separate key material from card metadata) and ips_uri, renamed "Public list" to "Registry Endpoint", and added guidance for authenticated private registries, conditional GET polling (ETag / If-Modified-Since), HTTP caching, and signed webhook notifications [1][3][7].
  5. Revision -03 (26 June 2026) — Redesign as an OAuth CIMD Document with a Nested web_bot_auth Object:
  6. Revision -03 restructured the Signature Agent Card into an OAuth client metadata document resolved at its own HTTPS client_id URL (distinct from /.well-known/http-message-signatures-directory), nested all bot-specific fields under web_bot_auth, renamed inline keys to jwks, made jwks and jwks_uri mutually exclusive, and introduced Signature-Agent discovery parameter type=cimd [1][3][8]: > "Web Bot Auth M. Guerreiro Internet-Draft Cloudflare Intended status: Informational U. Kirazci Expires: 28 December 2026 Amazon T. Meunier Cloudflare 26 June 2026 Registry and Signature Agent card for Web bot auth draft-meunier-webbotauth-registry-03 Abstract This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using [DIRECTORY] publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same namespace used by [CIMD], extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members." [8]
  7. Revision -04 (27 October 2026) — Alignment with draft-ietf-webbotauth-httpsig-protocol-00 and Mixed JWK Set / Card Registries:
  8. Announced on i-d-announce (I-D Action: draft-meunier-webbotauth-registry-04.txt) on 27 October 2026 [4], revision -04 updated its normative protocol reference to the adopted Working Group draft draft-ietf-webbotauth-httpsig-protocol-00, formally defined type=cimd, allowed registries to list JWK Set URLs alongside Signature Agent Card URLs (distinguished by HTTP response media type), changed rfc9309-compliance from an array of strings to a boolean, and moved push-based change notifications to non-normative Appendix C [1][4]: > "Changelog draft-meunier-webbotauth-registry-04 * Align with draft-ietf-webbotauth-httpsig-protocol; define type=cimd. * Allow JWK Set registry entries, selected by media type. * Make rfc9309-compliance a boolean. * Move change notifications to an appendix." [1]

3. Signature Agent Card Structure (client_id, jwks_uri / jwks, and web_bot_auth)

Section 3 defines a Signature Agent Card as a UTF-8 JSON object whose top-level client parameters are drawn from the RFC 7591 OAuth Dynamic Client Registration Metadata registry (client_id, client_name, client_uri, logo_uri, contacts, jwks_uri, jwks) and whose bot-specific claims are encapsulated in web_bot_auth [1][42]:

"A Signature Agent Card is a JSON object describing a Signature Agent. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same parameter namespace used by [CIMD]. Web bot auth-specific information is carried in a single web_bot_auth object, defined in Section 3.2. Because the card reuses the [CIMD] parameter namespace, an existing Client ID Metadata Document is a valid Signature Agent Card. A client that does not understand the web_bot_auth object ignores it. A Signature Agent Card can be referenced from the Signature-Agent header using type=cimd, as described in Section 4.5." [1]

"{ "client_id": "https://example.com/bot", "client_name": "Example Bot", "client_uri": "https://example.com/bot/about.html", "logo_uri": "https://example.com/logo.png", "contacts": ["mailto:bot-support@example.com"], "jwks_uri": "https://example.com/.well-known/http-message-signatures-directory", "web_bot_auth": { "expected-user-agent": "Mozilla/5.0 ExampleBot", "rfc9309-product-token": "ExampleBot", "rfc9309-compliance": false, "trigger": "fetcher", "purpose": "search", "targeted-content": "Cat pictures", "rate-control": "429", "rate-expectation": "avg=10rps;max=100rps", "known-urls": ["/", "/robots.txt", "*.png"], "ips_uri": "https://example.com/ips.json" } }" [1]

"Unless otherwise specified, all parameters in this document are OPTIONAL, except that a card resolved through its client_id MUST carry client_id (see Section 3.1.1). There MUST be at least one parameter set. Parameters for which the value is unknown MUST be ignored. All string values are UTF-8." [1]

A. Resolvable Identity (client_id) and Strict Retrieval Rules (Section 3.1.1)

When a card is resolved via its client_id HTTPS URL, Section 3.1.1 enforces the same anti-redirect and exact-match rules as draft-ietf-oauth-client-id-metadata-document-02 [1][41]:

"The client_id parameter is the resolvable identity of the Signature Agent, as defined in [CIMD]. It is an HTTPS URL that, when dereferenced, returns the Signature Agent Card. A card retrieved through its client_id MUST include the client_id parameter. A client retrieving a card from a URL MUST use the GET method, MUST treat any status code other than 200 (OK) as an error, and MUST NOT follow HTTP redirects. The client_id value in the returned document MUST be identical to the URL used to retrieve it, compared as described in Section 6.2.1 of [RFC3986] (simple string comparison)." [1]

B. Key Material Separation (jwks_uri vs. jwks, Sections 3.1.2–3.1.3)

A Signature Agent Card references its RFC 7517 JSON Web Key Set [44] either externally via jwks_uri (for example, pointing to https://example.com/.well-known/http-message-signatures-directory) or inline via jwks, but never both [1]:

"When present, this parameter separates key material discovery from metadata discovery. Clients that need key material SHOULD fetch the key set at the given URL rather than relying on the jwks parameter. This separation allows registry operators to host metadata and key material on different endpoints, supporting deployment scenarios where the registry endpoint itself contains signature agent card metadata but key material is hosted elsewhere. A Signature Agent Card MUST NOT contain both jwks_uri and jwks. Clients SHOULD reject a card that contains both parameters." [1]

Because the card binds descriptive metadata to keys hosted at jwks_uri, Section 3.1.2 requires a stricter key-possession check than the base signing protocol [1]:

"The response at jwks_uri SHOULD carry the possession proofs defined in Appendix B.1 of [PROTOCOL]. Clients SHOULD validate them as described there, and SHOULD ignore keys without a valid proof. This Guerreiro, et al. Expires 30 April 2027 [Page 6] Internet-Draft Registry and Signature Agent card for We October 2026 is stricter than [PROTOCOL], which lets a verifier use keys it resolved itself without proof: a card binds keys to metadata, so the key holder should vouch for that binding." [1]

"The jwks parameter contains a JWK Set as defined in Section 5 of [JWK]. It is the inline client metadata parameter defined in [DCR]. If jwks is present, it is RECOMMENDED that the card is signed using [HTTP-MESSAGE-SIGNATURES]. Content-Digest header MUST be included in the covered components." [1]

C. The web_bot_auth Extension Object (Section 3.2)

Section 3.2 defines ten initial parameters inside web_bot_auth [1]:

"The web_bot_auth parameter is a JSON object carrying bot-specific metadata. It is registered in the OAuth Dynamic Client Registration Metadata registry [DCR] (see Section 7), so that it may appear in any Client ID Metadata Document [CIMD]. Its members are governed by the "Web Bot Auth Metadata Parameters" registry defined in Section 7. Members for which the value is unknown MUST be ignored." [1]

  1. expected-user-agent (Section 3.2.1): One or more HTTP User-Agent strings or wildcard (*) prefix matches (e.g., "Mozilla/5.0 ExampleBot") [1].
  2. rfc9309-product-token (Section 3.2.2): The product token matched against robots.txt rules per Section 2.2.1 of RFC 9309: Robots Exclusion Protocol [1][45].
  3. rfc9309-compliance (Section 3.2.3): Changed in -04 to a boolean indicating whether the agent claims compliance with RFC 9309 (false by default when omitted) [1]:

    "The rfc9309-compliance parameter is a boolean indicating whether the agent claims compliance with [ROBOTSTXT]. A false value indicates that origins cannot assume robots.txt is followed. When undefined, the value defaults to false." [1]

  4. trigger and purpose (Sections 3.2.4–3.2.5): trigger distinguishes user-initiated "fetcher" requests from autonomous "crawler" scanning; purpose describes intended data use (noting draft-ietf-aipref-vocab as a candidate vocabulary) [1]:

    "The trigger parameter indicates the operational mode of the agent. Valid values: 1. fetcher - request initiated by the user 2. crawler - autonomous scanning 3.2.5. Purpose The purpose parameter describes the intended use of collected data. TODO: consider an array; [AIPREF-VOCAB] is one possible vocabulary." [1]

  5. targeted-content, rate-control, rate-expectation, and known-urls (Sections 3.2.6–3.2.9): UTF-8 description of sought content, supported origin rate-control signals (e.g., "429"), anticipated traffic volume/burstiness (e.g., "avg=10rps;max=100rps"), and predictable target paths/wildcards (e.g., ["/", "/robots.txt", "*.png"]) [1].
  6. ips_uri (Section 3.2.10): An https URL pointing to the agent's IP range list formatted under draft-illyes-webbotauth-jafar-01 ([JAFAR]) [1][40]:

    "The ips_uri parameter provides the URL of the signature agent's IP address list as defined in [JAFAR]. The URI scheme MUST be https. This allows discovery without a fixed location and does not preclude [JAFAR] from defining one." [1]

4. Discovery (type=cimd), Registry Format (ABNF), and Security Model

A. Two-Hop CIMD Discovery vs. JWK Set Entries in a Registry (Sections 4–4.2)

Unlike /.well-known/http-message-signatures-directory, a Signature Agent Card has no fixed well-known URI path; instead, it is discovered by dereferencing its client_id URL from a Signature-Agent header parameter (type=cimd) or from a Registry [1][34]. In revision -04, a Registry can contain both direct JWK Set URLs and Signature Agent Card client_id URLs, differentiated by the HTTP response Content-Type [1]:

"A Signature Agent Card is discovered by dereferencing its client_id, as described in Section 4.1, or from a registry. A registry is a list of entries. Each entry is an https URL or a data URL containing an inline Signature Agent Card. A client fetches an https entry with GET. If the response media type is application/jwk-set+json (Section 8.5 of [JWK]) or application/ http-message-signatures-directory+json (Section 8.2 of [PROTOCOL]), the response is a JWK Set, and the entry is resolved as a Signature- Agent value (Section 5.5 of [PROTOCOL]). Otherwise, the entry is the client_id of a Signature Agent Card, and the response is processed as described in Section 4.1. A JWK Set served with another media type, such as application/json, is therefore treated as a card, and rejected because it has no client_id." [1]

"A Signature Agent advertises its identity through a resolvable client_id URL, as defined in [CIMD]. A consumer discovers the agent's metadata and keys as follows: 1. Obtain a client_id URL from a Signature-Agent member with type=cimd (Section 4.5), a registry entry (Section 4), or out of band. 2. Dereference the client_id with a GET request. The response MUST be 200 (OK), redirects MUST NOT be followed, and the returned client_id MUST match the requested URL (see Section 3.1.1). The response is the Signature Agent Card. Guerreiro, et al. Expires 30 April 2027 [Page 10] Internet-Draft Registry and Signature Agent card for We October 2026 3. Obtain key material. If the card has a jwks_uri, fetch the JWK Set at that URL; otherwise use the inline jwks parameter. The metadata document and the key set are distinct resources reached at different hops, so no content negotiation between them is required." [1]

Section 4.1 illustrates how a single registry text file can list individual bots by their .well-known/http-message-signatures-directory key directories, a multi-tenant platform gateway by its Signature Agent Card URL, and an inline data:application/json,... card [1]:

"# Bots, by their key directory https://bot1.example.com/.well-known/http-message-signatures-directory https://crawler2.example.com/.well-known/http-message-signatures-directory # A platform, by its Signature Agent Card https://zerotrust-gateway.example.com/v1/signature-agent-card # An inline card with the data URL scheme data:application/json,%7B%22client_name%22:%22Inline%20Bot%22%7D" [1]

Section 4.2 specifies the formal ABNF syntax for a registry file (newline-separated https-URI or RFC 2397 dataurl entries with optional # comments) [1]:

"registry = *(entryline / emptyline) entryline = (https-URI /; As defined in Section 4.2.2 of RFC 9110 dataurl; As defined in Section 3 of RFC 2397) EOL" [1]

B. Registry Endpoint Operations and Signature-Agent Header Parameter type=cimd (Sections 4.4–4.5)

Section 4.4 allows registries to be hosted on GitHub, static file servers, or authenticated HTTPS endpoints (supporting ETag / If-Modified-Since conditional requests and Cache-Control headers), while Section 4.5 defines the type=cimd parameter on Signature-Agent dictionary members [1]:

"A registry MAY be provided via a GitHub repository, a public file server, or a dedicated endpoint. The registry SHOULD be served over HTTPS. A client application SHOULD validate the registry format and reject malformed entries. 4.4.1. Authentication A registry endpoint MAY require authentication to restrict access to authorized clients. This allows a registry operator to expose registries without revealing their contents publicly. Guerreiro, et al. Expires 30 April 2027 [Page 12] Internet-Draft Registry and Signature Agent card for We October 2026 No specific authentication mechanism is mandated. Implementations MAY use pre-shared keys as mentioned in [PSK-TLS], bearer tokens as defined in [OAUTH-BEARER], or HTTP Message Signatures as defined in [HTTP-MESSAGE-SIGNATURES]. HTTP Message Signatures are RECOMMENDED when key rotation without out-of-band coordination is desired." [1]

"A Signature-Agent member value is a JWK Set URL (Section 5.2.1 of [PROTOCOL]). This document defines the type member parameter with the value cimd: the member value is then the client_id of a Signature Agent Card, resolved as described in Section 4.1, and the keys are the card's keys. Signature-Agent: sig1="https://example.com/bot";type=cimd [PROTOCOL] requires verifiers to ignore members with parameters. A verifier that does not implement this document therefore ignores a type=cimd member and cannot attribute the signature to it. TODO: [PROTOCOL] currently prohibits member parameters. This section assumes it will allow them." [1]

Non-normative Appendix C (Change notification) additionally sketches an optional push webhook mechanism where a registry advertises Link: <https://...>; rel="registry-changes" and sends RFC 9421-signed POST notifications ({"action": "put" | "delete", "signature-agent": "..."}) when entries change, while keeping pull-based registry fetches authoritative [1]:

"Pull-based consumption with conditional requests is sufficient for most deployments. Fetching a large changed registry can be expensive. A registry operator may instead implement push-based change notification." [1]

C. Security Considerations and IANA Registries (Sections 5 & 7)

Section 5 highlights SSRF protections when fetching untrusted client_id, jwks_uri, and ips_uri URLs (Section 5.1), warns verifiers that all web_bot_auth metadata fields are self-asserted claims rather than verified behavior (Section 5.2), and recommends signing registry HTTP responses with the registry operator's own key (Section 5.3) [1]:

"A client_id from a Signature-Agent header, a registry entry, and a card's jwks_uri or ips_uri are all chosen by someone other than the client. A client fetching them is exposed to the server-side request forgery risks in Section 6.7 of [PROTOCOL], and SHOULD apply the precautions listed there to every fetch defined in this document. A registry can list many entries, so it is RECOMMENDED that clients bound the number of cards fetched per registry." [1]

"A valid card shows that whoever controls the client_id URL published it. As Section 4.4 of [PROTOCOL] puts it for keys, this does not mean the operator is honest. Every member of web_bot_auth, such as purpose, rfc9309-compliance, or rate-expectation, is a claim made by the Signature Agent. Clients MUST NOT treat these values as verified behavior." [1]

"To additionally bind the registry contents to the registry operator's cryptographic identity, registry servers SHOULD sign their HTTP responses using [HTTP-MESSAGE-SIGNATURES] with a key present in the registry operator's own signature agent card. Clients SHOULD verify such signatures when present." [1]

Section 7 requests IANA to register web_bot_auth in the OAuth Dynamic Client Registration Metadata registry and to establish a new Web Bot Auth Metadata Parameters registry under the RFC 8126 Specification Required policy pre-populated with the ten Section 3.2 parameters [1]:

"IANA is requested to register the following parameter in the "OAuth Dynamic Client Registration Metadata" registry established by [DCR]. Client Metadata Name: web_bot_auth Client Metadata Description: A JSON object carrying bot-specific metadata for a Signature Agent. Its members are registered in the "Web Bot Auth Metadata Parameters" registry. Change Controller: IETF Reference: Section 3.2 The remaining parameters used by a Signature Agent Card (client_id, client_name, client_uri, logo_uri, contacts, jwks_uri, jwks) are already registered OAuth client metadata parameters and are not registered by this document. 7.2. Web Bot Auth Metadata Parameters Registry IANA is requested to create the "Web Bot Auth Metadata Parameters" registry. This registry governs the members of the web_bot_auth object defined in Section 3.2. 7.2.1. Registration Template New registrations need to list the following attributes: Parameter Name: The name requested (e.g. "purpose"). This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception Parameter Description: Brief description of the parameter Guerreiro, et al. Expires 30 April 2027 [Page 15] Internet-Draft Registry and Signature Agent card for We October 2026 Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Reference: Where this parameter is defined Notes: Any notes associated with the entry New entries in this registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6)." [1]

D. Open Design Questions in the Author Repository (thibmeu/draft-meunier-webbotauth-registry)

On 10 September 2026, editor Thibault Meunier split the specification source into a dedicated GitHub repository (thibmeu/draft-meunier-webbotauth-registry, described as "A CIMD extension and a text file format to discover webbotauth entities") [13] and opened two architectural tracking issues migrated from thibmeu/http-message-signatures-directory [15]: - Issue #2 ([registry] Rename Signature-Agent Card to Registry Card): Proposes renaming the artifact to Registry Card to reflect the three-step chain Registry --> Card --> Metadata (jwks_uri, ips_uri, purpose) [15]. - Issue #1 (Support registries linking to registries): Proposes allowing registries to reference downstream registries so authoritative curators can delegate or revoke trust across sub-registries [15].

Who uses it

Who reads it

Recent coverage

See also

References

  1. Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), and Thibault Meunier (Cloudflare). `draft-meunier-webbotauth-registry-04` — Registry and Signature Agent card for Web bot auth (IETF Internet-Draft, Intended status Informational, 27 October 2026, expires 30 April 2027, 26 pages): "This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using HTTP Message Signatures for bots publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry, the same namespace used by OAuth Client ID Metadata Documents, extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members." "Signature Agents are entities that originate or forward signed HTTP requests on behalf of users or services. They include bots developers, platforms providers, and other intermediaries using [PROTOCOL]. These agents often need to identify themselves, and establish trust with origin servers. Today, the mechanisms for doing so are inconsistent: some rely on User-Agent strings (e.g. MyCompanyBot/1.0), others on IP address lists hosted on file servers (e.g. https://curated-bots.com/ ips.json), and still others on out-of-band definitions (e.g. documentation on docs.example.com/mybot). This diversity makes it Guerreiro, et al. Expires 30 April 2027 [Page 3] Internet-Draft Registry and Signature Agent card for We October 2026 difficult for operators and origin servers to reliably discover and share a Signature Agent's purpose, contact information, or rate expectations." "The OAuth Client ID Metadata Document [CIMD] already defines a resolvable identity: a client_id that is an HTTPS URL dereferencing to a JSON metadata document. This document reuses it. A Signature Agent Card takes the client metadata parameters that [CIMD] draws from [DCR], and adds bot-specific information in a single web_bot_auth object. An existing Client ID Metadata Document is therefore a valid Signature Agent Card." "A Signature Agent Card is a JSON object describing a Signature Agent. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same parameter namespace used by [CIMD]. Web bot auth-specific information is carried in a single web_bot_auth object, defined in Section 3.2. Because the card reuses the [CIMD] parameter namespace, an existing Client ID Metadata Document is a valid Signature Agent Card. A client that does not understand the web_bot_auth object ignores it. A Signature Agent Card can be referenced from the Signature-Agent header using type=cimd, as described in Section 4.5." "{ "client_id": "https://example.com/bot", "client_name": "Example Bot", "client_uri": "https://example.com/bot/about.html", "logo_uri": "https://example.com/logo.png", "contacts": ["mailto:bot-support@example.com"], "jwks_uri": "https://example.com/.well-known/http-message-signatures-directory", "web_bot_auth": { "expected-user-agent": "Mozilla/5.0 ExampleBot", "rfc9309-product-token": "ExampleBot", "rfc9309-compliance": false, "trigger": "fetcher", "purpose": "search", "targeted-content": "Cat pictures", "rate-control": "429", "rate-expectation": "avg=10rps;max=100rps", "known-urls": ["/", "/robots.txt", ".png"], "ips_uri": "https://example.com/ips.json" } }" "Unless otherwise specified, all parameters in this document are OPTIONAL, except that a card resolved through its client_id MUST carry client_id (see Section 3.1.1). There MUST be at least one parameter set. Parameters for which the value is unknown MUST be ignored. All string values are UTF-8." "The client_id parameter is the resolvable identity of the Signature Agent, as defined in [CIMD]. It is an HTTPS URL that, when dereferenced, returns the Signature Agent Card. A card retrieved through its client_id MUST include the client_id parameter. A client retrieving a card from a URL MUST use the GET method, MUST treat any status code other than 200 (OK) as an error, and MUST NOT follow HTTP redirects. The client_id value in the returned document MUST be identical to the URL used to retrieve it, compared as described in Section 6.2.1 of [RFC3986] (simple string comparison)." "When present, this parameter separates key material discovery from metadata discovery. Clients that need key material SHOULD fetch the key set at the given URL rather than relying on the jwks parameter. This separation allows registry operators to host metadata and key material on different endpoints, supporting deployment scenarios where the registry endpoint itself contains signature agent card metadata but key material is hosted elsewhere. A Signature Agent Card MUST NOT contain both jwks_uri and jwks. Clients SHOULD reject a card that contains both parameters." "The response at jwks_uri SHOULD carry the possession proofs defined in Appendix B.1 of [PROTOCOL]. Clients SHOULD validate them as described there, and SHOULD ignore keys without a valid proof. This Guerreiro, et al. Expires 30 April 2027 [Page 6] Internet-Draft Registry and Signature Agent card for We October 2026 is stricter than [PROTOCOL], which lets a verifier use keys it resolved itself without proof: a card binds keys to metadata, so the key holder should vouch for that binding." "The jwks parameter contains a JWK Set as defined in Section 5 of [JWK]. It is the inline client metadata parameter defined in [DCR]. If jwks is present, it is RECOMMENDED that the card is signed using [HTTP-MESSAGE-SIGNATURES]. Content-Digest header MUST be included in the covered components." "The web_bot_auth parameter is a JSON object carrying bot-specific metadata. It is registered in the OAuth Dynamic Client Registration Metadata registry [DCR] (see Section 7), so that it may appear in any Client ID Metadata Document [CIMD]. Its members are governed by the "Web Bot Auth Metadata Parameters" registry defined in Section 7. Members for which the value is unknown MUST be ignored." "The rfc9309-compliance parameter is a boolean indicating whether the agent claims compliance with [ROBOTSTXT]. A false value indicates that origins cannot assume robots.txt is followed. When undefined, the value defaults to false." "The trigger parameter indicates the operational mode of the agent. Valid values: 1. fetcher - request initiated by the user 2. crawler - autonomous scanning 3.2.5. Purpose The purpose parameter describes the intended use of collected data. TODO: consider an array; [AIPREF-VOCAB] is one possible vocabulary." "The ips_uri parameter provides the URL of the signature agent's IP address list as defined in [JAFAR]. The URI scheme MUST be https. This allows discovery without a fixed location and does not preclude [JAFAR] from defining one." "A Signature Agent Card is discovered by dereferencing its client_id, as described in Section 4.1, or from a registry. A registry is a list of entries. Each entry is an https URL or a data URL containing an inline Signature Agent Card. A client fetches an https entry with GET. If the response media type is application/jwk-set+json (Section 8.5 of [JWK]) or application/ http-message-signatures-directory+json (Section 8.2 of [PROTOCOL]), the response is a JWK Set, and the entry is resolved as a Signature- Agent value (Section 5.5 of [PROTOCOL]). Otherwise, the entry is the client_id of a Signature Agent Card, and the response is processed as described in Section 4.1. A JWK Set served with another media type, such as application/json, is therefore treated as a card, and rejected because it has no client_id." "A Signature Agent advertises its identity through a resolvable client_id URL, as defined in [CIMD]. A consumer discovers the agent's metadata and keys as follows: 1. Obtain a client_id URL from a Signature-Agent member with type=cimd (Section 4.5), a registry entry (Section 4), or out of band. 2. Dereference the client_id with a GET request. The response MUST be 200 (OK), redirects MUST NOT be followed, and the returned client_id MUST match the requested URL (see Section 3.1.1). The response is the Signature Agent Card. Guerreiro, et al. Expires 30 April 2027 [Page 10] Internet-Draft Registry and Signature Agent card for We October 2026 3. Obtain key material. If the card has a jwks_uri, fetch the JWK Set at that URL; otherwise use the inline jwks parameter. The metadata document and the key set are distinct resources reached at different hops, so no content negotiation between them is required." "# Bots, by their key directory https://bot1.example.com/.well-known/http-message-signatures-directory https://crawler2.example.com/.well-known/http-message-signatures-directory # A platform, by its Signature Agent Card https://zerotrust-gateway.example.com/v1/signature-agent-card # An inline card with the data URL scheme data:application/json,%7B%22client_name%22:%22Inline%20Bot%22%7D" "registry = (entryline / emptyline) entryline = (https-URI /; As defined in Section 4.2.2 of RFC 9110 dataurl; As defined in Section 3 of RFC 2397) EOL" "A registry MAY be provided via a GitHub repository, a public file server, or a dedicated endpoint. The registry SHOULD be served over HTTPS. A client application SHOULD validate the registry format and reject malformed entries. 4.4.1. Authentication A registry endpoint MAY require authentication to restrict access to authorized clients. This allows a registry operator to expose registries without revealing their contents publicly. Guerreiro, et al. Expires 30 April 2027 [Page 12] Internet-Draft Registry and Signature Agent card for We October 2026 No specific authentication mechanism is mandated. Implementations MAY use pre-shared keys as mentioned in [PSK-TLS], bearer tokens as defined in [OAUTH-BEARER], or HTTP Message Signatures as defined in [HTTP-MESSAGE-SIGNATURES]. HTTP Message Signatures are RECOMMENDED when key rotation without out-of-band coordination is desired." "A Signature-Agent member value is a JWK Set URL (Section 5.2.1 of [PROTOCOL]). This document defines the type member parameter with the value cimd: the member value is then the client_id of a Signature Agent Card, resolved as described in Section 4.1, and the keys are the card's keys. Signature-Agent: sig1="https://example.com/bot";type=cimd [PROTOCOL] requires verifiers to ignore members with parameters. A verifier that does not implement this document therefore ignores a type=cimd member and cannot attribute the signature to it. TODO: [PROTOCOL] currently prohibits member parameters. This section assumes it will allow them." "Pull-based consumption with conditional requests is sufficient for most deployments. Fetching a large changed registry can be expensive. A registry operator may instead implement push-based change notification." "A client_id from a Signature-Agent header, a registry entry, and a card's jwks_uri or ips_uri are all chosen by someone other than the client. A client fetching them is exposed to the server-side request forgery risks in Section 6.7 of [PROTOCOL], and SHOULD apply the precautions listed there to every fetch defined in this document. A registry can list many entries, so it is RECOMMENDED that clients bound the number of cards fetched per registry." "A valid card shows that whoever controls the client_id URL published it. As Section 4.4 of [PROTOCOL] puts it for keys, this does not mean the operator is honest. Every member of web_bot_auth, such as purpose, rfc9309-compliance, or rate-expectation, is a claim made by the Signature Agent. Clients MUST NOT treat these values as verified behavior." "To additionally bind the registry contents to the registry operator's cryptographic identity, registry servers SHOULD sign their HTTP responses using [HTTP-MESSAGE-SIGNATURES] with a key present in the registry operator's own signature agent card. Clients SHOULD verify such signatures when present." "IANA is requested to register the following parameter in the "OAuth Dynamic Client Registration Metadata" registry established by [DCR]. Client Metadata Name: web_bot_auth Client Metadata Description: A JSON object carrying bot-specific metadata for a Signature Agent. Its members are registered in the "Web Bot Auth Metadata Parameters" registry. Change Controller: IETF Reference: Section 3.2 The remaining parameters used by a Signature Agent Card (client_id, client_name, client_uri, logo_uri, contacts, jwks_uri, jwks) are already registered OAuth client metadata parameters and are not registered by this document. 7.2. Web Bot Auth Metadata Parameters Registry IANA is requested to create the "Web Bot Auth Metadata Parameters" registry. This registry governs the members of the web_bot_auth object defined in Section 3.2. 7.2.1. Registration Template New registrations need to list the following attributes: Parameter Name: The name requested (e.g. "purpose"). This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception Parameter Description: Brief description of the parameter Guerreiro, et al. Expires 30 April 2027 [Page 15] Internet-Draft Registry and Signature Agent card for We October 2026 Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. Reference: Where this parameter is defined Notes: Any notes associated with the entry New entries in this registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6)." "Changelog draft-meunier-webbotauth-registry-04 Align with draft-ietf-webbotauth-httpsig-protocol; define type=cimd. Allow JWK Set registry entries, selected by media type. Make rfc9309-compliance a boolean. Move change notifications to an appendix." — https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-04.txt
  2. IETF Datatracker. draft-meunier-webbotauth-registry-04 - Registry and Signature Agent card for Web bot auth (document status, revision history `-00` through `-04`, updated 27 October 2026): "Registry and Signature Agent card for Web bot auth" — https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/
  3. IETF Datatracker JSON Metadata. `draft-meunier-webbotauth-registry/doc.json` (checked 29 October 2026): "draft-meunier-webbotauth-registry" — https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/doc.json
  4. IETF `i-d-announce` Mail Archive. I-D Action: draft-meunier-webbotauth-registry-04.txt (27 October 2026, 11:59 UTC): "I-D Action: draft-meunier-webbotauth-registry-04.txt" — https://mailarchive.ietf.org/arch/msg/i-d-announce/B8EK0EhHJZJQ2pmJawYBXo7Rr-4/
  5. Maxime Guerreiro and Thibault Meunier (Cloudflare). `draft-meunier-webbotauth-registry-00` — 'Registry and Signature Agent card for Web bot auth' (initial IETF Internet-Draft, 5 September 2025, 15 pages): "Web Bot Auth M. Guerreiro Internet-Draft T. Meunier Intended status: Informational Cloudflare Expires: 9 March 2026 5 September 2025 Registry and Signature Agent card for Web bot auth draft-meunier-webbotauth-registry-00 Abstract This document describes a JSON based format for clients using [DIRECTORY] to advertise information about themselves. This document describes a JSON-based "Signature Agent Card" format for signature agent using [DIRECTORY] to advertise metadata about themselve. This includes identity, purpose, rate expectations, and cryptographic keys. It also establishes an IANA registry for Signature Agent Card parameters, enabling extensible and interoperable discovery of agent information." — https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-00.txt
  6. Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), and Thibault Meunier (Cloudflare). `draft-meunier-webbotauth-registry-01` — 'Registry and Signature Agent card for Web bot auth' (IETF Internet-Draft, 20 October 2025, 18 pages): "Registry and Signature Agent card for Web bot auth" "draft-meunier-webbotauth-registry-01" — https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-01.txt
  7. Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), and Thibault Meunier (Cloudflare). `draft-meunier-webbotauth-registry-02` — 'Registry and Signature Agent card for Web bot auth' (IETF Internet-Draft, 26 May 2026, 24 pages): "Registry and Signature Agent card for Web bot auth" "draft-meunier-webbotauth-registry-02" — https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-02.txt
  8. Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), and Thibault Meunier (Cloudflare). `draft-meunier-webbotauth-registry-03` — 'Registry and Signature Agent card for Web bot auth' (IETF Internet-Draft, 26 June 2026, 26 pages): "Web Bot Auth M. Guerreiro Internet-Draft Cloudflare Intended status: Informational U. Kirazci Expires: 28 December 2026 Amazon T. Meunier Cloudflare 26 June 2026 Registry and Signature Agent card for Web bot auth draft-meunier-webbotauth-registry-03 Abstract This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using [DIRECTORY] publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same namespace used by [CIMD], extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members." — https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-03.txt
  9. IETF Datatracker. References to draft-meunier-webbotauth-registry (incoming IETF draft cross-references, checked 29 October 2026): "References to draft-meunier-webbotauth-registry" — https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/referencedby/
  10. IETF Datatracker. Web Bot Auth (webbotauth) (Working Group charter, approved 23 October 2025, checked 29 October 2026): "Web Bot Auth (webbotauth)" — https://datatracker.ietf.org/wg/webbotauth/about/
  11. IETF Datatracker. Web Bot Auth (webbotauth) (`webbotauth` Working Group document and related Internet-Draft listing, checked 29 October 2026): "draft-ietf-webbotauth-httpsig-protocol" — https://datatracker.ietf.org/wg/webbotauth/documents/
  12. IETF 124 (Montréal). `agenda-124-webbotauth-04` — 'IETF124 - WebBotAuth WG Agenda' (4 November 2025): "IETF124 - WebBotAuth WG Agenda Chairs update – 10 min WebBotAuth Architecture - Thibault - 20 min https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/ SPIFFE - Arndt (15 min) Signatures Directory - Thibault - 15 min https://datatracker.ietf.org/doc/draft-meunier-http-message-signatures-directory/ Registry - Thibault - 10min https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/" — https://datatracker.ietf.org/meeting/124/materials/agenda-124-webbotauth-04
  13. GitHub REST API. `thibmeu/draft-meunier-webbotauth-registry` repository metadata (created 10 September 2026, pushed 27 October 2026): "A CIMD extension and a text file format to discover webbotauth entities" — https://api.github.com/repos/thibmeu/draft-meunier-webbotauth-registry
  14. GitHub REST API. `thibmeu/draft-meunier-webbotauth-registry/commits` (commit `1e57de25` on 27 October 2026): "1e57de25" — https://api.github.com/repos/thibmeu/draft-meunier-webbotauth-registry/commits
  15. GitHub REST API. `thibmeu/draft-meunier-webbotauth-registry/issues?state=all` (open issues `#1` and `#2`, opened 10 September 2026): ""title": "[registry] Rename `Signature-Agent Card` to `Registry Card`"," ""title": "Support registries linking to registries"," — https://api.github.com/repos/thibmeu/draft-meunier-webbotauth-registry/issues?state=all
  16. GitHub REST API. `cloudflare/web-bot-auth` repository metadata (checked 29 October 2026): ""full_name": "cloudflare/web-bot-auth"" — https://api.github.com/repos/cloudflare/web-bot-auth
  17. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `packages/web-bot-auth/src/registry.ts` (TypeScript parser for `Signature-Agent` headers, registries, and `SignatureAgentCard`): "export type SignatureAgentDiscoveryType = "directory" | "jwks_uri" | "cimd"; export interface SignatureAgentEntry { label: string; uri: string; type: SignatureAgentDiscoveryType; }" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/packages/web-bot-auth/src/registry.ts
  18. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `packages/web-bot-auth/test/test_data/web_bot_auth_signature_agent_card_v1.json` (Signature Agent Card test vectors): ""name": "jwks-uri-card", "url": "https://example.com/bot", "valid": true, "card": { "client_id": "https://example.com/bot", "client_name": "Example Bot", "contacts": ["mailto:bot-support@example.com"], "jwks_uri": "https://example.com/.well-known/http-message-signatures-directory", "web_bot_auth": { "expected-user-agent": "Mozilla/5.0 ExampleBot", "rfc9309-product-token": "ExampleBot", "trigger": "fetcher", "purpose": "tdm", "ips_uri": "https://example.com/ips.json" } } }" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/packages/web-bot-auth/test/test_data/web_bot_auth_signature_agent_card_v1.json
  19. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `crates/web-bot-auth/src/registry.rs` (Rust crate parser for `SignatureAgentCard`, `WebBotAuthMetadata`, and `SignatureAgentDiscoveryType`): "pub enum SignatureAgentDiscoveryType { /// Resolve the well-known HTTP Message Signatures Directory. Directory, /// Resolve the member value as a direct JWK Set URI. JwksUri, /// Resolve the member value as a Client ID Metadata Document. Cimd, }" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/crates/web-bot-auth/src/registry.rs
  20. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `examples/caddy-plugin/registry.go` (Go Caddy middleware for ingesting registries, `jwks_uri`, and JAFAR `ips_uri` lists): "type SignatureAgentCard struct { JWKSUri string `json:"jwks_uri"` IPSUri string `json:"ips_uri"` Keys []json.RawMessage `json:"keys"` }" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/examples/caddy-plugin/registry.go
  21. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `examples/signature-agent-card-and-registry/README.md` (Cloudflare Worker example documentation): "This deploys three endpoints on one Cloudflare Worker: a registry, a Signature Agent Card, and a signed key directory." — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/examples/signature-agent-card-and-registry/README.md
  22. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `examples/signature-agent-card-and-registry/src/lib.rs` (Rust Cloudflare Worker serving `/registry.txt`, `/signature-agent-card`, and `/.well-known/http-message-signatures-directory`): ""/signature-agent-card" => { let scheme = req.uri().scheme_str().ok_or(worker::Error::RouteNoDataError)?.to_string(); let origin = format!("{}://{}", scheme, authority); let card = SignatureAgentCard { client_id: format!("{origin}/signature-agent-card"), client_name: authority.to_string(), contacts: vec!["mailto:test@example.com".to_string()], jwks_uri: format!("{origin}/.well-known/http-message-signatures-directory"), web_bot_auth: WebBotAuthMetadata { trigger: "fetcher".to_string(), purpose: "example".to_string(), }, };" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/examples/signature-agent-card-and-registry/src/lib.rs
  23. Cloudflare, Inc. (`cloudflare/web-bot-auth`). `examples/verification-workers/src/index.ts` (TypeScript verification Worker serving `/signature-agent-card` and `/test-registry.txt` and resolving `type=cimd` cards): "function getSignatureAgentCard(env: Env): SignatureAgentCard { const origin = signatureAgentOrigin(env); return parseSignatureAgentCard({ client_name: "Example Bot", client_uri: origin, logo_uri: `${origin}/favicon.png`, contacts: [], jwks_uri: `${origin}${HTTP_MESSAGE_SIGNATURES_DIRECTORY}`, ips_uri: `${origin}/ips.json`, web_bot_auth: { "expected-user-agent": "Mozilla/5.0 ExampleBot", "rfc9309-product-token": "ExampleBot", "rfc9309-compliance": [ "User-Agent", "Allow", "Disallow", "Content-Usage", ], trigger: "fetcher", purpose: "example", "rate-control": "429", }, }); }" — https://raw.githubusercontent.com/cloudflare/web-bot-auth/main/examples/verification-workers/src/index.ts
  24. GitHub REST API. `cloudflare/web-bot-auth/pulls/65` ('Demonstrate hosting signature agent card and registry on Cloudflare Workers', opened 16 December 2025, merged 17 December 2025): ""number": 65, "state": "closed", "locked": false, "title": "Demonstrate hosting signature agent card and registry on Cloudflare Workers"" — https://api.github.com/repos/cloudflare/web-bot-auth/pulls/65
  25. GitHub REST API. `cloudflare/web-bot-auth/commits/0cecec1bf49d9f996fc56f463203aa7adb0462c4` ('Update Signature-Agent examples', 25 June 2026): "Update Signature-Agent examples" "Update the Worker verifier and debug page to read typed Signature-Agent entries while keeping the existing registry, card, and IP endpoints in place." — https://api.github.com/repos/cloudflare/web-bot-auth/commits/0cecec1bf49d9f996fc56f463203aa7adb0462c4
  26. npm Registry Metadata. `web-bot-auth` package (`0.2.0` published 31 August 2026, checked 29 October 2026): ""name":"web-bot-auth","dist-tags":{"latest":"0.2.0"}" — https://registry.npmjs.org/web-bot-auth
  27. Cloudflare Radar. `signature-agent-registry.txt` (public Web Bot Auth registry endpoint, checked 29 October 2026): "https://assistbot.duckduckgo.com/.well-known/http-message-signatures-directory" "https://chatgpt.com/.well-known/http-message-signatures-directory" — https://assets.radar.cloudflare.com/bots/signature-agent-registry.txt
  28. Cloudflare Research. `/.well-known/http-message-signatures-directory` (live demo signed key directory, checked 29 October 2026): "{"keys":[{"kid":"poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U","kty":"OKP","crv":"Ed25519","x":"JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs","nbf":1743465600000}],"purpose":"rag"}" — https://http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directory
  29. Thibault Meunier and Maxime Guerreiro (Cloudflare). Beyond IP lists- a registry format for bots and agents | Cloudflare Blog (30 October 2025): "Therefore, to complement the registry format, we have proposed a signature-agent card format that extends the JWKS directory (RFC 7517) with additional metadata. Similar to an old-fashioned contact card, it includes all the important information someone might want to know about your agent or crawler." "Cloudflare also offers a registry for bots and agents it trusts, provided through Radar. It uses the registry format to allow for the consumption of bots trusted by Cloudflare on your server. You can use these registries today – we've provided a demo in Go for Caddy server that would allow us to import keys from multiple registries." — https://blog.cloudflare.com/agent-registry/
  30. Veda Raman, Kosti Vasilakakis, and Joshua Samuel (AWS). Reduce CAPTCHAs for AI agents browsing the web with Web Bot Auth (Preview) in Amazon Bedrock AgentCore Browser | Artificial Intelligence (30 October 2025): "Today's preview release of Web Both Auth support in AgentCore Browser helps reduce friction with CAPTCHAs on domains that allow verified bots, by making your agent appear as a verified bot. Once the Web Bot Auth protocol is finalized, AgentCore intends to transition to customer-specific keys, so AgentCore users can use the tier of control that allows only specified verified bots." — https://aws.amazon.com/blogs/machine-learning/reduce-captchas-for-ai-agents-browsing-the-web-with-web-bot-auth-preview-in-amazon-bedrock-agentcore-browser/
  31. Amazon Web Services. Reducing CAPTCHAs with Web Bot Auth - Amazon Bedrock AgentCore (Amazon Bedrock AgentCore Developer Guide, checked 29 October 2026): "Reducing CAPTCHAs with Web Bot Auth - Amazon Bedrock AgentCore" — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-web-bot-auth.html
  32. Amazon Web Services. AWS WAF announces Web Bot Auth support - AWS (21 November 2025): "Web Bot Auth is used as a verification method for verified bots and signed agents. It relies on two active IETF drafts: a directory draft allowing the crawler to share their public keys, and a protocol draft defining how these keys should be used to attach crawler's identity to HTTP requests. AWS WAF now automatically allows verified AI agent traffic. Verified WBA bots will now be automatically allowed by default." — https://aws.amazon.com/about-aws/whats-new/2025/11/aws-waf-web-bot-auth-support/
  33. Cloudflare Docs. Web Bot Auth · Cloudflare bot solutions docs (last updated 8 October 2026): "Web Bot Auth is an authentication method that leverages cryptographic signatures in HTTP messages to verify that a request comes from an automated bot. Web Bot Auth is used as a verification method for verified bots and agents." — https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/
  34. WebBotAuth.net. What is a Signature Agent Card? - WebBotAuth.net (independent Web Bot Auth checker documentation, checked 29 October 2026): "At least one parameter must be set for the card to count as a card. The previous version, registry-02, put every field at the top level; the checker reads both shapes. How the checker treats it Agent Card checks are advisory. A missing or incomplete card lowers the score slightly and raises notes, but it never changes the verdict and never caps the grade. A directory with valid keys is still VALID even with no card at all." "Unlike the JWKS directory, which is always at /.well-known/http-message-signatures-directory, the Signature Agent Card has no fixed well-known location. It is found through its client_id URL, which a signed request can name directly with a Signature-Agent member of type=cimd, or listed in a registry. This checker finds it from the directory's Link header or a homepage <link> element; it does not resolve type=cimd members yet." — https://webbotauth.net/kb/signature-agent-card
  35. Thibault Meunier (Cloudflare) and Sandor Major (Google). `draft-ietf-webbotauth-httpsig-protocol-00` — 'HTTP Message Signatures for automated traffic' (IETF `webbotauth` Working Group Internet-Draft, 1 September 2026): "None of these options constitute redistribution. Nor is a list that names directory URLs rather than embedding keys. For instance, [REGISTRY] works that way, and the verifier still resolves them." — https://www.ietf.org/archive/id/draft-ietf-webbotauth-httpsig-protocol-00.txt
  36. S. Singh. `draft-singh-webbotauth-hosted-directories-00` — 'Hosted Key Directories for Web Bot Auth' (IETF Internet-Draft, 19 July 2026): "The registry document [I-D.meunier-webbotauth-registry] supplies discovery mechanics for this ecosystem: per-agent metadata cards, and registries that list them, which it explicitly contemplates being maintained by third parties. It deliberately leaves trust and accreditation policy to implementers." "3. Per-tenant metadata via Signature Agent Cards. The registry document [I-D.meunier-webbotauth-registry] defines a per-agent metadata card resolvable from a stable URL, with key material separable via jwks_uri. Pairing a hosted directory with one card per tenant expresses tenancy explicitly without new protocol elements. This document suggests the working group consider making that pairing normative guidance for shared directories." — https://www.ietf.org/archive/id/draft-singh-webbotauth-hosted-directories-00.txt
  37. Joel Hillier (Certisyn, Inc.). `draft-hillier-scitt-arp-06` — 'Attestation Reconciliation Protocol' (IETF Internet-Draft, 23 October 2026): "Where a reconciliation is requested over HTTP by an autonomous agent, the request MUST be signed under HTTP Message Signatures [RFC9421], with the signature-agent key resolvable through a Web Bot Auth signature-agent card [I-D.meunier-webbotauth-registry], advertised via the Signature-Agent header [I-D.ietf-webbotauth-httpsig-protocol], which also defines the key directory it names." — https://www.ietf.org/archive/id/draft-hillier-scitt-arp-06.txt
  38. Carsten Rehfeld. `draft-rehfeld-apix-core-00` — 'API Index (APIX) Core Infrastructure for Autonomous Agent Service Discovery' (IETF Internet-Draft, April 2026): "[I-D.meunier-webbotauth-registry] Guerreiro, M., Kirazci, U., and T. Meunier, "Registry and Signature Agent card for Web bot auth", Work in Progress, Internet-Draft, draft-meunier-webbotauth-registry-01, 20 October 2025" — https://www.ietf.org/archive/id/draft-rehfeld-apix-core-00.txt
  39. Carsten Rehfeld. `draft-rehfeld-apix-services-00` — 'APIX Services Profile Discovery Infrastructure for Web API and Bot Services' (IETF Internet-Draft, April 2026): "[I-D.meunier-webbotauth-registry]" — https://www.ietf.org/archive/id/draft-rehfeld-apix-services-00.txt
  40. Gary Illyes. `draft-illyes-webbotauth-jafar-01` — 'A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients' (IETF Internet-Draft, 22 October 2026): "A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients" "draft-illyes-webbotauth-jafar-01" — https://www.ietf.org/archive/id/draft-illyes-webbotauth-jafar-01.txt
  41. Aaron Parecki (Okta) and Emelia Smith. `draft-ietf-oauth-client-id-metadata-document-02` — 'OAuth Client ID Metadata Document' (IETF OAuth Working Group Internet-Draft, 6 July 2026): "This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration." — https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.txt
  42. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, and P. Hunt. `RFC 7591` — 'OAuth 2.0 Dynamic Client Registration Protocol' (IETF Standards Track, July 2015): "This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers." — https://www.rfc-editor.org/rfc/rfc7591.html
  43. A. Backman, Ed., J. Richer, Ed., and M. Sporny. RFC 9421: HTTP Message Signatures (IETF Standards Track, February 2024): "This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message." — https://www.rfc-editor.org/rfc/rfc9421.html
  44. M. Jones. `RFC 7517` — 'JSON Web Key (JWK)' (IETF Standards Track, May 2015): "A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs." — https://www.rfc-editor.org/rfc/rfc7517.html
  45. M. Koster, G. Illyes, H. Zeller, and L. Sassman. RFC 9309: Robots Exclusion Protocol (IETF Standards Track, September 2022): "This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers." — https://www.rfc-editor.org/rfc/rfc9309.html

JSON · Markdown · OKF v0.2