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

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