1. Minor formatting issue: section 1.2, "authorization code" and "access grant" need a new line before the definition.
2. The new token_type parameter is required in responses from the server. If the server supports multiple formats, which one will be used? In this case, would it make sense to allow the client to request a specific format? 3. The new Client Assertion Credentials do make sense, but the name is creating confusion. Hard to distinguish from assertion profile. 4. Do we really need both basic auth and request parameters for Client Password Credentials (section 3.1). Can we move basic auth to an extension? 5. Section 4.1, second to last paragraph. The server is required to redirect to the client in case of bad request. Do we really want that? At that point the redirect_uri is just a guess. 6. Section 5, description of grant_type. It is stated that value is a URI for the assertion flow. But it is a URI for extensions as well. Maybe we should stick with "assertion" grant type and assertion_type, it gets ambiguous like this. 7. Section 7.2. What about applications using legacy parameters? Does not make much sense to register them, and they cannot be changed to x_. Broken record: using a prefix for all registered parameters is much cleaner. Marius On Tue, Nov 30, 2010 at 10:53 PM, Eran Hammer-Lahav <[email protected]> wrote: > I didn't get to finish the editorial changes I want to make so I pushed the > incomplete but stable draft out as -11. This includes all the normative > language changes the group agreed on, as well as all the feedback I had for > -10. The remaining editorial work should not change any implementation > details. It will just impact the document organization. > > Changes in -11 include: > > -11 > > o Many editorial changes. Fixed user authorization section > structure. Removed unused normative references. Adjusted > language regarding single use of authorization codes. > > o Fixed header ABNF. > > o Change access token description from shared symmetric secret to > password. > > o Moved access grant 'none' to a separate section, renamed to > 'client_credentials'. > > o Demoted the HTTP status code requirement from MUST to SHOULD in > protected resource response error. > > o Removed 'expired_token' error code. > > o Moved all the 'code_and_token' parameter to the fragment (from > code being in the query). > > o Removed 'assertion_type' parameter (moved to 'grant_type'). > > o Added note about redirecting to invalid redirection URIs (open > redirectors). > > o Removed bearer token section, added new required 'token_type' > parameter with extensibility. > > o 'error-uri' parameter value changed to absolute URI. > > o OAuth 2.0 HTTP authentication scheme name changed to 'OAuth2'. > > o Dropped the 'WWW-Authenticate' header field 'realm' parameter. > > o Removed definition of access token characters. > > o Added instructions for dealing with error and an invalid > redirection URI. > > Please provide feedback and review the document fully, even with the pending > editorial changes. IOW, please consider this document the final draft (pre-WG > last call) for all normative/implementation language. > > EHL > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
