"This draft is actually significantly simpler than DPoP precisely because it is not defining an HTTP signing mechanism. " that is my understanding as well, but I was afraid to start a flame war :D
On Fri, Oct 8, 2021 at 4:23 PM Justin Richer <jric...@mit.edu> wrote: > 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> *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Wednesday, October 6, 2021 2:02 PM > *To:* oauth <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/ > > Please, provide your feedback on the mailing list by* October 20th*. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
