Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Sascha Preibisch <saschapreibisch@gmail.com> Mon, 15 April 2019 16:21 UTC

Return-Path: <saschapreibisch@gmail.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 A625D1203AA for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2019 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7wOIp1ol2OeY for <oauth@ietfa.amsl.com>; Mon, 15 Apr 2019 09:21:23 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 DB1E01203A4 for <oauth@ietf.org>; Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id y10so27603694itc.1 for <oauth@ietf.org>; Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9vQar4S8xD941gw11gByKYu/1WGYO+zwSYJi9N4iA7Y=; b=Xxjq2Ubsp1lA81+QSmUltos9fHXo5GIClEqs+cZPw2JvK+xO1XtGK2aTaCZZSdauel mQevLSGhUBua+00cRhTI4T0z0ottWiL8I46eYihfXTuAJSTiVPZO1jjSpn5zglSgWzpA Sa1d4eRYyAYOFyXFwXV1dVW9TtQR+EOuoPc8bSTmlTx/5Lzfwj0nZXvdVZw3kmPY/ZTI vFqyK2QfrGeqDp7ohd2atkiL7jV/OS9lbSHmy1a9IW54j6NnhDmQLv4KbMZ53IwWdbz+ jozPIzDbObj2cgddFSoK6HOBkrT9JmAkzk8mlBwX2yNoWICYKjuO3A+SBfptfZVRaY8l oLog==
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:content-transfer-encoding; bh=9vQar4S8xD941gw11gByKYu/1WGYO+zwSYJi9N4iA7Y=; b=ROYTdmguH7EBm4OU0Ew36xMM0Xw27ul/JQRbkGSV4FBvB7nL84yY8VeyiJLcNBort0 c4TAdb+7TF7RTTuJp/OXx4jRla1Oqo5eqXzN7iQfLTp9K0l2hdB65BL7n1iI+navlNII BKWN+8qYFgk5wRJpQ1zbsM3alC+g7ahLAq1m30VCfDK1ZecJvk9//vauEcSvr1cciEwF Z2kfebWMrRZLLvoPloUrLViXk1sI8nsoS8HsbhJAUbSSdXgJaStA5xjbAAdli8Cdkj1r hEbKXN7uyMEr+SlTz9fpXCMyJ1CGgRgTzBS5EKbn7WfO0495xyAP6WWlJ+n2bpd1nb0c LQjQ==
X-Gm-Message-State: APjAAAUyZ5TectZj4RvxFKPxwYoQx+xkq8SYWILMp6pVnw3CB3eJ3jds R9+2IyH/2oVwV/l+iT9WU+i89FKPnffvSEhh7FR3y1aa
X-Google-Smtp-Source: APXvYqyN3Zs9QyEQ1WzDMwREFBnbRPVNJmrKk3SOL34mC6r8Zl7cl3ZtxAPH2vAfc4mGPf7eTSwv2Zp4quwpf0AvdH8=
X-Received: by 2002:a05:6638:258:: with SMTP id w24mr53052304jaq.85.1555345282097; Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
MIME-Version: 1.0
References: <AM6PR08MB36861CE2351D6922D5F8F91FFA2C0@AM6PR08MB3686.eurprd08.prod.outlook.com> <MW2PR00MB0396F840F48EFC98A28C61BCA62E0@MW2PR00MB0396.namprd00.prod.outlook.com> <TYAPR01MB44130A50284A47FC923B0AA3F92E0@TYAPR01MB4413.jpnprd01.prod.outlook.com> <CAP=vD9tCqoy9BtXEx5u2fzLji8_XN=pnO7QFmO-mczRQb_FPzQ@mail.gmail.com> <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>
In-Reply-To: <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>
From: Sascha Preibisch <saschapreibisch@gmail.com>
Date: Mon, 15 Apr 2019 09:20:20 -0700
Message-ID: <CAP=vD9tQDhrZeLOEAYhGhfeeJ5v08kNLBwXTV3nrELmSoyL2uA@mail.gmail.com>
To: "Schanzenbach, Martin" <martin.schanzenbach@aisec.fraunhofer.de>
Cc: IETF oauth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/UL46ue5CBnf7QgZZA_KmJl0KLGI>
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
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, 15 Apr 2019 16:21:26 -0000

Thanks, Martin!

I understand. I just think it is difficult to get this adopted if
clients now have to include the target resource in their request in
order to place that into the 'aud' field. Unless the client has
somehow registered its intended protected resources beforehand the
authorization server cannot set an appropriate value if it was not
passed in as a request parameter.

Thanks,
Sascha

Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin
<martin.schanzenbach@aisec.fraunhofer.de>de>:
>
>
>
> > On 10. Apr 2019, at 19:39, Sascha Preibisch <saschapreibisch@gmail.com> wrote:
> >
> > I am late in the game, but not too late I hope.
> >
> > I would like to see 'aud' be the requesting client_id. For identifying the the target resource, a 'resource' claim should be introduced. I am also suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the validation process will show if it is an access_token or not.
>
> "aud = client_id" would mean that, by definition, the JWT must not be presented to any other entity than the client. This makes only sense for the ID Token in OIDC I think.  OTOH, defining a JWT which can be presented by the client to the RS is the whole point of this draft.
> Also, the reason why it makes sense to introduce a new type is that an OIDC ID Token _could_ be mistaken for an AT (which it isn't).
> IMO it might even make sense to encourage the OIDC spec to change to jwt+id or something by extending the JWT spec.
>
> I also support the adoption.
>
> >
> > Last but not least, 'aud' (as resource identifier) should not be required. Requiring that, and the requested resource in the the token request, will require existing clients to be updated. Introducing jwt access_token should be transparent to clients.
> >
> > Thanks,
> > Sascha
> >
> >
> > On Wed., Apr. 10, 2019, 06:41 n-sakimura, <n-sakimura@nri.co.jp> wrote:
> > +1
> >
> > For that matter, explicit typing is good and I am a bit ambivalent on the use of `sub`.
> >
> > Also, I need to add the 4th consideration: Although the current privacy consideration is stating about the encryption, it is in relation to the end user exposure. In fact, the by-value access token when involving some PII is by definition leaking information and violating the data minimization principle. This should be clearly delineated. My gut feeling is that it should be encrypted unless it is certain that it does not include sensitive PII as judging whether a claim may form a PII is too hard for an average developer..
> >
> > -----Original Message-----
> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Anthony Nadalin
> > Sent: Wednesday, April 10, 2019 8:12 PM
> > To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
> >
> > I support adoption of this draft as a working group document with the following caveats:
> >
> > 1. These are not to be used as ID Tokens/authentication tokens 2. The privacy issues must be addressed 3. Needs to be extensible, much like ID-Token, can't be 100% fixed
> >
> >
> > -----Original Message-----
> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
> > Sent: Monday, April 8, 2019 10:07 AM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
> >
> > Hi all,
> >
> > this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  document following the positive feedback at the last IETF meeting in Prague.
> >
> > Here is the document:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=0
> >
> > Please let us know by April 22nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.
> >
> > Ciao
> > Hannes & Rifaat
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&amp;sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;reserved=0
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> Martin Schanzenbach
> Fraunhofer AISEC
> Department Service & Application Security
> Parkring 4, 85748 Garching near Munich (Germany)
> Tel: +49 89 3229986-193
> martin.schanzenbach@aisec.fraunhofer.de
> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
>