Re: [OAUTH-WG] Dynamic Scopes

[Jacob Ideskog <[e-mail]>]

This borderlines another problem we've been adressing which is when a
client needs to pass on the request to an asyncronous queue. In that case
the client can request the AS to "downscope" it's token, and include a
signature of the request in the token. (simplified).

The dynamic scope approach would help in this case also, i.e. have a
dynamic scope "sign:" which lets the client downscope it by adding the
actual signature/hash of the request to the token endpoint in a refresh
(sign:<hash>). Since we then consider sign:<hash> to be the downscoped
version of sign:, thus allowing the AS to issue this AT.

Also, one-off scopes are useful in services like pay per view etc, where
you can purchase say a single movie, game etc. Then the dynamic scope can
be decided to be issued by the AS rathern than specifically asked for by
the client. Example client asks for games: and gets
games:world-cup-2018-06-15 etc.

So, the scope approach seems like a more general approach for both the
authorize endpoint as well as the token endpoint. With that said, it will
probably make it hard to narrow down dynamic scopes to single particular
usecase. It would mean that

1. If a dynamic scope is requested on  the Authorize endpoint it's a
consentable request that the user needs to sign
2. If a dynamic scope is requested on the Token endpoint, the AS determines
what the end result might be. Seems a bit vague perhaps.

For OpenID I still think the signed claims parameters make a more flexible
approach, but OpenID isn't always in play.

Just my 5-cents

/Jacob Ideskog
Curity


mån 18 juni 2018 kl 21:00 skrev David Waite <[e-mail]>:

> One of the reasons I hear for people wanting parameterized scopes is to
> deal with transactions. I’d love to hear thoughts from the group on if/how
> OAuth should be used to authorize a transaction, vs authorize access to
> information/actions for a period of time. This approach for instance sounds
> like it is trying to scope down access to a single resource representing a
> transaction to be performed?
>
> I also hear people wanting dynamic scopes to support a finer-grained
> access control, for instance not ‘allow moderation of chat rooms’ but
> rather the list of *specific* rooms. There is sometimes a case to be made
> that this would be better served as local state in the resource, or as the
> result of an API call, but there is value in some use cases to represent
> this as a finer-grained consent to the user.
>
> I’ve seen parameterized scopes take the form of colon-deliminated
> name:param, as a function name(param), or as a URL
> https://nameurl?param=value.  The latter is recommended sometimes in
> specs like opened connect as a way to prevent conflicting vendor extensions.
>
> In terms of requesting a parameterized scope - I prefer overloading scope
> (or perhaps claims when using connect) vs adding a new authorization
> request parameter - for one, use of authorization request parameters limits
> your grant type options unless you also define them as token request
> parameters for the other types. Second, the consent/business logic for
> determining which scopes a client get should already be a customization
> point for a reusable AS.
>
> -DW
>
> > On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt <
> [e-mail]> wrote:
> >
> > Hi all,
> >
> > I have been working lately on use cases where OAuth is used to authorize
> transactions in the financial sector and electronic signing. What I learned
> is there is always the need to pass resource ids (e.g. account numbers) or
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
> authorization process to further qualify the scope of the requested access
> token.
> >
> > It is obvious a static scope value, such as „payment“or „sign“, won’t do
> the job. For example in case of electronic signing, one must bind the
> authorization/access token to a particular document, typically represented
> by its hash.
> >
> > I would like to get your feedback on what you consider a good practice
> to cope with that challenge. As a starting point for a discussion, I have
> assembled a list of patterns I have seen in the wild (feel free to extend).
> >
> > (1) Parameter is part of the scope value, e.g.
> „sign:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - I think
> this is an obvious way to represent such parameters in OAuth, as it extends
> the scope parameter, which is intended to represent the requested scope of
> an access token. I used this pattern in the OAuth SCA mode in Berlin
> Group's PSD API.
> >
> > (2) One could also use additional query parameter to add further details
> re the requested authorization, e.g.
> >
> > GET /authorize?
> > ....
> > &scope=sign
> > ....
> > &hash_to_be_signed=<hash_to_be_signed>
> >
> > It seems to be robust (easier to implement?) but means the scope only
> represents the static part of the action. The AS needs to look into a
> further parameter to fully understand the requested authorization.
> >
> > (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to
> carry additional data.
> >
> > Example:
> >
> > "claims": {
> >    "id_token": {
> >        "acr": {
> >            "essential": true,
> >            "value": "..."
> >          },
> >        "hash_to_be_signed": {
> >            "essential": true,
> >            "value": "<hash_to_be_signed>"
> >        }
> >    },
> >    "userinfo": {
> >        "hash_to_be_signed": {
> >            "essential": true,
> >            "value": "<hash_to_be_signed>"
> >        }
> >    }
> >  }
> >
> > I‘m looking forward for your feedback. Please also indicated whether you
> think we should flush out a BCP on that topic.
> >
> > kind regards,
> > Torsten._______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Jacob Ideskog
Curity AB

M: [phone]
E: [e-mail] <[e-mail]>
W: curity.io

*Curity AB is the leading supplier of API-driven identity
management, providing unified security for digital services. Curity
Identity Server is the world’s most powerful OAuth and OpenID Connect
Server; it is used for logging in and securing millions of users’ access to
web and mobile apps over APIs and microservices. We enjoy the trust of
large organizations in financial services, telecom, retail, energy and
government services with operations across many countries which have chosen
Curity for their enterprise-grade API security needs. *

*More information about us can be found at: https://curity.io
<https://curity.io/> *