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

Torsten Lodderstedt <> Mon, 25 November 2019 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28071120F97 for <>; Mon, 25 Nov 2019 14:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b2_hYcstY38f for <>; Mon, 25 Nov 2019 14:02:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68FE0120FAC for <>; Mon, 25 Nov 2019 14:02:36 -0800 (PST)
Received: by with SMTP id 4so16769988wro.7 for <>; Mon, 25 Nov 2019 14:02:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AGjo+TvW/dqJChac3ZmjA1jomtrnWDKEFBn5wirXTe8=; b=ZqJ6Yn2lU6ldtyz05nIQSOhtlUAe9Rl9YQ0TWyCG3KlbItZAn1dZ1S9Mv0fnikcYBM TcVMS9oDXrjEUimjAKIW3w8q7g80HxHXZ+lOHo0CvTsLm47qJ82c3Tqh+DkfImMD8cAC Lf0Nywv9NW4eiZqHgogWdl+RgH3xsXl3WLtYGYz0hTRIHJAFQQE8Knjt4EexF3daGfwc PzrvTx6uq+88GQJ5LTdjJKwQHkt9wZ81/70C6fmJUIhC9RPjHKXP5kISaQIAhtd1i3Ie vyFaCeTM0MO/0P+XuXM2DX2NADtpkjE1Ws8ms4GRVrSTpP6xDwu+eSM5JFogxKwVsuUE HKTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AGjo+TvW/dqJChac3ZmjA1jomtrnWDKEFBn5wirXTe8=; b=AEfyRLZHMosOhag3imcZxaPgyiq8WUJg24AGrjTm5e3+X/c/yDuPQuzHFWQX4pERRX +mfL2qB8Xs4/4QQvE9mF53ez4ReIDsXvKN5DDFsnQe6SNBGFtfzxmLT6fay/4sjkyAww FDBY9qWU9RvCjqxNhH9oEUSw/v6LtypCEjZQwyLiPzG7DVAYJnaSUac3Ui3Ri6XH+nuZ MigXxM3T+zoCjGhxen3titJAsVxQ4kOgGmAqsyOfuw7YuLEE+3UDfROMtuR/x34I8pWz ApM6aJwsCwQixEJRj4Uct6JXDIxsWVZ211dhBg6mbJi4FCWMoOzMiZ2lr9mcFYtoPvoj kIzg==
X-Gm-Message-State: APjAAAUIIDsOMVGWfQfuETjMZDfrS3wlRF9Zw55dOi+IPUswtBjC81IO puY9/mTQsTTH7Y8qO2iCDSd5uc4FYocODA==
X-Google-Smtp-Source: APXvYqyUt+MphbJPeqzC0Be7S8y71YB/jVNeknoAF7elBgdG/cbWja3nuFFO9vv6xLn4xG06RDHxCw==
X-Received: by 2002:adf:ea4e:: with SMTP id j14mr11949324wrn.101.1574719354720; Mon, 25 Nov 2019 14:02:34 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e19sm780176wme.6.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Nov 2019 14:02:33 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-FD216799-DDBF-4C2C-BA91-CDCA1508DFFD"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <>
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Nov 2019 23:02:31 +0100
Message-Id: <>
References: <>
Cc: Daniel Fett <>, Brian Campbell <>, "" <>, Andrey Labunets <>, Mike Jones <>, "" <>
In-Reply-To: <>
To: Aaron Parecki <>
X-Mailer: iPhone Mail (17A878)
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 22:02:42 -0000

Parts of the text in section 4 capture discussions of potential solutions and reasons why we decided in favor of a certain solution. I think this will be useful in the future and it has already proven useful for me, e.g. in the recent discussions around PoP vs audience restriction.

> Am 25.11.2019 um 21:55 schrieb Aaron Parecki <>:
> +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
> _______________________________________________
> OAuth mailing list