Here's perhaps another way to come at the topic (which we touched on in our brief hallway convo). The OAuth group, in designing its scope capability, struggled with how much formality to give to that capability. Ultimately, the group kept it extremely informal, so that there are no semantics at the spec level. We in the UMA group have given some formality to scopes so far: They can optionally have description documents (or they can be just strings), and they must be attached to specific resource sets. I listed three options below in the thread. What Justin has done in his implementation, as I understand it, is to leave the "class-to-instance" mapping *implicit* at the spec level -- effectively leaving it up to API documentation, exactly the way scope and protected-resource semantics are left to API documentation in OAuth now. So he's exercising "option #3", that is, doing nothing in the spec, while letting the set math flow unimpeded. (Even if we choose to use this option, I still wonder if some nonnormative explanatory language would be valuable to explain the class-to-instance connection, particularly since UMA has a different approach to protected resources -- that is, they're named and RO-specific compared to OAuth.) (Another thought: Would it be friendlier if we were to use the name "protected resource" vs. "resource set"? I trip up on "resource set" all the time.) Though Justin indicated he may not be awake at the appointed BOF hour (I admit I will struggle with it myself!), it feels like this thread is on its way to giving us a better and better basis for discussion and decision-making, tomorrow and in subsequent WG calls. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Jun 8, 2016 at 2:36 PM, Justin Richer wrote:

From a hallway conversation with Eve just now:

I believe that the resource set is subordinate to the API that defines the resources, and that the scopes are subordinate to the API. I think it’s a transient property that scopes are defined with the resource set in UMA, since a resource set is really an instantiation of an API.

UMA doesn’t have a formal class/instance model to reflect this, and I would argue that it doesn’t need one in order to function. Eve (I believe) thinks there could be value in defining that.

Fundamentally, this is why I believe the RS should be allowed to register scopes with the resource set, the RS should be allowed to associate scopes with the ticket, and the client should be allowed to request scopes with the token request. Ergo, we need a way to combine all of these deterministically for a secure, interoperable, and importantly predictable protocol.

— Justin

On Jun 8, 2016, at 1:00 PM, Eve Maler wrote:

Still no WG call tomorrow, but it's been suggested to have a BOF -- so for those of us here at CIS, let's plan to meet at 7:30am over breakfast.

We could take the opportunity to discuss an item that's coming up in a few conversations: While scopes in OAuth are universal to their protected resources, scopes in UMA are bound to a particular RO context.

Thus, in the flow being proposed where clients make scope requests by clients, are the clients:

- Making a simplifying assumption about scopes being attached to generic "protected resource classes" (?) of some kind, where specific ROs are bound to instances of these classes later to get RSIDs? - Aware of RSIDs somehow in order to ask for scopes? - Doing something else entirely?

The way APIs are generally designed, the first option seems the most likely/reasonable/privacy-protecting. If that's the case, what other design considerations would there (have to) be for scope sets? E.g., our notes from last week had this list in it:

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) 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

There would need to be some insertions and questions answered for at least #1, #2, and #5.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

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

An excellent list of challenges to think about. Another business-y challenge, from the UMA MasterClass today: Mike S. mentioned the benefits of UMA's client-unawareness-of-scopes for his API security use case. UMA's approach in this light a beneficial paradigm shift, all part of getting entitlements handling out of code and into the hands of business owners. (Mike, do I understand your point correctly?) If we manage to figure out how to make client-awareness-of-scopes fully viable (right now I'm assuming that it isn't), does this halt or reverse the paradigm shift, undoing the benefit? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Jun 8, 2016 at 6:03 PM, Ishan Kumar wrote:

I agree that we should move to a more deterministic protocol for clients.

However, even if the scopes are documented and publicly available or applicable to all instances, it is still unknown to the client which AS the RO has used to protect their resource.

And in the case the client some how knows the particular AS the RO used and the client request scopes from the token endpoint, the AS would still need to know which RO policies to apply for the resource set/protected resource. Not to mention, the RO may not have allowed for all available scopes to be made available in the RSR flow.

In the current API definitions and flows, I do not see how the client can go directly to the AS and be authorized for tokens. Am I missing an alternative proposal?

I am available to meet at 7:30a, although I may need a bloody mary to get me through our meeting after tonight.

On Wed, Jun 8, 2016 at 2:36 PM Justin Richer wrote:

...

From a hallway conversation with Eve just now:

I believe that the resource set is subordinate to the API that defines the resources, and that the scopes are subordinate to the API. I think it’s a transient property that scopes are defined with the resource set in UMA, since a resource set is really an instantiation of an API.

UMA doesn’t have a formal class/instance model to reflect this, and I would argue that it doesn’t need one in order to function. Eve (I believe) thinks there could be value in defining that.

Fundamentally, this is why I believe the RS should be allowed to register scopes with the resource set, the RS should be allowed to associate scopes with the ticket, and the client should be allowed to request scopes with the token request. Ergo, we need a way to combine all of these deterministically for a secure, interoperable, and importantly predictable protocol.

— Justin

On Jun 8, 2016, at 1:00 PM, Eve Maler wrote:

Still no WG call tomorrow, but it's been suggested to have a BOF -- so for those of us here at CIS, let's plan to meet at 7:30am over breakfast.

We could take the opportunity to discuss an item that's coming up in a few conversations: While scopes in OAuth are universal to their protected resources, scopes in UMA are bound to a particular RO context.

Thus, in the flow being proposed where clients make scope requests by clients, are the clients:

- Making a simplifying assumption about scopes being attached to generic "protected resource classes" (?) of some kind, where specific ROs are bound to instances of these classes later to get RSIDs? - Aware of RSIDs somehow in order to ask for scopes? - Doing something else entirely?

The way APIs are generally designed, the first option seems the most likely/reasonable/privacy-protecting. If that's the case, what other design considerations would there (have to) be for scope sets? E.g., our notes from last week had this list in it:

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) 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

There would need to be some insertions and questions answered for at least #1, #2, and #5.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ 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

-- Take care,

Ishan

Ishan Kumar | UnboundID https://www.unboundid.com/ - Sr. Product Manager

512.600.7764 | ishank@unboundid.com

If we agree that the client can ask for more scopes then what the RS may deem necessary to perform the requested operation, then the clarification that Justin is asking for is how to guide an AS implementer to reconcile the scopes that comes from the permission ticket, requested by the client, and the approved scopes based on RO/RSR policies. I would say at a minimum the AS is obligated to evaluate the scopes tied with the permission ticket. The AS then has to check to see if the additional scopes provided by the client are registered to that RSR, and then determine if a policy is assigned for that scope. And if so, evaluate the policy and/or claims requirements. If it does not find a policy on a particular scope, then it should not grant access to that scope as it has not been determined by the RO under which conditions should that scope be granted. This would be inline with the default-deny authorization assessment model. On Tue, Jun 14, 2016 at 10:31 PM Eve Maler wrote:

So we did manage to hold a breakfast BOF at CIS on the Thursday morning last week where we discussed this, and I've put it on the agenda for this Thursday's telecon.

We discussed how, even if the client doesn't know the exact AS protecting the resource in question, the RS is still the entity that's authoritative for how to break up resource set boundaries and for the universe of scopes that are applicable to them, and unless there's some kind of very dynamic scope paradigm going on, which is *highly* unusual, scopes are a static and predictable feature of an API, which the RS can be expected to advertise and document, and which (as in plain OAuth now) the client can be expected to "code to" as part of the ordinary API contract.

My memory is dimming on this point now, but I remember that we talked about how the RS could register a permission simply for the scope(s) that cover exactly what the client attempted to do and nothing more, which would make the RS's action purely deterministic vs. reflecting a judgment call. This wouldn't necessarily be a single scope; look at the example of OpenID Connect, wherein there are multiple scopes that could potentially match a single API call. But nonetheless, we could mandate, if we choose, that the RS no longer needs to apply discretion.

Instead, the client could make a judgment call itself (if it wants to ???) at the point of asking for the token at the AS, by asking for more scopes than would have originally applied according to its original action.

Can others supply more detail that they remember? Any pros and cons to add? It felt like we were on the verge of practically having spec text! But we were eating, and not taking notes. :-)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Jun 8, 2016 at 8:33 PM, Eve Maler wrote:

...

An excellent list of challenges to think about.

Another business-y challenge, from the UMA MasterClass today: Mike S. mentioned the benefits of UMA's client-unawareness-of-scopes for his API security use case. UMA's approach in this light a beneficial paradigm shift, all part of getting entitlements handling out of code and into the hands of business owners. (Mike, do I understand your point correctly?)

If we manage to figure out how to make client-awareness-of-scopes fully viable (right now I'm assuming that it isn't), does this halt or reverse the paradigm shift, undoing the benefit?

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Jun 8, 2016 at 6:03 PM, Ishan Kumar wrote:

...

I agree that we should move to a more deterministic protocol for clients.

However, even if the scopes are documented and publicly available or applicable to all instances, it is still unknown to the client which AS the RO has used to protect their resource.

And in the case the client some how knows the particular AS the RO used and the client request scopes from the token endpoint, the AS would still need to know which RO policies to apply for the resource set/protected resource. Not to mention, the RO may not have allowed for all available scopes to be made available in the RSR flow.

In the current API definitions and flows, I do not see how the client can go directly to the AS and be authorized for tokens. Am I missing an alternative proposal?

I am available to meet at 7:30a, although I may need a bloody mary to get me through our meeting after tonight.

On Wed, Jun 8, 2016 at 2:36 PM Justin Richer wrote:

...

From a hallway conversation with Eve just now:

I believe that the resource set is subordinate to the API that defines the resources, and that the scopes are subordinate to the API. I think it’s a transient property that scopes are defined with the resource set in UMA, since a resource set is really an instantiation of an API.

UMA doesn’t have a formal class/instance model to reflect this, and I would argue that it doesn’t need one in order to function. Eve (I believe) thinks there could be value in defining that.

Fundamentally, this is why I believe the RS should be allowed to register scopes with the resource set, the RS should be allowed to associate scopes with the ticket, and the client should be allowed to request scopes with the token request. Ergo, we need a way to combine all of these deterministically for a secure, interoperable, and importantly predictable protocol.

— Justin

On Jun 8, 2016, at 1:00 PM, Eve Maler wrote:

Still no WG call tomorrow, but it's been suggested to have a BOF -- so for those of us here at CIS, let's plan to meet at 7:30am over breakfast.

We could take the opportunity to discuss an item that's coming up in a few conversations: While scopes in OAuth are universal to their protected resources, scopes in UMA are bound to a particular RO context.

Thus, in the flow being proposed where clients make scope requests by clients, are the clients:

- Making a simplifying assumption about scopes being attached to generic "protected resource classes" (?) of some kind, where specific ROs are bound to instances of these classes later to get RSIDs? - Aware of RSIDs somehow in order to ask for scopes? - Doing something else entirely?

The way APIs are generally designed, the first option seems the most likely/reasonable/privacy-protecting. If that's the case, what other design considerations would there (have to) be for scope sets? E.g., our notes from last week had this list in it:

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) 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

There would need to be some insertions and questions answered for at least #1, #2, and #5.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ 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

-- Take care,

Ishan

Ishan Kumar | UnboundID https://www.unboundid.com/ - Sr. Product Manager

512.600.7764 | ishank@unboundid.com

-- Take care,

Ishan Ishan Kumar | UnboundID https://www.unboundid.com/ - Sr. Product Manager 512.600.7764 | ishank@unboundid.com