Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt

Justin Richer <jricher@mitre.org> Mon, 07 January 2013 19:36 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 692A621F89E9 for <oauth@ietfa.amsl.com>; Mon, 7 Jan 2013 11:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.273
X-Spam-Level:
X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Ljn8izwO2WuU for <oauth@ietfa.amsl.com>; Mon, 7 Jan 2013 11:36:06 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48721F8481 for <oauth@ietf.org>; Mon, 7 Jan 2013 11:36:05 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F126C1F30F3; Mon, 7 Jan 2013 14:36:04 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D7AD55310949; Mon, 7 Jan 2013 14:36:04 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 7 Jan 2013 14:36:04 -0500
Message-ID: <50EB239F.2060309@mitre.org>
Date: Mon, 07 Jan 2013 14:35:59 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <20130107120057.29202.70722.idtracker@ietfa.amsl.com> <50EABAB0.4060807@lodderstedt.net> <8741efb85dbb4245a9c9584616d54cda@BY2PR03MB041.namprd03.prod.outlook.com> <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net>
In-Reply-To: <6F55059F-70CD-480D-9B0F-829E9C0A60CD@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------040809000102090901060903"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <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: Mon, 07 Jan 2013 19:36:07 -0000

"Access grant" was the old term that Eran came up with, and it has been 
replaced by "authorization grant", which I agree is also not as well 
defined as it could be. Both of these refer to the conceptual act of the 
resource owner saying "it is OK for this client to do these things". I 
objected to the language calling it a "credential", since that's 
misleading and has led to several developers I've run into thinking that 
it was the same thing as the access code, which it's not.

To best align the terminology, "authorization grant" as defined in 1.3 
is probably the best bet.

  -- Justin

On 01/07/2013 02:24 PM, Torsten Lodderstedt wrote:
> Access grant might be the better term. That's why previous revisions 
> used it. But as Amanda correctly pointed out, the core spec does not 
> define a concept of an access grant. There is just the term 
> authorization implicitly introduced via other definitions.
>
> section 1.3 introduces authorization grants:
> "An authorization grant is a credential representing the resource
>     owner's authorization (to access its protected resources) used by the
>     client to obtain an access token."
>
> and section 1.4 defines access tokens as follows:
> "An
>     access token is a string representing an authorization issued to the
>     client.  The string is usually opaque to the client."
>
> I tried to align the draft with this terminology.
>
> Am 07.01.2013 um 18:21 schrieb Anthony Nadalin <tonynad@microsoft.com 
> <mailto:tonynad@microsoft.com>>:
>
>> Is "authorization" the best  choice here over "access grant" since 
>> it's really not authorization that is being revoked it's the grant
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> 
>> [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
>> Sent: Monday, January 7, 2013 4:08 AM
>> To: oauth@ietf.org <mailto:oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt
>>
>> 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 
>> <mailto: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 <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
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth