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

Todd W Lainhart <lainhart@us.ibm.com> Tue, 05 February 2013 17:46 UTC

Return-Path: <lainhart@us.ibm.com>
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 BDC8221F86A2 for <oauth@ietfa.amsl.com>; Tue, 5 Feb 2013 09:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.51
X-Spam-Level:
X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 42755VFzjR7I for <oauth@ietfa.amsl.com>; Tue, 5 Feb 2013 09:46:03 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id B4B1121F8630 for <oauth@ietf.org>; Tue, 5 Feb 2013 09:46:02 -0800 (PST)
Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <oauth@ietf.org> from <lainhart@us.ibm.com>; Tue, 5 Feb 2013 12:42:15 -0500
Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e4.ny.us.ibm.com (192.168.1.104) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 5 Feb 2013 12:42:01 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 181EA38C90A7; Tue, 5 Feb 2013 11:47:22 -0500 (EST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r15GlL7w276780; Tue, 5 Feb 2013 11:47:21 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r15GlHKl026431; Tue, 5 Feb 2013 14:47:19 -0200
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r15GkoVd022195; Tue, 5 Feb 2013 14:46:53 -0200
In-Reply-To: <B33BFB58CCC8BE4998958016839DE27E068865E3@IMCMBX01.MITRE.ORG>
References: <510E5FB5.10803@lodderstedt.net> <B33BFB58CCC8BE4998958016839DE27E06886427@IMCMBX01.MITRE.ORG> <511020D3.1090201@aol.com> <B33BFB58CCC8BE4998958016839DE27E068865E3@IMCMBX01.MITRE.ORG>
To: "Richer, Justin P." <jricher@mitre.org>
MIME-Version: 1.0
X-KeepSent: 2060C435:DEAE300A-85257B09:005BEF8B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: <OF2060C435.DEAE300A-ON85257B09.005BEF8B-85257B09.005C2559@us.ibm.com>
From: Todd W Lainhart <lainhart@us.ibm.com>
Date: Tue, 5 Feb 2013 11:46:28 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/05/2013 11:46:53, Serialize complete at 02/05/2013 11:46:53
Content-Type: multipart/alternative; boundary="=_alternative 005C255885257B09_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020517-3534-0000-0000-000015046733
Cc: OAuth WG <oauth@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 17:46:03 -0000

> 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




From:   "Richer, Justin P." <jricher@mitre.org>
To:     George Fletcher <gffletch@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-bounces@ietf.org




On Feb 4, 2013, at 3:57 PM, George Fletcher <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> 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