Re: [OAUTH-WG] Transaction Authorization with OAuth

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. 

> 
> 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 <torsten@lodderstedt.net> 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
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 