[OAUTH-WG] Misplaced Resource Owner in PKCE

[Brian Campbell <[e-mail]>]

In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization
request going to the "Resource Owner" and goes on to say that 'the resource
owner responds as usual, but records "t(code_verifier)" and the
transformation method.' That's not what the resource owner does.

I know the protocol flow in RFC 6749 tries to have authorization grants be
these abstract things that sorta come from the resource owner but, in the
context of the the authorization request and authorization code grant type,
it really doesn't work like that. The content in §1.1 seems, at best, to be
 more abstract and complicated than it needs to be and is bordering on
being just kinda wrong.

The RO and AS boxes should probably be consolidated into just the AS. The
RO could be omitted from the diagram, I think. Or stick it over with the
client, if you really want it in there, and have it authenticating and
approving authorization though an interaction with the AS. Or something
like that...



[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1

1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>.
Protocol Flow

       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     |   Resource    |
       |        |                                  |     Owner     |
       |        |<-(B)--- Authorization Grant -----|               |
       |        |                                  +---------------+
       | Client |
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         | Authorization |
       |        |                                  |     Server    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier",
      and derives a transformed version "t(code_verifier)" (referred to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t".
   B. The resource owner responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code to the Access Token Request as
      usual, but includes the "code_verifier" secret generated at (A).
   D. The authorization server transforms "code_verifier" and compares
      it to "t(code_verifier)" from (B).  Access is denied if they are
      not equal.