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 
 
From: <wg-uma-bounces@kantarainitiative.org> on behalf of Eve Maler <eve@xmlgrrl.com>
Date: Thursday, 1 December 2016 at 18:23
To: "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org>
Subject: [WG-UMA] Draft minutes of UMA telecon 2016-12-01
 

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2016-11-10: Moved by Andi, seconded by John: APPROVED by unanimous consent.

Logistics

No meetings next week at all (no Dec 8 or Dec 9 meeting).

Dec 15 and Dec 16: regular meetings.

Dec 22: WG meeting. Dec 23: no Legal meeting.

Eve reviewed the "spec end game" timeline as shown above.

Work on UMA.next issues

UMA's essential characterization: Previously we called it a profile. Now it's called a framework, including mention of its extension grant. What's the right characterization? Though UMA has fewer MAYs and SHOULDs than OAuth, it's still general. Framework, application, extension, profile... Only profile is outright inaccurate if it's the only word used. John W suggests "make use of" instead of "leveraging".

AI: Justin: Please look at the new Note wording in Core 09 Sec 1.4 to see if a) it's okay and b) this wording could replace some instances of the wording that now appears in multiple places in the spec.

Set math: Eve left out a relevant step in her set math email; the set of scopes that the RS registered at the AS could have a bearing on later steps. If the client only ever registered for n scopes out of m possible ones, then even if it later asks for more, the n scopes are a hard mask/limiting factor. Registering for scopes is simply a part of client registration, so we don't have to talk about the mechanism at all, just the effects of it.

Today, clients register for scopes, and the scopes map in some relationship to resources (API calls/endpoints) determined by the API publisher (or the open API that the publisher adheres to). The same is true of UMA, except that the relationship is reified in the RReg interface by virtue of the resource description document that is registered from RS to AS, through a resource ID. (Note that there is an I-D floated in the OAuth WG that has a similar kind of resource ID...) What's weird is registering for scopes – which describe a strange universe of resources – vs specific resources or resource types or suchlike. Apparently the OAuth WG is discussing the latter as client registration upgrades.

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.

Maybe we can "future-proof" against client registration getting smarter and allowing registration for resources or resource types or something.

AI: All: Please review and respond to the "Set math discussion setup" email so we can decide key set math questions as expeditiously and thoroughly as possible.

Instructions:

·         Revise abstract and intro to account for characterization discussion.
·         Define "resource" as separate from "protected resource". Put an xref to the Sec 1.4.3 explanation about how an RS MAY manage complex resources.

Attendees

As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)

1.    Domenico
2.    Sal
3.    Nagesh
4.    Andi
5.    Eve
6.    Mike
7.    Cigdem
8.    Sarah

Non-voting participants:

·         François
·         Justin
·         John W
·         George
·         Ariel – responsible for IAM and data protection at TIAA
·         Kathleen
·         Ishan
·         Scott S

Regrets:

·         Maciej
·         James
 
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