Additional comments: 6. Section 4: 1) An attacker may generate a bogus tokens … [Kepeng] Change “tokens” to “token”. 2) A client may also re-use access tokens for some other resource servers. [Kepeng] Change “re-use” to “reuse”. The pragraph title says “reuse”. Also in other places. 3) To illustrate key confirmation the first examples borrow from Kerberos and use symmetric key cryptography. [Kepeng] Change “the first examples borrow” to “the first example is borrowed”. 7. Section 5.4 1) As a high level message, there are various ways how the threats can be mitigated and while the details of each solution is somewhat different they all ultimately accomplish the goal. [Kepeng] Change the last sentence to: the details of each solution are somewhat different even they all can ultimately accomplish the goal. 2) Depending on the chosen layer for providing client-side authentication there may be additional challenges due Web server load balancing, lack of API access to identity information, etc. [Kepeng] Change “due” to “due to”. 8. Section 6: [Kepeng] It will be better if we can divide this section into several sub-sections, e.g. each sub-section can be related to each figure. 9. Section 7: 1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we move this section ahead? 2) The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected. [Kepeng] What is “an unauthorized authorized”? Should it be “an unauthorized access”?
Kind Regards Kepeng 发件人: Li Kepeng <[email protected]> 日期: Saturday, 19 September, 2015 12:55 am 至: <[email protected]> 主题: [OAUTH-WG] Review comments to PoP Architecture Hello authors, Please find my review comments to PoP Architecture document: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 1. Introduction: At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token. [Kepeng] This sentences seem to be incomplete. What offers a security mechanism? Also why do we mention “at the time of writing”? Is the situation changed now? 2. Section 3: The main use case that motivates better-than-bearer token security is the desire of resource servers to obtain additional assurance that the client is indeed authorized to present an access token. [Kepeng] About “better-than-bear”, is it a word? Maybe reword the sentence a little bit. 3.Section 3.1 1) In a legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource servers to complete the requested operation. [Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit? 2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TLS connection. [Kepeng] Change “is conveyed” to “should be conveyed”? 4. Section 3.3: First, an eavesdropper may steal an access token and represent it at a different resource server. [Kepeng] Change “represent it at” to “present it to”? 5. Section 3.4: These load balancers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server. [Kepeng] Don’t understand “in the clear”. Should it be “in the wire”? Kind Regards Kepeng _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
