Assumptions:

1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources.
2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered.

Sets of scopes as identified in the meeting notes from 2016-06-02 [1]
  1. The universe of scopes the RS has registered for the resource set
  2. The scopes the client has registered for at the AS (if it has done this at all)
    1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request
  3. What the RO has attached to the policy for the resource set
  4. What the RS requests for at the permission endpoint (in order to get a ticket)
  5. The scopes the client requests at the token endpoint
Possible algorithm for determining the set of scopes to be issued with a permissions ticket.

Mapping this to pseudo-code:

Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes

Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes

Set RequestedScopes = ClientScopes UNION PermissionTicketScopes

Set AllowedScopes = PossibleScopes UNION RequestedScopes

Thanks,
George

[1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02