Human Continuity for HTTP

Human Continuity for HTTP Tools for Humanity

aurelien.brezun@toolsforhumanity.com

proof of human human continuity unique human sybil resistance structured fields http message signatures This document defines an HTTP extension for origins that need to attribute repeated participation to the same verified unique human within a declared continuity scope, without requiring a global human identifier or replacing existing authentication. Within a continuity scope, the same human yields one verifier-local handle across all of their accounts, devices, and agents and cannot present as two, distinguishing the signal from authentication, which identifies a credential a human may hold many of. An origin server can publish policy for client-presented unique-human artifacts, issue an explicit challenge, and receive a client-presented artifact on a subsequent request. The framework is independent of any realm operator, credential technology, proof system, or definition of humanness. Companion profiles define artifact syntax, issuance, verification, challenge binding, replay behavior, holder binding, privacy properties, realm metadata, and verifier output. A conforming profile produces a verifier-local continuity_handle scoped to a realm, attestation audience, and purpose. This version defines no initial profile. 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 HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP APIs may benefit from supplemental request signals that are not equivalent to authenticating a user account. One such signal is that a request is backed by a verified unique human within a continuity scope selected by the verifier. Origins may use such a signal as an input to origin policy decisions, including duplicate account prevention, free-tier signup, per-human quotas, API quota grouping, Sybil-resistant participation, grant claims, trial credit claims, agent delegation, request prioritization, or measurement. Authentication and human continuity answer different questions. Origin authentication identifies an account, session, API key, mTLS identity, or other application principal. A single human can often create or control multiple authenticated accounts, devices, sessions, or agents, and a single authenticated account can sometimes be accessed by multiple humans or automated systems. Human continuity is a supplemental signal. It allows an origin to learn that two presentations, accounts, devices, sessions, or agents are backed by the same verified unique human within a declared continuity scope, without learning that human's global identity and without enabling cross-verifier correlation. Two properties set this mechanism apart. Against authentication, the continuity_handle is keyed to a verified unique human, not to a credential the subject controls, so within a scope a human has one handle and cannot present as two. Against unlinkable mechanisms such as Privacy Pass , it is controlled linkability: the verifier intentionally receives a stable verifier-local value within a scope rather than an unlinkable fact (). A profile that does not produce a verifier-local continuity_handle is not a conforming profile under this specification. Existing human-continuity integrations are generally origin-specific. Each origin defines its own discovery mechanism, challenge format, token format, and verification behavior. This creates fragmented client support and makes it difficult for browsers, mobile apps, agents, SDKs, API gateways, and other HTTP clients to interoperate. This document defines a small HTTP protocol for unique-human artifacts:

policy metadata can declare the accepted human-continuity purposes and unique-human profiles for request contexts;
an origin can issue an explicit challenge using Human-Continuity-Challenge;
a client can present a unique-human artifact using Human-Continuity;
a holder-bound profile can bind the artifact to a concrete HTTP request using HTTP Message Signatures ; and
origins and clients can discover policy metadata and realm metadata using well-known locations .

The protocol intentionally does not define a single global proof of human, identity system, realm governance model, or cryptographic proof format. Those details belong to unique-human profiles. The core protocol requires that a conforming profile provide scoped human continuity and defines how origins and clients discover, request, and transport those artifacts over HTTP. This document does not privilege any realm operator, issuance ceremony, biometric system, credential format, or verification technology. Unique-human mechanisms specific to a realm are specified as separate unique-human profiles conforming to the requirements in . This document is therefore a discovery, challenge, and transport substrate, not a complete unique-human system by itself.

Relationship to Existing Work

Relationship to Privacy Pass, ARC, and ACT Privacy Pass provides privacy-preserving token issuance and redemption for cases where the origin should learn an unlinkable fact rather than a stable continuity value. Anonymous Rate-Limited Credentials (ARC) similarly support unlinkable rate limiting, and Anonymous Credit Tokens (ACT) unlinkable credit issuance and spending. These mechanisms are complementary to this specification: defines the boundary between them and scoped human continuity.

Relationship to OAuth Protected Resource Metadata This specification also defines metadata for origin policy discovery, but it deliberately uses a different topology from OAuth 2.0 Protected Resource Metadata . Human-continuity policy can apply across many API paths and methods at one origin, so this document uses a single origin-level policy metadata document with policy selectors that select policies.

Relationship to HTTP Authentication Schemes An origin uses human continuity as an input to its own policy. Native authentication and authorization remain origin-defined. An authentication scheme identifies a credential the subject can hold many of, whereas a continuity_handle represents the backing human and cannot be forked into a second value within a scope (). An HTTP authentication scheme conveys its credential in the Authorization request field , which carries a single credential. A presentation defined as an authentication scheme therefore could not accompany an origin's native authentication on the same request; the PrivateToken scheme of the Privacy Pass HTTP authentication scheme , which redeems tokens in Authorization, is one such design. Presentations are commonly sent together with native authentication: the holder-bound example in carries Human-Continuity alongside Authorization: Bearer. This specification carries presentations in dedicated fields rather than defining or extending an authentication scheme, and does not use status 401 or 407 ().

Relationship to Credential Presentation Protocols OpenID for Verifiable Presentations and the W3C Digital Credentials API define how a verifier requests and obtains a credential presentation from a holder's wallet. This document adds origin-discoverable policy, challenges, and a scope-local continuity_handle that an origin can use to link valid presentations backed by the same verified human; each verified human has at most one handle in the scope (). BBS pseudonyms provide a stable per-verifier value from one credential and holder-held secrets, but leave one-per-human uniqueness at issuance, continuity after loss of those secrets, and HTTP policy discovery out of scope. defines when a presentation alone suffices. These protocols can provide artifact acquisition paths rather than alternatives to this document. A unique-human profile can, for example, define a credential format carried in an OpenID4VP presentation. The Digital Credentials API is mediated by the user agent and supports a fixed set of exchange protocols, so a profile using it also needs an invocation path for clients outside a browser. Version 0.2.0 of x401 gates a route on a verifier-composed, nonce-bearing proof request. The client obtains a credential presentation by executing the embedded Digital Credentials API request in a user agent or relaying it to another credential manager. The verifier can mint a short-lived, verifier-scoped bearer token recording its decision. That token expires; a continuity_handle instead identifies the same verified human across presentations, clients, and transports.

Relationship to Web Bot Auth Web Bot Auth authenticates the automated agent behind an HTTP request, using an HTTP Message Signature with the web-bot-auth tag and signing keys discovered through an HTTP Message Signatures Directory . The two mechanisms are complementary: Web Bot Auth identifies the agent, and Human Continuity links those requests to the unique human on whose behalf it acts. The two compose on the same agent request as independent HTTP Message Signatures, each carrying its own tag: a web-bot-auth signature and a holder-bound human-continuity signature can coexist, and a verifier selects the human-continuity signature by its tag (, ).

Applicability and Alternatives This specification is intended for origins that require verifier-local human continuity within a declared continuity scope. A successful presentation intentionally allows the verifier to determine that repeated presentations within the same (realm, attestation audience, purpose) tuple are backed by the same verified unique human, without requiring a global human identifier. Origins SHOULD NOT request Human-Continuity when an unlinkable authorization, redemption, rate-limit, or credit-spend mechanism is sufficient. The boundary between this specification and unlinkable mechanisms turns on where policy state lives and when policy is applied. Unlinkable capability systems fix a spendable allowance at issuance and decide each redemption against the artifact rather than the human. Privacy Pass , the Privacy Pass HTTP authentication scheme , ARC , and ACT issue tokens, bounded-use credentials, or credits. At redemption time, the verifier asks only whether the bearer presents a still-valid, not-yet-exhausted capability: that the client is authorized to proceed, has satisfied an issuance precondition such as solving a CAPTCHA, holds a spendable token or credit, has not double-spent it, or is within an anonymous rate limit. Human-Continuity instead allows policy to bind at decision time. The verifier can use mutable per-human state keyed by the resulting continuity_handle to recognize that a presentation is backed by the same verified unique human as an earlier presentation in the same declared continuity scope. That recognition is needed when a per-human rule may be applied, audited, or revised after artifacts are already in use. An unlinkable mechanism cannot express such a rule because it cannot distinguish repeated use by one human from use by several. Examples include duplicate account prevention, per-human quota grouping across accounts or sessions, Sybil-resistant participation, recovery-sensitive account workflows, grant or trial credit claims that require human continuity, and agent delegation policies that group activity by the backing human. For use cases involving allocation or abuse control, a scoped continuity_handle does not eliminate abuse; it changes the attacker's bottleneck from creating accounts to obtaining access to distinct verified humans. Unlinkable token, credential, and credit systems often require the client to retain token, credential, presentation, balance, refund, or other protocol state. Such systems can be appropriate for short-lived or single-device use cases, such as solving a CAPTCHA and redeeming a small number of tokens. They can be less suitable when the origin requires long-lived continuity, multi-device use, or recovery after loss of client state. Those requirements are a primary motivation for verifier-local human continuity, but they also increase privacy risk and therefore require narrow continuity scopes. A credential presentation alone shows that the subject holds a qualifying credential at presentation time. If that check suffices, a presentation protocol without this document is preferable. A client-stored linkable value, such as a long-lived cookie or bearer token, can also give a verifier a stable per-client value, but it derives its continuity from the client retaining and replaying one secret. A client can hold several such values to present as several distinct continuities, and losing the value loses the continuity. A continuity_handle instead derives from the verification of a unique human under a realm and is computed verifier-locally: within a scope a human has at most one, regardless of how many clients, accounts, or credentials they control, cannot obtain a second, and recovers the same value after loss of client state.

Conventions and Terminology 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 () () when, and only when, they appear in all capitals, as shown here. The two HTTP fields defined by this document use Structured Field Values . This document does not define separate ABNF for their field values. The field values are parsed according to , and this document adds semantic constraints on the parsed items and parameters. HTTP field names are case-insensitive . Examples in this document use conventional capitalization. When an HTTP field is covered by an HTTP Message Signature, the component identifier and canonicalization rules are those defined by . Long example lines that end with backslash use the single backslash line-wrapping convention from and are to be unfolded before interpreting the example. This specification uses two related terms deliberately, on two axes. A unique-human profile defines how a subject is established to be a verified unique human under a realm, and defines how the continuity_handle is derived. The Human-Continuity HTTP layer transports presentations that, when valid, yield a verifier-local continuity_handle. The two axes meet in the continuity scope: the unique-human profile establishes that the subject is a unique human, the continuity scope is where the resulting continuity holds, and the continuity_handle is comparable within it. The first valid presentation in a scope establishes the scoped comparison value; later valid presentations producing the same value are backed by the same verified unique human. Origin: The HTTP origin server that publishes policy for, challenges for, receives, and verifies human-continuity presentations. Client: An HTTP client, browser component, mobile app, agent tool, SDK, command-line tool, service, or other requester that can obtain or present a unique-human artifact. Realm: A URI identifying a human-continuity namespace. Within a realm, a conforming profile maps the same verified human to the same continuity_handle for a given attestation audience and purpose; different realms are distinct handle namespaces. A human-continuity realm is unrelated to the realm authentication parameter of HTTP authentication schemes (). Realm operator: The entity responsible for a realm. The realm operator publishes the realm's metadata and the verification material, if any, that a verifier uses to validate artifacts, and establishes the conditions under which artifacts are produced. For example, it can sign a context that is bound to the attestation audience and purpose and used for a proof request. In profiles where the realm operator generates the artifact directly, it can instead sign the artifact itself. A realm operator is not required to custody the subject's identity secret; in profiles that separate these roles, a user-controlled component defined by the profile holds the secret and produces the artifact locally. Unique-human artifact: A cryptographic object presented by the client and verified by the origin according to a unique-human profile. A valid artifact proves that the subject is a verified unique human and produces a continuity_handle for the selected continuity scope. This document does not define the cryptographic format of the artifact. Unique-human profile: A named specification that defines artifact syntax, issuance, verification, realm metadata, privacy properties, holder binding, challenge nonce binding, replay behavior, revocation behavior, continuity_handle derivation, and verifier output. This document also uses "profile" for this term. Profile identifier: A case-sensitive ASCII string that identifies a unique-human profile. It is carried as the positional String value of a Human-Continuity-Challenge list member, or as the Human-Continuity item value. Its syntax and naming rules are defined in . Attestation audience: The origin to which a unique-human artifact is bound and within which the resulting continuity_handle is interpreted. In this version, unless a future cross-origin delegation extension allows otherwise, the attestation audience is the canonical HTTPS origin of the request. Purpose: A string defined by origin policy that identifies the context in which human continuity is requested or accepted. This document uses "concrete purpose" when contrasting a purpose with the purpose templates in policy metadata (). Purpose template: The name of a purpose entry that authorizes a family of concrete purposes by prefix, defined in . A purpose template is not part of the continuity scope; the concrete purpose carried in Human-Continuity-Challenge or Human-Continuity is. Continuity scope: The tuple under which the same verified human is expected to produce the same continuity_handle. The continuity scope is the tuple (realm, attestation audience, purpose). continuity_handle: The profile-defined continuity value included in verifier output. Within a continuity scope, repeated valid presentations by the same verified human produce the same continuity_handle. Policy identifier: An origin-local token that names a policy definition in policy metadata. A policy identifier is selected for a request path and method. Policy selector: A policy metadata mapping that maps request path patterns for one HTTP method to policy identifiers. Challenge nonce: A verifier-generated value carried in the challenge parameter of Human-Continuity-Challenge () and bound by the selected profile according to . A challenge nonce is distinct from the nonce signature parameter defined by . Challenge context: The profile, effective realm, effective attestation audience, purpose, and requested presentation-assurance value, if any, for which a challenge nonce was issued (). Subject: The verified human that an artifact attests as unique; the human claimed to be a unique human. Holder: The party that controls the use of an artifact in presentations. The holder can be the subject, or a client or agent acting for a human. Holder key: A client-controlled signing key bound to an artifact by a holder-bound profile. Presentation: The act of attaching a unique-human artifact to an HTTP request. Holder-bound presentation: A presentation in which the client proves possession of a holder key by attaching an HTTP Message Signature over selected HTTP message components. Verifier: The origin-side component that parses and validates a human-continuity presentation and emits verifier output to origin policy. Verifier output: A structured local result produced by the verifier. defines its states and required contents.

Design Goals The protocol has the following design goals:

Scoped human continuity. The protocol provides verifier-local continuity across repeat presentations by the same verified human, exposed as a continuity_handle that is meaningful only within a declared continuity scope.
Realm and artifact neutrality. The HTTP exchange is independent of any particular realm operator, credential, zero-knowledge proof system, token format, or vendor.
Voluntary client participation. Clients can ignore policy metadata and challenges, and origins can define behavior for requests that omit human-continuity presentations.
Verifier-local operation. The design favors profiles that can be verified locally by the origin, without requiring a call to the realm operator on the request path.
Artifact theft resistance. The design favors holder binding for reusable artifacts so that artifact disclosure alone is insufficient for presentation.
Deterministic method and policy selection and authorization, with precise audience and purpose binding. Clients need deterministic selection of the policy identifier, attestation audience, purpose, and continuity scope to avoid origin confusion, method confusion, purpose broadening, and cross-origin realm injection.
Operation through ordinary HTTP infrastructure. The protocol should work with API gateways, CDNs, reverse proxies, browser CORS, mobile clients, agents, and SDKs, subject to the caching and header size considerations described in this document.

Non-Goals This document does not define:

what makes a user human, how humanness is determined, or a single proof-of-human ceremony;
a global human identity system or a global realm governance model;
a cryptographic artifact format or a mandatory profile;
device integrity, workload attestation, or generic remote attestation ;
cross-origin policy or attestation audience delegation;
a browser- or operating-system-transparent attachment mechanism;
a guarantee that requests backed by human continuity receive different service treatment.

Protocol Overview | | | policy metadata | | |<------------------------| | | ordinary request | | |------------------------>| | | challenge | | |<------------------------| | | issuance ceremony | | |-------------------------------------------------->| | unique-human artifact | | |<--------------------------------------------------| | send Human-Continuity | | | optional HTTP signature | | |------------------------>| | | | local verification | | | origin policy | ]]> Human-Continuity-Challenge is the only response field defined by this specification that requests a human-continuity presentation. An origin MAY send Human-Continuity-Challenge on any response to ask the client to obtain or present an artifact. A challenge carries a challenge nonce and has specific cache and replay semantics. A client that chooses to present an artifact sends Human-Continuity on a subsequent request. If the selected profile is holder-bound, the client also sends an HTTP Message Signature using Signature-Input and Signature as defined by . This protocol does not define OPTIONS as a general negotiation step. For a protected GET request, the origin can send Human-Continuity-Challenge on the GET response, and the client can retry the same GET with Human-Continuity. Cross-origin browser requests can involve CORS preflight for the actual request fields and methods, but that preflight is not a human-continuity challenge exchange. In typical exchanges, the client validates metadata and any challenge against policy metadata and realm metadata before issuance or presentation. The diagram shows policy metadata as a separate fetch that can happen before, during, or after the request being evaluated, depending on cache state. It omits realm metadata fetches for readability. The origin verifies the presentation according to the selected profile. A successful verification result for a conforming profile includes a verifier-local continuity_handle scoped by realm, attestation audience, and purpose. This document does not define the origin's final policy decision.

Attestation Audience and Purpose A unique-human artifact is meaningful only for the attestation audience and purpose for which it was issued or derived. Clients and origins therefore need deterministic policy identifier, attestation audience, purpose, and continuity scope rules.

Canonical HTTPS Origin The attestation audience for a request is the canonical HTTPS origin of that request. To determine the canonical HTTPS origin, determine the target URI's origin as defined by , Section 4.3.1, requiring the scheme to be "https", and serialize that origin using the ASCII serialization of an origin defined by , Section 6.2. Clients and verifiers MUST compare canonical HTTPS origins by exact string equality after this serialization. Therefore, the following inputs have the same canonical HTTPS origin: and the canonical HTTPS origin is: Profiles MAY reject IP-literal attestation audiences.

Policy Selection The effective policy identifier for a request is derived from the request method, request URI, and valid policy metadata. Policy identifiers are origin-local names, such as quota, recovery, or graphql. An origin can make a policy the default for requests not matched by a policy selector for the request method by publishing a default policy selector that maps the request method to that policy identifier. Configured policy metadata is configured metadata () provisioned for the request's canonical HTTPS origin. To determine the effective policy identifier for a request:

Compute the canonical HTTPS origin of the request according to .
Fetch policy metadata for that canonical HTTPS origin from the URL formed by appending /.well-known/human-continuity to the canonical HTTPS origin, use valid cached policy metadata from that location, or use valid configured policy metadata for that canonical HTTPS origin: The metadata document's origin member MUST exactly equal the canonical HTTPS origin of the request. If no valid configured policy metadata is used, absence of fetched policy metadata is established only when the response of the origin-level policy metadata fetch has status code 404 or 410. In that case, the origin has no metadata-derived human-continuity policy. A client MUST NOT obtain or present, and a verifier MUST NOT accept, a unique-human artifact for that request under this protocol.
Let request-method be the HTTP method of the request. A method selector matches only by exact HTTP method token equality. Method tokens are case-sensitive. The special relationship between GET and HEAD, if any, is not inferred by this protocol; origins that want the same policy for GET and HEAD MUST list both methods.
Let request-path be the path component of the request URI, excluding any query component. If the request URI has an empty path, request-path is "/".
A request path containing dot-segments, as defined by , Section 3.3, MUST NOT match any policy selector or default policy selector under this protocol. No policy identifier is selected for inline human-continuity fields or presentations, and the selection algorithm stops. Clients and verifiers MUST NOT accept Human-Continuity-Challenge or Human-Continuity for such a request unless a future extension defines safe normalization semantics.
Look up request-method in policy_selectors. If policy_selectors contains a member name equal to request-method, the method's policy selector map is the value of that member. Otherwise, request-method has no policy_selectors entry. If request-method has a policy_selectors entry and the method's policy selector map contains a non-wildcard member name that is exactly equal to request-path, the effective policy identifier is that member's value and the selection algorithm stops. Otherwise, if request-method has a policy_selectors entry, build the set of matching subtree pattern candidates from the method's policy selector map. If request-method has no policy_selectors entry, no subtree pattern candidate exists from policy_selectors for that method. Each candidate is a tuple of (matched path_pattern, policy identifier, specificity). For a subtree pattern ending in "/**", let base be the pattern with the final "**" removed. The base MUST NOT be "/". The pattern matches request-path if request-path begins with base. An origin that wants both a base path and its descendants to select the same policy identifier lists both patterns, such as "/account" and "/account/**". For example, "/account/**" matches "/account/" and "/account/settings", but does not match "/account" or "/accounting".
If one or more subtree pattern candidates exist, the effective policy identifier is the policy identifier selected by the candidate with the highest path specificity, and the selection algorithm stops. For a subtree pattern, specificity is the length of the prefix before "/**".
If no subtree pattern candidate exists, look up request-method in default_policy_selectors. If default_policy_selectors contains a member name equal to request-method and request-path does not begin with "/.well-known/", the effective policy identifier is that member's value. Otherwise, no policy identifier is selected for inline human-continuity fields or presentations. The client and verifier MUST NOT accept Human-Continuity-Challenge or Human-Continuity based on policy metadata for that request. The "/.well-known/" exclusion mirrors the prohibition on "/.well-known/" path patterns in policy selectors.

Policy selector matching is method-first. A policy selector listed under one method does not shadow a less-specific policy selector or default policy selector for another method. For example, if metadata contains a GET selector for "/account/**" and a POST selector for "/account/recovery/**", then GET /account/recovery/123 selects the less-specific GET selector for "/account/**". Policy selection is performed before evaluating profile, effective realm, effective attestation audience, purpose, or presentation-assurance constraints. After a policy identifier has been selected for the request method by a policy selector or default policy selector, a client or verifier MUST NOT fall back to a less-specific or default policy identifier merely because the selected policy does not authorize the inline values.

Cross-Origin Delegation and Audience Granularity Cross-origin delegated attestation audiences are out of scope for this document. An origin MUST NOT cause a client to obtain or present an artifact for a different origin's attestation audience. Cross-origin delegation requires a future extension that defines delegation metadata, authority checks, downgrade protections, and realm trust rules. Attestation audiences narrower than the canonical HTTPS origin, such as path-scoped same-origin resource identifiers, are likewise not defined by this version. A future extension can introduce narrower audiences as an optional policy metadata member without changing the HTTP fields defined by this document.

Effective Values and Continuity Scope For each challenge or presentation, the client and verifier determine the following values: For Human-Continuity-Challenge, the request used for policy selection is the request that generated the response containing the field. For Human-Continuity, the request used for policy selection is the request carrying the field. request method: For Human-Continuity-Challenge, the request method is the method of the request that generated the response containing the field. For Human-Continuity, the request method is the method of the request carrying the field. effective policy identifier: The policy identifier selected for the request by . effective realm: The realm selected for the request by the selected purpose entry in policy metadata. effective attestation audience: The canonical HTTPS origin of the request (). purpose: The concrete purpose carried in the purpose field parameter () and authorized by policy metadata. selected purpose entry: The purpose entry () selected for the concrete purpose under the effective policy identifier. selected presentation-assurance value: The presentation-assurance value requested by Human-Continuity-Challenge or asserted by Human-Continuity, if present. If the field has no presentation-assurance parameter, no presentation-assurance value is selected. continuity scope: The tuple (effective realm, effective attestation audience, purpose) used to derive and interpret the continuity_handle. The prefix "effective" marks a value determined per request by this section. The purpose carries no prefix because it is carried verbatim in the purpose field parameter and validated against policy metadata rather than derived. Separating request method and policy identifier from realm, attestation audience, and purpose allows different HTTP request contexts to publish different profile choices or presentation-assurance requirements while sharing one continuity scope when policy selects the same effective realm and the fields select the same purpose. It also allows single-endpoint APIs, such as GraphQL or RPC over POST, to select one HTTP policy identifier while different application operations select different purposes, realms, profiles, or assurance requirements. The purpose value has no default. Each Human-Continuity-Challenge list member and Human-Continuity item MUST include a concrete purpose. The purpose value MUST be authorized by the selected policy through a purpose entry for the selected profile. Purpose authorization is privacy-sensitive because it defines the verifier's linkability sets. The purposes and purpose templates listed in metadata make those linkability sets visible, making policy easier to audit, while avoiding an unbounded namespace of arbitrary challenge-selected purposes. The values are determined as follows:

Determine the request method and effective policy identifier from the request according to .
Select the purpose entry from the selected policy definition's purposes map. If the selected policy definition's purposes map contains an entry name exactly equal to the concrete purpose, that purpose entry is selected. A purpose template is never exactly equal to a concrete purpose, because concrete purpose values cannot contain { or }. Within the selected policy definition, an exactly matching entry name takes precedence over any purpose template that would also match the concrete purpose. Such a purpose template is not considered to authorize that concrete purpose for that selected policy. Otherwise, if exactly one purpose template in the selected policy definition's purposes map matches the concrete purpose, that purpose entry is selected. If no purpose template matches, the concrete purpose is not authorized. If a purpose entry is selected but its profiles object does not authorize the selected profile or the selected presentation-assurance value, or its realm does not match the value required for the artifact or presentation, the client and verifier MUST NOT fall back to another purpose entry.
Determine the effective realm from the realm of the selected purpose entry.
The effective attestation audience is the canonical HTTPS origin of the request ().
The continuity scope is (effective realm, effective attestation audience, purpose). Profiles MAY use profile-specific cryptographic inputs when validating or generating artifacts, but those inputs MUST NOT change the verifier-visible continuity scope or the continuity_handle produced for the same effective realm, effective attestation audience, purpose, and verified human.

Changing the effective realm changes the continuity scope. A conforming profile produces continuity_handle values for the new scope that are not correlatable with values from the previous scope. Continuity across a change of realm operator therefore requires keeping the realm stable so that the continuity scope does not change; key and infrastructure changes under a stable realm follow the profile's defined behavior for rotating realm operator trust material. Origins SHOULD choose purpose values that are stable for the continuity set in which repeated participation by the same human is intended to be detected. The origin is responsible for ensuring that emitted purpose values correspond to the intended continuity set: a purpose value that is too broad increases linkability, and a purpose value that is too narrow can prevent human continuity. Origins SHOULD NOT include per-request randomness, challenge nonces, session identifiers, one-time transaction identifiers, or other values that make each presentation use a unique purpose, unless the origin intentionally does not need human continuity across those presentations. When per-request unlinkability is desired, Human-Continuity is the wrong mechanism; origins need an unlinkable redemption mechanism instead (). Origins MAY use bounded scopes, such as time-windowed or event-specific purpose values, when the origin requires human continuity only within that bounded context. For example, "api_quota:2026-06-04", "promo:summer-sale", or "trial_credit_claim" can define narrower continuity contexts than a broad account- or origin-wide purpose. Each such purpose value MUST be authorized in policy metadata, as a listed purpose or through a purpose template. Origins using bounded purpose values SHOULD document the continuity boundary, including how purpose values are formed and how long each scope is intended to last. Before obtaining or presenting an artifact, a client MUST verify that the challenge or presentation is authorized by policy metadata (). Unless a future cross-origin delegation extension allows otherwise:

the effective policy identifier MUST match a policy definition selected for the request by policy metadata; and
the effective attestation audience MUST be the canonical HTTPS origin of the request.

Clients MUST ignore any challenge whose purpose value is absent or syntactically invalid or that is not authorized by policy metadata (). Verifiers MUST NOT treat presentations as valid unless the presentation is authorized by policy metadata (), the purpose value is present and syntactically valid, the purpose value is accepted by origin policy for the request, and the artifact is bound to that purpose according to the selected profile. Examples: The examples below show the exchange first, then the policy metadata checked to derive the effective values. The abbreviated metadata is complete for the shown request method and path, with unrelated non-matching entries omitted. Example artifact and Signature values are illustrative placeholders. A real artifact is bound to one effective realm, effective attestation audience, and purpose, and the same artifact bytes would not be valid across the different continuity scopes shown in this document's examples. Additional end-to-end flows against a consolidated policy metadata document are shown in . Example 1: default policy selector with origin-scoped policy For a GET request to: HTTP field in the response: Relevant policy metadata: Effective policy identifier: Effective realm: Effective attestation audience: Purpose: Continuity scope: No policy selector is found for GET /accounts/free-tier, so the GET default policy selector selects the site policy. The effective attestation audience is the canonical HTTPS origin of the request. Example 2: purpose template for a single-endpoint API For a POST request to: HTTP field in the response: Relevant policy metadata: The POST /graphql request selects the GraphQL policy. The concrete purpose "promo:summer-sale" does not equal any purpose listed under the policy, so the "promo:{campaign}" purpose template authorizes it and selects the realm, profile entry, and presentation-assurance value. For the concrete purpose "promo:loyalty", the exactly matching purpose takes precedence even though the purpose template also matches it: its purpose entry applies, including its "human-verified" presentation-assurance value, with no fallback to the purpose template's purpose entry. The concrete purpose, not the purpose template, is part of the continuity scope. A purpose template authorizes concrete purpose values; the concrete purpose itself is always carried in the challenge. Selected presentation-assurance value: Continuity scope: When the client retries an operation-specific request with content, it includes request content coverage in the HTTP Message Signature:

HTTP Fields

Common Field Syntax Human-Continuity-Challenge is a Structured Field List as defined by . Human-Continuity is a Structured Field Item as defined by . These fields are specific to human-continuity presentations. A conforming presentation produces a verifier-local continuity_handle scoped by realm, attestation audience, and purpose. Each Human-Continuity-Challenge list member value and the Human-Continuity item value MUST be an sf-string. The string is the profile identifier. Example: A client that cannot parse a Human-Continuity-Challenge field value as a Structured Field List MUST ignore that field value. A client MUST ignore a Human-Continuity-Challenge list member whose member value is not an sf-string. A client that does not support the indicated profile MUST ignore the Human-Continuity-Challenge list member. A verifier MUST treat Human-Continuity as invalid if the field cannot be parsed as a Structured Field Item or its item value is not an sf-string. If the indicated profile is unsupported, Human-Continuity is unverifiable. Parameters defined by this document are listed in . A client or verifier MUST ignore a parameter defined by this document on a field for which it is not defined. Other parameters are profile-specific. A client or verifier MUST ignore a profile-specific parameter unless it supports the selected profile and that profile defines the parameter. If the profile requires processing of a defined parameter and the client or verifier cannot process it, it MUST reject the affected challenge or presentation.

The Human-Continuity-Challenge Field The Human-Continuity-Challenge response field explicitly requests a human-continuity presentation. Field value type: Structured Field List Member value: sf-string profile identifier Human-Continuity-Challenge carries a challenge nonce intended for subsequent presentations. A challenge nonce is valid for a verifier-defined interval (). Under window acceptance, the challenge layer allows multiple presentations bound to the nonce on requests matching the challenge context, but artifact and presentation reuse remain subject to the selected profile's replay model. Under single-use acceptance, the verifier accepts at most one presentation for the nonce in that challenge context. A challenge does not change what policy metadata authorizes (). This specification does not define a client-visible challenge lifetime. A client that presents an artifact bound to an expired or otherwise stale challenge nonce can receive a new Human-Continuity-Challenge and retry according to origin policy. A challenge MAY appear on any response status code. However, origins MUST NOT use 401 solely to request human continuity, and proxies MUST NOT use 407 for this mechanism, as described in . The protocol does not depend on a particular error status. An origin requiring a presentation to complete a non-idempotent operation MUST issue the challenge before applying any effects of that operation. The members of a Human-Continuity-Challenge list are alternatives; their order is not significant. A client that responds to the challenge selects one member that it supports and that policy metadata authorizes, and sends the presentation for that member. A verifier that issues a distinct challenge nonce for each member keeps the alternatives independent under the challenge nonce scoping rules of . A Human-Continuity-Challenge list member MUST include the purpose parameter. The purpose value MUST be authorized by a purpose entry under the selected policy for the selected profile and request method. A client MUST ignore a challenge that is not authorized by policy metadata (). An origin MAY challenge for any purpose and profile authorized by policy metadata. A Human-Continuity-Challenge list member MUST include the challenge parameter. A client MUST ignore a Human-Continuity-Challenge list member whose challenge parameter is absent, cannot be parsed as a Byte Sequence, or is not exactly 32 octets (). The subsequent presentation MUST bind the challenge nonce as defined in . This binding lets a verifier confirm that the profile-defined issuance or presentation process used the nonce as a freshness input and, when replay protection applies, as a replay key input. Example:

The Human-Continuity Field The Human-Continuity request field carries one human-continuity presentation. Field value type: Structured Field Item Item value: sf-string profile identifier The item value identifies the selected unique-human profile. The item parameters carry the artifact material, purpose, and any profile-defined presentation parameters. A Human-Continuity item MUST include the artifact and purpose parameters. A Human-Continuity field represents the client's selected presentation for the request. A client MUST NOT generate more than one Human-Continuity field line for a request. This version does not define composition of multiple human-continuity presentations in one request. A verifier MUST parse the Human-Continuity field value as a Structured Field Item. If the field value cannot be parsed as an Item, the Human-Continuity signal is invalid. A comma-separated combined field value is therefore invalid. Example: A client MUST NOT present an artifact bound to a realm, attestation audience, or purpose other than the effective realm, effective attestation audience, and purpose for which the artifact is valid. A verifier MUST validate the artifact according to its profile before using it for policy. The artifact is one parameter inside the presentation item; holder-bound request signing covers the human-continuity Structured Field component, not the artifact bytes alone.

Common Field Parameters The following parameters are defined for the fields in this document. Profiles MAY define additional parameters. A profile MUST NOT define a parameter whose name is defined in this section. artifact: sf-binary. Defined only for Human-Continuity, where it is required. Carries the serialized unique-human artifact required by the selected profile. purpose: sf-string. Carries the concrete purpose. Each Human-Continuity-Challenge list member and Human-Continuity item MUST include the purpose parameter. Purpose values MUST be non-empty ASCII strings and MUST NOT contain control characters, whitespace, DQUOTE, backslash, or the brace characters { and }. The brace characters are reserved for the purpose template syntax in policy metadata () and never appear in a concrete purpose. A purpose value that does not satisfy these requirements is syntactically invalid. Purpose values are case-sensitive. Clients and verifiers MUST compare purpose values by exact string equality after Structured Field parsing. Clients and verifiers MUST NOT apply case folding, Unicode normalization, path normalization, percent-decoding, or scope-like expansion to purpose values. challenge: sf-binary. Defined only for Human-Continuity-Challenge, where it is required. Carries a verifier-provided challenge nonce. Each subsequent presentation MUST contain profile-verifiable evidence that the challenge nonce was used as an input to the selected profile's issuance or presentation process according to . Verifier-generated challenge nonces MUST be unpredictable to clients before issuance, MUST be generated with at least 128 bits of entropy, and MUST be encoded as exactly 32 octets. presentation-assurance: sf-string. Identifies a presentation-assurance value. The parameter can appear on Human-Continuity-Challenge and Human-Continuity. Its semantics are defined in .

Presentation Assurance Presentation assurance lets an origin request or receive an assertion that a presentation satisfies an additional assurance property. Presentation-assurance values MUST be non-empty ASCII strings and MUST NOT contain control characters, whitespace, DQUOTE, or backslash. Values are case-sensitive and compared by exact string equality. This document defines initial presentation-assurance values as common assurance classes. The selected profile defines how those values are satisfied, including evidence, ceremonies, verifier checks, freshness, replay behavior, privacy properties, limitations, and satisfaction or substitution relationships. Initial presentation-assurance values are:

"human-approved": Profile-defined evidence that a human's approval covers the presentation. Approval can be granted per presentation or as standing consent, such as a client or authenticator setting that authorizes generating presentations of a given class automatically. Human interaction is not required when the evidence is generated. It does not by itself establish participation by the subject.
"human-verified": Profile-defined evidence that a human was prompted and completed a user verification interaction when the evidence was generated, such as local user verification, user verification by a human-controlled authenticator, or another profile-defined verification ceremony. It does not by itself establish participation by the subject.
"subject-present": Profile-defined evidence that the subject participated when the evidence was generated. This document does not mandate any specific ceremony or mechanism for establishing the subject's participation.

A profile that supports presentation-assurance values, including the initial values defined by this document, MUST define the meaning of each supported value, the evidence required, verifier checks, freshness requirements, replay behavior, privacy properties, limitations, and any satisfaction or substitution relationships between values. A profile MAY define that one presentation-assurance value satisfies another presentation-assurance value for that profile. For example, a profile might define "subject-present" as satisfying "human-verified". A verifier MUST NOT apply such substitution unless the selected profile explicitly defines it. The initial values defined by this document are ordered by increasing assurance, from "human-approved" to "subject-present". A stronger value does not satisfy a weaker value unless the selected profile defines that substitution. A verifier MUST NOT treat the same presentation-assurance value as equivalent across different profiles unless the relevant profile specifications define compatible semantics. When presentation-assurance appears on Human-Continuity-Challenge, it requests a presentation satisfying that value for the challenge context (). When presentation-assurance appears on Human-Continuity, it identifies the presentation-assurance value asserted by the client for that presentation. If the presentation responds to a Human-Continuity-Challenge that included presentation-assurance, the Human-Continuity field MUST include the same value, unless the selected profile explicitly defines the asserted value as satisfying the requested value. A verifier MUST NOT treat a requested or asserted presentation-assurance value as satisfied unless the selected profile verifies the required evidence according to that profile. If the asserted value differs from the requested value, the verifier MUST NOT treat the request as satisfied unless the selected profile defines the asserted value as satisfying the requested value. Because presentation-assurance is a single parameter value, an origin that needs to challenge for multiple values that are not substitutable under the selected profile represents them as separate Human-Continuity-Challenge list members. Policy metadata can authorize multiple values using presentation_assurances. Additional presentation-assurance values intended for use across profiles SHOULD be registered in the Human-Continuity Presentation Assurance Value registry (). Values that are not registered MUST use a name controlled by the author of the specification that defines the value, such as a reverse-DNS name or a value prefixed by the profile identifier.

Policy Metadata Policy metadata lets clients discover default policy selectors, policy selectors, policies, authorized purposes and purpose templates, realms, supported profiles, and presentation-assurance values. Metadata also establishes the trust boundaries within which inline fields are interpreted. Policy metadata is a JSON document served with media type application/json. Policy metadata uses an origin-level well-known location. If a JSON object within a policy metadata document contains duplicate member names, the document is invalid and MUST NOT be used.

Origin-Level Metadata The origin-level policy metadata location is: The metadata document's origin member MUST equal the canonical HTTPS origin that serves the metadata. The metadata document is the human-continuity policy for the canonical HTTPS origin.

Selectors and Policy Entries An origin-level metadata document MUST include policies, policy_selectors, and default_policy_selectors members. A default policy selector is analogous to a default route: it maps an HTTP method to one policy identifier when no policy selector matches the request path for that method. Each policies member value is a policy definition. A policy identifier is an origin-local name used to select one policy definition. For single-endpoint APIs such as GraphQL or RPC, one policy identifier can describe the HTTP endpoint while individual purposes or purpose templates describe continuity contexts authorized within that endpoint. A policy definition does not apply to a request merely because it exists in policy metadata. A request selects a policy only through the policy selection algorithm, using policy_selectors or default_policy_selectors. Within one policy metadata document, if two purpose entries in different policies can authorize the same concrete purpose, those entries MUST specify the same realm. Two purpose entries in different policies can authorize the same concrete purpose if their names are the same purpose, if one entry's name is a purpose that the other's purpose template would authorize, or if both names are purpose templates and one template prefix is a prefix of the other, including equal prefixes. This check is computable from the entry names alone, without enumerating concrete purposes. If two such entries specify different realms, the metadata document is invalid and MUST NOT be used. This prevents the same continuity set from producing different continuity_handle values solely because different request methods, paths, or purpose entries selected different realms. Different purposes MAY use different realms. Each policy_selectors member name and each default_policy_selectors member name MUST be a valid HTTP method token. Each path pattern member name under a policy_selectors method member MUST be a valid path pattern. Each policy_selectors path pattern member value and each default_policy_selectors member value MUST identify exactly one policy definition in the same metadata document. This version defines only exact path patterns, terminal "/**" subtree patterns, exact method token matching, exact purpose matching, and the limited purpose template syntax defined below. No other matching behavior is implied.

Metadata Members A policy metadata document has the following members. origin: REQUIRED string. The canonical HTTPS origin described by this metadata document. default_policy_selectors: REQUIRED object. Each member name is an HTTP method token. Each member value is the policy identifier selected when no policy selector matches the request path for that method. policy_selectors: REQUIRED object. Each member name is an HTTP method token. Each member value is an object whose member names are path patterns and whose member values are policy identifiers for that method. policies: REQUIRED object. Each member name is a policy identifier and each member value is a policy definition. Policy identifiers MUST use the HTTP token syntax defined by , Section 5.6.2. Policy identifiers are case-sensitive and compared by exact string equality. Each policy_selectors method object has path pattern member names. A path pattern MUST begin with "/", MUST NOT be "/", MUST NOT be "/**", MUST NOT begin with "/.well-known/", MUST NOT contain dot-segments, as defined by , and MUST NOT contain an empty path segment, that is, the character sequence "//". A path pattern either contains no wildcard or ends with "/**". The wildcard character "*" MUST NOT appear anywhere else. An exact path pattern, such as "/account/recovery" or "/account/recovery/", matches only that request path. An exact path match takes precedence over subtree matching. A subtree pattern, such as "/account/recovery/**", matches request paths below that prefix. If no exact path match exists, the most specific matching subtree pattern takes precedence. The value of each path pattern member is the policy identifier selected by that policy selector. Each policy definition has the following members. purposes: REQUIRED object. Each member is a purpose entry whose name is either a purpose or a purpose template. The purposes object MAY be empty. A selected policy whose purposes object is empty authorizes no challenges or presentations for requests that select it. Combined with the prohibition on post-selection fallback, an empty purposes object lets an origin explicitly exclude paths and methods from human-continuity policy that a default policy selector or less-specific subtree pattern would otherwise apply. A purpose listed as an entry name authorizes exactly that purpose. A purpose template uses the purpose value syntax, except that it contains { and } as template delimiters: it contains exactly one delimiter sequence :{, has non-empty text before the delimiter, has a non-empty variable name after the delimiter, contains no other { or } characters, and ends with }. The template prefix is the substring before {, including the preceding colon. The template variable name is the substring between { and } and is documentation only. A purpose template authorizes a concrete purpose only if the concrete purpose begins with the template prefix and contains at least one additional character after the template prefix. For example, the purpose template "promo:{campaign}" has the template prefix "promo:" and authorizes concrete purpose values such as "promo:summer-sale", but not "promo:". The concrete purpose, not the purpose template or variable name, is part of the continuity scope. Template prefixes MUST NOT overlap within one policy definition. Two template prefixes overlap if one concrete purpose value can match both templates. If a policy definition contains overlapping template prefixes, the metadata document is invalid and MUST NOT be used. If an entry name contains { or } but does not satisfy the purpose template syntax, the metadata document is invalid and MUST NOT be used (). Because concrete purpose values cannot contain { or } (), a purpose template is never exactly equal to a concrete purpose. Clients and verifiers MUST compare purposes by exact string equality after Structured Field parsing of the purpose field parameter. They MUST compare purpose templates by exact string prefix matching against the concrete purpose value after Structured Field parsing, including the requirement that at least one character follows the template prefix. They MUST NOT apply case folding, Unicode normalization, path normalization, percent-decoding, glob matching, regular expression matching, or URI template matching. A purpose entry carries the following members. realm: REQUIRED string. The realm used for this purpose entry. Realm values used for continuity scope comparison are compared by exact string equality. profiles: REQUIRED non-empty object. Each member is a profile entry whose name is a profile identifier and whose value describes how that profile can be used with this policy and purpose entry. Profile identifiers in policy metadata use the syntax defined in . They are case-sensitive and compared by exact string equality. Each profile entry has the following members. presentation_assurances: OPTIONAL non-empty array of unique strings. The presentation-assurance values directly authorized for this profile entry. A directly authorized value can be requested in Human-Continuity-Challenge or asserted in Human-Continuity even when the challenge did not request it. If omitted, policy metadata does not authorize presentation-assurance support for this profile entry. Profile entries are the profile-scoped extension point ().

Authorization by Policy Metadata A challenge or presentation is authorized by policy metadata when it satisfies the requirements of this section, which authorize, together, the request method, the effective policy identifier, the effective realm, the concrete purpose, the selected profile, and the selected presentation-assurance value, if any. The effective attestation audience is derived from the request according to . For an effective policy identifier, an inline challenge or presentation is authorized by policy metadata only if the concrete purpose selects a single purpose entry according to and the selected purpose entry's profiles object contains a profile entry whose name equals the selected profile and that satisfies all applicable requirements. The selected purpose entry MUST contain exactly one realm. The selected purpose entry's name MUST equal the purpose field parameter or, for a purpose template, MUST match it according to the purpose template rules in . The selected profile entry is the profile entry whose name equals the profile field value. If a presentation-assurance value is requested, the selected profile entry MUST include that value in presentation_assurances. If a presentation-assurance value is asserted, the selected profile entry MUST include the asserted value in presentation_assurances, unless the selected profile defines the asserted value as satisfying a requested value included by that profile entry. Policy metadata can constrain purpose, profile use, and presentation-assurance values for a profile. It MUST NOT redefine the profile's specified privacy properties, holder binding requirements, presentation-assurance semantics, continuity_handle semantics, replay model, artifact syntax, or artifact size behavior.

Metadata Precedence and Trust Policy metadata defines default policy selectors, policy selectors, policies, trusted realms, authorized purposes, supported profiles, and presentation-assurance values. Fetched policy metadata is authoritative only as a policy statement by the origin that serves it. Configured metadata is a policy metadata or realm metadata document provisioned through a trusted out-of-band mechanism instead of being fetched. It is authoritative only to the extent of the mechanism that provisioned it and is otherwise processed using the same rules as the corresponding fetched document. A configured policy metadata document's origin member MUST exactly match the canonical HTTPS origin for which it was provisioned. A configured realm metadata document's realm member MUST exactly match the realm for which it was provisioned. A client MUST NOT use policy metadata unless it was obtained over HTTPS from the origin-level metadata location for the request's canonical HTTPS origin, or it is valid configured policy metadata for that canonical HTTPS origin. In both cases, the policy metadata document's origin member MUST exactly match that canonical HTTPS origin. A fetched document MUST NOT be used as policy metadata or realm metadata unless the response of the fetch has status code 200 and the media type required for that document, matching metadata retrieval in . Policy metadata fetches and realm metadata fetches using this document's well-known mechanism MUST NOT follow cross-origin redirects. Realm origins and other URLs obtained from fetched metadata are untrusted. Unless trusted local configuration authorizes the exact private destination, a client or verifier fetching such a URL MUST reject any IP literal or resolved address that is loopback, link-local, private-use, multicast, unspecified, or otherwise not globally routable; fetched metadata cannot grant this exception. That client or verifier MUST validate every connection target, including redirects, connect only to the validated address, and send no automatically attached cookies, Authorization credentials, or human-continuity fields. HTTPS protects the fetch. Beyond that, this specification does not authenticate the origin's policy choices or protect against compromised origin infrastructure. A policy metadata or realm metadata document MAY contain members not defined by this document. A client or verifier MUST ignore an unrecognized member of the document, of a policy definition, or of a purpose entry. Profile entries in both documents are the profile-scoped extension point: a profile MAY define additional members in its profile entry. Such members are owned by that profile, are interpreted only when that profile is selected, and MUST NOT redefine or override members defined by this document. A client or verifier MUST ignore any such member it does not understand or that belongs to a profile it does not implement. Where this document assigns syntax to JSON member names, a name that fails the syntax for its position invalidates the metadata document and MUST NOT be ignored as unrecognized. This applies to member names used as HTTP method tokens, path patterns, policy identifiers, purposes, purpose templates, or profile identifiers. For profile identifiers, this invalidity rule covers only the string syntax in ; clients and verifiers do not validate the reverse-DNS naming structure. A profile-defined member that carries a URL for an endpoint, verification material, or verification procedure MUST require that URL to use the "https" URI scheme. A profile-defined member that conveys material by another means MUST define the authenticated retrieval or trust model for that material. Inline fields describe the current response's challenged human-continuity requirements or the current request's presentation. They MUST NOT cause a client to trust a realm, attestation audience, purpose, profile, method-to-policy selection, or policy identifier that it would not otherwise trust. A client encountering an inline reference to an unknown profile or profile-specific field parameter SHOULD refresh fetched policy metadata over HTTPS or revalidate configured policy metadata before proceeding. If the refreshed or revalidated metadata does not authorize the selected profile or presentation-assurance value for the selected policy and purpose, the client MUST NOT proceed. A client MAY rely on cached policy metadata only while that metadata remains valid under its cache directives and the client's configured freshness limits. A client MAY rely on configured policy metadata only while that metadata remains valid under the client's configured freshness limits. If fresh metadata cannot be obtained and no valid cached or configured metadata authorizes the concrete purpose, profile, and presentation-assurance value when present, the client MUST NOT proceed. Inline fields MAY select or narrow profile, purpose, and presentation-assurance parameters within the policy selected by the request and policy metadata. Inline fields MUST NOT broaden authorized purposes, profile choices, or presentation-assurance values authorized by policy metadata. If the challenge or presentation is not authorized by policy metadata (), the client MUST ignore the inline value and MUST NOT obtain or present a unique-human artifact based on it.

Realm Metadata Realm metadata describes realm operator capabilities, issuance endpoints, profile-defined verification and revocation information, and unique-human profile support. The verification material and verification procedure for a profile are defined by that profile. Depending on the profile, verification material can be a JWK Set , a zero-knowledge verifying key or circuit identifier, a contract address and a source of ledger state, a transparency log or accumulator reference, or no fetched material at all. This document defines no verification material member of its own and privileges no verification material form. After selecting the effective realm from policy metadata, a client or verifier MUST NOT treat that realm as supporting the selected profile unless support is indicated by one of:

realm metadata obtained for the effective realm using the well-known mechanism defined below;
configured realm metadata for the effective realm (); or
realm metadata obtained as defined by the selected profile ().

If realm metadata required for the selected profile is missing, cannot be obtained, or is stale beyond the freshness limit defined by the profile or origin, a client MUST NOT obtain or present an artifact based on that realm metadata, and a verifier MUST treat the presentation as unverifiable for that profile. This applies to every source above. The rest of this section defines the well-known mechanism. It applies only when the effective realm is a canonical HTTPS origin (); obtaining realm metadata for any other effective realm, such as a non-HTTPS identifier or one that carries a path, query, fragment, or userinfo, is defined by the selected profile (). The realm metadata location is formed by appending /.well-known/human-continuity-realm to the effective realm: The realm metadata document is a JSON document served with media type application/json, and is fetched subject to the requirements of . Its realm member MUST exactly match the effective realm. The document indicates support for the selected profile through a realm profile entry for that profile; absence of that entry means realm metadata for the selected profile is missing. If a JSON object within the document contains duplicate member names, the document is invalid and MUST NOT be used. A realm metadata document has the following members. realm: REQUIRED string. The realm the document describes. It MUST match the realm under which artifacts are produced. profiles: REQUIRED non-empty object. Each member is a realm profile entry whose name is a profile identifier and whose value describes the realm's support for that profile. Profile identifiers in realm metadata use the syntax defined in . They are case-sensitive and compared by exact string equality. Each realm profile entry has the following members. issuance_endpoint: OPTIONAL string. The HTTPS URL of the endpoint used to request issuance, if the profile uses an HTTP issuance endpoint. A profile whose artifacts are verified against a JWK Set, a verifying key, or other fetched verification material defines the member that conveys it; lifecycle and compromise requirements for that material are defined in . A profile that supports revocation likewise defines the member that conveys revocation metadata. max_artifact_size_issued: OPTIONAL positive integer. An upper bound, in octets, on the serialized artifact value produced for this profile under the realm metadata entry, whether the artifact is issued directly or constructed by the client from operator-provided material. If omitted, the realm operator makes no artifact size commitment for this profile entry. Origins use this value when deciding whether to accept the profile. This value does not guarantee that an intermediary will accept that artifact size. Revocation semantics are profile-defined. This document does not require origins to perform online revocation checks on the request path. Realm profile entries are the profile-scoped extension point (): for example, a profile can define a verifying key reference and circuit identifier for a zero-knowledge profile, or a chain identifier, verifier contract, and source of ledger state for a profile verified against distributed ledger state.

Unique-Human Profiles The core specification defines no initial unique-human profiles. This document defines the HTTP discovery, challenge, presentation, and verification framework. It is not independently deployable without at least one unique-human profile that defines artifact syntax, issuance, verification, holder binding, challenge nonce binding, replay behavior, privacy properties, and continuity_handle derivation. Profile specifications MAY be published independently of this document. Profile identifiers follow the syntax and naming rules in . Publication of a profile does not imply that the profile is preferred, mandatory, or endorsed by this core specification. Profiles SHOULD support local verification by the origin. The core protocol does not require the origin to call the realm operator on the request path. Implementations and interoperability reports for this protocol SHOULD identify the unique-human profile or profiles used for testing. A core implementation that only parses the HTTP fields and metadata, but does not implement a concrete profile, is not sufficient to demonstrate end-to-end interoperability.

Profile Identifiers Profile identifiers are non-empty, case-sensitive ASCII strings carried as Structured Field string values and compared by exact string equality. Profile identifiers SHOULD be short enough for practical use in HTTP fields and MUST NOT contain control characters, whitespace, DQUOTE, or backslash. A profile identifier MUST use a reverse-DNS prefix within a domain controlled by the profile author, such as "com.example.unique-human.v1". The profile author is responsible for taking reasonable precautions to ensure that it controls the portion of the DNS namespace from which the identifier is derived, so that independently defined profiles do not collide. The domain in a profile identifier identifies the author of the profile specification. It implies nothing about the realm of any artifact: a profile can be supported by any number of realms, and the effective realm is selected by policy metadata () independently of the profile identifier's namespace. A profile identifier is permanently bound to the specification that defines it. A revision that changes artifact syntax, verification behavior, challenge nonce binding, replay behavior, or continuity_handle derivation MUST use a new profile identifier, such as one with an incremented version suffix. The naming rules in this section bind profile specifications, not protocol participants. Clients and verifiers compare profile identifiers as opaque strings and do not validate naming structure or domain control.

Specification Requirements A profile specification MUST define:

profile identifier;
artifact syntax;
issuance model;
issuance accessibility constraints, such as device, connectivity, enrollment, biometric, or jurisdictional requirements that determine which humans can obtain an artifact;
verification algorithm;
the trust anchors and verification material used by the verification algorithm, and verifier behavior for selecting that material, for its freshness and refresh, for rotation (including overlap and retirement), and for missing or stale material, and the response to compromise of that material;
the conditions under which verification fails, and the state those conditions produce in verifier output;
realm metadata requirements;
how the artifact binds the continuity_handle to the realm, attestation audience, and purpose;
holder binding requirements;
challenge nonce binding, as required by ;
replay or double-spend behavior;
whether revocation is supported; and, if supported, what can be revoked, the member that conveys revocation metadata, how verifiers discover revocation state, the maximum staleness a verifier accepts for revocation state, whether revocation is forward-looking only or affects previously accepted presentations, and verifier behavior when revocation metadata is unavailable;
supported presentation-assurance values, if any, including evidence, verifier checks, satisfaction relationships with other values, freshness requirements, replay behavior, privacy properties, and limitations;
profile-specific HTTP field parameters, if any, including syntax, applicable fields, optional or mandatory status, and processing rules; these parameters MUST NOT replace or redefine parameters defined by this document;
verifier output;
continuity_handle format and semantics, including length, opacity, collision resistance, non-malleability, stability, comparison rules, and profile-specific validation rules;
lifecycle behavior affecting continuity_handle stability or validity, including recovery, credential refresh, re-enrollment, rotation of realm operator trust material, realm migration, revocation, and realm operator compromise, when applicable;
privacy properties; and
security considerations specific to the profile.

A profile MUST define its state, recovery, and device continuity model. For profiles that are not intended for long-lived, multi-device, or recoverable use cases, this can be an explicit statement that loss of client-held state prevents future presentations, requires re-issuance that preserves the continuity_handle invariant, or causes affected artifacts or verification states to become invalid or unverifiable. It MUST specify:

what private state is held by the client, holder, realm operator, and verifier;
whether loss of client-held state prevents future presentations;
whether a holder can migrate to a new device and still obtain artifacts that produce the same continuity_handle for an existing continuity scope;
how holder key rotation, credential refresh, recovery, re-enrollment, rotation of realm operator trust material, realm migration, revocation, or realm operator compromise affects presentation validity, verifier output, and continuity_handle stability;
how a verifier discovers realm operator compromise and how it treats artifacts issued before compromise detection;
whether recovery requires realm operator interaction, user re-authentication, biometric re-verification, account recovery, social recovery, hardware-backed key recovery, or another mechanism; and
what privacy or abuse risks are introduced by the recovery mechanism.

Profiles that rely on unrecoverable client-local state MUST declare that property explicitly. Profiles that support recovery or device migration MUST define how they preserve scoped human-continuity semantics without exposing a global human identifier or enabling correlation outside the continuity scope.

Human-Continuity Handle Requirements A profile that does not produce a continuity_handle for a valid presentation is not conformant with this specification. A successful verification result for a conforming profile MUST include a verifier-local continuity_handle. The continuity_handle MUST be opaque and canonically encoded. Under the profile's documented assumptions, prediction, preimage, and second-preimage resistance MUST be at least 112 bits and SHOULD be at least 128 bits. Enumeration and malleation MUST be infeasible, and accidental collisions MUST be negligible at the profile's maximum supported population. The continuity_handle MUST be cryptographically bound to the continuity scope. A conforming profile MUST use domain separation or an equivalent construction so that continuity_handle values for different continuity scopes are not correlatable and cannot be transformed into one another. The core protocol defines continuity scope and continuity_handle comparison semantics. Profiles MUST NOT redefine these semantics. The continuity scope is the tuple (realm, attestation audience, purpose). The profile identifier is not part of the continuity scope. A verifier MUST compare continuity_handle values only within the same continuity scope. For the same realm, attestation audience, purpose, and verified human, a conforming profile MUST produce the same continuity_handle. For different continuity scopes, a conforming profile MUST NOT produce correlatable continuity_handle values. For the same realm, attestation audience, and purpose, two different continuity_handle values MUST represent different verified humans, subject to the selected profile's security assumptions and compromise model. If the same realm supports multiple profiles for the same attestation audience and purpose, valid presentations under those profiles MUST produce the same continuity_handle for the same verified human. Profiles that cannot satisfy this requirement MUST use distinct realms. Excluding the profile identifier from the continuity scope is intentional. It allows a realm operator to migrate between profiles, or to offer several profiles for the same verified human population, without causing the same human to receive different verifier-visible continuity_handle values for the same realm, attestation audience, and purpose. A realm operator that cannot preserve the invariant across its profiles MUST use distinct realms, which places those profiles in distinct continuity scopes. Conversely, multiple realms MAY support the same profile. Each effective realm forms a distinct continuity scope, even when their realm operators attest the same underlying credential population or rely on the same verification material. Differences in profile assurance, holder binding, replay behavior, artifact syntax, issuance ceremony, verification method, or other profile properties are inputs to verifier output or origin policy. They MUST NOT be represented by changing the continuity_handle for the same continuity scope and verified human.

Privacy Properties Profile privacy properties MUST include: artifact_linkability: What linkability is exposed by observing the artifact or presentation, independent of any continuity_handle in verifier output. Examples include single-use artifacts whose content does not link presentations, scope-local artifacts linkable only within the same continuity scope, reusable artifacts whose repeated use is linkable, or another profile-defined model. scope_binding: How the artifact cryptographically binds the continuity_handle to the realm, attestation audience, and purpose defined by this specification. holder_binding: Whether the profile is holder-bound, and if so how the artifact is bound to the holder key. realm_operator_attestation_audience_visibility: Whether the realm operator learns no attestation audience, the attestation audience at issuance, the attestation audience at redemption, or profile-defined attestation audience information. realm_operator_purpose_visibility: Whether the realm operator learns no purpose, the purpose at issuance, the purpose at redemption, or profile-defined purpose information. realm_operator_challenge_visibility: Whether the realm operator learns no challenge nonce, the challenge nonce at issuance, the challenge nonce at redemption, or profile-defined challenge nonce information. realm_metadata_fetch_visibility: What client information, if any, is revealed while obtaining realm metadata for the profile.

Example Profile Categories This section is informative. It gives examples of companion profile categories for early discussion. These examples are illustrative only; a real profile can combine these patterns.

Unique-human profiles based on accounts or registries. Such a profile would define how a holder proves control of, or membership in, a unique-human account or registry entry. The profile would define how the verifier's origin policy context is mapped to realm, attestation audience, and purpose, how the resulting nullifier or equivalent scope-local value is exposed as continuity_handle, and what replay, holder binding, recovery, and privacy properties verifiers can rely on.
Proof profiles backed by credentials or certificates. Such a profile would define how a holder proves possession of a qualifying credential, certificate, or attestation signed by the realm operator. The profile would define the artifact format, realm operator trust model, verifier algorithm, revocation handling, holder binding, replay behavior, lifecycle behavior, and derivation of a scoped continuity_handle.

Other realm operators, credential systems, proof systems, and issuance ceremonies can define profiles without changing the HTTP fields, policy metadata, realm metadata, or core verifier output model defined here.

Holder-Bound Presentations A holder-bound profile prevents a stolen artifact from being useful without the holder key. This document uses HTTP Message Signatures as the request signing mechanism for holder-bound profiles. Profiles with reusable artifacts SHOULD be holder-bound when artifact disclosure alone would otherwise enable presentation. Holder keys and stable references to them, such as key identifiers or thumbprints, can themselves be linkability handles. Clients MUST use holder keying material scoped no broader than the continuity scope.

Binding the Artifact to the HTTP Message Signature Key A holder-bound profile MUST define how the verifier obtains or reconstructs the holder signature verification key. For JWT-like artifacts that use JWKs to confirm the holder key, a profile can use a confirmation claim . If the artifact contains a JWK thumbprint confirmation value, the value MUST be the base64url-encoded SHA-256 JWK Thumbprint of the holder public key. When the client presents a holder-bound artifact, it MUST also attach an HTTP Message Signature. The verifier MUST:

Verify the unique-human artifact according to its profile.
Extract the holder signature verification key, key reference, or thumbprint from the artifact according to the profile.
Resolve the HTTP Message Signature verification key according to the profile.
Verify the HTTP Message Signature using that key.
Confirm that the HTTP Message Signature verification key matches the holder binding in the artifact according to the profile.
Reject the presentation if any binding check fails.

The keyid parameter in Signature-Input identifies a key. It does not, by itself, transport the public key or prove that the key is bound to the artifact. A profile MUST define the key resolution and binding procedure. The keyid values in this document's examples use the JWK Thumbprint URI form .

HTTP Message Signature Requirements For holder-bound profiles, the signature input MUST cover, at minimum:

@method;
@target-uri; and
human-continuity, using the sf component parameter defined by .

A profile MAY require additional covered components based on request method, request content, or profile semantics. If a holder-bound presentation includes Content-Digest , the signature input MUST cover the content-digest component. The client MUST attach exactly one signature whose tag parameter value is human-continuity; that signature's parameters MUST also include created and expires. Signatures with other tag values () can coexist on the same message; this document places no requirements on them. When the selected profile is holder-bound, the verifier MUST select the signature by that tag value and apply the binding procedure of to it. If no signature, or more than one, carries that tag value, the verifier MUST reject the presentation. The verifier MUST also reject the presentation if the signature's parameters do not include both created and expires, or if, beyond the verifier's clock skew allowance (), the created value is in the future or the expires value is in the past. Signature labels carry no semantics and intermediaries can relabel signatures (). Profiles MAY require keyid, alg, nonce, or other parameters defined by . The nonce signature parameter provides request-level replay protection only; it does not satisfy the challenge nonce binding requirement of . Other signing requirements are profile-defined.

Freshness and Replay Model

Profile Contract A profile MUST define its challenge nonce binding and replay model. The profile MUST state how the nonce is carried, consumed, and verified; whether artifacts and separately generated proofs can be reused under one nonce or regenerated for a new nonce; whether identical request-level presentation material can be accepted more than once; and which replay keys it makes applicable. All presentations are challenge-bound. Challenge acceptance mode, artifact reuse, request replay, and per-human policy are separate properties.

Challenge Context and Acceptance A presentation MUST prove that the challenge nonce was an input to the profile's issuance or presentation process. A verifier MUST reject it as invalid if the nonce is missing, expired, retired, or was not issued for the matching challenge context. An HTTP Message Signature nonce alone does not meet this requirement. The challenge context is the profile, effective realm, effective attestation audience, purpose, and requested presentation-assurance value if any. Policy metadata independently authorizes each request. A verifier MUST assign each nonce a validity interval and MAY retire it early. It can avoid storing the challenge context, acceptance mode, and validity interval per nonce by cryptographically authenticating them within the nonce. Replay protection and early retirement can still require authoritative state. At issuance, the verifier MUST bind exactly one acceptance mode to the nonce: Single-use acceptance: The challenge replay key applies, so at most one presentation bound to the nonce and context can be accepted. This is at-most-once acceptance, not exactly-once application effects. Window acceptance: No challenge replay key applies. Multiple presentations MAY be accepted while the nonce remains valid, subject to profile replay rules. Without another replay key, a captured request can be replayed during that interval.

Replay Keys and Final Acceptance The challenge replay key is the challenge nonce plus challenge context and MUST NOT vary by artifact, holder key, or signature nonce. A signature nonce replay key is the challenge nonce, challenge context, HTTP Message Signature nonce, and holder key thumbprint or profile-defined holder identifier. A profile MAY define other keys but MUST define their scope and applicability. After all other validation succeeds and before returning valid, a verifier MUST atomically check and record every applicable replay key in authoritative replay state. If a key was already recorded, reject as invalid; if the operation cannot complete, return unverifiable. Replay state, and any nonce state or key material it depends on, MUST remain available until the presentations it governs can no longer be accepted, including configured clock skew. Where replay protection or mutable nonce state applies, replicas MUST share authoritative state. Verifiers SHOULD keep skew small; 60 seconds is RECOMMENDED, and an acceptance interval MUST NOT expand after its replay state is discarded.

Security Boundary Challenge binding establishes freshness at challenge granularity; replay keys prevent repeated acceptance; per-human policy operates separately on continuity_handle. Holder-bound presentations sign the components required by . This specification defines no equivalent request binding for bearer presentations. A validated challenge proves only that the profile used the verifier nonce. Evidence for any requested or asserted presentation-assurance value MUST be bound to the profile, effective realm, effective attestation audience, purpose, and challenge nonce. If the challenge omits presentation-assurance, this document requests no additional presentation assurance.

Request Content Binding This document does not require Content-Digest on every request with content. If Content-Digest is present on a holder-bound request, the signature input MUST cover the content-digest component. A profile MAY require Content-Digest coverage when request content is security-relevant to the attestation decision. A request with no content does not require Content-Digest unless a profile explicitly requires a digest of empty content. If a request contains content and Content-Digest is not covered by the HTTP Message Signature, the verifier MUST NOT claim that the human-continuity presentation is cryptographically bound to the complete request content. For single-endpoint APIs where the application operation is carried in request content, such as GraphQL or RPC over POST, an origin that uses Human-Continuity for operation-specific policy SHOULD select a profile that requires Content-Digest coverage. If the request content is not covered, the verifier MUST NOT claim that the presentation is bound to a specific operation.

Client Behavior A client MAY ignore Human-Continuity-Challenge. If a client has no valid policy metadata under which the challenge is authorized (), the client MUST ignore the challenge. The client MUST also ignore the challenge if the purpose value is absent or syntactically invalid. Ignoring a challenge means that the client does not obtain or present a unique-human artifact based on that inline value. This does not require the underlying HTTP request or interaction to fail. A client presents only in response to Human-Continuity-Challenge: the concrete purpose, the profile alternatives, the challenge nonce, and any requested presentation-assurance value are carried by the challenge and validated against policy metadata (). The normal flow is to make the request, receive Human-Continuity-Challenge, and retry according to origin policy. This governs presentation timing only; a client can hold pre-existing profile enrollment state or reusable artifacts unless the selected profile says otherwise. If the selected profile permits artifact reuse, a client MAY retain an artifact bound to a challenge nonce and attempt to use it on subsequent requests matching the challenge context while that nonce remains valid (). If the profile permits reuse of the same presentation material, the client MAY retain and resend it. Repeat acceptance requires window acceptance and compliance with the profile's replay rules. When the verifier stops accepting the nonce, it can issue a new Human-Continuity-Challenge, and the client obtains a presentation bound to the new nonce and retries. Obtaining a presentation can be expensive: profile issuance or presentation ceremonies can involve realm operator interaction, proof generation, or human interaction. A client SHOULD bound and back off artifact regeneration when presentations for a request context are repeatedly rejected or repeatedly re-challenged. A client that chooses to use this protocol MUST:

parse fields according to ;
determine the effective policy identifier, effective realm, effective attestation audience, and purpose according to and ;
verify that the challenge or presentation is authorized by policy metadata ();
ensure that inline fields do not expand trust beyond metadata;
obtain or select an artifact appropriate for the profile, effective realm, effective attestation audience, and purpose;
ensure that any selected presentation-assurance value requested by Human-Continuity-Challenge is authorized by policy metadata;
ensure that any asserted presentation-assurance value is supported by the selected profile, can be satisfied for the presentation, and either matches the requested value, is defined by the selected profile as satisfying that requested value, or, when no requested value is being satisfied, is itself authorized by policy metadata;
present the artifact only for the effective realm, effective attestation audience, and purpose for which it is valid;
attach an HTTP Message Signature satisfying when the selected profile is holder-bound; and
avoid exposing artifacts, holder keys, signature material, or bearer-like material to untrusted code, prompt transcripts, logs, shell history, or user-visible text.

Clients SHOULD store persistent holder keys in platform credential storage when available. Browser clients using persistent holder-bound keys SHOULD use non-extractable key material, such as non-extractable WebCrypto CryptoKey objects, rather than exportable key material.

Verifier Behavior A verifier that receives Human-Continuity MUST parse it according to and MUST NOT use an invalid Human-Continuity signal as a valid presentation. If parsing succeeds, the verifier MUST:

Determine the request method and effective policy identifier from the request according to .
Determine the selected profile, purpose, and selected presentation-assurance value, if any, from the parsed Human-Continuity field.
Determine the effective realm and effective attestation audience according to .
If the selected profile is supported, verify the artifact according to that profile before using the presentation for policy.

The verifier MUST NOT treat the presentation as valid unless all of the following hold:

the presentation is authorized by policy metadata ();
the verifier supports the selected profile;
the purpose value is present, syntactically valid, and accepted by origin policy for the request;
the presentation contains profile-verifiable evidence for a challenge nonce the verifier issued for the matching challenge context and still accepts ();
the selected profile verifies that the artifact is bound to the effective realm, effective attestation audience, and purpose.

A verifier MUST accept a presentation only for the challenge context it issued. The profile, effective realm, effective attestation audience, purpose, requested presentation-assurance value, and challenge nonce MUST match the challenge, and policy metadata MUST authorize the current request. If Human-Continuity-Challenge requested presentation-assurance, the verifier MUST reject the presentation unless the selected profile verifies the required evidence. The evidence MUST be present, fresh, bound to the same profile, effective realm, effective attestation audience, purpose, and challenge nonce, and satisfy the selected profile's verification rules. If Human-Continuity asserts presentation-assurance that the challenge did not request, the verifier MUST apply the selected profile's evidence, freshness, and replay rules for that value. The verifier MUST NOT accept the asserted assurance unless the required profile-defined evidence is present and valid. A verifier MUST enforce the constraints of the selected purpose entry, including the selected profile and presentation-assurance value if any. The verifier MUST NOT accept a presentation merely because it produces a valid continuity_handle for the same continuity scope. A verifier output has one of the following top-level states: valid: The artifact and all required presentation proofs are valid, and the verifier has produced a continuity_handle for the selected continuity scope. invalid: The artifact or presentation proof is malformed, expired, revoked, bound to a different realm, attestation audience, or purpose, bound to a challenge nonce the verifier did not issue or no longer accepts, fails to produce a required continuity_handle or requested or asserted presentation-assurance evidence, reuses an applicable replay key, or otherwise fails profile validation. unverifiable: The verifier lacks fresh enough metadata, does not support the profile, does not trust the realm, lacks verification material, cannot access required authoritative challenge or replay state, or otherwise cannot complete validation. This document does not require an origin to fail a request when a human-continuity presentation is missing, invalid, or unverifiable. Origin policy is out of scope. A successful verification result for a conforming profile MUST include at least:

state;
profile;
realm;
attestation_audience;
purpose; and
continuity_handle.

When a verifier accepts a presentation for which presentation-assurance was requested or asserted, the successful verification result MUST include the verified presentation-assurance value. The result MAY include additional profile-defined assurance details, such as method, freshness time, or assurance level, provided those details do not violate the selected profile's privacy properties. An example of one possible JSON representation: A successful verification MAY include additional profile-defined attributes. A verifier MUST NOT use a valid/invalid attestation result alone to enforce policy decisions that depend on attributing presentations to the same human. For those decisions, it MUST use the profile-defined continuity_handle, scoped by realm, attestation audience, and purpose. A continuity_handle is not an authenticator. A verifier MUST NOT use a continuity_handle, or equality with a previously stored continuity_handle value or derivative, as the sole basis for authenticating a request, granting account access, or proving control of an account. A verifier MAY use a continuity_handle as an input to origin policy after applying the origin's native authentication, authorization, or account recovery rules. A verifier output MAY include profile-defined or implementation-defined diagnostic information describing why a presentation was invalid or unverifiable. Where an origin surfaces such a reason in an HTTP response, one possible representation is Problem Details .

Caching and Intermediaries When human continuity affects whether a request is served, throttled, challenged, or rejected, the component that makes that decision MUST have access to the presentation or to a verifier-derived classification. When shared caches or CDNs are used, origins MUST ensure that cached responses cannot bypass the intended human-continuity policy under HTTP caching semantics . If the selected representation depends on the raw Human-Continuity field value, the origin MUST send: Vary addresses cache correctness only. It keys cache entries on the raw field value and cannot capture Signature-Input, Signature, or verifier validity state; it stores presented artifact values as shared cache keys and fragments cache entries when presentations contain dynamic signature parameters. Origins MUST NOT use Vary: Human-Continuity as a validity gate. When request handling, the selected representation, the status code, or challenge behavior depends on whether a presentation is present or valid, the origin SHOULD verify the presentation at or before the shared cache and key cached responses on the verifier classification, or mark the affected responses private or no-store. Origins MUST ensure, through response directives or cache configuration, that a cached response is not reused for a request with a different human-continuity state, unless bypassing origin-side human-continuity policy is acceptable for that response. Responses containing Human-Continuity-Challenge SHOULD use Cache-Control: no-store. A challenge stored by a shared cache can deliver the same challenge nonce to many clients.

Browser and CORS Considerations Browser JavaScript clients require origins to expose response fields and allow request fields through CORS. Actual resource responses that carry Human-Continuity-Challenge need to expose that response field to browser script: CORS preflight responses need to allow the actual request's method and fields: Human-Continuity-Challenge can appear on successful responses as well as error responses. Browser clients that use this protocol need to read it on any response for which CORS exposure permits access. Exposing Human-Continuity-Challenge to browser script exposes any challenge nonce to that script context. Challenge nonces are replay protection inputs, and implementations MUST NOT rely on their confidentiality for security. However, browser clients SHOULD perform artifact selection, use of holder keys, and presentation signing in trusted code paths and SHOULD avoid exposing those capabilities to untrusted third-party scripts, injected scripts, or broadly authorized cross-origin callers. XSS or script compromise in a context that can access holder keys or presentation APIs enables unauthorized credential use in this protocol. This document does not use the Sec- prefix for any field. The protocol does not rely on browser-reserved field names: clients generate Human-Continuity according to policy, and origins expose Human-Continuity-Challenge through ordinary HTTP and CORS controls. Because these fields are ordinary extension-defined HTTP fields, generic user agents, intermediaries, logging systems, and tracing systems will not treat them as sensitive by default.

Status Codes and Error Responses An origin MUST NOT use 401 solely to request human continuity under this protocol. A 401 response is reserved for HTTP authentication challenges and requires WWW-Authenticate . A proxy MUST NOT use 407 for this mechanism. A 407 response is reserved for proxy authentication and requires Proxy-Authenticate . Origins MAY use 403, 409, 422, 429, or another status code appropriate to origin policy when issuing a Human-Continuity-Challenge. Problem Details can be used to describe the origin policy error, but is not required by this document. A Human-Continuity-Challenge received on a 3xx response applies to the request that generated that response, not to the redirect target. A client that follows a redirect MUST NOT send the Human-Continuity, Signature-Input, or Signature field values generated for the original target URI on the redirected request. The client MUST perform policy selection, effective value determination, artifact selection, and signing for the redirect target as a new request under the redirect target's canonical HTTPS origin and policy metadata.

Header Size and Artifact Size This protocol carries artifacts in HTTP fields. Many origins, frameworks, CDNs, gateways, and proxies enforce limits on request header size. Large artifacts can trigger 431 Request Header Fields Too Large or intermediary-specific failures. max_artifact_size_issued refers to the serialized artifact value as carried in the Human-Continuity field, after any base64, base64url, or Structured Field Byte Sequence encoding has been applied. The value excludes the HTTP field name and unrelated field parameters, but includes any delimiters required by the artifact's Structured Field item encoding. This limit does not guarantee that every intermediary on the request path will accept the complete HTTP field section. Origins SHOULD choose conservative values when deployed behind intermediaries with smaller header limits. Profiles intended for broad HTTP deployment SHOULD keep artifacts small enough to fit within commonly deployed origin, framework, and intermediary field section limits. A profile whose proof objects are expected to exceed those limits SHOULD define a compact presentation form, such as a profile-defined exchange token, compact envelope, detached proof reference, or presentation endpoint, rather than requiring raw proof objects to be carried directly in the Human-Continuity field. A profile that uses a compact envelope, reference artifact, exchange token, or presentation endpoint MUST define how that presentation form is cryptographically or operationally bound to the realm, attestation audience, and purpose, how it satisfies the profile's holder binding requirements and replay model, and how it produces the verifier output required by this specification.

Privacy Considerations A continuity_handle is intentionally linkable within its continuity scope. This scoped linkability lets origins attribute repeated participation to the same human for purposes authorized by policy metadata. The privacy goal of this specification is unlinkability across different continuity scopes. Cross-scope unlinkability is a property of the selected profile and realm operator behavior, not of the HTTP transport defined by this document. The core protocol cannot prevent realm operators from colluding, sharing handle derivation material, or intentionally issuing correlatable artifacts. A profile that claims unlinkability across continuity scopes MUST state its realm operator non-collusion, key separation, and compromise assumptions. Continuity handles are not intended to reveal a user's real-world identity or account identity. A conforming profile MUST make continuity_handle values infeasible to reverse, enumerate, or correlate outside their continuity scope. However, a continuity_handle can still single out the same human within a scope and may be personal data or a regulated identifier for some origins. Verifiers SHOULD define retention, deletion, and access control policies for stored continuity_handle values and verifier-local derivatives. Profiles MUST NOT expose a global human identifier. Origins SHOULD request or accept human-continuity presentations only for the narrowest purpose that satisfies their declared policy. Conforming profiles MUST NOT produce correlatable continuity_handle values for different continuity scopes under their stated security and privacy assumptions. Verifiers MUST NOT compare continuity_handle values across different continuity scopes. The purpose value is privacy-sensitive because it defines the verifier's linkability set. Audience alone is often too coarse: a signup, comment, promotion claim, support request, API quota, and agent delegation can require different continuity_handle values for the same verifier. Verifiers SHOULD use separate purpose values for separate business contexts unless origin policy deliberately requires grouping them. Purpose templates are privacy-sensitive because they authorize many concrete linkability scopes. Concrete purposes authorized by a purpose template SHOULD be tied to stable origin policy units and SHOULD NOT encode per-client or per-request tracking material. Origins SHOULD provide user awareness appropriate to the breadth, lifetime, and sensitivity of the continuity scope. Broader scopes, longer-lived continuity_handle values, and recovery or device continuity mechanisms can require stronger user-facing controls. This document does not define the user interaction model. A profile might reveal information to the realm operator during issuance, such as requested attestation audience, purpose, profile, challenge nonce, holder key thumbprint, issuance time, or user consent state. A profile might reveal information to the realm operator during redemption, if it requires online redemption. Each profile MUST document these realm visibility properties (). The discovery fetches defined by this protocol are observable before any presentation. A policy metadata fetch tells the contacted origin that the client is evaluating human continuity for that origin, but does not by itself disclose activity at other origins. An on-demand realm metadata fetch () tells the realm operator the client's IP address and fetch timing, even for profiles that otherwise reveal nothing to the realm operator at presentation time. Cached or configured metadata (), or profile-defined realm metadata retrieval, can decouple that observation from presentation intent. Profiles and origins that rely on realm operator non-observation at presentation time SHOULD account for this channel. A scoped continuity_handle does not make the whole HTTP request unlinkable outside the profile's cryptographic design. Origins can still observe IP address, cookies, native authorization, TLS properties, client behavior, user-agent information, application identifiers, and timing. Clients and origins SHOULD treat artifacts, continuity_handle values, and signature material as sensitive. They can reveal linkability information or permit abuse if leaked, depending on profile semantics. Verifiers SHOULD avoid logging raw continuity_handle values. When storing continuity_handle values persistently, verifiers SHOULD use a verifier-local protected derivative, such as a keyed hash over the continuity scope and continuity_handle, when operationally feasible.

Privacy Threats This section relates the protocol to the privacy threats in , concentrating on those a human-continuity mechanism raises most directly. In each, the continuity scope () is the boundary that contains the threat, and the requirements stated earlier in this section are the floors that constrain it. The threats of stored data compromise and disclosure described in apply to artifacts, signature material, and stored continuity_handle values as sensitive data and are treated under . Surveillance (): A realm operator can observe issuance, and online redemption where a profile requires it; a verifier observes the presentations made to it. A verifier learns a continuity_handle only within the continuity scopes it requests, and what a realm operator learns is made auditable by the per-profile realm visibility documentation required above. The protocol does not, however, prevent a single realm operator from observing issuance across the scopes it serves, nor realm operators from colluding, as noted above; nor does it conceal the request metadata any HTTP server already sees, such as IP address, cookies, and TLS properties. Correlation (): A continuity_handle is deliberately correlatable within one continuity scope; that scoped linkability is the mechanism's function. Correlation across scopes is the threat this specification is built to prevent, through profiles that do not produce correlatable handles for different scopes and verifiers that do not compare handles across scopes. Because a scope is (effective realm, effective attestation audience, purpose), purpose granularity is the principal correlation control: a broad or shared purpose enlarges the set within which the same human is detected, which is why origins are directed to the narrowest purpose and to distinct purposes for distinct contexts. Linkability that does not derive from the handle, such as a shared IP address or account, lies outside the protocol's cryptographic guarantees. Identification (): A continuity_handle is a scope-local pseudonym. Profiles expose no global human identifier, and handles are infeasible to reverse or enumerate outside their scope, so the protocol does not by itself tie a handle to a real-world or account identity. Within a scope a handle still singles out the same human and can be personal data; an origin that joins it to identifying data it already holds performs that identification, which the retention, deletion, and access control guidance above is meant to constrain. Secondary use (): Purpose binds each artifact and continuity_handle to the context it was authorized for, and policy metadata makes that context visible and auditable. Linking the same human under a different purpose is a different continuity scope, which conforming profiles keep uncorrelatable and verifiers do not bridge; carrying stable business contexts rather than tracking material in purpose values keeps the use that is authorized aligned with the use that occurs.

Exclusion, Accessibility, and Coercion Conditioning access to a service on a human-continuity presentation excludes humans who cannot present. A human may have no access to any realm the origin's policy authorizes, they may lack a required device, or be unable to complete the issuance ceremony. Client participation is voluntary, and this document does not guarantee that requests backed by human continuity receive different service treatment; making a presentation a precondition for service is an origin policy choice that the protocol neither requires nor defines. Origins SHOULD offer an alternative path to the service for humans who cannot or choose not to present, consistent with the guidance to request Human-Continuity only where human continuity is required (). Where no alternative is offered, the origin SHOULD make the requirement, and the realms it accepts, transparent so that an affected human can understand the basis for exclusion. Conditioning service on presentation can also pressure a human into an issuance ceremony, and the enrollment or identification it entails, that they would otherwise decline; the more sensitive the ceremony, such as one involving biometric enrollment, the stronger this concern. Because the holder that presents an artifact can be a client or agent acting for a human, the HTTP presentation mechanism does not assume direct human interaction and is compatible with assistive technology and delegated agents. Exclusion risk therefore concentrates in issuance and in any subject participation a profile's presentation-assurance requires (); profiles document the accessibility constraints of obtaining an artifact (), so an origin can assess which humans the operator of an authorized realm can reach.

Implementation Status RFC Editor: Please remove this section and the reference to before publication. This section records the implementation status of this specification in accordance with . It is intended to inform IETF review and working group discussion. The information has not been independently verified, and listing or omitting an implementation does not imply IETF endorsement. As of this -00 version, no complete end-to-end implementation of this HTTP extension or interoperability report for this specification is known to the editor. Existing unique-human systems may inform future companion profiles, but this document defines no initial profile and does not report any deployment as implementing this specification end to end. The example artifacts in this document are implementation aids and are not reported as running implementations.

Security Considerations Security depends on clients and verifiers enforcing metadata policy, choosing narrow continuity scopes, preventing disclosure of artifacts and signature material, and preventing unauthorized use of holder keys. Artifact and signature disclosure: Human-Continuity fields, Signature-Input, Signature, and derived verifier output can be sensitive even when they are not authentication credentials. Ordinary HTTP infrastructure may log, trace, sample, or inspect extension-defined fields by default. Origins SHOULD configure redaction or use profiles whose artifacts and signatures are safe under the expected exposure. Holder key compromise: If a holder key and its bound artifact are compromised, an attacker can create holder-bound presentations only while the verifier accepts the artifact's challenge nonce and the artifact remains valid. Profiles SHOULD define holder key rotation and how compromise invalidates keys, artifacts, or outstanding challenges. Request binding: Holder signatures cover @method, @target-uri, and Human-Continuity. This specification defines no equivalent binding for bearer presentations. Authenticated principals: The challenge context and mandatory signature coverage do not bind a presentation to Authorization, a session, or an application principal. Before linking a continuity_handle to a principal, an origin SHOULD either record that principal with the challenge nonce and require the same principal on presentation, or require signature coverage of the request fields used for authentication (). Single-use acceptance limits replay but does not provide principal binding (). State exhaustion: Required replay and mutable nonce state MUST remain available through its retention deadline. Capacity, partition, or backend failures MUST fail closed as unverifiable. Verifiers SHOULD bound lifetimes, rate-limit issuance and verification, and provision replay storage for their acceptance modes. Origin, method, and purpose confusion: Clients MUST verify that challenges and presentations are authorized by policy metadata for the request (), including any presentation-assurance value. Clients MUST NOT infer cross-origin delegation, realm selection, attestation audience selection, purpose authorization, profile support, or presentation-assurance support from inline fields. Policy mapping confusion: The effective policy identifier is derived from the request method, request URI, and policy metadata. Clients and verifiers MUST implement the same matching algorithm. Origins using reverse proxies, request rewriting, routing normalization, or framework-level path normalization MUST ensure that the verifier computes the effective policy identifier from the externally visible request method and URI used by clients. Selector overlap: Path patterns can create policy overlap. This specification resolves overlap by first checking for an exact path match under the request method. If no exact path match exists, it considers subtree patterns that match both the request path and request method, then chooses the most specific matching subtree pattern, which is unique because selector member names are unique within one method. A selector for one method does not shadow a less-specific selector for another method. Clients and verifiers MUST NOT fall back to a less-specific policy after selecting a policy that does not authorize the request's concrete purpose, profile, effective realm, or presentation-assurance value. Path normalization: Clients and verifiers MUST NOT apply percent-decoding equivalence, dot-segment normalization, path case folding, Unicode normalization, framework route matching, filesystem path normalization, or query string matching when selecting a policy identifier. A request path containing dot-segments MUST NOT match a policy selector or default policy selector under this protocol. Clients and verifiers MUST NOT accept Human-Continuity-Challenge or Human-Continuity for such a request unless a future extension defines safe normalization semantics. Origins using policy_selectors or default_policy_selectors SHOULD reject requests whose externally visible path contains dot-segments. Default policy selectors: Default policy selectors are broad policy selectors. Origins SHOULD prefer explicit policy selectors. A default policy selector can cause requests not matched by a policy selector for the request method to authorize purposes or profiles that were intended only for a narrower part of the origin. An origin can exclude a path and method from a broader default policy selector or less-specific subtree pattern by mapping it to a policy whose purposes object is empty; such a policy authorizes nothing and fails closed. Because matching is exact, path forms that differ only by a trailing slash, such as "/x" and "/x/", are distinct paths under and can select different policy identifiers. Method forms that differ by case are also distinct. A request that has no matching policy selector for its method uses default_policy_selectors, if any, rather than an implicit origin-level fallback. Origins applying request-scoped policy SHOULD cover every protected path in all served forms, by registering each form or by using valid subtree patterns. Origins trying to cover all paths for a method SHOULD use default_policy_selectors for that method, and SHOULD list every method for which that policy is intended. Header injection and stripping: Intermediaries or compromised components might add, remove, or modify human-continuity fields. Inline fields do not select the effective policy identifier, effective realm, or effective attestation audience, and they do not broaden authorized purposes, profile choices, or presentation-assurance values authorized by policy metadata. Holder-bound presentations cover Human-Continuity in the HTTP Message Signature (). Signature coverage: HTTP Message Signatures protect only covered components. If a component is not covered, a verifier MUST NOT claim that the presentation is bound to that component. Request content: If Content-Digest is present on a holder-bound request, the signature input MUST cover the content-digest component. If request content matters to the attestation decision, the applicable profile SHOULD require Content-Digest coverage. Metadata fetching: Realm origins and other URLs obtained from fetched metadata are untrusted and are subject to the destination-validation and credential-handling requirements in . Metadata freshness: Stale metadata can cause clients or verifiers to use retired realms, verification material, trust anchors, profiles, or policies. Profiles and origins SHOULD define metadata freshness and refresh behavior. Origins SHOULD send explicit freshness directives, such as Cache-Control with max-age, on policy metadata responses, on the 404 or 410 responses that establish policy absence, and on realm metadata responses. Clients SHOULD NOT apply heuristic caching to these documents; absent explicit freshness directives, a client SHOULD revalidate before relying on them. Realm operator trust material compromise and rotation: Compromise of realm operator trust material can allow forged artifacts or false continuity_handle values. This risk applies to every form of verification material and trust anchor a profile uses, including keys, circuits, contracts, ledger state, accumulator roots, and transparency logs. The lifecycle requirements for verification material in , together with profile-defined revocation or invalidation behavior where applicable, bound the exposure window. Browser holder keys: Non-extractable browser key material can reduce key export risk, but it does not prevent use of the key by compromised same-origin script. In browser clients, XSS, malicious dependencies, or other same-origin script compromise can therefore permit unauthorized holder key use even when the private key is not extractable. Logging and transcripts: Implementations used by agents, model-facing tools, or developer environments SHOULD attach artifacts in trusted transport code and redact the Human-Continuity, Signature-Input, and Signature fields, verifier outputs containing continuity_handle values, and related holder key material from logs and transcripts by default. Header size denial of service: Very large artifacts can consume parser memory or trigger header processing failures. Origins SHOULD enforce size limits before expensive verification.

IANA Considerations

HTTP Field Name Registrations IANA is requested to register the following fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by . The "Structured Type" column is defined by .

Field Name	Status	Structured Type	Reference
Human-Continuity-Challenge	permanent	List	This document
Human-Continuity	permanent	Item	This document

Well-Known URI Registrations IANA is requested to register the following well-known URIs in the "Well-Known URIs" registry . This document uses separate well-known URI suffixes for policy metadata and realm metadata because the policy authority and the realm operator are not necessarily the same party. Policy metadata is authoritative for default policy selectors, policy selectors, accepted purposes, accepted profiles, presentation-assurance values, and effective realms at the origin and its policies. Realm metadata is authoritative for the realm operator's capabilities and verification material. If the same origin acts as both policy authority and realm operator, it MAY serve both metadata documents from that origin.

URI Suffix	Change Controller	Specification Document	Status	Related Information
human-continuity	IETF	This document	permanent	Policy metadata for Human Continuity for HTTP
human-continuity-realm	IETF	This document	permanent	Realm metadata for Human Continuity for HTTP

Human-Continuity Presentation Assurance Value Registry IANA is requested to create the Human-Continuity Presentation Assurance Value registry. Registered values use the presentation-assurance value syntax defined in and SHOULD be short enough for practical use in HTTP fields. Registration policy: Expert Review . The designated experts are instructed to approve a registration when the value's intent is clearly described and distinct from existing entries, and the value is intended for use across more than one profile; values specific to a single profile use author-controlled names as described in and are not registered. The experts MAY require a stable, publicly available definition of the value's general intent. The experts assess only distinctness and clarity of intent: registration does not constitute endorsement of any verification mechanism and does not establish cross-profile equivalence, and the equivalence rules in apply to registered and unregistered values alike. The registry is expected to grow slowly. Registration requests MUST include:

presentation-assurance value;
description;
specification reference; and
change controller.

The registry records shared presentation-assurance labels and their general intent only. The definitions in are authoritative for the values registered by this document, and how a value is satisfied for a given profile is defined by that profile as required by . Registration status is not consulted by clients or verifiers at runtime. Initial values:

Value	Description	Change Controller	Reference
human-approved	A human approved the presentation, either individually or through standing consent.	IETF	This document
human-verified	A human completed a user verification interaction when the evidence was generated.	IETF	This document
subject-present	The human subject claimed as unique participated when the evidence was generated.	IETF	This document

Examples

Challenge Reuse for a Request-Scoped Policy For a GET request to: The origin challenges on the response to the first request: The client retries with a presentation bound to the challenge nonce: With the Policy Metadata example below, GET /api/quota selects the following effective policy identifier: The effective attestation audience is the canonical HTTPS origin: The purpose is: The effective realm is: The continuity scope is: The policy is selected from the GET /api/quota request context, while the artifact is bound to the canonical HTTPS origin as its attestation audience. This example assumes that the selected profile permits reuse of the same presentation material. Under window acceptance, the client resends it until the origin challenges again ().

Holder-Bound Presentation For a POST request to: The origin can return: The origin sends this challenge before creating the account, allocating the free tier, or applying any other signup effect. The client then checks policy metadata before treating the purpose, profile, and presentation-assurance value as authorized. With the Policy Metadata example below, POST /accounts/free-tier selects the signup policy, which authorizes the challenge. The client can then repeat the not-yet-applied signup operation with a holder-bound presentation: The challenge above carried a challenge nonce. The challenge nonce evidence required by is carried inside the artifact according to the fictional profile; it does not appear as a Signature-Input parameter.

Policy Metadata

Realm Metadata In this non-normative example, verification_key_uri and revocation_status_uri are members defined by the example profile, not by this document. The members defined by this document are realm and profiles, and within each realm profile entry, issuance_endpoint and max_artifact_size_issued.

Realm Metadata Without JWKs This non-normative example shows realm metadata for two profiles whose verification material is not a JWK Set. The members other than issuance_endpoint and max_artifact_size_issued are profile-defined and illustrative only.

Using Verifier Output in Origin Policy A successful verification result is shown in the example in . For one-human-one-account enforcement, an origin can apply a uniqueness constraint over the verifier-visible scope: stored_continuity_handle is policy state, not an authenticator. It can be the raw continuity_handle or, preferably for persistent storage, a verifier-local protected derivative. Account access still depends on the origin's native authentication and authorization mechanisms.

Agent Delegation Binding For agent delegation, a verifier can use a separate purpose and bind agent keys to the resulting continuity_handle:

References Normative References Uniform Resource Identifier (URI): Generic Syntax 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] The Web Origin Concept This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. JSON Web Key (JWK) Thumbprint 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. Guidelines for Writing an IANA Considerations Section in RFCs 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. Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. HTTP Semantics 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. HTTP Caching 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. HTTP Message Signatures 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. Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Structured Field Values for HTTP This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Privacy Considerations for Internet Protocols This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. JSON Web Key (JWK) 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. Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. JWK Thumbprint URI This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs. Remote ATtestation procedureS (RATS) Architecture In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Problem Details for HTTP APIs This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. The Privacy Pass Architecture This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. The Privacy Pass HTTP Authentication Scheme This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. OAuth 2.0 Protected Resource Metadata This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Anonymous Rate-Limited Credentials Cryptography Apple, Inc. Apple, Inc. Cloudflare This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. BBS per Verifier Linkability MATTR Grotto Networking The BBS Signatures scheme describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, assertion of pseudonymous identity, monetization, etc.. This document provides a mechanism for binding prover secret material for pseudonym creation to a BBS signature and shows how to use this bound information for the creation of context dependent pseudonyms in BBS proofs. HTTP Message Signatures Directory 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. HTTP Message Signatures for automated traffic Cloudflare Google This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. Anonymous Credit Tokens Google Google This document specifies Anonymous Credit Tokens (ACT), a privacy- preserving authentication protocol that enables numerical credit systems without tracking individual clients. Based on keyed- verification anonymous credentials and privately verifiable BBS-style signatures, the protocol allows issuers to grant tokens containing credits that clients can later spend anonymously with that issuer. The protocol's key features include: (1) unlinkable transactions - the issuer cannot correlate credit issuance with spending, or link multiple spends by the same client, (2) partial spending - clients can spend a portion of their credits and receive anonymous change, and (3) double-spend prevention through cryptographic nullifiers that preserve privacy while ensuring each token is used only once. Anonymous Credit Tokens are designed for modern web services requiring rate limiting, usage-based billing, or resource allocation while respecting user privacy. Example applications include rate limiting and API credits. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. OpenID for Verifiable Presentations 1.0 OpenID Foundation Digital Credentials API W3C Federated Identity Working Group x401, Version 0.2.0 (Draft) Proof Circle

Illustrative Profile Sketch This appendix is informative. It is not a complete profile specification and is not sufficient for deployment. It exists only to illustrate how a companion profile would use the HTTP framework. The example profile "com.example.unique-human.v1" is fictional. It defines an opaque artifact that proves, according to the profile's verification rules, that the subject satisfies the profile's unique-human criteria. The artifact is valid for one attestation audience and one purpose. Verification produces a scope-local continuity_handle. Example challenge: Example presentation: A successful verification produces the verifier output shown in , with state set to "valid" and a scope-local continuity_handle for the selected continuity scope. A real profile would still need to define artifact syntax, issuance, verification, holder binding, challenge nonce binding, supported presentation-assurance values, replay behavior, revocation, lifecycle events, privacy properties, and continuity_handle derivation.

Open Issues RFC Editor: Please remove this section before publication. The following issues are intentionally left for discussion:

Whether future revisions should add path template matching or keep only exact and terminal subtree path patterns.
Whether purpose templates need additional privacy constraints or richer matching syntax beyond exact string prefixes.
Whether clients should learn the challenge acceptance mode or validity interval.
Clock skew defaults for browser, mobile, embedded, and agent deployments.
Whether future revisions should use Accept-Signature for dynamic covered component negotiation.
Whether one or more companion profile drafts should be published with this document to demonstrate interoperability across independent realm operator designs.
Whether future revisions should introduce attestation audiences other than the canonical HTTPS origin of the request, either same-origin audiences narrowed within an origin at issuance time, or delegated cross-origin audiences, and under what rules for realm visibility and delegation trust.

Acknowledgements This document is informed by prior work on HTTP Structured Fields, HTTP Message Signatures, well-known metadata, OAuth 2.0 Protected Resource Metadata, and Privacy Pass. The editor thanks the authors and contributors of those specifications.