Great writeup! I agree with all of this except the PS:

I don't see (and didn't intend) the ROPolicy to represent the single policy on the resource, as I believe there will be multiple policies that may apply. So ROPolicy is intended to represent "the scopes defined in the RO's policy where said policy has been fulfilled by the RqP" -- so it's really "scopes the RqP qualifies for based on RO's policy". In other words, it's post-calculation of the policy, not pre-calculation. Therefore treating it as a single set (not split into required/extra) is appropriate.

I think that the required/extra split is interesting, but only to the extent that the AS wants to differentiate to the RqP what they need to prove in order to move forward. That's an internal policy engine detail, and I honestly think that in the wild we're not going to see a ton of that. At the end of the day, the scopes are going to be approved or not, and therefore in the set or not.

 -- Justin


On 1/12/2017 8:24 AM, George Fletcher wrote:
So here is my attempt at a simple example:

Lets assume that Alice is using photos.example.com (RS) to manage her photos and copmonkey.example.com (UMA AS) to protect her photos. Bob wants to access Alice's landscape photo album (photos.example.com/photos/alice/landscape). Bob uses the myPhotos app (Client).

scopes registered by myPhotos at AS registration time
    ClientReg = (view, download, print)
    ClientRegisteredDefaults = (view)
    [Note, I don't believe the OAuth2 dynamic client registration allows for registering defaults, but I'm including it because it's part of this thread.]

scopes registered by photos.example.com for Alice's landscape photos resource set
    RSReg = (view, share, download, print)
    [resource set id = 1234]

Alice defines policy for the registered scopes for her landscape photos
    view = promise not to steal
    share = promise not to steal
    download = family members only
    print = NOT ALLOWED

    ROPolicy = (view, share, download)

Bob's myPhotos app attempts to access photos.example.com/photos/alice/landscape and receives back a permission ticket that identifies scopes (view, share). The app presents the permission ticket to the token endpoint along with scopes (print, resale).

    RSTicket = (view, share)
    ClientReq = (print, resale)

[I'm going to ignore the PrevRPT because I think is has some issues unless defined in a very particular way.]

So, now that all the sets are defined we can apply the set math:

    Requested = union(intersection(ClientReq,ClientReg), RSTicket, ClientRegisteredDefaults)
    Requested = union(intersection((print,resale),(view,download,print)),(view,share),(view))
    Requested = (view,share,print)

Evaluating the policy defined for the registered resource set id:1234, Alice and prohibited the use of the print scope. So the ROPolicy is limited to (view,share,download).

To determine which claims Bob must meet, we have to determine which scopes are in play for resource set id:1234

    Scopes = intersection(Requested, ROPolicy)
    Scopes = intersection((view,share,print),(view,share,download))
    Scopes = (view,share)

Bob meets the necessary claims for scopes (view,share) as defined by the Alice's policy for the 'view' and 'share' scopes on her landscape photos. Bob's myPhotos app is granted an RPT that allows for (view,share) for resource set id:1234

RPTResult = RSID_1234(view,share)

Please check the math! :)

To try an simplify the steps, for each /token call with uma grant
  1. Determine the set of requested scopes
    1. Requested = union( intersection(ClientReq,ClientReg), RSTicket, ClientRegisteredDefaults)
  2. Determine the set of scopes allowed by the Resource Owner
    1. Evaluate the policy for the identified resource set(s) and determine if any of the registered scopes are not allowed
    2. ROPolicy = list of scopes allowed by RO
  3. Determine the set of scopes for which RqP must meet claims in order to receive an RPT
    1. Scopes = intersection (Requested,ROPolicy)
  4. Determine the set of claims necessary for Scopes as they pertain to the specified resource set(s)
    1. Claims = union(resource_set_claims(rsid,scopes))
  5. Request RqP to meet Claims
  6. Assuming RqP meets Claims, issue RPT
Thanks,
George

P.S. Note that I think in step 3 we really want two sets of scopes. RequiredScopes and AdditionalScopes as it's possible for the RqP to meet the claims of the scopes in the RSTicket but not the possible additional scopes. This would look like...
     RequiredScopes = intersection(RSTicket,ROPolicy)
     AdditionalScopes = intersection(difference(Requested,RSTicket),ROPolicy)


On Wed, Jan 11, 2017 at 7:31 PM Eve Maler <eve@xmlgrrl.com> wrote:
I have to admit you guys have now gone beyond my ability to follow. :-) If someone could summarize in English pseudo-spec language, and a simple example, I would be very very grateful. I would like any discussion of this tomorrow to to be efficient, because there's lots of other stuff to discuss too.


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


On Tue, Jan 10, 2017 at 2:02 PM, James Phillpotts <james.phillpotts@forgerock.com> wrote:
Well, in fact I was suggesting:

Requested = union(intersection(ClientReg, ClientReq), RSTicket, ClientRegisteredDefaults)

But I can live with ClientRegisteredDefaults being an off-spec AS extension, so yes :)

Cheers
James

On 10 January 2017 at 19:16, George Fletcher <george.fletcher@teamaol.com> wrote:
Yes, though I'd feel better with James weighing in to make sure I understood his idea correctly:)

On Tue, Jan 10, 2017 at 2:08 PM Justin Richer <jricher@mit.edu> wrote:
Interesting thought — so are you suggesting that:

Requested = union(intersection(ClientReg, ClientReq), RSTicket)

That would let ClientReg be a limiting set but wouldn’t leave out the RS requesting more scopes (or policies granting more scopes) than the client itself asked for.

I could live with that interpretation.

 — Justin

On Jan 10, 2017, at 12:01 PM, George Fletcher <george.fletcher@teamaol.com> wrote:

I personally don't have any issues making the client be explicit about it's requests, so I'd prefer to not have a default option at all and just have the client request what it wants at each RPT/Token request. This would then cause the ClientReg set to just be a limiting set on what the client can request at run time. 

Note that the AS is free to not allow all the scopes requested in the ClientReg set at registration time, in which case the limiting set gets smaller. If that happens, then the only way the client can get a particular scope needed to access a resource is if that scope is identified by the permission ticket.

On Tue, Jan 10, 2017 at 11:57 AM James Phillpotts <james.phillpotts@forgerock.com> wrote:
Yes, exactly. The RS's permission ticket-requested scope values are incontrovertible. The registered scopes should only apply to whatever the Client is trying to request on top of that.

So my proposal is that the scope value in the client registration should be a restriction for what it can request in that vein (as RFC 7591 specifies it). A separate field, default_scope, could be added for what might get added by default. So I guess I'm suggesting a sort of hybrid of Option 2 and Option 3 from the minutes from last week's meeting.

Cheers
James
On 10 January 2017 at 16:32, George Fletcher <george.fletcher@teamaol.com> wrote:
So how do you want to apply the "superset" thinking to the scopes requested by the client at registration time? Are you thinking that the client can only explicitly requests scopes that are within that set? even though the permission ticket my expand the set beyond that?

Thanks,
George


On Tue, Jan 10, 2017 at 11:23 AM James Phillpotts <james.phillpotts@forgerock.com> wrote:
Like I said, I'm talking about scope values requested by the client, not by the RS in the permission ticket.

J.
On 10 January 2017 at 16:21, George Fletcher <george.fletcher@teamaol.com> wrote:
Hi James,

I guess what I'm saying is that even if the client registers for scopes A, B, C, and F; that doesn't prohibit the client from in fact requesting for scope K (as identified by the RS as required for the requested resource) when requesting a new RPT.

So in that sense, the list of client registered scopes can not be considered the super set of all scopes the client can request (which is what I thought you were saying in your email; again I probably misunderstood your intent:)

Thanks,
George
On Tue, Jan 10, 2017 at 10:45 AM James Phillpotts <james.phillpotts@forgerock.com> wrote:
Hi George,

I'm not sure I understand you - we're talking here about scope values that the client knows about itself, registers for, and can be requested separately from those that are in the permission ticket. As such, a degree of static-ness can be assumed, in the same way as it is in vanilla OAuth.

Cheers
James
On 9 January 2017 at 22:51, George Fletcher <george.fletcher@teamaol.com> wrote:
Hi James,

I may have misunderstood, but I don't think with UMA there is anyway to say a client can only ask for scopes within this "set". (referencing your last paragraph).

Because of the dynamic nature of scopes and permissions tickets, a key capability of a client within UMA is the ability to get access to a resource that requires a scope the client has never even "seen" before. The key to be able to get authorized for this new scope is the ability to mean the ROPolicy for the requested resource. If the client/RqP can meet the required policy, then the RPT is granted the associated scope(s).

I can envision an AS defining a "black list" of scopes that a particular client could NEVER be authorized for, but this seems AS specific and out of scope for UMA.

Thanks,
George


On Mon, Jan 9, 2017 at 4:06 AM James Phillpotts <james.phillpotts@forgerock.com> wrote:
This seems well thought out, thanks Justin. I've got just one concern:

I'm uneasy about using the client registered scopes as 'default scopes' in the case of UMA, when RFC7591 states that registered scopes represent "scope values that the client can use when requesting access tokens" - as you stated in Thursday's call. I'm particularly concerned about how any of this plays out when the client is trying to be both a vanilla OAuth (or OpenID Connect) client as well as an UMA client. If the client registers for scopes "openid profile view edit", then they must explicitly request openid and profile scope values in the token request in order to get an access token that contains those scopes, but if they present a permission ticket as well, we're saying they view and edit will automatically get evaluated/added without the client knowing about it.

I would prefer that we submit an extra 'default_scope' attribute to the OAuth Dynamic Client Registration Metadata Registry (https://tools.ietf.org/html/rfc7591#section-4) to disambiguate from the existing 'scope' field. The client could then register with scope "openid profile edit" and default_scope of "view".

This also has an extra advantage of being able to use the registered scope field to block requests for scope values that have not been registered for the client - i.e. client registers for scope A, has a permission ticket for scope B, but requests scope C in the token request, which should then result in an 'invalid_scope' response.

Cheers
James
On 8 January 2017 at 21:05, Justin Richer <jricher@mit.edu> wrote:
--
Distinguished Engineer
Identity Services Engineering, AOL Inc.
Mobile:+1-703-462-3494  Office:+1-703-265-2544


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