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

Stefanie Dronia <sDronia@gmx.de> Sat, 11 September 2010 16:52 UTC

Return-Path: <sDronia@gmx.de>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150313A68D9 for <oauth@core3.amsl.com>; Sat, 11 Sep 2010 09:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOjVzqMQ6B3C for <oauth@core3.amsl.com>; Sat, 11 Sep 2010 09:52:11 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 5C4A23A6828 for <oauth@ietf.org>; Sat, 11 Sep 2010 09:52:11 -0700 (PDT)
Received: (qmail invoked by alias); 11 Sep 2010 16:52:36 -0000
Received: from frnk-4d008b0e.pool.mediaWays.net (EHLO [192.168.2.239]) [77.0.139.14] by mail.gmx.net (mp038) with SMTP; 11 Sep 2010 18:52:36 +0200
X-Authenticated: #3259608
X-Provags-ID: V01U2FsdGVkX19d+O0jw/xdLICEaSq3baNNvG6XUAUCJqeLhr9CUd c62Zp/6OFmnjNC
Message-ID: <4C8BB3E7.7090606@gmx.de>
Date: Sat, 11 Sep 2010 18:52:55 +0200
From: Stefanie Dronia <sDronia@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: Brian Campbell <bcampbell@pingidentity.com>
References: <4C86BAF4.3060906@lodderstedt.net> <4C891EEA.80502@gmx.de> <AANLkTinUBD77ZtaHOD5CSGv+XAUuzSS0+NeyM5KLyJ8K@mail.gmail.com>
In-Reply-To: <AANLkTinUBD77ZtaHOD5CSGv+XAUuzSS0+NeyM5KLyJ8K@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D on token revocation submitted
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Sep 2010 16:52:14 -0000

  Hi Brain,

yes, you are right. I just went over that condition.

On the other hand, this implies to me, that access token revocation is 
not possible in a constellation as described before.

Regards,
Stefanie

Am 10.09.2010 00:38, schrieb Brian Campbell:
> Isn't that kind of situation exactly the reason that access token
> revocation was made optional?   Invalidation of access tokens on
> revocation of a refresh token is only a MUST, if the deployment
> already supports revocation of access tokens.  And if revocation of
> access tokens is supported, I'd assume the deployment already has an
> efficient means of invalidating them.
>
> Editorial note: shouldn't the "must" in that text be a "MUST"?
>
> 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
>