All, Based on the feedback on this call for adoption request, it seems that this document does *not* have enough support to adopt it as a WG document at this stage.
Regards, Rifaat & Hannes On Thu, Oct 14, 2021 at 11:19 AM Warren Parad <wpa...@rhosys.ch> wrote: > 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
