I'm glad you brought this up, since Signatures can already be used with OAuth, the question is exactly that. What are the ways using these together without an explicit RFC would cause a problem? I'm not totally sure that makes sense, so let me give an example. If the draft says "we need to exchange keys, but it isn't part of the draft" and we have that for every section, what's the benefit of the RFC in the first place. Sure PoP needs a solution, is it solved without an RFC for anyone using OAuth and the Signature draft as is, or is there something meaningful that needs to be documented?
Without providing author recommendations in the form of filling in at least part of the draft, instead of the question being *is this the right way to solve this part of the problem* it becomes *should we even have a draft.* The one part of the draft that does exist is "Introduction of a new token type", which if we say: > The RS can get that through introspection, through something in the token > itself (like the JWT “cnf” claim) Then the obvious conclusion should be: we don't need a new token type. So if we remove that from that draft, it brings me back to the original point, what problem does this particular draft solve as part of PoP, other than saying we should have PoP via message signatures because message signatures can provide PoP. We could say things like "Key exchange needs to be defined so that..." or "a new claim needs to be added so that...", but I fear we haven't done that with the draft so far. Obviously this is only my perspective, which isn't saying let's not do this, it is "sure let's do this as long as we can answer these questions". Right now I'm not convinced of this actually solving the PoP situation for me, while it is a valid argument, it isn't a sound one, due to its implementation relying on Signatures and how Signatures is constructed at this moment. So rather than "this is PoP", let's focus on the problems needed to solve for PoP Signatures to work. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Thu, Oct 14, 2021 at 4:51 PM Justin Richer <jric...@mit.edu> wrote: > I wanted to jump back to the top of the thread to point out something that > seems to be getting missed: > > > This is not a call for adoption of HTTP Message Signatures. That document > already exists in the HTTP WG and will be published as an RFC from that > group. If you want to have discussions about how the HTTP Message > Signatures specification works, come to the HTTP working group for those > discussions. > > This is a call for adoption of an OAuth application of the HTTP Message > Signatures spec. Signatures will exist with or without the OAuth WG’s use > of it, and I would argue that people are going to attach OAuth access > tokens to requests using HTTP Message Signatures whether or not the > OAuth WG picks up the work. The question is whether those applications are > going to be isolated profiles and silos, like they are today, or whether > there can be one way to use them together across different systems. > > My recommendation is that the OAuth WG define how exactly HTTP Message > Signatures should be used with OAuth, which is what this proposal is > for. > > — Justin > > > On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > wrote: > > 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
