Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt

Bill Mills <> Thu, 05 February 2015 20:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A0031A8B84 for <>; Thu, 5 Feb 2015 12:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id poipe72EpTm8 for <>; Thu, 5 Feb 2015 12:54:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2442F1A8AF6 for <>; Thu, 5 Feb 2015 12:54:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1423169662; bh=DJsYO/oLGLp+Lxn59qAp0lx4xNzbubWmiAa2QGw7LQ0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=T9LKKTZpw0NEUMdXS0DqfcB3wEALxnGcZpFtAWLr5ifufLbOeay7X/ZsRBbua+TQ9biqjjZBxExouX4Vz8wcZBtxXF55j2NwbcHX6PgfAYh//xo1bLwrG7vh0YJzcgwj0wLovc+jX1tNrwtIII14M+++r9Bmm1f0IawedVwEOeme6EYo4X0n0GHFX/C4msvD3/78TtdDNeBWhFBV06c4EpyePWfeXmolMSOsjqNKCavZekTmCj/U5+Kk1fBwah1CuUI2aVy4Sg5r4ZOiSJVAH+H1wDcA32uP3NyjQPU34pdCX45hKNx5MX4DPOQ3a2j9YxMKrR9OQf6qTSVQYN47aA==
Received: from [] by with NNFMP; 05 Feb 2015 20:54:22 -0000
Received: from [] by with NNFMP; 05 Feb 2015 20:54:22 -0000
Received: from [] by with NNFMP; 05 Feb 2015 20:54:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: cgoA8rMVM1lVdUzpTUTUtuInc6T5uZXNGuvwKD9fqy79P8WfMj0uJpoQg2lJEdG UI1Ljff2IT2q9RUvqRw9tjBkokGIFSJdcn7DgeJSo6iGQF45Rcyfyyc4uYffE74Lq_ItSTQTRyw3 tSVIcokE.QAOsAJ8ryq_Ht2vnZBkVnxte5Bl8h5sJpGrfCurCIvbig1BdKqlU3DQrf2qpx0PVenO uox1Jixo2CumFmbgZWRJp8anUE7wihwVyBZCDc27q1JOw9meAqfehseYsL6wWh70e7q6A2yQvnd4 Z11UQY5dze92Ntvm_yzurhNfMivUWt4sOkmdVFpGcJTPC8heNib10eUuH.LwVq_TE6ihyQjtvT6T zIiYwtIRQA93Qgd0KPC8qeI8.edkt4mYPP2TQNB8PaVGjteueXYbcWFIyfCq_71uuz2SI7Jy1P8l fQV_X.gGtjjhkkihiJZxvlke2xsrhwW2OvM2VWJeHgjyVJNX_Dv55WVjFMCvf9l8uVgNe3l2M44Q z5_T6mQN1iVS9Zg--
Received: by; Thu, 05 Feb 2015 20:54:21 +0000
Date: Thu, 05 Feb 2015 20:54:21 +0000
From: Bill Mills <>
To: John Bradley <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_461520_1231378395.1423169661105"
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Feb 2015 20:54:25 -0000

Ah, BNF builtin parser error, that's 42*128.  I had parsed that as 128unreserved as the name. 

     On Thursday, February 5, 2015 12:47 PM, John Bradley <> wrote:

 We are discussing the minimum size,  the max is currently 128 characters.

On Feb 5, 2015, at 5:11 PM, Bill Mills <> wrote:
Is there a compelling reason to make that length fixed?  

     On Thursday, February 5, 2015 10:10 AM, Brian Campbell <> wrote:

 22-chars (128 bits) as a lower limit seems just fine for this case.

"ccm" works for me but I don't feel strongly about it either way.

On Thu, Feb 5, 2015 at 9:49 AM, John Bradley <> wrote:


> On Feb 4, 2015, at 10:43 PM, Manger, James <> wrote:
>>    Title           : Proof Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ietf-oauth-spop-09.txt
> Some nits on this draft:
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in prose (just the upper limit); is too high (128-bits=22-chars is sufficient); and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32bytes.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the prose and if so what should it be?  22-chars (128 bits) or 43 char (256 bits)?

> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, though not really necessary as the underscore is enough to distinguish them as technical labels. Quotes around these terms in formula is bad as it looks like the formula applies to the 13 or 14 chars of the label. The quoting is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challenge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier).

I am going to leave this for a later formatting cleanup at the moment, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only one of these is mentioned in section 4.6.
>  SHA256(verifier) === B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) === challenge
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the 1st from appendix B). It is simpler to mention only one. It also means base64url-decoding is never done, and doesn't need to be mentioned in the spec.
Yes when I added the example I realized that the normative text was the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler comparison and drop the base64url-decode references.
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
> P.S. Suggesting code challenge method names not exceed 8 chars to be compact is a bit perverse given the field holding these values has the long name "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challange_method",  James has a point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name sooner is better than later.

It is that balance between compactness and clear parameter names for developers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction.

Feedback please

John B.
> --
> James Manger
> _______________________________________________
> OAuth mailing list

OAuth mailing list

OAuth mailing list