Thanks for the feedback Lucas! I've just published -01 to clarify that all parameter values are strings. While some parameters could be tokens, my view is consistency of having all parameters be strings is simpler for implementers. /Dick On Wed, Jan 7, 2026 at 10:23 PM Lucas Pardue <lucas@lucaspardue.com> wrote: > Hey, > > I only skimmed the draft and this is a nitpick but you'd likely benefit > from defining what Structured types are perkitted to be used in the > dictionary values and parametet values. I see a lot of Strings in the > examples but is that strictly a requirement? WouldbToken be suitablenot > arebthere risks that values would not be safely encodable in token. > > Cheers > Lucas > > On Wed, Jan 7, 2026, at 18:33, Dick Hardt wrote: > > Hey, > > I've just submitted a new individual draft that defines the > Signature-Key HTTP header field for distributing public keys used to verify > HTTP Message Signatures (RFC 9421): > > https://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/ > > *Problem*: To verify an HTTP Message Signature, the verifier needs the > signer's public key. While RFC 9421 defines signature creation and > verification procedures, it intentionally leaves key distribution to > application protocols, recognizing that different deployments have > different trust requirements. > > *Solution*: The Signature-Key header enables signers to provide their > public key or a reference to it directly in the HTTP message, allowing > verifiers to obtain keying material without prior coordination. > > Four schemes are defined: > - hwk - Inline public keys for pseudonymous verification > - jwks_uri - Identified signers with JWKS discovery via metadata > - x509 - Certificate-based verification with PKI trust chains > - jwt - Delegated keys embedded in signed JWTs for horizontal scale > > The draft is co-authored with Thibault Meunier (Cloudflare), and we > welcome feedback on the approach and schemes. > > /Dick > > >
Received on Thursday, 8 January 2026 09:24:47 UTC