1. Introduction: Adding the word "directly" after "rather than using the resource owner's credentials".
1.3. Overview: Comment on first sentence: "OAuth also supports having a client directly provide its own credentials to get an access token. It would seem useful to refer to this as well less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0." 1.3. Overview, paragraph 3: Commented on "The following steps are specified within this document": "Actually you also specify the token type returned in step D. I think this is worth explicitly calling out." 2. Authenticated Requests: Commented "It would seem appropriate to begin with an example of step D showing that the returned access token is of type bearer." 2.3. URI Query Parameter: Commented on second example: "Does order matter? In this case the access_token is last. Is that because it has to be or because order is irrelevant?" 2.4. The WWW-Authenticate Response Header Field: Commented on word "invalid": "The term invalid is a tricky one. Invalid can mean 'not supported' or 'not recognized' but that is generally taken to be a 400 Bad Request and would not require a www-authenticate response header field. Or invalid can mean 'supported but not the right credentials' in which case the error is a 401 Unauthorized and a www-authenticate response is required. I would urge you to consider simplifying this text by just stating (without preamble) that if a www-authenticate response header is returned (either from a 401 Unauthorized or other reasons) then support for the Bearer token type is specified as given below." 2.4. The WWW-Authenticate Response Header Field: Commented on "param" definition: "As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-15#section-4.4, www-authenticate is not really an error response mechanism. It's an advertisement mechanism. It says "here is what I support by way of authentication." So I really don't think it's appropriate to show horn in here error information that has nothing to do with advertising authorization capabilities. If we need to return things like error, error-desc, etc. that should either be stuck in the body or put in a separate header. We should leave the www-authenticate header to be as simple as possible." 3.1. Security Threats: Token redirect: Change "An attacker uses the token generated for consumption by resource server to obtain access to another resource server" to "An attacker uses the token generated for consumption by a particular resource server with a different resource server that mistakenly believes the token to be for it". 3.1 Security Threads: Token replay: Change "replay" to "capture" and change "An attacker attempts to use a token that has already been used with that resource server in the past" to "An attacker somehow obtains a token they were not authorized to possess and uses it to access protected resources". 3.2 Threat Mitigation: Add at end of first paragraph: "The mechanics of such an interaction are not defined by this specification." 3.2. Threat Mitigation: Delete "and replay" from paragraph 5. 3.2. Threat Mitigation: Change "has to be" to "MUST". 3.2. Threat Mitigation: Comment on "leaked" in paragraph 5: "Significantly? Really? In what way? Give me a token for a few hundred milliseconds and I can probably do all the damage I could do if you gave it to me for a few days. I would suggest removing the term significantly." 3.3. Summary of Recommendations: Validate SSL certificate chains: Change "must" to "MUST". 3.3. Summary of Recommendations: Always use TLS (https): Add "or equivalent transport security" after TLS reference. 3.3. Summary of Recommendations: Don't store bearer tokens in cookies: Add sentence at end: "Implementations that do store bearer tokens in cookies MUST take precautions against cross site request forgery." 3.3. Summary of Recommendations: Comment on "Don't pass bearer tokens in page URLs": "It seems like this should also be mentioned in section 3.2." Appendix A. Acknowledgements: Change "Yaron Goland" to "Yaron Y. Goland".
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
