Sorry. I mean, UMA provides much more than this 1st party authorization flow I'm talking about ....
On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva <[email protected]> wrote: > > > On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt < > [email protected]> wrote: > >> Hi Pedro, >> >> > >> > > The general idea is to empower RSs so that they can communicate to >> the AS how access to their resources should be granted as well as >> decoupling clients and RSs so that clients don't need to know the >> constraints imposed by the RS to their protected resources (e.g. scopes).. >> > >> > Sounds very much like UMA2. The difference I see is the RS needs to be >> heavily involved in the authorization process (whereas the approaches I >> discussed leave it passive). How would you handle the use cases I >> described? So for example, how would you construct the JWT for the >> signature use case? I’m asking because the signing case uses more data in >> the authorization process and might bundle the request to sign multiple >> documents, even if the first signing request would only need the hashes or >> even just a single hash of a document. >> > >> > Yes, it does. Like I mentioned, the model is based on UMA (Permission >> Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had >> talked with UMA WG in the past about this solution and how we extended the >> specs to solve this type of problem. >> > >> > By being active during the authorization process the RS is in control >> over additional claims that should be considered by the policies when >> making decisions about the resources/scopes a client/user can access. Where >> the information could be obtained from different sources such as the >> current HTTP request or internally/externally to the RS. >> >> The problem from my perspective (and my understanding of UMA) is the RS >> does not have any information about the context of the request. For >> example, the client might be calling a certain resource (list of accounts) >> and immediately afterwards wants to obtain the balances and initiate a >> payment. I think the UMA case the RS either predicts this based on policy >> or past behaviour of the client OR the client will need to issue several >> token requests. That might not be a problem in 1st party scenarios but it >> is in 3rd party scenarios if the AS gathers consent. >> > > Yeah, we are talking about different use cases. But they are still quite > related in regards to enriching authorization decisions. it would be nice > to have something in OAuth that could address both 1st and 3rd party use > cases. As I said before, the model I'm talking about is kind of a 1st party > Lodging_Intent. > > Just to clarify, UMA does not cover the scenario I'm talking about > although it provides a very good ground for extensions like this. It is not > part of UMA scope. It provides much more than that too ... > > >> >> > >> > We did not have much demand for addressing the signature use case, but >> use cases similar to the "payment" use case. As I mentioned, the model I'm >> talking about is not based on user consent. >> >> Right, you mentioned it is intended to be used for 1st parties only. >> >> > But considering that you can also pass any information to the AS, you >> should be able to let users to authorize the creation of signatures for one >> or more documents. >> >> I think the client needs to pass this information, which brings us back >> to the original question of my article. >> >> best regards. >> Torsten. >> >> > >> > >> > > >> > > I've started to write a document with this idea in mind and I'm happy >> to share it with you and see what you think. >> > > >> > >> > Look forward to reading your article. >> > >> > best regards, >> > Torsten. >> > >> > > Best regards. >> > > Pedro Igor >> > > >> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt < >> [email protected]> wrote: >> > > Hi all, >> > > >> > > I just published an article about the subject at: >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948 >> >> > > >> > > I look forward to getting your feedback. >> > > >> > > kind regards, >> > > Torsten. >> > > _______________________________________________ >> > > OAuth mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> >>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
