(Edited the subject line and broke up this thread into two for clarity...) I *think* this subject line captures at least many of the key elements of the interesting conundrum we face here, looking at the thread below. (And notice that it doesn't say that the claims are only about the RqP vs. the client, nor that the claims are provided "live" vs. represented by proxy in a PCT. Check me if I'm wrong about those details!) Justin notes that traditional OAuth implementations draw a hard line, seeming to interpret the "different" text of 6749 only in a "reduction" sense even if it could be interpreted in an "expansion" sense as well. Some strawman thinking-out-loud: What are the reasons that a client registers for scopes in the first place? If it's to express capabilities the client can handle, is it even meaningful for a client to be granted access to a scope it can't use? If the registration for scopes acts as a per-client mask, then it's a kind of least-privilege solution that makes sense in the context of every client the requesting party uses. If the client gains more capabilities and later registers for more scopes, and then attempts access using a new scope, perhaps a PCT that's in place will easily and silently grant that client the necessary access. If the requesting party is forced through an unpleasant interactive flow or something based on poor claims management or TTL strategies, that's an argument for a higher-quality authorization server, not a more permissive release of scopes. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer <jricher@mit.edu> wrote:

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