I know, that's why I asked. I think this is the simplest way to deal with this type of error. I therefore prefer it.
Am 05.02.2013 um 20:49 schrieb Justin Richer <jric...@mitre.org>: > You know, that works as well. From the client's perspective, the token isn't > good anymore. The client shouldn't care if the token was good in the first > place if it's revoking it. > > -- Justin > > > On 02/05/2013 02:41 PM, Torsten Lodderstedt wrote: >> 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
