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

Todd W Lainhart <lainhart@us.ibm.com> Tue, 05 February 2013 21:40 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 6542F21F892E for <oauth@ietfa.amsl.com>; Tue, 5 Feb 2013 13:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.52
X-Spam-Level:
X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 iUQa1v2PKMuS for <oauth@ietfa.amsl.com>; Tue, 5 Feb 2013 13:40:00 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id E01FB21F8915 for <oauth@ietf.org>; Tue, 5 Feb 2013 13:39:58 -0800 (PST)
Received: from /spool/local by e8.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 16:39:57 -0500
Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 5 Feb 2013 16:39:55 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3969F38C8021; Tue, 5 Feb 2013 16:39:55 -0500 (EST)
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r15LdsIb275304; Tue, 5 Feb 2013 16:39:54 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r15LdsnE004472; Tue, 5 Feb 2013 16:39:54 -0500
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r15Ldsv4004454; Tue, 5 Feb 2013 16:39:54 -0500
In-Reply-To: <51117B0D.7040703@aol.com>
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> <51116239.7030104@mitre.org> <D67A78CC-31FB-4E5E-A9C0-BD8951742E90@lodderstedt.net> <51117B0D.7040703@aol.com>
To: George Fletcher <gffletch@aol.com>
MIME-Version: 1.0
X-KeepSent: F051EEAA:E9A53F64-85257B09:0076FEB6; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: <OFF051EEAA.E9A53F64-ON85257B09.0076FEB6-85257B09.007701D9@us.ibm.com>
From: Todd W Lainhart <lainhart@us.ibm.com>
Date: Tue, 5 Feb 2013 16:39:52 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/05/2013 16:39:54, Serialize complete at 02/05/2013 16:39:54
Content-Type: multipart/alternative; boundary="=_alternative 007701D885257B09_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020521-9360-0000-0000-000010329CCC
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 21:40:01 -0000

+1





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:   George Fletcher <gffletch@aol.com>
To:     Torsten Lodderstedt <torsten@lodderstedt.net>et>, 
Cc:     "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>rg>, OAuth WG 
<oauth@ietf.org>
Date:   02/05/2013 04:35 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        oauth-bounces@ietf.org



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 <jricher@mitre.org>rg>:

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>om>:

> 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>om>, 
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


_______________________________________________
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