> > HTTP Message Signing exists, people are implementing it and using it.
Token Binding existed as well. HTTP Message Signing is not yet an RFC, and in my opinion it only makes sense for OAuth to build on top of it if it is successful with lots of interoperable deployments. ᐧ On Fri, Oct 8, 2021 at 12: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
