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