Re: [OAUTH-WG] I-D on token revocation submitted

  Hallo Torsten,

first of all thanks for providing this draft on the mailing list.
Except for the following words, the draft is consistent. It defines the 
end of a token's life cycle, intended by the user.

While reading it, I think that the following part of chapter 2 (Token 
Revocation) might cause problems a a certain situation:

"If the processed token is a refresh token and the authorization
    server supports the revocation of access tokens, then the
    authorization server must also invalidate all access tokens issued
    for that refresh token."

Situation:
Authz Server(s) and Resource Server(s) are separate systems that are set 
in an open triangle (no communication between them e.g. to verify access 
tokens).

Problem:
How does the Resource Server(s) know that an access token was revoked 
and is not valid to access resources any more?
=> Communication  between the servers necessary
=> benefit of open triangle architecture are lost for this case.
I think that this is a problem with large scale systems.

Although, if there are several Authz Server(s) , then there has to be 
communication between there or a shared data base to assure that revoked 
(refresh) tokens are invalid.

=> Is this requirement really a MUST?
I don't think so.

Any thoughts?

Regards,
Stefanie

Am 08.09.2010 00:21, schrieb Torsten Lodderstedt:
>  I just submited the first version of my I-D for token revocation.
>
> Link: 
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>
> The I-D proposes an additional endpoint, which can be used to revoke 
> both refresh and access tokens. The objective is to enhance OAuth 
> security by giving clients and users explicite control of the 
> finalization of the token life cycle, e.g. to implement application 
> logout or access authorization removal.
>
> Please take the time to review the document (2 pages, essentially) and 
> give me feedback. My goal is that this draft becomes a working group 
> document.
>
> regards,
> Torsten.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>