Thanks Kepeng for the review. I will respond next week. Cheers,
Phil > On Sep 19, 2015, at 09:02, Kepeng Li <[email protected]> wrote: > > 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
