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

[Justin Richer <[e-mail]>]

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