Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

Aaron Parecki <> Mon, 25 November 2019 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F9E51200DF for <>; Mon, 25 Nov 2019 12:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VfpSbGz78sym for <>; Mon, 25 Nov 2019 12:55:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAF25120F73 for <>; Mon, 25 Nov 2019 12:55:21 -0800 (PST)
Received: by with SMTP id q15so15509994ils.8 for <>; Mon, 25 Nov 2019 12:55:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PRWZ1NubKMotDzG1swltIqpAq3/IFqQWWovxoIUh65E=; b=rSVZhJrkhFNZzZrVkYP8hdISqFF9BeczfSu8d8nULsTIa7AAdLnwA/QpPPEGyv+hdw MYucNncdv8RAnEb3dDzOh3+XRfW4oQ+kdtOQTGhDwpMfrrXZPP6OyWi49SmmYll2pH+9 eHWG8Wg51IlgIjI2XBK3j8tjHxQBCwr5yju/R+4J8yS4dcHzSoE+svwwdVGVJ6QaPSGh l5h23ux+8Y6Vyw0hEhHWLthRh+IynXpw9+9T+VG5aAk+CzoyWBGaBMQj79ZzulOn9qRp jb8UHXBuER07d+JjkWidE8vRBROWcKv4FNLRpZE0920Jlm8HqF2ZurRelPwUeXK0j2Je M1CQ==
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:content-transfer-encoding; bh=PRWZ1NubKMotDzG1swltIqpAq3/IFqQWWovxoIUh65E=; b=XkCnXSJHrGqELOKSyvFQTHfKul15HWz7kRml+t7aV0B1G62LdwdB7JVw7qHw51yJyT /xcT2ZW0kUCAGbFf6xq9xGDIZfXEbkMaovFZDhnF2QfotSZruWGwDRSzao/fEwbNbJz6 UJ9qBf3l7y80sVElt0lLpB7iwgPdWbhYKZXM6B/vGHYMdhcbpA1BygR5h0TS56+6bgpU SPqwIcoOKPdj33G0ONw23ZJnea4QUiGwAXcJmF958lgAn0dAAPViDCrK2E42rFx/XTyq WOmP0EZcG4GASuSoTeY1cmylZinKQbUyukaFF3hRfY7anId4JAuZMzoaBXSfj8RAwWxc IjZA==
X-Gm-Message-State: APjAAAVUYYRZlz+Pg78qel/4iRoM5iNdcr7Bm6PcWmJpm9MKL6NK75BV R4tvNRpHW9tkpI4GW3YRPog5TyINZowoQA==
X-Google-Smtp-Source: APXvYqxg1oNe/EdMjLV4s4SASPyKjkZtyCPcmTNF4QlViIftWsegM+UC5qs/fG5vXmHFgGacny1QJg==
X-Received: by 2002:a05:6e02:8e4:: with SMTP id n4mr21136903ilt.210.1574715320785; Mon, 25 Nov 2019 12:55:20 -0800 (PST)
Received: from ( []) by with ESMTPSA id c73sm2504494ila.9.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Nov 2019 12:55:19 -0800 (PST)
Received: by with SMTP id v17so11652046ilg.7 for <>; Mon, 25 Nov 2019 12:55:19 -0800 (PST)
X-Received: by 2002:a05:6e02:8e2:: with SMTP id n2mr14161613ilt.167.1574715319430; Mon, 25 Nov 2019 12:55:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Mon, 25 Nov 2019 12:55:08 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Daniel Fett <>
Cc: Brian Campbell <>, Benjamin Kaduk <>, "" <>, "" <>, Andrey Labunets <>, Mike Jones <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones
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, 25 Nov 2019 20:55:25 -0000

+1, I'm only comfortable making recommendations in this BCP if they
are in fact, the best current practice. In my mind that means nothing
aspirational, only things that are well established and that people
can act on today.

Aaron Parecki

On Mon, Nov 25, 2019 at 12:50 PM Daniel Fett <> wrote:
> +1. We should only discuss solutions if we would be okay with people actually implementing them. (See also my feedback to Guido's review.)
> -Daniel
> Am 25. November 2019 20:41:45 MEZ schrieb Brian Campbell <>:
>> On Fri, Nov 22, 2019 at 11:46 PM Benjamin Kaduk <> wrote:
>>> On Wed, Nov 20, 2019 at 03:40:34AM +0000, Mike Jones wrote:
>>> >
>>> [...]
>>> >
>>> > Metadata - This section suggests the use of a "resource_servers" metadata value.  This isn't defined by RFC 8414 nor do I see it the IANA OAuth Authorization Server Metadata registry at  Is this something that's been standardized elsewhere?  If so, please add a citation.  If not, please clearly say that this metadata value is not standardized, and is therefore unlikely to be interoperable.
>>> I would go further and say that we should not document "best practices"
>>> that involve non-standardized values.
>>> > Metadata - This section suggests the use a "access_token_resource_server" token response value.  Please likewise clearly say that this parameter isn't a standard.
>>> (ditto)
>> The document has a number of occurrences similar to these where a particular solution is discussed even though it's not been standardized and/or isn't actually a recommendation of the document. Such discussions can instructive and have valuable information. But I wonder if it might be more appropriate to omit them from the BCP? When the document is read and understood in its full context, I do think the scope and intent of such discussions are made reasonably clear. However, they could be pretty easily misunderstood by someone just reading individual subsections or from citing parts of the document text without the larger context. I guess I'm thinking/suggesting that it'd be better if the BCP only focused on the actionable recommendations it is making. And omit background type discussion of alternative approaches that didn't get used for whatever reason. Or, if they do stay in the document, de-emphasize them even further like maybe moving them into an appendix rather than the main body of the doc.
>> 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.
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> _______________________________________________
> OAuth mailing list