Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

George Fletcher <gffletch@aol.com> Wed, 09 January 2013 13:08 UTC

Return-Path: <gffletch@aol.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF021F86E4 for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 05:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD53UOzyndCh for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 05:08:13 -0800 (PST)
Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56621F86DC for <oauth@ietf.org>; Wed, 9 Jan 2013 05:08:13 -0800 (PST)
Received: from mtaout-db03.r1000.mx.aol.com (mtaout-db03.r1000.mx.aol.com [172.29.51.195]) by imr-mb02.mx.aol.com (Outbound Mail Relay) with ESMTP id A50233800004D; Wed, 9 Jan 2013 08:08:12 -0500 (EST)
Received: from palantir.local (unknown [64.79.50.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9113CE000117; Wed, 9 Jan 2013 08:08:11 -0500 (EST)
Message-ID: <50ED6BBB.40008@aol.com>
Date: Wed, 09 Jan 2013 08:08:11 -0500
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: OAuth WG <oauth@ietf.org>
References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de>
In-Reply-To: <50EC988E.7070007@fun.de>
Content-Type: multipart/alternative; boundary="------------070602000307040705090505"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1357736892; bh=TtEI4z9ZioLrII+G42go5ldwIPc4SJ86FUWtTRZlptE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=hmsxwN2Qk5Un/MmM5hqobZNeP04r09YWCWFhUbd3tNWvJPW+jKNVYaYlz5A0lcDjF 5yJI0PgR3Zw1xK0Fui+0t/leTDUbtRv0Er82IdWv5x8ER7v/RYEW1zgG0iO3qjco6H QbBoMRBwDTTVA1XHa/6C9GyKrRrUEG5AhKZht+gE=
X-AOL-SCOLL-SCORE: 1:2:522901760:93952408
X-AOL-SCOLL-URL_COUNT: 2
x-aol-sid: 3039ac1d33c350ed6bbb48fb
X-AOL-IP: 64.79.50.205
Cc: Peter Mauritius <peter.mauritius@fun.de>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 09 Jan 2013 13:08:15 -0000

Hi Peter,

I do agree that the meanings of 'invalid_token' between the two specs 
(6750 and revocation) are different. After thinking about this for a 
while, I've determined, at least for myself, what the difference is 
between the 'invalid_token' error code in RFC 6750 and the revocation spec.

In RFC 6750 'invalid_token' means that the authorization token for the 
request is invalid.

In 'oauth-revocation', 'invalid_token' means that the parameter 
containing the token to be revoked is invalid.

I am very concerned about using the same error string, 'invalid_token', 
to mean two different things. While the semantic difference is not great 
in this case, I think it sets a bad precedent for OAuth to have the same 
error string have two different semantic meanings.

I do agree that the error code used in this spec should be registered.

Thanks,
George

On 1/8/13 5:07 PM, Peter Mauritius wrote:
> Hi George,
>
> RFC6750 defines "invalid-token" for access tokens which is not the 
> case for "invalid-token" in the revocation specification. Here it is 
> applicable for refresh tokens as well. Therefore we should not simply 
> reference the "invalid-token" of RFC6750.
>
> As far as I understand both, the reviewed specification and RFC6750, 
> reference RFC6749. RFC6750 includes in section 6.1 
> <http://tools.ietf.org/html/rfc6750#section-6.2>  OAuth Extensions 
> Error Registration sections according to RFC6749 section 11.4. 
> <http://tools.ietf.org/html/rfc6749#section-11.4> for the error codes 
> defined throughout the document including "invalid-token".
>
> I am not very experienced in the formal process but shouldn't we add 
> such sections for the two error codes defined in the revocation 
> document? Especially for "invalid-token" we should define an error 
> registration section that defines the error code for our error usage 
> location and protocol extension to distinguish it from RFC6750 and to 
> avoid confusion. Doing this I hope there is no necessity to add a 
> reference to RFC6750 or to define a new error code.
>
> What do the more experienced reviewers think?
>
> Regards
>   Peter
>
> Am 07.01.13 17:25, schrieb George Fletcher:
>> My concern with leaving both specs separated is that over time the 
>> semantics of the two error codes could diverge and that would be 
>> confusing for developers. If we don't want to create a dependency on 
>> RFC 6750, then I would recommend a change to the error code name so 
>> that there is no name collision or confusion.
>>
>> Thanks,
>> George
>>
>> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>
>>> thank you for pointing this out. Your proposal sounds reasonable 
>>> although the revocation spec does not build on top of RFC 6750.
>>>
>>> As refering to RFC 6750 would create a new dependency, one could 
>>> also argue it would be more robust to leave both specs separated.
>>>
>>> What do others think?
>>>
>>> regards,
>>> Torsten.
>>> Am 07.01.2013 17:12, schrieb George Fletcher:
>>>> One quick comment...
>>>>
>>>> Section 2.0: Both RFC 6750 and this specification define the 
>>>> 'invalid_token' error code.
>>>>
>>>> Should this spec reference the error code from RFC 6750?
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>
>>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote:
>>>>> Hi,
>>>>>
>>>>> the new revision is based on the WGLC feedback and incorporates 
>>>>> the following changes:
>>>>>
>>>>> - renamed "access grant" to "authorization" and reworded parts of 
>>>>> Abstract and Intro in order to better align with core spec wording 
>>>>> (feedback by Amanda)
>>>>> - improved formatting of section 2.1. (feedback by Amanda)
>>>>> - improved wording of last paragraph of section 6 (feedback by 
>>>>> Amanda)
>>>>> - relaxed the expected behavior regarding revocation of related 
>>>>> tokens and the authorization itself in order to remove unintended 
>>>>> constraints on implementations (feedback by Mark)
>>>>> - replaced description of error handling by pointer to respective 
>>>>> section of core spec (as proposed by Peter)
>>>>> - adopted proposed text for implementation note (as proposed by 
>>>>> Hannes)
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>> Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org:
>>>>>> A New Internet-Draft is available from the on-line 
>>>>>> Internet-Drafts directories.
>>>>>>   This draft is a work item of the Web Authorization Protocol 
>>>>>> Working Group of the IETF.
>>>>>>
>>>>>>     Title           : Token Revocation
>>>>>>     Author(s)       : Torsten Lodderstedt
>>>>>>                            Stefanie Dronia
>>>>>>                            Marius Scurtescu
>>>>>>     Filename        : draft-ietf-oauth-revocation-04.txt
>>>>>>     Pages           : 8
>>>>>>     Date            : 2013-01-07
>>>>>>
>>>>>> Abstract:
>>>>>>     This document proposes an additional endpoint for OAuth 
>>>>>> authorization
>>>>>>     servers, which allows clients to notify the authorization 
>>>>>> server that
>>>>>>     a previously obtained refresh or access token is no longer 
>>>>>> needed.
>>>>>>     This allows the authorization server to cleanup security 
>>>>>> credentials.
>>>>>>     A revocation request will invalidate the actual token and, if
>>>>>>     applicable, other tokens based on the same authorization.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation
>>>>>>
>>>>>> There's also a htmlized version available at:
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04
>>>>>>
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -- 
> Peter Mauritius   Chief Technical Director
> Senior Consultant
> Tel: +49 721 96448-0   Fax: +49 721 96448-299peter.mauritius@fun.de
>
> fun communications GmbH   Lorenzstr. 29   D-76135 Karlsruhe
> Geschaeftsfuehrer Johannes Feulner
> Amtsgericht Mannheim HRB 106906
>
> http://www.fun.de
> http://blogs.fun.de
> http://www.twitter.com/fun_de
> http://www.facebook.com/funcommunications