I oppose adoption because it isn't clear to me what problems DPoP has that we are trying to solve with the HTTPSig version.
And Neil, that article by Matthew Green is pure genius, thanks for sharing. On Tue, Sep 22, 2026 at 6:47 PM Neil Madden <[email protected]> wrote: > Presumably you refer to this talk? > https://talks.secworkshop.events/osw2026/talk/JUEELE/ > > Can you share slides for it? It would be helpful to understand why this is > needed and why the proposed shortcomings cannot be addressed by DPoP itself > (eg via an update) rather than an entirely different approach. > > At present I oppose adoption for several reasons: > > i. We already have DPoP (and mTLS), and this draft provides no rationale > itself as to why it is not sufficient. Adding yet another POP mechanism > will only harm interop. Any call for adoption is premature until the > rationale is clearly stated. > > ii. Signatures generally have numerous problems, including severe > unintended consequences. One of the drawbacks of DPoP you mention is that > it doesn't sign the message content, but for me this is a considerable > advantage. Signing users' messages without their explicit informed consent > is IMO actively harmful to the Internet ecosystem, as evidenced eg by this > article by Matthew Green on the harms of DKIM signatures: > https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ > . > I don't really see any reasonable way to mitigate this risk other than to > not include the message content in the signature, but this is apparently a > key motivating use-case. Therefore I cannot support the proposal. (I > provide more technical reasons against signatures as an authentication > mechanism in > https://neilmadden.blog/2024/09/18/digital-signatures-and-how-to-avoid-them/ > ). > > iii. HttpSig in particular brings in a whole load of new machinery that > OAuth implementations will have to know about, including more IANA > registries, and another new ad-hoc public key representation format. It > repeats security mistakes of the past, such as canonicalisation and > allowing (if not mandating) an attacker-asserted "alg" parameter. The bar > should be very high for introducing a new PoP mechanism, especially one of > this complexity. I don't think this draft meets that bar. > > Neil > > On 22 Sep 2026, at 15:38, Paul Bastian <[email protected]> wrote: > > I support the adoption. > > We have a stable HTTP message signature specification now and people > deploying DPoP have realized a number of shortcomings that Christian and I > presented about at the OAuth Security workshop last time. > > 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]
