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

[Justin Richer <[e-mail]>]

On conflating pass-by-value, pass-by-reference, and lookup: Section 3 defines one dispatch. The verifier looks up the scheme token in the Section 9.2 registry. A scheme it does not implement returns unsupported_scheme with the set it does accept in Accept-Signatutre-Scheme. A member the verifier did not select cannot cause a rejection. Tell me which of those rules produces the interoperability failure you expect.


The proposed Accept-Signature-Scheme and Accept-Signature-Alg create a world in which various combinations of parameters could be combined, perhaps erroneously, to create a valid-seeming setup. How does the client guess which combinations are acceptable? Accept-Signature deliberately combined parameters in the same way that the Signature header itself does — it’s an acceptable set.

Discovery at the level you’re describing seems better suited to a .well-known style protocol instead of something inline.

Your draft-richer-oauth-httpsig-03 looks to carry the same three modes — pub inline, keyid into a registered jwks, jwks_uri lookup — so the multiplicity is not where we disagree.

This is not a correct assessment of the other draft — The OAuth draft does not define the jwks or jwks_uri methods or their semantics, and instead relies on the rest of the OAuth protocol ecosystem to define the meaning of those key communication methods. The draft under discussion here would entangle itself with those and other key introduction systems. The OAuth doc concerns itself with “how does HTTPSig apply to OAuth”, and in doing so we identified a gap in the OAuth ecosystem for introducing HTTP signature key and algorithm sets at runtime, to mirror how DPoP works.


On Accept-Signature: it cannot carry what these headers carry. Its signature metadata parameters are Item parameters. Their values are bare Items (RFC 8941, Section 3.1.2) and cannot be Lists, and alg names one algorithm. A server has no way to say it accepts any of several algorithms, or any of several schemes. That is what Sections 4.1 and 4.2 do, and Section 4.3 covers the rest of the relationship, including keyid.

You can return multiple Accept-Signature header values with different combinations to show the client exactly what it would need to send. Or you can rely on an application level discovery mechanism.

Appendix B.5 of your draft lists Accept-Signature support as future work.

No, it defines “what does Accept-Signature mean in the OAuth world” as future work.


On the negotiation protocol: there is no negotiation. Accept-Signature-Scheme and Accept-Signature-Alg are advisory. A server that omits them asserts nothing. A client that ignores them is conformant. A client that cannot satisfy them gets Signature-Error, as it would today.

How is this not negotiation with a defined (even if loosely) default state?

And a nit: a client would not get Signature-Error today as that’s a new header proposed in the draft in question.

Two questions.

Which decision is being punted, and who should be making it? In this draft the verifier makes it and states it in Accept-Signature-Scheme. If it should be made once in the specification instead, which scheme wins?

You just said in the line above that the client can ignore that and the server doesn’t have to send it. There’s no interoperability handshake here, thus the decision is being punted down the line.

And why solve key introduction inside OAuth? Section 2.2 of your draft is the same problem — a party presenting a key the recipient has not seen before.

I would be happy to extract the public key signature parameter into an HTTP draft — it showed up in OAuth because that’s the use case driving it. Just like your Signature-Key header showed up in a separate proposal first before being brought here for discussion.

I agree that passing a public key by value is a valuable feature, but the document under discussion is not the way solve this problem. As I said in my message to this WG (https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0133.html) I haven’t seen the pull to extract it outside of that use case yet, but I’d be happy to do so.

Carrying it as raw bytes in pub rather than as a JWK costs you a second confirmation method in Section 5, a second algorithm registry that Section 3 declines to bridge, and the second RS code path your editor's note in Section 3.2 asks about. hwk carries a JWK, so it goes into cnf.jwk under RFC 7800 and none of that is needed. An HTTP client that has to authenticate to a server it has never talked to is not always an OAuth client. Solve it at the HTTP layer and OAuth gets it too.

This brings to light another problem I have with the proposed document: an over-reliance on JOSE semantics. Why does it need to be a JWK? The OAuth draft originally made the same mistake but the latest version strips that down to the bare necessities. If the key is being presented by value, you don’t need the enclosing syntax of the JWK — algorithm, type, and curve are all fixed and keyed is not needed because you’re never referencing it separately.

The confirmation type dichotomy doesn’t have to do with the JWK decision in the OAuth draft, but instead the decision to not rely on JOSE algorithms alone. This draft seems to ignore the HTTP Message Signatures algorithm space for a reliance on JOSE entirely, or hand-waves away the necessary connections.

 — Justin


Dick

On Mon, Aug 17, 2026 at 6:48 PM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
It's not just about the single header, it's about folding in all the disparate types of key resolution together then punting the actual decision away still. Even if the group wanted to do multiple headers for each key type, this draft's starting approach is not a good place to begin, and so I still say this document should not be adopted.

- Justin
________________________________
From: Ted Hardie <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 17, 2026 1:06 PM
To: Justin Richer <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Call for adoption: draft-hardt-httpbis-signature-key-08 (Ends 2026-09-07)

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]<mailto:[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]<mailto:[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