Core Section 3.5.3 (rev 09) has a Note that explains: "The authorization server is free to choose to return either the same RPT that appeared in the request or a new RPT, and it is also free to choose to
invalidate or retain the validity of the original RPT or any permission that was previously added to that RPT."
If the original RPT was valid, wouldn't the client have gotten access to the resource at the resource server? Would the client ever ask for another RPT with a valid original RPT? Does it describe the case where the RPT was for one resource/scope and not expired, but the client tried to use it to access another resource/scope and failed?
What we were trying to say was that:
- (Client can bring no RPT and ask for one -- not a concern)
- (AS can issue a new RPT A -- not a concern)
- Client can bring RPT A that doesn't have a permission for what it wants to do and ask for an RPT that works for what it wants to do
- AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it
- AS can issue a new RPT B (different RPT string), having added the relevant permissions to it
- AS can invalidate the old RPT A that the client brought it upon this action
- AS can retain the validity of the old RPT A that the client brought it and any of its permission(s) -- presumably ones that are still good and that the client didn't just try to exercise but found wanting
The question is, do all these options truly make sense? Is it, for example, such a common pattern for an AS to invalidate all previous tokens and stuff all current permissions into the latest and greatest access token (which equates to list item 2.2.1 above) that doing anything else is insanity? Any other option would leave the client juggling multiple tokens, and having to guess which ones unlock which resources.
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl