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 Office:+1-703-265-2544