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

> Editorial note: shouldn't the "must" in that text be a "MUST"?

You are right. I changed that.

regards,
Torsten.

> On Thu, Sep 9, 2010 at 11:52 AM, Stefanie Dronia<sDronia@gmx.de>  wrote:
>>   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
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth