Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt
Vittorio Bertocci <Vittorio@auth0.com> Mon, 16 December 2019 22:50 UTC
Return-Path: <vittorio.bertocci@auth0.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 CD70612093B for <oauth@ietfa.amsl.com>; Mon, 16 Dec 2019 14:50:41 -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=auth0.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 sA9dU6bbfzT9 for <oauth@ietfa.amsl.com>; Mon, 16 Dec 2019 14:50:38 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 938F912093C for <oauth@ietf.org>; Mon, 16 Dec 2019 14:50:38 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id t26so8427620ioi.13 for <oauth@ietf.org>; Mon, 16 Dec 2019 14:50:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3x8R7UQbK7eO+NJ5Z26uE8L1rpaGHyRu7r/05171yEk=; b=NmaGk2VF22gj+/GYWtBioxQaulRkIuX30RtX0NZa+l8HRk5I1hOkbEFF93TWQ8fAw/ g8jF19Vu8Cbcxuh4i4W8liNJSauZqyWGvRMIyE/7g0JX2zVM/T1e609IXwgrq0DS4bnO itb/NYM13/5PcEeuwt3KFv309uojDrCwShzLnIiRSxhwVQQWrg3dPjSk7b4OeZH0N9Qg akbGxUYor+6cnHEMwYoD+vhxPHkz14FFQSMbn+qE+NauwrktA7QLKv0P+TxyeCnEmxIA 3kAXs82t5HN8SE0vd5LWkUelwUS3Z3Mmj9taIc7tUyBhbzxM5PnVAAnWaGCQP3tgtXZN pJlg==
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=3x8R7UQbK7eO+NJ5Z26uE8L1rpaGHyRu7r/05171yEk=; b=JC2VPKNE5Qzi1oxikh67R13z9ujXIgPhFQWjhRRYLK9+tD0ivUEpV05mNgh34HDMZa oAPQPswCbROAdah/hU7WtGDeOLyZmsOzjCjsCa+dww95X83eKCGTA6FAY/tmbxfKWHnh oQWJSgVe5VCxKC0+oaDnBcIQTCqoybLBL4zK5PMFj2gofN7494a1gdAMom/LecUiAgd6 RzwFu0vsrCXI0OcseLOvw/olvsRwP6N2Zcf4pe0l8Dx1ldUOqqrw07aD0Knc8si471WY NY+auNhiDE+yF8rOCKX7ZKb2QLwoA63SYA7YeMAsPWbS7cEUNuI/YUBFWFdKJZDDHseV 6I3Q==
X-Gm-Message-State: APjAAAVCBGLjURLBDFgubkg2c5ZTywkFcgTBsrynlo5q3r9iCY8Oc03+ ckrVs7MpWM3306j5a5IJYI/fmlcRe/J2vzf+Ry4BMvJHpz0mJQ==
X-Google-Smtp-Source: APXvYqxg20MvU+x9IwgiEEGu6OEvPcI7BVBlAd86rQTkyxqSwvIsrBlhvBp/6HG6O/HKCHTGBEhzpkduacL2D+xf3zE=
X-Received: by 2002:a02:8525:: with SMTP id g34mr13826253jai.72.1576536637386; Mon, 16 Dec 2019 14:50:37 -0800 (PST)
MIME-Version: 1.0
References: <157653653318.24509.15075582637514649078@ietfa.amsl.com>
In-Reply-To: <157653653318.24509.15075582637514649078@ietfa.amsl.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Mon, 16 Dec 2019 14:50:26 -0800
Message-ID: <CAO_FVe4jYtrCiGAFSKQo2UF2WDCu8Yf8ww9_biMoW4TJPQ2Qpw@mail.gmail.com>
To: IETF oauth WG <oauth@ietf.org>
Cc: i-d-announce@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003f4a300599da0afb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZSJXzDadtRMJDNrtH5Ow1U_EUII>
Subject: Re: [OAUTH-WG] 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, 16 Dec 2019 22:50:42 -0000
Dear all, I finally found the time to push a new draft of the JWT profile for ATs. This version incorporates the feedback kindly provided by Brian and Aaron at IETF105. Unfortunately I didn't have a chance to participate to IETF106, hence we didn't do much progress since then. There are still two areas we didn't manage to reach consensus on: 1. Mechanisms for signaling whether the AT was obtained by a user or an application This point was the subject of intense debate on the list leading to IETF105. One insight that emerged from the IETF105 discussion was that the use case here is more about whether the AT has been obtained via a grant that authenticated the client (regardless of what specific grant was used) vs a public client grant- that information can be relevant to a resource as it determines whether the identity of the client can be used in authorization decisions (in the former case) or not (in the public client case). If that's the scenario we are truly after, a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice. Note for the people who didn't read the spec: I removed any reference to this already in draft-ietf-oauth-access-token-jwt-01. I think this is an important and useful info and standardizing it would be beneficial for middleware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach an agreement here, I am also OK with dropping the matter and not address this function in the spec. To summarize, I have two questions here: A. Do we believe it's worth it to formalize in the profile a mechanism to indicate whether the client th obtained the AT authenticated itself with the AS? B. If yes, are you OK wiht an optional bool claim here? 2. Claims indicating session properties This is one area where I am far more passionate about, as it represents a fundamental aspect that production systems (and in particular 1st party solutions) already rely on in the current proprietary JTW ATs. The profile currently includes the claims auth_time, acr and amr - capturing the values of those properties at the time of the latest authentication the user performed in the session used to issue the current AT: at session creation, at auth step up time and so on. Those are values that API need in order to make authorization decisions; in the case of 1st party APIs, the AT is the only artifact they ever receive hence there is no other way for an API to determine whether the caller performed say MFA in order to obtain the current AT. Since the first draft, some people signaled concerns about the current mechanisms thru which those claims get their value. For example, it has been proposed to maintain the original values of auth_time, acr & amr and introduce additional claims to indicate changes (like stepup). I am not clear on what cold go wrong with the current approach, hence I don't have an immediate grasp of how changes like the above would help. If the people uncomfortable with the current proposal could detail their concern, we can brainstorm ways to make that info available to API in a safer way. To summarize: A. Do you have concerns with the current auth_time, arm, acr proposal? Can you spell them out? (please read the relevant parts of the spec before chiming in :)) B. If yes, what can we do to make that info available to RSs in a way that makes you comfortable? Thanks V. On Mon, Dec 16, 2019 at 2:49 PM <internet-drafts@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename : draft-ietf-oauth-access-token-jwt-03.txt > Pages : 16 > Date : 2019-12-16 > > Abstract: > This specification defines a profile for issuing OAuth 2.0 access > tokens in JSON web token (JWT) format. Authorization servers and > resource servers from different vendors can leverage this profile to > issue and consume access tokens in interoperable manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] I-D Action: draft-ietf-oauth-access-to… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Richard Backman, Annabelle
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Vittorio Bertocci
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Torsten Lodderstedt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Steinar Noem
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Brian Campbell
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Benjamin Kaduk
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action… Justin Richer