IETF Logo Mail Archive

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

David Waite <david@alkaline-solutions.com> Mon, 11 November 2019 00:51 UTC

Return-Path: <david@alkaline-solutions.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 AD8D7120802 for <oauth@ietfa.amsl.com>; Sun, 10 Nov 2019 16:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 DfpXZZz2eAH1 for <oauth@ietfa.amsl.com>; Sun, 10 Nov 2019 16:51:32 -0800 (PST)
Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16B12001A for <oauth@ietf.org>; Sun, 10 Nov 2019 16:51:32 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:bc69:2824:515c:c2c2] (unknown [IPv6:2601:282:202:b210:bc69:2824:515c:c2c2]) by alkaline-solutions.com (Postfix) with ESMTPSA id 15310315B6; Mon, 11 Nov 2019 00:51:31 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.2\))
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <8541e349285c4ad78caaa95aa6e8c104@CHRP5009.corp.gwpnet.com>
Date: Sun, 10 Nov 2019 17:51:30 -0700
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A67D0E09-4FCE-4794-892B-4914050AB5C6@alkaline-solutions.com>
References: <8541e349285c4ad78caaa95aa6e8c104@CHRP5009.corp.gwpnet.com>
To: Lee McGovern <Lee_McGovern@swissre.com>
X-Mailer: Apple Mail (2.3608.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Cri7-IKqVkvds_pS6Bwbm7MT7Qw>
Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
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, 11 Nov 2019 00:51:35 -0000

On Nov 10, 2019, at 2:02 PM, Lee McGovern <Lee_McGovern@swissre.com> wrote:
> 
> 
> 3.1 - "Clients MUST memorize which authorization server they sent an authorization request to" - is memorize the best synonym here, perhaps store or retain is more aligned with computational language?

Store, retain, persist are all common.

> 
> 3.1.2 How does the draft https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 align with this guidance and will a future BCP update include a direct reference to the final published version of this spec?

The dependency will be the other way - Browser-Based Apps will inform AS and RS implementors/operators what they need to do to allow javascript clients, and browser clients will have guidance toward meeting the Security BCP, where possible. Other drafts like DPoP exist to try to reduce the delta between the security BCP and what is feasible to deploy in browsers today.

> 3.5, 3.6 Since there is a reference to the MTLS draft could there also be some guidance on the usage of token exchange best practise and also for the contents of the access token to be aligned https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-02
> 

-DW

v2.23.0 | Report a Bug | By Email