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
