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

[Dick Hardt <[e-mail]>]

One more argument for a common mechanism: caching.

A key, or a JWT with a cnf claim and a signature, are the expensive part of
these exchanges and the stable part. It is identical on every request from
a given client. Signature-Key-Cache and the cached scheme send it once and
reference it thereafter.

The cache belongs in the HTTP stack, not in the application. Our middleware
does not know whether the endpoint speaks EVP or AAuth, and it should not
need to in order to know it has already verified this JWT and when that
entry expires. If each protocol carries its key in its own message, every
RFC 9421 implementation needs one code path per protocol to decide what is
cacheable and for how long.

ML-DSA makes this pressing. ML-DSA-44 is a 1312-byte public key and a
2420-byte signature; ML-DSA-87 is 2592 and 4627. An ML-DSA-signed JWT, or a
certificate chain, runs to tens of kilobytes on every request unless it can
be sent once and referenced. Passing the key by value each time stops being
viable at those sizes, and per-protocol caching means solving the same
problem four times.

As Ted noted, how these keys are cached has to be considered against the
other caching already in the stack. That is an HTTP question.

/Dick

On Thu, Aug 20, 2026 at 1:59 PM Dick Hardt <[e-mail]> wrote:

> > My sense from each of those proposals is that the transport of keys is
> native to the protocol/application in use.  Each is different.
>
> While each protocol does dictate the key transport, the keys are
> transported in similar shapes:
>
> - bare key (or wrapped key)
>
> OAuth[1], EVP[3], and AAuth[4])
>
> - reference to a key at a url (directly or via a .well-known)
>
> web bot auth[2], OAuth, AAuth
>
> - a key as a cnf claim in a jwt
>
> AAuth, wimse [5]
>
>
> Each of these protocols has defined their own mechanism for the same
> scheme.
> Each has their own error responses for alg agility.
>
> The Hellō servers support both EVP and AAuth -- and we use one middleware
> that does http message signature verification that is unaware of the
> protocol of the endpoint.
>
> As noted in the post from Abay Aubakirov, implementors are already hitting
> issues with multiple http message signing schemes colliding
>
> There is industry interest as well in a generic mechanism to replace API
> keys for http clients to authenticate that is not protocol/application
> specific. Scott Motte maintains .env, one of the more popular OSS tools for
> managing API keys, and is working on how to adapt web bot auth to replace
> API keys.
>
> /Dick
>
> [1] https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig-03
> [2]
> https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-02
> [3]
> https://datatracker.ietf.org/doc/html/draft-hardt-email-verification-01
> [4]
> https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-10
> [5] https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/
> [6] https://github.com/vestauth/vestauth
>
> On Thu, Aug 20, 2026 at 8:14 AM Martin Thomson <[e-mail]> wrote:
>
>> My sense from each of those proposals is that the transport of keys is
>> native to the protocol/application in use.  Each is different.  Where the
>> HTTP message signing key requires endorsement before it is useful, carrying
>> the key in an endorsement makes more sense than having some unlabeled
>> container.
>>
>> For instance, in Justin's work, there is an OAuth "message" that carries
>> a request for a token.  That's where the key belongs.  I note that DPoP
>> requires proof that you know the private key when requesting a token, which
>> is probably not necessary, but the fact that it uses an HTTP Message
>> Signature for that purpose doesn't mean that the key transport needs to be
>> generic.  It's content that is specific to that domain and exchange, so it
>> can follow norms for the "message" there.
>>
>> The same applies throughout.  What seems common throughout is the need
>> for some hook that ties the key identifier in an HTTP Message Signature to
>> the application and key that is in use.  That seems like a useful construct
>> to build, but that's not the same as a generic key signaling mechanism.
>> Consider the client metadata stuff that Justin's draft references: that
>> could hold keys and establish key identifiers for keys that are used in
>> signing.
>>
>> Your own webbotauth proposal establishes the same tie by offering a bot
>> identity that also serves as a key delivery mechanism.  No need for a
>> header there.
>>
>> A generic system like this doesn't really achieve much.  Because the
>> semantics of the key are what is most important and a generic container
>> can't do anything to help with that.  Sometimes that means that the key
>> needs to be endorsed by another key that carries a different semantic,
>> sometimes not.  A bare key with no semantic has no real use outside of the
>> context of the protocol that uses that key.
>>
>> Consider how useful Link is and whether you think that this is an
>> acceptable pattern:
>>
>> Link: <data:....key bits...>; rel="key"
>>
>> And then compare that to a rel attribute that implies a more specific
>> semantic.
>>
>> On Thu, Aug 20, 2026, at 04:06, Thibault Meunier wrote:
>> > Hi httpbis,
>> >
>> > Thanks for the input. As a co-author I support adoption.
>> >
>> > Martin, I think you are right that the question is use cases rather
>> > than spelling. Here is what I have on that side.
>> >
>> > There are a couple of use cases which are converging on similar
>> > primitives across multiple wg. The oauth draft from Justin [1] passes
>> > the key by value so it can be used by HTTP Message Signatures, and does
>> > it as a signature parameter in Signature-Input. A draft I have in
>> > webbotauth [2] allows key material to be discovered by URL via an HTTP
>> > header. The email verification protocol [3], presented at dispatch in
>> > July 2026, also obtains a key by value using a header, similar to aauth
>> > [4] that is another draft from Dick, presented in oauth.
>> >
>> > To me, these primitives would benefit from having a shared framework. A
>> > shared header may or may not be the way to go. But at least, I think we
>> > should understand
>> >
>> > 1. should values be passed via a new HTTP header, a signature
>> > parameter, or an out of band document
>> > 2. are there specific interactions with the signature label. This draft
>> > posits that there should (the label of Signature-Key must match the one
>> > of Signature and Signature-Input), while [2] binds it differently (the
>> > Signature-Agent member keyed to the label is itself covered, as
>> > "signature-agent";key="sig1").
>> > 3. how are errors communicated?
>> > 4. any interaction with cache and pre-registered keys?
>> >
>> > HTTP seems to be the right venue for such an effort, since these are
>> > signature base and covered component questions in an extension to RFC
>> > 9421. I do not think that the eight schemes as they are written have to
>> > stay (such as x509), and that can be consolidated by the wg. Happy to
>> > help to pull individual primitives from existing proposals if that's
>> > the direction.
>> >
>> > In any case, none of this prevents the individual drafts [1][2][3][4]
>> > from moving. The main case is that as a maintainer of an http message
>> > signature implementation, I would rather not write one code path per
>> > use case while the underlying primitive is similar.
>> >
>> > [1] https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig-03
>> > [2]
>> >
>> https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-02
>> > [3]
>> > https://datatracker.ietf.org/doc/html/draft-hardt-email-verification-01
>> > [4]
>> >
>> https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-10
>> >
>> > Thibault
>> >
>> >
>> > On Monday, August 17th, 2026 at 06:02, Tommy Pauly <[e-mail]>
>> wrote:
>> >
>> >> Hello HTTP WG,
>> >>
>> >> At IETF 126, we discussed draft-hardt-httpbis-signature-key and we
>> heard a fair bit of interest in this work. We’ve previously issued an
>> adoption call earlier in the year, but we’ve had more discussion since
>> then. We’d like to get input from the group on whether or not you think we
>> should adopt this work. Please email the list with your input by September
>> 7!
>> >>
>> >> Best,
>> >> Tommy
>> >>
>> >>
>> >> > On Aug 16, 2026, at 8: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
>> >>
>> >>
>> >>
>>
>