Great, yes, this helps. I think the new wording aligns nicely with the example. Cigdem and I actually met earlier today and she helped me smooth out the language further; *CandidateGrantedScopes* survived that process. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Jan 24, 2017 at 9:04 AM, George Fletcher < george.fletcher@teamaol.com> wrote:

Hi Eve,

A couple of things...

1. the names "claimsRequired" and "claims()" function are more a misnomer by me. What I meant (and wasn't sure about the correct terminology) is... the "stuff" required by the client/RqP in order to meet the RO's policy for the requested scope(s).

2. I agree that we don't need the details of how to match resource_set:scope(s) tuple to the RO's policy. I explained in the email what made sense to me, but it can be left up to the AS.

3. From a set math perspective, what's critical is the resulting list of resource_set:scope(s) tuples that result from all the internal AS processing (and potentially claims gathering).

4. As for the specific example of the download scope being mapped to a policy that requires membership in the family list, I looked at this from the perspective that the AS is trying to meet all the policies for all RequestedScopes. However, when it comes to the download scope, the client/RqP has not proven the meet the policy so that scope can not be allowed. Hopefully that makes sense:)

Thanks, George

On Mon, Jan 23, 2017 at 9:33 PM Eve Maler wrote:

...

I'm studying this example very closely as I work on putting in spec text, since I want to include it as an example in the spec if I can.

I get the idea of "The client has registered/requested *download*, and this puts it legitimately into *RequestedScopes*, but that scope is only for 'family', so now the AS has to decide: Fail the client totally, or grant only the scopes the client actually qualifies for?" In my draft text right now, I've changed what was *GrantedScopes* to *CandidateGrantedScopes*, and (as agreed) said it's an option for the AS not to grant them. (Hoping to publish tonight, or if not, tomorrow mid-day.)

I'm a little worried about putting a lot of claim logic into the spec a la this part:

for each scope in scopesToProcess { claimsRequired += claims(rsid, scope) } normalize/merge claimsRequired ...

We have a couple of claims collection mechanisms, but it's not just about claims, it could be about other environmental factors. (This is partly what the Dept for Work and Pensions security profile is about.) And claims themselves are pretty closely tied to what you want to do with policy, and policy could be a lot of things (all out of scope). How much farther do we need to go for AS interoperability?

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Wed, Jan 18, 2017 at 8:56 AM, Eve Maler wrote:

The following is the "lost email" from George on questions about how the AS might manage registered scopes/resource IDs and the policy conditions that will have to govern the assessment process.

====

I wanted to start a different thread that relates to the "set math" discussion but is more focused on the relationship between resource registered scopes and resource owner policy (ROPolicy). Please correct any incorrect thinking that follows:)

In order for a RO to define policy for a given resource, the RS must first register that resource set with the AS. When the RS registers the resource set with the AS, the RS defines what scopes are allowed for that specific resource set. The RO can then go to the AS and find the resource set and define policies that link to the scopes associated with the resource set.

Following on my example from the "set math" thread, lets say my photo service registers two resources: rsid_1: photos/gff/landscape scopes: view, link, download rsid_2: photos/gff/family scopes: view, link, download, print

When I (as the RO) go to the AS, I'm assuming that I get to define the policy for each of the scopes associated with each of the registered resource sets. Now in practice, I suspect that as the RO, I want an AS that allows me to define sets of claims and then map those to the scopes associated with the different resource sets.

Lets assume I've defined the following policy claim sets at the AS. family -- list of individuals that are part of my family photo_viewer -- promises to not download/sell/market any photo

I then map the above policies to the resource sets and scopes as follows...

rsid_1: view, link -- photo_viewer download -- family

rsid_2: view, link, download, print -- family

Now, when the client tries to access photos/gff/landscape the RS registers a permissions ticket with scopes for "view" and "link" but not download. The client then presents the permissions ticket to the AS and the AS determines which claims the RqP needs to meet in order to be authorized for those scopes. In this case, both scopes require the same claims (photo_viewer).

Now, if the client requested the "download" scope in addition to the scopes in the permissions ticket, then the RqP must meet the family claims in order to get access to that scope. I'm assuming we are leaving it up to the AS to determine whether to fail the RPT request if the RqP can NOT meet the family claim, or return "view" and "link" but NOT "download". The latter feels more like OAuth2 though I'm guessing in more complicated cases this could get dicey:)

So RPT request processing at the AS should, I think, be determined by the intersection of the set of scopes defined for the resources set and the set of scopes requested. Simplifying slightly from Justin's set math...

scopesToProcess = intersection(Requested, RSReg)

The AS then needs to iterate through the "scopes to process" to determine the claims the RqP needs to meet in order to grant an RPT with that set of scopes.

for each scope in scopesToProcess { claimsRequired += claims(rsid, scope) } normalize/merge claimsRequired

Once the required set of claims is defined, the RqP/client can go through claims negotiation. Depending on which claims are met, the associated authorized scopes can be determined.

claims met == promise to not download/sell/market

scopes authorized based on claims met view, link

If the set of authorized scopes is NOT a super set of the scopes requested in the permissions ticket, the RPT request fails. Otherwise, return the scopes authorized.

In this context, I don't think the PrevRPT provides much value, however, a token defining previously satisfied claims provides a lot of value.

Does that resonate with how others envision the logic and flow working?

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

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

-- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 <(703)%20462-3494> Office:+1-703-265-2544 <(703)%20265-2544>