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

[Finn Sullivan <[e-mail]>]

Dick. I don’t recall that sharing background or affiliation is necessary
for participation here nor that an introduction is prerequisite to voicing
an objection. The basis of that objection is already set out below.

On Sun, Aug 30, 2026 at 6:24 AM Dick Hardt <[e-mail]> wrote:

> 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
>>>> >>>
>>>> >>
>>>>
>>>