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 | Skype: xmlgrrl | Twitter: @xmlgrrl