For my action item from Eve’s post, I would suggest this wording:

Note: In step 3, the client attempts access to a protected resource with no token, and in step 4, the resource server requests permissions on behalf of that client at the authorization server. In order for the resource server to know which authorization server to approach and which PAT (representing a resource owner) and resource identifier to supply in that request, the API being accessed by the client needs be structured in such a way that the resource server can derive this information from the client's token-free access attempt. Commonly, this information can be passed through the URI, headers, or body of the client's request. Alternatively, the entire interface could be dedicated to the use of a single resource owner and protected by a single authorization server.

As for dynamic registration and the like: yes, the client could manage its own scopes using the registration and management protocol in RFCs 7591/7592. Managing the client’s set of registered scopes is by and large outside the UMA and OAuth protocols. However, the question George raised is more subtle than that. Namely, let’s say a client registers with scopes A, B, and C. Said client then tries to access an API with scope X. In a traditional OAuth implementation (including ours), the client wouldn’t be able to get a token scoped to X, because the client’s identity would limit it to only scopes A, B, and C. However, there’s more going on with UMA: the RqP’s claims come into play in the calculation. So let’s say that Alice sets up a policy that Bob can fulfill, and it grants scope X. 

The core “set math” question that I’m trying to raise about this is simple: what do we do now? Do we not issue a token with scope X because the client wasn’t registered for it? Do we issue a token with scope X because the RqP was able to do everything required by the policy? Or do we add scope X to the client’s available registration somehow, so the client now has A, B, C, and X that it can ask for in the future. If we do the latter, is “X” in the same class of scopes as A, B, and C, or is X now in its own bubble relegated to the context of the RqP’s claims?

This gets even more fun when considering the claims represented by the PCT, which effectively represent fulfillment of policies good for X on this resource.

 — Justin

On Dec 1, 2016, at 2:11 PM, Cigdem Sengul <Cigdem.Sengul@nominet.uk> wrote:

Just commenting on this part – I wanted to say during the call, but kept dropping J

 

“How can a client dynamically add a scope that they didn't register for in the beginning? Or delete? Well, shouldn't that be for the client registration protocol to figure out? But if the policy conditions have been satisfied, maybe the authorization assessment should still result in granting the permission with the scope requested.”

 

If dynamic client registration is used, a client can update and delete its configuration (which optionally includes a scope parameter).  

 

About the AS assessment – in OAuth2 (RFC 6749) it says:

“ The authorization server MAY fully or partially ignore the scope

   requested by the client, based on the authorization server policy or

   the resource owner's instructions.  If the issued access token scope

   is different from the one requested by the client, the authorization

   server MUST include the "scope" response parameter to inform the

   client of the actual scope granted.”

 

“Different” may be understood as only scope reduction, but can it be seen also as scope expansion (if the policy allows)?

Upon a request, then AS can return a token with a wider set of scopes – which may amortize the cost for the client in its further interactions with the RS (Then, should the RS stay as just “the messenger”?  It just registers the permission for what is requested and does not try to expand the scope of the request).

I will respond separately also to set math, and use case question, which would probably make my point more clear.

 

Thanks,

--Cigdem