Re: [OAUTH-WG] draft-ietf-oauth-revocation

["Richer, Justin P." <[e-mail]>]

On Feb 4, 2013, at 3:57 PM, George Fletcher <[e-mail]>
 wrote:

> 
> On 2/4/13 3:41 PM, Richer, Justin P. wrote:
>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <[e-mail]> wrote:
>> 
>> 
>>> - invalid_token error code: I propose to use the new error code "invalid_parameter" (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice.
>> something more like "invalid_token_parameter" would maybe make sense, since it's not just *any* parameter, it's the special "token" parameter that we're talking about, but it's distinct from the invalid_token response. The introspection endpoint uses the same pattern of a token= parameter, but since the whole point of the introspection endpoint is determining token validity it doesn't actually throw an error here.
>> 
>> I agree that it doesn't need to be registered (since it's on a different endpoint).
> For what it's worth my thinking was that if we have an 'invalid_parameter' error, then the description can define which parameter is invalid. I don't think we should create a bunch of specific error values that are endpoint specific and could overlap which is where the whole error return value started.
> 

Hm, I see what you're saying, but the error response is already endpoint specific. Though there is value in not having conflicting and/or confusing responses from different endpoints that use the same error code for different things. 

What it really comes down to is: what can the client do with this error? Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? As I'm writing this out, I'm not convinced that it could, really, so this may be a bike shedding argument.

 -- Justin