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. Summary: This document is ready, with very minor issues. It does not appear to introduce new management/manageability considerations. This document describes a challenge-response mechanism to protect against an OAuth authorization code being intercepted by an attacker, when that authorization code is sent in the clear. The authorization code is used to acquire an access token and must be protected. This attack (an attacker using an intercepted authz code to acquire an access token) has been observed in the wild. We are astonished to learn that OAuth is being run over an unencrypted channel. However, given that it is, this is a reasonable defense mechanism. Questions: Why is S256 RECOMMENDED and not a MUST? Nits: ASCII(STRING) does not appear to be used in the protocol grammar? Melinda