> Am 22.04.2019 um 19:54 schrieb Pedro Igor Silva <[email protected]>: > > Sorry. I mean, UMA provides much more than this 1st party authorization flow > I'm talking about ....
got it ;-) > >> 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 >>> > >>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
