Subject: [OAUTH-WG] Misplaced Resource Owner in PKCE

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Jan 2015 15:01:58 -0700

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.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Jan 2015 19:14:19 -0300

How about

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

> On Jan 29, 2015, at 7:01 PM, Brian Campbell <[email-masked]> wrote:
> 
> 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 <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
> 
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Jan 2015 15:16:14 -0700

Works for me. The text below needs to be fixed up to match too.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Jan 2015 19:35:53 -0300

|        |<-(B)---- Authorization Code -----|               |
       | Client |                                     Authz Server

Sakimura, et al.         Expires August 2, 2015                 [Page 4]

Internet-Draft                 oauth_pkce                   January 2015

   B. The Authorization Endpoint responds as usual, but records
   C. The client then sends the code in the Access Token Request as

> On Jan 29, 2015, at 7:16 PM, Brian Campbell <[email-masked]> wrote:
> 
> On Thu, Jan 29, 2015 at 3:14 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> How about
> 
>> On Jan 29, 2015, at 7:01 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Jan 2015 15:39:47 -0700

Good by me.

On Thu, Jan 29, 2015 at 3:35 PM, John Bradley <[email-masked]> wrote:

>> 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.
>>