Re: [OAUTH-WG] Review comments to PoP Architecture

Thanks Kepeng for the review. I will respond next week. 

Cheers,

Phil

> On Sep 19, 2015, at 09:02, Kepeng Li <kepeng.lkp@alibaba-inc.com> 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 <kepeng.lkp@alibaba-inc.com>
> 日期: Saturday, 19 September, 2015 12:55 am
> 至: <oauth@ietf.org>
> 主题: [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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth