HI all, I'm not sure I support adoption as I don't think I see a need to replace access token binding with another binding method outside of DPoP and mTLS. The one use case that makes sense to me is binding to the request payload - e.g. binding the request to the same DPoP key material and/or DPoP proof that is used for tokens.
I'm slightly concerned we will have two similar methods of binding tokens that resource servers will need to be able to support given the DPoP is already out there. I also don't see the issue regarding RTs for confidential clients. If we need separate proofs for AT/RTs (I'm not sure I agree with this either to be honest), couldn't we look at extending or releasing a new version of existing DPoP? Saying this from having implemented DPoP myself in OSS as well as running DPoP at $dayjob. On Thu, 24 Sept 2026 at 09:44, <[email protected]> wrote: > Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > Today's Topics: > > 1. Re: Call for adoption - OAuth Proof of Possession Tokens with HTTP > Message Signatures > (Paul Bastian) > 2. Re: Beyond the DPoP / HTTPSig choice: login and session as one > problem > (Lombardo, Jeff) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Sep 2026 21:21:00 +0000 > From: Paul Bastian <[email protected]> > Subject: [OAUTH-WG] Re: Call for adoption - OAuth Proof of Possession > Tokens with HTTP Message Signatures > To: Neil Madden <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: multipart/alternative; > boundary="------------agels0x7Z4ev3LvBq7Y4CqNP" > > Hi Neil, > > thanks for the detailed review. Here are my thoughts: > > *1.* DPoP exists because TLS alone was judged insufficient to protect > access tokens in real deployments. We're applying the same reasoning to > the request the token authorizes. TLS termination at DDoS protection or > corporate proxies is a deployment reality. The difference from HttpSig > is that a terminating proxy gets full read/write access under TLS, but > cannot forge a signature. Stripping it doesn't help either, because the > AS/Credential Issuer requires it. > The motivating payloads (holder keys and key attestations in OpenID4VCI > proofs) aren't secret, so confidentiality isn't my concern. The attack > is substituting them so the credential is bound to an > attacker-controlled key, so integrity is the property at stake. Where > additional confidentiality is needed, OpenID4VCI provides options for > application-level encryption, but that's debatable. > The signature is verified where the request is semantically consumed, > i.e. the Credential Issuer endpoint. The issuer's internal decomposition > is its own trust domain, which is the same scoping as DPoP. > > *2.* One of the ideas here is that you may want to bind an RT to a > different key (e.g. HSM) than an AT. > > *3/4.* I'm working in regulated industries, where usage of HSM is > mandatory, loading private keys in memory is simply not allowed. > RFC 9449 doesn't require a server to return |DPoP-Nonce| on a proof-less > request, and doesn't mandate error precedence, so clients can't rely on > this interoperably. The AS may simply return an |invalid_request|, and > not return a nonce. It also only covers the first request: on nonce > rotation, the client discovers expiry only through a failed signed request. > > Best regards, > > Paul > > On 9/23/26 2:53 PM, Neil Madden wrote: > > Hi Paul, > > > > Thanks for sharing this slide deck. I think it would be useful if some > > of this rationale was summarised into the draft introduction, so that > > it is clear to readers what problems the new proposal is intended to > > solve. > > > > I summarise your arguments as follows: > > > > 1. DPoP doesn't protect the contents of HTTP messages, such as public > > keys in OpenID4VCI proofs. > > 2. DPoP doesn't protect refresh tokens for confidential clients, and, > > when it is used for (public client) RTs it uses the same key as > > for ATs. > > 3. Nonce negotiation requires an additional roundtrip with a "wasted > > signature" to retrieve an initial/updated nonce. This is > > potentially expensive in time and money especially for HSM-backed > > signing keys. > > 4. The HTTP 400 status code when requiring a nonce is confusing and > > leads to broken client logic. > > > > > > My responses to these issues are as follows: > > > > 1. The need to protect message bodies: > > > > The cited need for this is to protect against active attackers "after > > TLS termination". I would firstly question why OAuth needs to address > > what clearly appears to be architectural defict. If the payload needs > > protection "after TLS termination" then why has TLS been terminated > > prematurely? (And what would prevent HttpSig also being terminated > > similarly prematurely at some middlebox?). > > > > Why only protect integrity? TLS also protects confidentiality, and > > that protection is also being lost by this early termination. I fear > > that if we approve this approach, then it's only a matter of time > > before somebody then claims that confidentiality also needs to be > > protected downstream of TLS termination. Signatures are no help at all > > with that. > > > > There is also the question of what happens even further downstream. > > TLS termination is presumably being done at a gateway which is then > > forwarding the request un-altered. But what happens when it then hits > > eg a frontend service and results in N new requests to backend > > microservices, each request slightly different (but perhaps including > > sensitive details from the original)? All those requests would also > > need protection under your rationale, but neither DPoP nor HttpSig can > > address that, being point-to-point solutions rather than end-to-end. > > Either you need to go back to properly configuring TLS where it is > > needed (perhaps via a service mesh), or else design a solution that > > does work end-to-end. > > > > Finally, as already noted, using a non-repudiable signature over the > > entire HTTP body is using a sledgehammer to crack a nut, and will have > > unintended consequences (see my other messages in this thread). > > > > 2. > > i. No DPoP for Confidential Client RTs > > > > I don't really understand this problem. As the DPoP RFC notes, RTs for > > confidential clients are already sender-constrained, so what is the > > problem? > > > > ii. Using the same key for RTs and ATs > > > > Again, what is the problem here? There's nothing inherently bad about > > using the same key to sign DPoP proofs for ATs and RTs. What threat > > model are you trying to address? > > > > 3. Nonce negotiation is expensive. > > 4. Nonce negotiation using 400 status is annoying. > > > > I don't disagree with this. I don't particularly love the DPoP nonce > > negotiation. (A long time ago I proposed an alternative based on ECDH > > key agreement and then the use of a short-term HMAC key instead, but > > it was rejected by the WG). > > > > IMO the HSM issue is also an architectural problem. After much > > real-world experience with HSMs and KMSes I have formed the conclusion > > that you want them out of the hot path of your systems as much as > > possible: they are a reliability and performance bottleneck. Instead, > > I always recommend that people follow the approach of Google's Tink > > cryptography library: use the HSM to decrypt a set of keys on > > startup/periodically and then use those keys locally rather than > > calling out the HSM every time. Rotate them regularly mitigate to > > reduce the risk of compromise. I appreciate this is not always > > possible, but I've never seen anything but pain from having a direct > > dependency on a HSM at runtime. > > > > But aren't these issues solved anyway by the client simply not sending > > a DPoP proof at all in its first request? The server should then > > respond with a 401 and WWW-Authenticate: DPoP header, and could simply > > include a DPoP-Nonce header too at that time. No extra overhead for > > the client, normal 401 return code, and all done in a single > > roundtrip. This already seems permitted by the spec. > > > > On contrast, the draft being proposed here doesn't support > > server-generated responses at all, only client-supplied ones. This > > doesn't address the precomputation attack discussed section 11.2 of > > RFC 9449, which was the reason for adding nonces in the first place. > > So this argument doesn't appear to be addressed in any case by the > > proposed draft. > > > > -- Neil > > > > > >> On 22 Sep 2026, at 20:41, Paul Bastian <[email protected]> wrote: > >> > >> Hi Warren, > >> > >> Here is the slide deck from OSW: > >> > https://docs.google.com/presentation/d/1M54dFlaJP0UXeuIpYS3iPDDW3ulmySYP4yStO14SrbE/edit?usp=drivesdk > >> > >> > >> We asked people at the end of the presentation which direction to go. > >> Nobody supported extending DPoP. 5 people supported the direction of > >> this draft. > >> > >> Best regards, > >> Paul > >> _______________________________________________ > >> OAuth mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >-------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 11110 bytes > Desc: not available > > ------------------------------ > > Message: 2 > Date: Wed, 23 Sep 2026 21:43:33 +0000 > From: "Lombardo, Jeff" <[email protected]> > Subject: [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and > session as one problem > To: Neil Madden <[email protected]>, Thi Nguyen-Huu > <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: <[email protected] > rd18.prod.outlook.com> > Content-Type: multipart/alternative; boundary="_000_PH0PR18MB46850D > 0693B4AC8C285EAAEBD9822PH0PR18MB4685namp_" > > +1 to Neil > > We are conflating multiple things here. > > The key in DPoP, mTLS, HTTPSig is a key possessed by the Client to prove > it is the one which got authorized through the issuance of the access token > to perform a task for the scope, audience, and possible > authorization_details as well as access control logic based on other claims. > > When a user in involved, this happens during the authorization process. > This could rely to a private / public key based authentication scheme > (OIDC) with a keyset owned by the user (FIDO2). This keyset could be stored > on a portable or local hardware support. > > The action of authorizing is here to bound: the authenticity of the user > delegating with the key of the client acting on its behalf. Once done the > user is no longer required to be involved as it is the client key that is > used when accessing resources on the basis of this authorization. The fact > that the client has a key to bound authorization and that this key is only > existing upon security posture checks is exactly what WIMSE is already > proposing. > > Giving access from the client to the user bound keys is a unsecure are the > client could then authorize itself for any scope, audience, and possible > authorization_details as well as access control logic based on other claims > without the user knowledge and capability of action. This would confuse the > AS as it will impossible for it to differentiate an authorization request > to act on behalf of the subject/user and an authorization request in the > back of the user/subject. This would be especially bad for AI Agent > architecture. > > There are some works on allowing the client to expand beyond the initial > authorization scope, audience, authorization_details, etc. with boundaries > on what could be requested. For example, Karl McGuiness proposal around > Mission Based for OAuth. > > Jeff > > Jean-François “Jeff” Lombardo | Amazon Web Services > > Principal Standards Specialist, Identity Services > Montréal, Canada > > From: Neil Madden <[email protected]> > Sent: September 23, 2026 4:05 PM > To: Thi Nguyen-Huu <[email protected]> > Cc: [email protected] > Subject: [EXT] [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and > session as one problem > > > 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. > > They are separate because they authenticate different things. The login > authenticates the user, who then authorises a client. The client (which may > or may not be acting under direct user supervision) then acts using the > access token(s) - what you refer to as a session. They *could* in some > circumstances use the same mechanism, but there is no need to conflate > them. In particular, requiring a client to use a user’s credentials (eg > key) seems to defeat the purpose for which OAuth exists in the first place > - to avoid such credential sharing. > > Neil > > > On 23 Sep 2026, at 20:42, Thi Nguyen-Huu <thi.nh= > [email protected]<mailto:[email protected]>> > wrote: > > Subject: Beyond the DPoP / HTTPSig choice: login and session as one problem > > Hello, > > As the WG is discussing mTLS, DPoP and HTTPSig, I would like to raise a > question I have wanted to raise since joining the IETF this year. > > All three constrain who may present a token, with a proof of possession of > a key. The token exists because the authentication happened earlier, > somewhere else, and something has to carry it forward. > > What if the key represents an identity now — that is, authentication: a > condition-bound key, or easier for me to say a Live Key, that exists and > can sign only while the authorized user is using the authentic, authorized > endpoint with a policy-compliant security posture, and disappears when any > of that stops being true. > > With such a key, a login is no longer needed. An mTLS session using it as > the client key needs no user login, and identity is proven at the moment of > the request, on every request, for the session and each transaction in it. > > That is what I would like the group to consider. Today a login is needed > to establish who is there, and mTLS, DPoP or HTTPSig protect the session > that follows it: two problems, two solutions. > > But, one key can do both — it is the authentication, and it is what the > session is bound to. Simpler and end-to-end. > > To be precise, this key represents "identity". Online identity, as I use > the term, is a combination of actor, platform and local posture — the actor > being a user, an AI agent, an application, a browser, whatever acts. The > key is therefore registered per actor and endpoint. What that identity is > entitled to still comes from the authorization server, or from the token. > > OAuth might not be about login — that is perhaps OIDC's and FIDO2's > ground. But the issue is a gap in security, and more precisely in > cryptography. Current user authentications, Passkeys included, end in a > verdict. They do not establish a key to protect the data exchange that > follows, as an encapsulated operation like an authenticated key exchange > would. And so the token is not protected by the authentication. Other > methods may provide alternatives, but mTLS protecting login and session in > one atomic operation is stronger than covering login and then covering the > session separately. > > What I'd like to know is whether this group sees collapsing login and > session as in scope for OAuth. I have argued elsewhere that withstanding > AI-enabled attacks needs end-to-end cryptography, and that separating login > from session is a gap in it — one that can be closed. If it is out of scope > here, I would value a pointer to where it belongs — WIMSE, W3C, or > elsewhere. > > PS: Btw, the same condition-bound key works under all three mechanisms and > can carry whatever the token is meant to assert. > > Cheers > > Thi Nguyen-Huu > CEO > <image001.png> > winmagic.com<https://winmagic.com/> > <image002.png> > 11-80 Galaxy Blvd. | Toronto, ON | M9W 4Y8 | Canada > > > > > > > _______________________________________________ > OAuth mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto: > [email protected]> > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 18033 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of OAuth Digest, Vol 215, Issue 81 > ************************************** > -- Chris Keogh
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
