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

Comments inline... On 6/17/16 12:25 PM, Ishan Kumar wrote: 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 mailto: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 mailto: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 tel://15126007764 | ishank@unboundid.com mailto:ishank@unboundid.com

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

In our implementations we specific disallow default scopes and require clients to request the scopes they want. I want the developers to be explicitly asking for privileges. Our implementation aside, if you correct the error in the last line of my set math to... Set AllowedScopes = PossibleScopes INTERSECTION RequestedScopes then I think this will cover the scenario even if the client is provided some default scopes because the likelihood that those default scopes will overlap with the "PossibleScopes" is very small. If they do overlap, then it might be perfectly fine. Thanks, George On 6/17/16 9:33 PM, Justin Richer wrote:

In our MPD implementation, we ended up generally disregarding the client's scopes in the set math. The main reason for this actually has to do with defaulting:

We agreed on last week's call that we want to support the case where the client has no idea what the scopes on the API are, but the RS registers a reasonable set with the ticket to get things going -- basically the UMA 1.0 pattern. However, in our server, if a client doesn't ask for a specific set of scopes on registration, it gets assigned a default set. (Usually the OIDC set.) We ran into a case where a naive client registered no scopes but got defaulted some, and these happened to be unrelated to the set of scopes on the API. So we were at a bit of a loss what to do with this client's registered scopes in this case -- it obviously wasn't the intent of the client that it get those defaulted scopes, but this kind of defaulting behavior is not uncommon on OAuth systems.

So in our case we threw them out (like George's example in the text below), but like with the other sets I think we need to have explicit guidance as to what to do with them, if the server has this feature.

-- Justin

On 6/17/2016 2:29 PM, George Fletcher wrote:

...

Comments inline...

...

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

On 6/17/16 12:25 PM, Ishan Kumar wrote: 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 mailto: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 mailto: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 tel://15126007764 | ishank@unboundid.com mailto:ishank@unboundid.com

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

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

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

Waking up this thread yet again. There are two issues I'd like to resolve as we get closer to working our way through the spec(s). One is: What would spec text look like for the set language most recently proposed? I'm not finding it particularly easy to wend my way through the logic as currently stated. Could some "minimal examples" be provided, with scopes A/B/C/D in a context of resource sets 1/2, or something like that? That would be very helpful. The other is: We still need to add language about the qualitative aspects of what an RS, client, and AS need to do at each stage. What I've gleaned from our notes on past discussions is that: - A client should (SHOULD?) register the scopes it intends to use. - We haven't said anything yet about how asking for scopes against "multiple resource sets" should work. - A client should (SHOULD?) ask for as few scopes as it needs to do its job on the principle of least privilege, if it's going to ask for scopes at all. - Given our new thinking, an RS *perhaps* should (SHOULD?) register a requested permission on behalf of the client that represents an accurate picture of what access the client attempted. However, I'm not sure of this, and it doesn't admit the capability of the "multiple resource sets" capability, nor give advice on what to do there. What other qualitative aspects require us to comment? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Sep 20, 2016 at 8:38 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

Hi all,

I know Eve wants us to come back to this in the call soon, so I was going back over this thread.

So George is suggesting (I've changed ROAllowedScopes to PolicyAllowedScopes, as the RO may not necessarily be the author of the policy granting the scope):

AllowedScopes = RegisteredResourceSetScopes INTERSECTION PolicyAllowedScopes INTERSECTION ((ASAllowedClientScopes INTERSECTION ClientRequestedScopes) UNION PermissionTicketScopes)

This is only subtly different from what I had assumed, in the idea of ASAllowedClientScopes. Given that scopes for UMA are defined by the RS, it doesn't seem reasonable for the AS to get involved in what resource scopes the Client can request. So I wonder whether a formula should be:

AllowedScopes = (ASAllowedClientScopes UNION (RegisteredResourceSetScopes INTERSECTION PolicyAllowedScopes)) INTERSECTION (ClientRequestedScopes UNION PermissionTicketScopes)

If we then introduce the concept of default scopes that Justin raised, I'd say these are used if the client doesn't request any scopes itself (this is the same behaviour when defaulting the scopes at the AS in vanilla OAuth 2.0), irrespective of the values in the permission ticket. So, defining a new set:

ScopesForClient = ClientRequestScopes == EMPTY_SET ? ASDefaultClientScopes : ClientRequestScopes

AllowedScopes = (ASAllowedClientScopes UNION (RegisteredResourceSetScopes INTERSECTION PolicyAllowedScopes)) INTERSECTION (ScopesForClient UNION PermissionTicketScopes)

However, the policy engine and client configuration at the AS may deny scopes too, so including that we'd have:

PermittedScopes = ASAllowedClientScopes UNION ( RegisteredResourceSetScopes INTERSECTION PolicyAllowedScopes)

RequestedScopes = ScopesForClient UNION PermissionTicketScopes

DeniedScopes = PolicyDeniedScopes UNION ASDeniedClientScopes

AllowedScopes = (PermittedScopes INTERSECTION RequestedScopes) SET_MINUS DeniedScopes

In general, I'm assuming:

(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes

i.e. The Client may request, or have defaulted by the AS, scopes that are not provisioned by RS in the permission ticket.

Thoughts?

Cheers James

On 20 June 2016 at 16:05, George Fletcher wrote:

...

In our implementations we specific disallow default scopes and require clients to request the scopes they want. I want the developers to be explicitly asking for privileges.

Our implementation aside, if you correct the error in the last line of my set math to...

Set AllowedScopes = PossibleScopes INTERSECTION RequestedScopes

then I think this will cover the scenario even if the client is provided some default scopes because the likelihood that those default scopes will overlap with the "PossibleScopes" is very small. If they do overlap, then it might be perfectly fine.

Thanks, George

On 6/17/16 9:33 PM, Justin Richer wrote:

In our MPD implementation, we ended up generally disregarding the client's scopes in the set math. The main reason for this actually has to do with defaulting:

We agreed on last week's call that we want to support the case where the client has no idea what the scopes on the API are, but the RS registers a reasonable set with the ticket to get things going -- basically the UMA 1.0 pattern. However, in our server, if a client doesn't ask for a specific set of scopes on registration, it gets assigned a default set. (Usually the OIDC set.) We ran into a case where a naive client registered no scopes but got defaulted some, and these happened to be unrelated to the set of scopes on the API. So we were at a bit of a loss what to do with this client's registered scopes in this case -- it obviously wasn't the intent of the client that it get those defaulted scopes, but this kind of defaulting behavior is not uncommon on OAuth systems.

So in our case we threw them out (like George's example in the text below), but like with the other sets I think we need to have explicit guidance as to what to do with them, if the server has this feature.

-- Justin On 6/17/2016 2:29 PM, George Fletcher wrote:

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+tel econ+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

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma

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

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