But what is the same terminology? Authorization grant? I think 1.3 defines the authorization grant as an external representation of the authorization, not the authorization itself.
Am 07.01.2013 um 21:12 schrieb Mike Jones <michael.jo...@microsoft.com>: > +1 for using the same terminology as OAuth Core and Bearer > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Justin Richer > Sent: Monday, January 07, 2013 11:36 AM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-04.txt > > "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>: > > 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] On Behalf Of > Torsten Lodderstedt > Sent: Monday, January 7, 2013 4:08 AM > To: 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: > > 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 > > > > > > > _______________________________________________ > 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
