Yes, from 3.3.1 of the UMA OAuth2 grant...
scope
OPTIONAL. A string of space-separated values representing requested
scopes. For the authorization server to consider any requested scope
in its assessment, the client MUST have pre-registered the same
scope with the authorization server. The client should consult the
resource server's API documentation for details about which scopes
it can expect the resource server's initial returned permission
ticket to represent as part of the authorization assessment (see
Section 3.3.4
<https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#authorization-assessment>).
https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization
On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:
Does UMA use the standard scope parameter?
Am 22.04.2019 um 21:03 schrieb George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>>:
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
