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

[Peter Mauritius <[e-mail]>]

Ok,

now I understand your intention. In oauth-revocation the token is just a 
parameter not an authorization token as in RFC6750. RFC6749 uses  
"invalid_request" for
> includes an unsupported parameter value
Perhaps we should drop the error-code and use invalid-request with a 
error-description explaining the token parameter is not usable.

Regards
   Peter

On 09.01.2013 14:08, George Fletcher wrote:
> 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 [e-mail]:
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> -- 
>> Peter Mauritius   Chief Technical Director
>> Senior Consultant
>> Tel: [phone]   Fax: +49 721 [e-mail]
>>
>> 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
>