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

[Peter Mauritius <[e-mail]>]

Hi George,

I am with you and support your suggestion. An "invalid_parameter" error 
code would be a practical solution that would allow to distinguish 
between token usage and token as parameter.

Regards
   Peter

Am 09.01.13 16:40, schrieb George Fletcher:
> 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>


-- 
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