> 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) lainh...@us.ibm.com From: "Richer, Justin P." <jric...@mitre.org> To: George Fletcher <gffle...@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-boun...@ietf.org On Feb 4, 2013, at 3:57 PM, George Fletcher <gffle...@aol.com> wrote: > > On 2/4/13 3:41 PM, Richer, Justin P. wrote: >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <tors...@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
