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

Todd W Lainhart <lainhart@us.ibm.com> Mon, 04 February 2013 21:20 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 2BF8B21F8B11 for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.49
X-Spam-Level:
X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.108, 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 FnNeX3nQeREO for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2013 13:20:29 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2519621F8B0B for <oauth@ietf.org>; Mon, 4 Feb 2013 13:20:28 -0800 (PST)
Received: from /spool/local by e9.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>; Mon, 4 Feb 2013 16:20:28 -0500
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 4 Feb 2013 16:20:25 -0500
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id CD99DC9003C; Mon, 4 Feb 2013 16:20:24 -0500 (EST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r14LKOaC303270; Mon, 4 Feb 2013 16:20:24 -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 r14LKOeU012278; Mon, 4 Feb 2013 19:20:24 -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 r14LKOrd012274; Mon, 4 Feb 2013 19:20:24 -0200
In-Reply-To: <B33BFB58CCC8BE4998958016839DE27E06886427@IMCMBX01.MITRE.ORG>
References: <510E5FB5.10803@lodderstedt.net> <B33BFB58CCC8BE4998958016839DE27E06886427@IMCMBX01.MITRE.ORG>
To: "Richer, Justin P." <jricher@mitre.org>
MIME-Version: 1.0
X-KeepSent: 6BFF989E:BA988CD3-85257B08:0071ED60; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP2 SHF22 July 19, 2012
Message-ID: <OF6BFF989E.BA988CD3-ON85257B08.0071ED60-85257B08.00753859@us.ibm.com>
From: Todd W Lainhart <lainhart@us.ibm.com>
Date: Mon, 4 Feb 2013 16:20:21 -0500
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF4|December 14, 2012) at 02/04/2013 16:20:24, Serialize complete at 02/04/2013 16:20:24
Content-Type: multipart/alternative; boundary="=_alternative 0075385985257B08_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13020421-7182-0000-0000-000004EE5EAD
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: Mon, 04 Feb 2013 21:20:30 -0000

> Only if it's optional, and informational from the client's behalf. Would 
you define "access" and "refresh" values here, with a means for other 
specs (like OIDC) to put in their own values (like "id_token")?

I'd also like to see token_type explicitly called out, as we've also 
extended the spec for a token type.  Arguably the type could be encoded in 
the token itself, but it seems better to not require this of the 
implementation.

That said, the introspection endpoint doesn't disambiguate the incoming 
token via a token_type parameter.  Is there any reason to believe that it 
wouldn't see the same types of tokens that revocation would?





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:     Torsten Lodderstedt <torsten@lodderstedt.net>, 
Cc:     OAuth WG <oauth@ietf.org>
Date:   02/04/2013 03:42 PM
Subject:        Re: [OAUTH-WG] draft-ietf-oauth-revocation
Sent by:        oauth-bounces@ietf.org




On Feb 3, 2013, at 8:01 AM, Torsten Lodderstedt <torsten@lodderstedt.net> 
wrote:

> Hi all,
> 
> before I publish a new revision of the draft, I would like to sort out 
the following issues and would like to ask you for your feedback.
> 
> - Authorization vs. access grant vs. authorization grant: I propose to 
use "authorization grant".

+1 to authorization grant

> - 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).

> - Donald F. Coffin raised the need for a token_type parameter to the 
revocation request. Shall we re-consider this topic?
> 

Only if it's optional, and informational from the client's behalf. Would 
you define "access" and "refresh" values here, with a means for other 
specs (like OIDC) to put in their own values (like "id_token")?

 -- Justin

> best regards,
> Torsten.
> _______________________________________________
> 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