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

Brian Campbell <bcampbell@pingidentity.com> Thu, 29 January 2015 22:22 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFD41A8870 for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP4dr03zq-Lw for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:22:23 -0800 (PST)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA971A8884 for <oauth@ietf.org>; Thu, 29 Jan 2015 14:22:08 -0800 (PST)
Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVMqykC4wTDtWup1ei2GRDUP7Zpd0z6HW@postini.com; Thu, 29 Jan 2015 14:22:08 PST
Received: by mail-ie0-f169.google.com with SMTP id rl12so617555iec.0 for <oauth@ietf.org>; Thu, 29 Jan 2015 14:22:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i9xo8d16M4qr0iU+1zqfsROHlBLD4PObiWkI+1xIAeo=; b=REJulqARSuCJOuAuSCAhJa53+dQp+Nr2zqRXzjqCZ1aAEKvCePlhLvmU5HqF+gwd3i Zgt8C0E0o3Y10Y/D3S2fN7lRn+J8wf7i8sRIMYa9YS+aojgaQxyunbYTIXzYn/5IDKI/ ESDTyChsIzDfnymMUghfsbDTSTPHB/g/AAI00U6/LT9hQxpiU95dJKX0bNAvE5Um8Lpg 05O4FAAxWRIKz1vqFy82zIbvCd7PKP1YXK+WPsH9lN0JU4TIE+DdSe8ZymfCkqJanFvd 5cFzuei8r+NvGtJmsGuCxuLTQnif40itj9033kNgikWXUx3Ek9SXkaI0OKUh5MlcdEyd cAiw==
X-Received: by 10.107.5.79 with SMTP id 76mr3690867iof.15.1422569804353; Thu, 29 Jan 2015 14:16:44 -0800 (PST)
X-Gm-Message-State: ALoCoQmWEY3TLsAszKi7T9KMGCmpQDynAufqLtske0YXOKp4FPKA9Sgl3xeZ/KE2jqX+hGYEwdgRP4qm0I/8CbOxLunCdtEVVD7iMqJB403IYzEqdkvO5Xp3ndH/HPlldILgLneMVezq
X-Received: by 10.107.5.79 with SMTP id 76mr3690852iof.15.1422569804238; Thu, 29 Jan 2015 14:16:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:16:14 -0800 (PST)
In-Reply-To: <DE5F6289-144D-4002-85F0-34DCF3F783E6@ve7jtb.com>
References: <CA+k3eCS0BP5se-nbhw6bpCWH9HSe_4afQRXrS8fL8vYm3+LGmA@mail.gmail.com> <DE5F6289-144D-4002-85F0-34DCF3F783E6@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 29 Jan 2015 15:16:14 -0700
Message-ID: <CA+k3eCRrkExQk2Rkjq2aZaEUQW4k8jPZA50C3aO2nAHCBDry-g@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a113ee646d9ad95050dd1d7fc
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ARP1DMYx5oAurKm2MHmQcZtzJFg>
Cc: oauth <oauth@ietf.org>, Naveen Agarwal <naa@google.com>
Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jan 2015 22:22:26 -0000

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 <ve7jtb@ve7jtb.com> 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 <bcampbell@pingidentity.com>
> 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.
>
>
>
>