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