We can definitely start without that general purpose security mechanism being proven, by using other proven mechanisms to solve the same problem. There's no reason we need to depend on nor utilize HTTPSig for solving the problems hoped to be achieved with this draft. But we do need to stipulate concretely what should be solved by the draft and then we can discuss what's the right approach. If we are saying DPoP is the right approach to solve it, we have a draft already (we would need to discuss whether an alternative is the right approach or reusing that one/making adjustments). Perhaps DPoP isn't the right approach, and maybe it is, but we need to start at the beginning.
Right now it just seems we are haphazardly throwing out an implementation for a draft standard for the sake of implementing that standard. "There are people that want to use it" isn't productive, what is productive is describing the core problem that they are facing, the why, and attacking it problem-first, not solution-first. It also sounds like we want to justify that work with an authored RFC from the OAuth WG. Okay, we can push that work, but it needs to be focused on core problems and solutions revolving in the OAuth space, and not done in a way for the sole purpose of justifying the work another draft is setting up. I don't think any one is doubting the benefits that could be gained, but we should be doubting if this is the right way from an OAuth perspective and the direction we want to go. We should enumerate those, work on refining what is in scope and going from there. The problem with the current draft, is that it doesn't give us an adequate starting point, sure we can push everything to the WG to solve every open point, but I for one, would like to see at least a partial draft that attempts to outline the problem and include a solution which supports a majority of use cases, without being a very niche collaboration with the existing signature draft. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Fri, Oct 8, 2021 at 11:07 PM Dick Hardt <dick.ha...@gmail.com> wrote: > > inline > > On Fri, Oct 8, 2021 at 2:00 PM Richard Backman, Annabelle < > richa...@amazon.com> wrote: > >> IE, if the success of HTTP Signing is tied to the OAuth WG adopting the >> draft, then Mike's arguments about the WG already doing this work is valid. >> >> >> It's not the success of HTTP Message Signatures that concerns me here; >> that draft will reach RFC regardless of what the OAuth WG does. >> > > Maybe, maybe not. And then having adoption and proving that all the other > concerns raised on the list such as canonicalization challenges are moot. > > >> But I and others would like to use Message Signatures with OAuth 2.0, and >> would like to have some confidence that there will be a standard, >> interoperable way to do that. >> >> There are other, non-OAuth 2.0 use cases for HTTP Message Signatures. I >> don't see the rationale behind waiting for implementations for completely >> unrelated use cases, or by parties that aren't using OAuth 2.0 for >> authorization. How are they relevant? >> > > The proposal is to build upon a general purpose security mechanism. I > would like to see that general purpose security mechanism proven before > building upon it. > > /Dick > ᐧ > _______________________________________________ > 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
