On 26 Dec 2012, at 17:14, Torsten Lodderstedt <[email protected]> wrote: > What does this mean? I would like to focus on the revocation of the token > actually passed to the revocation endpoint and leave the impact on other > related tokens and the authorization itself to the authorization server's > policy. The authorization server may incorporate the client type into its > revocation policy. > > My base assumption is that a client must be prepared to handle invalidation > of tokens at any time. So from an interoperability perspective, it's not > necessary to dictate a certain revocation policy to authorization servers. > > Current text: > > In the next step, the authorization server invalidates the token and the > respective authorization. If the particular token is a refresh token and the > authorization server supports the revocation of access tokens, then the > authorization server SHOULD also invalidate all access tokens based on the > same authorization (see Implementation Note). > > The client MUST NOT use the token again after revocation. > > Proposal: > > In the next step, the authorization server invalidates the token. The > client MUST NOT use this token again after revocation. > > Depending on the authorization server's revocation policy, the > revocation of a particular token may cause the revocation of related tokens > and the underlying authorization. > If the particular token is a refresh token and the authorization > server supports the revocation of access tokens, then the authorization > server SHOULD also invalidate all access tokens based on the same > authorization (see Implementation Note). > > Thoughts?
That works for my use case I think, assuming "authorization" doesn't specifically mean "access grant" but whatever the AS takes it to mean. -- Mark Wubben http://novemberborn.net http://twitter.com/novemberborn _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
