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

[Dick Hardt <[e-mail]>]

Finn, welcome to HTTPBIS. I don’t recall seeing you participate here
previously. Would you mind introducing yourself and your
background/affiliation, and perhaps expanding on the technical or
architectural basis for your objection? In particular, what HTTP
architectural principle do you think makes standardized key
conveyance/discovery inappropriate here?

On Sat, Aug 29, 2026 at 12:33 AM Finn Sullivan <[e-mail]> wrote:

> I oppose adoption in this forum or any. Fundamentally, I don’t
> believe the IETF should undertake this as a generic HTTP facility.
>
> Putting something in an HTTP header doesn't make it appropriate to try
> and standardize it as an HTTP-layer thing. This draft takes eight
> materially different ideas for trust, delegation, discovery, and key
> distribution and tries to flatten them behind a syntax, with negotiation,
> caching, and error machinery piled on top. But HTTP cannot define who is
> entitled to assert a key, what authority that key conveys, how it binds to
> a principal, or which trust model applies. Those are application-protocol
> questions, and the answers are going to be different for each of these
> models.
>
> Common syntax does not make the underlying models coherent or
> interoperable; it just gives incompatible security semantics a misleading
> appearance of uniformity.
>
> If a concrete application protocol needs one of these mechanisms, it
> should define it there, within an actual trust and threat model. The IETF
> should not standardize a speculative, all-purpose authentication and
> key-distribution framework merely because it can kind of be expressed in
> HTTP headers.
>
> On Sun, Aug 23, 2026 at 6:12 AM Dick Hardt <[e-mail]> wrote:
>
>> Martin: to answer your question on forum -- I inquired with the chairs of
>> httpapi and httpbis on which WG they thought was more appropriate and
>> consensus was httpbis as the http message signing had been done in httpbis.
>> I have no strong preference.
>>
>> /Dick
>>
>> On Wed, Aug 19, 2026 at 2:59 AM Martin Thomson <[e-mail]> wrote:
>>
>>> I think that the question of spelling masks a deeper issue: use cases.
>>>
>>> I spoke with Dick, who had a wide array of use cases for each of the
>>> different modes (except perhaps the X.509 one).  With different motivation
>>> behind each, adopting this means adopting the entire array of use cases,
>>> even if you only like one of the set.
>>>
>>> Rather than bundling this, it seems like we should understand the use
>>> cases better first.  If there is just one user of each form, then maybe
>>> those users can define the fields as they need them.  There is still a
>>> chance to consult more widely about unifying formats as the opportunity
>>> arises, but a specialized use is fine.  If there are multiple users or the
>>> formats converge, then it makes sense to unify around a single format.
>>> Even in that case, it's not clear to me why this is generic HTTP as opposed
>>> to the HTTPAPI WG, except to the extent that unifying around a single
>>> format is a good thing.
>>>
>>> So I'm opposed to this in its current form.
>>>
>>> On Tue, Aug 18, 2026, at 03:06, Ted Hardie 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
>>> >>>
>>> >>
>>>
>>