]> Cloudflare

ot-ietf@thibault.uk

Google

ietf@sandormajor.com

Web and Internet Transport Web Bot Auth not-yet This document describes an architecture for identifying automated traffic using . The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Bot Auth Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Agents are increasingly used in business and user workflows, including AI assistants, search indexing, content aggregation, and automated testing. These agents need to reliably identify themselves to origins for several reasons:

1. Regulatory compliance requiring transparency of automated systems
2. Origin resource management and access control
3. Protection against impersonation and reputation management
4. Service level differentiation between human and automated traffic

Current identification methods such as IP allowlisting, User-Agent strings, or shared API keys have significant limitations in security, scalability, and manageability. This document defines an architecture enabling agents to cryptographically identify themselves using . It proposes that every request from bots be signed by a private key owned by its provider. This way, every origin can validate the service identity.

Motivation There is an increase in agent traffic on the Internet. Many agents choose to identify their traffic today via IP Address lists and/or unique User-Agents. This is often done to demonstrate trust and safety claims, support allowlisting/denylisting the traffic in a granular manor, and enable sites to monitor and rate limit per agent operator. However, these mechanisms have drawbacks:

1. User-Agent, when used alone, can be spoofed meaning anyone may attempt to act as that agent. It is also overloaded - an agent may be using Chromium and wish to present itself as such to ensure rendering works, yet it still wants to differentiate its traffic to the site.
2. IP blocks alone can present a confusing story. IPs on cloud plaforms have layers of ownership - the platform owns the IP and registers it in their published IP blocks, only to be re-published by the agent with little to bind the publication to the actual service provider that may be renting infra. Purchasing dedicated IP blocks is expensive, time consuming, and requires significant specialist knowledge to set up. These IP blocks may have prior reputation history that needs to be carefully inspected and managed before purchase and use.
3. An agent may go to every website on the Internet and share a secret with them like a Bearer from . This is impractical to scale for any agent beyond select partnerships, and insecure, as key rotation is challenging and becomes less secure as the consumers scale.

Using well-established cryptography, we can instead define a simple and secure mechanism that empowers small and large agents to share their identity.

HTTP layer choice This architecture operates solely at the HTTP layer. It allows signatures to be generated and verified without modifying the transport layer or TLS stack. It enables flexible deployment across proxies, gateways, and origin servers, and aligns with existing tooling and infrastructure that already inspect and manipulate HTTP headers. Because the signature is embedded in the request itself, it travels with the message through intermediaries, preserving end-to-end verifiability even when requests are forwarded or transformed within the HTTP layer.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document:

User

An entity initiating requests through an agent. May be a human operator or another system.

Agent

An orchestrated user agent (e.g. Chromium, CURL). It implements the HTTP protocol and constructs valid HTTP requests with signatures.

Origin

An HTTP server receiving signed requests that implements the HTTP protocol and verifies signatures. It acts as a verifier of the signature as defined by .

Architecture | | | | | | material | | | User +--- Request -->| Agent | | Origin | | | | +--- Request + Signature -->| | | | | |<-------- Response --------+ | | |<-- Response --+ | | | | | | | | | +--------+ +---------+ +----------+ ]]> A User initiates an action requiring the Agent to perform an HTTP request. The Agent constructs the request, generates a signature using its signing key, and includes it in the request as defined in along with the Signature-Agent header for discovery of its verification key. Upon receiving the request, the Origin ensures it has the verification key for the Agent, validates the signature, and processes the request if the signature is valid.

Deployment Models Signature verification can be performed either directly by origins or delegated to a fronting proxy. Direct verification by origins provides simplicity and control. Proxy verification offloads processing and enables shared caching across multiple origins. The choice depends on traffic volume and operational requirements.

Generating HTTP Message Signature defines components to be signed. Agents MUST include at least one of the following components:

@authority

as defined in

@target-uri

as defined in

Agents MUST include the following @signature-params as defined in

created

as defined in

expires

as defined in

keyid

MUST be a base64url JWK SHA-256 Thumbprint as defined in for RSA and EC, and in for ed25519.

tag

MUST be web-bot-auth

The signing key is available to the agent at request time. Algorithms should be registered with IANA as part of HTTP Message Signatures Algorithm registry. The creation of the signature is defined in . It is RECOMMENDED the expiry to be no more than 24 hours.

Signature-Agent Signature-Agent is an HTTP Method context header defined in Section 4.1 of . It is RECOMMENDED that the Agent sends requests with Signature-Agent header, as described in . If the header is to be sent, one of its members MUST be signed as a component as defined in . The Signature-Agent member identifies where candidate key material can be found. The key used to verify the signature is selected by the keyid parameter of the corresponding Signature-Input member. This results in the following components to be signed It is RECOMMENDED that the key matches the signature label.

Multiple signatures A request MAY contain more than one Web Bot Auth signature. Each signature is identified by its HTTP Message Signatures label. When Signature-Agent is present, each signer SHOULD provide a Signature-Agent member for its label. A signer MAY cover selected members from another signature label, including "signature";key=..., "signature-input";key=..., and "signature-agent";key=.... This lets a signer preserve evidence that another signer contributed to the request. This records which parties signed which fields. It does not, by itself, express authorization, delegation, or consent. Those meanings are deployment policy or are carried in separately signed fields. The delegation examples in cover a different problem: how key material can show delegation. Multiple signatures only show which signatures were present and what they covered.

Anti-replay Origins MAY want to prevent signatures from being spoofed or used multiple times by bad actors and thus require a nonce to be added to the @signature-params. This is described in . Agents SHOULD extend @signature-parameters defined in as follows:

nonce

base64url encoded random byte array. It is RECOMMENDED to use a 64-byte array.

Client MUST ensure that this nonce is unique for the validity window of the signature, as defined by created and expires attributes.

Additional headers Agents MAY include additional components, such as specific HTTP headers, in the signature. This can be prompted by the origin requesting additional headers, as described in , or initiated by the agent to provide more information within the signature scope. For example, an agent might include an HTTP header expressing its intent and sign it. Origins MAY ignore certain headers at their own discretion, and request a new signature, as described in .

Sending a request An Agent SHOULD send a request with the signature generated above. Updating the architecture diagram, the flow looks as follow. | | | | material | | | Agent | | Origin | | | .-------------------------------------------------------------------. | | | +-----| GET /path/to/resource |------->| | | | | Signature: sig=abc== | | | +---------+ | Signature-Input: sig=("@authority" "signature-agent";key="sig");\ | +----------+ | created=1700000000;\ | | expires=1700011111;\ | | keyid="ba3e64==";\ | | tag="web-bot-auth" | | Signature-Agent: sig="https://signer.example.com" | '-------------------------------------------------------------------' ]]> The Agent SHOULD send requests with two headers

1. Signature defined in
2. Signature-Input defined in

Mentioned in , the Agent MAY send requests with Signature-Agent header.

Requesting a Message signature defines the Accept-Signature field which can be used to request a Message Signature from a client by an origin. An Origin MAY choose to request signatures from clients that did not initially provide them. If requesting, Origins MUST use the same parameters as those defined by the . The status code SHOULD be 403 Forbidden as defined in . Origin MAY request a new signature with tag "web-bot-auth" even if a nonce is provided, for example if it believes the nonce is a replay, or if it doesn't store nonces and thus requests new signatures every time. The status code SHOULD be 429 Too Many Requests as defined in .

Validating Message signature Upon receiving an HTTP request, the origin has to verify the signature. The algorithm is provided in . Similar to a regular User-Agent check, this happens at the HTTP layer, once headers are received. Additional requirements are placed on this validation:

• During step 1 to 3 included, if the Origin fails to parse the provided Signature, Signature-Input, or Signature-Agent headers, it MAY respond with status code 400 Bad Request as defined in .
• During step 4, the Origin MAY discard signatures for which the tag is not set to web-bot-auth.
• During step 5, the Origin MAY discard signatures for which they do not know the keyid.
• During step 5, if the keyid is unknown to the origin, they MAY fetch key material as indicated by the Signature-Agent header defined in Section 4 of .

Origin MAY require the nonce to satisfy certain constraints: be globally unique using a global nonce store, be unique to a specific location or time window using a local cache, or no constraint at all.

Key Distribution and Discovery This section describes key discovery for the agent. The reference for discovery is a URL. It SHOULD be an HTTPS URL. The Signature-Agent header defines typed discovery. This architecture uses these types:

directory

Resolve the HTTP Message Signatures Directory at the well-known URI registered in . This is the default when no type parameter is present.

jwks_uri

Resolve the member value as a direct JWK Set URI.

cimd

Resolve the member value as a Client ID Metadata Document URI. The document then provides key material through jwks or jwks_uri.

For all types, the key is selected using the keyid parameter in Signature-Input. Examples: Example:

Out-of-band communication between client and origin A service submitting their key to an origin, or the origin manually adding a service to their trusted list.

Public list Could be a GitHub repository like the public suffix list. The issue is the gating of such repositories, and therefore its governance.

Signature-Agent header This allows for backward compatibility with existing header agent filtering, and an upgrade to a cryptographically secured protocol. See for more details.

Signature-Key header defines a separate key discovery header for HTTP Message Signatures. Deployments MAY use it when they need that model. This architecture uses Signature-Agent as its default discovery mechanism.

Session Protocol Considerations Per-request signature generation and verification may incur computational overhead from cryptographic operations and key discovery. For high-frequency interactions, origins might establish sessions to reduce repeated verification. One approach: after successful signature verification, an origin issues a session credential (e.g., an HTTP cookie) that subsequent requests present in lieu of a full signature. This trades cryptographic verification costs for the security properties of bearer tokens, including susceptibility to credential theft and replay within the session lifetime. The design of session protocols, including appropriate session lifetimes and binding mechanisms, is out of scope for this document.

Security Considerations

Use of TLS We reassess . Clients SHOULD use TLS (https) or equivalent transport security when making requests with Message signatures. Failing to do so exposes the Message signature to numerous attacks that could give attackers unintended access. This include reverse proxy and their consideration presented in . An origin SHOULD refuse Signature headers when communicated over an unsecured channel.

Performance Impact Origins should account for the overhead of signature verification in their operations. A local cache of public keys reduces network requests and verification latency. The choice of signing algorithm impacts CPU requirements. Origins should monitor verification latency and set appropriate timeouts to maintain service levels under load.

Nonce validation Clients control the nonce. While mandates that clients MUST provide a globally unique nonce, it is the origin's responsibility to enforce it. Different validation policies have different performance and operational considerations. Global uniqueness requires a global nonce store. Some origins may find that their use case can tolerate sharding on location, timing, or other properties.

Key Compromise Response An agent signing key might get compromised. If that happens, the agent SHOULD cease using the compromised key as soon as possible, notify affected origins if possible, and generate a new key pair. To minimise the impact of a key compromise, the origin should support rapid key rotation and monitor for suspicious signature patterns.

Shared Secrets Considered Harmful Implementations MUST NOT use shared HMAC defined in . Shared secrets break non-repudiation and make auditing difficult. Each automated client SHOULD use a unique asymmetric keypair to ensure attribution, support key rotation, and enable effective revocation if needed.

Key Reuse Considered Harmful Implementations SHOULD NOT reuse a signing key for different purposes. For example, if an agent implementor has two agents they want to differentiate, these should use distinct signing keys and signing key directories.

Reverse proxy consideration An origin may be placed behind a reverse proxy, which means the proxy will see the Signature and Signature-Agent headers before the origin does. A proxy SHOULD NOT strip the Signature or Signature-Agent headers from requests. A proxy SHOULD NOT replay signatures against other reverse proxies used by the origin, as this allows impersonation of the principal signature agent. Origins MAY require a specific nonce policy to prevent such malicious behaviour and decide to validate the signature themselves. This has to be done in accordance with . For example, an origin could require a nonce derived from public information (such as the current date), mandate nonce chaining (where each nonce is the hash of the previous one), or provide its own nonce in an Accept-Signature response to challenge the agent. Such policies MAY incur additional round-trip between the client and the origin to convey accept-signature header, or deployment specific exchanges.

Signature-Agent labeling An intermediary is allowed to relabel an existing signature when processing the message, per . This MAY apply to Signature-Agent, when included in the request as defined in , An intermediary updating the member key MUST update the components of the associated signatures accordingly. For instance, an intermediary updating the Signature-Agent from agent2 to agent3 on the example provided in would result in the following Signature, Signature-Input, and Signature-Agent header fields after recomputing the signature. Signature-Agent, Signature-Input, and Signature all reflect the update from agent2 to agent3.

Server-Side Request Forgery (SSRF) As described in , verifiers may fetch key directories based on the value conveyed in Signature-Agent when included in a request. Since clients control the Signature-Agent header value, this introduces a risk of server-side request forgery (SSRF) attacks by malicious clients. Verifiers SHOULD take appropriate precautions as follows:

Response size

a directory can be arbitrarily large. Verifiers SHOULD reject responses exceeding a defined byte limit after content decoding.

Key count

a JWKS with many keys forces O(n) key search. Verifiers SHOULD enforce a maximum key count.

Fetch latency

no timeout allows slowloris-style exhaustion. Verifiers SHOULD apply a wall-clock timeout to directory fetches.

Redirect chains

unbounded HTTP redirects can be used to amplify requests. Verifiers SHOULD limit redirect depth.

Network address ranges

no address filtering can target internal services. Verifiers SHOULD prevent directory fetches to private, loopback, and link-local address ranges.

Further recommendations can be found in the Open Worldwide Application Security Project (OWASP) SSRF Prevention Cheat Sheet .

Test and Demonstration Keys Test keys, including the example keys in , MUST NOT be used in production. Verifiers SHOULD reject known test keys when they are detected in key directories or out-of-band configuration.

Static Signatures Deployments MUST NOT treat a precomputed Web Bot Auth signature as a long-lived access credential. A reusable static signature has bearer-token semantics and can be replayed until the covered signature parameters, key, or verifier policy make it unusable. Agents SHOULD generate signatures for the request being sent, with bounded created and expires values. Long expiration windows increase replay risk.

Discovery Failure Failure to fetch or validate a key directory, beyond the directory cache window discussed in , means that the asserted identity is not verified. It does not prove that the signer is malicious, and it does not make the request trusted. The resulting enforcement decision is local policy.

Privacy Considerations

Public Identity This architecture assumes that automated clients identify themselves explicitly using digital signatures. The identity associated with a signing key is expected to be publicly discoverable for verification purposes. This reduces anonymity and allows receivers to associate requests with specific agents. If an agent wishes not to identify itself, this is not the right choice of protocol for it.

No Human Correlation The key used for signing MUST NOT be tied to a specific human individual. Keys SHOULD represent a role, company, or automation identity (e.g., "news-aggregator- bot", "example-crawler-v1"). This avoids accidental exposure of personally identifiable information and prevents the misuse of keys for user tracking or profiling.

Minimizing Tracking Risks To limit tracking risks, implementations SHOULD avoid long-lived, globally unique key identifiers unless strictly necessary. Key rotation SHOULD be supported, and clients SHOULD take care to avoid signing information that could be used to correlate activity across contexts, especially where sensitive user data is involved.

IANA Considerations This document has no IANA actions.

References Normative References Cloudflare Google This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as a new HTTP Method Context for in-band key discovery. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Okta 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. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. n.d. Hellō Cloudflare This document defines two HTTP header fields and one Accept-Signature parameter for use with HTTP Message Signatures as defined in RFC 9421. The Signature-Key request header distributes public keys used to verify signatures, with five initial key distribution schemes: pseudonymous inline keys (hwk), self-issued key delegation via JWK Thumbprint JWTs (jkt-jwt), identified signers with JWKS URI discovery (jwks_uri), JWT-based delegation (jwt), and X.509 certificate chains (x509). The sigkey parameter extends Accept-Signature (RFC 9421 Section 5) to indicate the type of Signature-Key the server requires. The Signature-Error response header provides structured error information when signature verification fails. Together, these mechanisms enable flexible trust models ranging from privacy- preserving pseudonymous verification to horizontally-scalable delegated authentication and PKI-based identity chains.

Deployment Guidance This appendix is operational guidance. It does not define new protocol requirements.

Verifier Outcomes Verifiers should keep three outcomes distinct:

verified

the signature and key material validate.

invalid

the signature, covered components, key, or freshness checks fail.

unverified

the verifier cannot obtain enough information to decide, for example because directory discovery failed or the key is unknown.

Origins can apply local policy to each outcome. During deployment, treating unverified as one bot-management signal is safer than treating it as either verified or invalid.

Directory Availability Directory resources are bootstrap material. Operators serving a directory should make it reachable without requiring Web Bot Auth on the directory request. They should also avoid bot protection rules that block ordinary verifier fetches of the well-known resource. The directory endpoint should support GET. Supporting HEAD, ETag, Last-Modified, Cache-Control, and conditional requests can reduce fetch load. Cache is specifically discussed in .

Bounded Directory Fetches Verifiers fetch directories named by untrusted requests. Fetches should be bounded as described in . In particular, verifiers should use a fetch timeout, bound the decoded response size, bound the number of keys considered, limit redirects, and prevent fetches to private, loopback, and link-local addresses. Verifiers should also coalesce concurrent fetches for the same directory and apply per-directory or per-origin concurrency limits. This avoids a fetch storm when many requests reference the same uncached directory.

Cache Behaviour Verifiers should use normal HTTP caching semantics for key directories. In particular, verifiers should respect Cache-Control, Expires, Date, ETag, and Last-Modified when present. A verifier should not fetch the directory for every request. It should refresh cached directories when they become stale, and can use background refresh with jitter to avoid synchronized refetches.

Negative Caching and Retry Verifiers can cache unsuccessful discovery outcomes for a short period to reduce repeated fetches. Negative cache entries should expire after no more than five minutes. They are operational throttling state, not proof that a signature is invalid. Network failures, TLS failures, and 5xx responses should be treated as transient unless local policy says otherwise. Verifiers should retry with bounded exponential backoff and jitter. When a directory response includes Retry-After, verifiers should respect it as described by and .

Freshness and Replay Shorter signature lifetimes reduce replay risk but increase sensitivity to clock skew and signing failures. Nonces provide stronger replay defense, but require state at the verifier. Some deployments can tolerate bounded replay for short windows; others need strict . These choices are deployment policy. Verifiers should avoid accepting signatures with freshness windows longer than their risk model permits.

Rollout and Fallback Web Bot Auth deployments will coexist with existing bot identification signals during rollout. Verifiers can continue to use existing methods such as IP-based checks, forward-confirmed reverse DNS, local allowlists, and reputation systems. Fallback should not turn an unsupported or unverifiable Web Bot Auth signature into a trusted identity. It should leave the request in the origin's existing bot-management path.

Proxies and Intermediaries Proxies and intermediaries need to preserve the fields covered by a signature if the origin will verify that signature. If a proxy rewrites the authority, path, or signed header fields, the origin may no longer see the message that was signed. A deployment can instead verify at the proxy and pass the result to the origin through a deployment-local trusted channel. That assertion is local policy; it is not a replacement for the original HTTP Message Signature.

CORS Key directories contain public key material. If browser-based verifiers need to fetch them cross-origin, a directory server can use a permissive CORS policy such as Access-Control-Allow-Origin: * without credentials. CORS is not key authentication and does not replace signature validation.

Deployment Anti-Patterns Deployments should avoid:

• using test or demonstration keys in production
• issuing one static signature for many requests
• asking users to copy long-lived signatures into third-party tools
• sharing one signing key across unrelated agents or purposes
• relying on manual key rotation as the only revocation mechanism

Examples

Multiple signatures with a remote browser This example shows Alice's agent using a remote browser to fetch a resource. The agent signs selected request fields. The remote browser signs the request it sends to the origin and also covers the agent's signature fields. The signature values are illustrative; this is not a test vector. The origin can verify both signatures. The agent signature covers the fields selected by Alice's agent. The browser signature covers the request sent by the remote browser, its own Signature-Agent member, and the agent signature fields. This records that the remote browser forwarded a request carrying the agent's signature. It does not say that Alice's agent authorized the remote browser to act for it.

Test Vectors

RSASSA-PSS Using SHA-512 The test vectors in this section use the RSA-PSS key defined in . This section includes non-normative test vectors that may be used as test cases to validate implementation correctness.

Signature-Agent absent from the request This example presents a minimal signature using the rsa-pss-sha512 algorithm over test-request. The request does not contain a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig1:

Signature-Agent included present on the request This example presents a minimal signature using the rsa-pss-sha512 algorithm over test-request. The request contains a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig2:

Legacy Signature-Agent (sf-string instead of sf-dictionary) included present on the request THIS IS A LEGACY EXAMPLE. IF YOU ARE AN IMPLEMENTER, PLEASE UPDATE TO THE ABOVE. This example presents a minimal signature using the rsa-pss-sha512 algorithm over test-request. The request contains a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig2:

EdDSA Using Curve edwards25519 The test vectors in this section use the Ed25519 key defined in . This section include non-normative test vectors that may be used as test cases to validate implementation correctness.

Signature-Agent absent from the request This example presents a minimal signature using the ed25519 algorithm over test-request. The request does not contain a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig1:

Signature-Agent included present on the request This example presents a minimal signature using the ed25519 algorithm over test-request. The request contains a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig2:

Legacy Signature-Agent (sf-string instead of sf-dictionary) included present on the request THIS IS A LEGACY EXAMPLE. IF YOU ARE AN IMPLEMENTER, PLEASE UPDATE TO THE ABOVE. This example presents a minimal signature using the ed25519 algorithm over test-request. The request contains a Signature-Agent header. The corresponding signature base is: This results in the following Signature-Input and Signature header fields being added to the message under the label sig2:

Implementations This draft has a couple of public implementations. A demonstration server has been deployed to https://http-message-signatures-example.research.cloudflare.com/. It uses ed25519 example signing and verifying keys defined in .

Clients draft-meunier-webbotauth-httpsig-protocol-00

• Chrome MV3 (TypeScript)
• Cloudflare Workers (TypeScript)
• Rust binaries (Rust)

draft-meunier-web-bot-auth-architecture-03

• Puppeteer script (JavaScript)
• Guzzle middleware (PHP)
• Python script (Python)
• Bot-Authentication (Python)
• HTTPie plugin (Python)
• Web scrapers (scrapy/crawl4ai) (Python)
• HUMAN Verified AI Agents (Python)
• Linzer (Ruby)

Servers draft-meunier-webbotauth-httpsig-protocol-00

• Cloudflare Workers (TypeScript)

draft-meunier-web-bot-auth-architecture-03

• Caddy plugin (Go)
• Apache module (C)

Test vectors

• In JSON format

Acknowledgments The editor would also like to thank the following individuals (listed in alphabetical order) for feedback, insight, and implementation of this document - Marwan Fayed, Maxime Guerreiro, Scott Hendrickson, Jonathan Hoyland, Mark Nottingham, Eugenio Panero, Lucas Pardue, Malte Ubl, Loganaden Velvindron, Tanya Verma.

Changelog draft-meunier-webbotauth-httpsig-protocol-00

• Rename draft from draft-meunier-web-bot-auth-architecture.
• Add SSRF guidance for Signature-Agent directory fetches.
• Add deployment guidance for verifier outcomes, directory fetches, caching, retry, rollout, proxies, CORS, and observability.
• Add guidance for test keys, static signatures, and discovery failures.
• Add multiple Web Bot Auth signatures and an example.
• Add typed Signature-Agent discovery examples for directory, jwks_uri, and cimd.
• Group implementations by the draft version that added them.
• Clarify that Signature-Input keyid selects the key and Signature-Agent points to candidate key material.
• Note Signature-Key as an optional discovery header.
• Align examples with published test-vector fixtures.
• Fix typos.

draft-meunier-web-bot-auth-architecture-05

• Add Sandor Major as an author.
• Add session protocol considerations.
• Update HTTP Message Signatures test vectors.
• Keep legacy Signature-Agent string examples for implementers migrating to dictionary members.

draft-meunier-web-bot-auth-architecture-04

• Change Signature-Agent to a Structured Fields dictionary.
• Add a security consideration for intermediaries that relabel Signature-Agent members.
• Allow @target-uri as a replacement for @authority.
• Add contributors.
• Add implementations.
• Remove the purpose field from the Web Bot Auth example.

draft-meunier-web-bot-auth-architecture-03

• Update the Linzer example URL.
• Fix the section reference and name for status code 429.
• Fix typos.

draft-meunier-web-bot-auth-architecture-02

• Add response status codes.
• Add references for readability.
• Add text about signing extra headers.
• Add TLS guidance to Security Considerations.
• Add RSASSA-PSS examples.
• Update acknowledgments.
• Add PHP, Python, Ruby, and Rust implementations.
• Fix Signature-Agent in the architecture diagram to use Structured Fields.
• Fix test vectors to use Structured Fields for Signature-Agent.
• Fix typos.

draft-meunier-web-bot-auth-architecture-01

• Require clients to sign Signature-Agent when it is present.
• Add test vectors for requests with and without Signature-Agent.
• Fix the example diagram.
• Add reverse proxy security considerations.
• Update text about why an origin may request a new signature.
• Update nonce validation wording and uniqueness requirements.
• Add acknowledgments.

draft-meunier-web-bot-auth-architecture-00

• Initial draft.
• Describe how to use HTTP Message Signatures to sign requests.
• Describe signature verification.
• Define the web-bot-auth tag.
• Derive keyid from the JWK Thumbprint.
• Add initial Security and Privacy Considerations.