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

Brian Campbell <bcampbell@pingidentity.com> Mon, 25 November 2019 19:42 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA37120018 for <oauth@ietfa.amsl.com>; Mon, 25 Nov 2019 11:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o_dO9vOdn4o for <oauth@ietfa.amsl.com>; Mon, 25 Nov 2019 11:42:15 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4726120E1E for <oauth@ietf.org>; Mon, 25 Nov 2019 11:42:13 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id m30so10144569lfp.8 for <oauth@ietf.org>; Mon, 25 Nov 2019 11:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JL9qXttewfOuM8zlrzzplmrOBPqXUGYf+EAkjq0qSrM=; b=bi5ktGe2YMAzQ81R80mcAVlEHlKNoplsqgYNEc8Xr72RkORDE8LOTCP/ZosrovKE4k Fa6iPzAc41NTTiSKUvDG6FzYaQC+qcKjPJqYmGYJwWEQRa5hDnIYOTCKvLBMGys9FBkI hkbZXY+tDgff1lYkCB41e6XXiFsBjsayrpRxe8STIWF1jd/THmKEi/926aRIt3qTvdUu 77snOwjPmADfeJNmUGzc4Sl3ZuRS4VmlE/vkDVxXJ+pIcTac9wsXaZJnZf7wsL7QtxiO fVykv9xoexKpFR0Q7h066v/5RWyEE3sCWxUc/OjCuzlaf/RHJ8RRRRTyWUHyfkkIbQDS uziQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JL9qXttewfOuM8zlrzzplmrOBPqXUGYf+EAkjq0qSrM=; b=k8jZeVJ/MDxoxd6mkyBDnE8lesATo7s7d0OCRX8Yes53Kgol48e3J6kBDGjxrTkfhu JEeV8lHeo9UQlvdRvSbbkwmPmnmLBQQ1reo065hkLVN8laarBKyr4E2/H4GU/U0bAa6E jSHy23wo+PbQXaw6GZlwqn7MCtKjTORUeLZBn4DWzpkcSsXOQIM93c33FVnYKWAxyw3d CEXORIFdQEpIiXZDK7dLxj7Mm4Dy3jPaBMy6gsrW+Qw54gDo3Y8aZz5dddY+IdWZ9GdE YG10UHp+B8+x059/531n1o1o7fW82R3s8tHRif2Vv6P+/spsFqQKRVnF+cJKTkU+Ht4K lyKw==
X-Gm-Message-State: APjAAAW45AQKceGLXNfZc5UFKZ5LnZRJkw6+G10b6foypjXLuYI+TX/s 66bMXwOKMVC9ONdb/lezPuGA7iebNOtQeXuxQkW+CKLmH8KuiqgxeLTdakG9eFZLWXHS10A7u9M Z+FRFafkcCDR+/A==
X-Google-Smtp-Source: APXvYqwhzHxrwn96i2Ny0j8vjU1GB2+DCDXCSYgwClzKAbeDJStJ+Fivf9Z/K4TM6MTCQgSOJkv8BfjSvPgMsCra49Q=
X-Received: by 2002:ac2:5388:: with SMTP id g8mr11315944lfh.43.1574710931912; Mon, 25 Nov 2019 11:42:11 -0800 (PST)
MIME-Version: 1.0
References: <BN8PR00MB056369C04536770FF5B90512F54F0@BN8PR00MB0563.namprd00.prod.outlook.com> <20191123064612.GI32847@mit.edu>
In-Reply-To: <20191123064612.GI32847@mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 25 Nov 2019 12:41:45 -0700
Message-ID: <CA+k3eCS1iZ2J_owo627WFuBY=0pYUuQpjRUzq4hpTEHkJPsAQA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "ve7jtb@gmail.com" <ve7jtb@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>, Andrey Labunets <isciurus@fb.com>
Content-Type: multipart/alternative; boundary="000000000000b899c4059830f5db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/X5qWEuJpdycOWa-QGcwmeFjutMI>
Subject: Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 25 Nov 2019 19:42:17 -0000

On Fri, Nov 22, 2019 at 11:46 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Wed, Nov 20, 2019 at 03:40:34AM +0000, Mike Jones wrote:
> > SUBSTANTIVE
> >
> [...]
> >
> > 4.8.1.1. 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
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata.
> 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.
>
> > 4.8.1.1. 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._