I'm fine with this solution as well. --George
On 2/5/13 3:45 PM, Torsten Lodderstedt wrote:
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
<mailto: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
<mailto: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 <mailto:lainh...@us.ibm.com>*
From: "Richer, Justin P." <jric...@mitre.org
<mailto:jric...@mitre.org>>
To: George Fletcher <gffle...@aol.com <mailto:gffle...@aol.com>>,
Cc: OAuth WG <oauth@ietf.org <mailto:oauth@ietf.org>>
Date: 02/04/2013 04:10 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
------------------------------------------------------------------------
On Feb 4, 2013, at 3:57 PM, George Fletcher <gffle...@aol.com
<mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
