Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt
Steinar Noem <steinar@udelt.no> Wed, 18 December 2019 07:44 UTC
Return-Path: <steinar@udelt.no>
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 B86021208DF for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2019 23:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.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 njLNM5_Nv5lT for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2019 23:44:24 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 94EDB1208DC for <oauth@ietf.org>; Tue, 17 Dec 2019 23:44:24 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id f71so1344604otf.2 for <oauth@ietf.org>; Tue, 17 Dec 2019 23:44:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F5tr63KToC4gL9nmf/amArUIwsNSHtNT3AWsuuMleoE=; b=ADdARjb3zLIytVF4QrP8YF1tmIhwDdWRiNZqUcuQ6YNXj230SRB7It6hiNhl72sVA3 gprG/UK7/HSmJRyhAXf/apTh4eItdM6JB3eXeaP8hOEro4Mb/BqTo8+wq1Gt+Mizg8L/ XfA5MwZgfoo7rjLc+1QktlNCdUyQaUgN82iD4xKNr6C1Zy15AUDgh6OLULSkpumsJPP+ sZr42IauiXpgPyUGPXpU59FiI0F1nn/S2cyIApyzLIvZukvmiGIR/+ptPqo4bYHR8th0 2r2Hv1S44qQ9Kdmq6c63vHJwBlq0ilfD7t8cTvTC8B6hyyBrVUvU36XzPgiVjsF7M/rI 5JYA==
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=F5tr63KToC4gL9nmf/amArUIwsNSHtNT3AWsuuMleoE=; b=bzqtXilR0oolOhbY66hDKzXRfkM98/ntwP3g+chkKA8QaO4V9SyAIo36m3QSfjkT5D /3S/55KL2w9b6782N7cJq8gS43G6ovcZrbzzUOp4DPmh9tO0GyhX17+1FmBLJhIOUNi2 clnoCcGMZipIWmlQIU093PZRI3eWpsozj82T3ehvPbr2O9Kf9FXFMOOVYbfCWSzVVoZc yQ1wXJyvhS3aN6NTyZdE/4JUhyb6mwHOOKodELTh0oQHajh94FnHbxNYjU5T7gZh9//a gUF+8mEDLrISeC2mjUCI6hIr3Yilnyk7grJXFCkkmaWoqzqAFuqyyOF8jbIw+mXJW7Lc X//g==
X-Gm-Message-State: APjAAAWd9kQLn+u28ZlUjyzOBbf6LXzkHE1N4HMJyewyHpLj9ekf+Vs8 UuMxKhJE7bFF2gsqPcgz54seHcaTQGHbxrwrwZ7alg==
X-Google-Smtp-Source: APXvYqz6NSoNppKbgnBa1mpEAj4OSTCXIOmElC1YPuehv7EaDPbMBm5RAatpurYSJ5s/6fACMl2nE8Q8EEtwx/zHDFA=
X-Received: by 2002:a9d:754a:: with SMTP id b10mr1187974otl.273.1576655063532; Tue, 17 Dec 2019 23:44:23 -0800 (PST)
MIME-Version: 1.0
References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <CAO_FVe4jYtrCiGAFSKQo2UF2WDCu8Yf8ww9_biMoW4TJPQ2Qpw@mail.gmail.com> <AE9BAC29-50B0-4DAD-B27D-02EC803537A9@amazon.com>
In-Reply-To: <AE9BAC29-50B0-4DAD-B27D-02EC803537A9@amazon.com>
From: Steinar Noem <steinar@udelt.no>
Date: Wed, 18 Dec 2019 08:44:12 +0100
Message-ID: <CAHsNOKfnuYaqMe2K2xU80cwreBHK6smROgyjYrQT6_goLuikKQ@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>, IETF oauth WG <oauth@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fed87f0599f59c47"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4JrkX74HMDFeP12d5ct9vv6sNIc>
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: Wed, 18 Dec 2019 07:44:29 -0000
Hi Vittorio! At HelseID we indicate the method that was used for client authentication in our ATs. For us, this is the case both with or without a user. If the client used a client-assertion for authentication we would give some indication about the key material that was used. In our case that would be either a x.509 enterprise certificate (that carries an organizational number) or a key-pair. We actually use a client analog to *amr*, as Anabelle suggests. These claims add value for the resources that rely on for several reasons, one being authorization policies for APIs that expose sensitive data. - Steinar tir. 17. des. 2019 kl. 02:28 skrev Richard Backman, Annabelle <richanna= 40amazon.com@dmarc.ietf.org>: > 1. Regarding AuthenticatedClient: > > Does a mobile app that uses Dynamic Client Registration to establish a > client secret count as an “authenticated client”? What if that registration > included an assertion signed by a trusted entity (e.g., device management > software) using a certificate that had been pushed to the device? Without > some kind of NIST LoA-style definition of “authenticated”, a single Boolean > “AuthenticatedClient” value is too ambiguous to be useful. However, I’m > skeptical that we could find consensus on what that definition should be, > and it may be better to define client analogs to `acr` and `amr` that > provide standard ways of expressing client authentication details without > getting prescriptive about what kind of authentication is “good enough.” > > > > 2. Regarding authentication session properties: > > I’m confused by the definitions given for `auth_time`, `acr`, and `amr`. > For `auth_time`, it says: > > > > “…its value will either remain the same for all the JWT access tokens > issued within that session or be updated to the time of latest > authentication if reauthentication occurred mid-session…” > > > > But the “For example” at the end of that definition implies that > `auth_time` will not be updated. The definitions for `acr` and `amr` say > the same, but also say that the “…same considerations presented for > auth_time apply…” What’s the intention here: are they fixed, updated, or is > it up to the deployment to decide? > > > > I’d like to better understand the use case for putting these in the access > token. If the RS is making authorization decisions based on these claims, > that implies that the RS cannot rely on the AS to determine (e.g., from the > requested scope) the required authentication method(s), freshness, etc. If > the AS could be relied upon for this, then presumably it would not issue > RTs and ATs for a scope without requiring the end user to meet the > appropriate authentication requirements. If this is the case, then the RS > must have a way to signal to the client (and then the AS) that a step-up > authentication is required. Is there an existing mechanism through which > they could do this? All I can come up with is cramming the information into > the scope attribute of a WWW-Authenticate challenge, but that has the same > scope opacity violation problem as described in this draft’s Security > Considerations. Without a clear way to express the step-up requirements, > this feels incomplete. > > > > 3. Regarding access tokens that are used to access different resource > servers: > Reading between the lines, I **think** the intention is that a JWT access > token that is intended to be used to access two different resources at two > different RSes should look something like: > > > > { > > "aud": "https://generic-resource-indicator.example.com/", > > "scope": "resource_foo resource_bar", > > ... > > } > > > And the expectation is that each RS should recognize that generic > audience. Is this correct? If so it seems to go against the spirit of > resource indicators as indicating the target or location of a resource. > It’s stretching that definition, at the very least. > > > > But as I said, I’m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth <oauth-bounces@ietf.org> on behalf of Vittorio Bertocci > <Vittorio=40auth0.com@dmarc.ietf.org> > *Date: *Monday, December 16, 2019 at 2:51 PM > *To: *IETF oauth WG <oauth@ietf.org> > *Cc: *"i-d-announce@ietf.org" <i-d-announce@ietf.org> > *Subject: *Re: [OAUTH-WG] I-D Action: > draft-ietf-oauth-access-token-jwt-03.txt > > > > 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 mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no |
- [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