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

[Brian Campbell <[e-mail]>]

Good by me.

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

>
>        +--------+                                  +---------------+
>        |        |--(A)-- Authorization Request --->|               |
>        |        |        + t(code_verifier), t     | Authorization |
>        |        |                                  |    Endpoint   |
>        |        |<-(B)---- Authorization Code -----|               |
>        |        |                                  +---------------+
>        | Client |                                     Authz Server
>        |        |                                  +---------------+
>        |        |--(C)--- Access Token Request --->|               |
>        |        |          + code_verifier         |    Token      |
>        |        |                                  |   Endpoint    |
>        |        |<-(D)------ Access Token ---------|               |
>        +--------+                                  +---------------+
>
>                      Figure 2: Abstract Protocol Flow
>
>
>
>
>
> Sakimura, et al.         Expires August 2, 2015                 [Page 4]
> 
> Internet-Draft                 oauth_pkce                   January 2015
>
>
>    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 Authorization Endpoint responds as usual, but records
>       "t(code_verifier)" and the transformation method.
>    C. The client then sends the code in 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.
>
>
> On Jan 29, 2015, at 7:16 PM, Brian Campbell <[e-mail]>
> wrote:
>
> Works for me. The text below needs to be fixed up to match too.
>
> On Thu, Jan 29, 2015 at 3:14 PM, John Bradley <[e-mail]> wrote:
>
>> 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 <[e-mail]>
>> 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
>>
>> 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.
>>
>>
>>
>>
>
>