I just wanted to address one specific item here: > precomputation attack discussed section 11.2 of RFC 9449
A large reason that pre computation is so easy in DPoP is because that was an intentional feature of DPoP, with the idea being that SPAs (the DPoP target client type) would want to be able to precompute requests and apply them to many messages. This is part of why `htu` strips parts of the target URL and headers aren’t included. With HTTPSig, the signing mechanics deliberately allow you to require more of the target message, and there are some well established patterns for doing so — the precomputing problem is much smaller and more dependent on the API being targeted as well as the chosen coverage of the message. — Justin On Sep 23, 2026, at 8:53 AM, Neil Madden <[email protected]> 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] _______________________________________________ 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]
