Re: Call for adoption: draft-hardt-httpbis-signature-key-08 (Ends 2026-09-07)

[Dick Hardt <[e-mail]>]

Hi Ted

No disagreement from us. If the consensus of the working group after
adoption and discussion is one header per scheme, the authors would take
that approach. That is why we are proposing adoption — to tap the working
group's judgment on exactly this kind of question.

We are okay making breaking changes. Despite a fair number of
implementations, -08 raised RFC 9864's RECOMMENDED to a requirement: every
conveyed JWK MUST carry a fully-specified alg, and the polymorphic EdDSA
identifier MUST NOT be used. The implementation count is not what is
holding the design in place.

We are not deferring the one header per scheme though for lack of a
position, though. Martin and I discussed this 1:1 in Vienna, where he
pointed me at RFC 9170. Thibault and I worked through his feedback and
concluded that the benefits of a single header outweighed a header per
scheme. We documented that in Appendix A.5, "Why a Scheme Token Instead of
a Header per Scheme?":

https://dickhardt.github.io/signature-key/draft-hardt-httpbis-signature-key.html#name-why-a-scheme-token-instead-

RFC 9170 also drove the third invariant in Section 2 — unknown schemes and
algorithms get defined, mandatory feedback, so the extension point is
exercised on ordinary traffic rather than only when a new value is first
deployed. The other half of Martin's February message asked for use cases
motivating the formats; each scheme in Section 3 now carries its own.

Martin: given that additional context, we would value your feedback.

/Dick



On Mon, Aug 17, 2026 at 6:07 PM Ted Hardie <[e-mail]> wrote:

> Hi Justin,
>
> Martin's point that doing this in multiple headers rather than a single
> header could be correct, but it strikes me as the sort of decision the
> working group could take once change control shifts.  If the authors
> disagree with that take, though, now would be the right time to say so.
>
> regards,
>
> Ted
>
> On Mon, Aug 17, 2026 at 5:43 PM Justin Richer <[e-mail]> wrote:
>
>> I do not support adoption of this document. It adds layers of
>> complication to key negotiation that are almost certain to lead to
>> interoperability problems and security holes. Fundamentally, it conflates
>> pass-by-value, pass-by-reference, and lookup semantics into a single
>> multi-format structure. This alone is, to me, sufficient cause for concern
>> to reject it outright.
>>
>> In spite of the updates to the text, I still agree with Martin’s concerns
>> from earlier this year:
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2026JanMar/0067.html
>>
>> If anything, the new text makes the problem worse, not better.
>>
>> Furthermore, the draft creates a higher-level negotiation protocol and
>> confuses the process with the addition of several new headers in addition
>> to Accept-Signature, which already covers to the existing parameters.
>>
>>  — Justin
>>
>> On Aug 16, 2026, at 11:54 PM, Tommy Pauly via Datatracker <
>> [e-mail]> wrote:
>>
>> This message starts a httpbis WG Call for Adoption of:
>> draft-hardt-httpbis-signature-key-08
>>
>> This Working Group Call for Adoption ends on 2026-09-07
>>
>> Abstract:
>>   This document defines five HTTP header fields for use with HTTP
>>   Message Signatures as defined in RFC 9421.  The Signature-Key request
>>   header distributes public keys used to verify signatures, with eight
>>   initial key distribution schemes: pseudonymous inline keys (hwk),
>>   self-issued key delegation via JWK Thumbprint JWTs (jkt-jwt),
>>   identified signers with JWKS URI discovery (jwks_uri), direct JWKS
>>   fetch (jwks), JWT-based delegation (jwt), self-issued JWTs (self-
>>   jwt), X.509 certificate chains (x509), and references to previously
>>   cached assertions (cached).  The Accept-Signature-Scheme and Accept-
>>   Signature-Alg response headers state the schemes and algorithms a
>>   server accepts, so a client can select both before it signs.  The
>>   Signature-Error response header provides structured error information
>>   when signature verification fails, and the Signature-Key-Cache
>>   response header issues a cache identifier by which a caller can
>>   reference a previously presented assertion instead of resending it.
>>   Together, these mechanisms enable flexible trust models ranging from
>>   privacy-preserving pseudonymous verification to horizontally-scalable
>>   delegated authentication and PKI-based identity chains.
>>
>> Please reply to this message and indicate whether or not you support
>> adoption
>> of this Internet-Draft by the httpbis WG. Comments to explain your
>> preference
>> are greatly appreciated. Please reply to all recipients of this message
>> and
>> include this message in your response.
>>
>> Authors, and WG participants in general, are reminded of the Intellectual
>> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
>> Appropriate IPR disclosures required for full conformance with the
>> provisions
>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>> Sanctions available for application to violators of IETF IPR Policy can be
>> found at [3].
>>
>> Thank you.
>> [1] https://datatracker.ietf.org/doc/bcp78/
>> [2] https://datatracker.ietf.org/doc/bcp79/
>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-hardt-httpbis-signature-key-08.html
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-hardt-httpbis-signature-key-08
>>
>>
>>