Comments inline...

On 6/17/16 12:25 PM, Ishan Kumar wrote:
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?
I was thinking about this from an OAuth2 perspective. When a client registered for a client_id / client_secret it often specifies which scopes it wants to request. The AS will then allow/disallow some of those scopes based on the client and trust of the developer. So in this particular case, if a client knows it wants to request certain scopes associated with an RS, it could specify that when it requests a client_id / client_secret with the AS.

I do agree that in the pure UMA case, it may be difficult for the UMA AS to specify whether a requested scope is valid or not at client registration time. We should discuss this on a call.

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.
Yes, you are correct. I had it correct in the text but not the psuedo-code:)
 

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.
I do agree that we need to dig into this deeper as in a pure UMA sense, the AS may not be able to predetermine the set of scopes a client is allowed to request. In the prior notes this catecory (item 2) it was listed as "if at all".

If we consider this set to not be relevant, then ClientScopes just becomes ClientRequestedScopes.

Thanks,
George

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 - Sr. Product Manager

512.600.7764  |  ishank@unboundid.com



_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma