Re: [OAUTH-WG] draft-ietf-oauth-revocation

Justin Richer <jricher@mitre.org> Tue, 05 February 2013 19:49 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B477621F8614; Tue, 5 Feb 2013 11:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level:
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqjcQgYk6jhT; Tue, 5 Feb 2013 11:49:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 96AD621F85D4; Tue, 5 Feb 2013 11:49:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D9A581F113E; Tue, 5 Feb 2013 14:49:49 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E0C10531136A; Tue, 5 Feb 2013 14:49:48 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 5 Feb 2013 14:49:48 -0500
Message-ID: <51116239.7030104@mitre.org>
Date: Tue, 5 Feb 2013 14:49:13 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <510E5FB5.10803@lodderstedt.net> <B33BFB58CCC8BE4998958016839DE27E06886427@IMCMBX01.MITRE.ORG> <511020D3.1090201@aol.com> <B33BFB58CCC8BE4998958016839DE27E068865E3@IMCMBX01.MITRE.ORG> <OF2060C435.DEAE300A-ON85257B09.005BEF8B-85257B09.005C2559@us.ibm.com> <2DC4D4CA-C65F-4B7D-96E3-A811B303B15A@lodderstedt.net>
In-Reply-To: <2DC4D4CA-C65F-4B7D-96E3-A811B303B15A@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------070205040608040806020508"
X-Originating-IP: [129.83.31.58]
Cc: OAuth WG <oauth@ietf.org>, "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2013 19:49:51 -0000

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 <lainhart@us.ibm.com 
> <mailto:lainhart@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)
>> lainhart@us.ibm.com <mailto:lainhart@us.ibm.com>*
>>
>>
>>
>>
>>
>>
>> From: "Richer, Justin P." <jricher@mitre.org <mailto:jricher@mitre.org>>
>> To: George Fletcher <gffletch@aol.com <mailto:gffletch@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-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> On Feb 4, 2013, at 3:57 PM, George Fletcher <gffletch@aol.com 
>> <mailto:gffletch@aol.com>>
>> wrote:
>>
>> >
>> > On 2/4/13 3:41 PM, Richer, Justin P. wrote:
>> >> On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt 
>> <torsten@lodderstedt.net <mailto:torsten@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