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

[Peter Mauritius <[e-mail]>]

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: [phone]   [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