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

[George Fletcher <[e-mail]>]

While this can work, it seems like it's mixing semantics a little as 
well. 'invalid_request' normally mean that the request is malformed in 
some way. Even 'unsupported parameter value' is really addressing a 
malformed request (e.g. a parameter only allows values of 'true' and 
'false' and the invocation uses the value 'maybe').

What about registering an error code of 'invalid_parameter_value'. Then 
the description could explain which parameter value is invalid and 
possibly why. We might even be able to shorten this to 
'invalid_parameter' as 'invalid_request' handles the case of an 
unsupported/invalid parameter name.

I did a quick check of the OpenID Connect specs and they also don't 
define an 'invalid_parameter' error code.

Thanks,
George

On 1/9/13 8:34 AM, Peter Mauritius wrote:
> 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
>>

-- 
George Fletcher <http://connect.me/gffletch>