I think it makes sense for the AS to be able to choose whether to re-use the incoming access token or not. It could be perfectly "valid" but just not for the context of the request that was being made. The question is then what to do about invalidation. I'm generally in favor of this being AS choice as well, but perhaps this guidance makes the most sense:

If the client presents an existing RPT and the AS issues a new RPT, the AS SHOULD revoke the existing RPT, if possible. The client MUST discard its previous RPT.

This is in keeping with OAuth's guidance on issuing new refresh tokens for a refresh token request:

   The authorization server MAY issue a new refresh token, in which case
   the client MUST discard the old refresh token and replace it with the
   new refresh token.  The authorization server MAY revoke the old
   refresh token after issuing a new refresh token to the client.  If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.
In other words, from the client's perspective, it's obviously trying to get something in the context of its existing RPT, otherwise it wouldn't have included it in the request. So anything that comes out should directly replace what the client sent in, from the client's side. If the AS can revoke the incoming RPT, it's probably a good idea, but the client won't care.

  -- Justin

On 12/29/2016 5:35 PM, Eve Maler wrote:
Cigdem asked some good questions in a series of comments she sent me:

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."

Cigdem's questions were (slightly edited):

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:
  1. (Client can bring no RPT and ask for one -- not a concern)
    1. (AS can issue a new RPT A -- not a concern)
  2. 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
    1. AS is allowed to reissue the existing RPT A (same RPT string), having added the relevant permissions to it
    2. AS can issue a new RPT B (different RPT string), having added the relevant permissions to it
      1. AS can invalidate the old RPT A that the client brought it upon this action
      2. 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



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