IETF · 13 September 2026

HTTP Signature Keys

draft-hardt-httpbis-signature-key-09

D. Hardt (Hellō), T. Meunier (Cloudflare)

Individual draftDraft — expect changeAuthenticationAgent-specificField guide

Without this (or an equivalent), AAuth cannot bootstrap 'here is my key' on the first call to a resource that has never seen the agent.

At a glance

Problem: RFC 9421 signs HTTP messages but does not say how the verifier gets the signer's public key. Signature-Key is a general-purpose header and discovery mechanism so keys can be inline, in JWTs, at JWKS URLs, or in certificates.
Identity / authn / authz: Key distribution for authentication. AAuth uses it as the identity presentation layer (the agent token rides in Signature-Key).

Actors

HTTP client (agent)
HTTP server (resource, PS, AS)

The gap for agents

RFC 9421 tells you how to sign an HTTP message. It deliberately does not tell the verifier how to get the public key. Agents that are strangers to the resource cannot rely on a pre-shared JWKS URL configured in a portal. Something on the request has to carry or point at the key, with a scheme the verifier understands.

HTTP Signature Keys is that missing bootstrapping layer. AAuth hangs the agent token in Signature-Key. Without this draft (or an equivalent), AAuth identity-based access cannot start. Workload identities that already have a mesh trust bundle may not need it; open-world HTTP agents do.

Actors and trust boundaries

The signer asserts a key via a scheme: inline (hwk), JWT (jwt, self-jwt, jkt-jwt), JWKS fetch (jwks, jwks_uri), X.509, or a cache handle. Each scheme has a different trust story. jwt means 'trust this JWT's issuer to name the key'; hwk means 'here is a key with no identity'; x509 means 'walk a PKI'. Mixing schemes without policy is how you accept a throwaway key as if it were an agent.

The verifier must fetch jwks_uri / well-known documents carefully (TLS, SSRF allow-lists). Accept-Signature-Scheme and Accept-Signature-Alg let the server say what it will take before the client signs. Signature-Error structures failures so clients can retry with a different scheme rather than guessing.

Mechanics

Draft-hardt-httpbis-signature-key-09 (13 September 2026) defines five header fields for use with RFC 9421. Signature-Key carries the key or a pointer. Accept-Signature-Scheme and Accept-Signature-Alg (response) advertise what the server accepts. Signature-Error reports structured verification failures. Signature-Key-Cache issues a cache identifier so a later request can reference a previously presented assertion instead of resending it.

Eight initial schemes in -09: hwk (pseudonymous inline keys), jkt-jwt (self-issued key delegation via JWK thumbprint JWTs), jwks_uri (identified signers with JWKS URI discovery), jwks (direct JWKS fetch), jwt (JWT-based delegation — AAuth's scheme), self-jwt, x509, and cached. Catalog text that only listed hwk/jwt/jwks_uri/jkt-jwt/x509 is incomplete relative to -09.

dwk ('dot well-known') is how AAuth pins metadata document names: {iss}/.well-known/{dwk}. Cover the signature-key component in the signature base so an attacker cannot swap the header after the fact. Authors of -09: D. Hardt (Hellō) and T. Meunier (Cloudflare) — the catalog previously listed Hardt alone.

Signature-Keyfrom spec: Quoted header. Conveys or references the verification key for this request. Parameters include scheme and scheme-specific members.
scheme=jwt | hwk | jwks_uri | jwks | jkt-jwt | self-jwt | x509 | cachedfrom spec: Quoted initial schemes from draft-09. AAuth uses jwt for agent/person/auth tokens. hwk is a key without an identity issuer.
dwkfrom spec: Quoted parameter used with JWT schemes to name the well-known metadata document (AAuth: aauth-agent.json, aauth-resource.json, aauth-person.json, aauth-access.json).
Accept-Signature-Scheme / Signature-Error / Signature-Key-Cachefrom spec: Quoted companion headers in -09. Negotiation, structured errors, and cache handles. Not present in RFC 9421 itself.

Step-by-step flows

Flow 1 of 2

First call with scheme=jwt (AAuth-shaped)

1
Client holds a JWT whose cnf.jwk is the signing key (agent token or similar).
2
Client signs the HTTP request per RFC 9421, covering signature-key, and sends Signature-Key with scheme=jwt and the JWT.
3
Server reads scheme, validates the JWT (typ, iss, exp, signature via JWKS at iss + dwk), extracts cnf.jwk, verifies the HTTP signature.
4
On failure the server MAY return Signature-Error describing scheme/alg problems; the client may retry with a scheme from Accept-Signature-Scheme.

Flow 2 of 2

Pseudonymous inline key (hwk)

When the server is willing to accept a key with no issuer-backed identifier.

1
Client puts an inline JWK in Signature-Key with scheme=hwk and signs the request.
2
Server verifies the signature with that key and applies policy for 'unidentified key' (often deny except for specific endpoints).

Useful for privacy-preserving proofs. Not a substitute for an agent identifier when the resource must audit who called.

Identity vs authentication vs authorization

This document is key distribution for authentication. It does not define who the signer is (that is the JWT profile or the certificate) and it does not define what the signer may do (AAuth auth tokens, OAuth, local policy).

AAuth uses it as the identity presentation layer: the agent token rides in Signature-Key. WIMSE has its own WIT header plus WPT; do not assume Signature-Key is how WITs travel.

How it composes

HTTP Message Signatures
RFC 9421 is the signature algorithm and component coverage. This draft is the key-discovery companion the RFC left to applications.
AAuth
Normative building block. AAuth's first-call identity is Signature-Key + jwt + dwk well-knowns.
DPoP
DPoP puts a JWK in the proof JWT's header and a thumbprint in cnf.jkt on the access token. Different header, different protocol. A resource that speaks both must not confuse a DPoP proof with Signature-Key.
JWT
jwt / jkt-jwt / self-jwt schemes are JWT profiles riding in an HTTP header. Validate typ, alg allow-lists, and iss as the profile requires.
WIMSE WPT
WPT is another application-layer PoP (Authorization: WPT plus Workload-Identity-Token). Complementary, not interchangeable.

What bites agent implementers

Uncovered Signature-Key
If signature-key is not a covered component, an attacker who can modify headers swaps in their JWT/key. The signature still verifies over the rest of the request.
Scheme confusion
Accepting hwk where you meant jwt means any key is an identity. Policy must be per-scheme.
SSRF on jwks_uri / dwk
Fetching attacker-controlled URLs from a signature header is a classic SSRF. Allow-list hosts, require HTTPS, cap redirects.
Individual draft churn
-09 added authors, cache headers, and more schemes versus earlier catalog summaries. Pin the revision. Not a WG HTTPBIS document despite the 'httpbis' in the filename.

Stability — what you can ship

draft-hardt-httpbis-signature-key-09, 13 September 2026, expires 17 March 2027, individual, intended standards track. Authors: D. Hardt, T. Meunier. Datatracker: https://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/.

Designed as a building block for AAuth and other applications (the draft's abstract mentions flexible trust models from pseudonymous to PKI). You can prototype with AAuth; you cannot cite an RFC number yet.

Catalog claims (short form)

Signature-Key: Conveys or references the verification key for this request.
dwk: AAuth pins dwk values: aauth-agent.json, aauth-resource.json, aauth-person.json, aauth-access.json at {iss}/.well-known/{dwk}.

Implementer notes

Individual draft, intended standards track, not a WG document despite 'httpbis' in the filename. Draft-09 (13 September 2026) lists eight schemes (hwk, jkt-jwt, jwks_uri, jwks, jwt, self-jwt, x509, cached) and adds Accept-Signature-Scheme, Signature-Error, and Signature-Key-Cache. Designed as a building block: AAuth and Email Verification both use it. Cover the signature-key component in the signature base so an attacker cannot swap the key header.

Relationship to others

Primary sources

Datatrackerhttps://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/
HTML of draft-09https://datatracker.ietf.org/doc/html/draft-hardt-httpbis-signature-key-09