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 <lainh...@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) > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
