A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:
Abstract: Currently it is: The OAuth 2.0 authorization protocol enables granting third-party applications limited access to HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. This sentence is confusing as to whom is doing the orchestrating. It is an important OAuth feature that the 3rd-party app does this. Also add "an" before "HTTP service". The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service. 2.1 Authorization Endpoints ...when sending requests to the token endpoints should be ...when sending requests to the authorization endpoint 7.1 Access Token Types I suggest adding the following sentence to the end of the 1st paragraph, just to be sure a security value is not used in the wrong protocol. A client MUST NOT use an access token if it does not understand the token type. 7.1 Access Token Types Use a different access token for the Bearer and MAC examples to avoid any implication that a given token can be used with either method at the client's discretion. Perhaps make the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn't match the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw 7.1 Access Token Types The timestamp value in the MAC example corresponds to a date in 1974! -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
