Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

Benjamin Kaduk <kaduk@mit.edu> Mon, 23 December 2019 19:13 UTC

Return-Path: <kaduk@mit.edu>
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 831E7120CDA; Mon, 23 Dec 2019 11:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 iuHfIGcZo4Qh; Mon, 23 Dec 2019 11:13:53 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68AB120CD8; Mon, 23 Dec 2019 11:13:52 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBNJDiH1023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 14:13:47 -0500
Date: Mon, 23 Dec 2019 11:13:44 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Vittorio Bertocci <Vittorio@auth0.com>, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>, IETF oauth WG <oauth@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Message-ID: <20191223191344.GD35479@kduck.mit.edu>
References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <CAO_FVe4jYtrCiGAFSKQo2UF2WDCu8Yf8ww9_biMoW4TJPQ2Qpw@mail.gmail.com> <AE9BAC29-50B0-4DAD-B27D-02EC803537A9@amazon.com> <CAO_FVe7=+G+Zc8VHbr=3Zt9w9v-1G6njRC-qPJFpwKMjBrY1Dg@mail.gmail.com> <CAO_FVe6Y-vaw_jVv9GUj0wkuOFXO9Lvd-Uq2HU87NQQ=SfFCnA@mail.gmail.com> <2518B18A-AD93-44E4-88D1-E5F6AAE7B1BB@amazon.com> <CAO_FVe4Y5pWdSR4m_g5op+fpoXVxz7kZ--BJLAgwdxfC6sr+kQ@mail.gmail.com> <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <16EBA415-06A9-4190-B8C3-EE96771B70BD@amazon.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EbCArB19S7_oBtROGqICNq969dE>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt
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, 23 Dec 2019 19:13:53 -0000

On Tue, Dec 17, 2019 at 09:12:26PM +0000, Richard Backman, Annabelle wrote:
> > That's a pretty strong statement :)
> 
> One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is not used at all, just that it is not universal and comes with real, practical tradeoffs that may not be appropriate for all use cases. Consequently, we should not design fundamental specs that mandate its adoption.
> 
> 
> > …knowledge of that level isn't necessary.
> 
> Either the RS and AS have a shared understanding of that level, or the RS is trusting the AS to decide what “AuthenticatedClient” means, and set it accordingly. The latter requires that the RS only supports ASes that have a shared (or substantially similar) understanding of what that level is, which is unlikely outside of a closed system. In that case, there isn’t a lot of value in providing a standard claim, as the closed system could just as easily define a proprietary one.

Talk of the different potential levels of authentication calls to mind RFC
8485's "Vectors of Trust" idiom, though, IIUC, it would require some
adaptation to be useful here.

-Ben