I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

This document is well-written, clear (especially section 6 and 7) and ready to be published as information RFC. 
>From the OPS point of view, there is no specific comment as this document describes only a set of use cases motivating the need for PoP security mechanism and provides a set of requirements.

However, as an external reviewer, I have some comments, mainly for sake of clarity in the first part of the document. Up to the authors to take them into account before publication.

Section 3:

the text put in the introduction of the section 3 describes the primary use case. It could be put in a specific sub-section (e.g. 3.1), at the same level than the other scenarios

section 3.1:

the use case is not so clear. It is said that it could be legitimate for a resource server to re-use a received access token... and that it should be required to prevent such a re-use. Should it be concluded that both use cases should be supported by the foreseen solution?

Section 3.2:

What is described in the section is the need for an e2e security, that is also described in section 3.4. I think that there is no specific reason to have two separate use cases to motivate the e2e security requirements. They could be merged into one use case.

Section 3.3:

In the OAuth 2.0 Authorization Framework, the use of TLS is mandatory for access token exchange. If TLS is not used between the client and the resource server, we are out of scope of the OAuth 2.0 Authorization Framework, right? This should be clarified to avoid misinterpretation.

Moreover, it is explicitly said that "In such a case (i.e. no TLS) the bearer token approach is not possible".
Therefore, why is it concluded at the end that the "the security solution should work in such a scenario"?

Section 5 "Requirements"

I'm assuming that the solution for PoP will have to fulfil "at least" the list of the requirements defined by RFC4962. It is only an assumption as this not clearly stated at the beginning of the section whereas the title of the section is "Requirements".
Moreover it seems that some requirements are not part of the RFC4962. It could be good to highlight them. As it is, we have the impression that everything was defined by the RFC4962.

Minor comments:

Introduction:

   This document outlines additional use cases requiring stronger
   security protection in Section 3, identifies threats in Section 4,
   proposes different ways to mitigate those threats in Section 6,
   outlines an architecture for a solution that builds on top of the
   existing OAuth 2.0 framework in Section 7, and concludes with a
   requirements list in Section 5.

Either the "requirement list" is not in the right section or the high level description of the document is wrong as the section 5 cannot come after section 7 :)

Section 3.1:

   In a scenario where a resource server receives a valid access token,
   the resource server then re-uses it with other resource server.

either "with other resource servers" or " with another resource server"

Section 3.2:

   In this use case additional information should be conveyed to the
   resource server to ensure that no entity entity has tampered with the
   TLS/DTLS connection.

s/ that no entity entity/ that no entity 

Section 4:

      extend the validity period.  A client, which MAY be a normal
      client or MAY be assumed to be constrained (see [RFC7252]), may
      modify the token to have access to information that they should
      not be able to view.

s/ that they should/ that it should

Best Regards,

Lionel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.