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 <[email protected]
<mailto:[email protected]>>:
> 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)
[email protected] <mailto:[email protected]>*
From: "Richer, Justin P." <[email protected] <mailto:[email protected]>>
To: George Fletcher <[email protected] <mailto:[email protected]>>,
Cc: OAuth WG <[email protected] <mailto:[email protected]>>
Date: 02/04/2013 04:10 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by: [email protected] <mailto:[email protected]>
------------------------------------------------------------------------
On Feb 4, 2013, at 3:57 PM, George Fletcher <[email protected]
<mailto:[email protected]>>
wrote:
>
> On 2/4/13 3:41 PM, Richer, Justin P. wrote:
>> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
