(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?