(In the following, "the previous RPT" means the actual RPT the client puts on its request, and *PreviousRPT* means the set of scopes associated with that RPT.) 1. I agree that *PreviousRPT* scopes are bound to resources, because an RPT is associated with one ore more permission structures, each of which has a resource ID with scopes in it. 2. I kind of see what you mean about the overlap between the PCT and *PreviousRPT*. The first is a proxy for an accumulated set of claims/environmental factors/state associated with getting a set of entitlements, and the second is the boiled-down set of entitlements themselves, gotten as a result of those claims. But it may easy to read too much into the overlap, or maybe it's a false equivalence or something, because claim values can go stale over time, and all kinds of interactions can/do take place that are entirely "internal" to the AS-RqP interface once the RqP is redirected to the AS, etc., etc. The PCT is really just "what we had to design in lightweight fashion in the face of not being able to leverage a real cross-domain identity system", kind of like how OIDC handles storing an access token for distributed and aggregated claims. :-) Is there anything about the overlap we should observe, make a caution about, etc. in the spec itself? 3. Thinking about motivations for including a previous RPT on the request, remember that we added some RPT management text recently that goes like this: "If the client included an existing RPT in its request and the authorization server issues a new RPT, the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT." We've said that the point of providing a *PCT* (not a previous RPT) is to help reduce the need for more claims collection. In the definition of the "pct" property itself, we say "the client MAY include the PCT in order to optimize the process of seeking a new RPT". (Hmm, maybe the word "new" isn't accurate...) But for the "rpt" property way the client can include it because "This gives the authorization server the option of updating the existing RPT instead of issuing a new one". We already did discuss this rationale for including a previous RPT, and I don't want us to have to discuss it unless we have some new information, but -- do we agree this makes logical sense? The alternative would be that the client just keeps getting back more "little" RPTs. (And we wouldn't have to solve the *PreviousRPT* set math problem. :-) ) (But it would be a fairly large backwards incompatibility, so we should be clear why we'd be doing it!) 4. Thinking about problems with RPT super-tokens: - If the client *doesn't* include a previous RPT on the request, the AS *has to* issue a new RPT, and the client gets lots of individual little tokens with bits of entitlements. - If the client *does* include a previous RPT and the AS upgrades it, the client gets its *original* token back, bigger. Which may be handled by reference, not value, so...who cares if it gets really big, I guess? - If the client *does* include a previous RPT and the AS swaps it for a *new* one, the client gets a *new* token back, bigger. Again, super-token problem waved away depending on the AS/ecosystem? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Jan 24, 2017 at 9:14 AM, George Fletcher < george.fletcher@teamaol.com> wrote:

As it relates to the PreviousRPT it seems like there are a couple key factors...

1. The data contained in the PreviousRPT must be resource_set:scope(s) tuples. I can't see how anything else makes sense.

2. I see a fair amount of overlap between the PCT and the PreviousRPT. I realize from an implementation perspective the impact on the AS could be different, but effectively, both are tracking the policy/permissions that have been granted to the client/RqP but just in different ways.

3. If the point of providing the PreviousRPT is to help reduce the set of new claims/policy the client/RqP must meet, then it doesn't make sense to remove resource_set:scope(s) tuples when issuing a new one. This of course means that the PreviousRPT could grow into a "super token". Maybe that's OK?

4. I do worry a little about the PreviousRPT going large in size as well. Of course, it's possible for the AS to just store the state for all resource_set:scope(s) tuples on the server side in which case the PreviousRPT is just a pointer to the server-side state.

Thanks, George

On Mon, Jan 23, 2017 at 8:03 PM Eve Maler wrote:

Domenico created a cool Venn diagram (huzzah!) showing what we've decided for set math thus far. I've attached it below.

I believe it's accurate as far as the client-requested scopes, client-registered scopes, and permission ticket go. When it comes to allowed scopes and granted scopes, these unfortunately may be impossible to show in any diagram because the policy conditions that have been configured into the AS are "invisible", and thus the allowed scopes could fall wholly within, fall partially with, or fall totally outside the requested scopes. This means the granted scopes are impossible to show as well. (Unless we show each option in turn, or something.)

James and I were talking earlier about how this connects to the paragraph about "default-deny". I'll let James say more about it for further email discussion.

Finally, how shall we account for the presence of a previous RPT on a client's request to the token endpoint? In the call, we got as far as saying "The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access."

Let *PreviousRPT* stand for all the scopes in an RPT present on a client's request at the token endpoint. Presumably, *the reason the client included this RPT* is because *the token failed* when it was trying to accomplish some access over at the RS and *the client would like the AS to upgrade that token, please*.

Is that correct?

It could have been that the token already had some scope (say, *read*) but didn't have some other scope (say, *write*) for resource ID *123* (say, a file), or it had all permissions for read resource *123* (the file) but no read access for resource *456* (its "enclosing" folder).

So the RPT might have permissions *123:read* but not *123:read,write*, or it might have *123:read,write* but not *456:read*. Importantly, it might also have collected a bunch of other stuff that's not relevant to what the client is currently seeking, like *6317:foo,bar,baz* and *83452:man,from,uncle*. Remember that these individual permissions may have individual expiration timestamps on them.

What's clear is that *RequestedScopes* as currently defined (whether coming through client reg/req action or through RS permission request action) could have, say, *123:write* or *456:read* in it in order to give the client what it needs right now. If *PreviousRPT* has permission structures in it for *123* and *456*, we can probably say something sensible.

What's really not clear yet is: What should happen to the *6317:foo,bar,baz* and *83452:man,from,uncle* permission structures in *PreviousRPT*?

Okay, that's an opening bid... What else?

*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>

Thank you, I think you've put your finger on it: It's temporal. The PCT and the set of scopes represented by the RPT *in the same request* (that is, *this* authorization process) can *possibly* have a kind of "last input"/"this output" equivalence, assuming the state of any of the claims etc. didn't change from the *last* authorization process (basically, a session). But if we're not talking about PCTs and RPTs from the same request, all bets are off. And since this assumption isn't a safe one to hold, it's moot anyway. Is this type of analysis worth discussing anywhere in the spec, or in an outside doc (say, the UIG)? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Jan 25, 2017 at 8:55 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:

I'm not sure I agree about the PreviousRPT and the PCT - the former is a collection of scopes previously granted for a set of resources, and the latter is a collection of claims that may be useful in granting scopes in the future.

If we take an example a resource A that has a policy that says:

user=fred && day=monday => view

User will be captured in the PCT, but the PreviousRPT, obtained on a Monday, that contains view for the resource should not result in getting view on the Tuesday, when given the PCT with user=fred in it?

J.

On 25 January 2017 at 00:42, Eve Maler wrote:

...

(In the following, "the previous RPT" means the actual RPT the client puts on its request, and *PreviousRPT* means the set of scopes associated with that RPT.)

1. I agree that *PreviousRPT* scopes are bound to resources, because an RPT is associated with one ore more permission structures, each of which has a resource ID with scopes in it.

2. I kind of see what you mean about the overlap between the PCT and *PreviousRPT*. The first is a proxy for an accumulated set of claims/environmental factors/state associated with getting a set of entitlements, and the second is the boiled-down set of entitlements themselves, gotten as a result of those claims. But it may easy to read too much into the overlap, or maybe it's a false equivalence or something, because claim values can go stale over time, and all kinds of interactions can/do take place that are entirely "internal" to the AS-RqP interface once the RqP is redirected to the AS, etc., etc. The PCT is really just "what we had to design in lightweight fashion in the face of not being able to leverage a real cross-domain identity system", kind of like how OIDC handles storing an access token for distributed and aggregated claims. :-)

Is there anything about the overlap we should observe, make a caution about, etc. in the spec itself?

3. Thinking about motivations for including a previous RPT on the request, remember that we added some RPT management text recently that goes like this: "If the client included an existing RPT in its request and the authorization server issues a new RPT, the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT."

We've said that the point of providing a *PCT* (not a previous RPT) is to help reduce the need for more claims collection. In the definition of the "pct" property itself, we say "the client MAY include the PCT in order to optimize the process of seeking a new RPT". (Hmm, maybe the word "new" isn't accurate...) But for the "rpt" property way the client can include it because "This gives the authorization server the option of updating the existing RPT instead of issuing a new one".

We already did discuss this rationale for including a previous RPT, and I don't want us to have to discuss it unless we have some new information, but -- do we agree this makes logical sense? The alternative would be that the client just keeps getting back more "little" RPTs. (And we wouldn't have to solve the *PreviousRPT* set math problem. :-) ) (But it would be a fairly large backwards incompatibility, so we should be clear why we'd be doing it!)

4. Thinking about problems with RPT super-tokens:

- If the client *doesn't* include a previous RPT on the request, the AS *has to* issue a new RPT, and the client gets lots of individual little tokens with bits of entitlements. - If the client *does* include a previous RPT and the AS upgrades it, the client gets its *original* token back, bigger. Which may be handled by reference, not value, so...who cares if it gets really big, I guess? - If the client *does* include a previous RPT and the AS swaps it for a *new* one, the client gets a *new* token back, bigger. Again, super-token problem waved away depending on the AS/ecosystem?

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

On Tue, Jan 24, 2017 at 9:14 AM, George Fletcher < george.fletcher@teamaol.com> wrote:

...

As it relates to the PreviousRPT it seems like there are a couple key factors...

1. The data contained in the PreviousRPT must be resource_set:scope(s) tuples. I can't see how anything else makes sense.

2. I see a fair amount of overlap between the PCT and the PreviousRPT. I realize from an implementation perspective the impact on the AS could be different, but effectively, both are tracking the policy/permissions that have been granted to the client/RqP but just in different ways.

3. If the point of providing the PreviousRPT is to help reduce the set of new claims/policy the client/RqP must meet, then it doesn't make sense to remove resource_set:scope(s) tuples when issuing a new one. This of course means that the PreviousRPT could grow into a "super token". Maybe that's OK?

4. I do worry a little about the PreviousRPT going large in size as well. Of course, it's possible for the AS to just store the state for all resource_set:scope(s) tuples on the server side in which case the PreviousRPT is just a pointer to the server-side state.

Thanks, George

On Mon, Jan 23, 2017 at 8:03 PM Eve Maler wrote:

Domenico created a cool Venn diagram (huzzah!) showing what we've decided for set math thus far. I've attached it below.

I believe it's accurate as far as the client-requested scopes, client-registered scopes, and permission ticket go. When it comes to allowed scopes and granted scopes, these unfortunately may be impossible to show in any diagram because the policy conditions that have been configured into the AS are "invisible", and thus the allowed scopes could fall wholly within, fall partially with, or fall totally outside the requested scopes. This means the granted scopes are impossible to show as well. (Unless we show each option in turn, or something.)

James and I were talking earlier about how this connects to the paragraph about "default-deny". I'll let James say more about it for further email discussion.

Finally, how shall we account for the presence of a previous RPT on a client's request to the token endpoint? In the call, we got as far as saying "The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access."

Let *PreviousRPT* stand for all the scopes in an RPT present on a client's request at the token endpoint. Presumably, *the reason the client included this RPT* is because *the token failed* when it was trying to accomplish some access over at the RS and *the client would like the AS to upgrade that token, please*.

Is that correct?

It could have been that the token already had some scope (say, *read*) but didn't have some other scope (say, *write*) for resource ID *123* (say, a file), or it had all permissions for read resource *123* (the file) but no read access for resource *456* (its "enclosing" folder).

So the RPT might have permissions *123:read* but not *123:read,write*, or it might have *123:read,write* but not *456:read*. Importantly, it might also have collected a bunch of other stuff that's not relevant to what the client is currently seeking, like *6317:foo,bar,baz* and *83452:man,from,uncle*. Remember that these individual permissions may have individual expiration timestamps on them.

What's clear is that *RequestedScopes* as currently defined (whether coming through client reg/req action or through RS permission request action) could have, say, *123:write* or *456:read* in it in order to give the client what it needs right now. If *PreviousRPT* has permission structures in it for *123* and *456*, we can probably say something sensible.

What's really not clear yet is: What should happen to the *6317:foo,bar,baz* and *83452:man,from,uncle* permission structures in *PreviousRPT*?

Okay, that's an opening bid... What else?

*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>

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

I do think it's worth mentioning somewhere that all authorizations issued and claims provided are temporal and the AS must treat them as such. If not, many implementations will make the mistake James points out by accepting the resource:view tuple from the PreviousRPT as valid for the resource today. Maybe the thing to say in the spec, is that even when provided with a PreviousRPT the AS MUST re-evaluate the policy for all identified resource_sets to ensure the previously issued authorizations are still valid. Thanks, George On Wed, Jan 25, 2017 at 12:29 PM George Fletcher < george.fletcher@teamaol.com> wrote:

Hi James,

I think I'm missing something. Regardless of whether a PreviousRPT or PCT was passed in, the user should not get access on Tuesday.

I do agree that PreviousRPT should capture the list of previously authorized resource_set:scope mapping. This is the result of previous AS authorization calculations based on the RO's policy. So the PreviousRPT is a collection of previous authorizations issued by the AS.

The PCT is a collection of previously provided data by the client/RqP in the process of meeting claims; i.e. it represents the "raw" claims the client/RqP have provided in the past. These "raw" claims can be used to determine if they are sufficient to meet the policy required for the current permission ticket. Where I see a connection is that you can get to some (if not all) of the claims identified by the PCT be working backward from the PreviousRPT resource_set:scope data to the claims that had to be met in order to generate that tuple. Those claims could then be used to see if they meet the policy for the current request (permission_ticket).

Regardless, as you point out, the AS can NOT just take the resource:view tuple in the PreviousRPT as valid when the user tries to access the resource on Tues, because the original authorization was time bound by the RO's policy. Maybe this means that the data in the PreviousRPT also needs to include an expiry time for any stored resource_set:scope tuples?

Thanks, George

On Wed, Jan 25, 2017 at 11:55 AM James Phillpotts < james.phillpotts@forgerock.com> wrote:

I'm not sure I agree about the PreviousRPT and the PCT - the former is a collection of scopes previously granted for a set of resources, and the latter is a collection of claims that may be useful in granting scopes in the future.

If we take an example a resource A that has a policy that says:

user=fred && day=monday => view

User will be captured in the PCT, but the PreviousRPT, obtained on a Monday, that contains view for the resource should not result in getting view on the Tuesday, when given the PCT with user=fred in it?

J.

On 25 January 2017 at 00:42, Eve Maler wrote:

(In the following, "the previous RPT" means the actual RPT the client puts on its request, and *PreviousRPT* means the set of scopes associated with that RPT.)

1. I agree that *PreviousRPT* scopes are bound to resources, because an RPT is associated with one ore more permission structures, each of which has a resource ID with scopes in it.

2. I kind of see what you mean about the overlap between the PCT and *PreviousRPT*. The first is a proxy for an accumulated set of claims/environmental factors/state associated with getting a set of entitlements, and the second is the boiled-down set of entitlements themselves, gotten as a result of those claims. But it may easy to read too much into the overlap, or maybe it's a false equivalence or something, because claim values can go stale over time, and all kinds of interactions can/do take place that are entirely "internal" to the AS-RqP interface once the RqP is redirected to the AS, etc., etc. The PCT is really just "what we had to design in lightweight fashion in the face of not being able to leverage a real cross-domain identity system", kind of like how OIDC handles storing an access token for distributed and aggregated claims. :-)

Is there anything about the overlap we should observe, make a caution about, etc. in the spec itself?

3. Thinking about motivations for including a previous RPT on the request, remember that we added some RPT management text recently that goes like this: "If the client included an existing RPT in its request and the authorization server issues a new RPT, the authorization server SHOULD revoke the existing RPT, if possible, and the client MUST discard its previous RPT."

We've said that the point of providing a *PCT* (not a previous RPT) is to help reduce the need for more claims collection. In the definition of the "pct" property itself, we say "the client MAY include the PCT in order to optimize the process of seeking a new RPT". (Hmm, maybe the word "new" isn't accurate...) But for the "rpt" property way the client can include it because "This gives the authorization server the option of updating the existing RPT instead of issuing a new one".

We already did discuss this rationale for including a previous RPT, and I don't want us to have to discuss it unless we have some new information, but -- do we agree this makes logical sense? The alternative would be that the client just keeps getting back more "little" RPTs. (And we wouldn't have to solve the *PreviousRPT* set math problem. :-) ) (But it would be a fairly large backwards incompatibility, so we should be clear why we'd be doing it!)

4. Thinking about problems with RPT super-tokens:

- If the client *doesn't* include a previous RPT on the request, the AS *has to* issue a new RPT, and the client gets lots of individual little tokens with bits of entitlements. - If the client *does* include a previous RPT and the AS upgrades it, the client gets its *original* token back, bigger. Which may be handled by reference, not value, so...who cares if it gets really big, I guess? - If the client *does* include a previous RPT and the AS swaps it for a *new* one, the client gets a *new* token back, bigger. Again, super-token problem waved away depending on the AS/ecosystem?

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

On Tue, Jan 24, 2017 at 9:14 AM, George Fletcher < george.fletcher@teamaol.com> wrote:

As it relates to the PreviousRPT it seems like there are a couple key factors...

1. The data contained in the PreviousRPT must be resource_set:scope(s) tuples. I can't see how anything else makes sense.

2. I see a fair amount of overlap between the PCT and the PreviousRPT. I realize from an implementation perspective the impact on the AS could be different, but effectively, both are tracking the policy/permissions that have been granted to the client/RqP but just in different ways.

3. If the point of providing the PreviousRPT is to help reduce the set of new claims/policy the client/RqP must meet, then it doesn't make sense to remove resource_set:scope(s) tuples when issuing a new one. This of course means that the PreviousRPT could grow into a "super token". Maybe that's OK?

4. I do worry a little about the PreviousRPT going large in size as well. Of course, it's possible for the AS to just store the state for all resource_set:scope(s) tuples on the server side in which case the PreviousRPT is just a pointer to the server-side state.

Thanks, George

On Mon, Jan 23, 2017 at 8:03 PM Eve Maler wrote:

Domenico created a cool Venn diagram (huzzah!) showing what we've decided for set math thus far. I've attached it below.

I believe it's accurate as far as the client-requested scopes, client-registered scopes, and permission ticket go. When it comes to allowed scopes and granted scopes, these unfortunately may be impossible to show in any diagram because the policy conditions that have been configured into the AS are "invisible", and thus the allowed scopes could fall wholly within, fall partially with, or fall totally outside the requested scopes. This means the granted scopes are impossible to show as well. (Unless we show each option in turn, or something.)

James and I were talking earlier about how this connects to the paragraph about "default-deny". I'll let James say more about it for further email discussion.

Finally, how shall we account for the presence of a previous RPT on a client's request to the token endpoint? In the call, we got as far as saying "The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access."

Let *PreviousRPT* stand for all the scopes in an RPT present on a client's request at the token endpoint. Presumably, *the reason the client included this RPT* is because *the token failed* when it was trying to accomplish some access over at the RS and *the client would like the AS to upgrade that token, please*.

Is that correct?

It could have been that the token already had some scope (say, *read*) but didn't have some other scope (say, *write*) for resource ID *123* (say, a file), or it had all permissions for read resource *123* (the file) but no read access for resource *456* (its "enclosing" folder).

So the RPT might have permissions *123:read* but not *123:read,write*, or it might have *123:read,write* but not *456:read*. Importantly, it might also have collected a bunch of other stuff that's not relevant to what the client is currently seeking, like *6317:foo,bar,baz* and *83452:man,from,uncle*. Remember that these individual permissions may have individual expiration timestamps on them.

What's clear is that *RequestedScopes* as currently defined (whether coming through client reg/req action or through RS permission request action) could have, say, *123:write* or *456:read* in it in order to give the client what it needs right now. If *PreviousRPT* has permission structures in it for *123* and *456*, we can probably say something sensible.

What's really not clear yet is: What should happen to the *6317:foo,bar,baz* and *83452:man,from,uncle* permission structures in *PreviousRPT*?

Okay, that's an opening bid... What else?

*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>

_______________________________________________ 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>

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