Hi George, Thank you for putting this together. This was very helpful to walk through. Here are my thoughts/questions.... Are the AS allowed scopes in reference to all possible RSR scopes? Or can the AS scopes be independent of what scopes an RS actually registers? I ask because if we are only considering the UMA flow...What specifically governs an AS issuing an AS scope? On the last pseudo code statement...should that not be an intersection? An AS scope could overlap with a RSR scope that was disallowed by RO policy but inadvertently allowed because the union could introduce the Allowed AS scopes requested by the client. I think if we allow AS allowed scopes to be evaluate for an UMA flow, there could be unforeseen consequences in determine what scopes are issued. On Thu, Jun 16, 2016 at 12:43 PM George Fletcher < george.fletcher@teamaol.com> wrote:
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.
- The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket - The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} - The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} - The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. - The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8].
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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Take care, Ishan Ishan Kumar | UnboundID https://www.unboundid.com/ - Sr. Product Manager 512.600.7764 | ishank@unboundid.com