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

Daniel Fett <fett@danielfett.de> Tue, 26 November 2019 07:18 UTC

Return-Path: <fett@danielfett.de>
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 E5DD31207FF for <oauth@ietfa.amsl.com>; Mon, 25 Nov 2019 23:18:28 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
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 B-nZz4tWC-sw for <oauth@ietfa.amsl.com>; Mon, 25 Nov 2019 23:18:27 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7322312026E for <oauth@ietf.org>; Mon, 25 Nov 2019 23:18:26 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id A38011B4A; Tue, 26 Nov 2019 07:18:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1574752704; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g3r/ZaO18IOncuJBozJsgGvXlLR48NYl/O3gPG6SpEM=; b=GIs2yU4eD+UhJza4z2fWU00XSncWOAq6GJkhYRuhgPG8wlMD2wvb07K73Tig4dfKAKqX8L R/98ZZ6EVluuyuFZOQrV0X7iE7J1Ti5wFnLYSyR4vgyKPKE7mREFJBwZX/XTlflDJxvLQF eJNGTtgvL9SxSwPsAlhEwcEUH5EslZU=
To: "oauth@ietf.org" <oauth@ietf.org>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Aaron Parecki <aaron@parecki.com>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, "ve7jtb@gmail.com" <ve7jtb@gmail.com>, Andrey Labunets <isciurus@fb.com>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
References: <CAGBSGjpeXoJXM-UzG2HrXefO6SW_NzFpuzD4Nh=9XPAmg_Wgtw@mail.gmail.com> <A11964CB-DD11-47A0-BA23-19731CB2C2FA@lodderstedt.net>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <0911bbfb-c80b-16c2-80a6-b0d0ed35ec55@danielfett.de>
Date: Tue, 26 Nov 2019 08:17:51 +0100
MIME-Version: 1.0
In-Reply-To: <A11964CB-DD11-47A0-BA23-19731CB2C2FA@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------BE442FB99F20E2402A848E89"
Content-Language: de-AT-frami
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1574752704; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g3r/ZaO18IOncuJBozJsgGvXlLR48NYl/O3gPG6SpEM=; b=F2+zWR7fa7oBQNX0ZMVUeZu+NOzmpm7M8vDVTltr7C+PidXriYdPexQLGxPXyYTQ7IxQ9n z8C+nOR1bWPaiCzHwv19i5OmbGPsblw9edU8u2jx+lKkikxccqVCa1xOihgHFyoUzOm2Pw UJ9pqg5Y4RHGfRpN2xg2G790QnRYtQg=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1574752704; a=rsa-sha256; cv=none; b=J5lmzhNVsbSlMOo9YQBgM5zlO1NuXaJAyEoI3+P2iFICh76wffw3jUjNykzXmFW5X+8bQSfOB4KuJhz5YoJEACP2xZdvHHsiyo7Z1CtnPJeHy/JgXIqM9qlcfljNLBn54dhpd3t2pguUWFUiN++iGAte2ZS9uEAUai5sKVEbu4s=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: ----
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lGEDwRNm8kfO7hDSH1okUsVotMc>
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: Tue, 26 Nov 2019 07:18:29 -0000

Am 25.11.19 um 23:02 schrieb Torsten Lodderstedt:
> 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.

Then let's move these discussions to an appendix or a separate document.
I have the feeling that some sections have too many "could"s, "might"s
and "should"s for a normative document. Another point is that the
alternative solutions that we are discussing often have not been
analyzed as thoroughly as the recommended solutions (see, e.g., PKCE vs.
Code-bound State vs. Token binding for Code).

-Daniel