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

Why not adopting Bill's suggestion and just return HTTP status code 200 for (already) invalid tokens?

regards,
Torsten.

Am 05.02.2013 um 17:46 schrieb Todd W Lainhart <lainhart@us.ibm.com>:

> > Could it do something with invalid_parameter that it couldn't do with invalid_token_parameter (among others), or vice versa? 
> 
> I'm not imagining a client doing anything programmatically useful with the distinction.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainhart@us.ibm.com
> 
> 
> 
> 
> 
> From:        "Richer, Justin P." <jricher@mitre.org> 
> To:        George Fletcher <gffletch@aol.com>, 
> Cc:        OAuth WG <oauth@ietf.org> 
> Date:        02/04/2013 04:10 PM 
> Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation 
> Sent by:        oauth-bounces@ietf.org 
> 
> 
> 
> 
> On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com>
> wrote:
> 
> > 
> > On 2/4/13 3:41 PM, Richer, Justin P. wrote:
> >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net> 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
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth