[OAUTH-WG] Misplaced Resource Owner in PKCE

Brian Campbell <bcampbell@pingidentity.com> Thu, 29 January 2015 22:02 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 3A4161A039C for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:02:33 -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 NnSDG2s9lLsE for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:02:30 -0800 (PST)
Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CED1A00DF for <oauth@ietf.org>; Thu, 29 Jan 2015 14:02:30 -0800 (PST)
Received: from mail-ie0-f179.google.com ([209.85.223.179]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKVMqt9ZlUwNYm01zDRXLJosVB/61DfDI9@postini.com; Thu, 29 Jan 2015 14:02:30 PST
Received: by mail-ie0-f179.google.com with SMTP id x19so39957195ier.10 for <oauth@ietf.org>; Thu, 29 Jan 2015 14:02:28 -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:from:date:message-id:subject:to:cc :content-type; bh=9FFjtoGDrJ5+1hOBTxctv+l3YRp1pO3E31t6EIH+Gw4=; b=aKyPviisJcIlPcJzUUBqmRRqH+IrrKkYc/qlIVv5KIQP3zD2eR5iiLV5b7eitVD05h cIxKHc1fRgainq3BXE77KtERbFOXSFoO6tUARFBbTi6SJWZCveI1IErScNQSqNq1mcnE zCmKR7WSkrXazoh8vNNLWpTx6Yp81J8sEGF7b+2fGBmGKQWQIAbSaS6eBbXaL6QQfnEf XiuZFhvHZMONWPoBpSX4eBx4Ejy9qt2Z0Tlx8gcKFvwRfpDHNKV137ITwmwr1CK8dtMl Y1NhhBhMrsw+s5LbUbz/A1C4NyYL/yafdAGmSk7obTS8LChqdVttXL/24nTA8BlEti+J eOHA==
X-Gm-Message-State: ALoCoQlnjRnjjDwSQ7wImBgi2ZtYGbIED6OslSxCKjxSRKja2zbNE3tmkLIS9x4IxuTCsDfe9GMbctLEPvRd66cSwKQH/B2rx2V/AQ6VrM3NVG7Z1y/QY/uMRrLIhNmBZ+h4bSUfQkZ+
X-Received: by 10.107.10.17 with SMTP id u17mr3597929ioi.45.1422568948745; Thu, 29 Jan 2015 14:02:28 -0800 (PST)
X-Received: by 10.107.10.17 with SMTP id u17mr3597915ioi.45.1422568948649; Thu, 29 Jan 2015 14:02:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 14:01:58 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 29 Jan 2015 15:01:58 -0700
Message-ID: <CA+k3eCS0BP5se-nbhw6bpCWH9HSe_4afQRXrS8fL8vYm3+LGmA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=001a113ee77eda68ff050dd1a48e
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/0xKhaJhraXKRluZuB1wlvWRlipg>
Cc: Naveen Agarwal <naa@google.com>
Subject: [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:02:33 -0000

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.