[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

"Barry Leiba" <barryleiba@computer.org> Tue, 07 July 2015 02:49 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 73CCF1A8752; Mon, 6 Jul 2015 19:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kfVlBl4CAqTB; Mon, 6 Jul 2015 19:49:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99481A00B8; Mon, 6 Jul 2015 19:49:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" <barryleiba@computer.org>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150707024902.24716.2952.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jul 2015 19:49:02 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/YtAad4SEavE5k4OpLRoJ_GhMehM>
Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org
Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 07 Jul 2015 02:49:04 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).  Thanks very much for considering these and working with me on

My comment about the IANA Considerations remains.  While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s)
keep track of.  Also, please give more instructions to the DEs about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should

For the first, here's a text change that I suggest we move toward for
this sort of thing:

<most of Section 6.2>

   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-review@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be

   Discussion on the oauth-ext-review@ietf.org mailing list should use
   an appropriate subject, such as "Request for PKCE
   code_challenge_method: example").

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as <<these other things>> when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request

-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion
with the author I suggest this:

Clients MUST NOT downgrade to "plain" after trying the S256 method.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.

Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge