Re: [WG-UMA] Set Math Discussion

I think you may still be thinking of this in a different part of the process than I am. For me, the whole set math discussion takes place *after* all the claims have been submitted, *after* the AS decides to make a token, *after* any redirects and ticket processing. This is answering the AS's question: "I've decided to make an RPT, what do I put into it?" So ROPolicy is the set of scopes defined in whichever policy of the RO on that resource has been fulfilled by the claims that the RqP/client have presented throughout the process up to this point. The RqP is not going to be presenting any more claims or meeting new scopes or anything anymore. All of that has been decided and is over at this point. So it's a limiting factor in the set math *because* you can't grant any new scopes that aren't approved by the RO's policies (and fulfilled by the RqP). The RqP and client already had their chance to request scopes (ClientReq) and provide claims, and this represents the *results* of that process. If they haven't presented the right claims to get a scope they wanted, then they don't get that scope. If there's not a policy that allows the scope they wanted in the first place, they don't get that scope because they can't provide claims to fulfill a policy (which doesn't exist) to provide that scope. I agree about the relationships via scopes and claims and resources, didn't intend to imply a different model. Everything in this is contextual to the resource except for ClientReg and PrevRPT, and even PrevRPT's scopes will almost certainly be contextual to resources as well. -- Justin On 1/12/2017 10:07 AM, George Fletcher wrote:

Thanks Justin,

OK, I see the difference in how we perceive ROPolicy and your perspective probably tweaks my write-up a little. Not sure yet whether I agree :-)

If the ROPolicy is the set of scopes the RqP has already met, how can it be a limiting factor? The RqP has to have the mechanism to provide new claims to meet to "new" scopes?

I also do not believe that there is a 1:1 relationship between scope name and claims required to meet that scope (see my other email from yesterday outside this thread). There is a 1:1 relationship between the resource_set_id:scope tuple and the claims required to meet that scope.

Thanks, George

On Thu, Jan 12, 2017 at 9:47 AM Justin Richer mailto:jricher@mit.edu> wrote:

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 http://photos.example.com (RS) to manage her photos and copmonkey.example.com http://copmonkey.example.com (UMA AS) to protect her photos. Bob wants to access Alice's landscape photo album (photos.example.com/photos/alice/landscape http://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 http://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 http://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 mailto: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 tel:%28425%29%20345-6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Jan 10, 2017 at 2:02 PM, James Phillpotts mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 mailto: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

-- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544