[Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

["Matt Miller (mamille2)" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-oauth-pop-architecture-07
Reviewer: Matthew A. Miller
Review Date: 2015-12-16
IETF LC End Date: 2015-12-15
IESG Telechat date: 2015-12-17

Summary: Almost ready.

I have several editorial nits, but also a couple of minor concerns that
I think would improve this document's readability.

I note that idnits complained about the lack of RFC 2119 boilerplate;
however, I think the text actually used in this document is most
appropriate and still conveys the intent.  The idnits also complained
about a reference to an obsolete RFC 5849; however, this reference
appears to be intentional and necessary.

-----

Major issues:

Nnne.

Minor issues:

1. In Section 1. Introduction, the last paragraph makes it seem the
document isn't organized properly.  It implies an order to read the
document that is not reflected in the outline:

 * Section 1
 * Section 2
 * Section 3
 * Section 4
 * Section 6
 * Section 7
 * Section 5

Simply re-ording the document I think causes bigger problems.  While
the intro hints at the order to read, it makes more sense to me in
the order it actually is.  Ultimately, for me the problem arises with
the word "concludes".  It might simply be enough to change the last
participle from ", and concludes with a requirements list in Section 5."
to ", and lists requirements in Section 5."

2. In several places, terms of art are used that have not been defined
in this document: "resource server", "protected resource", etc.  I
think it would help if Section 2. indicated where these terms are
defined or discussed, which is RFC 6749.


Nits/editorial comments:

* The reference to draft-ietf-oauth-proof-of-possession-08 should be
updated to its latest version, although I expect RFC Editor will
resolve this before publication.

* The reference to RFC 4347 should be updated to 6347; there's no clear
requirement for the older document.

* In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
"with other resource server" should be either "with another resource
server" or "with other resource servers".

* In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
should be "entity".

* In section 3.4 Offering Application Layer End-to-End Security, The
last sentence of the last paragraph seems out of place.  It seems it
would be better as the penultimate sentence of the previous paragraph.

* In section 4. Security and Privacy Threats under "Token
manufacture/modification", "causing resource server" should be "causing
the resource server".

* Also in Section 4. Security and Privacy Threats under "Token
manufacture/modification", the normative language here seems out of
place.  It seems to me that 'may' conveys just as much as 'MAY' for
how it is used here.

* In Section 5. Requirements under "Prevent the Domino Effect",
"Resource Server" is capitalized differently than all previous uses,
but it doesn't seem to be a different use.  I suggest changing it to
"resource server".

* In Section 6.3. Key Confirmation, uses the term "privacy key" where
I believe the common nomenclature is "private key".

* In Section 7. Client and Authorization Server Interaction, I find
most of the figures a little hard to follow.  While I appreciate the
attempt to go beyond strict perpendicularity, I find it distracting
from the information it is trying to convey.

* In Section 7.1 Symmetric Keys, I think the "three ways for
communicating this session key" would benefit having bullets or
outline numbers.

* In Section 10. Acknowledgements, the second paragraph discusses an
appendix that borrows content from another document, but there is no
appendix in this draft.  Is this text still relevant?


--
- m&m

Matt Miller
Cisco Systems, Inc.