Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher <[e-mail]>]

I can see use cases where both approaches are useful. I was just 
pointing out that while the RS might not be told the context of the 
request from the client's perspective, the client still knows it's own 
context and can leverage that with UMA at the RS to reduce the need to 
request multiple tokens (which is the issue I understood Torsten to be 
making).

I would also say that in UMA there is some desire to reduce the work the 
RS has to do as well where in Torsten's use case, the RS may be managing 
all the responsibility (for good or ill:)

On 4/22/19 3:36 PM, Pedro Igor Silva wrote:
> I think this knowledge by clients of the ecosystem is something that a 
> transactional authorization could avoid. Both UMA and ACE have 
> solutions that make clients really dumb about what they need to send 
> to the AS in regards to scopes. IMO, the RS should have the 
> possibility to tell clients the scope they need, making a lot easier 
> to change RS's access constraints as well as pushing contextual 
> information that could eventually enrich the authorization process.
>
> On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Speaking just to the UMA side of things...
>
>     ...it's possible in UMA 2 for the client to request additional
>     scopes when interacting with the token endpoint specifically to
>     address cases where the client knows it's going to make the
>     following requests and wants to obtain a token with sufficient
>     privilege for those requests. This requires a fair amount of
>     knowledge by the client of the ecosystem but that is sometimes the
>     case and hence this capability exists :)
>
>     On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>>     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.
>