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 <jricher@mit.edu> 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 <eve@xmlgrrl.com> 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 - Sr. Product Manager

512.600.7764  |  ishank@unboundid.com