Summary

  • HTTPbis has issued a Call for Adoption on draft-hardt-httpbis-signature-key-08; the Datatracker describes that state as a running call before consensus for adoption, not an adopted working-group document or an RFC.
  • The draft can standardize paths for finding a public verification key. It expressly leaves pre-configured, out-of-band and application-specific acquisition possible, so it cannot select the separate local policy that decides which verified signer may do which thing.

Eight mechanisms are a generous menu. They are not eight permissions.

The HTTPbis call asks the working group whether draft-hardt-httpbis-signature-key-08 should become a group work item. Its stated deadline is 7 September 2026. The message describes five header fields for use with HTTP Message Signatures and a set of initial ways in which a recipient might obtain verification material: inline pseudonymous keys, thumbprint-bound delegation, JWKS discovery, direct JWKS, JWT forms, X.509 chains and a reference to a cached assertion. It asks the community to reply with support or opposition and reasons.

That creates a valuable record of a procedural question. It does not create the outcome of that question. The Datatracker’s own state description is explicit: a Call For Adoption By WG Issued means that the call is running and the working group has not yet reached consensus for adoption. If consensus is later found, that will be a new state with its own actor, date and basis. A working-group document will be another state. Review, IESG action and any RFC publication will be later states again. A countdown date cannot carry all of them in advance.

This distinction is especially important because the draft itself describes capabilities that look close to policy. A jwks_uri can point to key material. A JWT can convey a relation relevant to a signer. An X.509 chain can support a familiar public-key validation path. A cached assertion can spare a caller from resending data. An Accept-Signature-Scheme response can tell a client which scheme tokens a server supports before the client signs. Those are all mechanisms with real security and interoperability consequences.

Yet a mechanism that permits verification is not the same thing as a policy that confers authority. Verification can establish that a message was signed by the private key corresponding to public material obtained under a defined procedure. A resource owner must still decide whether the signer is an acceptable principal for that resource; whether a signed request represents a human, a workload or a delegate; which claims, account relationship or contract are required; what action scope and limit apply; and how a denial, an exception, a revocation or an incident will be recorded.

Nothing in a generic key-distribution header can silently make those choices for every endpoint that might parse it.

The draft preserves this boundary rather than pretending it does not exist. It says that pre-configured keys and out-of-band key exchange are outside Signature-Key’s scope. A Signature-Key header is not required for those signatures, and a verifier may use application-specific means to obtain the verification key. That is not a minor escape clause. It records that key acquisition remains a deployment choice. An application may use the header, decide not to use it, or bind it to additional conditions that are not supplied by the header alone.

Consider a signed request to release funds, change a medical record, start a server, submit a government filing or invoke a tool on behalf of an employee. Each could carry a mathematically correct signature. Each might enable a verifier to locate a public key through one of the draft’s schemes. Still missing are the local facts that make the action legitimate: the identity context, the delegation relation, the current entitlement, the resource owner’s policy, applicable limits, expiration, audit retention and a path to correct a wrong grant. To name a key is not to name a principal. To validate a signature is not to validate a purpose.

The HTTPbis charter supplies an institutional reason to leave that boundary intact. The active group maintains core HTTP and may develop generic extensions, provided they are not specific to one application. It is a forum for interoperability and protocol health, not a standing authority over every application’s account model, consent rule, risk acceptance or business approval. Its chairs can conduct the group’s process. The group can decide whether a generic header proposal deserves collective work. Neither action transfers a resource owner’s authority to decide which signatures its service will accept as authorization.

This is not an argument to dismiss the draft. A common way to carry or refer to verification material may reduce needless bilateral coordination and make HTTP Signature implementations more interoperable. The draft’s breadth is itself a reason to examine it carefully: its initial schemes range from pseudonymous to identity-bearing and delegated forms, and their security and privacy effects are not interchangeable. The public discussion can surface implementation costs, downgrade risks, cache controls, discovery hazards and registration questions before a work item is accepted.

But a review of those technical questions cannot become a borrowed trust decision. A provider should not tell a customer that support for Signature-Key proves the provider is authorized to execute the customer’s instruction. An implementer should not report an X.509-path check as evidence that a key holder has the right business role. An operator should not say that a draft’s extensibility releases it from choosing egress rules for JWKS retrieval, binding identity to an account, or preserving logs for a disputed request. The work may make each of those local decisions easier to express. It does not take them.

The cleanest governance record therefore has two columns. The protocol column begins with the call, records later consensus if it occurs, preserves the exact draft version and tracks the specification’s technical requirements. The application column names the policy owner, acceptable signer classes, credential and delegation rules, endpoint acceptance criteria, scope, limits, logging, review and revocation. A link may connect the columns—an application may adopt a published HTTP mechanism—but neither column can fill in the other’s missing fields.

That two-column discipline also protects the public record from inflated participation. Mailing-list replies can demonstrate technical support, concerns or questions from their authors. They can improve a work item. They cannot bind absent resource owners, users or counterparties to an application’s trust policy. Participation remains evidence and technical discipline; it does not become a general mandate. Similarly, a future working-group result can make an interoperability statement without becoming a warrant for a signed business action.

The defensible conclusion is narrow. HTTPbis has opened a running call on a draft that could standardize generic HTTP Signature key-distribution behavior. It has not chosen a universal trust model, selected a trusted issuer for every application, or authorized a live operation. Keeping the decision surfaces separate makes the draft easier to evaluate on its merits and keeps the eventual application owner visible where accountability belongs.

Sources