From nobody Wed Jan 6 04:54:39 2021 Return-Path: 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 8F6803A0858 for ; Wed, 6 Jan 2021 04:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nxHYM3py359w for ; Wed, 6 Jan 2021 04:54:37 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E8CF23A083E for ; Wed, 6 Jan 2021 04:54:36 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id o19so6348795lfo.1 for ; Wed, 06 Jan 2021 04:54:36 -0800 (PST) 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; bh=dyd54LuyXt1nJZIzjvf8JsdWqNrLgqiZQhCNZnH/rCw=; b=sOlyO2KRBa8jFbP069S9ovEFt00H9kVmcIVbMEAVqs1f3fNpONolXpU5g3CGE6mDRL EqN8dHTxhHWyN6XzcXYyzDd5iQy/IJENUYGPqRkrQk1sQi4qO/rwNYZXGsK/lVvEj9sd 5p7BYvGvATgqYG4epK8A3bjlCYSZbvsVR4kRiJaMeqf2Axqj9Bhu/6BAvmA7eLTnToaa rjZo7dCBBH+aKMNfMyxgu9ARz5IHgS12Y9/qBbG+9Tk36KEiQyZ59GxOW7y5kZEqf4K7 Bt+TqwjaL2ehjwXoNQ+37ToO1fJ4fehYPvEE7Uojz2P3M0qcZZng0codF6uFbU/TMi4U tRIw== 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=dyd54LuyXt1nJZIzjvf8JsdWqNrLgqiZQhCNZnH/rCw=; b=AzXYJf1waaGOPjeaPof5SYFhmwqlwGYIG1Qbvir8xKg3d8Mniek5N+BfVNLVRbjMHy qUR/cDrBaMBGdRzoL71wCX5TzzXIm4CCZUZWrRzEqBphVOsYxrE70Ke68H6wi9VIoJ3D 0sMCaMbaaQ9wmr70RAyUVMY+i4I/VEU+fiOKny/8IOd01KOGtBhDEqOcBeqawlGBEpiI eqxUyN4Sn+ZyzV1flihECoW5CMt42KsNYtbm3SBJ6CM2U3glmvkQBVec0tPBvTcXcBJ3 /ho9fX+I5HWY1yibxSCj3BDwOzR+NTSrTK+3uTB6P3AuHHCruqXayrOEWfraXXKyRImJ /Lfg== X-Gm-Message-State: AOAM530+adoOHibZ2ucwxM6KGr/b/rJi1kdx4qNDuLS/7pIJeavV2aO1 PrjtDOffT5iQKo6Vndx97XfdEUznAOTRxKm/4RWvS6nZ X-Google-Smtp-Source: ABdhPJxzoQE16xoA4Ri5e0R3AunGWcsC9TK/SRQ7g+C/JCZtxA9ogvfOP3Ktf1JrEM8qaBPzOE9fRSQqv6ZMEAhQAOE= X-Received: by 2002:a05:6512:63:: with SMTP id i3mr1843232lfo.170.1609937675122; Wed, 06 Jan 2021 04:54:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 6 Jan 2021 07:54:23 -0500 Message-ID: To: Dominick Baier Cc: oauth Content-Type: multipart/alternative; boundary="0000000000003c7c5605b83ad321" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:54:39 -0000 --0000000000003c7c5605b83ad321 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, Based on the feedback during the last interim meeting and on this list below, the WG has decided to adopt this draft as a WG document. Authors, When you have a chance, feel free to submit a new WG document. Regards, Rifaat & Hannes On Mon, Dec 14, 2020 at 5:02 AM Dominick Baier wrote: > +1 > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef ( > rifaat.s.ietf@gmail.com) wrote: > > All, > > This is a call for adoption for the following AS Issuer Identifier in > Authorization Response as a WG document: > > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re= sp/ > > Please, provide your feedback on the mailing list by Dec 22nd. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000003c7c5605b83ad321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

Based on the feedback during the l= ast interim meeting and on this list below, the WG has decided to adopt thi= s draft as a WG document.


Authors,<= /div>

When you have a chance, feel free to submit a new = WG document.

Regards,
=C2=A0Rifaat &= Hannes


On Mon, Dec 14, 2020 at 5:02 AM Dominick Baie= r <dbaier@leastprivilege.co= m> wrote:
+1
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

O= n 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (rifaat.s.ietf@gmail.com) wrote:

Al= l,

This is a call for adoption for the following AS Issuer Identifie= r in Authorization Response as a WG document:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-aut= h-resp/

Please, provide your feedback on the mailing list by Dec= 22nd.

Regards,
=C2=A0Rifaat & Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003c7c5605b83ad321-- From nobody Wed Jan 6 07:27:24 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 921693A0EA4; Wed, 6 Jan 2021 07:27:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <160994684356.20419.17530600923773119329@ietfa.amsl.com> Date: Wed, 06 Jan 2021 07:27:23 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:27:24 -0000 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 : OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response Authors : Karsten Meyer zu Selhausen Daniel Fett Filename : draft-ietf-oauth-iss-auth-resp-00.txt Pages : 10 Date : 2021-01-06 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-00.html 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/ From nobody Thu Jan 7 04:23:48 2021 Return-Path: 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 8E8273A1028 for ; Thu, 7 Jan 2021 04:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit.de 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 YUPz3thGoKyW for ; Thu, 7 Jan 2021 04:23:44 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4315E3A1026 for ; Thu, 7 Jan 2021 04:23:43 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id r3so5472029wrt.2 for ; Thu, 07 Jan 2021 04:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=to:references:cc:from:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=2+bkfqjmaYnRXJj6V3UwCn4utIMYR4PccISMA0zF65E=; b=f83/8ZCtXlbOgS5L/v/AROe9bZpAzOdKEjrkTmaBfs9ur3DauaIXqUgJi1S6v0tXaf mURdGZRO1cIWxOxd0b1r6hFSqldqQbfiMwoFtKA43YkB7L4Spl9VK2D9Pxghh26uff6p bA9Q0abetcnT4FDJUAqy6KuMUg0IMxaw0o5UMRGHV8h1SvYF3vYzDcepsyDAL0UQpaCr iC3jRzCmPZ/s4uZmpCDCXPo6F2RBlEKcaIcqrGF/bbdLKu0IVwlwFmWGfp2geH1Re2y1 slE2WtQ7Ee1wVBGY4BI9gL0d063ix6SVEpXTxN9V8SwBIpNG24imebJUFGQxoFeb61WS YYBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:cc:from:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=2+bkfqjmaYnRXJj6V3UwCn4utIMYR4PccISMA0zF65E=; b=LSuFxmrsZqIiN/N226wwKqjTaiVeMsvHwyAI/GQeO6T2Wa24UhTN89JF9Lwgq4PpgJ l7ztp60ay7efta0J11DiuUPefApj6PFbwQCcTVP6VpDbqGpSUoJGLC2cAukwNM+GKkCf QiEO4cYBCd8AJtGaoJGrNsbR16h1slrggoAlAhrvjvlcb5PhmEP2Vl02qj/ykbbq4rJT rbNi/T6RtMshQBGpgQAfIZxQDedWzrNoJ3N0CaN/gm9SS1oL516aEEGcIOq2RfDPZ1vM SJLz0tI4Ufy5K+2T2DC4RsVJgozpOsXW2uBq9AchoUUyxqcSvLgutXLCfMw+E2CfKCcL vrmQ== X-Gm-Message-State: AOAM533ehsh6R0R22gj1uD2H5ZTs4PoPT//xCvk5ESCRsUpOkRq/RXPG MhxkaAIS6zd6lPDFKHrQbUrbpg== X-Google-Smtp-Source: ABdhPJy8VS3KiUhvUqoHXzp3md683RJ9Ez6K8EO3JekdLysMXb0gpIzcyXkTynsguwE80mhYyEVyPA== X-Received: by 2002:adf:db51:: with SMTP id f17mr8987466wrj.83.1610022222328; Thu, 07 Jan 2021 04:23:42 -0800 (PST) Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id a14sm7804020wrn.3.2021.01.07.04.23.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 04:23:41 -0800 (PST) To: oauth@ietf.org References: <160994684356.20419.17530600923773119329@ietfa.amsl.com> From: Karsten Meyer zu Selhausen Message-ID: <9e26909b-bacc-5ef4-20f2-64ec1d498175@hackmanit.de> Date: Thu, 7 Jan 2021 13:23:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <160994684356.20419.17530600923773119329@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5linv7022dUS0Ayb1DlhobhPgFL12aYPC" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 12:23:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5linv7022dUS0Ayb1DlhobhPgFL12aYPC Content-Type: multipart/mixed; boundary="iBPfZ6ZhtD0nzsX24mM2zUoAbsKU32G9n"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: oauth@ietf.org Cc: Daniel Fett Message-ID: <9e26909b-bacc-5ef4-20f2-64ec1d498175@hackmanit.de> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-00.txt References: <160994684356.20419.17530600923773119329@ietfa.amsl.com> In-Reply-To: <160994684356.20419.17530600923773119329@ietfa.amsl.com> --iBPfZ6ZhtD0nzsX24mM2zUoAbsKU32G9n Content-Type: multipart/alternative; boundary="------------89AFE684BFE6A025F6E4AC16" Content-Language: en-US This is a multi-part message in MIME format. --------------89AFE684BFE6A025F6E4AC16 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, thank you for your support and the comments/feedback on the draft so far.= The first official WG version does not contain any changes in comparison = to our individual draft version -02. We would like to ask you for further feedback and comments on the draft. Best regards, Karsten On 06.01.2021 16:27, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Web Authorization Protocol WG of the I= ETF. > > Title : OAuth 2.0 Authorization Server Issuer Identi= fier in Authorization Response > Authors : Karsten Meyer zu Selhausen > Daniel Fett > Filename : draft-ietf-oauth-iss-auth-resp-00.txt > Pages : 10 > Date : 2021-01-06 > > Abstract: > This document specifies a new parameter "iss" that is used to > explicitly include the issuer identifier of the authorization serve= r > in the authorization response of an OAuth authorization flow. If > implemented correctly, the "iss" parameter serves as an effective > countermeasure to "mix-up attacks". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-00.html > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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 --=20 Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Nehmen Sie an unserer n=C3=A4chsten Live Online-Schulung zur Sicherheit v= on OAuth und OpenID Connect am 27.01 + 28.01.2021 teil: https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-si= gn-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz --------------89AFE684BFE6A025F6E4AC16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,=

thank you for your support and the comments/feedback on the draft so far.

The first official WG= version does not contain any changes in comparison to our individual draft version -02.


We would like to ask = you for further feedback and comments on the draft.

Best regards,
Karsten

On 06.01.2021 16:27, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Web Authorization Protocol WG of the IET=
F.

        Title           : OAuth 2.0 Authorization Server Issuer Identifie=
r in Authorization Response
        Authors         : Karsten Meyer zu Selhausen
                          Daniel Fett
	Filename        : draft-ietf-oauth-iss-auth-resp-00.txt
	Pages           : 10
	Date            : 2021-01-06

Abstract:
   This document specifies a new parameter "iss" that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization flow.  If
   implemented correctly, the "iss" parameter serves as an effective
   countermeasure to "mix-up attacks".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf=
t-ietf-oauth-iss-auth-resp/

There is also an HTML version available at:
https://www.ietf.org/archive/id=
/draft-ietf-oauth-iss-auth-resp-00.html


Please note that it may take a couple of minutes from the time of submiss=
ion
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
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	htt=
ps://hackmanit.de | IT Security Consulting, Penetration Testing, Secu=
rity Training

Nehmen Sie an unserer n=C3=A4chsten Live Online-Schulung zur Sicherheit v=
on OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-l=
ive-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-=
01-28-01-2021

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
--------------89AFE684BFE6A025F6E4AC16-- --iBPfZ6ZhtD0nzsX24mM2zUoAbsKU32G9n-- --5linv7022dUS0Ayb1DlhobhPgFL12aYPC Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAl/2/UwFAwAAAAAACgkQRTXA59sW8Ugf ZA//dVgeT6ELV8lb0mew6JpGmZpDXfFHwZsdM1z8F2BuHEQhsxtDz1MPXJTbTPSeZOKPl1LyVrO/ 0sK1t45OGVyH++t8FiILhZ/yFt8TTsb2Q81ieIS+9IHWrB3mqvY3fBu0MPTAktSi0eLnzbFUykMJ j1wnRYgefljG/Go9q8p0h3SkT/LYDNj62JboGJIl4BMkjKbb0C4uZzxt2lhq4tX7FJOPeHv8sPwE wQpBu+vIcMWZvcRsk9sf5zrowRhcNI0HQjqsWsQ8ls69A5z3k4EkysiHF8XOaC15cUJ3R5URb5l0 PtTQnQKRiVlpVkBAuTRAeKhkNdIgAk8l+1724oMJdWneYCh3fBfGnwPcXh/64RaOE4aV3PbfGYED FxMLXoaON7yL4EO02QFUnsyqKnIrLV+d1bmyIfo6RsPuHlLAFLJjU8gCtvD+JNw1uX2SOdrQesyv JCPEqfwFdQDMsioPyuqtCGi9VXFKzMdtKrBexHca6ZiP60qxkvFbaK9/xTFBoutMpfLfZdeOilap KBok6DbdOhC6QSV7fzHpYYbwy9EoD0uABsGgfP3nUb0p4IHZP6+mIjTygId25sebstHZOYdZLvqF MxmzCj0b9VrZaLBpFBBabj7/F9T7Cvl8+uK/w3mGQhQ3ldkDyJH8lgwr+eAlR/ZS0Fmi0kLmYTwj nIY= =yWzB -----END PGP SIGNATURE----- --5linv7022dUS0Ayb1DlhobhPgFL12aYPC-- From nobody Sun Jan 10 17:36:45 2021 Return-Path: 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 244B43A146D for ; Sun, 10 Jan 2021 17:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=babelouest.org 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 OvL4m30wG2VZ for ; Sun, 10 Jan 2021 17:36:41 -0800 (PST) Received: from perceval.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9483A146C for ; Sun, 10 Jan 2021 17:36:40 -0800 (PST) Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-10-70-51-43-204.dsl.bell.ca [70.51.43.204]) by perceval.babelouest.org (Postfix) with ESMTPSA id 3BAEE2032B for ; Sun, 10 Jan 2021 20:36:38 -0500 (EST) Authentication-Results: OpenDMARC; dmarc=fail (p=quarantine dis=none) header.from=babelouest.org Authentication-Results: OpenDMARC; spf=fail smtp.mailfrom=nicolas@babelouest.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=babelouest.org; s=mail; t=1610328998; bh=hbh2Zysal+zJ9WYHX2d5xKZf7rphxixQ8qKHrTLvyso=; h=To:From:Subject:Date:From; b=kGCR7ZjJiYwxrnX1jtp+JPTE0CpzA2xoWOvYxDW8fEqiby/uxRJAigf0t81d6lZXJ GHG/DGR8E7q1pN+ZsnV3ssYaTcf0c7hpAs+zBRgrPhGe8w7WyR5IP3xKCJfWuL9EAE SnffW8SWrEiwZXgyhRTS5pxi21Ad/aC9WG1VZY9GA1sklhsruaPeKmWXHo+Met+TzO 0yP9C2HxNkvWYKxyPvqzL3S4lI7YlD5M9SVPwxNJDhagtvk/MiULWT4kVbK2gnT15i l3B1rVTsgFmi7P7J/R0mqY2SRe+k8W6iZCq5qsiuU2tsmrJjIOItQ5sc5fEWq3SRmf 5aBLdRTxyqxQA== To: oauth From: Nicolas Mora Message-ID: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> Date: Sun, 10 Jan 2021 20:36:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 01:36:43 -0000 Hello, I've implemented Rich Authorization Requests defined in draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I humbly wanted to write my feedback about this implementation to share my experience. For starters, this implementation and my following feedbacks are based on the prism of Glewlwyd's implementation and philosophy, and my limited experience on OAuth2, so I appologize in advance if I write non-sense or big mistakes. 1 - Design The way I saw it, there are 2 different approaches to implement oauth2 rar: either to get a token with a more detailed scope, or to get a one-time token with extra grants. Both are not exclusive, but a big difference I see between those 2 approaches is the grant access from the user part. The second approach would require the user to know what extra grant is asked by the client every time the client asks for it, i.e. when the client redirects the user to the /authorization endpoint. To be more consistent with Glewlwyd's philosophy, I chose the first approach, with those rules. The AS administrator declares what rar types are allowed [2] - a rar type has a defined set of locations, actions, datatypes and enriched authorization details that the client can ask for - the client must be explicitly allowed to add a rar type in the authorization request - a rar type can be linked to one or more scope. In that case, the authorization request must include at least one of the linked scope, and the scope must be available for the user and the scope must be granted to the client - the client can add as many properties as required in the rar type, those extra properties are not verified by the AS, on access granted, the extra properties will be present in the "authorization_details" result. On first use of a rar type by a client for a user, the user must grant to the client the rar access [3]. That's why the grant message will show to the user ALL access possible via this rar type Once this access is granted or not, the user will not be asked again on another authorization request by the client (but is can be changed at any time, as a scope grant). 2 - Limitations In this design, the AS has a limited control over the authorization_details content, and the trust between the AS and the client must be high enough so if a rar type can gain access to sensitive actions or information, the user should know about it. Also, in the draft specification, the only mandatory element type in a rar is the "type" element. In my point of view, this means that the business logic is mostly defined by the RS, rather than the AS. Therefore, for a client implementation to be compliant with the specs, there's not much to do: add as a parameter a JSON array with objects containing at least one "type" string property in it. 3 - Extensions I believe one way to mitigate these limitations is to allow extensions to be defined on top of the rar specifications. An extension can be declared like this: "RAR Extension XYZ: A rar whose type is XXX - Actions available: YYY, ZZZ or AAA - datatypes possibles: BBB, CCC, DDD or EEE - additional elements mandatory: an array of FFF and an object of GGG to represent access to some" Like this, if the AS, the RS and the client agree on using a rar extension, they can have at least a detailed pattern on what to expect in the rar type. Any thoughts? /Nicolas [1] https://github.com/babelouest/glewlwyd [2] https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/plugin-oidc-rar.png [3] https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/login-rar-grant.png From nobody Tue Jan 12 02:30:43 2021 Return-Path: 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 B06803A105E for ; Tue, 12 Jan 2021 02:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u_5i8Sgd-vsN for ; Tue, 12 Jan 2021 02:30:39 -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 72AF43A105D for ; Tue, 12 Jan 2021 02:30:39 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id i6so1813655otr.2 for ; Tue, 12 Jan 2021 02:30:39 -0800 (PST) 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; bh=16rsWVEFLLP/0luj42rg9yGNh/kuJNbmQFocOgeIkSA=; b=mTquik4r8fw7ILdWqFtsyBZfSbeMBe5pOa7ReXerAhIbilyNALpdGHp9qBYBi1sY/N hrARiguWJFDvHeaMms7qK5jM7CcMpShUxDI9CFxgSf2Lj4gxTQwN5DekXA23aTjT1Ves v+MW88YcTACkRBNFDMKnndtXIdDoUxxjLIHVXd5p27+dF6+YVJBGydMbY6KPNvwhgTja GrAqRgDfNy/OPqXzJF0DMl+Vrcp3zJKkTmhld48dkaxEm+jc0htbglkRpgPDDrpNr0Ef AftEmkXUQk1RjT3pE9lzA1W+K6D4I2aowXwd63iAWJ2ONC1dVrtGWQCenPZAuJfr2FPf TQCA== 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; bh=16rsWVEFLLP/0luj42rg9yGNh/kuJNbmQFocOgeIkSA=; b=qlLy/ZtSh+bKSqfzozwFnm/RMBBnZOcQw/L+S8Ccu2cW+KyxzaUz8v+8ET16ywMnfm gMlC3wqkNVzJMsJRTuVW+Yy6bS4t5bsKOcK6ntyHxgqqjPgN/5AYAnPzqU1ol0DUZ2cQ azFZqLLgEIG5QUGCK5xKr3V9WEC0BKPxBoZt6kEyFK7kq2CvnMfzYkxgFUz7dWRadTS4 goivw9h0qb6JQt/JOdNvK0tHU8Q1rTUzGGCkA7a81fxFxWRj13kM0D2nkWNwl1uRAg6R Woa4df7rzV05E1J6ITJvbcrOu4wT388thzvu/3eu/LcyZs1Y7Y/co5SIg5jE+jQLjMGO /TaA== X-Gm-Message-State: AOAM531fihoz3fHCX68ogTDWSsVTpPbClKEdMrLT9sLRRTP4VXt4ABlP dp46HR4eZAb+KCLbl/P5K7WxNtBOnKdFHLl8+a5S1A1goyE= X-Google-Smtp-Source: ABdhPJyjN/+nZyeZodYIo6cnyz2lrJOR9VchiMGUY3PwTkn2rfk/rHod42AEQClZzOSJLRyb1qEeFRYcpVJuWvm9fu8= X-Received: by 2002:a9d:3985:: with SMTP id y5mr2269507otb.202.1610447438494; Tue, 12 Jan 2021 02:30:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?7J207LKc7Jqx?= Date: Tue, 12 Jan 2021 19:30:27 +0900 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000803f0b05b8b18379" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 147, Issue 3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 10:30:42 -0000 --000000000000803f0b05b8b18379 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You send not mail please Loose mail only Please send not mail 2021=EB=85=84 1=EC=9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 5:02, <= oauth-request@ietf.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Rich Authorization Requests feedbacks on implementation > (Nicolas Mora) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Jan 2021 20:36:36 -0500 > From: Nicolas Mora > To: oauth > Subject: [OAUTH-WG] Rich Authorization Requests feedbacks on > implementation > Message-ID: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > > Hello, > > I've implemented Rich Authorization Requests defined in > draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I > humbly wanted to write my feedback about this implementation to share my > experience. > > For starters, this implementation and my following feedbacks are based > on the prism of Glewlwyd's implementation and philosophy, and my limited > experience on OAuth2, so I appologize in advance if I write non-sense or > big mistakes. > > 1 - Design > > The way I saw it, there are 2 different approaches to implement oauth2 > rar: either to get a token with a more detailed scope, or to get a > one-time token with extra grants. > > Both are not exclusive, but a big difference I see between those 2 > approaches is the grant access from the user part. The second approach > would require the user to know what extra grant is asked by the client > every time the client asks for it, i.e. when the client redirects the > user to the /authorization endpoint. > > To be more consistent with Glewlwyd's philosophy, I chose the first > approach, with those rules. > The AS administrator declares what rar types are allowed [2] > - a rar type has a defined set of locations, actions, datatypes and > enriched authorization details that the client can ask for > - the client must be explicitly allowed to add a rar type in the > authorization request > - a rar type can be linked to one or more scope. In that case, the > authorization request must include at least one of the linked scope, and > the scope must be available for the user and the scope must be granted > to the client > - the client can add as many properties as required in the rar type, > those extra properties are not verified by the AS, on access granted, > the extra properties will be present in the "authorization_details" resul= t. > > On first use of a rar type by a client for a user, the user must grant > to the client the rar access [3]. That's why the grant message will show > to the user ALL access possible via this rar type > Once this access is granted or not, the user will not be asked again on > another authorization request by the client (but is can be changed at > any time, as a scope grant). > > 2 - Limitations > > In this design, the AS has a limited control over the > authorization_details content, and the trust between the AS and the > client must be high enough so if a rar type can gain access to sensitive > actions or information, the user should know about it. > > Also, in the draft specification, the only mandatory element type in a > rar is the "type" element. In my point of view, this means that the > business logic is mostly defined by the RS, rather than the AS. > > Therefore, for a client implementation to be compliant with the specs, > there's not much to do: add as a parameter a JSON array with objects > containing at least one "type" string property in it. > > 3 - Extensions > > I believe one way to mitigate these limitations is to allow extensions > to be defined on top of the rar specifications. An extension can be > declared like this: > > "RAR Extension XYZ: > A rar whose type is XXX > - Actions available: YYY, ZZZ or AAA > - datatypes possibles: BBB, CCC, DDD or EEE > - additional elements mandatory: an array of FFF and an object of GGG to > represent access to some" > > Like this, if the AS, the RS and the client agree on using a rar > extension, they can have at least a detailed pattern on what to expect > in the rar type. > > Any thoughts? > > /Nicolas > > [1] https://github.com/babelouest/glewlwyd > [2] > > https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screens= hots/plugin-oidc-rar.png > [3] > > https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screens= hots/login-rar-grant.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 147, Issue 3 > ************************************* > --000000000000803f0b05b8b18379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You send not mail please
Loose mail only=
Please send not mail=C2=A0

2021=EB=85=84 1=EC= =9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 5:02, <oauth-request@ietf.org>=EB=8B=98=EC=9D= =B4 =EC=9E=91=EC=84=B1:
Send OAuth = mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Rich Authorization Requests feedbacks on implementation
=C2=A0 =C2=A0 =C2=A0 (Nicolas Mora)


----------------------------------------------------------------------

Message: 1
Date: Sun, 10 Jan 2021 20:36:36 -0500
From: Nicolas Mora <nicolas@babelouest.org>
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Rich Authorization Requests feedbacks on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation
Message-ID: <511128bf-348f-fc92-ddf1-95= 98502a20a9@babelouest.org>
Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed

Hello,

I've implemented Rich Authorization Requests defined in
draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I humbly wanted to write my feedback about this implementation to share my experience.

For starters, this implementation and my following feedbacks are based
on the prism of Glewlwyd's implementation and philosophy, and my limite= d
experience on OAuth2, so I appologize in advance if I write non-sense or big mistakes.

1 - Design

The way I saw it, there are 2 different approaches to implement oauth2
rar: either to get a token with a more detailed scope, or to get a
one-time token with extra grants.

Both are not exclusive, but a big difference I see between those 2
approaches is the grant access from the user part. The second approach
would require the user to know what extra grant is asked by the client
every time the client asks for it, i.e. when the client redirects the
user to the /authorization endpoint.

To be more consistent with Glewlwyd's philosophy, I chose the first approach, with those rules.
The AS administrator declares what rar types are allowed [2]
=C2=A0 =C2=A0- a rar type has a defined set of locations, actions, datatype= s and
enriched authorization details that the client can ask for
=C2=A0 =C2=A0- the client must be explicitly allowed to add a rar type in t= he
authorization request
=C2=A0 =C2=A0- a rar type can be linked to one or more scope. In that case,= the
authorization request must include at least one of the linked scope, and the scope must be available for the user and the scope must be granted
to the client
=C2=A0 =C2=A0- the client can add as many properties as required in the rar= type,
those extra properties are not verified by the AS, on access granted,
the extra properties will be present in the "authorization_details&quo= t; result.

On first use of a rar type by a client for a user, the user must grant
to the client the rar access [3]. That's why the grant message will sho= w
to the user ALL access possible via this rar type
Once this access is granted or not, the user will not be asked again on another authorization request by the client (but is can be changed at
any time, as a scope grant).

2 - Limitations

In this design, the AS has a limited control over the
authorization_details content, and the trust between the AS and the
client must be high enough so if a rar type can gain access to sensitive actions or information, the user should know about it.

Also, in the draft specification, the only mandatory element type in a
rar is the "type" element. In my point of view, this means that t= he
business logic is mostly defined by the RS, rather than the AS.

Therefore, for a client implementation to be compliant with the specs,
there's not much to do: add as a parameter a JSON array with objects containing at least one "type" string property in it.

3 - Extensions

I believe one way to mitigate these limitations is to allow extensions
to be defined on top of the rar specifications. An extension can be
declared like this:

"RAR Extension XYZ:
A rar whose type is XXX
- Actions available: YYY, ZZZ or AAA
- datatypes possibles: BBB, CCC, DDD or EEE
- additional elements mandatory: an array of FFF and an object of GGG to represent access to some"

Like this, if the AS, the RS and the client agree on using a rar
extension, they can have at least a detailed pattern on what to expect
in the rar type.

Any thoughts?

/Nicolas

[1] https://github.com/babelouest/glewlwyd
[2]
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/s= creenshots/plugin-oidc-rar.png
[3]
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/s= creenshots/login-rar-grant.png



------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 147, Issue 3
*************************************
--000000000000803f0b05b8b18379-- From nobody Tue Jan 12 08:20:40 2021 Return-Path: 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 08F1B3A0ADF for ; Tue, 12 Jan 2021 08:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mendix.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 gn2GzQEHff26 for ; Tue, 12 Jan 2021 08:20:36 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40089.outbound.protection.outlook.com [40.107.4.89]) (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 61E6A3A0AD6 for ; Tue, 12 Jan 2021 08:20:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GJjTqlkDP+UHZwSfVeSvMYAM/h81PapkEX7mZ0fRPI5z/Rn/Y4YL886GyG7d3+7VBFghXGGUiS32J6fXP8K4mqNW8Z8zdNjtRoq7OOxztslnBYEUQ/MMVJ4/Nh7Ul2J//Au09B5mDAV+qMuApBnwI1jX1RHznFi+ccejx5ab5bDHZbV43pHSPsC927D8NXsCKdN1eqML4mxcoVbvHUj/wVyMvfwPZQkR7iHrkB6JRgJhFHSz1D8fgaFOrOzcm+3bTxSzYGkUPSqM2qRETH8tt7nDHn2PbBF8zkg1DFVuE9qolNhrzMciDi+5xbmeXgPqWbdZcIDQ1vBLqbNnh2f3SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMZgJqEw9CZmf3S0402JdtMiu6hwH+zTUS26v9CbaxQ=; b=egdcxKC1qSDJ0suAp7u7q3YcHeDgNdnitlW/WmE3NI0pZ+GcZfmSQH36rcEziRkIxYuj4NMw+IIKxxp6AjcvbhF85UEKwnNh5PfMrvVpGz9rQev4mdg6S0813QtsTUvBU1mxMMSWXBLO//u/avyRDcgeobbZ3NFWg6RUAdKwadNE9K4tXA6h1QNR4wTl//RuJi/zGefJYMyxKVhCzR1MpzoK75eUymD5gWJZGbTsHR2I69/oz3I7TVXoQVlsdDuIPBGFArwPsgETgp49a1N0DCMexSc6YmbwnMCGlQooXRXrXlU3jii2gndX21xjv5oBTopFoBzloXF1MQ3I5kdT0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mendix.com; dmarc=pass action=none header.from=mendix.com; dkim=pass header.d=mendix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mendix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMZgJqEw9CZmf3S0402JdtMiu6hwH+zTUS26v9CbaxQ=; b=b+4II8+JMoo3OHXGbG6yqXlOHhDy/cYAu0h7xVChp1kCWeR/xFyzBjT0vum7SSubfu0dQi3Y9HnLyxcuccqIp3gX+wMaj4ui0yAfnd2z0xSKvpVNUm7iUsn6ZSB8jj9GXl2UfBicXi6EoOU1fAD3GjvfgxClmjhwzPZCcbQuLe8= Received: from AM0PR06MB4180.eurprd06.prod.outlook.com (2603:10a6:208:7a::24) by AM0PR06MB6098.eurprd06.prod.outlook.com (2603:10a6:208:16c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Tue, 12 Jan 2021 16:20:33 +0000 Received: from AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e]) by AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e%5]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 16:20:33 +0000 From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: Tenancy in OAuth Thread-Index: AQHW6P7Zj57BpwaMUkmxUfMvbyRPgg== Date: Tue, 12 Jan 2021 16:20:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mendix.com; x-originating-ip: [86.84.216.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9427ecad-5e6d-497b-fb78-08d8b715fc93 x-ms-traffictypediagnostic: AM0PR06MB6098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GisEu1V5kf69nkJm9Hy+RSYB5Al+4g4azZDmFw0dKEbh5cs9xeknR7YCl2mlEnrOEB4LBCSUcqHte7s8zPFVzPvkfamOp/w7sgHs3gr1ixS8uLek5Ee6174+m2a92Z+rjDEy4VsnZPJAfgYlu78aRFI6xVGJg65jXxeutJstnaN2CEu5FLpeWTLb69hxEoeDjhcjwy0RcatFvCFwUe+Y8pF3tDXzY40NLtWfVQJQwyiFKib0ohfe3LMDnIQ16FiCq7VOivNPBV+yV/VRualJ0DWsoArwXmbrwL5M74Ne9yvP/F+Z20VxIIFpTgQ5bXHQpiYSoVL7EzcPzbPqZZn+/6j29bxF7xQVEFuDp0YQW9XLh3uMDLfWoP6oh7PhqChK9G0Y+hHrCqej6helPGvvFbi6ITFimiS2ZcQzeX6b6et18etkSl9JRZdiko1dJAZE14++dvuCmW8EVXsbz801iA6pSerEFhLrvCpCN1wGqJ1vVsmP1Vi96XM1yb2TcVvAyWlsRn7QzIFTxoLzrYvIgw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR06MB4180.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(3480700007)(5660300002)(71200400001)(66556008)(64756008)(66446008)(66476007)(76116006)(498600001)(66946007)(36756003)(33656002)(66616009)(26005)(8676002)(99936003)(186003)(8936002)(6486002)(4744005)(6506007)(6512007)(166002)(86362001)(6916009)(2616005)(2906002)(7116003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?emYyMG9HU3RhUlBUbXBQQU0zeGJMRDk0VkZZdWxTZm8vd0Joc2dDZ1AxNXFN?= =?utf-8?B?clM1R3lnWVoyb2RkOG5aWkRyTmxvMlYxNFYrRng5NWs1aklmajlHd0p5OEVo?= =?utf-8?B?WE9POUJkL2E5eExkc2xrUS80YWhxcXZvVERzUEo0UVRyQTVmWDhnN2NPUU9I?= =?utf-8?B?Rk12V09LQ0ZDM1hJU2ZiTWV5TGN1SlR5S1FqR2tKWGJzeXd3aFFyUUU3QnRS?= =?utf-8?B?bUJ4OENieVdSQi94WExML3ZLSlV6b2ltdmxqVTB3dS9SZmVJTHkzeEhyYnJa?= =?utf-8?B?UzJ6N2NkUjlLYk1way9ZMkhTbm5SNDFIQjZ0ZndicGh1YXNhVHZ2TGZDcWlw?= =?utf-8?B?YUpYTUFoQkhoQ1cvYzl2WHdWNHh1SzNKM2ZWK21nNUQwVzRLckRXajhJc0FF?= =?utf-8?B?bWpRdTNBMjRieUlvcURWUFRPQ2tIOXdkdnVNcm9qRUU1QkFqdmdQQWZxK2xx?= =?utf-8?B?TTVuZSszTzdmWU91TlFVek1FcjNUMDhuUnVQeVN3bEh5RnZJUmpRNGJuSDJh?= =?utf-8?B?aTFmb0FNZ3pTeWwzL2NqWVVZY0FKWERPSkJGZnNRSjFSdkhCdG84QkZDclEz?= =?utf-8?B?QnExUHd2ZUx3a2ZkcmE2NkRaL1Z4R1p1NW9nMTFqdkg4SmEzUUpsOGRNcE1G?= =?utf-8?B?UXZGQ20yaDY1RTNZSWdJTnMzRWdiVkRYbVVIQXdNVTBPcWJxaDNyQ1d6OUZi?= =?utf-8?B?dk5Td1VkNTZaeE5Bb2pqS0xVNlJsK1VSWTZkdTNabEFncUtWcUo2My8xUGg5?= =?utf-8?B?OTJQR3dHQXJSQllFeDNiYkdhamJVdTFseTBoYTRGbXlmbDlqSytjVXFLclZw?= =?utf-8?B?ZEVSZ3ZCMzFmTEQxM0psajNxSEtFVS9HZ3RHRi95UFNxYmdPaG14KzM1MU96?= =?utf-8?B?Um9Hd1Vjemw4QlRRVy9JQ05qZUROUkEyV3E0K01vc05kdCtFd09ZQkdpMnRC?= =?utf-8?B?bzhISll4bHFLWFR3V3VKc2lFcjczb3RwRVlRVG5vbW1laDhLaXkzM1JWRFZF?= =?utf-8?B?NUVZTWJ3SjRFSndTQUU3Y2ExQS9OTGhaR2RMYjBVcDVtbCtWTTVGUjUwa1Bl?= =?utf-8?B?S3U4TFdSL0RYTGdtcXMrRzdBWGVyeFNQWHJYTjJPbmh1K0hRL0xPd09tNzE0?= =?utf-8?B?emtvRUdxMHhzSDN5MWkwTHdKS0dEMXBoTzRMTVp0ZStEN3REWnBXWUIvQU5D?= =?utf-8?B?blZ4cm5QTjU3SnN2MTV1RnJ0b2ZrOWR4bHZwSjhYUVlLaEkyc04yMjkzV1A2?= =?utf-8?B?aDE3eVhhWmFzWFRuclU3Wm5NeUFRbjZFUGk3b3ovSlEvbUNSMkcxTVRiUGgz?= =?utf-8?Q?3xc5ECvc7FeWNcPHzLUlZemMSqLdw6M5RF?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_A643E85AB4B0437BAB7680BF3F795983mendixcom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: mendix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR06MB4180.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9427ecad-5e6d-497b-fb78-08d8b715fc93 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 16:20:33.1388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e3c78d-8e3b-46d8-bc56-5540da23ba4d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8KoBUwd9RvbFUPA91jeJgiyJALYk/QFOymaZ0t/AnOds1+Ye5bCYDLgS0r+0sbgFhLpuw9NqX6QBAsuhvzpKmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB6098 Archived-At: Subject: [OAUTH-WG] Tenancy in OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 16:20:39 -0000 --_004_A643E85AB4B0437BAB7680BF3F795983mendixcom_ Content-Type: multipart/alternative; boundary="_000_A643E85AB4B0437BAB7680BF3F795983mendixcom_" --_000_A643E85AB4B0437BAB7680BF3F795983mendixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCknigJltIGxvb2tpbmcgaW50byB0aGUgdG9waWMgb2YgdGVuYW5jeS4gQSBtdWx0aS10 ZW5hbnQgc2VydmljZSBjYW4gYmUgY29uc2lkZXJlZCBhcyBhbiBPQXV0aCBSZXNvdXJjZSBTZXJ2 ZXIgbWFuYWdpbmcgcmVzb3VyY2VzIG9mIGRpZmZlcmVudCB0ZW5hbnRzLg0KQW4gQVMgbWFrZXMg YXV0aG9yaXphdGlvbiBkZWNpc2lvbnMgYW5kIGNvbW11bmljYXRlcyB0aGVzZSB1c2luZyBzY29w ZXMsIHNvIG9uZSB3YXkgd291bGQgYmUgdG8g4oCYZW5jb2Rl4oCZIHRoZSB0ZW5hbnQgaW50byB0 aGUgc2NvcGUgdmFsdWVzLg0KQW5vdGhlciBsaW5lIG9mIHRob3VnaHQgaXMgdG8gc29tZWhvdyBi aW5kL3Jlc3RyaWN0IGFuIGFjY2VzLXRva2VuIHRvIGEgY2VydGFpbiB0ZW5hbnQsIGxlYXZpbmcg dGhlIHNldCBvZiBzY29wZXMgYmVpbmcgdXNlZCBtb3JlIHN0YXRpYy4NCg0KTXkgcXVlc3Rpb24g aXMgd2hldGhlciB0aGlzIGhhcyBiZWVuIGEgdG9waWMgdGhhdCBoYXMgYmVlbiBhZGRyZXNzZWQg aW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXA/IEFueSBjb21tb24gcHJhY3RpY2Ugb3IgZHJhZnQ/ DQpUaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciByZXBsaWVzLg0KDQpLaW5kIHJlZ2FyZHMsDQoN CkphYXAgRnJhbmNrZQ0KUHJvZHVjdCBNYW5hZ2VyIElkZW50aXR5DQorMzEoMCk2NDE0OTUzMjQN Cm1lbmRpeC5jb20NCltzaWduYXR1cmVfODI3NzE0MzI3XTxodHRwOi8vd3d3Lm1lbmRpeC5jb20v Pg0KDQoNCg== --_000_A643E85AB4B0437BAB7680BF3F795983mendixcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0DD3AE0A3D9C1D47B9AFCAAF37854B29@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iZW4tTkwiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJlt IGxvb2tpbmcgaW50byB0aGUgdG9waWMgb2YgdGVuYW5jeS4gQSBtdWx0aS10ZW5hbnQgc2Vydmlj ZSBjYW4gYmUgY29uc2lkZXJlZCBhcyBhbiBPQXV0aCBSZXNvdXJjZSBTZXJ2ZXIgbWFuYWdpbmcg cmVzb3VyY2VzIG9mIGRpZmZlcmVudCB0ZW5hbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbiBBUyBtYWtlcyBhdXRob3Jp emF0aW9uIGRlY2lzaW9ucyBhbmQgY29tbXVuaWNhdGVzIHRoZXNlIHVzaW5nIHNjb3Blcywgc28g b25lIHdheSB3b3VsZCBiZSB0byDigJhlbmNvZGXigJkgdGhlIHRlbmFudCBpbnRvIHRoZSBzY29w ZSB2YWx1ZXMuPGJyPg0KQW5vdGhlciBsaW5lIG9mIHRob3VnaHQgaXMgdG8gc29tZWhvdyBiaW5k L3Jlc3RyaWN0IGFuIGFjY2VzLXRva2VuIHRvIGEgY2VydGFpbiB0ZW5hbnQsIGxlYXZpbmcgdGhl IHNldCBvZiBzY29wZXMgYmVpbmcgdXNlZCBtb3JlIHN0YXRpYy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhpcyBoYXMgYmVlbiBhIHRvcGljIHRoYXQgaGFzIGJl ZW4gYWRkcmVzc2VkIGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwPyBBbnkgY29tbW9uIHByYWN0 aWNlIG9yIGRyYWZ0Pzxicj4NClRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIHJlcGxpZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMy44cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuOHB0Ij48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjhwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+SmFhcCBGcmFuY2tlPC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Q cm9kdWN0IE1hbmFnZXIgSWRlbnRpdHk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuOHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4rMzEoMCk2 NDE0OTUzMjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7bGluZS1oZWlnaHQ6MTMuOHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5t ZW5kaXguY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjhwdCI+PGEgaHJlZj0iaHR0cDovL3d3dy5tZW5kaXguY29t LyIgdGl0bGU9Imh0dHA6Ly93d3cubWVuZGl4LmNvbS8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzU1NTU1NTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt0ZXh0LWRlY29y YXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNTYiIGhlaWdodD0iNDEiIHN0eWxl PSJ3aWR0aDoxLjYyNWluO2hlaWdodDouNDI3aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0i Y2lkOmltYWdlMDAxLnBuZ0AwMUQ2RTkwNy4zQjFGMDVBMCIgYWx0PSJzaWduYXR1cmVfODI3NzE0 MzI3Ij48L3NwYW4+PC9iPjwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy44cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzU1NTU1NTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0Ii PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A643E85AB4B0437BAB7680BF3F795983mendixcom_-- --_004_A643E85AB4B0437BAB7680BF3F795983mendixcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=9765; creation-date="Tue, 12 Jan 2021 16:20:32 GMT"; modification-date="Tue, 12 Jan 2021 16:20:32 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArcAAAC7CAYAAAB/wLYlAAAACXBIWXMAADWsAAA1rAFe8plaAAAF IGlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0w TXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRh LyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMxNDUgNzkuMTYzNDk5LCAyMDE4LzA4LzEz LTE2OjQwOjIyICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0i IiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRw Oi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMu YWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNv bS94YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9z VHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ0Mg MjAxOSAoTWFjaW50b3NoKSIgeG1wOkNyZWF0ZURhdGU9IjIwMTktMDQtMTVUMTQ6NDM6MTMtMDQ6 MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDE5LTA0LTIzVDE0OjAyOjI3LTA0OjAwIiB4bXA6TWV0YWRh dGFEYXRlPSIyMDE5LTA0LTIzVDE0OjAyOjI3LTA0OjAwIiBkYzpmb3JtYXQ9ImltYWdlL3BuZyIg cGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhvdG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5 NjYtMi4xIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjVkYWE0NzA4LTRhNWQtNDczMy1hMWZi LTU5NTYyOWUyOTMxZCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDo1ZGFhNDcwOC00YTVkLTQ3 MzMtYTFmYi01OTU2MjllMjkzMWQiIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0ieG1wLmRpZDo1 ZGFhNDcwOC00YTVkLTQ3MzMtYTFmYi01OTU2MjllMjkzMWQiPiA8eG1wTU06SGlzdG9yeT4gPHJk ZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4 bXAuaWlkOjVkYWE0NzA4LTRhNWQtNDczMy1hMWZiLTU5NTYyOWUyOTMxZCIgc3RFdnQ6d2hlbj0i MjAxOS0wNC0xNVQxNDo0MzoxMy0wNDowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhv dG9zaG9wIENDIDIwMTkgKE1hY2ludG9zaCkiLz4gPC9yZGY6U2VxPiA8L3htcE1NOkhpc3Rvcnk+ IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5k PSJyIj8+f5LirAAAIKZJREFUeJzt3T+z20a65/GfvQ42O9RGmwlXN9hQqNLm5lZpYp8NfFNxE004 3MiTDSbzjYYbyompdG5wObFdNVAu1UAvwB7oDdg4r4AbNGGCPPwDgE+j8ef7qeqSdER0Pw3ikA8f NoDPZCvetUjS3LhvjF8hKau0PFgkAABgkD4z6OO+0u4M+gNKnyRtJK3lkl0AAAAvZpISucralkbr oGWSFgIAADC2kPv6OHSyQ5tmy8SSFwAAYCCSlCp8ckOjbSWt5L5BAAAAaOxeVGtp/WuZ3AmMAAAA tS0VPomh0c61QiS4AACgprXCJy802rVWyH27AAAAJu7SpcAWkr7vKA7gVg9yJ5plYcMAAAAhnUtu 7yX9Z4dxABYe5JYo5GHDAAAAoZxKbiO56tddp5EANj6KNbgAAEzWfznxs42k/9FxHICV/y73oS0N HAcAAAjguHK7EOtsMXwsTwAAYKKOK7cbcWF8DN9/lfRE7ngGAAAT8nnl7wtJTwPFAVh7Jbd+HAAA TEi1crsRVVuMC9VbAAAmplxzG0v6R8A4AB8exAc2AAAmpVyWsAgZBODJnbhzGQAAk1Imt/chgwA8 ug8dAAAA6M7ncifdcCIZxioOHQAAAOhOmdwCY/U8dAAAAKA7n0uahw4C8GweOgAAANCNz68/BAAA ABgGKreYgjh0AAAAoBtUbjEFs9ABAACAbpDcAgAAYDRIbgEAADAaJLcAAAAYDZJbAAAAjAbJLQAA AEaD5BYAAACj8UXoAAAAmLC59tebz3ctDRDHQlJ0w/aZpI1BHMDNSG4BAAhnLulPJ37+Ti5Z3Mgl vD5lkp4b9PNWLkkGgmJZAgAA/fOlpL9I+qektfzdaXEpm8RWkl6JO0KiB0huAQDot1eS/iGX5M6M +7bu7964P6AxklsAAIbhldwShXnYMIB+I7kFAGA47iT9XaxtBc4iuQUAYHi+FwkucBLJLQAAw0SC C5xAcgsAwHB9L65QABwguQUAYNjWoQMA+oTkFgCAYXsud71aACK5BQBgDJLQAQB9QXILAMDw3YmT ywBJJLcAAIzFfegAgD4guQUAYBy+Ch0A0AcktwAAjMc8dABAaCS3AACMx6zh4wvj8TfG/QGNkdwC ADAeccPHryV9NBr7raTMqC+gtS9CBwAAAIIp5JYyLNT+hLRCrmK7vjkawADJLQAA01ZIWu0aMHgs SwAAAMBokNwCAABgNEhuAQAAMBoktwAAABgNklsAAACMBsktAAAARoPkFgAAAKPBdW4BAGhufuH/ 0o5iAHCC1+R2tVopjmOz/pbLpbIsu/q4KIoUx7HiOFYURYqi6OTjsixTnudK07RWv03NZjPFcaz5 fP7b30/J8/wgjqIoavW/2Ww0m83M4l0sFsrzvPF29/f3Wi6XZnFkWWbaXw8tds1KJmlZ87HzXZvp /G06811L5e9Nei4p2rV4F8+xQm5uZcs9xWJlpv1c4prb5EetS6lxf0vVu/VqJLd/Yu2PgVNSuX2S 1ezXp0ju7l1zubif1tjmQS7uVO7uXZl5VDZWan7L3kvWunynsrmkxHC8XO1fT9c6f/y1sZJ7rtED qaStj5am6dbSfD4/O1Ycx9vVarXN87xV30VRbNfr9TaKopvmHEXRdrlcbrMsaz3PLMu2i8ViO5vN Lo6VJEnrMU5Zr9et5tx2n5+zWCysj8Wk0W+Ef4ls55deGGsml3SkN/S/UfvbclbjWOz6ahtHLvfm Ed0Yi5VY7rlM5RJxq+dypdv3dx3Wv2fzC2NFcvsqb9l3IZeIXBrDh2g3rsX+yeX2wexojMSo/7Il DeeYBhg/Nx5z3nDO2m1jGUOh0x/SEUgq+xe5rdRNchvHsfk4m82mcZIbx/F2s9mYxlEUxTZJkrNJ 7mw22xZFYTpm03kvFgvT8fM893EsJu1+NbxJZDu/9MQYs904heE4uZonXT7i2MolyXHDWCxEcsln cSE2q1bIJVaxp7lYxzs/MUYku+Swehwubp/+VSvjuKvP67IyTmLcf9JwnmmA8RfGY6YN5xxq3uhQ Kj+/wN6TW+vK5bEkSa7OcTabbVerldc4iqLY3t/fnxw/dPXWump7qTp/Q0va/3p4kcjvC3ss+8rI 8XizGvNcyH8SuKoZy60i2SdpTfd5bDwn6xjnR/0nHsY43ieRxY44MpPH98VK22j/4c+y36ThfK3n Wnf83HjceYM5z43HLkTVtndSefrl9Zncrtdr077PSdP0bOU0jmPz5O6SU4lnyOqtddU2TVMvx6Gm ldwujPu+9GIen5nfTLctP2jaMvldqpB0OJcuj2Xr2Oa7fmfq7oNAIdslHDO546nLY3dl3GfScM5p oPEXxuOmAee8aDA2OpLK0y+ur+S2q8S2lGXZowR3sViYJ5V1nEpwQ1VvB1K1bfNi71siPy/qC+N+ r7VCjxPcSN0mB9VYojP7u61ZoLlca5nRXK3jmu/6zQLsk4XB/pC6qdj6bkngOTcZPzcee15jzLnx mHmD+aJDqTz9kvlIbrtObEtZlv02L+uKZVOr1epgP4eo3g6oatvmxd63RLbzS2X/gl23FdonuLG6 WYt6rmWy+2ow9Fya7Pe2rGOaK9zSDYv9sQoUu3VLGs47DTj+wnjsNMB8Fw3miw6l8vRLZp3c+l7b Wmf80Ilt6XgNbtfV2wFVbdu82PuWyHZ+mcInlVHgGMq2qfMEXBH3ZC7XWqHbEjof+z7k/sjV/sPN PHDsli1pOPc08Pi58fjzC2PNjcfKG84VHUrl6ZfMOrnFXp7nB0sluqzeDqxq2+bF1rdEfucbohU9 iKFs85rPwykz+T0Zz8d+j1rONXTsPlrScl9kPYg91D5IA4+/MB4/7XCui4ZzRUe4/e5APX36VPf3 97/9uygKrVYr0zGSJGn0c+txMCh3oQOoSG7Ydq16F+jviztx0fiqpZpXbxeSnlsHgtrWkj4Z9vel Tn/Ane/+z8onXb5ZBQIiuR2w47t4rVYrPTw8mPX/6tWrR3d3WywWevrU7r3/3bt3StPUrD9A7g0s arHdvaSvTCPpxnP179uJUO7U/OoJiX0YaCjpoL8uxkBPkNwO2PPnzw+Szy6qt1RtMRD3LbZZGcdQ +iTp3a5ZVqiqluI6m6X7Bo+N5bdS/zdJf961v8ndkhePreW3ejsXVdvJSeVp7Y/vNbdpmm4Xi8Vv a0Nns9n2/v4+yBUVyljm8/k2juPtfD7fLpdL79fBPb5Vrc+1twNca9t2DZhvifzON5f7qnVWGTPa /Sz3PPapWBK5N5d49+dC/k8+Sk/t+AsWHmLY6PQJX5H8HANJwzn7fu5Tuf0a7cabySWea8/j5g32 wcpTDJlOP/cz+blj3y3HQRp4/NLCOI7U4xwXLeeIDqXy9EvmK7m9dMeussVxvM2yzMv4VXmeXz3T f7lcehv/+LJgkr8rJwzsCgkWL7a+JPI312Xg8Zvs91h+T+RpIjcee1FjzFi2SU6hZtVbX/u90PWT +mL147nPPYy9qTFu5HH+SYP5S/1JbiU/V06YG/eZ3zA/dCiVpxcYH8ltURTbOI5rjT+bzbwmuKdu 7nCuxXHsJYZT1U8f1VvrhLnDqu2tL7Y+JPIzz0WDGJaeYmgay0z+3uSjmjHEgeYeemwf+7xQ/cuT zeTvua8j8jBurvofMGbyU8FNao5fSgOPX7UwjiX1ML/FDfNDh1L5eXHxktwefw1/rUVRZB5DqW6S XTYfFdxzSaJ1Mmqtw6rtrS+2PiSyn+OmRRyphzja7O9Ift7k5zXHXxmOmTacu/X4mwbj+nju75tN 3Ty5L1sdCw/jLhrO30cMScMY0sDjH8uN47Fs+Y1zQ4dSeToQrJPbPM9bxeFjDW7dW9QeN+uv9s8l tz6qt1Y6rtpavNhaS2Q/x6hFHLGHOAq1O7Fp5SGWec2x8wBjVkWG429Vf/9b7++s+dQl+VmDG2Lc rPnUJdknc0nD8dPA4x+bG8dj2RY3zg0dGdTVEtbrdafb+ehzs9mYxnFOURS9vRJBX+MasI9qV1HI ZH/2/kYuwW1qbRpFfZHszpb/pHaV21zuObQyN+yriXXL7TaGMTQRGfe3arldahjDGKRyVxbpG66Q MCCDSm7bXg/Vx3VU+xTLOavVSp8++bryUDtc19aL4oZtc6MYbu0vM4yhiblhX/kN2xZGMUjhktus 5XapYQxNfGnY14PaJ+m5XRijkYQO4IQkdACob1DJ7RgURdHpeH2rkvYtHphLQwfQUGTYV3bDtqlR DFL9E7r6oggdgIFU45hHX6TqV/WWqu3AkNyO3Hq97k319u3bt1Rt0TexYV+FYV+3iEMHMABz4/42 xv2hX5XSZegA0AzJ7QT0pVralziAiplhX4VhX7e4E3cr61oaOoARStWP6u078eFlcEhuJ6AP1du3 b98qz/OgMQAnxIZ9ZYZ93SoOHcCEPIh1s74koQNQP2JAQyS3ExG6ahp6fOCMu9ABYPCy0AGMWKqw 1dt3oio/SCS3ExGyekvVFj01Cx2AR7PQAUxIFjqAkUsmOjZuQHI7IaGqp1Rt0VNx6AA8ikMH0HOR YV+FYV94LFWY6i1V2wH7InQA6M56vVaSJHr61Oqa9ddRtcWExDdsGxnFgHoiw75Sw75wWiLp7wHG xECR3E5MkiT6/vvvOx0PmIi/hA4AGKlUrpJqeeONS6jaDhzLEiamy7W3VG3Rc7PQAWAUitABTEQy 0rHgAcntBHVVTaVqi56LQweAUchCBzARqbpZe0vVdgRIbieoi+otVVsAgLFkJGPAM5LbifJdVaVq CwAwlspv9Zaq7UiQ3E6Uz+otVVsguDR0AIAnyUD7RodIbifMV3WVqi0AwJNU0lsP/X4UHwpHg+R2 wuI49tLvfD730i8AAJLmHvqMxBVURoPkdqKiKNIf/vAHL31TuQUAeJJI8nEnojtJSw/9IgCS24ny mYA+ffpUi8XCW/8AgEmayW8CuhTV21EguZ2gKIr06tUrr2NQvcUEfdajlvqdKhDEUq7C6gvV25Eg uZ2gLhJPqrcYgDR0AABqm6mbxHMpqreDR3I7MV1UbUtUbwEARpbyW7UtUb0dAZLbieky4aR6C2AC 5qEDmICZuk04l6J6O2gktxPSZdW2RPUWQA8VoQNAI0t1U7UtUb0dOJLbCQmRaFK9RY+loQNAMJlh XzPDvvDYTGESzaV4bgeL5HYiQlRtS1RvAYxYHDqAkVuq26ptiertgJHcTkTIBJPqLXrswbCv2LAv DEcUOoARmylsgrkU1dtBIrmdgJBV2xLVW/RUZtjXzLAvDEcUOoARWypM1bZE9XagSG4noA+JJdVb 9FQROgAM3pehAxipmfqRWC7FB9fBIbkduT5UbUt9SLKBI1noAHZSSVvDNu8y+AEqjPuLjftD+Kpt iertAJHcjlyfEsqnT59quVyGDgOoygz7mhv2Bb8y4/7mxv1N3Uz9Sij/JJafDArJ7YjFcdybqm0p SRLNZrPQYQClPHQAnuShAxgAy5MJ54Z9oT9V26okdACoj+R2xFarVegQHrm7u6N6iz7JZJfkxDds OzOKQXLzyQ37G6vMsK+vxLpMKzP1q2pbeiWqt4NBcjtS8/lcX37Zz/Mclssl1Vv0SWrUz7zldpGk 50YxSNycoq7cuL9Fy+1iwxjGYKn+VW1LSegAUA/J7UhZr7X99OmTWV9Ub9EzG6N+7tQuwVkZjV/a GPc3Vplxf8uW280NYxi6SLZV2wfZLj+hejsQJLcjZF21/fTpk+bzuVl/EtVb9MrGsK+Vmr35LeS+ 0rbyIJLbulLj/p6qeWVvof5WKUNIZLs/VrL/8JgY9wcPSG5HyLpqmySJ8jzX27dvzfqkeoseKSRZ Hdx3cklTfOVxM7k33e+Nxi2txLV768pkW9WTXNUxrvnYSPaJ15BFcpVRKw/aJ7dUbyeG5HZkfFRt 1+u1JPukmeotemRt2NdTSf/Y9Xmv/RthJPcV9EpuvecfDMeU9m/mqG9j3F/dDzfxbmyqtnuJcX8r uQ96hajeTg7J7cj4qNqWqN5ixFJJ74z7fCXpPyX9U+7GCv+U9He5pNZHUpOIqm1TqYc+ywR3ceL/ Irnn6R+yPYlw6CL5qdqWVqJ6OykktyPis2pbonqLEUtCB3CDd6Jq28Za9ksTJJfgfi/3YSPdtULu A86fPIw3dIlxfysdftArRPV2UkhuR8Rn1bZE9RYjlkr6f6GDaOGT3PIHtLP22PedpC93jSUIp0Xy W7UtrUT1djJIbkeii6ptieotRiyR9DF0EA08yCW2RdgwBm0VOoCJS4z7W+n070MhqreTQXI7El1U bUtUbzFihdxJX3YXdvbnQS7WLGwYg5dL+nPoICYqUjdV29JKVG8ngeR2BLqs2pao3mLECrlqaJ8r uJ9EYmtppWF8oBmbxLi/lS5/i1GI6u0kkNyOQJdV2xLVW4xcJpc8Wl9BwcI7uUtJZWHDGJVC7gON j5PLcFqkbqu2pZWo3o4eye3AxXHcedW2RPUWI1fIJbh9+cr6QdL/lYupCBrJOGWyvfUrLkuM+1up 3u9FIaq3o0dyO3B3d7Yn4DZJWKneYiISSf8iu7uYNfUgl2BH4uQn39aS/k+H4z1omsshIoWp2pZW sq/exob94UYkt/hNk6ptieotJiKXuyh/meR28fX1R7lEKxI3aOjSWtL/kv/n+KNcFT73PE4fJcb9 rdTs96OQ/QdF6/5wA5Jb/KZNouqjertarcz6A4zlcknuTNL/lrsurtWJZw+S/ia39OBf5CpBa5HU hpDK7X8fa67LSvxc01w3Hcm2aiu1SyxXsv0A86Xcc4oe+Ezul9hu0WZFHMemVbgsy1QURatt5/O5 WRySlKZpq+1ms5niODaNxUpf5lQUhbIsM+tP7o0ksezwRpFsT0Ao1P5NMpZL1Kxkap+Mzc2icDJ1 mxjGcs9rvPv3TOe/qsy0v+99Jpc0516iOm9u3F+m/jz3qWFfc7kPNLcmZJ/kEqq1DvfTQravB6ma zT+W7WtArsvHcqTxvv7lmmYlvne8JrdAT/QtuQUwPDO5RDfe/TmT9PzMYz9qn3Rlcu+zubfIABz4 InQAAAAMQCFps2sAeow1twAAABgNklsAAACMBsktAAAARoPkFgAAAKNBcgsAAIDRILkFAADAaJDc AgAAYDRIbgEAADAaJLcAAAAYDZJbAAAAjAbJLQAAAEaD5BYAAACjQXILAACA0SC5BQAAwGiQ3AIA AGA0SG4BAAAwGiS3AAAAGA2SWwAAAIwGyS0AAABGg+QWAAAAo/FF6AAAAAAGZrv780dJvwsZSCBf S/pW0jO5ffBHSR88jTU/8bNC0kxSvmva/TuWVJDcAgBw3gu5N/IXkl5Wfv7zrv24a77e2IE+eiPp ye7vLyV9I+nfPI2V7P78UtJHucS2kPSVpE+Sot3/30v6XtI7SUrlPoHQaGNtiQCgmZeSflD915kf dJj8Ytyqz/vUvNTp34E6flL7fbbVvoqbVMaNdz/b7P6dsuYWAIC9J3JVqVPJ6gftK7U/H/1fmQx/ 4ztAILDjY//cz469kFvGYOmTpIVc9fYr7aq2JLcAADhP5BLU15Wf/Sj3detnkv6n3PrK30n6V0n/ TdLvdfjG/q1ccgyM1c9ya2xLvx79+5yvPcSykUtu7+US3bT8j1Thvzam0Xy2RABw2RNJ77V/3fhF zZYZfKvD1x0S3HErn+cpLksoPZP7HXly7YG7x/yi2/bZVo+XJUTaPxfL3c9ZlgAAgKS/yn1tKrnl B/8qV7Wt649yVdzSa7FEAeNWnlD5a43HVk9As5TLnWQmSevqf6QKX1mj0Xy2RABw3jfav178pNve hKt9bbVPmDEu5fM75cptXa91+DvRdp/N5S73JbmK7bzy9/j476n8JRU0Wh9aIgA47ZkOXy8sktHq 8oZbkp9ncsnyD3JJd9nnL9qfvGZ9gk5bz+SWZlSvMPGLXEX89YXtJLfPT21bzvHWil95Tdbjq1+8 r8TXdAyL57eJ6rFQfr2/lTsu2s6hC8cf9jrbZ+mJgWm0MbVEAHDaG+1fK6yWERxfKqnpJcLKKzbU fY17o+6S3FP76ni98an2Xo8/ONSdZ9P1z6XXOkwEr43R5Pkvt2uaqB0ne9dOsnoml7z6mMOtLu2D Z2p2Kb3tlf4aS1sOTqMNpSUCgMeqVdtfZFv5KpO2X9SsGvy1Hidk73f9fbNr3+qwOlyO4+Ns9GPl eGUCUk1OfzmK8zgpq+6LUyfwXdp2q/r78Zke758y5m90OMZPR4+peyLg8X6o4/jr+WsV7VPJ+Xu5 57+cw5sTc3ivbj7sXNoH566FW6eR3NJoNVoiAHisWnH81rjvl2qe2B4nP3/V5STlmR5XPq8lTLcq xykTxfLf55YPHCea73c/r/7s25rb/lQjvhc6TAjLaualDy7HSWSdY6G6H+pok9hWH3+tOv9Sjz8s +E5wL+2DchlFtVWfx+P/qzaTYzjV4Q6k0cbWEgHAY9WKl49EoEmfL3T4utXkDf642uvzTmnVGMsx r8X6RIf7uvp1ddNtLz3++LFNKpjHSfG17apzadr3tTl/rcN93KQiX/2w8/7KY2/VZB+0efxN1jo8 WGm0sbWFAOBQNZn0nQRc0ySBO6c6H+slFlXHr691K97HlcitXGW66baXlg1UlzK8V/N9UB3n2trV 8nHXErXjxPZav8+OHt/mBEcf68hPqbsP2j7+JokeH3A02pjaXABwqPo1qfWShFtiuSUZ6WJO1dfW Jkn0Ez1+bW5S2S63OfdBpHqTgLbJfTXGa4l3+bhLiVo1pq3qree1SEyrH5a6+KDTy+R2occHHI02 phYLAA5Vkwjf61QvqSZUddaUXuN7qUX1tbXpXdhuuURaddtzypOYbnk+68Z37XHHJ8zV2VfV6vut x0KTKnRbTZ/Lts99Y5/L3d0BGLMsdAAAeqea+P0cLIrDROzfDfqr9uH76gn/0fDxv1b+3uTub8fb nvOj3J3ivmvYt7UncglcuaTgOx3eve4cy2PhO+33WcgPb0GFrqzRaL5aKgB4rPp1cUjVr4+tlHOz qAQfq76+NlU9kazpSW/VbX2pnsh1S+X2eO1vXdbPW/XbCZ9V/F5WbiXpb74HAgJJQwcAoJf6cDen Z9onHU2roJeUfVX7t/bhxu2bVm59eyKbr+/faF8x/yDpdzW3e6n9MWm1b6rP0aRuA10mt5uQQQAe bUIHAABnVBOOW5PFqi6Sml899RtCeY3YW/fVG+2XAJSJbd395ONYqC636cttmjtBcosx+yjW2wLo L1/rfieb1DRQ3mTgvdzX5M90W8L+Wu0T22NWx0K1Ajyp4+CL3Z+FpLeSXoULBTC3Ch0AAFxQTTh8 VW4nldRc8EyuQvti9+fxfvlVLiFtc83j19pfDeFXuZPHmia2L4/+bl1xn+xxECn8yT80mlUrJM0E AKdVL9PUNpGoXlf2Ujt3Ao3Pk6SujR2i31vm22bbJ3KJZ/W5Pm7Ht+etO7/q9tW/tz2WqvPz0Xyc xNW0b5+xHPii8vdcVG8xHolcggsAp/xa+XsfTi6Dra/lbmRxqmL5Qe4r+w+yPZHviVxya1mFRwtf HP07kXQv6a7zSAA7H8WSBACXVdc1vlC7M9Q/yF1X9ZzQdz6bquqJXZL7IPMfcs/xj7I9Ga5MkMtl CW8q47X12a1BTd1xcpvLJbh/6TwSwM4idAAAeu84uW2jTJbOuZbcVmN4Irukq1qJtkzkhuAbHSa2 5U0dfO6H8qYR1QT3ZzWr4H7Qft3tM4W9scjgfX7iZytx3VsM15/FFRIAXFdNSpveUMCKRYJ9iq9L jPXdMx1+oPid3J2+ukjwv9M+yT2+Q1kd1Rgne/KXlVPJreQqXx87jAOw8FbumwcAuOaD9gnFE/m/ Ve0p1YTGV3I7pcrtccW26xtF/F6PE9y6iepkb7jgw7nktpBbe/vQWSTAbT5KWoYOAsCgVNdFvj77 KH+qyZev5LZvdwLzqVqB/+7so/z6vfbH1RO5W/HWOWGxmtyG+KA1KueSW8mtv51L+tRJJEB7H+WO 1SJsGAAGpprcvlT3yxN+1n5pwtey+Tq6WoWu9j8FZVLf9qQxq+f/99onqy/kKrjXEtxfj7axWpow ySuBXEpuJbd2MRZLFNBfb+WO0SJsGAAG6PiEMMurG9StxFYrjN8YjFutQIeqXg6VVcX0V7n1vscJ 7jXVD1sWx8ILuWv8TjLBrWMmaa3wF+an0aptKQC4zUsdvq68ufzwWp7o8MYBlxKbJzq8EcAtyxNe 6HAuPk5MqjOnc3zfxOGn3f+3ucvY8b6rexOHS497psPn9tqxdXws3FJJfqL9/rBIlE9peizccux4 dS+3XCF0UkObdkvlqrUAYOFbHb7G3JLgvtBhgrLV9Tfz6p3OflG7SttxQt2XhKbKd3L718pjmiT2 bZ6zuo877vvasVU9Fn6SzbHwU4s+6mh6LNxy7Hg30/7uT6GTHNq0Wi6uYQvA3nEysFWzM93LPs7d jrfOm3k1eftJzSq4z3QYv8+vopvM6Zjv5PZ15TF/rdnvSz1ObOvMr8l+OK4KX/vgccuxUC5FKLe/ 5ZbA1zQ9Fqox9dZMLtHIFD7poY27beS+NQAAX04luFu5Stu5r4fLk7fe6HGCVE1067z5nxr/G11O sMuEujp228pvXU3mdMx3civtv4ovn7tz++Ll7v+r+626RMUyuZUOE++tLl+do82xUF7jt7qNz8RW ar4Pqs/hcYL/Wu2Wk3gVya1/3IiKLu32lsut8V7IfYgCgK4cJwjV9l7uDfoHna72beWSqzIZLpOn um/+5bVRT437rVxC8M3u7+ce5/vkoXKsvia3x8sAfpF7Hsp990aHCXD5mDIJrDu/NvuhaYJ76jn+ QY+PhVMfyt7L//Vym+6D4/n/pMe/SyYx+7x/8dxj3xinQtxdDEB4L+XeiJucPf+r3N2wqrd6fSb3 Bv6j3Nnzdb3W9UrdqbH/vcEYbZXJZdM5SS6RKRP/pvlHk21fyC1LqLP/vpO74UP5nJXjXJtf2/1Q Jqalf9PhVRKONT0Wftb+OPStzT54o8tJ/R9lcBz7TG4BABiyZ3KJTnnd0RfaV0bLO5x92LVLCUpb X+/GLFu1Kvuj57HH4LUOnz9pf+3fH+X221CuA3zuWKgeg0M5FsoPjuWHlWrsJjcd+f966/8/7p2U cwAAAABJRU5ErkJgggAAAAAA --_004_A643E85AB4B0437BAB7680BF3F795983mendixcom_-- From nobody Tue Jan 12 09:28:09 2021 Return-Path: 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 46A793A0DBF for ; Tue, 12 Jan 2021 09:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 RgmtAekWnnGm for ; Tue, 12 Jan 2021 09:28:06 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 DF6B03A0DBC for ; Tue, 12 Jan 2021 09:28:05 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id f4so3553975ejx.7 for ; Tue, 12 Jan 2021 09:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LYiOPZMo5dMvdsuHtya5LJFn/77QqdNufJCeZ0BQCCw=; b=ZJvooOrnGvKg1hMT+laWpedZHpoaPCuax6b4ORXPJp7bKLxhdFHi9dPFg/EML4VyqF r2spx4fFegcdAxYR7fsQ+NoYFH698ofWYsSb7DC5gG8WiDAWvPSrmZEm3HnbXYcU916u e8v14fIY3Xyl9T15Eni+/lgaEEKmpAUpd2sE1XBgR67zH44Gn+Ow6wBGLqmGUbuDOuHX has1hkItY9ZpTpWpJfGBU+oAKe69d8+RbCzIda0WUOA3P3JthLMHCO0JjiLRAiPtmVp4 vPlCIFOxfH5YISES0tDVaVzGWseLTKcsjUisfxT2wkP3+ihgQ2bgVeK6IGzO/nccTEsp 3SJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LYiOPZMo5dMvdsuHtya5LJFn/77QqdNufJCeZ0BQCCw=; b=myUcGNvOJDmiP1Vf2HsK7ZgX8Tc7fGKNO4H/Cax6HNzs5gN1iLlDTNGbU82xN4mD94 zI3Q14s0R1Qi19yDSh998ZXetZF0EQc/GSjxBx/N+uQIFm5XHELltMQ9mI+XiLYTFPcA 1L3ITKyGuuUJAHFFmFevicjDLxj+8LycfpFIHk3H9RMECsE+T9hrHTRbqn+u4HpBO/Jb kEVV8Ff22A1RAL7iFM2A0T8NWHXbdtm5fN/gSY5uO794ZAz2WvnPItmOW0xvf16ocQYO suM17qK1vEC/9f9BcgAHh45jZFOg9zxRLOefxFLAkufTudJQ2QmA1A4fQzYTW3ELqXow b2Rg== X-Gm-Message-State: AOAM530Az3ZGLpNpN+c0PFeRc7LS5KVU1Z36hWCveGHLhyRnHeGPJ/kU x2vBybNxKuHnk6g0ctVzNDIxHoWuAVVheaWi8dTFlqgkAtc= X-Google-Smtp-Source: ABdhPJx3Tg+gRBYXhlR7FYw2yK9z5MU0Stzb+o0bcXjYCF5sESgN4jwizveymlTHDRUKwnrH1SUXpmTUd3ELNePs/c0= X-Received: by 2002:a17:906:7f0b:: with SMTP id d11mr3990056ejr.7.1610472484099; Tue, 12 Jan 2021 09:28:04 -0800 (PST) MIME-Version: 1.0 From: Bunh Tha Chau Date: Wed, 13 Jan 2021 00:27:52 +0700 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="00000000000055db9005b8b758ae" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 17:28:07 -0000 --00000000000055db9005b8b758ae Content-Type: text/plain; charset="UTF-8" Thanks --00000000000055db9005b8b758ae Content-Type: text/html; charset="UTF-8"
Thanks
--00000000000055db9005b8b758ae-- From nobody Tue Jan 12 13:13:32 2021 Return-Path: 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 07CAF3A1229; Tue, 12 Jan 2021 13:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 J6n9ktnW1IQG; Tue, 12 Jan 2021 13:13:29 -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 B6A733A1227; Tue, 12 Jan 2021 13:13:28 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10CLDQVX001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 16:13:27 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AD5D422C-DD86-4AE0-B212-C6D0AA04CE0C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 12 Jan 2021 16:13:26 -0500 In-Reply-To: Cc: "oauth@ietf.org" To: Jaap Francke References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Tenancy in OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 21:13:31 -0000 --Apple-Mail=_AD5D422C-DD86-4AE0-B212-C6D0AA04CE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jaap, There have been a number of efforts to address this kind of thing in the = OAuth world. You can definitely use a special scope to encode this = value, which has the benefit of fitting into the implementation = limitations of nearly all OAuth systems out there. The =E2=80=9Cresource=E2= =80=9D parameter can also be used for the kind of thing, and it gives = you a bucket that=E2=80=99s separate from =E2=80=9Cscope=E2=80=9D so = that you can keep the latter available for describing the API itself: https://tools.ietf.org/html/rfc8707 = There=E2=80=99s also the Rich Authorization Request (RAR) draft that = this group is currently working on, which provides a multi-dimensional = way to describe access. It=E2=80=99s more complex than scopes, but it = boils down to having JSON objects describe the elements needed. In this = case you might put the API bits into the =E2=80=9Cactions=E2=80=9D and = =E2=80=9Cdatatypes=E2=80=9D fields, and put the tenant information into = the =E2=80=9Clocations=E2=80=9D field. I believe there are people using = it in exactly this way today: https://tools.ietf.org/html/draft-ietf-oauth-rar-03 = There are also some historical efforts to address this, including an = =E2=80=9Caudience=E2=80=9D and a (completely separate) =E2=80=9Caud" = parameter, but AFAIK neither of these have been raised to standard or = even to common practice, and so I wouldn=E2=80=99t recommend it. I = currently have a project to migrate a system that=E2=80=99s currently = using one of these onto RAR. =E2=80=94 Justin > On Jan 12, 2021, at 11:20 AM, Jaap Francke = wrote: >=20 > Hi, > =20 > I=E2=80=99m looking into the topic of tenancy. A multi-tenant service = can be considered as an OAuth Resource Server managing resources of = different tenants. > An AS makes authorization decisions and communicates these using = scopes, so one way would be to =E2=80=98encode=E2=80=99 the tenant into = the scope values. > Another line of thought is to somehow bind/restrict an acces-token to = a certain tenant, leaving the set of scopes being used more static. > =20 > My question is whether this has been a topic that has been addressed = in the OAuth working group? Any common practice or draft? > Thanks in advance for your replies. > =20 > Kind regards, > =20 > Jaap Francke > Product Manager Identity > +31(0)641495324 > mendix.com > > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_AD5D422C-DD86-4AE0-B212-C6D0AA04CE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jaap,

There have = been a number of efforts to address this kind of thing in the OAuth = world. You can definitely use a special scope to encode this value, = which has the benefit of fitting into the implementation limitations of = nearly all OAuth systems out there. The =E2=80=9Cresource=E2=80=9D = parameter can also be used for the kind of thing, and it gives you a = bucket that=E2=80=99s separate from =E2=80=9Cscope=E2=80=9D so that you = can keep the latter available for describing the API itself:

https://tools.ietf.org/html/rfc8707

There=E2=80=99s also the = Rich Authorization Request (RAR) draft that this group is currently = working on, which provides a multi-dimensional way to describe access. = It=E2=80=99s more complex than scopes, but it boils down to having JSON = objects describe the elements needed. In this case you might put the API = bits into the =E2=80=9Cactions=E2=80=9D and =E2=80=9Cdatatypes=E2=80=9D = fields, and put the tenant information into the =E2=80=9Clocations=E2=80=9D= field. I believe there are people using it in exactly this way = today:

https://tools.ietf.org/html/draft-ietf-oauth-rar-03

There are also some = historical efforts to address this, including an =E2=80=9Caudience=E2=80=9D= and a (completely separate) =E2=80=9Caud" parameter, but AFAIK neither = of these have been raised to standard or even to common practice, and so = I wouldn=E2=80=99t recommend it. I currently have a project to migrate a = system that=E2=80=99s currently using one of these onto RAR.

 =E2=80=94 = Justin

On Jan 12, 2021, at 11:20 AM, Jaap Francke = <Jaap.Francke=3D40mendix.com@dmarc.ietf.org> = wrote:

Hi,
 
I=E2=80=99m = looking into the topic of tenancy. A multi-tenant service can be = considered as an OAuth Resource Server managing resources of different = tenants.
An AS makes authorization decisions and = communicates these using scopes, so one way would be to =E2=80=98encode=E2= =80=99 the tenant into the scope values.
Another line of = thought is to somehow bind/restrict an acces-token to a certain tenant, = leaving the set of scopes being used more static.
 
My question is whether this has been a topic = that has been addressed in the OAuth working group? Any common practice = or draft?
Thanks in advance for your replies.
 
Kind regards,
 
Jaap Francke
Product Manager = Identity
+31(0)641495324

mendix.com

<image001.png>
 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_AD5D422C-DD86-4AE0-B212-C6D0AA04CE0C-- From nobody Tue Jan 12 14:10:08 2021 Return-Path: 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 758843A12BC for ; Tue, 12 Jan 2021 14:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 mRexQXAa8h6t for ; Tue, 12 Jan 2021 14:10:04 -0800 (PST) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (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 624063A12BB for ; Tue, 12 Jan 2021 14:10:04 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id zRrWkFchYq3RjzRrWkbVYL; Tue, 12 Jan 2021 15:10:03 -0700 X-CMAE-Analysis: v=2.4 cv=KJufsHJo c=1 sm=1 tr=0 ts=5ffe1e3b a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=OPE_keaqAAAA:8 a=_hUQx-6YfCI2_Z5dKvIA:9 a=QEXdDO2ut3YA:10 a=LSZRARl4ZZNvyWOSxHQA:9 a=v5XpdSk_JC5CTb9n:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L47nHB812nP-ulAiFgtB:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Wed, 13 Jan 2021 00:10:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030404030505020500030307" X-CMAE-Envelope: MS4xfFwkBHuq388EBNVZxsjsItQMgc/bOTaDEzlzY1EQKQoxJtVk8/GuesasHdPsxCnwNdkpS3+RLwQzGm/mBcKsIsaLHdhwMWFXpNtSUyTcgY98c9p/ap1U Geth+/FUees2Ij1/+86AhUHVrR5B0VXcNwRPGkljp2sDo8A5xEXypHPT0MFTYf56Uht6uXJ+BAgeoA== Archived-At: Subject: Re: [OAUTH-WG] Tenancy in OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 22:10:07 -0000 This is a cryptographically signed message in MIME format. --------------ms030404030505020500030307 Content-Type: multipart/alternative; boundary="------------5CB0DFDFE00A82472B993C04" Content-Language: en-GB This is a multi-part message in MIME format. --------------5CB0DFDFE00A82472B993C04 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jaap, Justin made a good overview of the available OAuth facilities when dealing with multiple resource servers or resource server tenants. If you have control over the resource server, i.e. the token validation is going to happen in one place, then you have plenty of freedom to find out what will work best for you, semantically and in terms of available OAuth server. In cases when the resources are left to implement the token validation on their own my preferred approach is to encode the resource server identity (tenant) into the scope values. Access is defined in one place and I don't have to worry about the developer accidentally forgetting the "resource" or "aud(ience)" check. Vladimir On 12/01/2021 23:13, Justin Richer wrote: > Hi Jaap, > > There have been a number of efforts to address this kind of thing in > the OAuth world. You can definitely use a special scope to encode this > value, which has the benefit of fitting into the implementation > limitations of nearly all OAuth systems out there. The =E2=80=9Cresourc= e=E2=80=9D > parameter can also be used for the kind of thing, and it gives you a > bucket that=E2=80=99s separate from =E2=80=9Cscope=E2=80=9D so that you= can keep the latter > available for describing the API itself: > > https://tools.ietf.org/html/rfc8707 > > There=E2=80=99s also the Rich Authorization Request (RAR) draft that th= is > group is currently working on, which provides a multi-dimensional way > to describe access. It=E2=80=99s more complex than scopes, but it boils= down > to having JSON objects describe the elements needed. In this case you > might put the API bits into the =E2=80=9Cactions=E2=80=9D and =E2=80=9C= datatypes=E2=80=9D fields, and > put the tenant information into the =E2=80=9Clocations=E2=80=9D field. = I believe there > are people using it in exactly this way today: > > https://tools.ietf.org/html/draft-ietf-oauth-rar-03 > > There are also some historical efforts to address this, including an > =E2=80=9Caudience=E2=80=9D and a (completely separate) =E2=80=9Caud" pa= rameter, but AFAIK > neither of these have been raised to standard or even to common > practice, and so I wouldn=E2=80=99t recommend it. I currently have a pr= oject > to migrate a system that=E2=80=99s currently using one of these onto RA= R. > > =C2=A0=E2=80=94 Justin > >> On Jan 12, 2021, at 11:20 AM, Jaap Francke >> > > wrote: >> >> Hi, >> =C2=A0 >> I=E2=80=99m looking into the topic of tenancy. A multi-tenant service = can be >> considered as an OAuth Resource Server managing resources of >> different tenants. >> An AS makes authorization decisions and communicates these using >> scopes, so one way would be to =E2=80=98encode=E2=80=99 the tenant int= o the scope values. >> Another line of thought is to somehow bind/restrict an acces-token to >> a certain tenant, leaving the set of scopes being used more static. >> =C2=A0 >> My question is whether this has been a topic that has been addressed >> in the OAuth working group? Any common practice or draft? >> Thanks in advance for your replies. >> =C2=A0 >> Kind regards, >> *=C2=A0* >> *Jaap Francke* >> Product Manager Identity >> +31(0)641495324 >> >> mendix.com >> >> ** >> *=C2=A0* >> =C2=A0 >> _______________________________________________ >> 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 --=20 Vladimir Dzhuvinov --------------5CB0DFDFE00A82472B993C04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Jaap,

Justin made a good overview of the available OAuth facilities when dealing with multiple resource servers or resource server tenants.

If you have control over the resource server, i.e. the token validation is going to happen in one place, then you have plenty of freedom to find out what will work best for you, semantically and in terms of available OAuth server.

In cases when the resources are left to implement the token validation on their own my preferred approach is to encode the resource server identity (tenant) into the scope values. Access is defined in one place and I don't have to worry about the developer accidentally forgetting the "resource" or "aud(ience)" check.

Vladimir


On 12/01/2021 23:13, Justin Richer wrote:
Hi Jaap,

There have been a number of efforts to address this= kind of thing in the OAuth world. You can definitely use a special scope to encode this value, which has the benefit of fitting into the implementation limitations of nearly all OAuth systems out there. The =E2=80=9Cresource=E2=80=9D parameter can a= lso be used for the kind of thing, and it gives you a bucket that=E2=80=99s separ= ate from =E2=80=9Cscope=E2=80=9D so that you can keep the latter avai= lable for describing the API itself:

https://tools.ietf.org/html= /rfc8707

There=E2=80=99s also the Rich Authorization Request= (RAR) draft that this group is currently working on, which provides a multi-dimensional way to describe access. It=E2=80=99s more compl= ex than scopes, but it boils down to having JSON objects describe the elements needed. In this case you might put the API bits into the =E2=80=9Cactions=E2=80=9D and =E2=80=9Cdatatypes=E2=80=9D fie= lds, and put the tenant information into the =E2=80=9Clocations=E2=80=9D field. I believe= there are people using it in exactly this way today:

https://tools.ietf.org/html= /draft-ietf-oauth-rar-03

There are also some historical efforts to address this, including an =E2=80=9Caudience=E2=80=9D and a (completely s= eparate) =E2=80=9Caud" parameter, but AFAIK neither of these have been raised to standard or even to common practice, and so I wouldn=E2=80=99t re= commend it. I currently have a project to migrate a system that=E2=80=99s= currently using one of these onto RAR.

=C2=A0=E2=80=94 Justin

On Jan 12, 2021, at 11:20 AM, Jaap Francke <Jaap.Francke=3D40mend= ix.com@dmarc.ietf.org> wrote:

Hi,
=
=C2=A0
I=E2=80=99m looking into the topic of = tenancy. A multi-tenant service can be considered as an OAuth Resource Server managing resources of different tenants.
An AS makes authorization decisions an= d communicates these using scopes, so one way would be to =E2=80=98encode=E2=80=99 the tenant into the scope= values.
Another line of thought is to somehow bind/restrict an acces-token to a certain tenant, leaving the set of scopes being used more static.
=C2=A0
My question is whether this has been a= topic that has been addressed in the OAuth working group? Any common practice or draft?
Thanks in advance for your replies.
=C2=A0=
Kind regards,
=C2=A0
Jaap Francke
Pro= duct Manager Identity
+31(0)641495324

mendix.com<= /a>

&= lt;image001.png>
=C2=A0
=C2=A0=
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/oauth


____________________________=
___________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
--------------5CB0DFDFE00A82472B993C04-- --------------ms030404030505020500030307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAxMTIyMjEwMDFaMC8G CSqGSIb3DQEJBDEiBCApwFtuc6ABowP6c5lj1q5G1nzyOFiVg78TkumUSLYZhTBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAL8iLk+XGGjarWgGksKmH9bp4AZUt+frCdZNFQNuUtz69DbJ u4tErHFjUag1CuOfvr/TbxlZ5DJYSMZ9udU9E5hMgeOXW8iLB0G4LBQoF+B0xtX5CMXBn83Y Do/9oTKCuf8EMaOQgpWuO5NVHI4UiGV86w7x2i6y6ThUHATVH7LlcDAiVAK2Io1Q9cQrh+ZB 9OI6FNN44ZXWVm41FPuIkV42817rKQXyDEQ40DRgU0cRKkhNFSTzM/dkm/mle2jcR52zWmvK yTBz72yA/OGktLagLkQ6/1UJwabXaVvcvo0rnuZ69/UX7eC8n6bfbdfHsKTa4SmnvprSKbKB HpoTkF0AAAAAAAA= --------------ms030404030505020500030307-- From nobody Tue Jan 12 18:22:20 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 852C83A0902; Tue, 12 Jan 2021 18:22:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org, rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161050453845.23610.3735292126990703466@ietfa.amsl.com> Date: Tue, 12 Jan 2021 18:22:18 -0800 Archived-At: Subject: [OAUTH-WG] oauth - Not having a session at IETF 110 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 02:22:19 -0000 Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the oauth working group does not plan to hold a session at IETF 110. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Jan 13 02:10:29 2021 Return-Path: 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 E49FF3A0C04 for ; Wed, 13 Jan 2021 02:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mendix.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 TwEVtNQCUr59 for ; Wed, 13 Jan 2021 02:10:25 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (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 3C00D3A0C85 for ; Wed, 13 Jan 2021 02:10:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sh/oj2PGLB4OAyuGMb7MWRK/+yNmTR1Pp12dDFsWxxTAlJsiAMfoUj9s//zGOtLdvGrLo5D+2D74n9Czm4zvgxfWVMilXeLgBXLxDvY/zkftBVO7cFgLG/uaePh+huCOZbhleVJIhtHGDrUBBF4AR0UAU6XHfbJcjjKzU3qwGYiw2qutkQloaJKibpy8qvtg0TIs1c/FBCKQmGvbC89C6jqlxS1K6p0PMLyDr9DKiyG/DvuPOW8kVOWzCLghgCCR/ejU6YUHcEZh/UGykGXidogaNcypYYPDyn+OXdmXO9eldgDEfMpZKlueX00GOvR4ox4UjBaIqv0ZePnmQ6TMQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH8Dvn1HGX/hWOMzvmSTxHYTTQDRQEPIOMpPkyPBzmk=; b=aA38hwviFakiUnIOUEBAGJtHeppamw41JSSLGrVx5N8miBMXz4vElv7yKzby7BgCsFtXCmsEtiWsWo+h5NXXTOGzM4cmU0RQQIq1h5Gphm+MYNitjctFYQS6ToDxlD4+ALHp6u17LzdGttR83fYDNJurGGc5Kyue80F5oC36TaQuW4o7v0Qtb5FjT/n9YI1BUW7x9QKVpgo7EDdHeFhZ1LrUuubZqdBE2f4knMlVyVlHoeiRm6+yHLf7A7nLwueUOqRG9cEG86bZZ4p0wGEoXgBmqI/siscQURojuJ+KO4Xjdhf0seux2KqeObNVDSwiu3CedJEBGkoCPB0pFkcC2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mendix.com; dmarc=pass action=none header.from=mendix.com; dkim=pass header.d=mendix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mendix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH8Dvn1HGX/hWOMzvmSTxHYTTQDRQEPIOMpPkyPBzmk=; b=Mpab2FUkMfcdNIri+qYA6GsXMSh8xY6UZnMypeJTLvo4Cr23YzjGzGuvdxjhh6cZzFJW9lqhfxJG8Jw1Cwyvav73xNwnwOD11fJxs6+zDlkDg82ktRonGd9EJ8DN+8CDoXewTgTWXxWpaAI3+dFu+JtCqJrPLion1oJDlc8d6Os= Received: from AM0PR06MB4180.eurprd06.prod.outlook.com (2603:10a6:208:7a::24) by AM4PR0601MB2132.eurprd06.prod.outlook.com (2603:10a6:200:47::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.12; Wed, 13 Jan 2021 10:10:12 +0000 Received: from AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e]) by AM0PR06MB4180.eurprd06.prod.outlook.com ([fe80::489b:ed4b:779c:37e%5]) with mapi id 15.20.3742.012; Wed, 13 Jan 2021 10:10:12 +0000 From: Jaap Francke To: "oauth@ietf.org" Thread-Topic: Tenancy in OAuth Thread-Index: AQHW6ZRH9/k3PuSDgEq0Kqp8ugdsjA== Date: Wed, 13 Jan 2021 10:10:12 +0000 Message-ID: <35A2B178-B99F-4EBB-A2A8-A386183682C5@mendix.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mendix.com; x-originating-ip: [86.84.216.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aedb06d5-9836-4d02-7925-08d8b7ab6a76 x-ms-traffictypediagnostic: AM4PR0601MB2132: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2276; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VztivfesjRwcxqumh6VRzzvWE7TfZo/LIp13NrQLYsLMweu99yYoigcKg/4q+abSYekqJbyIQ7ArxYCWxsZkWjJZ35NTf5ALk575roJLBwFLWrIAePoxEP70EILEO9h3tkVy3v5PuE9fQv4pKesquxZ869yPagl5dd50hl48+s7CMefxn4ZpCFuMBUPVaGjZAQ2pNGz36zYl9dyOKsVQ4/gcVGj761hEiCk3Yjiyt29nzpfbUaeLKF8mbALpPapPXi0ns/A9EhR2k/XaOOhS7L9c/4mPJmtZbz2Aj4wpzp/Ei9QXP3qvbakYzR/KWW84J+ATjB/AglsAJ2RLW2qwpcT4i7cen9MYBllqmi8n+etgpwU7CQnmF5EtGpukdgy6dJmJk2TYpYRa8LJjy9yPxOS6+paVDnY+xSOVuAmpR6kUQa5YM58OOWSdt7Wgx8jJXJcUnMJSFvPXRSv0mTVXMm6CBIYOVaPb8Xpfeg1iw9rZFGU8XWbLGjjPbHR7GIBzqW1gKyuvHRRV1f/OdU94WA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR06MB4180.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(39850400004)(136003)(376002)(186003)(53546011)(83380400001)(478600001)(4743002)(71200400001)(8676002)(45080400002)(76116006)(26005)(33656002)(966005)(66946007)(3480700007)(7116003)(316002)(86362001)(8936002)(6916009)(64756008)(66446008)(66476007)(5660300002)(66556008)(6506007)(6512007)(30864003)(2616005)(2906002)(36756003)(6486002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dXdHNnFoczkxNFplSktLUmtFZmdVS2FETmtpZWVFdVg1ZEdxekNoUFM1TFk0?= =?utf-8?B?MVNUa3c1aDNDRWxUbk5PVXMwYWFNQTRYWDAvb01jYm9SUTdKYmJvTVJRM0lC?= =?utf-8?B?cHBxSUVwMVdiNTd2WlBTenZpK1dWS09ZeFcwYXVqOFcra1hVUWRjQTNmc1JJ?= =?utf-8?B?alhBK1c1NTZ4dytHUGw4bkJNZVh6aG5hNGdKdzljQ1d5dHZ2a1JaWHBhdG15?= =?utf-8?B?cXlXNm5hM1ZpMHFtS0FvZThDTVNYczJleFBxRFZ6dndoNzZVblhoYm1KcTVO?= =?utf-8?B?eXVjT0F3d3Q0NzhYMzhZdFJCcEhQZ2c3dVNKZ1NWOXR4aTJzaXY3YjRXV3NG?= =?utf-8?B?WFFmTXVLb3ZoWEdrK25HdVhFbGdTNStnb0h3Z20yeHJpaEQzSDZOa0dpdUNs?= =?utf-8?B?UHlKRWgwWDQwdzVOVEpWT1ZXOU5GdVNSV01TQnRQb1dIUlZ1dWRZbkN0QU90?= =?utf-8?B?SWwxRUxybFpjblgxaHNMdDdpTHFTbTVvOGFpVlN3ZnU5ck94MFBCUkVnZEhq?= =?utf-8?B?MXlTaWRySHVMcGVkNHZoa3RpbldYMjQ5V0hCZEVJYU1HTnYxT3h5eGlZeitB?= =?utf-8?B?d0xraUJVbFpaQzNMRjZjWFVxWXdtM2d2bHdqSHBuNWVpR1FidlAwSWhNdmgx?= =?utf-8?B?YWoxSStPbUJXN0dEcFZGOUlxTEwxaWd5YU95aFlJV2JoS2MyMXIwclEyNHoy?= =?utf-8?B?ZFBOai94TXp4TEhoeVRUVDdRd3pkT0dqcHp2WmVFaXRxbDZuSmlQNHdHSzI3?= =?utf-8?B?bUFUamgzajNFb1l3R2cweCtEaEx0QmF5OUJEZDVWeFdYZWdRelZXNGpBWkd2?= =?utf-8?B?UHhwQUs3ZzN3M3pnVDErcU0vVHphb0Rrb3RqajhBOHNsOVRuVnFUSENNYTRv?= =?utf-8?B?N2kwZVcvQlpzSDA4Q3lSZVFSTkV1Ujl6d0ZGV3VYRnU5eUlxdEx2WTc3L1RV?= =?utf-8?B?OHRVS1ZRbTQ2U1p3eVNyMkhDTXdObGRrejNQTVlHV0JldkRuMlp5Uzg4YXFO?= =?utf-8?B?S1Vwb1dsMTgyeFYzTUd0QkNCT29YS3hDUUFFdk9OeHpIOHBGajFLS1JkMk5l?= =?utf-8?B?eldTWmUxYkFEa1MrbzMyb0hPL2ZJVkJxcVhXQk1IRTJkZi9HWVd2R2ZTd1B5?= =?utf-8?B?dnMxWm0vTS9maDU2ZjhlSTZxR3A0OVVDcm5ObUdhRHE0OVBxdnpxYzd4bkZU?= =?utf-8?B?dFltck53bFRhTzZEMWFPNUdMcy9CYktzMHcyR0Jkd1dEU2ltRnR4aDQrLzli?= =?utf-8?B?WmNCd3ppMExJTFJqcE1vaUQzTTBuQmhNZU0yN1JyS2JxcGl2YTYvRFNnQWw3?= =?utf-8?Q?Q8Ra4BGiUHdnQ3TfZT9+uDP1sC/a/3ACZu?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6594D3310310204C8C7B7D4D901E76C6@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mendix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR06MB4180.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aedb06d5-9836-4d02-7925-08d8b7ab6a76 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2021 10:10:12.5525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e3c78d-8e3b-46d8-bc56-5540da23ba4d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pwqVLXTcQv/lXEMW83RHcEsJ/iR+I+E1w0/amzRCu9+kkt3aiCdGOqQ5ZigjlzyMaTJ2EqaQjeFO2YLgSkrxFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2132 Archived-At: Subject: Re: [OAUTH-WG] Tenancy in OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 10:10:28 -0000 VGhhbmtzIEp1c3RpbiBhbmQgVmxhZGltaXIgZm9yIHlvdXIgZ3VpZGFuY2UhDQoNClRoZSByZXNv dXJjZSBpbmRpY2F0b3IgYXBwcm9hY2ggc2VlbXMgdG8gaGF2ZSB0aGUgYmVzdCBmaXQgZm9yIG15 IHVzZSBjYXNlLg0KSXQgYWRkcmVzc2VzIG15IGNvYXJzZS9taWQtZ3JhaW5lZCB1c2UgY2FzZSwg d2l0aG91dCBicmluZ2luZyB0aGUgY29tcGxleGl0eSBvZiB0aGUgZmluZS1ncmFpbmVkIFJBUiBh cHByb2FjaC4NCkVuY29kaW5nIHRoZSB0ZW5hbnQgaW50byBzY29wZSB2YWx1ZXMgcmVtYWlucyBh biBvcHRpb24gYXMgd2VsbC4NCkVuc3VyaW5nIHRoZSB0b2tlbiB2YWxpZGF0aW9uIGlzIGltcGxl bWVudGVkIHByb3Blcmx5IGlzIGluZGVlZCBhIHBvaW50IG9mIGF0dGVudGlvbi4NCg0KTWVhbndo aWxlIEkndmUgYmVlbiBsb29raW5nIGludG8gT0F1dGgvT0lEQyBzcGVjcyBmb3IgY2xpZW50IHJl Z2lzdHJhdGlvbi4gDQpJdCBtYXkgYWxzbyBiZSB1c2VmdWwgdG8gZXh0ZW5kIHRoZSBjbGllbnQn cyBtZXRhZGF0YSB3aXRoICdyZXNvdXJjZScgdG8gYmluZCB0aGUgc3BlY2lmaWMgY2xpZW50IHRv IGEgc3BlY2lmaWMgdGVuYW50KHMpLg0KV291bGQgdGhhdCBtYWtlIHNlbnNlIHRvIHlvdSBhcyB3 ZWxsPw0KDQpHcmVhdCBmZWVkYmFjaywga2luZCByZWdhcmRzLCANCkphYXANCg0KDQrvu79PbiAx Mi8wMS8yMDIxLCAyMzoxMCwgIk9BdXRoIG9uIGJlaGFsZiBvZiBvYXV0aC1yZXF1ZXN0QGlldGYu b3JnIiA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygb2F1dGgtcmVxdWVzdEBp ZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBTZW5kIE9BdXRoIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9u cyB0bw0KICAgIAlvYXV0aEBpZXRmLm9yZw0KDQogICAgVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2Ny aWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQogICAgCWh0dHBzOi8vZXVyMDMuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmFtcDtkYXRhPTA0JTdDMDElN0NqYWFw LmZyYW5ja2UlNDBtZW5kaXguY29tJTdDOTM3MDcyMDJiZDQ4NDc4OTUzMDAwOGQ4Yjc0NmUxZjQl N0NiNGUzYzc4ZDhlM2I0NmQ4YmM1NjU1NDBkYTIzYmE0ZCU3QzAlN0MwJTdDNjM3NDYwODYyMzgz MTY4MTY4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRh PXpOVnl1eTJhdkVFV3RJSjNlWFpHRVY5UzBLTHlZajI3S2lHMnlPUHRXOVElM0QmYW1wO3Jlc2Vy dmVkPTANCiAgICBvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3Ig Ym9keSAnaGVscCcgdG8NCiAgICAJb2F1dGgtcmVxdWVzdEBpZXRmLm9yZw0KDQogICAgWW91IGNh biByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQogICAgCW9hdXRoLW93bmVy QGlldGYub3JnDQoNCiAgICBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3Qg bGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQogICAgdGhhbiAiUmU6IENvbnRlbnRzIG9mIE9B dXRoIGRpZ2VzdC4uLiINCg0KDQogICAgVG9kYXkncyBUb3BpY3M6DQoNCiAgICAgICAxLiBSZTog VGVuYW5jeSBpbiBPQXV0aCAoSnVzdGluIFJpY2hlcikNCiAgICAgICAyLiBSZTogVGVuYW5jeSBp biBPQXV0aCAoVmxhZGltaXIgRHpodXZpbm92KQ0KDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAg ICBNZXNzYWdlOiAxDQogICAgRGF0ZTogVHVlLCAxMiBKYW4gMjAyMSAxNjoxMzoyNiAtMDUwMA0K ICAgIEZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCiAgICBUbzogSmFhcCBG cmFuY2tlIDxKYWFwLkZyYW5ja2U9NDBtZW5kaXguY29tQGRtYXJjLmlldGYub3JnPg0KICAgIENj OiAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBSZTogW09B VVRILVdHXSBUZW5hbmN5IGluIE9BdXRoDQogICAgTWVzc2FnZS1JRDogPEUzREU1RUQyLTc1MDYt NDA5MC1BMzJBLUYzRDRBRTc5N0RGNUBtaXQuZWR1Pg0KICAgIENvbnRlbnQtVHlwZTogdGV4dC9w bGFpbjsgY2hhcnNldD0idXRmLTgiDQoNCiAgICBIaSBKYWFwLA0KDQogICAgVGhlcmUgaGF2ZSBi ZWVuIGEgbnVtYmVyIG9mIGVmZm9ydHMgdG8gYWRkcmVzcyB0aGlzIGtpbmQgb2YgdGhpbmcgaW4g dGhlIE9BdXRoIHdvcmxkLiBZb3UgY2FuIGRlZmluaXRlbHkgdXNlIGEgc3BlY2lhbCBzY29wZSB0 byBlbmNvZGUgdGhpcyB2YWx1ZSwgd2hpY2ggaGFzIHRoZSBiZW5lZml0IG9mIGZpdHRpbmcgaW50 byB0aGUgaW1wbGVtZW50YXRpb24gbGltaXRhdGlvbnMgb2YgbmVhcmx5IGFsbCBPQXV0aCBzeXN0 ZW1zIG91dCB0aGVyZS4gVGhlID9yZXNvdXJjZT8gcGFyYW1ldGVyIGNhbiBhbHNvIGJlIHVzZWQg Zm9yIHRoZSBraW5kIG9mIHRoaW5nLCBhbmQgaXQgZ2l2ZXMgeW91IGEgYnVja2V0IHRoYXQ/cyBz ZXBhcmF0ZSBmcm9tID9zY29wZT8gc28gdGhhdCB5b3UgY2FuIGtlZXAgdGhlIGxhdHRlciBhdmFp bGFibGUgZm9yIGRlc2NyaWJpbmcgdGhlIEFQSSBpdHNlbGY6DQoNCiAgICBodHRwczovL2V1cjAz LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29s cy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NzA3JmFtcDtkYXRhPTA0JTdDMDElN0NqYWFwLmZyYW5j a2UlNDBtZW5kaXguY29tJTdDOTM3MDcyMDJiZDQ4NDc4OTUzMDAwOGQ4Yjc0NmUxZjQlN0NiNGUz Yzc4ZDhlM2I0NmQ4YmM1NjU1NDBkYTIzYmE0ZCU3QzAlN0MwJTdDNjM3NDYwODYyMzgzMTY4MTY4 JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1 TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPTVjbEtu JTJCOCUyRkNFaVFpbmRlamZIbmNBNjcwRldWb3klMkJIRFE0OUp0T09SakUlM0QmYW1wO3Jlc2Vy dmVkPTAgPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg3MDcmYW1wO2RhdGE9 MDQlN0MwMSU3Q2phYXAuZnJhbmNrZSU0MG1lbmRpeC5jb20lN0M5MzcwNzIwMmJkNDg0Nzg5NTMw MDA4ZDhiNzQ2ZTFmNCU3Q2I0ZTNjNzhkOGUzYjQ2ZDhiYzU2NTU0MGRhMjNiYTRkJTdDMCU3QzAl N0M2Mzc0NjA4NjIzODMxNjgxNjglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZhbXA7c2RhdGE9NWNsS24lMkI4JTJGQ0VpUWluZGVqZkhuY0E2NzBGV1ZveSUyQkhEUTQ5 SnRPT1JqRSUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCg0KICAgIFRoZXJlP3MgYWxzbyB0aGUgUmljaCBB dXRob3JpemF0aW9uIFJlcXVlc3QgKFJBUikgZHJhZnQgdGhhdCB0aGlzIGdyb3VwIGlzIGN1cnJl bnRseSB3b3JraW5nIG9uLCB3aGljaCBwcm92aWRlcyBhIG11bHRpLWRpbWVuc2lvbmFsIHdheSB0 byBkZXNjcmliZSBhY2Nlc3MuIEl0P3MgbW9yZSBjb21wbGV4IHRoYW4gc2NvcGVzLCBidXQgaXQg Ym9pbHMgZG93biB0byBoYXZpbmcgSlNPTiBvYmplY3RzIGRlc2NyaWJlIHRoZSBlbGVtZW50cyBu ZWVkZWQuIEluIHRoaXMgY2FzZSB5b3UgbWlnaHQgcHV0IHRoZSBBUEkgYml0cyBpbnRvIHRoZSA/ YWN0aW9ucz8gYW5kID9kYXRhdHlwZXM/IGZpZWxkcywgYW5kIHB1dCB0aGUgdGVuYW50IGluZm9y bWF0aW9uIGludG8gdGhlID9sb2NhdGlvbnM/IGZpZWxkLiBJIGJlbGlldmUgdGhlcmUgYXJlIHBl b3BsZSB1c2luZyBpdCBpbiBleGFjdGx5IHRoaXMgd2F5IHRvZGF5Og0KDQogICAgaHR0cHM6Ly9l dXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1vYXV0aC1yYXItMDMmYW1wO2RhdGE9 MDQlN0MwMSU3Q2phYXAuZnJhbmNrZSU0MG1lbmRpeC5jb20lN0M5MzcwNzIwMmJkNDg0Nzg5NTMw MDA4ZDhiNzQ2ZTFmNCU3Q2I0ZTNjNzhkOGUzYjQ2ZDhiYzU2NTU0MGRhMjNiYTRkJTdDMCU3QzAl N0M2Mzc0NjA4NjIzODMxNjgxNjglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZhbXA7c2RhdGE9aHhuMmdGZFVoaG1XcmYwQVRhcVVVVUI5QzYyeWglMkZZMjdhTk92UjFo V2JNJTNEJmFtcDtyZXNlcnZlZD0wIDxodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZk cmFmdC1pZXRmLW9hdXRoLXJhci0wMyZhbXA7ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQw bWVuZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4 ZTNiNDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4MzE2ODE2OCU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1oeG4yZ0ZkVWho bVdyZjBBVGFxVVVVQjlDNjJ5aCUyRlkyN2FOT3ZSMWhXYk0lM0QmYW1wO3Jlc2VydmVkPTA+DQoN CiAgICBUaGVyZSBhcmUgYWxzbyBzb21lIGhpc3RvcmljYWwgZWZmb3J0cyB0byBhZGRyZXNzIHRo aXMsIGluY2x1ZGluZyBhbiA/YXVkaWVuY2U/IGFuZCBhIChjb21wbGV0ZWx5IHNlcGFyYXRlKSA/ YXVkIiBwYXJhbWV0ZXIsIGJ1dCBBRkFJSyBuZWl0aGVyIG9mIHRoZXNlIGhhdmUgYmVlbiByYWlz ZWQgdG8gc3RhbmRhcmQgb3IgZXZlbiB0byBjb21tb24gcHJhY3RpY2UsIGFuZCBzbyBJIHdvdWxk bj90IHJlY29tbWVuZCBpdC4gSSBjdXJyZW50bHkgaGF2ZSBhIHByb2plY3QgdG8gbWlncmF0ZSBh IHN5c3RlbSB0aGF0P3MgY3VycmVudGx5IHVzaW5nIG9uZSBvZiB0aGVzZSBvbnRvIFJBUi4NCg0K ICAgICA/IEp1c3Rpbg0KDQogICAgPiBPbiBKYW4gMTIsIDIwMjEsIGF0IDExOjIwIEFNLCBKYWFw IEZyYW5ja2UgPEphYXAuRnJhbmNrZT00MG1lbmRpeC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3Rl Og0KICAgID4gDQogICAgPiBIaSwNCiAgICA+ICANCiAgICA+IEk/bSBsb29raW5nIGludG8gdGhl IHRvcGljIG9mIHRlbmFuY3kuIEEgbXVsdGktdGVuYW50IHNlcnZpY2UgY2FuIGJlIGNvbnNpZGVy ZWQgYXMgYW4gT0F1dGggUmVzb3VyY2UgU2VydmVyIG1hbmFnaW5nIHJlc291cmNlcyBvZiBkaWZm ZXJlbnQgdGVuYW50cy4NCiAgICA+IEFuIEFTIG1ha2VzIGF1dGhvcml6YXRpb24gZGVjaXNpb25z IGFuZCBjb21tdW5pY2F0ZXMgdGhlc2UgdXNpbmcgc2NvcGVzLCBzbyBvbmUgd2F5IHdvdWxkIGJl IHRvID9lbmNvZGU/IHRoZSB0ZW5hbnQgaW50byB0aGUgc2NvcGUgdmFsdWVzLg0KICAgID4gQW5v dGhlciBsaW5lIG9mIHRob3VnaHQgaXMgdG8gc29tZWhvdyBiaW5kL3Jlc3RyaWN0IGFuIGFjY2Vz LXRva2VuIHRvIGEgY2VydGFpbiB0ZW5hbnQsIGxlYXZpbmcgdGhlIHNldCBvZiBzY29wZXMgYmVp bmcgdXNlZCBtb3JlIHN0YXRpYy4NCiAgICA+ICANCiAgICA+IE15IHF1ZXN0aW9uIGlzIHdoZXRo ZXIgdGhpcyBoYXMgYmVlbiBhIHRvcGljIHRoYXQgaGFzIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBP QXV0aCB3b3JraW5nIGdyb3VwPyBBbnkgY29tbW9uIHByYWN0aWNlIG9yIGRyYWZ0Pw0KICAgID4g VGhhbmtzIGluIGFkdmFuY2UgZm9yIHlvdXIgcmVwbGllcy4NCiAgICA+ICANCiAgICA+IEtpbmQg cmVnYXJkcywNCiAgICA+ICANCiAgICA+IEphYXAgRnJhbmNrZQ0KICAgID4gUHJvZHVjdCBNYW5h Z2VyIElkZW50aXR5DQogICAgPiArMzEoMCk2NDE0OTUzMjQNCiAgICA+IG1lbmRpeC5jb20gPGh0 dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNB JTJGJTJGbWVuZGl4LmNvbSUyRiZhbXA7ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQwbWVu ZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4ZTNi NDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4MzE2ODE2OCU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1uUEtqZVBjJTJCJTJC OFR1TTR6dUNHNlpVMlhOc1BtSnh1NVdpZG1DSHo5RSUyQlNVJTNEJmFtcDtyZXNlcnZlZD0wPg0K ICAgID4gPGltYWdlMDAxLnBuZz4gPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3Lm1lbmRpeC5jb20lMkYmYW1wO2RhdGE9 MDQlN0MwMSU3Q2phYXAuZnJhbmNrZSU0MG1lbmRpeC5jb20lN0M5MzcwNzIwMmJkNDg0Nzg5NTMw MDA4ZDhiNzQ2ZTFmNCU3Q2I0ZTNjNzhkOGUzYjQ2ZDhiYzU2NTU0MGRhMjNiYTRkJTdDMCU3QzAl N0M2Mzc0NjA4NjIzODMxNjgxNjglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZhbXA7c2RhdGE9N0hRMXFlMzJIYzlRY1lOVlk4NjY3dWZ4bUx6N0REV0NZQThtaHNLU0hW byUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCiAgICA+ICANCiAgICA+ICANCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBPQXV0aCBtYWlsaW5n IGxpc3QNCiAgICA+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQogICAg PiBodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZvYXV0aCZhbXA7 ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQwbWVuZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3 ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4ZTNiNDZkOGJjNTY1NTQwZGEyM2JhNGQlN0Mw JTdDMCU3QzYzNzQ2MDg2MjM4MzE2ODE2OCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MxMDAwJmFtcDtzZGF0YT16TlZ5dXkyYXZFRVd0SUozZVhaR0VWOVMwS0x5WWoyN0tpRzJ5 T1B0VzlRJTNEJmFtcDtyZXNlcnZlZD0wIDxodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZvYXV0aCZhbXA7ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQwbWVu ZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4ZTNi NDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4MzE2ODE2OCU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT16TlZ5dXkyYXZFRVd0 SUozZVhaR0VWOVMwS0x5WWoyN0tpRzJ5T1B0VzlRJTNEJmFtcDtyZXNlcnZlZD0wPg0KICAgIC0t LS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KICAgIEFuIEhUTUwgYXR0YWNo bWVudCB3YXMgc2NydWJiZWQuLi4NCiAgICBVUkw6IDxodHRwczovL2V1cjAzLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRm Lm9yZyUyRmFyY2glMkZicm93c2UlMkZvYXV0aCUyRmF0dGFjaG1lbnRzJTJGMjAyMTAxMTIlMkYx OWFhNTVlMiUyRmF0dGFjaG1lbnQuaHRtJmFtcDtkYXRhPTA0JTdDMDElN0NqYWFwLmZyYW5ja2Ul NDBtZW5kaXguY29tJTdDOTM3MDcyMDJiZDQ4NDc4OTUzMDAwOGQ4Yjc0NmUxZjQlN0NiNGUzYzc4 ZDhlM2I0NmQ4YmM1NjU1NDBkYTIzYmE0ZCU3QzAlN0MwJTdDNjM3NDYwODYyMzgzMTY4MTY4JTdD VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPTFReldTeFE0 ZXNDeGpUSTZmNW1iN0NQRnhpWXM5YUNkVmNISXlFbnV3TWslM0QmYW1wO3Jlc2VydmVkPTA+DQoN CiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIE1lc3NhZ2U6IDINCiAg ICBEYXRlOiBXZWQsIDEzIEphbiAyMDIxIDAwOjEwOjAxICswMjAwDQogICAgRnJvbTogVmxhZGlt aXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4NCiAgICBUbzogb2F1dGhAaWV0 Zi5vcmcNCiAgICBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUZW5hbmN5IGluIE9BdXRoDQogICAg TWVzc2FnZS1JRDogPGNjNDE1MTdmLWY3MzItMGQ2Zi05NWYzLTY0YmI3ZmNkZjI0ZUBjb25uZWN0 MmlkLmNvbT4NCiAgICBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0K DQogICAgSGVsbG8gSmFhcCwNCg0KICAgIEp1c3RpbiBtYWRlIGEgZ29vZCBvdmVydmlldyBvZiB0 aGUgYXZhaWxhYmxlIE9BdXRoIGZhY2lsaXRpZXMgd2hlbg0KICAgIGRlYWxpbmcgd2l0aCBtdWx0 aXBsZSByZXNvdXJjZSBzZXJ2ZXJzIG9yIHJlc291cmNlIHNlcnZlciB0ZW5hbnRzLg0KDQogICAg SWYgeW91IGhhdmUgY29udHJvbCBvdmVyIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGkuZS4gdGhlIHRv a2VuIHZhbGlkYXRpb24NCiAgICBpcyBnb2luZyB0byBoYXBwZW4gaW4gb25lIHBsYWNlLCB0aGVu IHlvdSBoYXZlIHBsZW50eSBvZiBmcmVlZG9tIHRvIGZpbmQNCiAgICBvdXQgd2hhdCB3aWxsIHdv cmsgYmVzdCBmb3IgeW91LCBzZW1hbnRpY2FsbHkgYW5kIGluIHRlcm1zIG9mIGF2YWlsYWJsZQ0K ICAgIE9BdXRoIHNlcnZlci4NCg0KICAgIEluIGNhc2VzIHdoZW4gdGhlIHJlc291cmNlcyBhcmUg bGVmdCB0byBpbXBsZW1lbnQgdGhlIHRva2VuIHZhbGlkYXRpb24NCiAgICBvbiB0aGVpciBvd24g bXkgcHJlZmVycmVkIGFwcHJvYWNoIGlzIHRvIGVuY29kZSB0aGUgcmVzb3VyY2Ugc2VydmVyDQog ICAgaWRlbnRpdHkgKHRlbmFudCkgaW50byB0aGUgc2NvcGUgdmFsdWVzLiBBY2Nlc3MgaXMgZGVm aW5lZCBpbiBvbmUgcGxhY2UNCiAgICBhbmQgSSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IHRo ZSBkZXZlbG9wZXIgYWNjaWRlbnRhbGx5IGZvcmdldHRpbmcNCiAgICB0aGUgInJlc291cmNlIiBv ciAiYXVkKGllbmNlKSIgY2hlY2suDQoNCiAgICBWbGFkaW1pcg0KDQoNCiAgICBPbiAxMi8wMS8y MDIxIDIzOjEzLCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KICAgID4gSGkgSmFhcCwNCiAgICA+DQog ICAgPiBUaGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgZWZmb3J0cyB0byBhZGRyZXNzIHRoaXMg a2luZCBvZiB0aGluZyBpbg0KICAgID4gdGhlIE9BdXRoIHdvcmxkLiBZb3UgY2FuIGRlZmluaXRl bHkgdXNlIGEgc3BlY2lhbCBzY29wZSB0byBlbmNvZGUgdGhpcw0KICAgID4gdmFsdWUsIHdoaWNo IGhhcyB0aGUgYmVuZWZpdCBvZiBmaXR0aW5nIGludG8gdGhlIGltcGxlbWVudGF0aW9uDQogICAg PiBsaW1pdGF0aW9ucyBvZiBuZWFybHkgYWxsIE9BdXRoIHN5c3RlbXMgb3V0IHRoZXJlLiBUaGUg P3Jlc291cmNlPw0KICAgID4gcGFyYW1ldGVyIGNhbiBhbHNvIGJlIHVzZWQgZm9yIHRoZSBraW5k IG9mIHRoaW5nLCBhbmQgaXQgZ2l2ZXMgeW91IGENCiAgICA+IGJ1Y2tldCB0aGF0P3Mgc2VwYXJh dGUgZnJvbSA/c2NvcGU/IHNvIHRoYXQgeW91IGNhbiBrZWVwIHRoZSBsYXR0ZXINCiAgICA+IGF2 YWlsYWJsZSBmb3IgZGVzY3JpYmluZyB0aGUgQVBJIGl0c2VsZjoNCiAgICA+DQogICAgPiBodHRw czovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NzA3JmFtcDtkYXRhPTA0JTdDMDElN0Nq YWFwLmZyYW5ja2UlNDBtZW5kaXguY29tJTdDOTM3MDcyMDJiZDQ4NDc4OTUzMDAwOGQ4Yjc0NmUx ZjQlN0NiNGUzYzc4ZDhlM2I0NmQ4YmM1NjU1NDBkYTIzYmE0ZCU3QzAlN0MwJTdDNjM3NDYwODYy MzgzMTY4MTY4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3Nk YXRhPTVjbEtuJTJCOCUyRkNFaVFpbmRlamZIbmNBNjcwRldWb3klMkJIRFE0OUp0T09SakUlM0Qm YW1wO3Jlc2VydmVkPTANCiAgICA+DQogICAgPiBUaGVyZT9zIGFsc28gdGhlIFJpY2ggQXV0aG9y aXphdGlvbiBSZXF1ZXN0IChSQVIpIGRyYWZ0IHRoYXQgdGhpcw0KICAgID4gZ3JvdXAgaXMgY3Vy cmVudGx5IHdvcmtpbmcgb24sIHdoaWNoIHByb3ZpZGVzIGEgbXVsdGktZGltZW5zaW9uYWwgd2F5 DQogICAgPiB0byBkZXNjcmliZSBhY2Nlc3MuIEl0P3MgbW9yZSBjb21wbGV4IHRoYW4gc2NvcGVz LCBidXQgaXQgYm9pbHMgZG93bg0KICAgID4gdG8gaGF2aW5nIEpTT04gb2JqZWN0cyBkZXNjcmli ZSB0aGUgZWxlbWVudHMgbmVlZGVkLiBJbiB0aGlzIGNhc2UgeW91DQogICAgPiBtaWdodCBwdXQg dGhlIEFQSSBiaXRzIGludG8gdGhlID9hY3Rpb25zPyBhbmQgP2RhdGF0eXBlcz8gZmllbGRzLCBh bmQNCiAgICA+IHB1dCB0aGUgdGVuYW50IGluZm9ybWF0aW9uIGludG8gdGhlID9sb2NhdGlvbnM/ IGZpZWxkLiBJIGJlbGlldmUgdGhlcmUNCiAgICA+IGFyZSBwZW9wbGUgdXNpbmcgaXQgaW4gZXhh Y3RseSB0aGlzIHdheSB0b2RheToNCiAgICA+DQogICAgPiBodHRwczovL2V1cjAzLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1pZXRmLW9hdXRoLXJhci0wMyZhbXA7ZGF0YT0wNCU3QzAxJTdDamFh cC5mcmFuY2tlJTQwbWVuZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0 JTdDYjRlM2M3OGQ4ZTNiNDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4 MzE2ODE2OCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0 YT1oeG4yZ0ZkVWhobVdyZjBBVGFxVVVVQjlDNjJ5aCUyRlkyN2FOT3ZSMWhXYk0lM0QmYW1wO3Jl c2VydmVkPTANCiAgICA+DQogICAgPiBUaGVyZSBhcmUgYWxzbyBzb21lIGhpc3RvcmljYWwgZWZm b3J0cyB0byBhZGRyZXNzIHRoaXMsIGluY2x1ZGluZyBhbg0KICAgID4gP2F1ZGllbmNlPyBhbmQg YSAoY29tcGxldGVseSBzZXBhcmF0ZSkgP2F1ZCIgcGFyYW1ldGVyLCBidXQgQUZBSUsNCiAgICA+ IG5laXRoZXIgb2YgdGhlc2UgaGF2ZSBiZWVuIHJhaXNlZCB0byBzdGFuZGFyZCBvciBldmVuIHRv IGNvbW1vbg0KICAgID4gcHJhY3RpY2UsIGFuZCBzbyBJIHdvdWxkbj90IHJlY29tbWVuZCBpdC4g SSBjdXJyZW50bHkgaGF2ZSBhIHByb2plY3QNCiAgICA+IHRvIG1pZ3JhdGUgYSBzeXN0ZW0gdGhh dD9zIGN1cnJlbnRseSB1c2luZyBvbmUgb2YgdGhlc2Ugb250byBSQVIuDQogICAgPg0KICAgID4g Pz8gSnVzdGluDQogICAgPg0KICAgID4+IE9uIEphbiAxMiwgMjAyMSwgYXQgMTE6MjAgQU0sIEph YXAgRnJhbmNrZQ0KICAgID4+IDxKYWFwLkZyYW5ja2U9NDBtZW5kaXguY29tQGRtYXJjLmlldGYu b3JnDQogICAgPj4gPG1haWx0bzpKYWFwLkZyYW5ja2U9NDBtZW5kaXguY29tQGRtYXJjLmlldGYu b3JnPj4gd3JvdGU6DQogICAgPj4NCiAgICA+PiBIaSwNCiAgICA+PiA/DQogICAgPj4gST9tIGxv b2tpbmcgaW50byB0aGUgdG9waWMgb2YgdGVuYW5jeS4gQSBtdWx0aS10ZW5hbnQgc2VydmljZSBj YW4gYmUNCiAgICA+PiBjb25zaWRlcmVkIGFzIGFuIE9BdXRoIFJlc291cmNlIFNlcnZlciBtYW5h Z2luZyByZXNvdXJjZXMgb2YNCiAgICA+PiBkaWZmZXJlbnQgdGVuYW50cy4NCiAgICA+PiBBbiBB UyBtYWtlcyBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBhbmQgY29tbXVuaWNhdGVzIHRoZXNlIHVz aW5nDQogICAgPj4gc2NvcGVzLCBzbyBvbmUgd2F5IHdvdWxkIGJlIHRvID9lbmNvZGU/IHRoZSB0 ZW5hbnQgaW50byB0aGUgc2NvcGUgdmFsdWVzLg0KICAgID4+IEFub3RoZXIgbGluZSBvZiB0aG91 Z2h0IGlzIHRvIHNvbWVob3cgYmluZC9yZXN0cmljdCBhbiBhY2Nlcy10b2tlbiB0bw0KICAgID4+ IGEgY2VydGFpbiB0ZW5hbnQsIGxlYXZpbmcgdGhlIHNldCBvZiBzY29wZXMgYmVpbmcgdXNlZCBt b3JlIHN0YXRpYy4NCiAgICA+PiA/DQogICAgPj4gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGlz IGhhcyBiZWVuIGEgdG9waWMgdGhhdCBoYXMgYmVlbiBhZGRyZXNzZWQNCiAgICA+PiBpbiB0aGUg T0F1dGggd29ya2luZyBncm91cD8gQW55IGNvbW1vbiBwcmFjdGljZSBvciBkcmFmdD8NCiAgICA+ PiBUaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciByZXBsaWVzLg0KICAgID4+ID8NCiAgICA+PiBL aW5kIHJlZ2FyZHMsDQogICAgPj4gKj8qDQogICAgPj4gKkphYXAgRnJhbmNrZSoNCiAgICA+PiBQ cm9kdWN0IE1hbmFnZXIgSWRlbnRpdHkNCiAgICA+PiArMzEoMCk2NDE0OTUzMjQNCiAgICA+Pg0K ICAgID4+IG1lbmRpeC5jb20gPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGbWVuZGl4LmNvbSUyRiZhbXA7ZGF0YT0wNCU3QzAx JTdDamFhcC5mcmFuY2tlJTQwbWVuZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3 NDZlMWY0JTdDYjRlM2M3OGQ4ZTNiNDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2 MDg2MjM4MzE3ODE2NiU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFt cDtzZGF0YT0lMkZBTTdhN2lINXk4RTZFVEFnJTJCQW1yTmgzV25BdUJpT1olMkZFQmhpa3FPRnhJ JTNEJmFtcDtyZXNlcnZlZD0wPg0KICAgID4+DQogICAgPj4gKjxpbWFnZTAwMS5wbmc+KiA8aHR0 cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0El MkYlMkZ3d3cubWVuZGl4LmNvbSUyRiZhbXA7ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQw bWVuZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4 ZTNiNDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4MzE3ODE2NiU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1NYXFIM0t2NG9i NTZMcDI4bTlnMmlkTEVYaUxscGtrd3Q0UWN0WVRBaXFnJTNEJmFtcDtyZXNlcnZlZD0wPg0KICAg ID4+ICo/Kg0KICAgID4+ID8NCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KICAgID4+IE9BdXRo QGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQogICAgPj4gaHR0cHM6Ly9ldXIwMy5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDQlN0MwMSU3Q2ph YXAuZnJhbmNrZSU0MG1lbmRpeC5jb20lN0M5MzcwNzIwMmJkNDg0Nzg5NTMwMDA4ZDhiNzQ2ZTFm NCU3Q2I0ZTNjNzhkOGUzYjQ2ZDhiYzU2NTU0MGRhMjNiYTRkJTdDMCU3QzAlN0M2Mzc0NjA4NjIz ODMxNzgxNjYlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2Rh dGE9OCUyRmslMkJWWlM5ZSUyQiUyRkN3RXdTVm83bnFpdnV3amRnM0p5NDh4NmF3a0JUeFYwJTNE JmFtcDtyZXNlcnZlZD0wDQogICAgPg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBPQXV0aCBtYWlsaW5nIGxpc3QNCiAg ICA+IE9BdXRoQGlldGYub3JnDQogICAgPiBodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZvYXV0aCZhbXA7ZGF0YT0wNCU3QzAxJTdDamFhcC5mcmFuY2tlJTQwbWVu ZGl4LmNvbSU3QzkzNzA3MjAyYmQ0ODQ3ODk1MzAwMDhkOGI3NDZlMWY0JTdDYjRlM2M3OGQ4ZTNi NDZkOGJjNTY1NTQwZGEyM2JhNGQlN0MwJTdDMCU3QzYzNzQ2MDg2MjM4MzE3ODE2NiU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT04JTJGayUyQlZaUzll JTJCJTJGQ3dFd1NWbzducWl2dXdqZGczSnk0OHg2YXdrQlR4VjAlM0QmYW1wO3Jlc2VydmVkPTAN Cg0KICAgIC0tIA0KICAgIFZsYWRpbWlyIER6aHV2aW5vdg0KDQogICAgLS0tLS0tLS0tLS0tLS0g bmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tDQogICAgQW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1 YmJlZC4uLg0KICAgIFVSTDogPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUy RmJyb3dzZSUyRm9hdXRoJTJGYXR0YWNobWVudHMlMkYyMDIxMDExMyUyRjEzNmI1OTg1JTJGYXR0 YWNobWVudC5odG0mYW1wO2RhdGE9MDQlN0MwMSU3Q2phYXAuZnJhbmNrZSU0MG1lbmRpeC5jb20l N0M5MzcwNzIwMmJkNDg0Nzg5NTMwMDA4ZDhiNzQ2ZTFmNCU3Q2I0ZTNjNzhkOGUzYjQ2ZDhiYzU2 NTU0MGRhMjNiYTRkJTdDMCU3QzAlN0M2Mzc0NjA4NjIzODMxNzgxNjYlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9MGRKM2tZeWlnZEJ0YlVETmh3Umlw QXp3ajV1cnprS0tMQ3pxdUdUeTd2WSUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCiAgICAtLS0tLS0tLS0t LS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0NCiAgICBBIG5vbi10ZXh0IGF0dGFjaG1lbnQg d2FzIHNjcnViYmVkLi4uDQogICAgTmFtZTogc21pbWUucDdzDQogICAgVHlwZTogYXBwbGljYXRp b24vcGtjczctc2lnbmF0dXJlDQogICAgU2l6ZTogNDAwNyBieXRlcw0KICAgIERlc2M6IFMvTUlN RSBDcnlwdG9ncmFwaGljIFNpZ25hdHVyZQ0KICAgIFVSTDogPGh0dHBzOi8vZXVyMDMuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZl LmlldGYub3JnJTJGYXJjaCUyRmJyb3dzZSUyRm9hdXRoJTJGYXR0YWNobWVudHMlMkYyMDIxMDEx MyUyRjEzNmI1OTg1JTJGYXR0YWNobWVudC5wN3MmYW1wO2RhdGE9MDQlN0MwMSU3Q2phYXAuZnJh bmNrZSU0MG1lbmRpeC5jb20lN0M5MzcwNzIwMmJkNDg0Nzg5NTMwMDA4ZDhiNzQ2ZTFmNCU3Q2I0 ZTNjNzhkOGUzYjQ2ZDhiYzU2NTU0MGRhMjNiYTRkJTdDMCU3QzAlN0M2Mzc0NjA4NjIzODMxNzgx NjYlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9JTJC cU1IeTRaJTJGa2pSQ2V5RThVSGdVdXF0bThEJTJGTHdQZDJIZmZFbWhpVmZjcyUzRCZhbXA7cmVz ZXJ2ZWQ9MD4NCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgU3Vi amVjdDogRGlnZXN0IEZvb3Rlcg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgICBPQXV0aEBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm9h dXRoJmFtcDtkYXRhPTA0JTdDMDElN0NqYWFwLmZyYW5ja2UlNDBtZW5kaXguY29tJTdDOTM3MDcy MDJiZDQ4NDc4OTUzMDAwOGQ4Yjc0NmUxZjQlN0NiNGUzYzc4ZDhlM2I0NmQ4YmM1NjU1NDBkYTIz YmE0ZCU3QzAlN0MwJTdDNjM3NDYwODYyMzgzMTc4MTY2JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk OGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pY VkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPTglMkZrJTJCVlpTOWUlMkIlMkZDd0V3U1ZvN25x aXZ1d2pkZzNKeTQ4eDZhd2tCVHhWMCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQoNCiAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIEVuZCBvZiBPQXV0aCBEaWdlc3QsIFZvbCAx NDcsIElzc3VlIDYNCiAgICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoN Cg== From nobody Wed Jan 13 13:52:58 2021 Return-Path: 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 86E643A16D9; Wed, 13 Jan 2021 13:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7enmW31tYsxD; Wed, 13 Jan 2021 13:52:48 -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 044853A16BA; Wed, 13 Jan 2021 13:52:01 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10DLpx4i022311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jan 2021 16:52:00 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Justin Richer In-Reply-To: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> Date: Wed, 13 Jan 2021 16:51:59 -0500 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: <0062E5EE-4AD3-47FE-A81A-6D724B001929@mit.edu> References: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> To: Nicolas Mora X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 21:52:57 -0000 Hi Nicolas, > On Jan 10, 2021, at 8:36 PM, Nicolas Mora = wrote: >=20 > Hello, >=20 > I've implemented Rich Authorization Requests defined in = draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I = humbly wanted to write my feedback about this implementation to share my = experience. >=20 > For starters, this implementation and my following feedbacks are based = on the prism of Glewlwyd's implementation and philosophy, and my limited = experience on OAuth2, so I appologize in advance if I write non-sense or = big mistakes. >=20 Thanks for reaching out! Implementation experience is incredibly valued = here in the IETF, especially when someone=E2=80=99s coming to the spec = from =E2=80=9Coutside=E2=80=9D the community. :) > 1 - Design >=20 > The way I saw it, there are 2 different approaches to implement oauth2 = rar: either to get a token with a more detailed scope, or to get a = one-time token with extra grants. >=20 > Both are not exclusive, but a big difference I see between those 2 = approaches is the grant access from the user part. The second approach = would require the user to know what extra grant is asked by the client = every time the client asks for it, i.e. when the client redirects the = user to the /authorization endpoint. >=20 > To be more consistent with Glewlwyd's philosophy, I chose the first = approach, with those rules. > The AS administrator declares what rar types are allowed [2] > - a rar type has a defined set of locations, actions, datatypes and = enriched authorization details that the client can ask for > - the client must be explicitly allowed to add a rar type in the = authorization request > - a rar type can be linked to one or more scope. In that case, the = authorization request must include at least one of the linked scope, and = the scope must be available for the user and the scope must be granted = to the client > - the client can add as many properties as required in the rar type, = those extra properties are not verified by the AS, on access granted, = the extra properties will be present in the "authorization_details" = result. >=20 I think this is an interesting approach, but I=E2=80=99m not sure about = a few things: - What=E2=80=99s the utility of linking to a scope. Why require both = structures to be interpreted together like that? - There will absolutely be implementations that do not limit which RAR = types (or even values) the client is allowed to send, much like there = are implementations today that don=E2=80=99t restrict scopes on a = per-client basis. - I don=E2=80=99t think that we can say the AS doesn=E2=80=99t verify = =E2=80=9Cextra required properties=E2=80=9D, since the AS can (and = arguably should) know about the details of the =E2=80=9Ctype=E2=80=9D = being used, and enforce internal consistency and structure. > On first use of a rar type by a client for a user, the user must grant = to the client the rar access [3]. That's why the grant message will show = to the user ALL access possible via this rar type > Once this access is granted or not, the user will not be asked again = on another authorization request by the client (but is can be changed at = any time, as a scope grant). >=20 It=E2=80=99s always up to the AS to determine what the granted access = is, whether it=E2=80=99s for a new token, a limitation of existing grant = (via refresh token), or a client asking for something =E2=80=9Cadditional=E2= =80=9D for whatever purpose.=20 > 2 - Limitations >=20 > In this design, the AS has a limited control over the = authorization_details content, and the trust between the AS and the = client must be high enough so if a rar type can gain access to sensitive = actions or information, the user should know about it. The AS has full control to interpret the authorization_details content, = and apply it to access token granting policies, which include whether to = ask the user to grant anything.=20 >=20 > Also, in the draft specification, the only mandatory element type in a = rar is the "type" element. In my point of view, this means that the = business logic is mostly defined by the RS, rather than the AS. Just like =E2=80=9Cscope=E2=80=9D in OAuth, it=E2=80=99s ultimately = enforced by the RS, but the AS works in the process to interpret and = potentially modify the meaning of the scope.=20 >=20 > Therefore, for a client implementation to be compliant with the specs, = there's not much to do: add as a parameter a JSON array with objects = containing at least one "type" string property in it. >=20 Yup =E2=80=94 and even more, most clients will be sending in static or = templated values that the developers get from documentation, much like = they do with scopes in APIs today. Keeping it simple for clients is = definitely a goal! > 3 - Extensions >=20 > I believe one way to mitigate these limitations is to allow extensions = to be defined on top of the rar specifications. An extension can be = declared like this: >=20 > "RAR Extension XYZ: > A rar whose type is XXX > - Actions available: YYY, ZZZ or AAA > - datatypes possibles: BBB, CCC, DDD or EEE > - additional elements mandatory: an array of FFF and an object of GGG = to represent access to some" >=20 > Like this, if the AS, the RS and the client agree on using a rar = extension, they can have at least a detailed pattern on what to expect = in the rar type. I like that structure, but not for =E2=80=9Cextensions=E2=80=9D exactly; = more properly, I think this can be some guidance on how to create a RAR = =E2=80=9Ctype=E2=80=9D definition. This fits with the philosophy of = =E2=80=9Ctype=E2=80=9D defining what=E2=80=99s allowed to go in the = object, but it would allow for a more formal definition of what that = connection is. Should this be normative, or just informative, though? = I=E2=80=99m not sure yet =E2=80=94 I will try to come up with some = proposed text on that and propose a PR. =E2=80=94 Justin >=20 > Any thoughts? >=20 > /Nicolas >=20 > [1] https://github.com/babelouest/glewlwyd > [2] = https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screensh= ots/plugin-oidc-rar.png > [3] = https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screensh= ots/login-rar-grant.png >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 13 18:50:35 2021 Return-Path: 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 D379C3A0E85 for ; Wed, 13 Jan 2021 18:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=babelouest.org 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 hV3UCq1eNzXS for ; Wed, 13 Jan 2021 18:50:31 -0800 (PST) Received: from perceval.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B833A0E83 for ; Wed, 13 Jan 2021 18:50:30 -0800 (PST) Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-10-70-51-43-204.dsl.bell.ca [70.51.43.204]) by perceval.babelouest.org (Postfix) with ESMTPSA id 9565327473 for ; Wed, 13 Jan 2021 21:50:28 -0500 (EST) Authentication-Results: OpenDMARC; dmarc=fail (p=quarantine dis=none) header.from=babelouest.org Authentication-Results: OpenDMARC; spf=fail smtp.mailfrom=nicolas@babelouest.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=babelouest.org; s=mail; t=1610592628; bh=gWUBvtjdOrfENSBsvzIGT6QQj1tYGgENi02+FF280Bc=; h=To:References:From:Subject:Date:In-Reply-To:From; b=iXEKErqTaKx0RyKcHzSqsKsWSJvX55C23K92tFUalPAdEVnOB7VLAf5rALETJln9o wIFx8h0R2adiPSrN/IMzr+csXq2m9bvUNUdp98X3K7rYXCHjXaPL2n7tdDLY3A0e72 zir91UCARxB+g/nzyWX3HJLnGbsQlI7ZrVKFl5w9I6nzF+KEzJDm5QZXZvd1hT8nKD ikxqxy/LJTkyEEzuxFjmZ4yuC0D2Gd/Eb26YjPhIE/tAZDhrRNCwTbqOP+1TjZrtMA dODaKazw2q+FHc13Jxu9EL0CpGkRe4jk6D5vgvozNAoVvErQ5KOa/BRFZMhK5xhOdK kk/5tY1SrWJAg== To: oauth@ietf.org References: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> <0062E5EE-4AD3-47FE-A81A-6D724B001929@mit.edu> From: Nicolas Mora Autocrypt: addr=nicolas@babelouest.org; keydata= xsFNBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABzSVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+wsF3BBMBCAAhBQJZiaq/AhsDBQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEP6CE5RAvSK5ZTkP/3PN+SPKLKOcgG/C3ZI9KxM93y4AKZ0z UCBtr2QJDt8viFKq3jPsSo6+Rw1UuY2oDx4wWUXqlsp3NKnvoKWMip6UVVH0XB48iLe4Tiu0 PVqIfHB/MIdE/QSYLFZzX0n4AgTlrho7Hd+S7TZMtf15FKF4/8y5lLVXK86cbZhaOEPcJyb9 taT4IVkU5M22aNfuZAUjexeCsn/em4pjEyREilht8Fo9tND9Nr/w2SOJNAKWZp+JlKR1ok3z sFvEN5rAEsdA9gvQ/5ubs8iXM0KfBHLa0wp/YWRLRrDFoCEqrkZdBetGxJn4G+wNdhb4TTsX HTfb/0Je179uF2jcFawr/DhJb/bKJUB236u2+0e53QufYq8brBqA4aONDCfOVAHVNjazruCK Wli2E2lHvJLVQeFkBP2Mo9IiWO8uNdXpK5QUjcipW5t6fxN1beNzJdZLiHVjjVKskVueoLDY tHt0TzPY75I6Bgy/oRz5e1sP6UjYsZs5+ZUFOw7Zii5kXcPDrhXb1sEd9ZvB4f9XdvxtE91h aUz9EW63XIvsUYsnjqdTznojBVeLVVnZJKp3RlWFw0o0xT90JuOkA5Pw8oL0GpBRA9vaPi1p hs2DCbCRe/U188HkNmhiH1C9dY+J/4h8IvicjIgTI0+27FPFxp6nMlkH4OgjUHZrbvE9E8Sr zonrzsFNBFmJqr8BEADrI5lstjLaS6IXxH37GWvfPLdjLyTFK5kJqyZkhGNMWHmwmRU3BVrz 0M0Tva/a3Z1B+fXJGzKevQhKMBsrpYhkbKkbMg7vreiWhZjQyy5nvbKA4aMhZ1ckmYWExOk2 QiUpTDoLDBN7VEZG+FV9Hw5ZVeH1k5LnbIxxxIGdzK1mxcCBgJodvzHsp1SZefVIKBKLH+y+ scAZDbnDfSUo/1pPgruogskpg67XrtDP/mZxgf7GB0wlrQrrJt9eBuCD5NXIjtl8KvEIPKTx AlYf/Gu8ZCuu0cwHLl/79WUH6wT35XByAsBMtuG8dHDidj50/XkpP2L6GE52KYTNoQVv5XoA IzpuwXDxcTML0JjE1EKAfRFeyuuiMncX9dgtRdJGMgN/4HYzIiSvWsjYkgVUFrh/ZlENbE6D hy4NLqDEBQb5RMIWrO7VVaAKosRysY72G3Z1FmS2m2dPAlNNLGHESlcLp3nwnNFFneQif4Kf 1ZdFMZJCy8D6n+TbuZmY8eMC624Ot5h18an0yBWFE8E/XU4yQR6savhhinY1Yc4EKjcNiP4c Trphh4cE7XgMitX+0yc1D9s7umuiBdqw9VAsyA20NfLZCMxieiGYcgda1WPA5V7jQc3m8G+C Jyg762Tb3XyPGBPy4TDfghpw1RqYf8wYAi8e74wKHck/uAP6R1lc7wARAQABwsFfBBgBCAAJ BQJZiaq/AhsMAAoJEP6CE5RAvSK5Y4AP/Rb0F2lmB6uDu66BhCYX7Z2hcnt4/LZK1hYb6fRO 3mnW8XClntYOGbKoAGAQDS3PrIx2EJkUr5FiWMpnneQPcwfNuL7VlSqlcFfwN+kkjTcsIjrw 3KMgGNbjjQ83jCUzidyQ4eg18AKKaxb0NrA8UNRTvtK0ozSThxnzLZ20nu/mU9NJhcMVx2Qz IEUiJK5ag3uXli/r52ILle5Wq9LPxjPEsl0oGlqNMGcCZLr20tHXm0XLrSVEenWKL8hjaEud PNdcKMLBWVsp0VIS/di1fsQgwhuJ9C+fwhtqaGsL5DsKDYhrUo1iKi4avX0f8IdzenQSKFso Jf+t+kHIm5/ZdZ8jMN081RznIvz8p8BxWOzbg+BZCCkOIsCxypmU9WgMMJ3hXgRa2OIhQZQ3 AnBc/U843uU/7HVRMhd4efzjNw/v1joDd4KEJEHnS/jT/s9jxEyikOtQW9otJBLgZpoEG+9R FCKPu4TV8RB9kZCHOM5lwSwq7CIwwVltF1pMRokm6X7lyclZ4iCEtfZAM6ZuvN/fh1GbIJxf t+hIWqDPiG9bPtoXZMArUi1zCaSmFdzba/15+P+B3EyaadYiSjVn9WBhe6syxZ8WYo0ehvJE e42BLGcGRcQl+l2Jt57D3FPDYYJEUkl72sGhhKbrg4YBVfCoWuchD0wXvR9ARXtLK5H4 Message-ID: Date: Wed, 13 Jan 2021 21:50:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <0062E5EE-4AD3-47FE-A81A-6D724B001929@mit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vSbnaEdrY7foQtyKTaEHcl170ErFTEmac" Archived-At: Subject: Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 02:50:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vSbnaEdrY7foQtyKTaEHcl170ErFTEmac Content-Type: multipart/mixed; boundary="rqi6GmRCQIFvAqXtkYB6wCiWvbj6wYPLx"; protected-headers="v1" From: Nicolas Mora To: oauth@ietf.org Message-ID: Subject: Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation References: <511128bf-348f-fc92-ddf1-9598502a20a9@babelouest.org> <0062E5EE-4AD3-47FE-A81A-6D724B001929@mit.edu> In-Reply-To: <0062E5EE-4AD3-47FE-A81A-6D724B001929@mit.edu> --rqi6GmRCQIFvAqXtkYB6wCiWvbj6wYPLx Content-Type: multipart/mixed; boundary="------------AB80F745F3C1A5FB96620DC8" Content-Language: en-US This is a multi-part message in MIME format. --------------AB80F745F3C1A5FB96620DC8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Thank you for your feedback, I'll add some precision then Le 2021-01-13 =C3=A0 16 h 51, Justin Richer a =C3=A9crit=C2=A0: >=20 > I think this is an interesting approach, but I=E2=80=99m not sure about= a few things: >=20 > - What=E2=80=99s the utility of linking to a scope. Why require both st= ructures to be interpreted together like that? Linking a rar to a scope is not mandatory, i.e. if a rar type has no=20 scope, then the type will be available for every request and every user. That said, in Glewlwyd, the access level is the scopes. A user "has" a=20 set of scopes which can be granted or not during authorization requests. Therefore if the client requests scopes and some are not available for=20 the user, the grant will be limited to the ones available. The rar types are another type of access levels, therefore I assume that = a rar type can be unavailable for a user, so I allow to bind a rar type=20 to the scopes for that purpose. But that's a design choice. > - There will absolutely be implementations that do not limit which RAR = types (or even values) the client is allowed to send, much like there are= implementations today that don=E2=80=99t restrict scopes on a per-client= basis. > - I don=E2=80=99t think that we can say the AS doesn=E2=80=99t verify =E2= =80=9Cextra required properties=E2=80=9D, since the AS can (and arguably = should) know about the details of the =E2=80=9Ctype=E2=80=9D being used, = and enforce internal consistency and structure. >=20 I agree, but the specs doesn't mandate, allow, nor forbid anything about = the extra properties. Assuming that, I didn't want the admin to have to use a hardcoded rar=20 structure, and because this implementation is a first shot, I didn't=20 want to complicate the rar type configuration, which could be dangerous=20 to implement. Other part of the application are very customizable and were painful to=20 implement. >=20 > It=E2=80=99s always up to the AS to determine what the granted access i= s, whether it=E2=80=99s for a new token, a limitation of existing grant (= via refresh token), or a client asking for something =E2=80=9Cadditional=E2= =80=9D for whatever purpose. >=20 I don't allow a client to upgrade the grant access via the refresh=20 token, only the same grant access. Therefore to be consistent, the=20 client can't change the rar request during a refresh, and the new access = token will have the same rar content as the one granted during the=20 authorization. >> Also, in the draft specification, the only mandatory element type in a= rar is the "type" element. In my point of view, this means that the busi= ness logic is mostly defined by the RS, rather than the AS. >=20 > Just like =E2=80=9Cscope=E2=80=9D in OAuth, it=E2=80=99s ultimately enf= orced by the RS, but the AS works in the process to interpret and potenti= ally modify the meaning of the scope. >=20 Yes, if we use a rar reduced only to what's required in the specs, then=20 a rar type has no more information than a scope, so the advantage of rar = lies beyond the mandatory parts of the specs. But to have a usable rar, the triad client-AS-RS must previously agree=20 to use rar types defined outside of the specs. This is not necessary a disadvantage though. >> >> Therefore, for a client implementation to be compliant with the specs,= there's not much to do: add as a parameter a JSON array with objects con= taining at least one "type" string property in it. >> >=20 > Yup =E2=80=94 and even more, most clients will be sending in static or = templated values that the developers get from documentation, much like th= ey do with scopes in APIs today. Keeping it simple for clients is definit= ely a goal! >=20 Ack >> 3 - Extensions >> >> I believe one way to mitigate these limitations is to allow extensions= to be defined on top of the rar specifications. An extension can be decl= ared like this: >> >> "RAR Extension XYZ: >> A rar whose type is XXX >> - Actions available: YYY, ZZZ or AAA >> - datatypes possibles: BBB, CCC, DDD or EEE >> - additional elements mandatory: an array of FFF and an object of GGG = to represent access to some" >> >> Like this, if the AS, the RS and the client agree on using a rar exten= sion, they can have at least a detailed pattern on what to expect in the = rar type. >=20 > I like that structure, but not for =E2=80=9Cextensions=E2=80=9D exactly= ; more properly, I think this can be some guidance on how to create a RAR= =E2=80=9Ctype=E2=80=9D definition. This fits with the philosophy of =E2=80= =9Ctype=E2=80=9D defining what=E2=80=99s allowed to go in the object, but= it would allow for a more formal definition of what that connection is. = Should this be normative, or just informative, though? I=E2=80=99m not su= re yet =E2=80=94 I will try to come up with some proposed text on that an= d propose a PR. >=20 I used the name extension because the first example I had in mind is the = extensions and protocols describe in the websocket specs, but I don't=20 mind the name that should be used. Describing the rar types normalization structure is what I think could=20 be improved, at least specifying how it should be normalized and for=20 what purpose. /Nicolas --------------AB80F745F3C1A5FB96620DC8 Content-Type: application/pgp-keys; name="OpenPGP_0xFE82139440BD22B9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0xFE82139440BD22B9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX76= fs+ F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU7Qe1M= 2Do fmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mzO7dtMY6XQ= kpv qtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5JNHsANmgsWCch= eEL 15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvyg7LL9GsrAaH51ksR1= ksD H41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJeqRDF1HfjPFFm3dZ7E0dLR= 0aP vxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/icho20wnEVJsVrbNld/0fMvxen= rWS muwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURiSbAyNmfoOII9GBTAFm13XkHWbBysp= pGQ VAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOho4GYW4d/smGlCbki/bYdSItbtk4rjHAyl= +WY M6Jpy1sZXe7SDQARAQABzSVOaWNvbGFzIE1vcmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+w= sF3 BBMBCAAhBQJZiaq/AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEP6CE5RAvSK5ZTkP/= 3PN +SPKLKOcgG/C3ZI9KxM93y4AKZ0zUCBtr2QJDt8viFKq3jPsSo6+Rw1UuY2oDx4wWUXqlsp3N= Knv oKWMip6UVVH0XB48iLe4Tiu0PVqIfHB/MIdE/QSYLFZzX0n4AgTlrho7Hd+S7TZMtf15FKF4/= 8y5 lLVXK86cbZhaOEPcJyb9taT4IVkU5M22aNfuZAUjexeCsn/em4pjEyREilht8Fo9tND9Nr/w2= SOJ NAKWZp+JlKR1ok3zsFvEN5rAEsdA9gvQ/5ubs8iXM0KfBHLa0wp/YWRLRrDFoCEqrkZdBetGx= Jn4 G+wNdhb4TTsXHTfb/0Je179uF2jcFawr/DhJb/bKJUB236u2+0e53QufYq8brBqA4aONDCfOV= AHV NjazruCKWli2E2lHvJLVQeFkBP2Mo9IiWO8uNdXpK5QUjcipW5t6fxN1beNzJdZLiHVjjVKsk= Vue oLDYtHt0TzPY75I6Bgy/oRz5e1sP6UjYsZs5+ZUFOw7Zii5kXcPDrhXb1sEd9ZvB4f9XdvxtE= 91h aUz9EW63XIvsUYsnjqdTznojBVeLVVnZJKp3RlWFw0o0xT90JuOkA5Pw8oL0GpBRA9vaPi1ph= s2D CbCRe/U188HkNmhiH1C9dY+J/4h8IvicjIgTI0+27FPFxp6nMlkH4OgjUHZrbvE9E8Srzonrz= sFN BFmJqr8BEADrI5lstjLaS6IXxH37GWvfPLdjLyTFK5kJqyZkhGNMWHmwmRU3BVrz0M0Tva/a3= Z1B +fXJGzKevQhKMBsrpYhkbKkbMg7vreiWhZjQyy5nvbKA4aMhZ1ckmYWExOk2QiUpTDoLDBN7V= EZG +FV9Hw5ZVeH1k5LnbIxxxIGdzK1mxcCBgJodvzHsp1SZefVIKBKLH+y+scAZDbnDfSUo/1pPg= ruo gskpg67XrtDP/mZxgf7GB0wlrQrrJt9eBuCD5NXIjtl8KvEIPKTxAlYf/Gu8ZCuu0cwHLl/79= WUH 6wT35XByAsBMtuG8dHDidj50/XkpP2L6GE52KYTNoQVv5XoAIzpuwXDxcTML0JjE1EKAfRFey= uui MncX9dgtRdJGMgN/4HYzIiSvWsjYkgVUFrh/ZlENbE6Dhy4NLqDEBQb5RMIWrO7VVaAKosRys= Y72 G3Z1FmS2m2dPAlNNLGHESlcLp3nwnNFFneQif4Kf1ZdFMZJCy8D6n+TbuZmY8eMC624Ot5h18= an0 yBWFE8E/XU4yQR6savhhinY1Yc4EKjcNiP4cTrphh4cE7XgMitX+0yc1D9s7umuiBdqw9VAsy= A20 NfLZCMxieiGYcgda1WPA5V7jQc3m8G+CJyg762Tb3XyPGBPy4TDfghpw1RqYf8wYAi8e74wKH= ck/ uAP6R1lc7wARAQABwsFfBBgBCAAJBQJZiaq/AhsMAAoJEP6CE5RAvSK5Y4AP/Rb0F2lmB6uDu= 66B hCYX7Z2hcnt4/LZK1hYb6fRO3mnW8XClntYOGbKoAGAQDS3PrIx2EJkUr5FiWMpnneQPcwfNu= L7V lSqlcFfwN+kkjTcsIjrw3KMgGNbjjQ83jCUzidyQ4eg18AKKaxb0NrA8UNRTvtK0ozSThxnzL= Z20 nu/mU9NJhcMVx2QzIEUiJK5ag3uXli/r52ILle5Wq9LPxjPEsl0oGlqNMGcCZLr20tHXm0XLr= SVE enWKL8hjaEudPNdcKMLBWVsp0VIS/di1fsQgwhuJ9C+fwhtqaGsL5DsKDYhrUo1iKi4avX0f8= Idz enQSKFsoJf+t+kHIm5/ZdZ8jMN081RznIvz8p8BxWOzbg+BZCCkOIsCxypmU9WgMMJ3hXgRa2= OIh QZQ3AnBc/U843uU/7HVRMhd4efzjNw/v1joDd4KEJEHnS/jT/s9jxEyikOtQW9otJBLgZpoEG= +9R FCKPu4TV8RB9kZCHOM5lwSwq7CIwwVltF1pMRokm6X7lyclZ4iCEtfZAM6ZuvN/fh1GbIJxft= +hI WqDPiG9bPtoXZMArUi1zCaSmFdzba/15+P+B3EyaadYiSjVn9WBhe6syxZ8WYo0ehvJEe42BL= GcG RcQl+l2Jt57D3FPDYYJEUkl72sGhhKbrg4YBVfCoWuchD0wXvR9ARXtLK5H4 =3D1rnn -----END PGP PUBLIC KEY BLOCK----- --------------AB80F745F3C1A5FB96620DC8-- --rqi6GmRCQIFvAqXtkYB6wCiWvbj6wYPLx-- --vSbnaEdrY7foQtyKTaEHcl170ErFTEmac Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAl//sXIFAwAAAAAACgkQ/oITlEC9Irlu rhAAu9PnsrETUEDeHN37s/EqAbzEIQ9jGKJCiyOLCZZnDvAt35zJPwhZLMKTA9sxvxQbZjplX8g5 zxRftIy8UjuWVGs5jQ6C1bN2ljJLWgMJuITn1Q972RJD86Cp6wevU32F3KVwqnQoMY1nBKRTO57M 1NCu/dXDFQlgkjgLTjN4ZMHm8XzFQpMLV0YT8Oz8eDEJDm5/zCgrJv9K/XKIUoFGouV/icghguCJ urEmSe5UeBVQpCFkW1uoZI31LX4Ppyxfwo+3LQ2XSuoyRqSalqQsqHKDGN9BWiXzr/zoxovHspE0 GpLO7ALw5NXokTjpbVZ2d7ec2SEBFugI3CFYl0Y2s74zYLQF9ADNWRpPON0Ce0OG46W+PxEdkEzG OCoS2Co+Tu2JfE6b3vQbzT4yBzx+sswsqmplyn59CEHV/cypNmfGPMhipDCd7GC0qTzT4ktZsfBw 8rh7Em+D6CNDLnhMOhxp8asDt+bC5pFPkV0wOkSebkkXJnLzM9eCrlbYpAnKDVqGuV5viWWrkHbS 6GorlmhkgK9fsptnXtWCRfLrtQHzJM90qsjLb7HOMAuKddEw3JZqcj1ZtpFJQYLv7/jJ4OY1L2xE lbE5LhRRLOZuC2fm8FJ2r+iXgFpObmQwMxTnD2OmPqVQZoHhqgKZDBSFyf6/iMABRbEurJ9QrHG3 OA8= =ndzU -----END PGP SIGNATURE----- --vSbnaEdrY7foQtyKTaEHcl170ErFTEmac-- From nobody Thu Jan 14 06:36:04 2021 Return-Path: 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 0C1B33A1304 for ; Thu, 14 Jan 2021 06:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 vA39JU7A6qoI for ; Thu, 14 Jan 2021 06:36:00 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 0FFB33A1009 for ; Thu, 14 Jan 2021 06:35:59 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10EEZvlN013644; Thu, 14 Jan 2021 09:35:57 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 10EEZvlN013644 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1610634957; bh=xfsxXe/sxQuSNesecYOyfVOW/dSZaeHYXGGTPMxQyc0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=q2AfIvGF4FeY2SiwyINDBrEBDRAt2o1X4dd1ov0J+NminMv1yl7/bN+P+GwCJc95j AwbuAwb/82c1Yu8uKZBIgrGJoborA1OeEtJEDtwmt+G24kofyICecEvHbbJpsOoEB8 EqhPyWicRkoLokaPuOuNyOTD5jG9CSawfo1I+Ofk= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10EEZqLY042329; Thu, 14 Jan 2021 09:35:52 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 14 Jan 2021 09:35:52 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 14 Jan 2021 09:35:52 -0500 From: Roman Danyliw To: Vittorio Bertocci , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10 Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyECus6VlA= Date: Thu, 14 Jan 2021 14:35:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 14:36:03 -0000 SGkgVml0dG9yaW8hDQoNClNvIHNvcnJ5IGZvciB0aGUgZGVsYXksIEkgZGlkbid0IGFwcHJlY2lh dGUgdGhpcyB3YXMgYXdhaXRpbmcgb24gYSByZXNwb25zZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lA YXV0aDAuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTksIDIwMjAgMzo0NSBBTQ0K PiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgb2F1dGhAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNz LXRva2VuLWp3dC0xMA0KPiANCj4gVGhhbmsgeW91IFJvbWFuIGZvciB0aGUgdGhvcm91Z2ggcmV2 aWV3IQ0KPiBJIGFwcGxpZWQgYWxsIHRoZSBlZGl0b3JpYWwgYW5kIHR5cG8gZml4ZXMuIEkgaGF2 ZSBhIGZldyBxdWVzdGlvbnMgb24gc29tZQ0KPiBjb21tZW50cywgb25jZSBzb2x2ZWQgSSdsbCB1 cGRhdGUgYWNjb3JkaW5nbHkgYW5kIHB1c2ggYSBuZXcgdmVyc2lvbi4NCj4gVGhhbmtzIQ0KPiBJ bmxpbmUNCj4gDQo+IA0KPiDvu78+T24gMTEvMTUvMjAsIDA4OjM5LCAiT0F1dGggb24gYmVoYWxm IG9mIFJvbWFuIERhbnlsaXciIDxvYXV0aC0NCj4gYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgcmRkQGNlcnQub3JnPiB3cm90ZToNCj4gPlsuLl0NCj4gPiAgICAqKiBTZWN0aW9uIDIuMi4y LiAgUGVyICJBbnkgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHdob3NlIHNlbWFudGljcyAgIEFueQ0K PiBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgd2hvc2Ugc2VtYW50aWNzIGFyZSB3ZWxsIGRlc2NyaWJl ZCBieSB0aGUgYXR0cmlidXRlJ3MNCj4gZGVzY3JpcHRpb24gZm91bmQgaW4gU2VjdGlvbiA1LjEg b2YgWy4uXQ0KPiA+ICAgTWF5YmUgbXkgcmVhZCBpdCB3cm9uZywgYnV0IGl0IHNlZW1zIGxpa2Ug dGhpcyB0ZXh0IHNheWluZyB0aGF0IGJleW9uZCB0aGUNCj4gcmVxdWlyZWQgY2xhaW1zIGxpc3Rl ZCBpbiBzZWN0aW9uIDIuMiwgeW91IGNhbiB1c2UgYW55IG9mIHRoZSBvdGhlciBjbGFpbXMgYXMg bG9uZw0KPiBhcyB0aGV5IGFyZSBpbiB0aGUgSUFOQSBKV1QgcmVnaXN0cnkuICBJc24ndCB0aGF0 IHNpbXBsZXIsIHNpbmNlIHRoZSBTZWN0aW9uIDUuMS4NCj4gT3BlbklELkNvcmUgYXR0cmlidXRl cyBhcmUgcmVnaXN0ZXJlZD8NCj4gIFlvdSBhcmUgcmlnaHQsIHRoYXQncyBub3QgdmVyeSBjbGVh ci4NCj4gSW4gYSBudXRzaGVsbCwgd2hhdCBJIGFtIHRyeWluZyB0byBzYXkgaXMgImlmIHlvdSB3 YW50IHRvIGV4cHJlc3MgYW4gYXR0cmlidXRlIGZvcg0KPiB3aGljaCB0aGVyZSdzIGFscmVhZHkg YSB3ZWxsLWVzdGFibGlzaGVkIGNsYWltIGF2YWlsYWJsZSwgdXNlIHRoYXQgcmF0aGVyIHRoYW4N Cj4gaW52ZW50aW5nICBuZXcgb25lLiIuDQo+IFRoYXQgc3RpbGwgYWxsb3dzIGZvciBub24tSUFO QSBjbGFpbXMgdG8gYmUgaW50cm9kdWNlZCwgYXMgbG9uZyBhcyB0aGUNCj4gaW1wbGVtZW50ZXIg aGFzIGRvbmUgdGhlIGR1ZSBkaWxpZ2VuY2UgYW5kIHZlcmlmaWVkIHRoYXQgdGhlIGF0dHJpYnV0 ZSB0aGV5DQo+IGNvbnZleSBpc24ndCBjb3ZlcmVkIGluIHRoZSBJQU5BIEpXVCByZWdpc3RyeS4N Cj4gSSBleHBsaWNpdGx5IG1lbnRpb24gT3BlbklEIENvbm5lY3QgYXMgc291cmNlIG9mIGNsYWlt cyBtb3N0bHkgdG8gZW5zdXJlIHRoYXQNCj4gdGhlIHJlYWRlciB3aWxsIHVuZGVyc3RhbmQgYXQg Zmlyc3QgZ2xhbmNlIHRoYXQgd2hlbiBpdCBjb21lcyB0byB1c2VyDQo+IGluZm9ybWF0aW9uIGEg SldUIEFUIGNhbiBjb252ZXkgdGhlIHNhbWUgaW5mb3JtYXRpb24gb2J0YWluZWQgdmlhIE9wZW5J RA0KPiBDb25uZWN0LCB3aXRob3V0IHRoZSBuZWVkIHRvIGZvbGxvdyB0aGUgbGluayBhbmQgY29u c3VsdCB0aGUgY2hhbmdlDQo+IGNvbnRyb2xsZXIvcmVmZXJlbmNlIGNvbHVtbiBvZiB0aGUgY2xh aW1zIHRvIHJlYWxpemUgdGhhdC4gT25lIG9mIHRoZSBnb2FscyBJIGFtDQo+IGhvcGluZyB0aGlz IHNwZWMgd2lsbCBhY2hpZXZlIGlzIHRvIHN0b3AgcGVvcGxlIGZyb20gYWJ1c2luZyBJRCB0b2tl bnMgYW5kIHVzaW5nDQo+IHRoZW0gaW4gbGlldSBvZiBhY2Nlc3MgdG9rZW5zIChhcyBLdWJlcm5l dGVzIHJvdXRpbmVseSBkb2VzLCBmb3IgZXhhbXBsZSksDQo+IGhlbmNlIHRoZSAiZGVub3JtYWxp emVkIiBsYW5ndWFnZSBvZiB0aGF0IHNlY3Rpb24uDQo+IEhlcmUncyBhbiBhbHRlcm5hdGl2ZSBm b3JtdWxhdGlvbiB0aGF0IHRyaWVzIHRvIHByZXNlcnZlIHRoYXQgY2xhcml0eSB3aGlsZQ0KPiBy ZWZlcnJpbmcgdG8gdGhlIHJlZ2lzdHJ5Og0KPiANCj4gIkFueSBhZGRpdGlvbmFsIGlkZW50aXR5 IGF0dHJpYnV0ZSB3aG9zZSBzZW1hbnRpYyBpcyB3ZWxsIGRlc2NyaWJlZCBieSBhbiBlbnRyeQ0K PiBpbiB0aGUgSlNPTiBXZWIgVG9rZW4gKEpXVCkgSUFOQSByZWdpc3RyeSBpbnRyb2R1Y2VkIGlu IFtSRkM3NTE5XSBTSE9VTEQNCj4gYmUgZW5jb2RlZCB1c2luZyB0aGUgY29ycmVzcG9uZGluZyBj bGFpbSBuYW1lLg0KPiBOb3RlIHRoYXQgdGhlIEpXVCBJQU5BIHJlZ2lzdHJ5IGluY2x1ZGVzIHRo ZSBjbGFpbXMgZm91bmQgaW4gU2VjdGlvbiA1LjEgb2YNCj4gW09wZW5JRC5Db3JlXS4iDQo+IA0K PiBXaGF0IGRvIHlvdSB0aGluaz8gV2FpdGluZyBmb3IgeW91ciBmZWVkYmFjayBiZWZvcmUgY2hh bmdpbmcgdGhlIGxhbmd1YWdlIGluDQo+IHRoZSBkcmFmdA0KDQpUaGlzIGxvb2tzIGZpbmUgdG8g bWUuDQoNCj4gPiAgICAqKiBTZWN0aW9uIDMuICBXaGF0IHdvdWxkIGJlIHRoZSBjYXNlIHdoZXJl IGl0IHdvdWxkIG5vdCBiZSBhcHByb3ByaWF0ZQ0KPiBmb3IgdGhlIHJlc291cmNlIHBhcmFtZXRl ciB2YWx1ZSB0byBiZSB0aGUgc2FtZSBhcyB0aGUgYXVkIGNsYWltIGluIHRoZSBhY2Nlc3MNCj4g dG9rZW4gKHRoZSB0ZXh0IGN1cnJlbnRseSBzYXlzIFNIT1VMRCwgd2h5IG5vdCBNVVNUPyk/DQo+ IFRoaXMgd2FzIGFjdHVhbGx5IGEgTVVTVCB1bnRpbCBkcmFmdCAzLCB0aGVuIEJyaWFuIHBvaW50 ZWQgb3V0IHRoYXQgdGhpcyB3b3VsZA0KPiBoYXZlIG1hZGUgdGhpcyBwcm9maWxlIG1vcmUgcmVz dHJpY3RpdmUgdGhhbiByZXNvdXJjZSBpbmRpY2F0b3JzIGl0c2VsZi0gd2hpY2gNCj4gbGVkIG1l IHRvIHNvZnRlbiB0aGUgcmVxdWlyZW1lbnQgYWNjb3JkaW5nbHkuIEJyaWFuJ3MgY29tbWVudCBp biBpdHMgZW50aXJldHk6DQo+IHxSZXNvdXJjZSBJbmRpY2F0b3JzIGlzIGFib3V0IGhvdyB0aGUg Y2xpZW50IGNvbnZleXMgdGhlIHRhcmdldCB0byB0aGUgQVMgYW5kDQo+IHNheXMgIiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgbWF5IHVzZSB0aGUgZXhhY3QgJ3Jlc291cmNlJyB2YWx1ZSBhcyB0 aGUNCj4gYXVkaWVuY2Ugb3IgaXQgbWF5IG1hcCBmcm9tIHRoYXQgdmFsdWUgdG8gYSBtb3JlIGdl bmVyYWwgVVJJIG9yIGFic3RyYWN0DQo+IGlkZW50aWZpZXIgZm9yIHRoZSBnaXZlbiByZXNvdXJj ZSIuIFRoZSBmb2xsb3dpbmcgZnJvbSB8c2VjIDMgaXMgbW9yZSByZXN0cmljdGl2ZSAvDQo+IHBy ZXNjcmlwdGl2ZSwgd2hpY2ggc2VlbXMgdG8gcmVhY2ggYmV5b25kIHRoZSBzY29wZSBvZiB0aGUg SldUIGFjY2VzcyB0b2tlbg0KPiBwcm9maWxlLg0KPiB8fCAgIklmIHRoZSByZXF1ZXN0IGluY2x1 ZGVzIGEgcmVzb3VyY2UgcGFyYW1ldGVyIChhcyBkZWZpbmVkIGluDQo+IHx8IFtSZXNvdXJjZUlu ZGljYXRvcnNdKSwgdGhlIHJlc3VsdGluZyBKV1QgYWNjZXNzIHRva2VuIGF1ZCBjbGFpbSBNVVNU DQo+IHx8ICAgaGF2ZSB0aGUgc2FtZSB2YWx1ZSBhcyB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGlu IHRoZSByZXF1ZXN0LiINCg0KT2gsIGdvdCBpdC4gIFRoYW5rcyBmb3IgZXhwbGFpbmluZy4NCg0K PiA+ICAgICoqIFNlY3Rpb24gNC4gUGVyIHRoZSB2YWxpZGF0aW9uIGd1aWRlbGluZXMgb24gYWNj ZXNzIHRva2VuIHZhbGlkYXRpb24sIGlzDQo+IHRoZXJlIHBhcmFsbGVsIHRleHQgbmVlZGVkIHRv IGRpc2N1c3MgdGhlIFJTIHVzZSBvZiB0aGUgdG9rZW4gc2F5OiBjaGVja2luZyB0aGF0DQo+IHRo ZSBhY3IgaGFzIGEgdmFsdWUgdGhhdCBpcyBhcHByb3ByaWF0ZSAoc28gaXQgY2FuIGhhdmUgY29u ZmlkZW5jZSBpbiB0aGUgc2VjdXJpdHkNCj4gb2YgPiB0aGUgYXV0aGVudGljYXRpb24gdXNlZCBi ZXR3ZWVuIGNsaWVudC9BUyk/IE9yIHRoYXQgdGhlIHJpZ2h0DQo+IGVudGl0bGVtZW50cy9ncm91 cHMvZXRjIHdlcmUgcHJlc2VudCBmb3IgdGhlIHJlcXVlc3RlZCBvcGVyYXRpb24/DQo+IFRoYXQn cyBhIGdvb2QgcG9pbnQuIFRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQgd2FzIG1lYW50 IHRvIGJlIGEgY2F0Y2gtYWxsDQo+IGZvciB0aG9zZSBjYXNlcywgbWVudGlvbmluZyBlbnRpdGxl bWVudHMgdW5kZXIgdGhlICJhdXRob3JpemF0aW9uIGNsYWltcyINCj4gdW1icmVsbGEgYW5kIGV2 ZXJ5dGhpbmcgZWxzZSBhcyAiYW55IG90aGVyIGNvbnRleHR1YWwgaW5mb3JtYXRpb24iLiBUaGUg dGhpbmcNCj4gdGhhdCBtYWtlcyBtZSBoZXNpdGF0ZSBiZWZvcmUgZ2V0dGluZyBtb3JlIHNwZWNp ZmljIHRoYW4gdGhhdCBpcyB0aGF0IGl0IGNhbiBiZQ0KPiBhIHNsaXBwZXJ5IHNsb3BlIChhY3Is IGFtciwgZW50aXRsZW1lbnRzIGV0YyBhcmUgZ29vZCBjYW5kaWRhdGVzLCBidXQgdGhlIHNhbWUN Cj4gbWlnaHQgYmUgc2FpZCBhYm91dCBhdXRoX3RpbWUgZm9yIG1heF9hZ2UgbGlrZSBzY2VuYXJp b3MsIGZvciBleGFtcGxlLi4uIHdoZXJlDQo+IHRvIGRyYXcgdGhlIGxpbmU/KSBhbmQgYmVpbmcg dGhvc2Ugb3B0aW9uYWwsIG5vdCBldmVyeW9uZSBtaWdodCByZWFkaWx5DQo+IHVuZGVyc3RhbmQg d2l0aG91dCBhZGRpbmcgbW9yZSBjb2xvci9jb250ZXh0LiBDb21iaW5lZCB3aXRoIGhvdyBkaWZm aWN1bHQNCj4gcmVhY2hpbmcgY29uc2Vuc3VzIGZvciB0aGUgaW5jbHVzaW9uIG9mIHNlc3Npb24g cHJvcGVydGllcyBpbiBhY2Nlc3MgdG9rZW5zLCBwbHVzDQo+IHRoZSBmYWN0IHRoYXRSRkM2NzUw IGRvZXMgbm90IGdpdmUgUlMgc3BlY2lmaWMgZ3VpZGFuY2UgZm9yIGhvdyB0byBhY3Qgb24NCj4g YXV0aG9yaXphdGlvbiBpbmZvIChzY29wZXMpLCBJIG9wdGVkIGZvciBnZW5lcmljIGxhbmd1YWdl Lg0KPiBJZiB5b3UgZmVlbCBzdHJvbmdseSBhYm91dCBtb3JlIHNwZWNpZmljIGd1aWRhbmNlIGJl aW5nIHJlcXVpcmVkIGZvciB0aG9zZQ0KPiBjbGFpbXMsIEkgY2FuIHByb3Bvc2UgbW9yZSBzcGVj aWZpYyBsYW5ndWFnZS0gYnV0IGJlZm9yZSBkb2luZyBzbywgSSB3YW50ZWQgdG8NCj4gb2ZmZXIg dGhlIGNvbnRleHQgYWJvdmUgdG8gc2VlIGlmIGl0IGNoYW5nZXMgdGhpbmdzLg0KDQpIbW0uICBJ IHdpc2ggaXQgY291bGQgYmUgY2xlYXJlciBidXQgSSBub3cgdW5kZXJzdGFuZCB0aGUgdHJhZGUg b2ZmIHlvdSBtYWRlLiAgUGxlYXNlIGxlYXZlIHRoZSB0ZXh0IGFzIGlzLg0KDQo+ICA+ICAgKiog U2VjdGlvbiA1LiAgVGhpcyB0ZXh0IHNlZW1zIHRvIHJlc3RhdGUgbXVjaCBvZiB0aGUgdGV4dCBm cm9tDQo+IFtPQXV0aDIuU2VjdXJpdHkuQmVzdFByYWN0aWNlc10uICBEbyBvdGhlciBzZWN0aW9u IGFwcGx5IGhlcmU/ICBQZXJoYXBzIGFsc28NCj4gYWRkIHRoYXQgdGhlIFNlY0NvbnMgb2YgaW5k aXZpZHVhbCBjbGFpbXMgYXBwbHkgaGVyZSB0b28gaWYgdXNlZCBpbiB0aGUgcHJvZmlsZQ0KPiAo YXMgdGhpcyBwcm9maWxlIGFsbG93cyBwcmV0dHkgbXVjaCBhbnl0aGluZyBpbiB0aGUgSldUIHJl Z2lzdHJ5IHRvIGJlIHVzZWQpLg0KPiBJIGNvbWJlZCBkcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5 LXRvcGljcy0xNiBhbmQgYmVzaWRlcyB0aGUgcGFydHMgYWJvdXQgc3ViLA0KPiBjbGllbnRfaWQg YW5kIGF1ZCAoYWxyZWFkeSByZWZlcmVuY2VkIGJ5IHRoZSBjdXJyZW50IHNwZWMsIG9yIGZ1cnRo ZXIgcmVzdHJpY3RlZC0NCj4gYXMgaXQgdGhlIGNhc2UgZm9yIHRoZSBhdWRpZW5jZSBjb25zaWRl cmF0aW9ucyksIHRoZSBCQ1AgZG9lc27igJl0IGFwcGVhciB0byBvZmZlcg0KPiBmdXJ0aGVyIGd1 aWRhbmNlIHRoYXQgd291bGQgdmFyeSBkZXBlbmRpbmcgb24gdGhlIGNvbnRlbnQgb2YgdGhlIHRv a2VuLiBUaGUNCj4gZ3VpZGFuY2Ugc2VlbXMgbW9zdGx5IG9uIGhvdyB0aGUgdG9rZW4gaXMgb2J0 YWluZWQsIGFuZCB0aGUgbWVjaGFuaXNtcw0KPiBkZXNjcmliZWQgb3BlcmF0ZSBhdCB0aGUgbWVz c2FnZSBsZXZlbCBoZW5jZSBhcHBseSB0byBKV1QgYWNjZXNzIHRva2VucyBhbmQNCj4gb3BhcXVl IHRva2VucyBpbiB0aGUgc2FtZSB3YXkuIERpZCB5b3UgaGF2ZSBhbnkgc3BlY2lmaWMgc2VjdGlv biBvZiB0aGUgQkNQIGluDQo+IG1pbmQ/DQo+IEkgYWxzbyB0b29rIGEgbG9vayBhdCByZmM3NTE5 IFNlY0NvbiBhbmQgaXQgZG9lc27igJl0IGFwcGVhciB0byBvZmZlciBjbGFpbXMtDQo+IHNwZWNp ZmljIGNvbnNpZGVyYXRpb25zLiBGaW5hbGx5LCBJIGNvbWJlZCB0aHJ1IHJmYzg3MjUgYW5kIGl0 IHNlZW1zIHRoZSBjdXJyZW50DQo+IHNwZWMgY292ZXJzIGFsbCB0aGUgY29udGVudCBzcGVjaWZp YyByZWNvbW1lbmRhdGlvbnMgdGhhdCBhcHBseSB0byB0aGlzDQo+IHNjZW5hcmlvLCBuYW1lbHkg aW4gc2VjdGlvbiA0IGZvciB0aGUgYXVkaWVuY2UsIGlzc3VlIGFuZCBzdWJqZWN0IHZhbGlkYXRp b24sIGFuZA0KPiBzZWN0aW9uIDIuMSBhbmQgNCBmb3IgdGhlIHN0cm9uZyB0eXBpbmcuDQo+IEJv dHRvbSBsaW5lOiBJIGNvdWxkIGFkZCBhIGdlbmVyaWMgcmVjb21tZW5kYXRpb24gdG8gY29uc2lk ZXINCj4gT0F1dGgyLlNlY3VyaXR5LkJlc3RQcmFjdGljZXMsIHJmYzc1MTkgYW5kIHJmYzg3MjUg d2hlbiBjb25zaWRlcmluZyB0aGUNCj4gc2VjdXJpdHkgb2YgYSBKV1QgYWNjZXNzIHRva2VuLCBi dXQgdGhlIG9ubHkgc2VjdGlvbiB0aGF0IHNlZW0gZGlyZWN0bHkNCj4gYXBwbGljYWJsZSBzZWVt cyB0aGUgNC4xNCB3ZSBhbHJlYWR5IHJlZmVyZW5jZS4gV2hhdCBkbyB5b3UgdGhpbms/IERvIHdl DQo+IG5lZWQgdGhhdCBibGFua2V0IHJlZmVyZW5jZT8NCg0KSSByZS1yZWFkIFtPQXV0aDIuU2Vj dXJpdHkuQmVzdFByYWN0aWNlc10gYW5kIG15IHN1Z2dlc3Rpb247IGFuZCBhZ3JlZSB3aXRoIHlv dXIgYXNzZXNzbWVudC4gIEFsbW9zdCBub3RoaW5nIGluIHRoZSBCQ1AgaXMgYWJvdXQgc3BlY2lm aWMgdG8gdGhlIHRva2VuIGNvbnRlbnQgYW5kIGZvcm1hdCB3aGljaCB0aGlzIG5hcnJvdyBmb2N1 cyBvZiB0aGlzIGRyYWZ0Lg0KDQpBZ2Fpbiwgc29ycnkgZm9yIGRlbGF5Lg0KDQpSZWdhcmRzLA0K Um9tYW4NCg0KIA0KPiANCg== From nobody Thu Jan 14 12:20:34 2021 Return-Path: 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 9D20F3A162D for ; Thu, 14 Jan 2021 12:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 i6zG6hsS2f8i for ; Thu, 14 Jan 2021 12:20:29 -0800 (PST) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (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 4AC323A162C for ; Thu, 14 Jan 2021 12:20:29 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 096YlhKyMCcJR096Zlc8Iu; Thu, 14 Jan 2021 13:20:28 -0700 X-CMAE-Analysis: v=2.4 cv=Bv5Yfab5 c=1 sm=1 tr=0 ts=6000a78c a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=UqCG9HQmAAAA:8 a=OPE_keaqAAAA:8 a=__SxRlIrAAAA:8 a=IzNHE0-dzueNqnZ0qosA:9 a=QrD5s1Yyd6gXmrxS:21 a=czHfMAbg24kHEzhe:21 a=QEXdDO2ut3YA:10 a=y5F7X6vxnMXjTaPbyQcA:9 a=jJ4LBlMIXxj5INpu:21 a=k8IHbTIy_nNptCPv:21 a=y-bpsXK2LnFRJf2F:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L47nHB812nP-ulAiFgtB:22 a=H5r4HjhRfVyZ-DhAOYba:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <35A2B178-B99F-4EBB-A2A8-A386183682C5@mendix.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Thu, 14 Jan 2021 22:20:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <35A2B178-B99F-4EBB-A2A8-A386183682C5@mendix.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040208070303010003020102" X-CMAE-Envelope: MS4xfARSCP75CF2eGFMimUOsRO4DAOGsUU6Gt1brBk1E4un2Y+lNELeMBBWiRwmLIow7o+1xrU4X3nBB2q3hrjdfBzfLbUN9DrW2DT5nG8tc2sgLHMg0wZP4 eksP3PKdpVuoL/Th9QrBRpuXPkdazahwT8NSe0JX1+8QMDTmqLZReb0ki2Dh6RO9UrxqztAudeGNrA== Archived-At: Subject: Re: [OAUTH-WG] Tenancy in OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 20:20:33 -0000 This is a cryptographically signed message in MIME format. --------------ms040208070303010003020102 Content-Type: multipart/alternative; boundary="------------316A7380851EAB059DBBAAED" Content-Language: en-US This is a multi-part message in MIME format. --------------316A7380851EAB059DBBAAED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/01/2021 12:10, Jaap Francke wrote: > Thanks Justin and Vladimir for your guidance! > > The resource indicator approach seems to have the best fit for my use c= ase. > It addresses my coarse/mid-grained use case, without bringing the compl= exity of the fine-grained RAR approach. > Encoding the tenant into scope values remains an option as well. > Ensuring the token validation is implemented properly is indeed a point= of attention. > > Meanwhile I've been looking into OAuth/OIDC specs for client registrati= on.=20 > It may also be useful to extend the client's metadata with 'resource' t= o bind the specific client to a specific tenant(s). > Would that make sense to you as well? If that make sense in your scenario, then why not. We have the "scope" client metadata field, which was intended for that purpose, but relating to the scope authZ parameter. https://tools.ietf.org/html/rfc7591#section-2 > scope > String containing a space-separated list of scope values (as > described in Section 3.3 of OAuth 2.0 [RFC6749 ]) t= hat the client > can use when requesting access tokens. The semantics of values i= n > this list are service specific. If omitted, an authorization > server MAY register a client with a default set of scopes. Vladimir > > Great feedback, kind regards,=20 > Jaap > > > =EF=BB=BFOn 12/01/2021, 23:10, "OAuth on behalf of oauth-request@ietf.o= rg" wrote: > > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D04%7C01%7Cjaap.fra= ncke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc= 565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= sdata=3DzNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=3D0 > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific= > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Tenancy in OAuth (Justin Richer) > 2. Re: Tenancy in OAuth (Vladimir Dzhuvinov) > > > -------------------------------------------------------------------= --- > > Message: 1 > Date: Tue, 12 Jan 2021 16:13:26 -0500 > From: Justin Richer > To: Jaap Francke > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Tenancy in OAuth > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" > > Hi Jaap, > > There have been a number of efforts to address this kind of thing i= n the OAuth world. You can definitely use a special scope to encode this = value, which has the benefit of fitting into the implementation limitatio= ns of nearly all OAuth systems out there. The ?resource? parameter can al= so be used for the kind of thing, and it gives you a bucket that?s separa= te from ?scope? so that you can keep the latter available for describing = the API itself: > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Frfc8707&data=3D04%7C01%7Cjaap.francke%40mend= ix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23b= a4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D5cl= Kn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=3D0 > > There?s also the Rich Authorization Request (RAR) draft that this g= roup is currently working on, which provides a multi-dimensional way to d= escribe access. It?s more complex than scopes, but it boils down to havin= g JSON objects describe the elements needed. In this case you might put t= he API bits into the ?actions? and ?datatypes? fields, and put the tenant= information into the ?locations? field. I believe there are people using= it in exactly this way today: > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=3D04%7C01%7Cjaa= p.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b4= 6d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &sdata=3Dhxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserve= d=3D0 > > There are also some historical efforts to address this, including a= n ?audience? and a (completely separate) ?aud" parameter, but AFAIK neith= er of these have been raised to standard or even to common practice, and = so I wouldn?t recommend it. I currently have a project to migrate a syste= m that?s currently using one of these onto RAR. > > ? Justin > > > On Jan 12, 2021, at 11:20 AM, Jaap Francke wrote: > >=20 > > Hi, > > =20 > > I?m looking into the topic of tenancy. A multi-tenant service can= be considered as an OAuth Resource Server managing resources of differen= t tenants. > > An AS makes authorization decisions and communicates these using = scopes, so one way would be to ?encode? the tenant into the scope values.= > > Another line of thought is to somehow bind/restrict an acces-toke= n to a certain tenant, leaving the set of scopes being used more static. > > =20 > > My question is whether this has been a topic that has been addres= sed in the OAuth working group? Any common practice or draft? > > Thanks in advance for your replies. > > =20 > > Kind regards, > > =20 > > Jaap Francke > > Product Manager Identity > > +31(0)641495324 > > mendix.com > > > > =20 > > =20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D04%7C01%7Cjaap.fr= ancke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8b= c565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= ;sdata=3DzNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=3D0 = > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Wed, 13 Jan 2021 00:10:01 +0200 > From: Vladimir Dzhuvinov > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Tenancy in OAuth > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" > > Hello Jaap, > > Justin made a good overview of the available OAuth facilities when > dealing with multiple resource servers or resource server tenants. > > If you have control over the resource server, i.e. the token valida= tion > is going to happen in one place, then you have plenty of freedom to= find > out what will work best for you, semantically and in terms of avail= able > OAuth server. > > In cases when the resources are left to implement the token validat= ion > on their own my preferred approach is to encode the resource server= > identity (tenant) into the scope values. Access is defined in one p= lace > and I don't have to worry about the developer accidentally forgetti= ng > the "resource" or "aud(ience)" check. > > Vladimir > > > On 12/01/2021 23:13, Justin Richer wrote: > > Hi Jaap, > > > > There have been a number of efforts to address this kind of thing= in > > the OAuth world. You can definitely use a special scope to encode= this > > value, which has the benefit of fitting into the implementation > > limitations of nearly all OAuth systems out there. The ?resource?= > > parameter can also be used for the kind of thing, and it gives yo= u a > > bucket that?s separate from ?scope? so that you can keep the latt= er > > available for describing the API itself: > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc8707&data=3D04%7C01%7Cjaap.francke%40me= ndix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da2= 3ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D5= clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=3D0 > > > > There?s also the Rich Authorization Request (RAR) draft that this= > > group is currently working on, which provides a multi-dimensional= way > > to describe access. It?s more complex than scopes, but it boils d= own > > to having JSON objects describe the elements needed. In this case= you > > might put the API bits into the ?actions? and ?datatypes? fields,= and > > put the tenant information into the ?locations? field. I believe = there > > are people using it in exactly this way today: > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=3D04%7C01%7Cj= aap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3= b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10= 00&sdata=3Dhxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reser= ved=3D0 > > > > There are also some historical efforts to address this, including= an > > ?audience? and a (completely separate) ?aud" parameter, but AFAIK= > > neither of these have been raised to standard or even to common > > practice, and so I wouldn?t recommend it. I currently have a proj= ect > > to migrate a system that?s currently using one of these onto RAR.= > > > > ?? Justin > > > >> On Jan 12, 2021, at 11:20 AM, Jaap Francke > >> >> > wrote: > >> > >> Hi, > >> ? > >> I?m looking into the topic of tenancy. A multi-tenant service ca= n be > >> considered as an OAuth Resource Server managing resources of > >> different tenants. > >> An AS makes authorization decisions and communicates these using= > >> scopes, so one way would be to ?encode? the tenant into the scop= e values. > >> Another line of thought is to somehow bind/restrict an acces-tok= en to > >> a certain tenant, leaving the set of scopes being used more stat= ic. > >> ? > >> My question is whether this has been a topic that has been addre= ssed > >> in the OAuth working group? Any common practice or draft? > >> Thanks in advance for your replies. > >> ? > >> Kind regards, > >> *?* > >> *Jaap Francke* > >> Product Manager Identity > >> +31(0)641495324 > >> > >> mendix.com > >> > >> ** > >> *?* > >> ? > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D04%7C01%7Cjaap.f= rancke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8= bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am= p;sdata=3D8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&rese= rved=3D0 > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D04%7C01%7Cjaap.fr= ancke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8b= c565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= ;sdata=3D8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&reser= ved=3D0 > > --=20 > Vladimir Dzhuvinov > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4007 bytes > Desc: S/MIME Cryptographic Signature > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D04%7C01%7Cjaap.fran= cke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc5= 65540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s= data=3D8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&reserve= d=3D0 > > > ------------------------------ > > End of OAuth Digest, Vol 147, Issue 6 > ************************************* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------316A7380851EAB059DBBAAED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 13/01/2021 12:10, Jaap Francke wrote:
Thanks Justin and Vladimir f=
or your guidance!

The resource indicator approach seems to have the best fit for my use cas=
e.
It addresses my coarse/mid-grained use case, without bringing the complex=
ity of the fine-grained RAR approach.
Encoding the tenant into scope values remains an option as well.
Ensuring the token validation is implemented properly is indeed a point o=
f attention.

Meanwhile I've been looking into OAuth/OIDC specs for client registration=
=2E=20
It may also be useful to extend the client's metadata with 'resource' to =
bind the specific client to a specific tenant(s).
Would that make sense to you as well?

If that make sense in your scenario, then why not. We have the "scope" client metadata field, which was intended for that purpose, but relating to the scope authZ parameter.

https://tools.ietf.org/html/rfc7591#section-2= 

   scope
      String containing a space-separated list of scope values (as
      described in Section 3.3 of OAuth 2.0 [RF=
C6749]) that the client
      can use when requesting access tokens.  The semantics of values in
      this list are service specific.  If omitted, an authorization
      server MAY register a client with a default set of scopes.


Vladimir



Great feedback, kind regards,=20
Jaap


=EF=BB=BFOn 12/01/2021, 23:10, "OAuth on behalf of oauth-request@ietf=
=2Eorg" <oauth-bounces@ietf.org o=
n behalf of oauth-request@ietf.org> wrote:

    Send OAuth mailing list submissions to
    	oauth@ietf.org

    To subscribe or unsubscribe via the World Wide Web, visit
    	https://eur03.safeli=
nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2F=
listinfo%2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C937=
07202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%=
7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi=
V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DzNVyuy2avEE=
WtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&amp;reserved=3D0
    or, via email, send a message with subject or body 'help' to
    	oauth-request@ietf.org

    You can reach the person managing the list at
    	oauth-owner@ietf.org

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of OAuth digest..."


    Today's Topics:

       1. Re: Tenancy in OAuth (Justin Richer)
       2. Re: Tenancy in OAuth (Vladimir Dzhuvinov)


    ---------------------------------------------------------------------=
-

    Message: 1
    Date: Tue, 12 Jan 2021 16:13:26 -0500
    From: Justin Richer <jricher@mit.edu>
    To: Jaap Francke <Jaap.Francke=3D40mendix.com=
@dmarc.ietf.org>
    Cc: "oauth@ietf.org" <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] Tenancy in OAuth
    Message-ID: <E3DE5ED2-7506-4090-A32A-F3D4AE=
797DF5@mit.edu>
    Content-Type: text/plain; charset=3D"utf-8"

    Hi Jaap,

    There have been a number of efforts to address this kind of thing in =
the OAuth world. You can definitely use a special scope to encode this va=
lue, which has the benefit of fitting into the implementation limitations=
 of nearly all OAuth systems out there. The ?resource? parameter can also=
 be used for the kind of thing, and it gives you a bucket that?s separate=
 from ?scope? so that you can keep the latter available for describing th=
e API itself:

    https://eur03.safelinks.p=
rotection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc870=
7&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd48478953=
0008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C6374608623831=
68168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI=
6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D5clKn%2B8%2FCEiQindejfHncA=
670FWVoy%2BHDQ49JtOORjE%3D&amp;reserved=3D0 <https://eur03.safelinks.protection.outlook.com=
/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&amp;data=3D04%7=
C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3=
c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWF=
pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%=
3D%7C1000&amp;sdata=3D5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOOR=
jE%3D&amp;reserved=3D0>

    There?s also the Rich Authorization Request (RAR) draft that this gro=
up is currently working on, which provides a multi-dimensional way to des=
cribe access. It?s more complex than scopes, but it boils down to having =
JSON objects describe the elements needed. In this case you might put the=
 API bits into the ?actions? and ?datatypes? fields, and put the tenant i=
nformation into the ?locations? field. I believe there are people using i=
t in exactly this way today:

    https://eur03=
=2Esafelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2=
Fhtml%2Fdraft-ietf-oauth-rar-03&amp;data=3D04%7C01%7Cjaap.francke%40m=
endix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da=
23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL=
jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat=
a=3Dhxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&amp;reserved=3D0=
 <https://=
eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.or=
g%2Fhtml%2Fdraft-ietf-oauth-rar-03&amp;data=3D04%7C01%7Cjaap.francke%=
40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc56554=
0da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC=
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s=
data=3Dhxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&amp;reserved=3D=
0>

    There are also some historical efforts to address this, including an =
?audience? and a (completely separate) ?aud" parameter, but AFAIK neither=
 of these have been raised to standard or even to common practice, and so=
 I wouldn?t recommend it. I currently have a project to migrate a system =
that?s currently using one of these onto RAR.

     ? Justin

    > On Jan 12, 2021, at 11:20 AM, Jaap Francke =
<Jaap.Francke=3D40mendix.com@dmarc.ietf.org> wrote:
    >=20
    > Hi,
    > =20
    > I?m looking into the topic of tenancy. A multi-tenant service ca=
n be considered as an OAuth Resource Server managing resources of differe=
nt tenants.
    > An AS makes authorization decisions and communicates these using=
 scopes, so one way would be to ?encode? the tenant into the scope values=
=2E
    > Another line of thought is to somehow bind/restrict an acces-tok=
en to a certain tenant, leaving the set of scopes being used more static.=

    > =20
    > My question is whether this has been a topic that has been addre=
ssed in the OAuth working group? Any common practice or draft?
    > Thanks in advance for your replies.
    > =20
    > Kind regards,
    > =20
    > Jaap Francke
    > Product Manager Identity
    > +31(0)641495324
    > mendix.com <https://eur03.safelinks.=
protection.outlook.com/?url=3Dhttp%3A%2F%2Fmendix.com%2F&amp;data=3D0=
4%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb=
4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7C=
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M=
n0%3D%7C1000&amp;sdata=3DnPKjePc%2B%2B8TuM4zuCG6ZU2XNsPmJxu5WidmCHz9E=
%2BSU%3D&amp;reserved=3D0>
    > <image001.png> <https://eur03.sa=
felinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.mendix.com%2F&=
amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8=
b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%=
7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha=
WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D7HQ1qe32Hc9QcYNVY8667ufxmLz7DDWC=
YA8mhsKSHVo%3D&amp;reserved=3D0>
    > =20
    > =20
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org <mailto:OAuth@ietf.org>
    > https://eur03.sa=
felinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailma=
n%2Flistinfo%2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7=
C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%=
7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ=
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DzNVyuy2=
avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&amp;reserved=3D0 <https://eur03.safelinks.prote=
ction.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%=
2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd48=
4789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C6374608=
62383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL=
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DzNVyuy2avEEWtIJ3eXZG=
EV9S0KLyYj27KiG2yOPtW9Q%3D&amp;reserved=3D0>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <https://eur03.safelinks.prote=
ction.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrow=
se%2Foauth%2Fattachments%2F20210112%2F19aa55e2%2Fattachment.htm&amp;d=
ata=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e=
1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnk=
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC=
JXVCI6Mn0%3D%7C1000&amp;sdata=3D1QzWSxQ4esCxjTI6f5mb7CPFxiYs9aCdVcHIy=
EnuwMk%3D&amp;reserved=3D0>

    ------------------------------

    Message: 2
    Date: Wed, 13 Jan 2021 00:10:01 +0200
    From: Vladimir Dzhuvinov <vladimir@connect2id.com>
    To: oauth@ietf.org
    Subject: Re: [OAUTH-WG] Tenancy in OAuth
    Message-ID: <cc41517f-f732-0d6f-95f3=
-64bb7fcdf24e@connect2id.com>
    Content-Type: text/plain; charset=3D"utf-8"

    Hello Jaap,

    Justin made a good overview of the available OAuth facilities when
    dealing with multiple resource servers or resource server tenants.

    If you have control over the resource server, i.e. the token validati=
on
    is going to happen in one place, then you have plenty of freedom to f=
ind
    out what will work best for you, semantically and in terms of availab=
le
    OAuth server.

    In cases when the resources are left to implement the token validatio=
n
    on their own my preferred approach is to encode the resource server
    identity (tenant) into the scope values. Access is defined in one pla=
ce
    and I don't have to worry about the developer accidentally forgetting=

    the "resource" or "aud(ience)" check.

    Vladimir


    On 12/01/2021 23:13, Justin Richer wrote:
    > Hi Jaap,
    >
    > There have been a number of efforts to address this kind of thin=
g in
    > the OAuth world. You can definitely use a special scope to encod=
e this
    > value, which has the benefit of fitting into the implementation
    > limitations of nearly all OAuth systems out there. The ?resource=
?
    > parameter can also be used for the kind of thing, and it gives y=
ou a
    > bucket that?s separate from ?scope? so that you can keep the lat=
ter
    > available for describing the API itself:
    >
    > https://eur03.safeli=
nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fr=
fc8707&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484=
789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C63746086=
2383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC=
JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D5clKn%2B8%2FCEiQindej=
fHncA670FWVoy%2BHDQ49JtOORjE%3D&amp;reserved=3D0
    >
    > There?s also the Rich Authorization Request (RAR) draft that thi=
s
    > group is currently working on, which provides a multi-dimensiona=
l way
    > to describe access. It?s more complex than scopes, but it boils =
down
    > to having JSON objects describe the elements needed. In this cas=
e you
    > might put the API bits into the ?actions? and ?datatypes? fields=
, and
    > put the tenant information into the ?locations? field. I believe=
 there
    > are people using it in exactly this way today:
    >
    > https://=
eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.or=
g%2Fhtml%2Fdraft-ietf-oauth-rar-03&amp;data=3D04%7C01%7Cjaap.francke%=
40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc56554=
0da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC=
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s=
data=3Dhxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&amp;reserved=3D=
0
    >
    > There are also some historical efforts to address this, includin=
g an
    > ?audience? and a (completely separate) ?aud" parameter, but AFAI=
K
    > neither of these have been raised to standard or even to common
    > practice, and so I wouldn?t recommend it. I currently have a pro=
ject
    > to migrate a system that?s currently using one of these onto RAR=
=2E
    >
    > ?? Justin
    >
    >> On Jan 12, 2021, at 11:20 AM, Jaap Francke
    >> <Jaap.Francke=3D40mendix.com@dmarc.i=
etf.org
    >> <mailto:Jaap.Francke=3D40mendix.=
com@dmarc.ietf.org>> wrote:
    >>
    >> Hi,
    >> ?
    >> I?m looking into the topic of tenancy. A multi-tenant servic=
e can be
    >> considered as an OAuth Resource Server managing resources of=

    >> different tenants.
    >> An AS makes authorization decisions and communicates these u=
sing
    >> scopes, so one way would be to ?encode? the tenant into the =
scope values.
    >> Another line of thought is to somehow bind/restrict an acces=
-token to
    >> a certain tenant, leaving the set of scopes being used more =
static.
    >> ?
    >> My question is whether this has been a topic that has been a=
ddressed
    >> in the OAuth working group? Any common practice or draft?
    >> Thanks in advance for your replies.
    >> ?
    >> Kind regards,
    >> *?*
    >> *Jaap Francke*
    >> Product Manager Identity
    >> +31(0)641495324
    >>
    >> mendix.com <https://eur03.safeli=
nks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fmendix.com%2F&amp;data=
=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4=
%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnknow=
n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV=
CI6Mn0%3D%7C1000&amp;sdata=3D%2FAM7a7iH5y8E6ETAg%2BAmrNh3WnAuBiOZ%2FE=
BhikqOFxI%3D&amp;reserved=3D0>
    >>
    >> *<image001.png>* <https://eu=
r03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.mendix.com%2=
F&amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd48478953=
0008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C6374608623831=
78166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI=
6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DMaqH3Kv4ob56Lp28m9g2idLEXi=
Llpkkwt4QctYTAiqg%3D&amp;reserved=3D0>
    >> *?*
    >> ?
    >> _______________________________________________
    >> OAuth mailing list
    >> OAuth@ietf.org <mailto:OAuth@ietf.org>
    >> http=
s://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.=
org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40=
mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540d=
a23ba4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w=
LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda=
ta=3D8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&amp;reser=
ved=3D0
    >
    >
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://=
eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%=
2Fmailman%2Flistinfo%2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40mend=
ix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23b=
a4d%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw=
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D=
8%2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&amp;reserved=3D=
0

    --=20
    Vladimir Dzhuvinov

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <https://eur03.safelinks.prote=
ction.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrow=
se%2Foauth%2Fattachments%2F20210113%2F136b5985%2Fattachment.htm&amp;d=
ata=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e=
1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383178166%7CUnk=
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC=
JXVCI6Mn0%3D%7C1000&amp;sdata=3D0dJ3kYyigdBtbUDNhwRipAzwj5urzkKKLCzqu=
GTy7vY%3D&amp;reserved=3D0>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4007 bytes
    Desc: S/MIME Cryptographic Signature
    URL: <https://eur03.safelinks=
=2Eprotection.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farc=
h%2Fbrowse%2Foauth%2Fattachments%2F20210113%2F136b5985%2Fattachment.p7s&a=
mp;amp;data=3D04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd48478953000=
8d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C6374608623831781=
66%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik=
1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D%2BqMHy4Z%2FkjRCeyE8UHgUuqtm8=
D%2FLwPd2HffEmhiVfcs%3D&amp;reserved=3D0>

    ------------------------------

    Subject: Digest Footer

    _______________________________________________
    OAuth mailing list
    =
OAuth@ietf.org
    https://eur03=
=2Esafelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fm=
ailman%2Flistinfo%2Foauth&amp;data=3D04%7C01%7Cjaap.francke%40mendix.=
com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d=
%7C0%7C0%7C637460862383178166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA=
iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D8%=
2Fk%2BVZS9e%2B%2FCwEwSVo7nqivuwjdg3Jy48x6awkBTxV0%3D&amp;reserved=3D0=



    ------------------------------

    End of OAuth Digest, Vol 147, Issue 6
    *************************************

_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
--------------316A7380851EAB059DBBAAED-- --------------ms040208070303010003020102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAxMTQyMDIwMjZaMC8G CSqGSIb3DQEJBDEiBCAOcMXIMAVL3V+Mn7B99XH9qZpwyVLpvu9MfaRjACLFDzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAIbIQiLzo6UGphFgTwdVmn+GaC/lN14lz8hbkm9YnY1oCUJc Oo5Ngcnl6ZiYjMxwSKJbrmvHmjdLuNQJiMRaBtw2l12yVWlTz34l2Qjb2+68Jv76mPritxCg ur5VTT8KDnw8xIyt9r3E8H2yaFYltXBBat74XtnXRGvVLeGRXQylMXoPNdhUTN344T76R/+F 1ToCk1wJ6idg0279+p8aOfKM+XgppbFCQBTlk3IUrR61Z0gaIy6VlsrEd3NRzsIJxBu6m2IU dE4Bo4GSbk8BBU6qp0huq2NpNAz68SlptLQsoDKol3AtcfjjgsqcQy8383e+dBTK/UHQ8Vjz 5rrDGvQAAAAAAAA= --------------ms040208070303010003020102-- From nobody Tue Jan 19 06:10:49 2021 Return-Path: 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 312AE3A151C for ; Tue, 19 Jan 2021 06:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 HBcoeToRNtGh for ; Tue, 19 Jan 2021 06:10:45 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 5106E3A151B for ; Tue, 19 Jan 2021 06:10:45 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10JEAhoV008742 for ; Tue, 19 Jan 2021 09:10:44 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 10JEAhoV008742 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1611065444; bh=jJhrEVRm/VXJizEtPoXO4Jl6j9B9UhnEh5vNyX6yTkk=; h=From:To:Subject:Date:From; b=sW7JQocGQG8Ce9s45Yqd3PcmuFPlLKHoOnLf38LNsvHbT0whJPzCjfgPjNujMyFfw jA+rNrqBCMPT9THUy9TQ4ekerYKA0TwuVxeDXzHOS3IP41TPW+A1YO6aRkMlmxtQOl qJ0Cb8zwajmDZp6d7GKPCctLjPzqE172lFv6SkwY= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10JEAdnL035581 for ; Tue, 19 Jan 2021 09:10:39 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 19 Jan 2021 09:10:39 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 19 Jan 2021 09:10:39 -0500 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: Status summary of document in AD Evaluation status Thread-Index: AdbubEWrYMo70AXPSgiZWGEVZkUzVA== Date: Tue, 19 Jan 2021 14:10:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Status summary of document in AD Evaluation status X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 14:10:48 -0000 Hi! Below is a summary explanation of where all of the documents that are with = me (as AD) stand. I hope this better explains the status in the datatracke= r. =20 =3D=3D[ draft-ietf-oauth-access-token-jwt Status: AD Evaluation::Revised I-D Needed (aka, after WG LC but before IETF LC pending edits the AD has requested) Pending edits from AD review confirmed at https://mailarchive.ietf.org/arch= /msg/oauth/t57XP7RICTpoI3FbOyrY0gpsNnE/. After these are merged, this docu= ment can proceed to IESG Review. =3D=3D[ draft-ietf-oauth-jwsreq Status: Status: Waiting for AD Go-Ahead:Revised I-D Needed (aka, after the second WG and IETF LC, but IETF LC Directorate reviews requ= ire action) All AD review and individual IETF LC feedback was addressed. A few outstanding updates remain from the IETF LC SECDIR review -- https://= mailarchive.ietf.org/arch/msg/secdir/5CrZTLR8v6cm8wZVkfY_Yywckcw/. After these changes are made, this document can return for IESG Review. =3D=3D[ draft-ietf-oauth-jwt-introspection-response Status: Waiting for AD Go-Ahead:Revised I-D Needed (aka, after the second WG and IETF LC, but IESG DISCUSS position from first= IESG requires actions) -10 addressed: * the 2nd AD review -- https://mailarchive.ietf.org/arch/msg/oauth/6VPGZxX= t12WRgXe4IXsWN7UA054/ * and the negotiated text from the thread in the 2nd IETF LC -- https://mai= larchive.ietf.org/arch/msg/last-call/ZdceEhKUiBSmrBfKm2Nqa2jYs4Q/ Outstanding are closure on two DISCUSS points from the -08 IESG ballot (htt= ps://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/b= allot/)=20 * Ben Kaduk said: It looks like we need to register 'active' as a JWT claim= ? 'active' appears to be registered in https://www.iana.org/assignments/oauth= -parameters/oauth-parameters.xhtml#token-introspection-response, but I beli= eve Ben's point is that it is NOT registered in https://www.iana.org/assign= ments/jwt/jwt.xhtml#claims * Ben Kaduk also said:=20 I don't think the new semantics for "jti" in the introspection response are= compatible with the RFC 7519 definition. Specifically, we say that "jti" = will be tied to the input access token, but 7519 says that "jti" has to change when the contents of the JWT change ("MUST be assigned in a m= anner that ensures that there is a negligible probability that the same val= ue will be accidentally assigned to a different data object"), and we admit= at least the possibility of "active" and "iat" changing. Checking Section 5 of the -10, it contains: If the access token is invalid, expired, revoked, or is not intended for the calling resource server (audience), the authorization server MUST set the value of the "active" member in the "token_introspection" claim to "false" and other members MUST NOT be included. Otherwise, the "active" member is set to "true". I believe this is the source of Ben's concern. Other necessary actions: * Updated Shepherd write-up to capture the 2nd IETF LC feedback Regards, Roman From nobody Fri Jan 22 11:30:14 2021 Return-Path: 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 05CB53A146E for ; Fri, 22 Jan 2021 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 MzH0kS5LtbLV for ; Fri, 22 Jan 2021 11:30:10 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 450C53A1474 for ; Fri, 22 Jan 2021 11:30:10 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id i63so4481687pfg.7 for ; Fri, 22 Jan 2021 11:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:mime-version; bh=0igwdTzrkOPafbRghdRXeGx8JVagE/7J1dpXj6B36BA=; b=GiXr/B/mEfAng2W8H3mjqBEn0VNM3C92ZGor+7Un4udcx31NyLNRnQn4it4+4cRY5C u8FcNdsasDWv+8zmlfScUZHCpacLB0Q8zp8PQYNV7wJG+dZWfF7y3HxDWCQ4OvnwRuYY yeBMHR37VhD+unBe3AfqFyiTiNVs7JHrqtY1I+s/5s56ZDMK4rfDp81gRmpnthKM6HU7 uhzereyO8ZgkymDumBzCcq1UTyOvGuqXtb05YGSAANIckEgnAJV2MdTGqUlMSo7iS64S d3US7sk1DyTcGx2MCORTARuC6NpBHhOa5cvYowMu1PrPV1l+nAVm0P22cN59T3vBrau8 8ntg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:mime-version; bh=0igwdTzrkOPafbRghdRXeGx8JVagE/7J1dpXj6B36BA=; b=uRFOwnSq0vOksHeI7VWme7LC2+mD4YKpNQtiUtp+aCOR79rWzNRzHMa8QSB++NgL0X vdjizc6wsxGvm+oWVIjF4v2QF1eUolOTFyBMBdNMMHporse+Gi8eK2S/1JwnGbzCqKx5 kxcP0l3/DthG7AwbePW0AlfkSCNeU6x4a1ozQCgC9V3X90/VjFnYRC0NV1qJIUFDnFrf mMdQadaoXhRqmItuqW6MVnFWl1O3lWhzT949LRDHjyEw/WCoaALn5LRNJ8YB1+CgJsKt xVf6fOjL5GNr4fG5vJaSdNI1dALgOVxJIqhqfQWq+hrRxt59ucpDBzDs22yIBg8JCWer gWeA== X-Gm-Message-State: AOAM530ZWpziGimU2MU6sKvGjvxjScPmIZ3d5nU+jI4+ZYC+GjrVfk8I BOk1z3zDk0Y5Njtnq285yMdlSD+0eb3NfmWcWAKRTZfb/V5i1fnTUVO2YR37sWBGmN98UhsL693 jX4dE2Krj9KynwmpxuMcU23pJYpMpWSyvuhwRBRQB8ciwC/I5DGGF4IovK/0bfXEFwZJ0 X-Google-Smtp-Source: ABdhPJxVsk4fZ7gMTCxtSizhRA0WBbj/OLrmNUAvQPvPfArM5wSbsVu1P+eTAuyBiE8x44K03Og7cg== X-Received: by 2002:a63:d04a:: with SMTP id s10mr1393384pgi.32.1611343808948; Fri, 22 Jan 2021 11:30:08 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id z3sm9244591pfb.157.2021.01.22.11.30.07 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 11:30:07 -0800 (PST) From: Vittorio Bertocci To: "oauth@ietf.org" Thread-Topic: November Interim meeting on WebID/IsLoggedIn followup Thread-Index: AQHW8PT97IEIO3/gCU6wmDE9jW6LAA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 22 Jan 2021 19:30:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB40521AEB923752B77E749A6EAEA09CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] November Interim meeting on WebID/IsLoggedIn followup X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 19:30:12 -0000 --_000_CO6PR18MB40521AEB923752B77E749A6EAEA09CO6PR18MB4052namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all, This is a followup on the actions we agreed upon during the November interi= m meeting in November (notes in https://datatracker.ietf.org/meeting/interi= m-2020-oauth-12/materials/minutes-interim-2020-oauth-12-202011021200-00). A= pologies for the delay. The TL;DR is that we decided it might be useful to put together a document = that describes the identity scenarios relying on current browser features a= nd that we=92d like to preserve. Such document should help grounding discussions with browser vendors by mak= ing it easy to pinpoint how specific changes might impair functionality in = important scenarios, and what functionality we are trying to preserve (in c= ase the new browser feature can offer alternate path to the same outcomes). Tackling on all the possible scenarios is too big a task for George and mys= elf alone, hence we devised a proposed mechanism to generate and maintain t= hat list collaboratively. You can find a framing proposal in https://datatracker.ietf.org/doc/html/dr= aft-bertocci-identity-in-browser-00, and the github repo workspace https://= github.com/IDBrowserUseCases/docs. Thanks to Daniel and Torsten for their h= elp on figuring out how to use mmark to write internet drafts. We do have a list of candidate scenarios, but before going too deep in it w= e wanted to give the group the chance to take a look at the model and get y= our feedback before we charge down that path. This is a pretty unusual coll= aboration model and getting it to work might be tricky. Please let us know what you think! Cheers G&V --_000_CO6PR18MB40521AEB923752B77E749A6EAEA09CO6PR18MB4052namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Dear all,

This is a followup on the actions we agre= ed upon during the November interim meeting in November (notes in https://datatracker.ietf.org/meeting/interim-2020-oauth-12/materials/minute= s-interim-2020-oauth-12-202011021200-00). Apologies for the delay.

The TL;DR is that we decided it might be = useful to put together a document that describes the identity scenarios rel= ying on current browser features and that we=92d like to preserve.

Such document should help grounding discu= ssions with browser vendors by making it easy to pinpoint how specific chan= ges might impair functionality in important scenarios, and what functionality we are trying to preserve (in case the new browser = feature can offer alternate path to the same outcomes).

 

Tackling on all the possible scenarios is= too big a task for George and myself alone, hence we devised a proposed me= chanism to generate and maintain that list collaboratively.

You can find a framing proposal in https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00= , and the github repo workspace https://github.com/ID= BrowserUseCases/docs. Thanks to Daniel and Torsten for their help on fi= guring out how to use mmark to write internet drafts.

 

We do have a list of candidate scenarios,= but before going too deep in it we wanted to give the group the chance to = take a look at the model and get your feedback before we charge down that path. This is a pretty unusual collaboration mo= del and getting it to work might be tricky.

Please let us know what you think!

 

Cheers

G&V

 

 

--_000_CO6PR18MB40521AEB923752B77E749A6EAEA09CO6PR18MB4052namp_-- From nobody Fri Jan 22 14:12:24 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4C3A1557; Fri, 22 Jan 2021 14:12:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161135354245.29889.16402204718029823884@ietfa.amsl.com> Date: Fri, 22 Jan 2021 14:12:22 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 22:12:23 -0000 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-11.txt Pages : 20 Date : 2021-01-22 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-11 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/ From nobody Fri Jan 22 14:15:47 2021 Return-Path: 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 6D62B3A0CFF for ; Fri, 22 Jan 2021 14:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 u8ek1Pz99Pqz for ; Fri, 22 Jan 2021 14:15:43 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 7BB223A1484 for ; Fri, 22 Jan 2021 14:14:54 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id z21so4765341pgj.4 for ; Fri, 22 Jan 2021 14:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=MsmbUgQwEk2DMc9tWIINR0YviuiXQ5FwXD28u7K5GPxNxX4eIx8ITGqbrVRhlSAWeu iAVVdYkYVEwkQMcjGk0YTHzFwtVKT7F3hMLdyTWVRwcy6kwRk0Xc+3OAGlfXJCMTVdey nw7Ax9D7k4PfZsE019f3QTW/OYOcp/C8Yu82kufW18Eyezu6PmswJcu6Slu/A5oFWQzv HYcywL7NHG5cFvPhJBkSJUwuvyEYrElVY2XTH2lNVZIxzbBwJFUfLljV2teJCO9Oomhb 3aDNhnA4NCkxbzWjJrEN21wg79v0Xuqg2xsXOtqf11stSEeb9hsbkiNtws/T71KmImac u9xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=1WIM5hueFDfkBB2SHWn3yVuSX6qp8Y6cI6kFF7cksVE=; b=OTl/ZAts2FOb8a9d+O2cykTb4cKbzRtTnh4qg9FYvY7LamKG3aDpfhAoIMYdDtzlyq y5jgccRravNLJItSFE79JP5fQLZWj7TyZOuHBvnjob7V43CusXsXYqooMx4BuPsqIr55 0UPAtES+s1Ftdac364uA3mzvwZijssNrKJ78Q1hZATvspQ/7OmoUjV8GM+odberZZ5AN nalIedN0PV2PJhlcIn0Xuhq4fr99D0VKTAhnFP3jfBn432gyi3Fb/uVncDmsehN2Sy8P NbZhK6uwIG5XLtbnm6ZqxHzirc9fMbglH2G6We7cOv1t2nsKWCRyDzEUiaBOW4M7OouS rzCw== X-Gm-Message-State: AOAM532k47fhceop+sgi1how5XGypwOocHHuVLO/9dVosIUesRc+Okc5 cX00RdWFUyWPNnoBJqHVSjj51Jed1z2SPw== X-Google-Smtp-Source: ABdhPJxWMTev4LvOsrUoIzEo1NL8zAWWsg4DlsKMWKOqxk8uee2TjVimL/n/FJ3LAqios9jQ2dYXSQ== X-Received: by 2002:a62:8801:0:b029:1b9:c4af:8148 with SMTP id l1-20020a6288010000b02901b9c4af8148mr7199465pfd.18.1611353693555; Fri, 22 Jan 2021 14:14:53 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id c4sm3090249pfo.35.2021.01.22.14.14.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 14:14:52 -0800 (PST) From: Vittorio Bertocci To: Roman Danyliw , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10 Thread-Index: Ada7bYibjuDIkiTCR8eXer4b6TfeyQC4rcyECus6VlABw7Xgdw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 22 Jan 2021 22:14:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 22:15:45 -0000 TlAsIHRoYW5rIHlvdSBmb3IgdGhlIGZvbGxvd3VwIQ0KSSBwb3N0ZWQgYW4gdXBkYXRlIHJlZmxl Y3RpbmcgdGhlIGZlZWRiYWNrIGFuZCBjb21tZW50cy4gV2UncmUgdmVyc2lvbiAxMS4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10 b2tlbi1qd3QtMTENClRoYW5rcw0KVi4NCg0K77u/T24gMS8xNC8yMSwgMDY6MzUsICJSb21hbiBE YW55bGl3IiA8cmRkQGNlcnQub3JnPiB3cm90ZToNCg0KICAgIEhpIFZpdHRvcmlvIQ0KICAgIA0K ICAgIFNvIHNvcnJ5IGZvciB0aGUgZGVsYXksIEkgZGlkbid0IGFwcHJlY2lhdGUgdGhpcyB3YXMg YXdhaXRpbmcgb24gYSByZXNwb25zZS4NCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQogICAgPiBGcm9tOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lA YXV0aDAuY29tPg0KICAgID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE5LCAyMDIwIDM6NDUg QU0NCiAgICA+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBvYXV0aEBpZXRmLm9y Zw0KICAgID4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYt b2F1dGgtYWNjZXNzLXRva2VuLWp3dC0xMA0KICAgID4gDQogICAgPiBUaGFuayB5b3UgUm9tYW4g Zm9yIHRoZSB0aG9yb3VnaCByZXZpZXchDQogICAgPiBJIGFwcGxpZWQgYWxsIHRoZSBlZGl0b3Jp YWwgYW5kIHR5cG8gZml4ZXMuIEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgb24gc29tZQ0KICAgID4g Y29tbWVudHMsIG9uY2Ugc29sdmVkIEknbGwgdXBkYXRlIGFjY29yZGluZ2x5IGFuZCBwdXNoIGEg bmV3IHZlcnNpb24uDQogICAgPiBUaGFua3MhDQogICAgPiBJbmxpbmUNCiAgICA+IA0KICAgID4g DQogICAgPiDvu78+T24gMTEvMTUvMjAsIDA4OjM5LCAiT0F1dGggb24gYmVoYWxmIG9mIFJvbWFu IERhbnlsaXciIDxvYXV0aC0NCiAgICA+IGJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJk ZEBjZXJ0Lm9yZz4gd3JvdGU6DQogICAgPiA+Wy4uXQ0KICAgID4gPiAgICAqKiBTZWN0aW9uIDIu Mi4yLiAgUGVyICJBbnkgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHdob3NlIHNlbWFudGljcyAgIEFu eQ0KICAgID4gYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHdob3NlIHNlbWFudGljcyBhcmUgd2VsbCBk ZXNjcmliZWQgYnkgdGhlIGF0dHJpYnV0ZSdzDQogICAgPiBkZXNjcmlwdGlvbiBmb3VuZCBpbiBT ZWN0aW9uIDUuMSBvZiBbLi5dDQogICAgPiA+ICAgTWF5YmUgbXkgcmVhZCBpdCB3cm9uZywgYnV0 IGl0IHNlZW1zIGxpa2UgdGhpcyB0ZXh0IHNheWluZyB0aGF0IGJleW9uZCB0aGUNCiAgICA+IHJl cXVpcmVkIGNsYWltcyBsaXN0ZWQgaW4gc2VjdGlvbiAyLjIsIHlvdSBjYW4gdXNlIGFueSBvZiB0 aGUgb3RoZXIgY2xhaW1zIGFzIGxvbmcNCiAgICA+IGFzIHRoZXkgYXJlIGluIHRoZSBJQU5BIEpX VCByZWdpc3RyeS4gIElzbid0IHRoYXQgc2ltcGxlciwgc2luY2UgdGhlIFNlY3Rpb24gNS4xLg0K ICAgID4gT3BlbklELkNvcmUgYXR0cmlidXRlcyBhcmUgcmVnaXN0ZXJlZD8NCiAgICA+ICBZb3Ug YXJlIHJpZ2h0LCB0aGF0J3Mgbm90IHZlcnkgY2xlYXIuDQogICAgPiBJbiBhIG51dHNoZWxsLCB3 aGF0IEkgYW0gdHJ5aW5nIHRvIHNheSBpcyAiaWYgeW91IHdhbnQgdG8gZXhwcmVzcyBhbiBhdHRy aWJ1dGUgZm9yDQogICAgPiB3aGljaCB0aGVyZSdzIGFscmVhZHkgYSB3ZWxsLWVzdGFibGlzaGVk IGNsYWltIGF2YWlsYWJsZSwgdXNlIHRoYXQgcmF0aGVyIHRoYW4NCiAgICA+IGludmVudGluZyAg bmV3IG9uZS4iLg0KICAgID4gVGhhdCBzdGlsbCBhbGxvd3MgZm9yIG5vbi1JQU5BIGNsYWltcyB0 byBiZSBpbnRyb2R1Y2VkLCBhcyBsb25nIGFzIHRoZQ0KICAgID4gaW1wbGVtZW50ZXIgaGFzIGRv bmUgdGhlIGR1ZSBkaWxpZ2VuY2UgYW5kIHZlcmlmaWVkIHRoYXQgdGhlIGF0dHJpYnV0ZSB0aGV5 DQogICAgPiBjb252ZXkgaXNuJ3QgY292ZXJlZCBpbiB0aGUgSUFOQSBKV1QgcmVnaXN0cnkuDQog ICAgPiBJIGV4cGxpY2l0bHkgbWVudGlvbiBPcGVuSUQgQ29ubmVjdCBhcyBzb3VyY2Ugb2YgY2xh aW1zIG1vc3RseSB0byBlbnN1cmUgdGhhdA0KICAgID4gdGhlIHJlYWRlciB3aWxsIHVuZGVyc3Rh bmQgYXQgZmlyc3QgZ2xhbmNlIHRoYXQgd2hlbiBpdCBjb21lcyB0byB1c2VyDQogICAgPiBpbmZv cm1hdGlvbiBhIEpXVCBBVCBjYW4gY29udmV5IHRoZSBzYW1lIGluZm9ybWF0aW9uIG9idGFpbmVk IHZpYSBPcGVuSUQNCiAgICA+IENvbm5lY3QsIHdpdGhvdXQgdGhlIG5lZWQgdG8gZm9sbG93IHRo ZSBsaW5rIGFuZCBjb25zdWx0IHRoZSBjaGFuZ2UNCiAgICA+IGNvbnRyb2xsZXIvcmVmZXJlbmNl IGNvbHVtbiBvZiB0aGUgY2xhaW1zIHRvIHJlYWxpemUgdGhhdC4gT25lIG9mIHRoZSBnb2FscyBJ IGFtDQogICAgPiBob3BpbmcgdGhpcyBzcGVjIHdpbGwgYWNoaWV2ZSBpcyB0byBzdG9wIHBlb3Bs ZSBmcm9tIGFidXNpbmcgSUQgdG9rZW5zIGFuZCB1c2luZw0KICAgID4gdGhlbSBpbiBsaWV1IG9m IGFjY2VzcyB0b2tlbnMgKGFzIEt1YmVybmV0ZXMgcm91dGluZWx5IGRvZXMsIGZvciBleGFtcGxl KSwNCiAgICA+IGhlbmNlIHRoZSAiZGVub3JtYWxpemVkIiBsYW5ndWFnZSBvZiB0aGF0IHNlY3Rp b24uDQogICAgPiBIZXJlJ3MgYW4gYWx0ZXJuYXRpdmUgZm9ybXVsYXRpb24gdGhhdCB0cmllcyB0 byBwcmVzZXJ2ZSB0aGF0IGNsYXJpdHkgd2hpbGUNCiAgICA+IHJlZmVycmluZyB0byB0aGUgcmVn aXN0cnk6DQogICAgPiANCiAgICA+ICJBbnkgYWRkaXRpb25hbCBpZGVudGl0eSBhdHRyaWJ1dGUg d2hvc2Ugc2VtYW50aWMgaXMgd2VsbCBkZXNjcmliZWQgYnkgYW4gZW50cnkNCiAgICA+IGluIHRo ZSBKU09OIFdlYiBUb2tlbiAoSldUKSBJQU5BIHJlZ2lzdHJ5IGludHJvZHVjZWQgaW4gW1JGQzc1 MTldIFNIT1VMRA0KICAgID4gYmUgZW5jb2RlZCB1c2luZyB0aGUgY29ycmVzcG9uZGluZyBjbGFp bSBuYW1lLg0KICAgID4gTm90ZSB0aGF0IHRoZSBKV1QgSUFOQSByZWdpc3RyeSBpbmNsdWRlcyB0 aGUgY2xhaW1zIGZvdW5kIGluIFNlY3Rpb24gNS4xIG9mDQogICAgPiBbT3BlbklELkNvcmVdLiIN CiAgICA+IA0KICAgID4gV2hhdCBkbyB5b3UgdGhpbms/IFdhaXRpbmcgZm9yIHlvdXIgZmVlZGJh Y2sgYmVmb3JlIGNoYW5naW5nIHRoZSBsYW5ndWFnZSBpbg0KICAgID4gdGhlIGRyYWZ0DQogICAg DQogICAgVGhpcyBsb29rcyBmaW5lIHRvIG1lLg0KICAgIA0KICAgID4gPiAgICAqKiBTZWN0aW9u IDMuICBXaGF0IHdvdWxkIGJlIHRoZSBjYXNlIHdoZXJlIGl0IHdvdWxkIG5vdCBiZSBhcHByb3By aWF0ZQ0KICAgID4gZm9yIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgdmFsdWUgdG8gYmUgdGhlIHNh bWUgYXMgdGhlIGF1ZCBjbGFpbSBpbiB0aGUgYWNjZXNzDQogICAgPiB0b2tlbiAodGhlIHRleHQg Y3VycmVudGx5IHNheXMgU0hPVUxELCB3aHkgbm90IE1VU1Q/KT8NCiAgICA+IFRoaXMgd2FzIGFj dHVhbGx5IGEgTVVTVCB1bnRpbCBkcmFmdCAzLCB0aGVuIEJyaWFuIHBvaW50ZWQgb3V0IHRoYXQg dGhpcyB3b3VsZA0KICAgID4gaGF2ZSBtYWRlIHRoaXMgcHJvZmlsZSBtb3JlIHJlc3RyaWN0aXZl IHRoYW4gcmVzb3VyY2UgaW5kaWNhdG9ycyBpdHNlbGYtIHdoaWNoDQogICAgPiBsZWQgbWUgdG8g c29mdGVuIHRoZSByZXF1aXJlbWVudCBhY2NvcmRpbmdseS4gQnJpYW4ncyBjb21tZW50IGluIGl0 cyBlbnRpcmV0eToNCiAgICA+IHxSZXNvdXJjZSBJbmRpY2F0b3JzIGlzIGFib3V0IGhvdyB0aGUg Y2xpZW50IGNvbnZleXMgdGhlIHRhcmdldCB0byB0aGUgQVMgYW5kDQogICAgPiBzYXlzICIgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIG1heSB1c2UgdGhlIGV4YWN0ICdyZXNvdXJjZScgdmFsdWUg YXMgdGhlDQogICAgPiBhdWRpZW5jZSBvciBpdCBtYXkgbWFwIGZyb20gdGhhdCB2YWx1ZSB0byBh IG1vcmUgZ2VuZXJhbCBVUkkgb3IgYWJzdHJhY3QNCiAgICA+IGlkZW50aWZpZXIgZm9yIHRoZSBn aXZlbiByZXNvdXJjZSIuIFRoZSBmb2xsb3dpbmcgZnJvbSB8c2VjIDMgaXMgbW9yZSByZXN0cmlj dGl2ZSAvDQogICAgPiBwcmVzY3JpcHRpdmUsIHdoaWNoIHNlZW1zIHRvIHJlYWNoIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhlIEpXVCBhY2Nlc3MgdG9rZW4NCiAgICA+IHByb2ZpbGUuDQogICAgPiB8 fCAgIklmIHRoZSByZXF1ZXN0IGluY2x1ZGVzIGEgcmVzb3VyY2UgcGFyYW1ldGVyIChhcyBkZWZp bmVkIGluDQogICAgPiB8fCBbUmVzb3VyY2VJbmRpY2F0b3JzXSksIHRoZSByZXN1bHRpbmcgSldU IGFjY2VzcyB0b2tlbiBhdWQgY2xhaW0gTVVTVA0KICAgID4gfHwgICBoYXZlIHRoZSBzYW1lIHZh bHVlIGFzIHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIgaW4gdGhlIHJlcXVlc3QuIg0KICAgIA0KICAg IE9oLCBnb3QgaXQuICBUaGFua3MgZm9yIGV4cGxhaW5pbmcuDQogICAgDQogICAgPiA+ICAgICoq IFNlY3Rpb24gNC4gUGVyIHRoZSB2YWxpZGF0aW9uIGd1aWRlbGluZXMgb24gYWNjZXNzIHRva2Vu IHZhbGlkYXRpb24sIGlzDQogICAgPiB0aGVyZSBwYXJhbGxlbCB0ZXh0IG5lZWRlZCB0byBkaXNj dXNzIHRoZSBSUyB1c2Ugb2YgdGhlIHRva2VuIHNheTogY2hlY2tpbmcgdGhhdA0KICAgID4gdGhl IGFjciBoYXMgYSB2YWx1ZSB0aGF0IGlzIGFwcHJvcHJpYXRlIChzbyBpdCBjYW4gaGF2ZSBjb25m aWRlbmNlIGluIHRoZSBzZWN1cml0eQ0KICAgID4gb2YgPiB0aGUgYXV0aGVudGljYXRpb24gdXNl ZCBiZXR3ZWVuIGNsaWVudC9BUyk/IE9yIHRoYXQgdGhlIHJpZ2h0DQogICAgPiBlbnRpdGxlbWVu dHMvZ3JvdXBzL2V0YyB3ZXJlIHByZXNlbnQgZm9yIHRoZSByZXF1ZXN0ZWQgb3BlcmF0aW9uPw0K ICAgID4gVGhhdCdzIGEgZ29vZCBwb2ludC4gVGhlIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24g NCB3YXMgbWVhbnQgdG8gYmUgYSBjYXRjaC1hbGwNCiAgICA+IGZvciB0aG9zZSBjYXNlcywgbWVu dGlvbmluZyBlbnRpdGxlbWVudHMgdW5kZXIgdGhlICJhdXRob3JpemF0aW9uIGNsYWltcyINCiAg ICA+IHVtYnJlbGxhIGFuZCBldmVyeXRoaW5nIGVsc2UgYXMgImFueSBvdGhlciBjb250ZXh0dWFs IGluZm9ybWF0aW9uIi4gVGhlIHRoaW5nDQogICAgPiB0aGF0IG1ha2VzIG1lIGhlc2l0YXRlIGJl Zm9yZSBnZXR0aW5nIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGF0IGlzIHRoYXQgaXQgY2FuIGJlDQog ICAgPiBhIHNsaXBwZXJ5IHNsb3BlIChhY3IsIGFtciwgZW50aXRsZW1lbnRzIGV0YyBhcmUgZ29v ZCBjYW5kaWRhdGVzLCBidXQgdGhlIHNhbWUNCiAgICA+IG1pZ2h0IGJlIHNhaWQgYWJvdXQgYXV0 aF90aW1lIGZvciBtYXhfYWdlIGxpa2Ugc2NlbmFyaW9zLCBmb3IgZXhhbXBsZS4uLiB3aGVyZQ0K ICAgID4gdG8gZHJhdyB0aGUgbGluZT8pIGFuZCBiZWluZyB0aG9zZSBvcHRpb25hbCwgbm90IGV2 ZXJ5b25lIG1pZ2h0IHJlYWRpbHkNCiAgICA+IHVuZGVyc3RhbmQgd2l0aG91dCBhZGRpbmcgbW9y ZSBjb2xvci9jb250ZXh0LiBDb21iaW5lZCB3aXRoIGhvdyBkaWZmaWN1bHQNCiAgICA+IHJlYWNo aW5nIGNvbnNlbnN1cyBmb3IgdGhlIGluY2x1c2lvbiBvZiBzZXNzaW9uIHByb3BlcnRpZXMgaW4g YWNjZXNzIHRva2VucywgcGx1cw0KICAgID4gdGhlIGZhY3QgdGhhdFJGQzY3NTAgZG9lcyBub3Qg Z2l2ZSBSUyBzcGVjaWZpYyBndWlkYW5jZSBmb3IgaG93IHRvIGFjdCBvbg0KICAgID4gYXV0aG9y aXphdGlvbiBpbmZvIChzY29wZXMpLCBJIG9wdGVkIGZvciBnZW5lcmljIGxhbmd1YWdlLg0KICAg ID4gSWYgeW91IGZlZWwgc3Ryb25nbHkgYWJvdXQgbW9yZSBzcGVjaWZpYyBndWlkYW5jZSBiZWlu ZyByZXF1aXJlZCBmb3IgdGhvc2UNCiAgICA+IGNsYWltcywgSSBjYW4gcHJvcG9zZSBtb3JlIHNw ZWNpZmljIGxhbmd1YWdlLSBidXQgYmVmb3JlIGRvaW5nIHNvLCBJIHdhbnRlZCB0bw0KICAgID4g b2ZmZXIgdGhlIGNvbnRleHQgYWJvdmUgdG8gc2VlIGlmIGl0IGNoYW5nZXMgdGhpbmdzLg0KICAg IA0KICAgIEhtbS4gIEkgd2lzaCBpdCBjb3VsZCBiZSBjbGVhcmVyIGJ1dCBJIG5vdyB1bmRlcnN0 YW5kIHRoZSB0cmFkZSBvZmYgeW91IG1hZGUuICBQbGVhc2UgbGVhdmUgdGhlIHRleHQgYXMgaXMu DQogICAgDQogICAgPiAgPiAgICoqIFNlY3Rpb24gNS4gIFRoaXMgdGV4dCBzZWVtcyB0byByZXN0 YXRlIG11Y2ggb2YgdGhlIHRleHQgZnJvbQ0KICAgID4gW09BdXRoMi5TZWN1cml0eS5CZXN0UHJh Y3RpY2VzXS4gIERvIG90aGVyIHNlY3Rpb24gYXBwbHkgaGVyZT8gIFBlcmhhcHMgYWxzbw0KICAg ID4gYWRkIHRoYXQgdGhlIFNlY0NvbnMgb2YgaW5kaXZpZHVhbCBjbGFpbXMgYXBwbHkgaGVyZSB0 b28gaWYgdXNlZCBpbiB0aGUgcHJvZmlsZQ0KICAgID4gKGFzIHRoaXMgcHJvZmlsZSBhbGxvd3Mg cHJldHR5IG11Y2ggYW55dGhpbmcgaW4gdGhlIEpXVCByZWdpc3RyeSB0byBiZSB1c2VkKS4NCiAg ICA+IEkgY29tYmVkIGRyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE2IGFuZCBiZXNp ZGVzIHRoZSBwYXJ0cyBhYm91dCBzdWIsDQogICAgPiBjbGllbnRfaWQgYW5kIGF1ZCAoYWxyZWFk eSByZWZlcmVuY2VkIGJ5IHRoZSBjdXJyZW50IHNwZWMsIG9yIGZ1cnRoZXIgcmVzdHJpY3RlZC0N CiAgICA+IGFzIGl0IHRoZSBjYXNlIGZvciB0aGUgYXVkaWVuY2UgY29uc2lkZXJhdGlvbnMpLCB0 aGUgQkNQIGRvZXNu4oCZdCBhcHBlYXIgdG8gb2ZmZXINCiAgICA+IGZ1cnRoZXIgZ3VpZGFuY2Ug dGhhdCB3b3VsZCB2YXJ5IGRlcGVuZGluZyBvbiB0aGUgY29udGVudCBvZiB0aGUgdG9rZW4uIFRo ZQ0KICAgID4gZ3VpZGFuY2Ugc2VlbXMgbW9zdGx5IG9uIGhvdyB0aGUgdG9rZW4gaXMgb2J0YWlu ZWQsIGFuZCB0aGUgbWVjaGFuaXNtcw0KICAgID4gZGVzY3JpYmVkIG9wZXJhdGUgYXQgdGhlIG1l c3NhZ2UgbGV2ZWwgaGVuY2UgYXBwbHkgdG8gSldUIGFjY2VzcyB0b2tlbnMgYW5kDQogICAgPiBv cGFxdWUgdG9rZW5zIGluIHRoZSBzYW1lIHdheS4gRGlkIHlvdSBoYXZlIGFueSBzcGVjaWZpYyBz ZWN0aW9uIG9mIHRoZSBCQ1AgaW4NCiAgICA+IG1pbmQ/DQogICAgPiBJIGFsc28gdG9vayBhIGxv b2sgYXQgcmZjNzUxOSBTZWNDb24gYW5kIGl0IGRvZXNu4oCZdCBhcHBlYXIgdG8gb2ZmZXIgY2xh aW1zLQ0KICAgID4gc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMuIEZpbmFsbHksIEkgY29tYmVkIHRo cnUgcmZjODcyNSBhbmQgaXQgc2VlbXMgdGhlIGN1cnJlbnQNCiAgICA+IHNwZWMgY292ZXJzIGFs bCB0aGUgY29udGVudCBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbnMgdGhhdCBhcHBseSB0byB0aGlz DQogICAgPiBzY2VuYXJpbywgbmFtZWx5IGluIHNlY3Rpb24gNCBmb3IgdGhlIGF1ZGllbmNlLCBp c3N1ZSBhbmQgc3ViamVjdCB2YWxpZGF0aW9uLCBhbmQNCiAgICA+IHNlY3Rpb24gMi4xIGFuZCA0 IGZvciB0aGUgc3Ryb25nIHR5cGluZy4NCiAgICA+IEJvdHRvbSBsaW5lOiBJIGNvdWxkIGFkZCBh IGdlbmVyaWMgcmVjb21tZW5kYXRpb24gdG8gY29uc2lkZXINCiAgICA+IE9BdXRoMi5TZWN1cml0 eS5CZXN0UHJhY3RpY2VzLCByZmM3NTE5IGFuZCByZmM4NzI1IHdoZW4gY29uc2lkZXJpbmcgdGhl DQogICAgPiBzZWN1cml0eSBvZiBhIEpXVCBhY2Nlc3MgdG9rZW4sIGJ1dCB0aGUgb25seSBzZWN0 aW9uIHRoYXQgc2VlbSBkaXJlY3RseQ0KICAgID4gYXBwbGljYWJsZSBzZWVtcyB0aGUgNC4xNCB3 ZSBhbHJlYWR5IHJlZmVyZW5jZS4gV2hhdCBkbyB5b3UgdGhpbms/IERvIHdlDQogICAgPiBuZWVk IHRoYXQgYmxhbmtldCByZWZlcmVuY2U/DQogICAgDQogICAgSSByZS1yZWFkIFtPQXV0aDIuU2Vj dXJpdHkuQmVzdFByYWN0aWNlc10gYW5kIG15IHN1Z2dlc3Rpb247IGFuZCBhZ3JlZSB3aXRoIHlv dXIgYXNzZXNzbWVudC4gIEFsbW9zdCBub3RoaW5nIGluIHRoZSBCQ1AgaXMgYWJvdXQgc3BlY2lm aWMgdG8gdGhlIHRva2VuIGNvbnRlbnQgYW5kIGZvcm1hdCB3aGljaCB0aGlzIG5hcnJvdyBmb2N1 cyBvZiB0aGlzIGRyYWZ0Lg0KICAgIA0KICAgIEFnYWluLCBzb3JyeSBmb3IgZGVsYXkuDQogICAg DQogICAgUmVnYXJkcywNCiAgICBSb21hbg0KICAgIA0KICAgICANCiAgICA+IA0KICAgIA0K From nobody Mon Jan 25 15:09:49 2021 Return-Path: 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 5573E3A19E6 for ; Mon, 25 Jan 2021 15:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ybBS6_Dhn_K5 for ; Mon, 25 Jan 2021 15:09:45 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 76C1C3A19C3 for ; Mon, 25 Jan 2021 15:09:45 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id n2so30091473iom.7 for ; Mon, 25 Jan 2021 15:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2k1aev//TcNnXluRbka8raobILQ6VF9f/J2D4B0270=; b=f4UcMrNiUovxtQy1EAVylxn80+jSAvfJfAtmVkc1V+x7wfoCdnjJReK0PozPZf4EYC yqE4CCYGjTcRpB8k+CHfz5rlW4M01wFOfhiHlhZ8lBiXz3ldnbXOagaD3WQGGB42jDrN 0fSqDhg4G2v9D6/4HzHX2zkO2r5Qz9/5jLcu+VF79dp5e1RCfM8JqB0pKLi9sFzOCaR3 t6Hsgd9ja8v7eiD36PwKEGLgEHpL07nbnZJl51ZDTMhsI/W/XAtushZ4ZDQ+uRQ1f/ZX GZDZAyQBzI46ilyQw9o+/m8n4nlTgG0SwEihF4GNvaIy8Yhl2xbBrYjjPshCQqytqR4I kAgw== 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=w2k1aev//TcNnXluRbka8raobILQ6VF9f/J2D4B0270=; b=f6m87TeerLhA5TCLXFW339gMutXQh7BMUE4SojwVTtR1DwjMPXzXPy0UT/nJjTjtwT RY9DwjwUIwhVP/0WXgQbm2/p7neJR7z9q6wF+DH2dhTTb4bQRbWxeFyQVelVs4bL2gKG 4pQrZuLQIdPfILmtQGR/pGM6HDr7sbcAR+tkO1nYzGBwrW6VQIkiXgvJpvV/ro9QwFd9 VVlqU4WGNvzkBABrDUZXkVpYnz/dSlpJPie9QY+K7OPIGABb2cWJEpxZ8/nj7Fnb8xr4 sc5z27AfSzEUO0HwFpa1elhf5S6Q2zHHNqQcwyUZErKiSQVTPJRG2WlV4JBGeFZHDEmQ qGUw== X-Gm-Message-State: AOAM531l7aOlk/3cU4GmqK2TcDnAuuCdTEEuxVoMXRGbRGD1zSHOO7pA 2Gy4piM2YRoLO78ehXLelH59zbnlQfpg6WYBj/Yg7Q== X-Google-Smtp-Source: ABdhPJzvA1HtcrkL2H3IiiwC0iJ2WTuiknQdDrkfS+TY2adkuiXwact2Q+qGqTrkBuI5HNlCym7SyWNziPl44Dcsxuc= X-Received: by 2002:a02:634b:: with SMTP id j72mr2577629jac.106.1611616184425; Mon, 25 Jan 2021 15:09:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sam Goto Date: Mon, 25 Jan 2021 15:09:33 -0800 Message-ID: To: Vittorio Bertocci Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003089ee05b9c1a209" Archived-At: Subject: Re: [OAUTH-WG] November Interim meeting on WebID/IsLoggedIn followup X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 23:09:47 -0000 --0000000000003089ee05b9c1a209 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 2021 at 11:30 AM Vittorio Bertocci wrote: > Dear all, > > This is a followup on the actions we agreed upon during the November > interim meeting in November (notes in > https://datatracker.ietf.org/meeting/interim-2020-oauth-12/materials/minu= tes-interim-2020-oauth-12-202011021200-00). > Apologies for the delay. > > The TL;DR is that we decided it might be useful to put together a documen= t > that describes the identity scenarios relying on current browser features > and that we=E2=80=99d like to preserve. > > Such document should help grounding discussions with browser vendors by > making it easy to pinpoint how specific changes might impair functionalit= y > in important scenarios, and what functionality we are trying to preserve > (in case the new browser feature can offer alternate path to the same > outcomes). > > > > Tackling on all the possible scenarios is too big a task for George and > myself alone, hence we devised a proposed mechanism to generate and > maintain that list collaboratively. > > You can find a framing proposal in > https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-= 00, > and the github repo workspace https://github.com/IDBrowserUseCases/docs. > Thanks to Daniel and Torsten for their help on figuring out how to use > mmark to write internet drafts. > > > > We do have a list of candidate scenarios, but before going too deep in it > we wanted to give the group the chance to take a look at the model and ge= t > your feedback before we charge down that path. This is a pretty unusual > collaboration model and getting it to work might be tricky. > > Please let us know what you think! > Thanks Vittorio for kicking this off and I just wanted to stop by and say that this seems like a wonderful starting point. I read your introduction (which I think has done a great job in capturing the intent), your template, and your initial test use case and I think this is a great starting point. More specifically: - I really like how you are positioning this effort. - I really like the section on scoping , primarily on what not to cover: any scenario not currently in mainstream. I know this is an over categorization, and I don't believe this was your intent, but just for clarification, we would welcome scenarios under "consumers" , "EDU" in addition to "enterprises" (I get the irony of the section above "classifying most other cases as enterprise use cases hence solvable by exceptions and local business policies" -- point taken). - The template LGTM. There is a chance it will evolve as we write more and we read more, but this is a good starting point. Here are a few ways that I think this could evolve: - perhaps a section with "Possible technologies/announcements/APIs/features that may pose a risk to this scenario" would be constructive to indicate "X (use case) breaks with Y (browser API)". - I have a sense that we would want to extend/break down "Privacy Considerations". One way to make this more concrete, is possibly to cross-reference one of the privacy threat models (e.g. ours is here: Privac= y Threat Model ) so that we can collect something like "X (use case) conflicts with Y (privacy threat)". Cross-referencing the threat model will also be useful in giving you a sense of the threats we are set to address too. I'll be watching the repository and looking forward to hearing from you, Thanks again, Sam > > Cheers > > G&V > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003089ee05b9c1a209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 22, 2021 at 11:30 AM Vitt= orio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Dear all,<= u>

This is a followup on the actions we agreed upon during= the November interim meeting in November (notes in https://datatracker.ietf.org/meeting/interim-2020-oauth-12/materials/minute= s-interim-2020-oauth-12-202011021200-00). Apologies for the delay.

The TL;DR is that we decided it might be useful to put = together a document that describes the identity scenarios relying on curren= t browser features and that we=E2=80=99d like to preserve.

Such document should help grounding discussions with br= owser vendors by making it easy to pinpoint how specific changes might impa= ir functionality in important scenarios, and what functionality we are trying to preserve (in case the new browser = feature can offer alternate path to the same outcomes).

=C2=A0<= /span>

Tackling on all the possible scenarios is too big a tas= k for George and myself alone, hence we devised a proposed mechanism to gen= erate and maintain that list collaboratively.

You can find a framing proposal in https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00= , and the github repo workspace htt= ps://github.com/IDBrowserUseCases/docs. Thanks to Daniel and Torsten fo= r their help on figuring out how to use mmark to write internet drafts.<= /u>

=C2=A0<= /span>

We do have a list of candidate scenarios, but before go= ing too deep in it we wanted to give the group the chance to take a look at= the model and get your feedback before we charge down that path. This is a pretty unusual collaboration mo= del and getting it to work might be tricky.

Please let us know what you think!


Thanks Vittorio for kicking this off and= I just wanted to stop by and say that this seems like a wonderful starting= point. I read your introduction (which I think has done a great job in cap= turing the intent), your template, and your initial test use case and I thi= nk this is a great starting point.=C2=A0=C2=A0
=C2=A0
M= ore specifically:

- I really like how you are posi= tioning this effort.
- I really like the section on scoping, primarily on what not to cover: any scenario not c= urrently in mainstream. I know this is an over categorization, and I don= 9;t believe this was your intent, but just for clarification, we would welc= ome scenarios under "consumers" , "EDU" in addition to = "enterprises" (I get the irony of the section above "classif= ying most other cases as enterprise use cases hence solvable by exceptions = and local business policies" -- point taken).=C2=A0=C2=A0
- = The template LGTM. There is a chance it will evo= lve as we write more and we read more, but this is a good starting point. H= ere are a few ways that I think this could evolve:
=C2=A0 - perha= ps a section with "Possible technologies/announcements/APIs/features t= hat may pose a risk to this scenario" would be constructive to indicat= e "X (use case) breaks with Y (browser API)".
=C2=A0 - = I have a sense that we would want to extend/break down "Privacy Consid= erations". One way to make this more concrete, is possibly to cross-re= ference one of the privacy threat models (e.g. ours is here:=C2=A0Priv= acy Threat Model) so that we can collect something like "X (use ca= se) conflicts with Y (privacy threat)". Cross-referencing the threat m= odel will also be useful in giving you a sense of the threats we are set to= address too.

I'll=C2=A0be watching the reposi= tory and looking forward to hearing from you,

Than= ks again,

Sam

=C2=A0<= /span>

Cheers<= /u>

G&V=

=C2=A0<= /span>

=C2=A0<= /span>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003089ee05b9c1a209-- From nobody Tue Jan 26 07:20:26 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDE3A0E33; Tue, 26 Jan 2021 07:20:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk CC: Hannes Tschofenig , draft-ietf-oauth-access-token-jwt@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161167442045.17170.14968771117405387964@ietfa.amsl.com> Date: Tue, 26 Jan 2021 07:20:20 -0800 Archived-At: Subject: [OAUTH-WG] Last Call: (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 15:20:25 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 26 15:20:57 2021 Return-Path: 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 10C6A3A0A65 for ; Tue, 26 Jan 2021 15:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 6N77R9oThzPl for ; Tue, 26 Jan 2021 15:20:54 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 D4B393A0A63 for ; Tue, 26 Jan 2021 15:20:53 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10QNKqvm044494 for ; Tue, 26 Jan 2021 18:20:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 10QNKqvm044494 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1611703252; bh=kmXcBIaIlacw+u4SLmND9e1poNoHdslBKQ2axX+Ljpk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=qv+SNhSQ0XoOEoClKi4hD+PH0nGAxyrZG+bVqND7EeqwOPoIqEcxN8yDtB0Dmhxng esJEjRw37hA2lh4E+pu9iyn5KYt4Xht+glW4Q8lII4UanRtajAieS1388YUWy1O/6d fgEdYbCHWjhy4R41IAnBN9cvTMBiRYWEiZqhrRVA= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10QNKnep005135 for ; Tue, 26 Jan 2021 18:20:49 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 26 Jan 2021 18:20:49 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 26 Jan 2021 18:20:49 -0500 From: Roman Danyliw To: "oauth@ietf.org" Thread-Topic: Status summary of document in AD Evaluation status Thread-Index: AdbubEWrYMo70AXPSgiZWGEVZkUzVAFzN0IA Date: Tue, 26 Jan 2021 23:20:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Status summary of document in AD Evaluation status X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 23:20:56 -0000 Hi! A correction ... > -----Original Message----- > From: Roman Danyliw > Sent: Tuesday, January 19, 2021 9:11 AM > To: oauth@ietf.org > Subject: Status summary of document in AD Evaluation status >=20 > Hi! >=20 > Below is a summary explanation of where all of the documents that are wit= h > me (as AD) stand. I hope this better explains the status in the datatrac= ker. >=20 > =3D=3D[ draft-ietf-oauth-access-token-jwt > Status: AD Evaluation::Revised I-D Needed (aka, after WG LC but before IE= TF LC > pending edits the AD has requested) >=20 > Pending edits from AD review confirmed at > https://mailarchive.ietf.org/arch/msg/oauth/t57XP7RICTpoI3FbOyrY0gpsNnE/. > After these are merged, this document can proceed to IESG Review. These edits have been merged and the document is now in IETC LC. > =3D=3D[ draft-ietf-oauth-jwsreq > Status: Status: Waiting for AD Go-Ahead:Revised I-D Needed (aka, after th= e > second WG and IETF LC, but IETF LC Directorate reviews require action) >=20 > All AD review and individual IETF LC feedback was addressed. >=20 > A few outstanding updates remain from the IETF LC SECDIR review -- > https://mailarchive.ietf.org/arch/msg/secdir/5CrZTLR8v6cm8wZVkfY_Yywckcw/ > . >=20 > After these changes are made, this document can return for IESG Review. >=20 > =3D=3D[ draft-ietf-oauth-jwt-introspection-response > Status: Waiting for AD Go-Ahead:Revised I-D Needed (aka, after the second= WG > and IETF LC, but IESG DISCUSS position from first IESG requires actions) [snip] I made a mistake when reviewing the old ballot position against the documen= t -- I must have used an older version. This document was ready and has be= en placed on the Feb 6, 2021 telechat. Thanks to Torsten for double chec= king. Roman From nobody Tue Jan 26 16:13:18 2021 Return-Path: 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 4F6A33A0E08 for ; Tue, 26 Jan 2021 16:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eSpVskOzRpgT for ; Tue, 26 Jan 2021 16:13:13 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 045023A0E05 for ; Tue, 26 Jan 2021 16:13:12 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id j13so250624edp.2 for ; Tue, 26 Jan 2021 16:13:12 -0800 (PST) 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; bh=MjcYu5KLbqd9U5NplBghkjLgrgcNN/RXtKM/Me1SsT8=; b=HyJojNN7CjtBfivAFIC+vA9ho6zW3dFjuoGIaDJco2QtzPfZVI0Agszf2qUWRzPl3W sRZ+uSLy4z3Ja9bCJoTpwcQu8i82n7rIHlQX10sBKQxvAQAw61VLiMwexoCIfjwL3gnA mM9+ao34tZWiT/87A9zSEnaEThlxDr7DzgG5GRoW+545L6AZcurxx/fSipoYtISOTpvI Up+zIEG375KsRbuZqo1ENywCP1CJTa4v77eKdGNi9EGOX+Sqj59Oi1DSmWQX7BaUS46o UGFsdRvgYbgi+yDonPVhh3tgLr6OFlrp7fv2XjHFXeIKNO+P5v+SRhFat4nSU+tLAe0e l7cw== 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; bh=MjcYu5KLbqd9U5NplBghkjLgrgcNN/RXtKM/Me1SsT8=; b=h5MCyW0INYoC8gSEgJJ5m/16KIBNsfSxW7yEg6H30POWKylydcVEtkmWFIjdK6prgx Eq320bkpk+rF0Ta5A6iK6NHsL8hfl7aOvThy/MiOR79lALBGSYvZPEcRehJcI7+l3alp 5bGQ3YNuiRUiuN2RmTdiA/4BlAIzXXRQ9EViGU/y13f1IDj3pvsisJYx16KrzHpA4Dc/ TIDGPfl98481dC62VcxYcooFECRsGjvi9GQeRUQl8qj0sbhoJabOWAQvdVpY1KEUUcRv uyMWrgnOW6IcqtTjq7k9lpwVbulfVjo5/vg28ib31ZxE8Z9O1K6sIqdWWhfC+ZdURP1u D2qw== X-Gm-Message-State: AOAM533HpTyvZV7EZQ/rrIfZnICbxRel9hwIQi/Sc/DCNWpa7del3IVY oa5IMMls/Yd/Rq07GHs6NQvfSTrIJ628X2dBpY64M+j9BSg= X-Google-Smtp-Source: ABdhPJwmRz7PMxAnqhJ+mTfr3r4a4t3buIU/4OSbUpX6P526apus9POmpMJneq842ZIzw/ZkBIrAokSAFBAi7mV+oYQ= X-Received: by 2002:a05:6402:d0a:: with SMTP id eb10mr6548555edb.249.1611706390981; Tue, 26 Jan 2021 16:13:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Jerry Louis Leyendecker, Living Soul" Date: Tue, 26 Jan 2021 18:12:58 -0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000eaaf9405b9d6a27d" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 147, Issue 13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 00:13:16 -0000 --000000000000eaaf9405b9d6a27d Content-Type: text/plain; charset="UTF-8" Call me asap to discuss what this means. 512-770-3800 Jerry Louis Leyendecker, Living Soul On Tue, Jan 26, 2021, 2:02 PM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: November Interim meeting on WebID/IsLoggedIn followup > (Sam Goto) > 2. Last Call: (JSON > Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed > Standard (The IESG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Jan 2021 15:09:33 -0800 > From: Sam Goto > To: Vittorio Bertocci > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] November Interim meeting on WebID/IsLoggedIn > followup > Message-ID: > UA@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Jan 22, 2021 at 11:30 AM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > Dear all, > > > > This is a followup on the actions we agreed upon during the November > > interim meeting in November (notes in > > > https://datatracker.ietf.org/meeting/interim-2020-oauth-12/materials/minutes-interim-2020-oauth-12-202011021200-00 > ). > > Apologies for the delay. > > > > The TL;DR is that we decided it might be useful to put together a > document > > that describes the identity scenarios relying on current browser features > > and that we?d like to preserve. > > > > Such document should help grounding discussions with browser vendors by > > making it easy to pinpoint how specific changes might impair > functionality > > in important scenarios, and what functionality we are trying to preserve > > (in case the new browser feature can offer alternate path to the same > > outcomes). > > > > > > > > Tackling on all the possible scenarios is too big a task for George and > > myself alone, hence we devised a proposed mechanism to generate and > > maintain that list collaboratively. > > > > You can find a framing proposal in > > > https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00 > , > > and the github repo workspace https://github.com/IDBrowserUseCases/docs. > > Thanks to Daniel and Torsten for their help on figuring out how to use > > mmark to write internet drafts. > > > > > > > > We do have a list of candidate scenarios, but before going too deep in it > > we wanted to give the group the chance to take a look at the model and > get > > your feedback before we charge down that path. This is a pretty unusual > > collaboration model and getting it to work might be tricky. > > > > Please let us know what you think! > > > > Thanks Vittorio for kicking this off and I just wanted to stop by and say > that this seems like a wonderful starting point. I read your introduction > (which I think has done a great job in capturing the intent), your > template, and your initial test use case and I think this is a great > starting point. > > More specifically: > > - I really like how you are positioning this effort. > - I really like the section on scoping > < > https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00#section-1.1 > >, > primarily on what not to cover: any scenario not currently in mainstream. I > know this is an over categorization, and I don't believe this was your > intent, but just for clarification, we would welcome scenarios under > "consumers" , "EDU" in addition to "enterprises" (I get the irony of the > section above "classifying most other cases as enterprise use cases hence > solvable by exceptions and local business policies" -- point taken). > - The template > < > https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00#section-4 > > > LGTM. There is a chance it will evolve as we write more and we read more, > but this is a good starting point. Here are a few ways that I think this > could evolve: > - perhaps a section with "Possible > technologies/announcements/APIs/features that may pose a risk to this > scenario" would be constructive to indicate "X (use case) breaks with Y > (browser API)". > - I have a sense that we would want to extend/break down "Privacy > Considerations". One way to make this more concrete, is possibly to > cross-reference one of the privacy threat models (e.g. ours is here: > Privacy > Threat Model > ) so > that we can collect something like "X (use case) conflicts with Y (privacy > threat)". Cross-referencing the threat model will also be useful in giving > you a sense of the threats we are set to address too. > > I'll be watching the repository and looking forward to hearing from you, > > Thanks again, > > Sam > > > > > > Cheers > > > > G&V > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210125/f7ca7c74/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Tue, 26 Jan 2021 07:20:20 -0800 > From: The IESG > To: "IETF-Announce" > Cc: Hannes Tschofenig , > draft-ietf-oauth-access-token-jwt@ietf.org, > hannes.tschofenig@arm.com, > oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org > Subject: [OAUTH-WG] Last Call: > (JSON Web Token (JWT) > Profile for OAuth 2.0 Access Tokens) to Proposed Standard > Message-ID: <161167442045.17170.14968771117405387964@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > 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 file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 147, Issue 13 > ************************************** > --000000000000eaaf9405b9d6a27d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Call me asap to discuss what this means. 512-770-3800=C2= =A0
Jerry Louis Leyendecker, Living Soul=C2=A0
=
On Tue= , Jan 26, 2021, 2:02 PM <oaut= h-request@ietf.org> wrote:
S= end OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: November Interim meeting on WebID/IsLoggedIn followup =C2=A0 =C2=A0 =C2=A0 (Sam Goto)
=C2=A0 =C2=A02. Last Call: <draft-ietf-oauth-access-token-jwt-11.txt>= (JSON
=C2=A0 =C2=A0 =C2=A0 Web Token (JWT) Profile for OAuth 2.0 Access Tokens) t= o Proposed
=C2=A0 =C2=A0 =C2=A0 Standard (The IESG)


----------------------------------------------------------------------

Message: 1
Date: Mon, 25 Jan 2021 15:09:33 -0800
From: Sam Goto <goto@google.com>
To: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.iet= f.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] November Interim meeting on WebID/IsLoggedIn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 followup
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAMtUnc6hOz74NQwAuPbMYBaq-gSr48h0iGPs8oAVcD= ggQ9E=3DUA@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

On Fri, Jan 22, 2021 at 11:30 AM Vittorio Bertocci <vittorio.bertocci=3D=
40auth0.com@dmarc.ietf.org> wrote:

> Dear all,
>
> This is a followup on the actions we agreed upon during the November > interim meeting in November (notes in
> https://datatracker.ietf.org/meeting/interim-= 2020-oauth-12/materials/minutes-interim-2020-oauth-12-202011021200-00).=
> Apologies for the delay.
>
> The TL;DR is that we decided it might be useful to put together a docu= ment
> that describes the identity scenarios relying on current browser featu= res
> and that we?d like to preserve.
>
> Such document should help grounding discussions with browser vendors b= y
> making it easy to pinpoint how specific changes might impair functiona= lity
> in important scenarios, and what functionality we are trying to preser= ve
> (in case the new browser feature can offer alternate path to the same<= br> > outcomes).
>
>
>
> Tackling on all the possible scenarios is too big a task for George an= d
> myself alone, hence we devised a proposed mechanism to generate and > maintain that list collaboratively.
>
> You can find a framing proposal in
> https://d= atatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00,
> and the github repo workspace https://githu= b.com/IDBrowserUseCases/docs.
> Thanks to Daniel and Torsten for their help on figuring out how to use=
> mmark to write internet drafts.
>
>
>
> We do have a list of candidate scenarios, but before going too deep in= it
> we wanted to give the group the chance to take a look at the model and= get
> your feedback before we charge down that path. This is a pretty unusua= l
> collaboration model and getting it to work might be tricky.
>
> Please let us know what you think!
>

Thanks Vittorio for kicking this off and I just wanted to stop by and say that this seems like a wonderful starting point. I read your introduction (which I think has done a great job in capturing the intent), your
template, and your initial test use case and I think this is a great
starting point.

More specifically:

- I really like how you are positioning this effort.
- I really like the section on scoping
<https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-= 00#section-1.1>,
primarily on what not to cover: any scenario not currently in mainstream. I=
know this is an over categorization, and I don't believe this was your<= br> intent, but just for clarification, we would welcome scenarios under
"consumers" , "EDU" in addition to "enterprises&qu= ot; (I get the irony of the
section above "classifying most other cases as enterprise use cases he= nce
solvable by exceptions and local business policies" -- point taken). - The template
<= https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00= #section-4>
LGTM. There is a chance it will evolve as we write more and we read more, but this is a good starting point. Here are a few ways that I think this could evolve:
=C2=A0 - perhaps a section with "Possible
technologies/announcements/APIs/features that may pose a risk to this
scenario" would be constructive to indicate "X (use case) breaks = with Y
(browser API)".
=C2=A0 - I have a sense that we would want to extend/break down "Priva= cy
Considerations". One way to make this more concrete, is possibly to cross-reference one of the privacy threat models (e.g. ours is here: Privac= y
Threat Model
<https://github.com/W= ICG/WebID/blob/master/privacy_threat_model.md>) so
that we can collect something like "X (use case) conflicts with Y (pri= vacy
threat)". Cross-referencing the threat model will also be useful in gi= ving
you a sense of the threats we are set to address too.

I'll be watching the repository and looking forward to hearing from you= ,

Thanks again,

Sam


>
> Cheers
>
> G&V
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau= th
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021= 0125/f7ca7c74/attachment.htm>

------------------------------

Message: 2
Date: Tue, 26 Jan 2021 07:20:20 -0800
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: Hannes Tschofenig <hannes.tschofenig@arm.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-access= -token-jwt@ietf.org, hannes.tschofenig@arm.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-chairs@ietf.org, oauth@ietf.org, <= a href=3D"mailto:rdd@cert.org" target=3D"_blank" rel=3D"noreferrer">rdd@cer= t.org
Subject: [OAUTH-WG] Last Call:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <draft-ietf-oauth-access-token-jwt-11.txt>= ; (JSON Web Token (JWT)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Profile for OAuth 2.0 Access Tokens) to Propose= d Standard
Message-ID: <161167442045.17170.1496= 8771117405387964@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JSON Web Token (JWT) Pro= file
for OAuth 2.0 Access Tokens'
=C2=A0 <draft-ietf-oauth-access-token-jwt-11.txt> as Proposed Standar= d

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
= last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments= may
be sent to iesg@ietf.org instead. In either case, please retain the beginnin= g
of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This specification defines a profile for issuing OAuth 2.0 acc= ess
=C2=A0 =C2=A0tokens in JSON web token (JWT) format.=C2=A0 Authorization ser= vers and
=C2=A0 =C2=A0resource servers from different vendors can leverage this prof= ile to
=C2=A0 =C2=A0issue and consume access tokens in interoperable manner.




The file can be obtained via
https://datatracker.ie= tf.org/doc/draft-ietf-oauth-access-token-jwt/



No IPR declarations have been submitted directly on this I-D.







------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 147, Issue 13
**************************************
--000000000000eaaf9405b9d6a27d-- From nobody Tue Jan 26 20:32:20 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E043A1211; Tue, 26 Jan 2021 20:32:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef , rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161172193850.26768.7940243594405897258@ietfa.amsl.com> Date: Tue, 26 Jan 2021 20:32:18 -0800 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 04:32:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- We've made a lot of progress at unravelling the gnarly issues relating to merging the introspection response and JWT claims namespaces, which is good. That said, I'd still like to discuss a little bit more the behavior described in Section 5, where the "token_introspection" claim in the response can also contain JWT claims (''' In addition, claims from the JSON Web Token Claims registry [IANA.JWT] established by [RFC7519] MAY be included as members in the "token_introspection" claim.''') That seems to be granting carte blanche to do the thing that was deemed problematic, i.e., mix the namespaces. As such, the current formulation in the document, in the general case of independent uncoordinated implementations, seems to admit the prospect of an AS adding something to an introspection response under the guise of the JWT claim exception that is interpreted by the recipient RS as a new introspection response parameter (or, I think, vice versa). Yes, this would require conflicting registrations to occur, but we still don't have a procedure in place that would prevent such conflicting registrations from occurring in the future. How can we add some low-cost safety controls that mitigate the risk while still enabling the desired functionality? I have a couple thoughts on this: there is already an exception for implementation/service-specific (unregistered) claims in the introspection response, which could apply to JWT claims under the same requisite conditions of administrative control, if that's going to cover the scenarios in question. One could also imagine a new registration procedure for introspection response parameters whereby (for example) any non-conflicting value already registered as a JWT claim can be mechanically propagated into the introspection response registry potentially just by IANA without even expert review. Then we would just require the contents to be registered introspection response parameters, and someone who wants to use JWT claims can trivially get them registered before using them. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not balloting this at a DISCUSS-level, because it may just be me failing to understand the intended meaning (or being forgetful), but I'm having a hard time seeing how we're self-consistent about the requirement for an RS to authenticate and authorize a given RS for a given introspection transaction. In particular, in Section 3 we see that "the authorization server MUST be able to identify, authenticate and authorize resource servers" and that "[t]he authorization server MUST be able to determine whether an RS is the audience for a particular access token and what data it is entitled to receive, otherwise the RS is not authorized to obtain data for the access token". While I see that there is also some discussion about using the "scope" parameter of the token being introspected as an indicator of the RS it is to be used for (and thus the identity of the RS that would legitimately be making an introspection request), and I also see discussion of using an encrypted introspection response as a way to ensure that the contents are only viewable by the intended RS, I'm not sure how clearly either (or both) mechanisms constitute "authentication" of the introspection request. Since we already require a "strong two-way trust relationship", it's not clear to me that it would be difficult to strongly authenticate the actual introspection request itself or that there is much gained by skipping such a check in favor of other mechanisms. Several of my inline comments touch on this topic (on the assumption that there is a strong MUST for strong authentication); I left them in place to benefit from the context of where they appear, rather than constructing a laundry list of all of them. That said, it will suffice to explain how I'm wrong/confused just once; there's no need to repeat it at each place I bring up the topic. Section 3 To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms. That seems more of a descriptive than a normative "must", to me. Section 4 A resource server requests a JWT introspection response by including an "Accept" HTTP header "application/token-introspection+jwt" in the introspection request. nit: "header field". and probably also something about "containing" or "with body". The AS SHOULD authenticate the caller at the token introspection endpoint. Authentication can utilize client authentication methods or a separate access token issued to the resource server. Whether a resource server is required to authenticate is determined by the respective RS-specific policy at the AS. I don't think this can be only a SHOULD-level requirement and be consistent with the MUST-level requirements in the previous section (most notably, "[AS] MUST be able to determine whether an RS is the audience for a particular access token". It is hard to believe that an unauthenticated RS could have such authorization. The following is a non-normative example request with client authentication: POST /introspect HTTP/1.1 Host: as.example.com Accept: application/token-introspection+jwt Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW (side note: "Authorization: Basic" makes me sad.) Section 5 The introspection endpoint responds with a JWT, setting the "Content- Type" HTTP header to "application/token-introspection+jwt" and the nit: "header field" again. If possible, the AS MUST narrow down the "scope" value to the scopes relevant to the particular RS. What's the difference between "if possible, MUST" and " SHOULD"? The JWT MAY include other claims, including those from the "JSON Web Token Claims" registry established by [RFC7519]. The JWT SHOULD NOT include the "sub" and "exp" claims as an additional prevention against misuse of the JWT as an access token (see Section 8.1). nit: I think a comma after "'exp' claims" would increase clarity. The JWT is cryptographically secured as specified in [RFC7662]. I think that this was intended to refer to 7519 (JWT), not 7662 (introspection)? Depending on the specific resource server policy the JWT is either signed, or signed and encrypted. If the JWT is signed and encrypted it MUST be a Nested JWT, as defined in JWT [RFC7519]. Note: If the resource server policy requires a signed and encrypted (nit?) Just to confirm: the "resource server policy" here is a policy that's applied at the AS on a per-resource-server basis? If so, perhaps writing it "resource-server-specific policy" would clarify. response and the authorization server receives an unauthenticated request containing an "Accept" header with content type other than "application/token-introspection+jwt", it MUST refuse to serve the request and return an HTTP status code 400. This is done to prevent downgrading attacks to obtain token data intended for release to legitimate recipients only (see Section 8.2). An unauthenticated request should be denied unconditionally, right? Should this MUST apply to just requests containing the "Accept" header (field) with other content-types? The example response JWT payload contains the following JSON document: [...] "token_introspection": { [...] "scope":"read write dolphin", Is there any chance the minimizer that was run on this payload as input to JWT generation also removed the spaces in the scope string? I seem to be having some unexpected behavior from my local tooling, but it is looking like the claims set from the example HTTP payload lists "scope":"readwritedolphin". Section 8.2 To prevent introspection of leaked tokens and to present an additional security layer against token guessing attacks the authorization server MAY require all requests to the token introspection endpoint to be authenticated. As an alternative or as an addition to the authentication, the intended recipients MAY be set up for encrypted responses. Isn't this ("require all requests to be authenticated") also a MUST now? From nobody Wed Jan 27 17:46:26 2021 Return-Path: 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 EBB853A1084 for ; Wed, 27 Jan 2021 17:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 vDPyeJRaw2hB for ; Wed, 27 Jan 2021 17:46:23 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 CEA2B3A1086 for ; Wed, 27 Jan 2021 17:46:23 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id a1so3794027ilr.5 for ; Wed, 27 Jan 2021 17:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hffutRBVi1BNgSJffhPnp+M0slaoTvGFptG1CfxUuiM=; b=gOHtV3KdP3aBermMUVHlm7tOrT4bCdx0H+YZ8fJ1HbIK56tCwN23uJyFfjAUI38p1O xoC7GKZfosc2SvcSmk7NlispFg6O6rMOFD32l8RrH5Dwr2YuPpSSEyGQBPsxVe47LSjJ 9vsPqb91PmdGKO6c/Y1PE7CBdqqSQX45/iWLL7dxNSxgQ+16ZNZRie5UnSEF+jHn0Gbm 55u7XsFtdwRRk6sVxAlBZlQDESFqZddJgs4JUcMXvJRQKONwPnFyD71cTLtfWepqF0QZ mb9aYYB2o97Qae5g8itv+62mTKYFREvtBCah4IZBVt5/AuQjTXpurNZQj04Y8TFvQWB2 y2Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hffutRBVi1BNgSJffhPnp+M0slaoTvGFptG1CfxUuiM=; b=IA7kQugkKxs0iUz22RyNk22SGNZv5e5wLms9L27JI2Kn90FEYDHrYiayQiq7W0RRJa dWem2ElJl/yHtA4TokgPM0qPzvKdQCXOfqZZ/mr8GZGaI6q3JhQYBs1NVLA0ZjgEuynC CrHl6uVP7JdoC761ZB0wVyxvNUt90OA7+goxbYZW5wxKH6Gr+Q/18nZjdpFDcOIlEdA1 BNwIK4lEFGhgedn0cScDRRiBVmuzUUrIAo4a8BIreBgn0WAaij1VUjX8xzpuL0q3EhkN bc5o64RR/G+uo4g6uteDfSgwWUc6GvW4CaABqgxCyRqK0BZnDxIBcq5gTo5BfW80zuvX LiZA== X-Gm-Message-State: AOAM531sihI7rAiAzcKiyCFB79eHRYtHsLqiZxREgOTebXxA1Gx0xoBT /YUZSLm8jZ2jItRUMdTs9917whuGTJPeJlpBOsSvzW2+G1s= X-Google-Smtp-Source: ABdhPJwmbpxipQ9faX1F+s5iJF0NJ0LYz2buoTjOtazQi2y81fJq3D8+LPInfWSSnaacQ9JisuC/MvueZU+JO9FQobA= X-Received: by 2002:a05:6e02:13ea:: with SMTP id w10mr11208538ilj.68.1611798382748; Wed, 27 Jan 2021 17:46:22 -0800 (PST) MIME-Version: 1.0 From: Kevin Powell Date: Wed, 27 Jan 2021 19:46:14 -0600 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000000da7f505b9ec0e84" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 01:46:25 -0000 --0000000000000da7f505b9ec0e84 Content-Type: text/plain; charset="UTF-8" Send permission --0000000000000da7f505b9ec0e84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Send permission=C2=A0
--0000000000000da7f505b9ec0e84-- From nobody Fri Jan 29 01:04:38 2021 Return-Path: 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 64C943A10B0 for ; Fri, 29 Jan 2021 01:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 VqPxp-dIdaih for ; Fri, 29 Jan 2021 01:04:28 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DFE3A10AD for ; Fri, 29 Jan 2021 01:04:27 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d12 with ME id NZ4N240045Eqqlm03Z4NwZ; Fri, 29 Jan 2021 10:04:25 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 29 Jan 2021 10:04:25 +0100 X-ME-IP: 90.79.54.243 To: last-call@ietf.org References: <161167442045.17170.14968771117405387964@ietfa.amsl.com> Cc: oauth From: Denis Message-ID: <33f8e681-5ee8-2fe1-8fea-3ee46f5eeb8d@free.fr> Date: Fri, 29 Jan 2021 10:04:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <161167442045.17170.14968771117405387964@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------DFB414AFF0080F328B313F98" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] Last Call: (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 09:04:31 -0000 This is a multi-part message in MIME format. --------------DFB414AFF0080F328B313F98 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have one comment on the Security Considerations section and several comments on the Privacy Considerations section. *Security Considerations section(Section 5) * The intent of this comment is to add information, but not to change the meaning. Current text: The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core]. The explicit typing required in this profile, in line with the recommendations in [RFC8725] helps the resource server to distinguish between JWT access tokens and OpenID Connect ID Tokens. Proposed text: The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core]. The explicit typing required in this profile (i.e. "at+jwt", see section 2.1), in line with the recommendations in [RFC8725] helps the resource server to distinguish between JWT access tokens (i.e. " jwt") and OpenID Connect ID Tokens (i.e. either "jwt" or "json"). *Privacy Considerations section(Section 6) * Current text: As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection. The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.Administrators of authorization servers should also take into account that the content of an access token is visible to the client.Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. Rational for a change: The following sentence at the beginning of the second paragraph is correct: "The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients". The current first sentence says that it is possible to directly peek inside the token claims collection. This is indeed possible /in the context of this RFC/ (/i.e. not in general/) since that client is able to test if a "typ" header parameter exists and if it contains the value " at+jwt". It is sufficient to warn the reader that such peeking is not possible in general, but is possible when/if the previous two conditions are satisfied. Before proposing a text replacement, if we were using sub-paragraphs for addressing the different topics, the text would be more readable: 6.1. Peeking inside the token claims collection 6.2. End-user identifier correlation 6.3. AS tracking Let us start with the last one (6.3). An email sent by Vittorio Bertocci on 2020-04-29 states in its last sentence: " I’ll try to come up with concise language that clarifies to the reader that the current mechanism does allow AS tracking". See: https://mailarchive.ietf.org/arch/msg/oauth/x2Xvd14hREBoYKEZ1h0bDsPRGKM/ However, no sentence has been added to address this warning. This explains why I propose the following text : 6.3. AS tracking Since an "aud" claim parameter is included by the AS inside every access token, the AS is in a position to know and trace where each access token is likely to be used. In addition, if token introspection is used by the RS, this allows the AS to know and trace exactly where and when each access token has been used.This may be a privacy concern for some end-users. Let us come back to the three previously quoted paragraphs. Proposed text replacement: 6. Privacy Considerations 6.1. Peeking inside the token claims collection JWT access tokens issued under this profile include in the "typ" header parameter of an access token the value "at+jwt" to explicitly declare that the JWT represents an access token compliant to this profile. This information allow RSs to know if they receive an access token compliant to this profile. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Nevertheless, when a client gets back an access token from an AS, if the value "at+jwt" is present in the "typ" header parameter of that access token, as such access tokens carry information by value, it is possible for clients and potentially even end users to directly peek inside the token claims collection. However, the AS and the RS might decide to change the token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse.As a consequence, clients should not expect to be always able to inspect the content of access tokens. Furthermore, this profile does not allow a client to request an access token format conformant to this profile. Administrators of authorization servers should take into account that the content of an access token is visible to the client. If this is a concern for the AS, it should take explicit steps to prevent it. The three paragraphs that come after can remain unchanged. To be explicit, here they are: In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed without privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidentiality. Possible measures to prevent leakage of information to clients and end users include: encrypting the access token, encrypting the sensitive claims, omitting the sensitive claims or not using this profile, falling back on opaque access tokens. In every scenario, the content of the JWT access token will eventually be accessible to the resource server.It’s important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims, for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on. The next and last original paragraph is addressing another topic. It starts with the following sentence: "This profile mandates the presence of the "sub" claim in every JWT (...) ". A key sentence is the following: " The "sub" claim should be populated by the authorization servers according to a privacy impact assessment ". This sentence does not provide a sufficient guidance. It is important to mention that there exists three options for the "sub" claim: * a globally unique identifier, * a resource server specific identifier, or * an access token specific identifier. and then, although no specific parameter has been defined to allow the client to choose between these three options, it is possible for an AS to allow such a choice using the "scope" parameter. Proposed text replacement for the last original paragraph: 6.2. End-user identifier correlation This profile mandates the presence of the "sub" claim in every JWT access token. The "sub" claim is defined in RFC 7519 (section 4.1.2) in the following way: "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique." When the subject value is scoped to be globally unique, it is possible for every RS to use that information for correlating incoming requests with data stored locally for the authenticated principal with different RSs. It is also possible for servers that are not resource servers (RSs) but which use the same globally unique identifiers for correlating stored data. Although the ability to correlate requests and stored data might be required by design in some scenarios, there are scenarios where such correlation is not desirable. In such scenarios, the AS may use an identifier that is locally unique in the context of the issuer: it may be unique either for every RS or for every access token : - In order to prevent tracking principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant         for different resource servers have distinct "sub" values that cannot be correlated in the event of resource servers collusion. - In order to prevent a resource server from correlating the principal’s activity within the resource itself, the authorization server should assign different "sub" values         for every JWT access token issued.In turn, the client should obtain a new JWT access token for every call to the resource server, to ensure that the resource server         receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests. This profile does not define a specific parameter that allows a client or an end-user to choose between these three options for the "sub" claim parameter: * a globally unique identifier (that allows correlations between RSs and beyond), * a resource server specific identifier (to prevent correlations between RSs and beyond), or * an access token specific identifier (for anonymous accesses to one or more RSs). The choice between these three options for the "sub" claim parameter is managed by the AS. However, if the AS supports a "scope" parameter in the access token request, it is possible for the AS to define different scopes that support one or more of these options. Alternatively, an AS may use one of these options for all its end-users or some of them on a per-user basis. In addition, such a choice may depend on the RS being accessed. Denis > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > 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 file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------DFB414AFF0080F328B313F98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I have one comment on the Security Considerations section and several comments on the Privacy Considerations section.

Security Considerations section  (Section 5)

The intent of this comment is to add information, but not to change the meaning.

Current text:
The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core]. 
The explicit typing required in this profile, in line with the recommendations in [RFC8725] helps the resource server to distinguish
between JWT access tokens and OpenID Connect ID Tokens.
Proposed text:
The JWT access token data layout described here is very similar to the one of the id_token as defined by [OpenID.Core]. 
The explicit typing required in this profile (i.e. "at+jwt", see section 2.1), in line with the recommendations in [RFC8725] helps
the resource server to distinguish between JWT access tokens (i.e. " jwt") and OpenID Connect ID Tokens (i.e. either "jwt" or "json").

Privacy Considerations section  (Section 6)

Current text:
As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection.

The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time
(for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse.

The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.  Administrators of authorization servers should also take into account
that the content of an access token is visible to the client.  Whenever client access to the access token content presents privacy issues for a given scenario,
the authorization server should take explicit steps to prevent it.
Rational for a change:

The following sentence at the beginning of the second paragraph is correct:
"The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients".
The current first sentence says that it is possible to directly peek inside the token claims collection. This is indeed possible in the context of this RFC
(i.e. not in general) since that client is able to test if a "typ" header parameter exists and if it contains the value " at+jwt". 
It is sufficient to warn the reader that such peeking is not possible in general, but is possible when/if the previous two conditions are satisfied.

Before proposing a text replacement, if we were using sub-paragraphs for addressing the different topics, the text would be more readable:
6.1. Peeking inside the token claims collection
6.2. End-user identifier correlation
6.3. AS tracking
Let us start with the last one (6.3). An email sent by Vittorio Bertocci on 2020-04-29 states in its last sentence:
" I’ll try to come up with concise language that clarifies to the reader that the current mechanism does allow AS tracking".
See: https://mailarchive.ietf.org/arch/msg/oauth/x2Xvd14hREBoYKEZ1h0bDsPRGKM/

However, no sentence has been added to address this warning. This explains why I propose the following text :
6.3. AS tracking

Since an "aud" claim parameter is included by the AS inside every access token, the AS is in a position to know
and trace where each access token is likely to be used. In addition, if token introspection is used by the RS,
this allows the AS to know and trace exactly where and when each access token has been used.  This may be
a privacy concern for some end-users.
Let us come back to the three previously quoted paragraphs.

Proposed text replacement:
6. Privacy Considerations

6.1. Peeking inside the token claims collection

JWT access tokens issued under this profile include in the "typ" header parameter of an access token the value "at+jwt"
to explicitly declare that the JWT represents an access token compliant to this profile. This information allow RSs to know
if they receive an access token compliant to this profile.

The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.

Nevertheless, when a client gets back an access token from an AS, if the value "at+jwt" is present in the "typ" header parameter
of that access token, as such access tokens carry information by value, it is possible for clients and potentially even end users
to directly peek inside the token claims collection.

However, the AS and the RS might decide to change the token format at any time (for example by switching from this profile to opaque tokens)
hence any logic in the client relying on the ability to read the access token content would break without recourse.  As a consequence, clients
should not expect to be always able to inspect the content of access tokens.

Furthermore, this profile does not allow a client to request an access token format conformant to this profile.

Administrators of authorization servers should take into account that the content of an access token is visible to the client. 
If this is a concern for the AS, it should take explicit steps to prevent it.
The three paragraphs that come after can remain unchanged. To be explicit, here they are:
   In scenarios in which JWT access tokens are accessible to the end
   user, it should be evaluated whether the information can be accessed
   without privacy violations (for example, if an end user would simply
   access his or her own personal information) or if steps must be taken
   to enforce confidentiality.

   Possible measures to prevent leakage of information to clients and
   end users include: encrypting the access token, encrypting the
   sensitive claims, omitting the sensitive claims or not using this
   profile, falling back on opaque access tokens.

   In every scenario, the content of the JWT access token will
   eventually be accessible to the resource server.  It’s important to
   evaluate whether the resource server gained the proper entitlement to
   have access to any content received in form of claims, for example
   through user consent in some form, policies and agreements with the
   organization running the authorization servers, and so on.
The next and last original paragraph is addressing another topic. It starts with the following sentence:
"This profile mandates the presence of the "sub" claim in every JWT (...) ".
A key sentence is the following: " The "sub" claim should be populated by the authorization servers according to a privacy impact assessment ".
This sentence does not provide a sufficient guidance. It is important to mention that there exists three options for the "sub" claim:
  • a globally unique identifier,
  • a resource server specific identifier, or
  • an access token specific identifier.
and then, although no specific parameter has been defined to allow the client to choose between these three options,
it is possible for an AS to allow such a choice using the "scope" parameter.

Proposed text replacement for the last original paragraph:
6.2. End-user identifier correlation

This profile mandates the presence of the "sub" claim in every JWT access token. The "sub" claim is defined in RFC 7519 (section 4.1.2)
in the following way:

      "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique."

When the subject value is scoped to be globally unique, it is possible for every RS to use that information for correlating incoming requests
with data stored locally for the authenticated principal with different RSs. It is also possible for servers that are not resource servers (RSs)
but which use the same globally unique identifiers for correlating stored data.

Although the ability to correlate requests and stored data might be required by design in some scenarios, there are scenarios where such correlation is not desirable.

In such scenarios, the AS may use an identifier that is locally unique in the context of the issuer: it may be unique either for every RS or for every access token :

      - In order to prevent tracking principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant
        for different resource servers have distinct "sub" values that cannot be correlated in the event of resource servers collusion.

      - In order to prevent a resource server from correlating the principal’s activity within the resource itself, the authorization server should assign different "sub" values
        for every JWT access token issued.  In turn, the client should obtain a new JWT access token for every call to the resource server, to ensure that the resource server
        receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests.

This profile does not define a specific parameter that allows a client or an end-user to choose between these three options for the "sub" claim parameter:
  • a globally unique identifier (that allows correlations between RSs and beyond),
  • a resource server specific identifier (to prevent correlations between RSs and beyond), or
  • an access token specific identifier (for anonymous accesses to one or more RSs).
The choice between these three options for the "sub" claim parameter is managed by the AS.

However, if the AS supports a "scope" parameter in the access token request, it is possible for the AS to define different scopes that support one or more of these options. 
Alternatively, an AS may use one of these options for all its end-users or some of them on a per-user basis. In addition, such a choice may depend on the RS being accessed.
Denis

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens'
  <draft-ietf-oauth-access-token-jwt-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/



No IPR declarations have been submitted directly on this I-D.





_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------DFB414AFF0080F328B313F98--