I +1 Aaron position here.
FAPI 2.0 already open the door to have both PoP methods as valid therefore
having an end to end HTTPSig coverage would be better for consistency.
Also, from my reading of the 2021 exchange (I was not senior nor involved
enough at the time so I had to look it up) of the former proposal, the salient
elements for the NO were:
* HTTP Message Signatures [was] not yet been adopted as an IETF draft.
* This is solved now.
* The mechanism is not widely deployed as far as he knew.
* There have been implementations cf. Justin, FAPI , and others.
* It has not stabilized or proven itself in the field.
* There have been 2 errata in 2024 to improve the RFC
* Errata #8103 (Structured Field parsing vulnerability):
https://www.rfc-editor.org/errata/eid8103
* Errata #8102 (Terminology issue):
https://www.rfc-editor.org/errata/eid8102
* The WG already has sufficient work items.
* This is still the case (un)fortunately.
* Adding another PoP mechanism is likely to confuse the community rather
than help it.
* This where I and other agree, but I agree it is not blocking the
clarifications.
* Resources should focus on existing, proven mechanisms.
* HTTPSig is a proven mechanism
* Let’s have Drafts on DPoP as profiles per use case to allow the debate
to progress too if this is pertinent.
* Suggested waiting for HTTP Sig to stabilize and gain field deployment.
* As explained this is done.
* Once proven, the OAuth WG can then build extensions for OAuth use cases.
* Here is why this proposal is coming back.
As a personal use case that I did not see DPoP solving is the Token Exchange of
a DPoP protected Access Token. Shame on me to not have worked on a proposal
here for DPoP, still from the discussion I got, the oversigning capability of
HTTPSig seems to be a right fit for this use case.
Jean-François “Jeff” Lombardo | Amazon Web Services
Principal Standards Specialist, Identity Services
Montréal, Canada
From: Aaron Parecki <[email protected]>
Sent: September 22, 2026 1:30 PM
To: Justin Richer <[email protected]>
Cc: Warren Parad <[email protected]>; oauth <[email protected]>
Subject: [EXT] [OAUTH-WG] Re: Call for adoption - OAuth Proof of Possession
Tokens with HTTP Message Signatures
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
contenu ne présente aucun risque.
I support adoption for the reasons Justin mentions below.
If we don’t adopt this, people are going to continue using HTTPSig for OAuth
PoP anyway, it will just be one-off implementations instead of based on a
consistent profile. That will arguably lead to worse interoperability problems
later down the road since everyone will be signing slightly different things
and managing key distribution in their own way.
I am totally on board with better clarifying in the document when HTTPSig makes
sense to use over DPoP, but that doesn’t seem like a blocker to adoption.
Aaron
On Tue, Sep 22, 2026 at 8:46 AM Justin Richer
<[email protected]<mailto:[email protected]>> wrote:
I think a lot has changed in six years, actually. RFC9449 (DPoP) is published
and no longer an active WG item, and one of the arguments at the time was
splitting the group’s attention. RFC9421 (HTTPSig) is also published and widely
deployed, and several proposals have been made to extend DPoP into spaces that
HTTPSig covers natively. We’ve got a few years of experience in both that can
better inform the combination of HTTPSig and OAuth. We’ve also got people
making this combination on their own because it’s nearly obvious how to fit
them together and sign an OAuth message. The real value of this doc is the key
assignment, from which we take a lot of learnings from both DPoP and mTLS as
well as WIMSE’s HTTPSig draft.
— Justin
On Sep 22, 2026, at 8:07 AM, Warren Parad
<[email protected]<mailto:[email protected]>> wrote:
I would appreciate knowing what exactly has changed since the last time this
draft was brought to the WG and rejected.
On Tue, Sep 22, 2026 at 1:56 PM Dick Hardt
<[email protected]<mailto:[email protected]>> wrote:
I'm opposed to adoption of this draft.
It is focussed on binding a key to an access token, which the WG has already
solved with DPoP (RFC 9449). It is not clear why a new mechanism is needed. The
editor's note in Section 1 says the draft still needs to give guidance on when
to use it instead of DPoP or mTLS.
Section 4 introduces a new representation for public keys, the pub signature
parameter carrying raw key bytes, instead of using JWK (RFC 7517). Because of
that, Section 5 has to define a new htsk confirmation method. A resource server
also has to support two algorithm registries and two code paths, depending on
how the key was bound. The editor's note in Section 3.2 acknowledges this.
It ignores the other HTTP message signature key exchange work, all of which
conveys keys as JWKs:
Web Bot Auth:
https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/
Signature-Key:
https://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/
WIMSE: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/
On Mon, Sep 21, 2026 at 8:17 PM Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>> wrote:
All,
This is an official call for adoption for the OAuth Proof of Possession Tokens
with HTTP Message Signatures draft:
https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-03.html
Please, reply on the mailing list, on whether you support or oppose the
adoption of this draft as a WG document by October 5th.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
