Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
Peter Mauritius <peter.mauritius@fun.de> Thu, 10 January 2013 21:37 UTC
Return-Path: <peter.mauritius@fun.de>
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 629EB21F85EA for <oauth@ietfa.amsl.com>; Thu, 10 Jan 2013 13:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 GXW8l9jwIJjw for <oauth@ietfa.amsl.com>; Thu, 10 Jan 2013 13:37:19 -0800 (PST)
Received: from mailfwd.fun.de (fungate2.fun.de [IPv6:2a01:198:3c6:1:81:26:162:57]) by ietfa.amsl.com (Postfix) with ESMTP id BBB3E21F85D7 for <oauth@ietf.org>; Thu, 10 Jan 2013 13:37:15 -0800 (PST)
Received: from hsi-kbw-109-193-164-118.hsi7.kabel-badenwuerttemberg.de ([109.193.164.118] helo=funmiraus.local) by mailfwd.fun.de with esmtpsa (Exim 4.69 #1 (Debian)) id 1TtPoE-0006Ts-9d; Thu, 10 Jan 2013 22:37:10 +0100
Message-ID: <50EF348B.4080104@fun.de>
Date: Thu, 10 Jan 2013 22:37:15 +0100
From: Peter Mauritius <peter.mauritius@fun.de>
Organization: fun communications GmbH, Karlsruhe, Germany
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0a2
MIME-Version: 1.0
To: George Fletcher <gffletch@aol.com>
References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <50EAF409.80704@aol.com> <50EAF568.8000201@lodderstedt.net> <50EAF6F2.90407@aol.com> <50EC988E.7070007@fun.de> <50ED6BBB.40008@aol.com> <50ED71D9.5080703@fun.de> <50ED8F85.5000604@aol.com>
In-Reply-To: <50ED8F85.5000604@aol.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010101050705010407030501"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
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: Thu, 10 Jan 2013 21:37:21 -0000
Hi George, I am with you and support your suggestion. An "invalid_parameter" error code would be a practical solution that would allow to distinguish between token usage and token as parameter. Regards Peter Am 09.01.13 16:40, schrieb George Fletcher: > While this can work, it seems like it's mixing semantics a little as > well. 'invalid_request' normally mean that the request is malformed in > some way. Even 'unsupported parameter value' is really addressing a > malformed request (e.g. a parameter only allows values of 'true' and > 'false' and the invocation uses the value 'maybe'). > > What about registering an error code of 'invalid_parameter_value'. > Then the description could explain which parameter value is invalid > and possibly why. We might even be able to shorten this to > 'invalid_parameter' as 'invalid_request' handles the case of an > unsupported/invalid parameter name. > > I did a quick check of the OpenID Connect specs and they also don't > define an 'invalid_parameter' error code. > > Thanks, > George > > On 1/9/13 8:34 AM, Peter Mauritius wrote: >> Ok, >> >> now I understand your intention. In oauth-revocation the token is >> just a parameter not an authorization token as in RFC6750. RFC6749 >> uses "invalid_request" for >>> includes an unsupported parameter value >> Perhaps we should drop the error-code and use invalid-request with a >> error-description explaining the token parameter is not usable. >> >> Regards >> Peter >> >> On 09.01.2013 14:08, George Fletcher wrote: >>> Hi Peter, >>> >>> I do agree that the meanings of 'invalid_token' between the two >>> specs (6750 and revocation) are different. After thinking about this >>> for a while, I've determined, at least for myself, what the >>> difference is between the 'invalid_token' error code in RFC 6750 and >>> the revocation spec. >>> >>> In RFC 6750 'invalid_token' means that the authorization token for >>> the request is invalid. >>> >>> In 'oauth-revocation', 'invalid_token' means that the parameter >>> containing the token to be revoked is invalid. >>> >>> I am very concerned about using the same error string, >>> 'invalid_token', to mean two different things. While the semantic >>> difference is not great in this case, I think it sets a bad >>> precedent for OAuth to have the same error string have two different >>> semantic meanings. >>> >>> I do agree that the error code used in this spec should be registered. >>> >>> Thanks, >>> George >>> >>> On 1/8/13 5:07 PM, Peter Mauritius wrote: >>>> Hi George, >>>> >>>> RFC6750 defines "invalid-token" for access tokens which is not the >>>> case for "invalid-token" in the revocation specification. Here it >>>> is applicable for refresh tokens as well. Therefore we should not >>>> simply reference the "invalid-token" of RFC6750. >>>> >>>> As far as I understand both, the reviewed specification and >>>> RFC6750, reference RFC6749. RFC6750 includes in section 6.1 >>>> <http://tools.ietf.org/html/rfc6750#section-6.2> OAuth Extensions >>>> Error Registration sections according to RFC6749 section 11.4. >>>> <http://tools.ietf.org/html/rfc6749#section-11.4> for the error >>>> codes defined throughout the document including "invalid-token". >>>> >>>> I am not very experienced in the formal process but shouldn't we >>>> add such sections for the two error codes defined in the revocation >>>> document? Especially for "invalid-token" we should define an error >>>> registration section that defines the error code for our error >>>> usage location and protocol extension to distinguish it from >>>> RFC6750 and to avoid confusion. Doing this I hope there is no >>>> necessity to add a reference to RFC6750 or to define a new error code. >>>> >>>> What do the more experienced reviewers think? >>>> >>>> Regards >>>> Peter >>>> >>>> Am 07.01.13 17:25, schrieb George Fletcher: >>>>> My concern with leaving both specs separated is that over time the >>>>> semantics of the two error codes could diverge and that would be >>>>> confusing for developers. If we don't want to create a dependency >>>>> on RFC 6750, then I would recommend a change to the error code >>>>> name so that there is no name collision or confusion. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 1/7/13 11:18 AM, Torsten Lodderstedt wrote: >>>>>> Hi George, >>>>>> >>>>>> thank you for pointing this out. Your proposal sounds reasonable >>>>>> although the revocation spec does not build on top of RFC 6750. >>>>>> >>>>>> As refering to RFC 6750 would create a new dependency, one could >>>>>> also argue it would be more robust to leave both specs separated. >>>>>> >>>>>> What do others think? >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> Am 07.01.2013 17:12, schrieb George Fletcher: >>>>>>> One quick comment... >>>>>>> >>>>>>> Section 2.0: Both RFC 6750 and this specification define the >>>>>>> 'invalid_token' error code. >>>>>>> >>>>>>> Should this spec reference the error code from RFC 6750? >>>>>>> >>>>>>> Thanks, >>>>>>> George >>>>>>> >>>>>>> >>>>>>> On 1/7/13 7:08 AM, Torsten Lodderstedt wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the new revision is based on the WGLC feedback and incorporates >>>>>>>> the following changes: >>>>>>>> >>>>>>>> - renamed "access grant" to "authorization" and reworded parts >>>>>>>> of Abstract and Intro in order to better align with core spec >>>>>>>> wording (feedback by Amanda) >>>>>>>> - improved formatting of section 2.1. (feedback by Amanda) >>>>>>>> - improved wording of last paragraph of section 6 (feedback by >>>>>>>> Amanda) >>>>>>>> - relaxed the expected behavior regarding revocation of related >>>>>>>> tokens and the authorization itself in order to remove >>>>>>>> unintended constraints on implementations (feedback by Mark) >>>>>>>> - replaced description of error handling by pointer to >>>>>>>> respective section of core spec (as proposed by Peter) >>>>>>>> - adopted proposed text for implementation note (as proposed by >>>>>>>> Hannes) >>>>>>>> >>>>>>>> regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> Am 07.01.2013 13:00, schrieb internet-drafts@ietf.org: >>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>> Internet-Drafts directories. >>>>>>>>> This draft is a work item of the Web Authorization Protocol >>>>>>>>> Working Group of the IETF. >>>>>>>>> >>>>>>>>> Title : Token Revocation >>>>>>>>> Author(s) : Torsten Lodderstedt >>>>>>>>> Stefanie Dronia >>>>>>>>> Marius Scurtescu >>>>>>>>> Filename : draft-ietf-oauth-revocation-04.txt >>>>>>>>> Pages : 8 >>>>>>>>> Date : 2013-01-07 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> This document proposes an additional endpoint for OAuth >>>>>>>>> authorization >>>>>>>>> servers, which allows clients to notify the authorization >>>>>>>>> server that >>>>>>>>> a previously obtained refresh or access token is no longer >>>>>>>>> needed. >>>>>>>>> This allows the authorization server to cleanup security >>>>>>>>> credentials. >>>>>>>>> A revocation request will invalidate the actual token and, if >>>>>>>>> applicable, other tokens based on the same authorization. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 >>>>>>>>> >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-04 >>>>>>>>> >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Peter Mauritius Chief Technical Director >>>> Senior Consultant >>>> Tel: +49 721 96448-0 Fax: +49 721 96448-299peter.mauritius@fun.de >>>> >>>> fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe >>>> Geschaeftsfuehrer Johannes Feulner >>>> Amtsgericht Mannheim HRB 106906 >>>> >>>> http://www.fun.de >>>> http://blogs.fun.de >>>> http://www.twitter.com/fun_de >>>> http://www.facebook.com/funcommunications >>> > > -- > George Fletcher <http://connect.me/gffletch> -- Peter Mauritius Chief Technical Director Senior Consultant Tel: +49 721 96448-0 Fax: +49 721 96448-299 peter.mauritius@fun.de fun communications GmbH Lorenzstr. 29 D-76135 Karlsruhe Geschaeftsfuehrer Johannes Feulner Amtsgericht Mannheim HRB 106906 http://www.fun.de http://blogs.fun.de http://www.twitter.com/fun_de http://www.facebook.com/funcommunications
- [OAUTH-WG] I-D Action: draft-ietf-oauth-revocatio… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… George Fletcher
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Anthony Nadalin
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Justin Richer
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Mike Jones
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Peter Mauritius
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… George Fletcher
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Peter Mauritius
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… George Fletcher
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revoc… Peter Mauritius