I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

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

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-oauth-spop-11
Reviewer: Alexey Melnikov
Review Date: 2015-06-09
IETF LC End Date: 2015-06-01
IESG Telechat date: 2015-06-11

Summary: Almost Ready


Major Concerns:



What is the justification for having the "plain" verifier? If one is 


intercepted by a malicious application, your extension becomes pointless.





Minor Concerns:

Is code_challenge_method missing in 4.5?



Sections 7.1 and 7.3 are talking about the same thing? Should they be 


merged into one? If they are not talking about the same thing, should 


they be named differently?





Nits:


4.2.  Client creates the code challenge

   The client then creates a code challenge, "code_challenge", derived
   from the "code_verifier" by using one of the following
   transformations on the "code_verifier":

   plain  "code_challenge" = "code_verifier"
   S256  "code_challenge" = BASE64URL-

      ENCODE(SHA256(ASCII("code_verifier")))
   It is RECOMMENDED to use the S256 transformation when possible.
   ABNF for "code_challenge" is as follows.

   code-challenge = 43*128unreserved
   unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
   ALPHA = %x41-5A / %x61-7A
   DIGIT = %x30-39

SHA-256 requires a normative reference.