Does DPoP exist because access tokens can be stolen, TLS breaking isn't the real issue, at least for me.
I agree that HSM support is necessary, but if the claim is that keys can't be loaded into memory, how is an HTTPSig going to get created? Isn't that even worse? DPoP binds in a way to hopefully allow some reuse, binding a signature to a payload requires a frequency that no hardware backed HSM can provide at scale. Regarding the last point, it sounds like multiple challenges to the nonce generation in DPoP should be reviewed and augmented to support easier to use strategies as alternatives. That sounds like a real motivator to have DPoP 2.0 On Wed, Sep 23, 2026 at 11:21 PM Paul Bastian <[email protected]> wrote: > 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]> > <[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] > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
