Hi Mike, One of the major benefits of this proposed draft is that it does not try to solve the problem of HTTP message signing — which is a huge problem unto itself. When I wrote the original draft-ietf-oauth-signed-http-request, I wasn’t able to write it to depend on a general-purpose HTTP signing spec and so it had to invent a mechanism. OAuth 1 worked on signing just query parameters and lots of things in the front-channel, and so invented its own mechanism.
Now that the HTTP working group is well on the way to standardizing the HTTP Message Signatures draft as a general-purpose RFC, the OAuth working group doesn’t need to solve that problem anymore, and that’s a really, really good thing. We aren’t the right community to get that right, and the two previous failed attempts you point to prove that better than anything. That’s exactly why this draft is NOT going to do that, at all. HTTP Message Signing exists, people are implementing it and using it. It makes sense for the OAuth working group to define a way to use that work in an OAuth context. We are not and should not try again to define a way to sign HTTP messages. That said, we know that DPoP invents its own way to sign an HTTP message, in a limited fashion. It has clear limitations — it doesn’t sign query parameters (which are likely to be important to many API types), it doesn’t sign headers, it doesn’t sign the body, etc. Even with these limitations, DPoP is useful, and I still argue that instead of trying to extend DPoP with a bunch of other things, we should let it exist as the clean point solution that it is. This draft is actually significantly simpler than DPoP precisely because it is not defining an HTTP signing mechanism. — Justin > On Oct 8, 2021, at 2:24 PM, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > I do not support adoption of this draft. OAuth 1 failed because of the > complexity of HTTP Signing and the resulting difficulty of achieving interop. > draft-ietf-oauth-signed-http-request was abandoned by the working group > recognizing that it was resurrecting equivalent complexity to OAuth 1. The > proposed new draft is a third crack at the same thing that’s not sufficiently > differentiated from the previous failed efforts in my mind to warrant us > spending time on it. > > Also, note we do have draft-ietf-oauth-dpop, which solves the actual > proof-of-possession problem for OAuth in a narrowly targeted, focused manner. > That draft is active and in good shape. We don’t need a more general, more > complicated draft solving the same problem. > > -- Mike > > From: OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> On > Behalf Of Rifaat Shekh-Yusef > Sent: Wednesday, October 6, 2021 2:02 PM > To: oauth <oauth@ietf.org <mailto:oauth@ietf.org>> > Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with > HTTP Message Signature > > All, > > As a followup on the interim meeting today, this is a call for adoption for > the OAuth Proof of Possession Tokens with HTTP Message Signature draft as a > WG document: > https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ > <https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/> > > Please, provide your feedback on the mailing list by October 20th. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
