Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

Brian Campbell <> Mon, 27 April 2020 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40A263A0C3A for <>; Mon, 27 Apr 2020 07:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JId0LimLLYCB for <>; Mon, 27 Apr 2020 07:56:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E0F33A0C28 for <>; Mon, 27 Apr 2020 07:56:44 -0700 (PDT)
Received: by with SMTP id j3so17865108ljg.8 for <>; Mon, 27 Apr 2020 07:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pfGmfNgxzBOIfzneCWMVrMUFKTWrtEUgpLTql/IDjPY=; b=GCMg95zCMyJYWI+Hxfnf7Jp7YoSmRiNDk81Qf5SuRIa17Rv6Q93ta8fUtG3Wr7Kzsw A1Dwyarx2HT57x+3tTRxRJhpw8D3QdatGDceFAU5YhY4DDVNjJ+byUPiHRxxXt4b/08S UxWxLgjSAYJO8wQIcdy6Wh9049exec1ljdE/9zZnYFB7yfMoX8va8Kq/TnrEx7pHhzLb /6ldZs+uEqIfEOff3J+TJBSU90MK5EcO3SOKmjZ2bQpN2m4res9o52c7Abk8qCsCuN80 rBaTuWAWB2CwENCWDkaFk/akLp50m6mVLW/3ccc/BUB14PAQvC+dBdI6bAra43wR2DdB Rh5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pfGmfNgxzBOIfzneCWMVrMUFKTWrtEUgpLTql/IDjPY=; b=RBXEjWACNUPfl1kQLiL6tcs98u4tKhoNiWJXnL64V8OltUDUf1sBD2xZjr3mWUXWjb NpK/8NqRw9iAA1tIw6rMckaGIwoYI5/rsjD4yevRx9rJkUBLR0skzpNdC24vWv75gxl9 qOd7zhR+2/IM9fTKqnLHhkqG5t8ZuLJ9E/apZbCJWy+/K9l8QfQwR0YevVYJLI/DC5xS AQBZ68PO05p0xGIhyK3t45DBxplhre9Z+qqvNJdTdC5zxFHk7J6ORrD2Guo+Lx7FTcex RP/YRNjIKzUIxD84bSh6G73J6S+jpzWX7rPf4nPyhojqhNG5QJbrfcVugR46Fy/YtiWM DM3A==
X-Gm-Message-State: AGi0Pua3Ztiu52AcuoSjbMa/kthh8Mt5fqo1/Np9aDmhsc4BtJ6xNiD1 qgYRjm3JcEAKnTABt0crS0JMq4ccFtARHyItpUjtrMdUoA+GYaU9iYbYe2B77sL7evPXJBOQfaa Cmf7B8S2a3Eb0CQ==
X-Google-Smtp-Source: APiQypI5KL00/yABV23Se1s1nJSfwsmzS/hkVS552VJLvtfP4CfgMPFqSBNN7UT3EL7ji75F9PBLxNwJnggyAupKB6U=
X-Received: by 2002:a2e:3813:: with SMTP id f19mr14191659lja.216.1587999402052; Mon, 27 Apr 2020 07:56:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Mon, 27 Apr 2020 08:56:15 -0600
Message-ID: <>
To: Aaron Parecki <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000043700f05a446ec83"
Archived-At: <>
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 14:56:48 -0000

On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki <> wrote:

> Thanks for the detailed review Brian! I've made many of these edits to the
> draft, but there are still a few things that need some discussion on the
> list. My notes are inline below.

Thanks Aaron. I realize there was a lot there. I've followed up on just a
couple of the things below that seemed like they needed a response.

>>  "  *  _Sender-constrained refresh tokens:_ the authorization server
>>       cryptographically binds the refresh token to a certain client
>>       instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]."
>> Given the relative immaturity of ways to do this, maybe something more
>> open ended would be appropriate? This reads like token-binding or MTLS are
>> the only ways allowed. I'd think wording that would allow for DPoP or some
>> yet-to-be-defined method would be better here. Also maybe drop the
>> token-binding reference all together (it's long expired and doesn't look
>> like that's gonna change).
> I'm generally supportive of something more open ended here. Would that
> also suggest that the corresponding text in the Security BCP be updated as
> well?

For some reason, I'd been thinking that this stuff had been changed in the
Security draft. But I was apparently mistaken.  Anyway, yes, I think it
should be updated there as well.

>> <>
>> "Attacker A4 in (#secmodel)"
>> "The use of PKCE is RECOMMENDED to this end."
>> PKCE is required elsewhere so this doesn't seem quite right. Similar
>> comments about text ijn
>> that talks as though PKCE might not be there.
> I believe this text was included since an extension such as OpenID Connect
> can define other methods of authorization code injection. Also note that
> this same sentence is in the Security BCP so if we update anything here
> they should probably match.

I guess my understanding of the intended scope of the two documents was
that they were a little different. Like there's a security profile that
describes a few different ways of achieving something with the tools of
2.0, OIDC and PKCE. While 2.1 is saying PKCE is always required and there
are benefits to that. So the latter doesn't seem to need conditional
language around PKCE or alternatives. Maybe my understanding is flawed
though. Or maybe there's a larger question here about the value/need/cost
of having a lot of duplicative or overlapping content across multiple

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._