]> Cloudflare

maxime.guerreiro@gmail.com

Amazon

ulaskira@amazon.com

Cloudflare

ot-ietf@thibault.uk

Web and Internet Transport Web Bot Auth not-yet This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using 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 , extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members. 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 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 . 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 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 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 draws from , 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.

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.

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 , the same parameter namespace used by . Web bot auth-specific information is carried in a single web_bot_auth object, defined in . Because the card reuses the 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. The Signature-Agent header is defined in . A Signature Agent Card can be referenced from that header using type=cimd, as described in . Unless otherwise specified, all parameters in this document are OPTIONAL, except that a card resolved through its client_id MUST carry client_id (see ). There MUST be at least one parameter set. Parameters for which the value is unknown MUST be ignored. All string values are UTF-8.

Client Metadata Parameters The following parameters are OAuth client metadata parameters defined in and used as in . They keep the semantics defined there; this section only notes how they are used by a Signature Agent.

client_id

A resolvable identifier for the Signature Agent. See .

client_name

A friendly name for the Signature Agent, e.g. ExampleBot.

client_uri

A URL of a web page describing the Signature Agent: what it does, and how it handles the data it fetches, e.g. https://example.com/bot/about.html.

logo_uri

A URL referencing a logo for the Signature Agent, for quick visual identification, e.g. https://example.com/logo.png.

contacts

An array of URIs providing reliable communication channels, typically email addresses, e.g. ["mailto:bot-support@example.com"].

jwks_uri

See .

jwks

A JWK Set as defined in . See .

Client ID The client_id parameter is the resolvable identity of the Signature Agent, as defined in . 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 (simple string comparison). Example

• https://example.com/bot

JWKS URI The jwks_uri parameter provides the URL of a JWK Set as defined in , following the semantics. does not mandate a media type for the resource at jwks_uri. 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 resource at jwks_uri SHOULD be signed using . Clients SHOULD validate the signature and ignore keys that do not carry a corresponding valid signature. The URI scheme MUST be https. Example

• https://example.com/.well-known/http-message-signatures-directory

JWKS The jwks parameter contains a JWK Set as defined in . It is the inline client metadata parameter defined in . If jwks is present, it is RECOMMENDED that the card is signed using . Content-Digest header MUST be included in the covered components. TODO: describe signature, CWS keys.

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

Expected user agent The expected-user-agent parameter specifies one or more User-Agent strings as defined in or prefix matches. Prefixes MAY use * as a wildcard. Example

• Mozilla/5.0 ExampleBot

robots.txt product token The rfc9309-product-token parameter specifies the product token used for robots.txt directives per . Example

• ExampleBot

robots.txt compliance The rfc9309-compliance parameter lists directives from robots.txt that the agent implements. Example

• ["User-Agent", "Disallow"]
• ["User-Agent", "Disallow", "CrawlDelay"]

Trigger The trigger parameter indicates the operational mode of the agent. Valid values:

1. fetcher - request initiated by the user
2. crawler - autonomous scanning

Purpose The purpose parameter describes the intended use of collected data. Values SHOULD be drawn from a controlled vocabulary, such as . Example

• search
• tdm

Targeted content The targeted-content parameter specifies the type of data the agent seeks. Its format is arbitrary UTF-8 encoded string. Example

• SEO analysis
• Vulnerability scanning
• Ads verification

Rate control The rate-control parameter indicates how origins can influence the agent’s request rate. TODO: specify a format Example

• CrawlDelay in robots.txt (non-standard)
• Custom tool
• 429 +

Rate expectation The rate-expectation parameter specifies anticipated request volume or burstiness. TODO: consider a format such as avg=10rps;max=100rps Example

• 500 rps
• Spikes during reindexing

Known URLs The known-urls parameter lists predictable endpoints accessed by the agent. These URLs may be absolute URLs like https://example.com/index.html. They could be relative path like /ads.txt. Or they can use * as wildcard such as *.png. Example

• ["/"]
• ["/ads.txt"]
• ["/favicon.ico"]
• ["/index.html"]

IP Address List URI The ips_uri parameter provides the URL of the signature agent's IP address list as defined in . The URI scheme MUST be https. Example

• https://example.com/ips.json

Discovery A Signature Agent Card is discovered by dereferencing its client_id, as described in , or from a registry. A registry is a list of URLs, each refering to a signature agent card. An entry MAY be the client_id of a Signature Agent Card. The URI scheme MUST be one of:

• https: Points to an HTTPS resource serving a signature agent card
• data: Contains an inline signature agent card

CIMD-based discovery A Signature Agent advertises its identity through a resolvable client_id URL, as defined in . A consumer discovers the agent's metadata and keys as follows:

1. Obtain a client_id URL, from a Signature-Agent header with type=cimd (), a registry entry, 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 ). The response is the Signature Agent Card.
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. Example

Formal Syntax Below is an Augmented Backus-Naur Form (ABNF) description, as described in . The below definition imports https-URI from , and dataurl from .

Out-of-band communication between client and origin A signature agent MAY submit their signature agent card to an origin, or the origin MAY manually add them to their local registry.

Registry Endpoint 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.

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. No specific authentication mechanism is mandated. Implementations MAY use pre-shared keys as mentioned in , bearer tokens as defined in , or HTTP Message Signatures as defined in . HTTP Message Signatures are RECOMMENDED when key rotation without out-of-band coordination is desired.

Efficient Polling with Conditional Requests Registry servers SHOULD include ETag and Last-Modified response header fields as defined in . Clients SHOULD send If-None-Match or If-Modified-Since precondition header fields as defined in on subsequent requests. A server SHOULD respond with 304 (Not Modified) when the registry has not changed, avoiding redundant data transfer.

Caching Registry servers SHOULD include a Cache-Control response header field as defined in to communicate the intended freshness lifetime of the registry content. Clients SHOULD respect these cache directives and SHOULD NOT poll more frequently than indicated.

Signature-Agent header When used for HTTP Message Signatures, a Signature Agent Card MAY be discovered via a Signature-Agent header member with type=cimd. The URI carried in that member is the client_id of a Signature Agent Card resolved as described in .

Composable discovery with Signature-Key The discovery in this document is anchored on the client_id URL and is independent of the header that carries it. defines a composable Signature-Key header with an extensible registry of key-distribution schemes. A future scheme could carry a client_id URL, letting a verifier resolve a Signature Agent Card per-signature alongside the keying material. This document does not define such a scheme; it is noted as a possible composable carrier.

Change Notification Pull-based consumption with conditional requests is sufficient for most deployments. When lower notification latency is required (e.g., to promptly act on entry removal), a registry operator MAY implement a push-based change notification mechanism.

Advertising the Notification Endpoint A registry operator that supports change notifications SHOULD advertise its notification endpoint in the registry HTTP response using a Link header field as defined in : ; rel="registry-changes" ]]> The registry-changes link relation identifies an endpoint to which clients may register callbacks out of band. TODO: Register the registry-changes link relation with IANA, or replace it with an extension relation URI.

Callback Registration Registration of a client callback URL with the registry operator is performed out of band. No specific registration protocol is defined by this document. An unsubscribe mechanism SHOULD be considered, and MAY also be out of band.

Notification Requests When an entry is added to or removed from the registry, the registry operator MUST send an HTTP request to each registered callback URL. The format in is as follows: TODO: should we use application/json, a new media-type, permit binary encoding? TODO: should signature-agent be an array? action denotes the operation performed on the registry: 1. put when a new entry has been added, 2. delete when an entry has been removed. The request MUST use POST. It MUST be signed using with a key present in the registry operator's existing signature agent card. This is the signature agent card associated with the registry operator during out-of-band callback registration. The Content-Type SHOULD be application/json. Example notification for an added entry:

Notification Processing Upon receiving a notification, the client MUST verify the HTTP Message Signature against the registry operator's key, discovered via the registry operator's signature-agent card. Notifications with missing or invalid signatures MUST be rejected. A notification is advisory only. The registry endpoint remains the authoritative source of truth. After verifying a put notification, clients SHOULD re-fetch the affected signature agent card to obtain current metadata. For delete notifications, clients SHOULD confirm the removal by re-fetching the full registry. This confirmation does not need to happen synchronously with notification processing. Registry operators SHOULD retry delivery of failed notifications with exponential backoff. Clients that miss notifications will recover on their next conditional pull from the registry endpoint.

Security Considerations Malicious actors may put properties which are not theirs in the registry. If signatures are present, clients MUST verify them. Clients SHOULD reject cards with invalid signatures.

Registry Integrity When a registry is served over HTTPS, TLS provides channel integrity between the server and the client. To additionally bind the registry contents to the registry operator's cryptographic identity, registry servers SHOULD sign their HTTP responses using with a key present in the registry operator's own signature agent card. Clients SHOULD verify such signatures when present.

Binding Delegated Keys to the Directory Authority When a signature agent card delegates key discovery using jwks_uri, clients SHOULD validate the referenced directory response to ensure the authenticity and integrity of the delegated key material. When a directory server provides key material over HTTP or HTTPS, it is RECOMMENDED that it include one HTTP Message Signature per key in the response, with each key used to provide one signature. The signature SHOULD cover @authority with the req flag set, and SHOULD include the created, expires, keyid, and tag signature parameters. The tag value MUST be http-message-signatures-directory. Clients SHOULD validate these signatures using the keys provided by the directory. Clients SHOULD ignore keys from a directory response that do not have a corresponding valid signature binding the key material to the directory authority.

Private Registries Registry endpoints that require authentication as described in limit exposure of registry entries to authorized clients only. Registry operators SHOULD use authenticated endpoints when the enumeration of their registry entries is sensitive.

Privacy Considerations TODO

Access Patterns Registry servers SHOULD avoid logging personally identifiable information from client requests. Clients fetching a registry reveal their interest in its entries; registry servers SHOULD treat access logs as sensitive.

IANA Considerations

OAuth Dynamic Client Registration Metadata Registration IANA is requested to register the following parameter in the "OAuth Dynamic Client Registration Metadata" registry established by .

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:

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.

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 .

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

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 (). Designated experts can reject registrations on the basis that they do not meet the security and privacy requirements defined in TODO.

Initial Registry content This section registers the web_bot_auth member names defined in in this registry.

Expected User Agent Parameter

Parameter Name:

expected-user-agent

Parameter Description:

String or fragment patterns

Change Controller:

IETF

Reference:

Notes:

N/A

RFC9309 Product Token Parameter

Parameter Name:

rfc9309-product-token

Parameter Description:

Robots.txt product token your signature-agent satisfies.

Change Controller:

IETF

Reference:

Notes:

N/A

RFC9309 Compliance Parameter

Parameter Name:

rfc9309-compliance

Parameter Description:

Does your signature-agent respect robots.txt.

Change Controller:

IETF

Reference:

Notes:

N/A

Trigger Parameter

Parameter Name:

trigger

Parameter Description:

Fetcher/Crawler

Change Controller:

IETF

Reference:

Notes:

N/A

Purpose Parameter

Parameter Name:

purpose

Parameter Description:

Intended use for the collected data

Change Controller:

IETF

Reference:

Notes:

N/A

Targeted Content Parameter

Parameter Name:

targeted-content

Parameter Description:

Type of data your agent seeks

Change Controller:

IETF

Reference:

Notes:

N/A

Rate control Parameter

Parameter Name:

rate-control

Parameter Description:

How can an origin control your crawl rate

Change Controller:

IETF

Reference:

Notes:

N/A

Rate expectation Parameter

Parameter Name:

rate-expectation

Parameter Description:

Expected traffic and intensity

Change Controller:

IETF

Reference:

Notes:

N/A

Known URLs Parameter

Parameter Name:

known-urls

Parameter Description:

Predictable endpoint accessed

Change Controller:

IETF

Reference:

Notes:

N/A

IP Address List URI Parameter

Parameter Name:

ips_uri

Parameter Description:

URL of the signature agent's IP address list in format.

Change Controller:

IETF

Reference:

Notes:

N/A

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Open Future Mozilla This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. 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] Independent This document defines a standardized JSON format for operators of automated HTTP clients (e.g., web crawlers, AI bots) to publicly disclose their IP address ranges. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases. 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. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. 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. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. 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. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Independent Ericsson Blind Five Year Old This document describes best practices for web crawlers. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/garyillyes/cbcp. A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK] 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] n.d. This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. Team Digitale, Italian Government Red Hat Microsoft This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. 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. 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. Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching. 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. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

Test Vectors TODO

Implementations TODO

Acknowledgments TODO The editor would also like to thank the following individuals (listed in alphabetical order) for feedback, insight, and implementation of this document -

Changelog draft-meunier-webbotauth-registry-03

• Make the Signature Agent Card an OAuth client metadata document with a web_bot_auth object.
• Add resolvable client_id discovery: GET, 200 OK, no redirects, and an exact client_id match.
• Allow Signature-Agent members with type=cimd and registry entries to point to a client_id URL.
• Register web_bot_auth in the OAuth Dynamic Client Registration Metadata registry.
• Move bot-specific fields into a new Web Bot Auth Metadata Parameters registry.
• Stop redefining shared client metadata fields; reference RFC 7591 instead.
• Drop the data:text/plain restriction on client_uri.
• Rename inline keys from keys to jwks to match OAuth client metadata.
• State that jwks_uri points to a JWK Set, without requiring a media type.
• Require client_id in a card resolved through its client_id.
• Require jwks and jwks_uri to be mutually exclusive.
• Restrict registry entries and resolvable cards to https.
• Say the jwks_uri resource SHOULD be signed using HTTP Message Signatures.
• Note Signature-Key as a possible carrier.

draft-meunier-webbotauth-registry-02

• Add ips_uri so a client can publish IP addresses.
• Add jwks_uri to separate key material from metadata.
• Fix the inline data URL example.
• Rename "Public list" to "Registry Endpoint".
• Add authentication guidance for private registry endpoints.
• Add conditional GET guidance using ETag and If-Modified-Since.
• Add caching guidance using HTTP-CACHE.
• Add change notifications using signed PUT and DELETE webhooks.
• Keep pull-based registry fetches as the source of truth.
• Add registry integrity and private registry guidance to Security Considerations.
• Add customer list exposure and access patterns to Privacy Considerations.
• Add RFC 8288 as a normative reference.

draft-meunier-webbotauth-registry-01

• Add contributors.
• Align the registry draft with the OAuth Dynamic Client Registration Metadata registry.
• Add an about URL field.
• Add ABNF for registry discovery.
• Clarify known URLs.
• Add a placeholder for image size.

draft-meunier-webbotauth-registry-00

• Initial draft.