"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 <tony...@microsoft.com <mailto:tony...@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-boun...@ietf.org <mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@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-dra...@ietf.org <mailto:internet-dra...@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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to