[OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture

[Kathleen Moriarty <[e-mail]>]

Hello,

I reviewed draft-ietf-oauth-pop-architecture and have a few questions.

1. Section 6, Threat Mitigation:

Last sentence of first paragraph, "To
   simplify the subsequent description we assume that the token itself
   is digitally signed by the authorization server and therefore cannot
   be modified."

Since bearer tokens are not signed by default, is this proposing a
change?  If so, where will that change occur?  To state that "it is
assumed" without it being required anywhere is not a good assumption.
I'd still see this as a risk or security consideration.  When OAuth is
re-used by other protocols, I am seeing that re-use leave off basic
protections that should be assumed like TLS, let alone digital
signatures.  If this is required in the defined architecture (Section
7 - it does show this, but there are no MUSTs that I can find), just
state that and refer to the requirement.

2. Section 6, Threat Mitigation

Third paragraph, "As an example, TLS with a ciphersuite
   that offers confidentiality protection has to be applied (which is
   currently true for all ciphersuites, except for one).

Please list a reference so the reader knows which ciphersuites are
acceptable from the recommended ones in RFC7525.  I don't recall there
being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and
that we've discussed that already with previous drafts, so this should
be spelled out more).

3. (Nit) Section 6.2, add a comma to improve readability
From: "Instead of providing confidentiality protection the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"
To: "Instead of providing confidentiality protection, the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"

Thank you all for your work on this draft!
-- 

Best regards,
Kathleen