A few small corrections: - section "1.3. Overview": "exchange that access grant" => "exchange the access grant" ?
- section "1.4.2. User-Agent", step (C) and also section "3.1. Authorization Server Response": the authorization code is optionally returned in the user_agent profile, but it is not clear when this is done; even if an authz server issues these codes with User-Agent I don't think it will be done on every single request, an extra request parameter may be needed to ask for a code (I think the original request for this feature did specify such a parameter) - section "1.4.3. Native Application": "incapable of receiving callback requests from the server", in most cases this is not true, native apps can specify a callback URL (custom scheme, locally running web server, local HTML file, helper web app) - section "4. Obtaining an Access Token": "The token endpoint URI MAY include a query component, which must be retained when adding additional query parameters.", in this case there is no need to add any query parameters, the request is executed as a POST. Thanks, Marius On Mon, Jun 14, 2010 at 7:06 PM, Eran Hammer-Lahav <[email protected]> wrote: > This is the second half of the big rewrite. I changed the entire introduction > to better explain the new model, as well as cleaned up the rest of the new > work. This is still not a smooth specification, but I think the general > structure is starting to come through. I feel much better about the current > story line, even if it has many holes in it. > > My focus now is on adding in extensibility. > > The spec is now 33 pages! > > -08 > > o Renamed verification code to authorization code. > o Revised terminology, structured section, added new terms. > o Changed flows to profiles and moved to introduction. > o Added support for access token rescoping. > o Cleaned up client credentials section. > o New introduction overview. > o Added error code for invalid username and password, and renamed error > code to be more consistent. > o Added access grant type parameter to token endpoint. > > EHL > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of [email protected] >> Sent: Monday, June 14, 2010 7:00 PM >> To: [email protected] >> Cc: [email protected] >> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Open Authentication Protocol Working Group >> of the IETF. >> >> >> Title : The OAuth 2.0 Protocol >> Author(s) : E. Hammer-Lahav, et al. >> Filename : draft-ietf-oauth-v2-08.txt >> Pages : 33 >> Date : 2010-06-14 >> >> This specification describes the OAuth 2.0 protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-08.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the Internet- >> Draft. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
