From nobody Wed Apr 1 07:14:15 2020 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 A5E9C3A0FF9 for ; Wed, 1 Apr 2020 07:14:10 -0700 (PDT) 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 1O4e7KLZw8Oi for ; Wed, 1 Apr 2020 07:14:08 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B994E3A0FF8 for ; Wed, 1 Apr 2020 07:14:08 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id y14so8695177iol.12 for ; Wed, 01 Apr 2020 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2oVZkVav8y9y/VKdujclNeO2nlAqbe1UWcwrXtUaFt8=; b=i1SWqAX33aeBKFN+3o/YGtt+UBP1GvRvEmA3hwPFv9X1TMU6E9UlOZM1zy1nBod4+F X8aP86MBq+qJ+X0QNnx8+27j+UbrupKAghE5rpZ3/4iYqvlgTReSSAQ/3uuhRN/+GR59 7IQGkEJDCb7s+6uI0iIVedL1BhZlNc/M9o5Teg0TAMtWuhvp5MgktIEFHznuBSIxXRwr mgRiFPI01sPW4E1l6LFflO/GzDgXBkUT63KhC1axXVXOktA49Zv/oI4tq4YnlSVetR45 bskjKyPDCzvwrwPvdPaksJZxzUszFkF4s+P3ru9AZ3bRbtlKg6h/XD86dIblFxi7d3BK qFSg== 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=2oVZkVav8y9y/VKdujclNeO2nlAqbe1UWcwrXtUaFt8=; b=gg60yVsj+h389gPdBmLlU9gfS5ar3dVXymz3td/T1bEXOEOQfuFaKxNcexDydzD72r vJQYmMuohLe71tjssBR6NjNCeKDAvGlxpyCsJrKLDyGQi0vBw3BMvHWkd1aMaXyCjLf/ 098G/SjE62Xkvc4BUlahdkkC1MPWkZo870fAJ5izsxUBH3mMQJqg8ralICD0aPBr8G2I LB0eQgq+pxqj+AEeZB3jgPC5hoVWj2fWQWZlqMMPqt6djG5NkgtSQNpjalU8lTln50qv to0dQuRoy/epAbHC24VPOtk+8p87ifSgc5mUaDT3XWwHJvGweLM3UJER7wiuiGoHznZI i1yA== X-Gm-Message-State: ANhLgQ1KZRaPgUlr+Ho/JMAFooTUQnsfYeoyV1UMsHMxs+v8jzZdUhyA XUZtRko5S9fSczwV1YVaF572i40KMN4oroe39dzGWQ== X-Google-Smtp-Source: ADFU+vujC9LmYQVQhpsyH3aBx7y1YokhCq2RLw1VTGE1sjlX5iPuuNduPuABoM7weNgC6JLy4aUAfS7JQThZCR3Ho2A= X-Received: by 2002:a05:6638:a9b:: with SMTP id 27mr20996318jas.70.1585750448016; Wed, 01 Apr 2020 07:14:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 1 Apr 2020 10:13:56 -0400 Message-ID: To: Steinar Noem Cc: oauth Content-Type: multipart/alternative; boundary="00000000000028108d05a23b4ce4" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: DPoP 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, 01 Apr 2020 14:14:11 -0000 --00000000000028108d05a23b4ce4 Content-Type: text/plain; charset="UTF-8" All, This concludes this call for adoption, and as per the feedback received, this document has been adopted as a WG document. *Authors,* Feel free to submit a new WG document. Regards, Rifaat & Hannes On Tue, Mar 24, 2020 at 4:11 AM Steinar Noem wrote: > +1 > > tir. 17. mar. 2020 kl. 13:21 skrev Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com>: > >> All, >> >> As per the conclusion of the PoP interim meeting, this is a call for >> adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the >> Application Layer (DPoP)* document: >> https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/ >> >> Please, let us know if you support or object to the adoption of this >> document as a working group document by March 31st. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > --00000000000028108d05a23b4ce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This concludes this call for= adoption, and as per the feedback=C2=A0received, this document has been ad= opted as a WG document.

Authors,

Feel free to submit a new WG document.

Re= gards,
=C2=A0Rifaat & Hannes





On Tue, Mar 24, 2020 at 4:11 AM Steinar No= em <steinar@udelt.no> wrote:<= br>
+1

tir. 17. mar. 2020 kl. 13:21 skrev Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&= gt;:
All,

As per the conclusion of the PoP interim meeting, this is= a call for adoption for the OAuth 2.0 Demonstration of Proof-of-Possess= ion at the Application Layer (DPoP) document:
https://dat= atracker.ietf.org/doc/draft-fett-oauth-dpop/
=C2=A0
Please, let u= s know if you support or object to the adoption of this document as a worki= ng group document by March 31st.

Regards,
=C2=A0Rifaat & Hann= es

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


--
<= span style=3D"color:rgb(34,34,34)">Vennlig hilsen

Ste= inar Noem
Partner Udelt AS
Systemutvikler
=C2=A0
|=C2=A0steinar@= udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
<= /div>
--00000000000028108d05a23b4ce4-- From nobody Wed Apr 1 08:20:03 2020 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 296F83A10F0 for ; Wed, 1 Apr 2020 08:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 sIC0K0RRXArp for ; Wed, 1 Apr 2020 08:20:00 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FF73A10EE for ; Wed, 1 Apr 2020 08:19:59 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 6193A2A84 for ; Wed, 1 Apr 2020 15:19:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1585754398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LeowqJr5iR+lKLD60/vHyK6uGgSLbV7Bz1nKG5z4e88=; b=bUqL7F6vKHkSGGJXXgPPfmY8IQeM+Vin/l1LNV7xCKmc4cvKm9N4qFHptTwZBfkGhCv1B/ 1v+xV0s6UhXWX5wXYT5bawlLuyjVEyqKtvGHYvTfjfSGhJm1609FWD5pvga87ZRUVeEHcb EFprVlN6X2KycQbLt7hU6Gq636SCbKM= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <6b4fa6ef-4c25-3759-cf6e-12dc64e469b4@danielfett.de> Date: Wed, 1 Apr 2020 17:19:57 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3EAE386B4B3FD4CB85537B83" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1585754398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LeowqJr5iR+lKLD60/vHyK6uGgSLbV7Bz1nKG5z4e88=; b=EAM8ht3vP+FxtKbaRSBh5FhfZMF398EIeEHqutglNEQjLdpJUTkLV2tAkWLt2ateK7reVt NX4MU8jh1APqcjhdtfqYDwbRFj05ELMLFVICVyzSDl8rOQucNe4JAEK99BtIcBsrZBDAh+ lbbCadUPB2TNSCFgstSfv4aDFZOf8ls= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1585754398; a=rsa-sha256; cv=none; b=JnuQ61DXLD6LR+xjXR8WlbqGEPMP8jUlaB/DulrZ4oy10qTfzzfCJLXTdFW5wha/aCXihh k5NEyMR431UHkuzEw25zK9PaZM4IfScJJD1E4X1HpepkHWPoTUIq08yATd0MA797oV/4jW t58SBk0NSXNZkNlutKk97iNaO1upg/A= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: DPoP 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, 01 Apr 2020 15:20:02 -0000 This is a multi-part message in MIME format. --------------3EAE386B4B3FD4CB85537B83 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 01.04.20 um 16:13 schrieb Rifaat Shekh-Yusef: > All, > > This concludes this call for adoption, and as per the > feedback received, this document has been adopted as a WG document. Thank you! > > *Authors,* > > Feel free to submit a new WG document. And done :-) -Daniel --------------3EAE386B4B3FD4CB85537B83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 01.04.20 um 16:13 schrieb Rifaat Shekh-Yusef:
All,

This concludes this call for adoption, and as per the feedback received, this document has been adopted as a WG document.

Thank you!


Authors,

Feel free to submit a new WG document.

And done :-)


-Daniel


--------------3EAE386B4B3FD4CB85537B83-- From nobody Wed Apr 1 08:20:58 2020 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 3520E3A10F0; Wed, 1 Apr 2020 08:20:56 -0700 (PDT) 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: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158575445614.30890.12392929945578599343@ietfa.amsl.com> Date: Wed, 01 Apr 2020 08:20:56 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-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, 01 Apr 2020 15:20:57 -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 Demonstration of Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley Torsten Lodderstedt Michael Jones David Waite Filename : draft-ietf-oauth-dpop-00.txt Pages : 15 Date : 2020-04-01 Abstract: This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-dpop-00 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-00 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 Wed Apr 1 10:14:18 2020 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 60D5C3A13D2 for ; Wed, 1 Apr 2020 10:14:10 -0700 (PDT) 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, 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=mitre.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 xfxyiESdU2h3 for ; Wed, 1 Apr 2020 10:14:08 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16143A1406 for ; Wed, 1 Apr 2020 10:14:06 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BF482332031 for ; Wed, 1 Apr 2020 13:14:03 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id 711EA33201E for ; Wed, 1 Apr 2020 13:14:03 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 6464E80C0D3 for ; Wed, 1 Apr 2020 13:14:03 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 48st8W2rJmzlYC; Wed, 1 Apr 2020 17:13:49 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2101.outbound.protection.outlook.com [104.47.64.101]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 48st8B55qVzlnd for ; Wed, 1 Apr 2020 17:13:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jMlIHuaJp9B2t5oD0drREUMLTFzQYMclDam+kPBoqZc76OxD/wTFZMxnyq5McxLmeMnMCpLdhju9OwyE4/Zmt8NNrXozX+xtfpXgqj5YdlvQBP3w2+MvW+O8ea7P2XfGdonJ2sqMwQgyYjdQlaCU5wST1MCvYS/EXglM4iUK/tKbyl5k+PJQ5DDRkR0+eZYzpJhbaAheRxbNMIHhzciiMhcpjz/NkfHnuur71CltT07pXSYOCC2ohT29C+daIMmCRfgxDqGzZeCohP6bsv/4IsLtfFw2gxoIRdT5vYP/mKAw1grcENJUp1W/9d96kwKbOQRJtPMV5b3yIDB87CWzhg== 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=1p3ajwvRED6qn5ULI9HeIOUUvSNVW1JQULeh2DxmtpE=; b=VC5o4RyGtzZ7Q6jv3iFYvLbE+peZ+njAPF7ZoeFnVeDmearj/X4aFI7PgTfQH2jODLjSqu20kvkK+8bRJW/L/B2aJuchVLtWHgVVpP7mFhRN8N5DcQmbwtOrf1O8lP+zzsFwOnXmkSGtDeg+FdDT37QWtlOgqgHFpSphEYnCYxpuA8FBj7a46czmMP+DO+xXSp6cRa8W/78sDLIqq0VeLlbd18reN0L5/TIpH6ewQtCYBt7ErF8tQMJ6l6dcRj7dv0vgEf2bvO5gTPUvVyPjYacartq7o9TFyMkT9gXKiWu8bC9u5AVvhZsXzr9qfNyhhtCGEXwwjegUYBqhtK2KSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BL0PR0901MB4578.namprd09.prod.outlook.com (2603:10b6:208:1c5::17) by BL0PR0901MB3731.namprd09.prod.outlook.com (2603:10b6:207:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Wed, 1 Apr 2020 17:13:46 +0000 Received: from BL0PR0901MB4578.namprd09.prod.outlook.com ([fe80::4c0:c5a6:52f:6e08]) by BL0PR0901MB4578.namprd09.prod.outlook.com ([fe80::4c0:c5a6:52f:6e08%6]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 17:13:46 +0000 From: "Peck, Michael A" To: "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-dpop-00 comments Thread-Index: AQHV/VsiS+GbQkdim0uit4ZD3i6X4w== Date: Wed, 1 Apr 2020 17:13:45 +0000 Message-ID: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mpeck@mitre.org; x-originating-ip: [192.160.51.87] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bf9dda87-1883-45ff-a855-08d7d6600974 x-ms-traffictypediagnostic: BL0PR0901MB3731: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR0901MB4578.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39860400002)(316002)(6916009)(81156014)(6506007)(8936002)(2906002)(966005)(81166006)(478600001)(6486002)(64756008)(26005)(8676002)(66556008)(66446008)(33656002)(71200400001)(76116006)(6512007)(66476007)(66946007)(86362001)(186003)(36756003)(2616005)(5660300002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XQGw5w3T2ytcnwDB51whZeDyi2K9iQzVdZJ+jlOv9cyu5JlVXVtIXdJVHz8yaB7bouUe6VaVhMxlYEn9AcQNYCNydyjelZI+2Hfapij+p5B7m20bM0KCX5nIBARqgkKbGETzusMtIGkRRuSQFo8WcQkPEHQjNW7mz7CdmQe3PuswwMo/wJiJuWw9aUrPwC5cHAraug2wmxRc+KXwf7ueD8Axrf6WAHjBTvv6CCAefMe20Tz0pnefFBwEu5YBwgSxS7Qlm1VPSJ3hAshU6VaIlpQm0z0ScxcmltwtFpFp+1oeL2ZScJR74eXFirKYdNMfTu3Hd8zVIt81QJWhDJfjezQHY8QVuoKlyj09zJnT0tafnXwQ3Ix7pGaJrjHPWMK8iL4X3Tth2F6QGR1Z8owAG7Tidf/sXfU7g3mp3sQkEBDu99vWfHIlDB/oAhy1Pl++p5ujZnKgymDV7G4k7fgWMknZkIUhttvFU3dtWmqP/zVcZxWkNf/Pqa3y4xEmYfRWDDK4oMp9f3moaRB3leiR8A== x-ms-exchange-antispam-messagedata: GFvm7r2cg9Vr1WGZnBz7z7oF5M7WE6/Ey/9fhNwWZUVWwyB4TA+d/S/RG32jLSa0RHXIhfqIYtgmZFg/gP4Iw2NIgeMGPaRuNC1LYM1xeCUtibLCgZLu2WKQCHEAewSQpzhbeesgKAftrXOxdum4Wg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <87BF6E69B5537C4A8F9BA665E7118BBF@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-Network-Message-Id: bf9dda87-1883-45ff-a855-08d7d6600974 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 17:13:45.8157 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tqsHYOhJyVA3xHbLnodGkSK2xnfZGMjRBxIkcdp4m/zViaZE01VkKVVjiMjt92ic X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3731 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:content-type:content-id:content-transfer-encoding:mime-version; s=selector1; bh=1p3ajwvRED6qn5ULI9HeIOUUvSNVW1JQULeh2DxmtpE=; b=FIaidYZak5q43klAWW+5U2wvOzvmT9IgVRknMR4fGE/EEAixJT3UNEPEiWNWDnCpHane/lpINXidknqBnP0FeL6GXcNjLtuydS0s6Fyd15nS2/knLmKE3FSxdjAVEnI0PFbjpNpSM45kTubo6d2AwdeyN9Zwc1JhEnqCsFMCUAE= Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 01 Apr 2020 17:14:16 -0000 SGksDQoNCkdsYWQgdG8gc2VlIERQb1AgbW92aW5nIGZvcndhcmQgYXMgYSB3b3JraW5nIGdyb3Vw IGl0ZW0uDQpJIGhhdmUgYSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhlIGN1cnJlbnQgZHJhZnQ6 DQoNCjEuDQpJIHJlY29tbWVuZCBleHBhbmRpbmcgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSB0aHJl YXQgbW9kZWwuDQpJdCdzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB3aGF0IHRocmVhdHMgRFBv UCBpcyBleHBlY3RlZCB0byBhZGRyZXNzLCB3aGljaCBtYWtlcyBpdCBoYXJkIHRvIGV2YWx1YXRl IHdoZXRoZXIgRFBvUCBtZWV0cyBpdHMgb2JqZWN0aXZlcy4NCg0KU2VjdGlvbiAyIHN0YXRlcyB0 aGF0IHRoZSBtYWluIG9iamVjdGl2ZSBpcyB0byBwcmV2ZW50IGFuIGFkdmVyc2FyeSB3aG8gc2V0 IHVwIGEgY291bnRlcmZlaXQgQVMgb3IgUlMgZnJvbSByZXBsYXlpbmcgYSByZWNlaXZlZCByZWZy ZXNoIHRva2VuIG9yIGFjY2VzcyB0b2tlbiBhdCBhbm90aGVyIHNlcnZlci4gV291bGQgaXQgYmUg cG9zc2libGUgdG8gZXhwYW5kIHVwb24gdGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgdGhyZWF0IGFu ZCBob3cgaXQgbWF5IG9jY3VyPw0KQXJlIHRoZXJlIG90aGVyIHNpdHVhdGlvbnMgd2hlcmUgYW4g YWR2ZXJzYXJ5IG1heSBiZSBhYmxlIHRvIGNhcHR1cmUgYSByZWZyZXNoIHRva2VuIG9yIGFjY2Vz cyB0b2tlbiB0aGF0IHNob3VsZCBiZSBtZW50aW9uZWQgYXMgb2JqZWN0aXZlcyB0byBhZGRyZXNz IC0gZS5nLiBtYWxpY2lvdXMgLyB0aGlyZC1wYXJ0eSBKYXZhU2NyaXB0IGNvZGU/DQoNClByZXN1 bWFibHkgdGhlIGNvdW50ZXJmZWl0IEFTIG9yIFJTIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUgaG9z dG5hbWUgKGUuZy4gd2l0aCBhbiBpbGxlZ2l0aW1hdGVseSBpc3N1ZWQgc2VydmVyIGNlcnRpZmlj YXRlKSBhcyB0aGUgbGVnaXRpbWF0ZSBzZXJ2ZXIsIGFzIG90aGVyd2lzZSBEUG9QIHdvdWxkbuKA mXQgcHJvdmlkZSBwcm90ZWN0aW9uLiBXaHkgd291bGQgdGhlIGNsaWVudCBzZW5kIHRoZSByZWZy ZXNoIHRva2VuIHRvIHRoZSB3cm9uZyBBUz8NCg0KRm9yIHJlc291cmNlIHNlcnZlcnMsIHdoeSB3 b3VsZG7igJl0IGFuIGFjY2VzcyB0b2tlbiBhdWRpZW5jZSByZXN0cmljdGlvbiBzdWZmaWNlPyBJ cyB0aGUgY29uY2VybiB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gbWlnaHQgbm90IGNvbnRhaW4gYW4g YXVkaWVuY2UgcmVzdHJpY3Rpb24sIG9yIG1pZ2h0IGNvbnRhaW4gbXVsdGlwbGUgYXVkaWVuY2Vz PyAoSWYgdGhlIGNvbmNlcm4gaXMgdGhhdCB0aGUgcmVzb3VyY2Ugc2VydmVyIHdvdWxkbuKAmXQg Y2hlY2sgdGhlIGF1ZGllbmNlLCBJ4oCZZCBoYXZlIGEgc2ltaWxhciBjb25jZXJuIHRoYXQgaXQg d291bGRu4oCZdCBjaGVjayBhIERQb1AgcHJvb2YuKQ0KDQoyLg0KRFBvUCBjdXJyZW50bHkgZG9l cyBub3QgcHJvdmlkZSBhbnkgZ3VhcmFudGVlcyB0aGF0IHRoZSBEUG9QIHNpZ25hdHVyZSB3YXMg ZnJlc2hseSBnZW5lcmF0ZWQsIGFzIHRoZXJlIGlzIG5vIG5vbmNlIGZyb20gdGhlIHNlcnZlciBp bmNvcnBvcmF0ZWQgaW50byB0aGUgc2lnbmF0dXJlLg0KSSBhc3N1bWUgdGhlcmUgaXMgbm8gcHJh Y3RpY2FsIG1lYW5zIGZvciB0aGUgc2VydmVyIHRvIHNlbmQgYSBub25jZSB0byB0aGUgY2xpZW50 IHRvIHVzZSB3aXRoIGVhY2ggcmVxdWVzdCB0aGF0IHdvdWxkbid0IG92ZXItY29tcGxpY2F0ZSBE UG9QLg0KSSBhbHNvIGRvbid0IHNlZSBhbnkgZ3VpZGFuY2UgaW4gdGhlIGRyYWZ0IGFib3V0IGxp ZmV0aW1lL3JvdGF0aW9uIG9mIGVhY2ggRFBvUCBrZXkgb3Igd2hldGhlciB0aGUgc2FtZSBrZXkg Y2FuIGJlIHVzZWQgd2l0aCBtdWx0aXBsZSBzZXJ2ZXJzLg0KDQpNeSBjb25jZXJuIGlzIHRoYXQg c29tZXRoaW5nIGFuYWxvZ291cyB0byB0aGlzIEtlcmJlcm9zIFBLSU5JVCBhdHRhY2sgLSBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2tyYi13Zy9wTGdJRDM1Zk5HMVpoX1FK amdYSDl2RWJ3b1EvIC0gY291bGQgb2NjdXIgaWYgRFBvUCBzaWduYXR1cmVzIGNhbiBiZSBwcmUt Y29tcHV0ZWQgYnkgYW4gYWR2ZXJzYXJ5IHRoYXQgc29tZWhvdyBnYWlucyB0aGUgYWJpbGl0eSB0 byBjb21wdXRlIHNpZ25hdHVyZXMgd2l0aCB0aGUgcHJpdmF0ZSBrZXkgYnV0IGRvZXNuJ3QgZ2Fp biBhY2Nlc3MgdG8gdGhlIHByaXZhdGUga2V5IGl0c2VsZi4gQ291bGQgdGhhdCBwb3RlbnRpYWxs eSBoYXBwZW4gd2l0aCBtYWxpY2lvdXMgSmF2YVNjcmlwdCBjb2RlPw0KDQpUaGUgaWF0IHRpbWVz dGFtcCBpcyBpbnN1ZmZpY2llbnQgc2luY2UgZnV0dXJlIHZhbHVlcyBjb3VsZCBiZSBpbnB1dHRl ZCB3aXRoIHRoZSBzaWduYXR1cmVzIHN0b3JlZCBmb3IgbGF0ZXIgdXNlLiBJIGNvdWxkIGVudmlz aW9uIGEgcHJpdmF0ZSBrZXkgcG90ZW50aWFsbHkgYmVpbmcgcmUtdXNlZCBmb3IgYSBsb25nIHBl cmlvZCBvZiB0aW1lLCBhbmQgZGVwZW5kaW5nIG9uIGhvdyBEUG9QIGVuZHMgdXAgZ2V0dGluZyB1 c2VkIGluIHByYWN0aWNlLCBhIHByaXZhdGUga2V5IGJlaW5nIHVzZWQgd2l0aCBtdWx0aXBsZSBz ZXJ2ZXJzPw0KDQpJZiBndWFyYW50ZWVpbmcgc29tZSBkZWdyZWUgb2YgZnJlc2huZXNzIG9mIHRo ZSBzaWduYXR1cmUgaXMgYSBjb25jZXJuLCBvbmUgc29sdXRpb24gY291bGQgYmUgdG8gaW5jb3Jw b3JhdGUgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpbnRvIHRoZSBEUG9QIHNpZ25hdHVyZSBmb3Ig dG9rZW4gcmVxdWVzdHMgdG8gdGhlIEFTIHdpdGggZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2Nv ZGUsIGluY29ycG9yYXRlIHRoZSByZWZyZXNoIHRva2VuIGludG8gdGhlIERQb1Agc2lnbmF0dXJl IGZvciB0b2tlbiByZXF1ZXN0cyB0byB0aGUgQVMgd2l0aCBncmFudF90eXBlPXJlZnJlc2hfdG9r ZW4sIGFuZCBpbmNvcnBvcmF0ZSB0aGUgYWNjZXNzIHRva2VuIGludG8gdGhlIERQb1Agc2lnbmF0 dXJlIGZvciByZXF1ZXN0cyB0byBhIHJlc291cmNlIHNlcnZlci4gVGhhdCB3b3VsZCBwcmV2ZW50 IHByZS1jb21wdXRpbmcgRFBvUCBzaWduYXR1cmVzIGJlZm9yZSB0aGUgYXV0aG9yaXphdGlvbiBj b2RlIC8gcmVmcmVzaCB0b2tlbiAvIGFjY2VzcyB0b2tlbiBpcyBnZW5lcmF0ZWQgYnkgdGhlIEFT LCBhcyBsb25nIGFzIHRoZSByZWNpcGllbnQgcHJvcGVybHkgY2hlY2tzIHRoZSBEUG9QIHByb29m Lg0KDQpJJ2QgYWxzbyBzdWdnZXN0IGFkZGluZyBndWlkYW5jZSBvbiByb3RhdGluZyB0aGUgRFBv UCBrZXkgLSBlLmcuIG1hbmRhdGUvcmVjb21tZW5kIHRoYXQgdGhlIGNsaWVudCBjcmVhdGUgYSBu ZXcga2V5cGFpciBmb3IgZWFjaCB0b2tlbiByZXF1ZXN0Pw0KDQpUaGFua3MsDQpNaWtlDQoNCg0K From nobody Wed Apr 1 12:47:26 2020 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 2B7A03A1855; Wed, 1 Apr 2020 12:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158577044306.30914.10917143124102266083@ietfa.amsl.com> Date: Wed, 01 Apr 2020 12:47:23 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 01 Apr 2020 19:47:24 -0000 A new interim meeting request has just been submitted by Hannes Tschofenig. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-03 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Meeting Type: Virtual Meeting Session 1: Date: 2020-04-06 Start Time: 18:00 Europe/Vienna Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m7e39bc19240468eafc9b00a0ebc673b0 Agenda Note: --------------------------------------------------------- From nobody Wed Apr 1 12:52:55 2020 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 6B1473A186B for ; Wed, 1 Apr 2020 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=1oDygTxV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=1oDygTxV 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 BWe9Um7MgwgO for ; Wed, 1 Apr 2020 12:52:52 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::604]) (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 9708A3A1867 for ; Wed, 1 Apr 2020 12:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w8f2zbPuVqBbQF5RVW9dQxdOU2eelLGfPrHEF4XDTvM=; b=1oDygTxVrqFAQ0L7hZOGnE8a77VF7F+i5Fa8gvg7WL60oZ6goubmPXQBCr75FC881rET48ed/JZ/Q7PP7yv40Yn3Cefvag0ZyegsP0aQgN5cOH/H5V/8ZAE4VEIYW/s8SfeZNtQRXCeKMCbYtgnWtVUxS7jPPeUl3YnT4SLVH2s= Received: from DB6PR0301CA0051.eurprd03.prod.outlook.com (2603:10a6:4:54::19) by AM0PR08MB5090.eurprd08.prod.outlook.com (2603:10a6:208:15c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 19:52:48 +0000 Received: from DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:54:cafe::fe) by DB6PR0301CA0051.outlook.office365.com (2603:10a6:4:54::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Wed, 1 Apr 2020 19:52:48 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT013.mail.protection.outlook.com (10.152.20.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Wed, 1 Apr 2020 19:52:48 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Wed, 01 Apr 2020 19:52:48 +0000 X-CR-MTA-TID: 64aa7808 Received: from ed17c65d04a8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 08065DD2-0DF4-406C-9DAB-C8667621815D.1; Wed, 01 Apr 2020 19:52:43 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ed17c65d04a8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Apr 2020 19:52:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jLEqUKsZdxinVFzbk4GRj5t8BtGSlBOaimYcuEsaNCF/x9Zpyd77WlJrVsWNAbmh/wSOVGTgYtEEhXC+O4aV4kPscPheFCMEgCqLvtnOrNkPUCr4TypKiKncQVc78uaHMycTkdsQ9Px9W2rLTdxruJumR+pb79d2ovbwJB5l6XeHwGNFa5kbDYB6NOjf2Je53f/QCRMpgNfQ7p47CtZaSW0u+yDmfh4FsjZD+Mt7DorKVNSfz0PPkSVip791BGvuBajOrEzcaxZuLE1JK4abwIGsds5vJcn5nATWZ3Lv32hw+NPxl06RnumPq2NXzoP60y+s92sHElvMAQZ9OWJAgA== 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=w8f2zbPuVqBbQF5RVW9dQxdOU2eelLGfPrHEF4XDTvM=; b=iUPMnGm0c+pBOn7rk+Y8Cu8T8t7k+cFe+Z6T51uxuxDzMrLZYQJec/ykvWik75rk6YKpGXuJq+wdI2xTyBWcxaL5Bis6fMz0VG+DbDc4EmFTH/mO/AlAmXey1V10YSdPJVja8oMcpPPm17hZYgYsWM/gMlJHwUtYj+wGleKTA3q5LUxCdwhkHA2E9iHsfW+EARB7Z7H2AT0gQ33uyF/EYBklAZhHssTQk4HoffmaGTyCpYLKmZOaw1IGq2SxikGPXqKVhPmY1i9fAb7Y2VF39KTp9kB9EzLG5X9QoAdWHAHlIK6p8Up/zzzPloYQII4s2P0N4F9vrkE5wWFDxagjPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w8f2zbPuVqBbQF5RVW9dQxdOU2eelLGfPrHEF4XDTvM=; b=1oDygTxVrqFAQ0L7hZOGnE8a77VF7F+i5Fa8gvg7WL60oZ6goubmPXQBCr75FC881rET48ed/JZ/Q7PP7yv40Yn3Cefvag0ZyegsP0aQgN5cOH/H5V/8ZAE4VEIYW/s8SfeZNtQRXCeKMCbYtgnWtVUxS7jPPeUl3YnT4SLVH2s= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3492.eurprd08.prod.outlook.com (20.177.108.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 19:52:18 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 19:52:18 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Meeting info for April 6th Thread-Index: AdYIXmyyFvVJ5IaSQn6eEJftQ3+9BA== Date: Wed, 1 Apr 2020 19:52:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ts-tracking-id: 8f4316d0-28d4-43de-8231-55447a6215df.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.116.70] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2dac7696-5c21-4773-f5f9-08d7d6764151 x-ms-traffictypediagnostic: AM0PR08MB3492:|AM0PR08MB5090: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3968;OLM:6430; x-forefront-prvs: 03607C04F0 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(81156014)(66476007)(66946007)(186003)(66556008)(55016002)(64756008)(66574012)(4744005)(2906002)(316002)(99936003)(66446008)(33656002)(9686003)(7696005)(6506007)(26005)(66616009)(86362001)(76116006)(478600001)(71200400001)(8676002)(6916009)(81166006)(52536014)(966005)(5660300002)(8936002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 0BTU7k+NkwmkwzmYIJNN4ie+FT3buhhirTeujODfX16CqCZ42wtWQjik8xNrczq/P7J98qSiOEOKdPe8DcOKeUvOUA/V+W8RP/B3wwdNrkwj8BujUwf7m/6NPyXO4w6FELWdLGu0EHGxilHzTD/MzvGdcn5LAmY+IRb/SXrChzYh9ACLjyDfEzmcmTeZlZGnsG6pYo8UO4XHPdS4t2jCdZGGZLllX4W/wBO3/o5BYHGLb44B4sYK+IPLdRNfWHHRB2GfP79dok93CvHVL3eR3oK2DtzbnuOSPZouIbpLmuWVY9FwbjzJeMIb83hxGNo7I5MRdPpYmbCZjZBTP9Qf0p90yvl1F/baBUJNtU0ESWqvNXsGYcS/NIolLTx9VV3fI1G+8Yf2oDpEFvNeosMprwPGx4IPKnMEUdXOA6oqgprwcjfzOZIwE+vzu+rnMdQnztA7w1BeS1ojbeXjaQIQSH4/OD1nYjR+n4Nz1A9TvG8qWB+f8gL6rQoRbAGJlOjAaLGQKuaffR+XalrE84jS0A== x-ms-exchange-antispam-messagedata: KNf7wGTGIhVFDx+1MaqN4wx2MwJyYaG5NYRt/sKGnVVTj0Yh6IOKPuL6n646A4J7//kqv2+cse3+MdlK5CWCVNCdRTQrCPXh5+T+rALBxQ4C5TXXb6Xt+xlXcL4Mp/MzusS7gtugjDTAqS2pP53yFg== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3492 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(396003)(39860400002)(376002)(46966005)(8936002)(2906002)(966005)(9686003)(66574012)(33656002)(6506007)(316002)(26826003)(356004)(7696005)(478600001)(47076004)(82740400003)(99936003)(70586007)(186003)(70206006)(336012)(81166006)(26005)(235185007)(55016002)(86362001)(81156014)(66616009)(52536014)(8676002)(6916009)(5660300002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 06fda582-63c0-4eaf-37d3-08d7d6762f7c X-Forefront-PRVS: 03607C04F0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gRooYCq0VfSGicR1xrHO57INNku7cczCBBJG+k52tUh2y49hJ4HHOEQRJ/Fk1MQjSl+CKL4VJ4YKWrjCTSM5uUDSTtn9tyHeQselj+I0+4N4dqfVDncLgtb7+jtEYPVBBXa0hVh0YXHt8phcrl0+xRSQulFJwGitQ7f3Y2fgwKc2j0+EJUbzSmpDH9Fzab5gVEReAFTpkBtaZ8fzn88YSFeg2Cva3ab+14iylsp5nw5aUqeoFz7iwZAgOcc+7gpnEWsSjQTh1FvqqdtiCJaVfeNvoLinMagwuJuI9ZMoEOnAJX/uN4QcNuQ5AXB1DbYONTcXYh2FTunAuazCZ+zJnQ/5TdwMsdu7T6H06NnQ6xNMXZEf9vV55IU0kJQCCMswmQhHJdiBvAIUUe75Ebzm3amiJ7AAS+8ZmcjoVMiKkRAQTKDbbMkbRAtFaHPuZ0yyiZJiB49IUdGZCzt3YWRg0WqX+rqBDjw8CaNmfLHUnc1vLJAbp6wSoKLv9mF1Cqlpy3r+Tcakgi+xwg4sQmMIX/WZ+5Au7t6NjFhDs8vc0cj2/3jhYsF6MgHpTa3yrp4oVz9vsIPATyMuNnOKlbhPOA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2020 19:52:48.6519 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2dac7696-5c21-4773-f5f9-08d7d6764151 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5090 Archived-At: Subject: [OAUTH-WG] Meeting info for April 6th 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, 01 Apr 2020 19:52:55 -0000 --_004_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_ Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_" --_000_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As announced, here is the calendar invite for the virtual interim meeting n= ext Monday. We are going to focus on the following two documents, as previously posted= to the list: 1) OAuth Security Topics https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 Goal: Make it ready for the IESG 2) Browser-Based Apps https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 Goal: Get it ready for WGLC Please read through these two documents. We have a 1 hour timeslot and we w= ant to use our time as efficient as possible. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As announced, here is the calendar invite for the vi= rtual interim meeting next Monday.

 

We are going to focus on the following two documents= , as previously  posted to the list:

 

1) OAuth Security Topics

https://tools.ietf.org/html/draft-ietf-oauth-securi= ty-topics-14

 

Goal: Make it ready for the IESG

 

2) Browser-Based Apps

https://tools.ietf.org/html/draft-ietf-oauth-bro= wser-based-apps-05

 

Goal: Get it ready for WGLC

 

Please read through these two documents. We have a 1= hour timeslot and we want to use our time as efficient as possible.

 

Ciao

Hannes & Rifaat

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_-- --_004_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_ Content-Type: text/calendar; name="OAuth_Webex_Meeting_6April2020.ics" Content-Description: OAuth_Webex_Meeting_6April2020.ics Content-Disposition: attachment; filename="OAuth_Webex_Meeting_6April2020.ics"; size=7580; creation-date="Wed, 01 Apr 2020 19:47:53 GMT"; modification-date="Wed, 01 Apr 2020 19:46:07 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTgxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE4MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iV2ViIEF1dGhvcml6 YXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1G QUxTRTpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iQ2lzY28gV2Vi ZXgiOk1BSUxUTzptZXNzZW5nZXJAd2ViZXguY29tCkRUU1RBUlQ7VFpJRD0iRXVyb3BlIFRpbWUi OjIwMjAwNDA2VDE4MDAwMApEVEVORDtUWklEPSJFdXJvcGUgVGltZSI6MjAyMDA0MDZUMTkwMDAw CkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1mMGI4ZmIx NTY3MGI5MzIxZDdlN2MyNjUwOGFmMTRiMgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE1ODU3NzAz MTIKVUlEOmE1NWU3MTE5LTE4Y2QtNGE5Yy05ODU2LWI0MjYyYzA2MmNmMQpEVFNUQU1QOjIwMjAw NDA2VDE2MDAwMFoKREVTQ1JJUFRJT046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWYwYjhmYjE1NjcwYjkzMjFkN2U3YzI2NTA4 YWYxNGIyXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2MTEgNTQ3IDI3N1xuXG5NZWV0 aW5nIHBhc3N3b3JkOiBhMjRSSlBGUGhWM1xuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAtNDc5 LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKSBcblRhcCBoZXJlIHRvIGNhbGwg KG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxMTU0NzI3NyUyMyUyMyowMSpcblxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIFxuVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxl IHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOjEtODc3LTY2OC00NDkzLCwq MDEqNjExNTQ3Mjc3JTIzJTIzKjAxKlxuXG5HbG9iYWwgY2FsbC1pbiBudW1iZXJzOlxuaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tYTQ1MGRiNThlOWFk YzlmNGE4ZGQzZmFmZWE0NzY3OWFcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBc bmh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5c bkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjExNTQ3 Mjc3QGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2MTE1NDcyNzcuaWV0ZkBs eW5jLndlYmV4LmNvbVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBw b3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hv dWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlv dSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0 L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj4qIHsgICAgcGFkZGluZzogMDsgICAgbWFyZ2lu OiAwO310YWJsZSB7CWJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IHdpZHRoID0xMDAlOwlib3Jk ZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO310ciB7CWxpbmUtaGVpZ2h0OiAxOHB4O31hLCB0ZCB7 CWZvbnQtc2l6ZTogMTRweDsJZm9udC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13 cmFwOiBicmVhay13b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fS50aXRsZSB7 CWZvbnQtc2l6ZTogMjhweDt9LmltYWdlIHsJd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9 LmZvb3RlciB7CXdpZHRoOiA2MDRweDt9Lm1haW4ge31AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRl dmljZS13aWR0aDogODAwcHgpIHsJLnRpdGxlIHsJCWZvbnQtc2l6ZTogMjJweCAhaW1wb3J0YW50 Owl9CS5pbWFnZSB7CQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFp bXBvcnRhbnQ7CX0JLmZvb3RlciB7CQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRo OiA2MDRweCAhaW1wb3J0YW50CX0JLm1haW4gewkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1h eC13aWR0aDogNjA0cHggIWltcG9ydGFudAl9fTwvc3R5bGU+PHRhYmxlIGJnY29sb3I9IiNGRkZG RkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBtYXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7 IiBhbGlnbj0ibGVmdCI+CTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48 L3RyPgk8dHI+CQk8dGQgYWxpZ249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdp bjogMCI+CQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgkJCQk8dHI+CQkJCQk8dGQgYWxpZ249ImNlbnRlciIg dmFsaWduPSJ0b3AiID4mbmJzcDsJCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4tLT4JCQk8 dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhl cmUuPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDog MjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj4JCQkJPHRyPgkJ CQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjExIDU0NyAyNzc8L0ZPTlQ+CQkJCQk8L3Rk PgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZPTlQ+CQkJCQk8L3Rk PgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0 ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5hMjRSSlBGUGhW MzwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4gICAgICAgIDx0YWJsZT4gICAgICAgIAk8dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPgkJCTx0cj4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj4JCQkJ CTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9 IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQy OyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRo OjE2MHB4IWltcG9ydGFudDsiPgkJCQkJCTx0cj4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW1mMGI4ZmIxNTY3MGI5MzIxZDdlN2MyNjUwOGFmMTRiMiIgc3R5bGU9 ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpv aW4gbWVldGluZzwvYT48L3RkPgkJCQkJCTwvdHI+CQkJCQk8L3RhYmxlPgkJCQk8L3RkPgkJCTwv dHI+CQk8L3RhYmxlPiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7 PEJSPiZuYnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiM5OTk5OTkiIEZBQ0U9ImFyaWFsIj5UYXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRl dmljZSAoYXR0ZW5kZWVzIG9ubHkpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgQ09MT1I9IiMzMzMz MzMiIEZBQ0U9IkFyaWFsIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRw eDtjb2xvcjojMzMzMzMzO2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjExNTQ3Mjc3JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwNDlGRDk7 ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgJz4xLTY1MC00NzktMzIwODwvYT4mbmJzcDtDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgQ09MT1I9IiMz MzMzMzMiIEZBQ0U9IkFyaWFsIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTog MTRweDtjb2xvcjojMzMzMzMzO2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVsOjEtODc3 LTY2OC00NDkzLCwqMDEqNjExNTQ3Mjc3JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwNDlGRDk7 ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgJz4xLTg3Ny02NjgtNDQ5MzwvYT4mbmJzcDtDYWxsLWlu IHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW1hNDUwZGI1 OGU5YWRjOWY0YThkZDNmYWZlYTQ3Njc5YSI+PEZPTlQgIENPTE9SPSIjMDQ5RkQ5IiBGQUNFPSJh cmlhbCI+R2xvYmFsIGNhbGwtaW4gbnVtYmVyczwvRk9OVD48L2E+PEZPTlQgU0laRT0iMSIgRkFD RT0iQVJJQUwiPiZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs8L0ZPTlQ+PGEgaHJlZj0iaHR0cHM6 Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48Rk9OVCBTSVpF PSIxIiBDT0xPUj0iIzA0OUZEOSIgRkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3Ry aWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PEJSPjx0YWJsZT48dHIgc3R5bGU9ImxpbmUt aGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwv dGFibGU+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj OTk5OTk5IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0 aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzMzMzMzMyIgRkFDRT0iYXJpYWwi PkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2MTE1NDcyNzdAaWV0Zi53ZWJleC5jb20iPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjMDQ5RkQ5IiBGQUNFPSJhcmlhbCI+NjExNTQ3Mjc3QGlldGYud2Vi ZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIENPTE9SPSIjMzMzMzMzIiBGQUNFPSJh cmlhbCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7Y29sb3I6IzMz MzMzMztsaW5lLWhlaWdodDogMjRweDsiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBh bmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZu YnNwOyA8QlI+Jm5ic3A7IDxCUj48dGFibGU+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAw OyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jv c29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBw eCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNp emU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjYxMTU0NzI3 Ny5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xv cjojMDQ5RkQ5Ij42MTE1NDcyNzcuaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90 YWJsZT4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJt YWluIj4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8 L3RkPjwvdHI+CQkJCTx0cj4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPgkJCQkJPC90ZD4JCQkJPC90cj4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJo ZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CQkJPC90YWJsZT4JCTwvdGQ+CTwvdHI+ PC90YWJsZT4KU1VNTUFSWTpPQXV0aCBWaXJ0dWFsIEludGVyaW0gTWVldGluZwpQUklPUklUWTo1 CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpE RVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_004_AM0PR08MB3716E5354EFB127CC0902B0AFAC90AM0PR08MB3716eurp_-- From nobody Thu Apr 2 07:04:08 2020 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 24BEB3A1413; Thu, 2 Apr 2020 07:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158583623802.26510.6501784119483278282@ietfa.amsl.com> Date: Thu, 02 Apr 2020 07:03:58 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-06 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: Thu, 02 Apr 2020 14:04:02 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-04-06 from 18:00 to 19:00 Europe/Vienna (16:00 to 17:00 UTC). Agenda: Two documents: 1) OAuth Security Topics https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 2) Browser-Based Apps https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7e39bc19240468eafc9b00a0ebc673b0 From nobody Thu Apr 2 23:46:10 2020 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 65CBB3A10C2 for ; Thu, 2 Apr 2020 23:46:08 -0700 (PDT) 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 CUrCcy64OUJs for ; Thu, 2 Apr 2020 23:46:06 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 331943A10BF for ; Thu, 2 Apr 2020 23:46:06 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id c23so3070601pgj.3 for ; Thu, 02 Apr 2020 23:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=8zKNVBtqvHEUjWuKSITB2eqtM6LQnXZsCvcL3IRoAAw=; b=iCZAqem6CaciaJ2YWN/jB5HAwsi5TgGxvNulAWyM2c0bTfWGIthVILy9ZDv4Vd0ypM qavelnf+CBw0ULveCsSM5tqdTr4saBL2puStPdslywmxn8EdxRp+bNjZZCh0uqG0AZVT KYA06tYrsLhPFB/7J6EBvDu1y1ldydGesjkbJ3lEvCxGYs0WpPDmG5ElxfVod0AVGDW1 71jExDvW8D5mZFmQDmzluCimWzLtMGTYrN1GFoF/AZFsr1tJRKNGo8OXrREIjk8urkeA huqLq9mYMlNBpArqx0J1Yg3zis0HP4Uh4LXBepUCRkooE+65pZs41rjobfyPCV7v1Jtx 00EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=8zKNVBtqvHEUjWuKSITB2eqtM6LQnXZsCvcL3IRoAAw=; b=o8509K7Wpup6X3vbWlucH1oNgnGbSHSC1MKL2Kh2wNCNc4PFC9cE+fTDMNpt302k7p s79UcYUG22UadNSXJxRJ9VhpFZ/0ksles544Wj4m6mnJZpytX4/wo8s0DtfdJsvOTgPL 2vmTGdLgHno+/X3L68eVaw/avZbQM+Wr6RJAOPSF2CCsrX4rvj+88KpsebzP5a811XVq YHFInOsLO3nG0SYyZOTO5dj3uFb91qPZLd5tvY1vfRNWleEosRVDAOuLsOTwDQnP+Bhx MLqU2oY6QSC2EjPXqEyaPVU8e/FHEso+Jq1q1lh3xn3ce4wV9kVaHPHxOuJ3KdAqjb84 TY6A== X-Gm-Message-State: AGi0PuZ0Rk4WU50sGtSBfnpANcV1pjQP6QpTasU1WUzTlcg+hueHlleM qBcTzqFVoZgUCYLkGKuFHepcEg== X-Google-Smtp-Source: APiQypKwKGHWOykGY1pTd94qshb6iGuTgRa1MVdMd/pcFbY5ehjZtEW5jfcfKJCOUMj43yjTcW6B1g== X-Received: by 2002:a63:a351:: with SMTP id v17mr6646388pgn.319.1585896365208; Thu, 02 Apr 2020 23:46:05 -0700 (PDT) Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id 1sm5062767pjo.10.2020.04.02.23.46.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 23:46:04 -0700 (PDT) From: Vittorio Bertocci To: Karl McGuinness CC: Aaron Parecki , OAuth WG Thread-Topic: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens Thread-Index: AWc2c3hjpw0LjVgh/3UrGwXW8Y7ysiRkNCRkMUNCNDLa+ORwRA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 3 Apr 2020 06:46:03 +0000 Message-ID: References: <13cbd01d602df$f19f7490$d4de5db0$@auth0.com> <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com> In-Reply-To: <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com> 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_MWHPR19MB150194FA38AD91F0B64D8621AEC70MWHPR19MB1501namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens 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, 03 Apr 2020 06:46:09 -0000 --_000_MWHPR19MB150194FA38AD91F0B64D8621AEC70MWHPR19MB1501namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2FybCwNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIEkgYWdyZWUgdGhhdCBoYXZpbmcgYSBm cmFtZXdvcmsgZm9yIGZ1cnRoZXIgY2xhcmlmeWluZyBhdXRoZW50aWNhdGlvbiBhc3N1cmFuY2Ug d291bGQgYWxsb3cgU0RLIG93bmVyIHRvIHByb3ZpZGUgZXZlbiBtb3JlIGZ1bmN0aW9uYWxpdHkg b3V0IG9mIHRoZSBib3guDQpJIGFsc28gYWdyZWUgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiBzdWNo IGEgZnJhbWV3b3JrIGZvciBhdXRoZW50aWNhdGlvbiBhc3N1cmFuY2UgZ29lcyBiZXlvbmQgdGhl IHNjb3BlIG9mIHRoZSBjdXJyZW50IHByb2ZpbGUuIE5vbmV0aGVsZXNzLCBkZWZpbmluZyBpbiB0 aXMgcHJvZmlsZSB3aGF0IGNsYWltcyBzaG91bGQgYmUgdXNlZCBmb3IgY2FycnkgdGhhdCBpbmZv cm1hdGlvbiBpc27igJl0IHdpdGhvdXQgaW50ZXJvcCB2YWx1ZSwgYXMgaXQgZGlzY291cmFnZXMg dGhlIGludHJvZHVjdGlvbiBvZiBkaWZmZXJlbnQgY2xhaW1zIHRvIGNhcnJ5IHRoYXQgaW5mbyBh bmQgYXQgbGVhc3QgaGVscHMgU0RLcyB0byBpZGVudGlmeSB0aG9zZSBjbGFpbXMgaW4gdGhlIGlu Y29taW5nIHRva2VucyBhbmQgZXhwb3NlIHRoZWlyIHZhbHVlcyB0aGVpciBvYmplY3QgbW9kZWwv ZXZlbnRzIGNvbGxlY3Rpb24sIHNhdmluZyB0aGUgZW5kIGRldmVsb3BlciBhdCBsZWFzdCBzb21l IHdvcms7IGFuZCBpZiBtb3JlIGd1aWRhbmNlIGFib3V0IHRoZSB2YWx1ZXMgb2YgdGhvc2UgY2xh aW1zIHdpbGwgZXZlbnR1YWxseSBlbWVyZ2UsIGl0IHdpbGwgYmUgZWFzaWVyIHRvIGRvdmV0YWls IGZ1cnRoZXIgU0RLIGxvZ2ljIGRvd25zdHJlYW0gdGhhbiBpZiB3ZSB3b3VsZCBoYXZlIGxlZnQg ZXZlbiB0aGUgdHJhbnNwb3J0IGNsYWltcyBlbnRpcmVseSB1bnNwZWNpZmllZC4NClRoYW5rcw0K Vi4NClBTOiBpZiB5b3Ugd2FudCB0byBkcmFmdCBzdWNoIGEgc3BlYywgSSBhbSBzdXJlIHRoZXJl IHdvdWxkIGJlIGludGVyZXN0IGluIHJldmlld2luZyBpdCDwn5iKDQoNCkZyb206IEthcmwgTWNH dWlubmVzcyA8a21jZ3Vpbm5lc3M9NDBva3RhLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IE1v bmRheSwgTWFyY2ggMzAsIDIwMjAgYXQgMDk6MzgNClRvOiAidml0dG9yaW8uYmVydG9jY2k9NDBh dXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+DQpD YzogQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5jb20+LCBPQXV0aCBXRyA8b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBFcnJvciBSZXNwb25zZXMgaW4gSldUIFBy b2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zDQoNCkhpIFZpdHRvcmlvLA0KDQpJIHdh cyBjaGF0dGluZyB3aXRoIEFhcm9uIG9mZmxpbmUgYWJvdXQgdGhpcyBpc3N1ZSBhbmQgbXkgY29u Y2VybiBpcyB0aGUgYWRkaXRpb24gb2YgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb24gQ2xhaW1z IGluIHRoaXMgc3BlYyBvcGVucyB1cCBtb3JlIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHRoYXQg Y2Fu4oCZdCBiZSBhZGRyZXNzZWQgd2l0aCBqdXN0IGEgSldUIEFjY2VzcyBUb2tlbiBzcGVjLg0K DQpPQXV0aCAyLjAgQUZBSUssIGRvZXNu4oCZdCBkZWZpbmUgYW55IGJlaGF2aW9ycyBhcm91bmQg cmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24gYXNzdXJhbmNlIHdpdGggcmVzcGVjdCB0byBp c3N1aW5nLCBpbnRyb3NwZWN0aW5nLCBvciBwcmVzZW50aW5nIGFjY2VzcyB0b2tlbnMuDQoNCiAg KiAgIFRva2VuIGludHJvc3BlY3Rpb24NCiAgKiAgIFRva2VuIHZhbGlkYXRpb24gZXJyb3IgcmVz cG9uc2VzDQogICogICBUb2tlbiByZWZyZXNoDQogICogICBDbGllbnQgUmVtZWRpYXRpb24gKG9p ZGMgZGVmaW5lZCBwcm9tcHQ9bG9naW4sIG1heF9hZ2UsIGFuZCBhY3JfdmFsdWVzKQ0KICAqICAg TWV0YWRhdGENClRoaXMgc3BlYyBpcyBkZWZpbmluZyBBUyBiZWhhdmlvcnMgdGhhdCBhcmUgb3J0 aG9nb25hbCB0byB0aGUgZm9ybWF0IGFuZCBzaG91bGQgYmUgYXZhaWxhYmxlIHZpYSB0b2tlbiBp bnRyb3NwZWN0aW9uIGZvciBleGFtcGxlDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDQjc2VjdGlvbi0yLjIuMQ0KDQoNClRo ZSBjbGFpbXMgbGlzdGVkIGluIHRoaXMgc2VjdGlvbiByZWZsZWN0IGluIHRoZSBhY2Nlc3MgdG9r ZW4gdGhlIHRoZQ0KDQogICB0eXBlcyBhbmQgc3RyZW5ndGggb2YgYXV0aGVudGljYXRpb24gdGhh dCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyDQoNCiAgIGVuZm9yY2VkIHByaW9yIHRvIHJldHVy bmluZyB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSB0byB0aGUgY2xpZW50Lg0KDQogICBUaGVp ciB2YWx1ZXMgYXJlIGZpeGVkLCBhbmQgcmVtYWluIHRoZSBzYW1lIGFjcm9zcyBhbGwgYWNjZXNz IHRva2Vucw0KDQogICB0aGF0IGRlcml2ZSBmcm9tIGEgZ2l2ZW4gYXV0aG9yaXphdGlvbiByZXNw b25zZSwgd2hldGhlciB0aGUgYWNjZXNzDQoNCiAgIHRva2VuIHdhcyBvYnRhaW5lZCBkaXJlY3Rs eSBpbiB0aGUgcmVzcG9uc2UgKGUuZy4sIHZpYSB0aGUgaW1wbGljaXQNCg0KICAgZmxvdykgb3Ig YWZ0ZXIgb25lIG9yIG1vcmUgdG9rZW4gZXhjaGFuZ2VzIChlLmcuLCBvYnRhaW5pbmcgYSBmcmVz aA0KDQogICBhY2Nlc3MgdG9rZW4gdXNpbmcgYSByZWZyZXNoIHRva2VuLCBvciBleGNoYW5naW5n IG9uZSBhY2Nlc3MgdG9rZW4NCg0KICAgZm9yIGFub3RoZXIgdmlhIFtSRkM4NjkzPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjkzPl0pLg0KDQoNCkkgd2FzIGhvcGluZyBvbmUgb2Yg dGhlIG91dGNvbWVzIG9mIHRoaXMgc3BlYyB3YXMgdG9vbGtpdC9zZGsgaW50ZXJvcCBmb3IgY2xp ZW50cyBhbmQgcmVzb3VyY2Ugc2VydmVycy4gICBJIGRvbuKAmXQgc2VlIGhvdyB0aGlzIHBvc3Np YmxlIGlmIGFsbCB0aGUgc2VtYW50aWNzIGFyb3VuZCByZXF1ZXN0aW5nLCB2YWxpZGF0aW5nLCBh bmQgcmVtZWRpYXRpbmcgcmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24gYXNzdXJhbmNlIGlz IGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiAgIFRoZSBlbmQtdG8tZW5kIHNjZW5hcmlvcyBhcmUg bm90IGFjaGlldmFibGUgd2l0aCBqdXN0IE9BdXRoIDIuMCB3aGljaCBicmVha3MgaW50ZXJvcC4N Cg0KSSB0aGluayB0aGVyZSBpcyBhIHJlYWwgbmVlZCB0byBkZWZpbmUgcmVzb3VyY2Ugb3duZXIg YXV0aGVudGljYXRpb24gYXNzdXJhbmNlIGludGVyb3BlcmFiaWxpdHkgZm9yIGFjY2VzcyB0b2tl bnMsIGJ1dCBJIGZlYXIgdGhpcyBtYXkgcmVxdWlyZSBpdHMgb3duIHNwZWMuDQoNCi1LYXJsDQoN CkthcmwgTWNHdWlubmVzcw0KQ2hpZWYgUHJvZHVjdCBBcmNoaXRlY3QNCnd3dy5va3RhLmNvbTxo dHRwOi8vd3d3Lm9rdGEuY29tLz4NCg0KDQpPbiBNYXIgMjUsIDIwMjAsIGF0IDEyOjU5IFBNLCB2 aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86dml0dG9y aW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQpUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlZCBvdXRzaWRlIHlvdXIgb3JnYW5pemF0aW9uLg0KDQpUaGFua3MgQWFy b24hDQpZb3UgYXJlIHJpZ2h0LCB3ZSBjb3VsZCBiZSBjbGVhcmVyIHJlOmVycm9ycy4gQUZBSUsg dGhlIG9ubHkgZXJyb3JzIHdlIGNhbg0KcmVseSBvbiBmcm9tIGFuIFJTIGFyZSBpbiBSRkM2NzUw LCBhbmQgdGhlIGVudGlyZSBzZWN0aW9uIGlzIGFib3V0IHdoYXQgdG8NCmxvb2sgZm9yIGluIGFu IGluY29taW5nIEFUIHRvIHZhbGlkYXRlLCBoZW5jZSBpdCBkb2Vzbid0IGxvb2sgbGlrZSB3ZSBo YXZlDQptdWNoIGNob2ljZSBidXQgdG8gcmV0dXJuIGludmFsaWRfdG9rZW4gZm9yIGV2ZXJ5IGVy cm9yIGluIHRoZSB2YWxpZGF0aW9uDQpjaGVja3MgZW51bWVyYXRlZCBpbiBTZWN0aW9uIDQuIEkg Y2FuIGRlZmluaXRlbHkgYWRkIGEgcGFyYWdyYXBoIHRvIHRoYXQNCmVmZmVjdCAoZG9lcyBpdCBo YXZlIHRvIGJlIGEgc2VjdGlvbj8pLg0KDQpUaGUgcmUtYXV0aGVudGljYXRpb24gcGFydCBpcyB0 cmlja3kuIFRlY2huaWNhbGx5IHdlIGFyZSBzdGlsbCByZWplY3RpbmcgdGhlDQppbmNvbWluZyB0 b2tlbiwgaGVuY2UgdGhlIGFib3ZlIHNob3VsZCBzdGlsbCBhcHBseS4NCkkgYW0gbm90IGF3YXJl IG9mIHRvb2xzIHdlIGNhbiB1c2UgZnJvbSB0aGUgcHJpbWl0aXZlcyBkZWZpbmVkIGluIHRoZSBP QXV0aDINCmZhbWlseSBvZiBzdGFuZGFyZHMgZm9yIHRlbGxpbmcgcGVvcGxlIGhvdyB0byBtYWtl IHJlYXV0aGVudGljYXRpb24gaGFwcGVuLQ0KYW5kIG1ha2luZyByZWF1dGggaGFwcGVuIGNhbiBi ZSBxdWl0ZSBpbnZvbHZlZC4gSW4gQXp1cmUgQUQgdGhlcmUgYXJlIHNlbWkNCnByb3ByaWV0YXJ5 IG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUgdXNlZCB0byBzaWduYWwgdGhlIG5lZWQgdG8gcmVwZWF0 DQphdXRoZW50aWNhdGlvbiwgc2F5IGZvciB0cmlnZ2VyaW5nIGEgc3RlcC11cCBhdXRoLCBieSBz ZW5kaW5nIGJhY2sgdG9nZXRoZXINCndpdGggdGhlIGVycm9yIHJlc3BvbnNlIGEgY2hhbGxlbmdl IHRoYXQgY2FuIGluIHR1cm4gYmUgdXNlZCBieSB0aGUgY2xpZW50DQp0byBjb21tdW5pY2F0ZSBw b2xpY3kgcmVxdWlyZW1lbnRzIHRvIHRoZSBBUyAod2hpY2ggaXMgYXNzdW1lZCB0byBzdXBwb3J0 DQpPSURDIGFuZCBhY2NlcHQvdW5kZXJzdGFuZCB0aG9zZSBwb2xpY2llcyBpbiBmb3JtIG9mIGNs YWltKS4gR2l2aW5nDQplcXVpdmFsZW50IGd1aWRhbmNlIGJ1dCByZWx5aW5nIG9ubHkgb24gc3Rh bmRhcmRzIHNlZW1zIHRyaWNreSwgZXNwZWNpYWxseQ0Kd2l0aG91dCBtYWtpbmcgc3Ryb25nIGFz c3VtcHRpb25zIGFib3V0IGhvdyBhdXRoIGhhcHBlbnMgKGUuZyBjYW4gd2UgYXNzdW1lDQpPSURD PykuDQpUbyBzb2x2ZSB0aGlzIGZvciB0aGUgcHJvZmlsZSwgSSBzZWUgdHdvIG1haW4gd2F5cyBm b3J3YXJkOg0KQSkgV2Ugd2FybiB0aGUgcmVhZGVyIHRoYXQgaXQncyBvbiB0aGVtIHRvIGRlY2lk ZSBob3cgdG8gc2lnbmFsIHRoZSByZWF1dGgNCnJlcXVpcmVtZW50IGZyb20gdGhlIEFQSSB0byB0 aGUgY2xpZW50LCBhbmQgaG93IHRvIHVzZSB0aGF0IGluIHRoZSBjbGllbnQgdG8NCkFTIHN1YnNl cXVlbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0DQpCKSBXZSB2ZW50dXJlIGluIGRldmlzaW5nIGEg c3RhbmRhcmQgbWVjaGFuaXNtIGZvciBwcm9wYWdhdGluZyBlcnJvcnMgdGhhdA0KcmVxdWlyZSBy ZWF1dGgsIGJhc2ljYWxseSBleHRlbmRpbmcgUkZDNjc1MCB3aXRoIGEgbmV3IHVzZSBjYXNlIChw ZXJoYXBzIGJ5DQpkZXRhaWxpbmcgZXh0cmEgaW5mbyB0byBiZSBwdXQgaW4gV1dXLUF1dGhlbnRp Y2F0ZT8pLg0KDQpJIGNhbiBzZWUgaG93IEIpIG1pZ2h0IGJlIHVzZWZ1bCBpbiBnZW5lcmFsLCBi dXQgaXQgZG9lc24ndCBzZWVtDQpwYXJ0aWN1bGFybHkgdGllZCB0byB0aGUgZmFjdCB0aGF0IHRo ZSBBVHMgYmVpbmcgZGlzY3Vzc2VkIGhlcmUgYXJlIEpXVHMuLi4NCmhlbmNlIEknZCBiZSBpbmNs aW5lZCB0byBkZWNsYXJlIGl0IG91dCBvZiBzY29wZSBoZXJlLCB0aG8gSSB3b3VsZCByZWFsbHkN CmxvdmUgZm9yIHVzIHRvIGRldmlzZSBhIHN0YW5kYXJkIHNvbHV0aW9uIGZvciBpdCBfc29tZXdo ZXJlXy4NCldEWVQ/DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1 dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ PiBPbiBCZWhhbGYgT2YgQWFyb24gUGFyZWNraQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNSwg MjAyMCAxMjowNyBQTQ0KVG86IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+Pg0KU3ViamVjdDogW09BVVRILVdHXSBFcnJvciBSZXNwb25zZXMgaW4gSldUIFBy b2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MNClRva2Vucw0KDQpTZWN0aW9uIDQgdGFsa3MgYWJv dXQgdmFsaWRhdGluZyBKV1QgQWNjZXNzIFRva2Vucw0KDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA0I3NlY3Rpb24tNA0KDQpJ dCBoYXMgYSBsaXN0IG9mIHRoaW5ncyB0aGUgUlMgTVVTVCBkbyB3aGVuIHZhbGlkYXRpbmcgYSBy ZXF1ZXN0IG1hZGUgd2l0aCBhDQpKV1QgYWNjZXNzIHRva2VuLiBUaGlzIHNlY3Rpb24gY29udGFp bnMgcGhyYXNlcyBsaWtlICIuLi5hbmQgcmVqZWN0DQp0b2tlbnMuLi4iIGFuZCAiTVVTVCBiZSBy ZWplY3RlZCBpZi4uLiIsIHdpdGhvdXQgY2xlYXIgaW5zdHJ1Y3Rpb25zIG9uICpob3cqDQp0byBy ZWplY3QgdGhpcyByZXF1ZXN0LiBGb3IgdGhlc2UsIEkgY291bGQgaW5mZXIgdGhhdCB0aGUgUkZD Njc1MCBlcnJvciBjb2RlDQoiaW52YWxpZF90b2tlbiIgaXMgdGhlIGNvcnJlY3QgcmVzcG9uc2Us IGJ1dCB0aGVzZSBjb3VsZCBiZW5lZml0IGZyb20gYmVpbmcNCm1vcmUgZXhwbGljaXQgYWJvdXQg dGhhdCBoZXJlLg0KDQpTdGVwIDcgc2F5czogICJ0aGUgcmVzb3VyY2Ugc2VydmVyIFNIT1VMRCBj aGVjayB0aGUgYXV0aF90aW1lIHZhbHVlIGFuZA0KcmVxdWVzdCByZS1hdXRoZW50aWNhdGlvbi4u LiIgQnV0IHRoZXJlIGFyZSBubyBpbnN0cnVjdGlvbnMgb24gaG93IHRoZSBSUw0Kc2hvdWxkIHJl c3BvbmQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgY2xpZW50IHNob3VsZCByZXF1ZXN0IHJlLWF1dGhl bnRpY2F0aW9uLg0KVGhpcyBzb3VuZHMgbGlrZSBhIGRpZmZlcmVudCByZXNwb25zZSB0aGFuICJp bnZhbGlkX3Rva2VuIiB0byBtZSwgYnV0IGluIGFueQ0KY2FzZSwgcmVnYXJkbGVzcyBvZiB3aGF0 IHRoZSBjb3JyZWN0IHJlc3BvbnNlIGlzLCBTZWN0aW9uIDQgcmVhbGx5IG5lZWRzIGENCmRlc2Ny aXB0aW9uIG9mIGhvdyB0byByZXNwb25kIGluIHRoZXNlIGVycm9yIGNhc2VzLg0KDQotLS0tDQpB YXJvbiBQYXJlY2tpDQphYXJvbnBhcmVja2kuY29tDQpAYWFyb25waw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP QXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K --_000_MWHPR19MB150194FA38AD91F0B64D8621AEC70MWHPR19MB1501namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEzNzk2MjY0NzE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM4MTY4NjczNDt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBLYXJsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIGZvciB0aGUgY29tbWVudC4gSSBhZ3JlZSB0aGF0IGhhdmluZyBhIGZyYW1l d29yayBmb3IgZnVydGhlciBjbGFyaWZ5aW5nIGF1dGhlbnRpY2F0aW9uIGFzc3VyYW5jZSB3b3Vs ZCBhbGxvdyBTREsgb3duZXIgdG8gcHJvdmlkZSBldmVuIG1vcmUgZnVuY3Rpb25hbGl0eSBvdXQg b2YgdGhlIGJveC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBh Z3JlZSB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIHN1Y2ggYSBmcmFtZXdvcmsgZm9yIGF1dGhlbnRp Y2F0aW9uIGFzc3VyYW5jZSBnb2VzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIGN1cnJlbnQgcHJv ZmlsZS4gTm9uZXRoZWxlc3MsIGRlZmluaW5nIGluIHRpcyBwcm9maWxlIHdoYXQgY2xhaW1zIHNo b3VsZCBiZSB1c2VkIGZvciBjYXJyeSB0aGF0IGluZm9ybWF0aW9uIGlzbuKAmXQgd2l0aG91dCBp bnRlcm9wDQogdmFsdWUsIGFzIGl0IGRpc2NvdXJhZ2VzIHRoZSBpbnRyb2R1Y3Rpb24gb2YgZGlm ZmVyZW50IGNsYWltcyB0byBjYXJyeSB0aGF0IGluZm8gYW5kIGF0IGxlYXN0IGhlbHBzIFNES3Mg dG8gaWRlbnRpZnkgdGhvc2UgY2xhaW1zIGluIHRoZSBpbmNvbWluZyB0b2tlbnMgYW5kIGV4cG9z ZSB0aGVpciB2YWx1ZXMgdGhlaXIgb2JqZWN0IG1vZGVsL2V2ZW50cyBjb2xsZWN0aW9uLCBzYXZp bmcgdGhlIGVuZCBkZXZlbG9wZXIgYXQgbGVhc3Qgc29tZSB3b3JrOw0KIGFuZCBpZiBtb3JlIGd1 aWRhbmNlIGFib3V0IHRoZSB2YWx1ZXMgb2YgdGhvc2UgY2xhaW1zIHdpbGwgZXZlbnR1YWxseSBl bWVyZ2UsIGl0IHdpbGwgYmUgZWFzaWVyIHRvIGRvdmV0YWlsIGZ1cnRoZXIgU0RLIGxvZ2ljIGRv d25zdHJlYW0gdGhhbiBpZiB3ZSB3b3VsZCBoYXZlIGxlZnQgZXZlbiB0aGUgdHJhbnNwb3J0IGNs YWltcyBlbnRpcmVseSB1bnNwZWNpZmllZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Vi4gJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QUzogaWYgeW91 IHdhbnQgdG8gZHJhZnQgc3VjaCBhIHNwZWMsIEkgYW0gc3VyZSB0aGVyZSB3b3VsZCBiZSBpbnRl cmVzdCBpbiByZXZpZXdpbmcgaXQNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBs ZSBDb2xvciBFbW9qaSZxdW90OyI+JiMxMjg1MjI7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+S2FybCBNY0d1aW5uZXNzICZsdDtrbWNndWlubmVzcz00 MG9rdGEuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1h cmNoIDMwLCAyMDIwIGF0IDA5OjM4PGJyPg0KPGI+VG86IDwvYj4mcXVvdDt2aXR0b3Jpby5iZXJ0 b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyZxdW90OyAmbHQ7dml0dG9yaW8uYmVydG9j Y2lAYXV0aDAuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+QWFyb24gUGFyZWNraSAmbHQ7YWFyb25A cGFyZWNraS5jb20mZ3Q7LCBPQXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIEVycm9yIFJlc3BvbnNlcyBpbiBKV1QgUHJvZmls ZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVml0dG9yaW8sIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgY2hhdHRpbmcgd2l0aCBBYXJvbiBv ZmZsaW5lIGFib3V0IHRoaXMgaXNzdWUgYW5kIG15IGNvbmNlcm4gaXMgdGhlIGFkZGl0aW9uIG9m IEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9uIENsYWltcyBpbiB0aGlzIHNwZWMgb3BlbnMgdXAg bW9yZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB0aGF0IGNhbuKAmXQgYmUgYWRkcmVzc2VkIHdp dGgganVzdCBhIEpXVCBBY2Nlc3MgVG9rZW4gc3BlYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0F1dGggMi4wIEFGQUlLLCBkb2VzbuKAmXQg ZGVmaW5lIGFueSBiZWhhdmlvcnMgYXJvdW5kIHJlc291cmNlIG93bmVyIGF1dGhlbnRpY2F0aW9u IGFzc3VyYW5jZSB3aXRoIHJlc3BlY3QgdG8gaXNzdWluZywgaW50cm9zcGVjdGluZywgb3IgcHJl c2VudGluZyBhY2Nlc3MgdG9rZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQpUb2tlbiBpbnRyb3NwZWN0aW9uPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVG9rZW4gdmFsaWRhdGlv biBlcnJvciByZXNwb25zZXM8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUb2tlbiByZWZyZXNoPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQ2xpZW50IFJl bWVkaWF0aW9uIChvaWRjIGRlZmluZWQgcHJvbXB0PWxvZ2luLCBtYXhfYWdlLCBhbmQgYWNyX3Zh bHVlcyk8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQpNZXRhZGF0YTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc3BlYyBpcyBkZWZpbmluZyBBUyBi ZWhhdmlvcnMgdGhhdCBhcmUgb3J0aG9nb25hbCB0byB0aGUgZm9ybWF0IGFuZCBzaG91bGQgYmUg YXZhaWxhYmxlIHZpYSB0b2tlbiBpbnRyb3NwZWN0aW9uIGZvciBleGFtcGxlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3Qt MDQjc2VjdGlvbi0yLjIuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNCNzZWN0aW9uLTIuMi4xPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZTtmb250LXZh cmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtvcnBoYW5zOjI7d2lkb3dzOjIiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+VGhlIGNsYWltcyBsaXN0ZWQgaW4gdGhpcyBzZWN0aW9uIHJlZmxlY3QgaW4g dGhlIGFjY2VzcyB0b2tlbiB0aGUgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHR5cGVzIGFuZCBzdHJlbmd0aCBv ZiBhdXRoZW50aWNhdGlvbiB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgZW5mb3JjZWQgcHJpb3IgdG8gcmV0dXJuaW5nIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNl IHRvIHRoZSBjbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZWlyIHZhbHVlcyBhcmUgZml4ZWQsIGFuZCBy ZW1haW4gdGhlIHNhbWUgYWNyb3NzIGFsbCBhY2Nlc3MgdG9rZW5zPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoYXQg ZGVyaXZlIGZyb20gYSBnaXZlbiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB3aGV0aGVyIHRoZSBh Y2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgdG9rZW4gd2FzIG9idGFpbmVkIGRpcmVjdGx5IGluIHRoZSByZXNw b25zZSAoZS5nLiwgdmlhIHRoZSBpbXBsaWNpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBmbG93KSBvciBhZnRlciBv bmUgb3IgbW9yZSB0b2tlbiBleGNoYW5nZXMgKGUuZy4sIG9idGFpbmluZyBhIGZyZXNoPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGFjY2VzcyB0b2tlbiB1c2luZyBhIHJlZnJlc2ggdG9rZW4sIG9yIGV4Y2hhbmdpbmcg b25lIGFjY2VzcyB0b2tlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBmb3IgYW5vdGhlciB2aWEgWzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NjkzIiB0aXRsZT0iJnF1b3Q7T0F1dGggMi4w IFRva2VuIEV4Y2hhbmdlJnF1b3Q7Ij5SRkM4NjkzPC9hPl0pLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIGhvcGlu ZyBvbmUgb2YgdGhlIG91dGNvbWVzIG9mIHRoaXMgc3BlYyB3YXMgdG9vbGtpdC9zZGsgaW50ZXJv cCBmb3IgY2xpZW50cyBhbmQgcmVzb3VyY2Ugc2VydmVycy4gJm5ic3A7IEkgZG9u4oCZdCBzZWUg aG93IHRoaXMgcG9zc2libGUgaWYgYWxsIHRoZSBzZW1hbnRpY3MgYXJvdW5kIHJlcXVlc3Rpbmcs IHZhbGlkYXRpbmcsIGFuZCByZW1lZGlhdGluZyByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlv biBhc3N1cmFuY2UNCiBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gJm5ic3A7IFRoZSBlbmQt dG8tZW5kIHNjZW5hcmlvcyBhcmUgbm90IGFjaGlldmFibGUgd2l0aCBqdXN0IE9BdXRoIDIuMCB3 aGljaCBicmVha3MgaW50ZXJvcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGVyZSBpcyBhIHJlYWwgbmVlZCB0byBkZWZpbmUg cmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24gYXNzdXJhbmNlIGludGVyb3BlcmFiaWxpdHkg Zm9yIGFjY2VzcyB0b2tlbnMsIGJ1dCBJIGZlYXIgdGhpcyBtYXkgcmVxdWlyZSBpdHMgb3duIHNw ZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1LYXJsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkthcmwgTWNHdWlubmVzczwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij5DaGllZiBQcm9kdWN0IEFyY2hpdGVjdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cDov L3d3dy5va3RhLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVD QyI+d3d3Lm9rdGEuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTAw MDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyNSwgMjAyMCwgYXQgMTI6 NTkgUE0sIDxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFy Yy5pZXRmLm9yZyI+DQp2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVkIG91 dHNpZGUgeW91ciBvcmdhbml6YXRpb24uPGJyPg0KPGJyPg0KVGhhbmtzIEFhcm9uITxicj4NCllv dSBhcmUgcmlnaHQsIHdlIGNvdWxkIGJlIGNsZWFyZXIgcmU6ZXJyb3JzLiBBRkFJSyB0aGUgb25s eSBlcnJvcnMgd2UgY2FuPGJyPg0KcmVseSBvbiBmcm9tIGFuIFJTIGFyZSBpbiBSRkM2NzUwLCBh bmQgdGhlIGVudGlyZSBzZWN0aW9uIGlzIGFib3V0IHdoYXQgdG88YnI+DQpsb29rIGZvciBpbiBh biBpbmNvbWluZyBBVCB0byB2YWxpZGF0ZSwgaGVuY2UgaXQgZG9lc24ndCBsb29rIGxpa2Ugd2Ug aGF2ZTxicj4NCm11Y2ggY2hvaWNlIGJ1dCB0byByZXR1cm4gaW52YWxpZF90b2tlbiBmb3IgZXZl cnkgZXJyb3IgaW4gdGhlIHZhbGlkYXRpb248YnI+DQpjaGVja3MgZW51bWVyYXRlZCBpbiBTZWN0 aW9uIDQuIEkgY2FuIGRlZmluaXRlbHkgYWRkIGEgcGFyYWdyYXBoIHRvIHRoYXQ8YnI+DQplZmZl Y3QgKGRvZXMgaXQgaGF2ZSB0byBiZSBhIHNlY3Rpb24/KS48YnI+DQo8YnI+DQpUaGUgcmUtYXV0 aGVudGljYXRpb24gcGFydCBpcyB0cmlja3kuIFRlY2huaWNhbGx5IHdlIGFyZSBzdGlsbCByZWpl Y3RpbmcgdGhlPGJyPg0KaW5jb21pbmcgdG9rZW4sIGhlbmNlIHRoZSBhYm92ZSBzaG91bGQgc3Rp bGwgYXBwbHkuPGJyPg0KSSBhbSBub3QgYXdhcmUgb2YgdG9vbHMgd2UgY2FuIHVzZSBmcm9tIHRo ZSBwcmltaXRpdmVzIGRlZmluZWQgaW4gdGhlIE9BdXRoMjxicj4NCmZhbWlseSBvZiBzdGFuZGFy ZHMgZm9yIHRlbGxpbmcgcGVvcGxlIGhvdyB0byBtYWtlIHJlYXV0aGVudGljYXRpb24gaGFwcGVu LTxicj4NCmFuZCBtYWtpbmcgcmVhdXRoIGhhcHBlbiBjYW4gYmUgcXVpdGUgaW52b2x2ZWQuIElu IEF6dXJlIEFEIHRoZXJlIGFyZSBzZW1pPGJyPg0KcHJvcHJpZXRhcnkgbWVjaGFuaXNtcyB0aGF0 IGNhbiBiZSB1c2VkIHRvIHNpZ25hbCB0aGUgbmVlZCB0byByZXBlYXQ8YnI+DQphdXRoZW50aWNh dGlvbiwgc2F5IGZvciB0cmlnZ2VyaW5nIGEgc3RlcC11cCBhdXRoLCBieSBzZW5kaW5nIGJhY2sg dG9nZXRoZXI8YnI+DQp3aXRoIHRoZSBlcnJvciByZXNwb25zZSBhIGNoYWxsZW5nZSB0aGF0IGNh biBpbiB0dXJuIGJlIHVzZWQgYnkgdGhlIGNsaWVudDxicj4NCnRvIGNvbW11bmljYXRlIHBvbGlj eSByZXF1aXJlbWVudHMgdG8gdGhlIEFTICh3aGljaCBpcyBhc3N1bWVkIHRvIHN1cHBvcnQ8YnI+ DQpPSURDIGFuZCBhY2NlcHQvdW5kZXJzdGFuZCB0aG9zZSBwb2xpY2llcyBpbiBmb3JtIG9mIGNs YWltKS4gR2l2aW5nPGJyPg0KZXF1aXZhbGVudCBndWlkYW5jZSBidXQgcmVseWluZyBvbmx5IG9u IHN0YW5kYXJkcyBzZWVtcyB0cmlja3ksIGVzcGVjaWFsbHk8YnI+DQp3aXRob3V0IG1ha2luZyBz dHJvbmcgYXNzdW1wdGlvbnMgYWJvdXQgaG93IGF1dGggaGFwcGVucyAoZS5nIGNhbiB3ZSBhc3N1 bWU8YnI+DQpPSURDPykuPGJyPg0KVG8gc29sdmUgdGhpcyBmb3IgdGhlIHByb2ZpbGUsIEkgc2Vl IHR3byBtYWluIHdheXMgZm9yd2FyZDo8YnI+DQpBKSBXZSB3YXJuIHRoZSByZWFkZXIgdGhhdCBp dCdzIG9uIHRoZW0gdG8gZGVjaWRlIGhvdyB0byBzaWduYWwgdGhlIHJlYXV0aDxicj4NCnJlcXVp cmVtZW50IGZyb20gdGhlIEFQSSB0byB0aGUgY2xpZW50LCBhbmQgaG93IHRvIHVzZSB0aGF0IGlu IHRoZSBjbGllbnQgdG88YnI+DQpBUyBzdWJzZXF1ZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdDxi cj4NCkIpIFdlIHZlbnR1cmUgaW4gZGV2aXNpbmcgYSBzdGFuZGFyZCBtZWNoYW5pc20gZm9yIHBy b3BhZ2F0aW5nIGVycm9ycyB0aGF0PGJyPg0KcmVxdWlyZSByZWF1dGgsIGJhc2ljYWxseSBleHRl bmRpbmcgUkZDNjc1MCB3aXRoIGEgbmV3IHVzZSBjYXNlIChwZXJoYXBzIGJ5PGJyPg0KZGV0YWls aW5nIGV4dHJhIGluZm8gdG8gYmUgcHV0IGluIFdXVy1BdXRoZW50aWNhdGU/KS48YnI+DQo8YnI+ DQpJIGNhbiBzZWUgaG93IEIpIG1pZ2h0IGJlIHVzZWZ1bCBpbiBnZW5lcmFsLCBidXQgaXQgZG9l c24ndCBzZWVtPGJyPg0KcGFydGljdWxhcmx5IHRpZWQgdG8gdGhlIGZhY3QgdGhhdCB0aGUgQVRz IGJlaW5nIGRpc2N1c3NlZCBoZXJlIGFyZSBKV1RzLi4uPGJyPg0KaGVuY2UgSSdkIGJlIGluY2xp bmVkIHRvIGRlY2xhcmUgaXQgb3V0IG9mIHNjb3BlIGhlcmUsIHRobyBJIHdvdWxkIHJlYWxseTxi cj4NCmxvdmUgZm9yIHVzIHRvIGRldmlzZSBhIHN0YW5kYXJkIHNvbHV0aW9uIGZvciBpdCBfc29t ZXdoZXJlXy48YnI+DQpXRFlUPzxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxm IE9mIEFhcm9uIFBhcmVja2k8YnI+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI1LCAyMDIwIDEy OjA3IFBNPGJyPg0KVG86IE9BdXRoIFdHICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEVycm9y IFJlc3BvbnNlcyBpbiBKV1QgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2Vzczxicj4NClRva2Vu czxicj4NCjxicj4NClNlY3Rpb24gNCB0YWxrcyBhYm91dCB2YWxpZGF0aW5nIEpXVCBBY2Nlc3Mg VG9rZW5zPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNCNzZWN0aW9uLTQiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDQjc2Vj dGlvbi00PC9hPjxicj4NCjxicj4NCkl0IGhhcyBhIGxpc3Qgb2YgdGhpbmdzIHRoZSBSUyBNVVNU IGRvIHdoZW4gdmFsaWRhdGluZyBhIHJlcXVlc3QgbWFkZSB3aXRoIGE8YnI+DQpKV1QgYWNjZXNz IHRva2VuLiBUaGlzIHNlY3Rpb24gY29udGFpbnMgcGhyYXNlcyBsaWtlICZxdW90Oy4uLmFuZCBy ZWplY3Q8YnI+DQp0b2tlbnMuLi4mcXVvdDsgYW5kICZxdW90O01VU1QgYmUgcmVqZWN0ZWQgaWYu Li4mcXVvdDssIHdpdGhvdXQgY2xlYXIgaW5zdHJ1Y3Rpb25zIG9uICpob3cqPGJyPg0KdG8gcmVq ZWN0IHRoaXMgcmVxdWVzdC4gRm9yIHRoZXNlLCBJIGNvdWxkIGluZmVyIHRoYXQgdGhlIFJGQzY3 NTAgZXJyb3IgY29kZTxicj4NCiZxdW90O2ludmFsaWRfdG9rZW4mcXVvdDsgaXMgdGhlIGNvcnJl Y3QgcmVzcG9uc2UsIGJ1dCB0aGVzZSBjb3VsZCBiZW5lZml0IGZyb20gYmVpbmc8YnI+DQptb3Jl IGV4cGxpY2l0IGFib3V0IHRoYXQgaGVyZS48YnI+DQo8YnI+DQpTdGVwIDcgc2F5czogJm5ic3A7 JnF1b3Q7dGhlIHJlc291cmNlIHNlcnZlciBTSE9VTEQgY2hlY2sgdGhlIGF1dGhfdGltZSB2YWx1 ZSBhbmQ8YnI+DQpyZXF1ZXN0IHJlLWF1dGhlbnRpY2F0aW9uLi4uJnF1b3Q7IEJ1dCB0aGVyZSBh cmUgbm8gaW5zdHJ1Y3Rpb25zIG9uIGhvdyB0aGUgUlM8YnI+DQpzaG91bGQgcmVzcG9uZCB0byBp bmRpY2F0ZSB0aGF0IHRoZSBjbGllbnQgc2hvdWxkIHJlcXVlc3QgcmUtYXV0aGVudGljYXRpb24u PGJyPg0KVGhpcyBzb3VuZHMgbGlrZSBhIGRpZmZlcmVudCByZXNwb25zZSB0aGFuICZxdW90O2lu dmFsaWRfdG9rZW4mcXVvdDsgdG8gbWUsIGJ1dCBpbiBhbnk8YnI+DQpjYXNlLCByZWdhcmRsZXNz IG9mIHdoYXQgdGhlIGNvcnJlY3QgcmVzcG9uc2UgaXMsIFNlY3Rpb24gNCByZWFsbHkgbmVlZHMg YTxicj4NCmRlc2NyaXB0aW9uIG9mIGhvdyB0byByZXNwb25kIGluIHRoZXNlIGVycm9yIGNhc2Vz Ljxicj4NCjxicj4NCi0tLS08YnI+DQpBYXJvbiBQYXJlY2tpPGJyPg0KYWFyb25wYXJlY2tpLmNv bTxicj4NCkBhYXJvbnBrPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQpPQXV0aEBpZXRm Lm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQpPQXV0aEBpZXRmLm9yZzxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MWHPR19MB150194FA38AD91F0B64D8621AEC70MWHPR19MB1501namp_-- From nobody Fri Apr 3 02:03:24 2020 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 9D7EF3A1531 for ; Fri, 3 Apr 2020 02:03:23 -0700 (PDT) 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 GR9za5Rqd5ck for ; Fri, 3 Apr 2020 02:03:18 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 4422C3A152E for ; Fri, 3 Apr 2020 02:03:18 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id w3so2467455plz.5 for ; Fri, 03 Apr 2020 02:03:18 -0700 (PDT) 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 :mime-version; bh=RVVJcJ754cbvyn8flUfLqwl3cY8aA5YmMfN9Q5ddgKI=; b=YBX2sMqOsCB+B4r+75qoB/Q05c32ivdOncD+zioaXd3EglYWEEfkYt5BPWkKOb9Ivh z5MqM3Aij3J1PRdIXWeBnAcJ1wAx4KPAyiFqP9OjPBXqfQR8oBWrSpmMuKPtQQcazwO2 cijmNT7yNiV97xr8NQgiKj5c13N1FWr7dmT4D3V8FhelutShFVNth8/0F+Io/rzFXcsg TPUR/kd6Ooypk7YgxLue0v6y4fB12wqrIIJ8/A0S4fuBm18Q/2WCt4fVd4n+WG+wysDE 1WsG8CSfHp2CpbU1LsDFnwraAR0kSs95mToMZxbpaWvENETOacJA3BT4OroK+FycIUBq wuBQ== 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 :mime-version; bh=RVVJcJ754cbvyn8flUfLqwl3cY8aA5YmMfN9Q5ddgKI=; b=bvJXMJ9dl3FQ/J7eM+b3kVuUZLuYrURQzrn8vCuamUIg7kcXg/D6MCwBvpQivOZshV GZRNI+fdQOtfi/ekUgVd3akipeKj6wU6+GPK0m1WAZ4bOxm5zNoQIvj6XWIfs0xmXV1v 79USscj3qdYfXPfekbOiV8WuZasJsXDxFQ1HXXCKwkrRnBc+F76l78Bw41an5e+C6Cb8 QZs0KVieT3rDUwhQAHeXsL5F20ELPiOwbMPFoapbfAv7nUKTIAKcoDLM9Vy58e9l1apo HYulJUQuZKjN25l6OqsTUPasXwGtzl9Vu72tFVr7jl6QqIbDQffM098OIRLOt7Cj/HOx R22Q== X-Gm-Message-State: AGi0Pubc/dCgF5MLwnjHRPwXP3Ay7lta+WfemI4XTKbGIk9wk6uxf9z4 auaD966nkrQe1c5p2MB2Xh3jTQ== X-Google-Smtp-Source: APiQypKNefrMCEZgX0KXd+98B8y8p4uLRHlVZgS9XldO1ggneN3UtlBpbi04DakbdlKcSHOaUOFNyQ== X-Received: by 2002:a17:902:b088:: with SMTP id p8mr7108126plr.106.1585904596504; Fri, 03 Apr 2020 02:03:16 -0700 (PDT) Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id y15sm5335000pfc.206.2020.04.03.02.03.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 02:03:15 -0700 (PDT) From: Vittorio Bertocci To: "Richard Backman, Annabelle" , Vittorio Bertocci , George Fletcher , Hannes Tschofenig , oauth , Vittorio Bertocci Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Thread-Index: AWY3YmE0phjvGCczRNd2oS0LIvsK+DBGRDM13hN5qICADrzdRw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 3 Apr 2020 09:03:14 +0000 Message-ID: References: <760BA08D-CB52-440D-9CDB-699BEE306A31@amazon.com> In-Reply-To: <760BA08D-CB52-440D-9CDB-699BEE306A31@amazon.com> 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_MWHPR19MB1501ACC81394A8D8B19050F1AEC70MWHPR19MB1501namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 03 Apr 2020 09:03:24 -0000 --_000_MWHPR19MB1501ACC81394A8D8B19050F1AEC70MWHPR19MB1501namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFubmFiZWxsZSBhbmQgR2VvcmdlISAgSSBhbSBjb25zb2xpZGF0aW5nIHJlcGxpZXMg dG8gYm90aCB5b3VyIGxhdGVzdCBjb21tZW50cyBpbiB0aGlzIG1haWwuIFRoaXMgc2VlbXMgYSBo YXJkIHJvY2sgdG8gbGlmdCwgYnV0IGl0IGFsc28gc2VlbXMgdG8gYmUgdGhlIGxhc3Qgb25lIPCf mIouDQoNClRoZSBUTDtEUiBpcywgSSBhbSBub3QgY29tcGxldGVseSBvcHBvc2VkIHRvIHJlbGF4 aW5nIHRoZSBjb25zdHJhaW50cyBhbmQgdHVybmluZyB0aGVtIGludG8gc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMsIGJ1dCBJIHRoaW5rIHdl4oCZZCBtaXNzIGFuIG9wcG9ydHVuaXR5IHRvIG1ha2Ug dGhpbmdzIGNsZWFyZXIgZm9yIGRldmVsb3BlcnMuIEF0IHRoZSBzYW1lIHRpbWUgSSB3b3VsZG7i gJl0IHdhbnQgdG8gbWFrZSB0aGlzIHByb2ZpbGUgdG9vIHBhdHJvbml6aW5nLCBoZW5jZSBJIGFw cHJlY2lhdGUgdGhlIG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MuDQoNCg0KDQpbQW5uYWJlbGxlXQ0K DQogID4uIFRoZXJlIG1heSBiZSBubyAic2NvcGUiIHBhcmFtZXRlci4gIFRoZSAic2NvcGUiIHBh cmFtZXRlciBpcyBPUFRJT05BTCBpbiBhdXRob3JpemF0aW9uIHJlcXVlc3RzLiBTbyBhbiBBUy9S UyBvcGVyYXRvciBjb3VsZCBkZWNpZGUgdGhleSdyZSBnb2luZyB0byBvbWl0ICJzY29wZSIgZW50 aXJlbHkgYW5kIHVzZSBtdWx0aXBsZSByZXNvdXJjZSBwYXJhbWV0ZXJzIGluc3RlYWQuIFNpbmNl IHRoZXJlIGFyZSBubyBzY29wZXMsIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciBjb25mdXNp b24uDQoNCkkgYW0gYSBCSUcgZmFuIG9mIEFUcyB3aXRoIG5vIHNjb3BlLSBhbGwgdGhlIHNjZW5h cmlvcyB3aGVyZSB0aGVyZeKAmXMgbm8gZGVsZWdhdGlvbiAoMXN0IHBhcnRpZXMgZXRjKSBzaG91 bGRu4oCZdCB1c2Ugc2NvcGVzIGF0IGFsbC4gVGhlIGN1cnJlbnQgbGFuZ3VhZ2UgaW4gdGhlIHBy b2ZpbGUgZG9lcyBhbGxvdyBmb3Igc2NvcGUtbGVzcyBBVHMsIGFuZCBnaXZlbiB0aGF0IHRoZSBn b2FsIGlzIHRvIHByZXZlbnQgY29uZnVzaW9uLCBJIGFncmVlIHRoYXQgdGhlcmXigJlzIG5vIG5l ZWQgdG8gcmVzdHJpY3QgdGhlIGF1ZGllbmNlIHRvIG9uZSBzaW5nbGUgcmVzb3VyY2UgaWYgdGhl cmUgYXJlIG5vIHNjb3BlcyBhdCBhbGwgdG8gbWlzaW50ZXJwcmV0Lg0KDQpJIHdvdWxkIGJlIGlu IGZhdm9yIHRvIGFsbG93IG11bHRpcGxlIHJlc291cmNlcyBpbiBhdWRpZW5jZSBpbiB0aGF0IGNh c2UuDQoNClVuZm9ydHVuYXRlbHkgaXTigJlzIG5vdCBhcyBzaW1wbGUgYXMganVzdCBzYXlpbmcg 4oCcSWYgdGhlIGluY29taW5nIHJlcXVlc3QgaW5jdWRlcyBtdWx0aXBsZSByZXNvdXJjZSBpbmRp Y2F0b3JzIGFuZCBubyBzY29wZSwgYWNjZXB0IGl0IGFuZCB1c2UgdGhlIGluY29taW5nIHJlc291 cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXigJ0g4oCTIG1vc3RseSBiZWNhdXNlIHRo ZXJlIGlzIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgcHJvZHVjdGlvbiBzeXN0ZW1zIHdoZXJlIHRo ZSByZXF1ZXN0IGluY2x1ZGVzIG5vIHNjb3BlcyBhbmQgb25lIHJlc291cmNlIGluZGljYXRvciwg YnV0IHRoZSByZXN1bHRpbmcgdG9rZW4gaW5jbHVkZXMgYSBjb2xsZWN0aW9uIG9mIHNjb3BlcyB0 aGUgdXNlciBhbHJlYWR5IGNvbnNlbnRlZCB0byBmb3IgdGhhdCByZXNvdXJjZS0gYnV0IEkgYW0g c3VyZSB3ZSBjYW4gZ2V0IHRvIGFjY2VwdGFibGUgbGFuZ3VhZ2UgdGhhdCBleHByZXNzZXMgdGhl IGNvbmNlcHQg4oCcaWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlc291cmNlIGluZGljYXRvcnMgaW4g dGhlIHJlcXVlc3QgYW5kIHRoZSByZXN0IG9mIHRoZSBydWxlcyBpbiBTLjMgdGhlIHJlc3VsdGlu ZyBBVCB3b27igJl0IGNvbnRhaW4gYSBzY29wZSBjbGFpbSwgdGhlIHJlc3VsdGluZyBBVCBtdXN0 IHVzZSB0aGF0IHJlc291cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXigJ0uDQoNCg0K DQo+IEFuIEFTL1JTIG9wZXJhdG9yIG1heSB1c2UgInNjb3BlIiB0byBpbmRpY2F0ZSBhIHJvbGUg b3IgcG9saWN5IChvciBzZXQgb2YgcG9saWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3YW50cywgYW5k IGFsbG93IHRoZSBjbGllbnQgdG8gbmFycm93IHRoZWlyIHBlcm1pc3Npb25zIHVzaW5nICJyZXNv dXJjZSIgcGFyYW1ldGVycy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG9idGFpbiBu YXJyb3dseSBzY29wZWQgYWNjZXNzIHRva2VucyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpdGhv dXQgbmVlZGluZyB0byBkZWZpbmUgc2VwYXJhdGUgcm9sZXMvcG9saWNpZXMgZm9yIGVhY2guIElu IHRoaXMgY2FzZSwgYSBKV1QgQVQgd2l0aCBhIG11bHRpLXZhbHVlZCAiYXVkIiBjbGFpbSBhbmQg YSAic2NvcGUiIGNsYWltIHdvdWxkIHNlZW0gYXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFp bSBpcyBpbnRlbmRlZCB0byBhcHBseSB0byBhbGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy4NCg0K SSBhZ3JlZSB0aGF0IGRlcGxveW1lbnRzIGxpa2UgdGhlIG9uZSB5b3UgZGVzY3JpYmUgbWlnaHQg ZXhpc3QsIGluIGZhY3QgSSBhbSBzdXJlIHRoZXkgZG8uIEhvd2V2ZXIgaXQgc2VlbXMgcmVhbGx5 IGEgYnJpdHRsZSBhcHByb2FjaCwgZ2l2ZW4gdGhhdCBpdCBtYWtlcyBhIHNwZWNpZmljIGFzc3Vt cHRpb24gKHNjb3BlcyBhcmUgdmFsaWQgYWNyb3NzIGFsbCB0aGUgcmVzb3VyY2VzKSB0aGF0IGlz buKAmXQgZW5zaHJpbmVkIGFueXdoZXJlIGFuZCBpZiBmdXR1cmUgdXBkYXRlcyB0byB0aGF0IGRl cGxveW1lbnQgdmlvbGF0ZSB0aGF0IGFzc3VtcHRpb24sIHRoYXQgd291bGQgbGVhZCB0byB0aGUg c2NvcGUgY29uZnVzaW9uIHRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGlzIHRy eWluZyB0byBwcmV2ZW50LiBXZSBvZmZlciB2ZXJ5IGxpdHRsZSBndWlkYW5jZSBpbiB0aGF0IHJl c3BlY3Q6IHRoZSBtYWluIHBsYWNlIHdlcmUgbXVsdGlwbGUgcmVzb3VyY2VzIGFyZSBldmVuIG1l bnRpb25lZCBpcyByZXNvdXJjZSBpbmRpY2F0b3JzLCBhbmQgYWxsIHRoZSBzYW1wbGVzIChJIGtu b3csIG5vbi1ub3JtYXRpdmUpIHVzZSBzY29wZXMgdW5hbWJpZ3VvdXNseSB0aWVkIHRvIGEgc3Bl Y2lmaWMgcmVzb3VyY2UgKG1vcmUgb24gdGhhdCBsYXRlcikgbWFraW5nIHRoZSBtdWx0aS1yZXNv dXJjZSBzY29wZSBldmVuIG1vcmUgb2YgYSBzcGVjaWFsIGNhc2UuDQoNCg0KDQpTdGVwcGluZyBi YWNrIGEgYml0IC0gdGhlIGludGVudCBiZWhpbmQgdGhvc2UgcmVzb3VyY2Utc2NvcGUgcmVzdHJp Y3Rpb25zIGlzIHRvIHByb3ZpZGUgYSBiaXQgbW9yZSBndWlkYW5jZSBvbiBzY29wZXMgYW5kIHJl c291cmNlcyB0aGFuIHdlIGRpZCBpbiB0aGUgcGFzdCwgYW5kIG5hcnJvd2luZyB0aGUgcmFuZ2Ug b2YgY2FzZXMgZGV2ZWxvcGVycyB3b3VsZCBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IHdoZW4g aW1wbGVtZW50aW5nIHRoZSBwcm9maWxlLg0KDQpJbiBteSBleHBlcmllbmNlIHRoZSBsYWNrIG9m IG1vcmUgcHJlc2NyaXB0aXZlIGd1aWRhbmNlIGxlZCB0byBkZXBsb3ltZW50cyBhbmQgaW50ZXJw cmV0YXRpb25zIHRoYXQsIHdoaWxlIHJlbWFpbmluZyBmdWxseSB3aXRoaW4gdGhlIGJvdW5kYXJ5 IG9mIHdoYXQgdGhlIHNwZWMgYWxsb3dzLCBhcmUgb2Z0ZW4gcXVlc3Rpb25hYmxlIGZyb20gdGhl IHNlY3VyaXR5IGFuZCBhcmNoIHBlcnNwZWN0aXZlLg0KDQooKilJIGFja25vd2xlZGdlIHRoYXQg SSBtaWdodCBiZSBzd2luZ2luZyB0b28gZmFyIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24sIGFu ZCBwZXJoYXBzIGEgc2ltaWxhciBlZmZlY3QgY291bGQgYmUgYWNoaWV2ZWQgYnkgYWRkaW5nIGFu IOKAnEF1dGhvcml6YXRpb24gQ29uc2lkZXJhdGlvbnPigJ0gc2VjdGlvbiB3aGVyZSBpbXBsZW1l bnRlcnMgYXJlIHdhcm5lZCBhYm91dCB0aGUgZGFuZ2VyIG9mIHNjb3BlIGNvbmZ1c2lvbiByYXRo ZXIgdGhhbiBkb3ducmlnaHQgZm9yYmlkZGluZyBtdWx0aSByZXNvdXJjZXMgYXVkaWVuY2VzIHdo ZW4gaW5jbHVkaW5nIHNjb3BlcyBhcyB3ZWxsLiBJIHN0aWxsIGxpa2UgdGhlIHNpbXBsaWNpdHkg YW5kIGNsYXJpdHkgb2YgdGhlIGN1cnJlbnQgcmVzdHJpY3Rpb24sIGJ1dCBvZiBjb3Vyc2UgSSBh bSBvcGVuIHRvIGZlZWRiYWNrLg0KDQoNCg0KPiBUaGUgbWFwcGluZyBiZXR3ZWVuIGF1ZGllbmNl IGFuZCBzY29wZSBtYXkgYmUgdW5hbWJpZ3VvdXMuIFRoZXJlIGFyZSBhIGxvdCBvZiBkZXBsb3lt ZW50cyB0byB3aGljaCB0aGUgYmxhc3QgcmFkaXVzIHJpc2sgeW91J3JlIHRyeWluZyB0byBhZGRy ZXNzIGJ5IHJlcXVpcmluZyAiYXVkIiBzaW1wbHkgZG9lcyBub3QgYXBwbHkNCg0KVGhlcmUgYXJl IGNlcnRhaW5seSBjYXNlcyB3aGVyZSBzY29wZSBzdHJpbmdzIHVuYW1iaWd1b3VzbHkgbWFwIHRv IHNwZWNpZmljIHJlc291cmNlcywgYnV0IG9uY2UgYWdhaW4sIHRoYXTigJlzIGEgc3Ryb25nIGFz c3VtcHRpb24gdG8gbWFrZSBhbmQgb25lIEkgZmVlbCBjYW5ub3QgYmUgbWFkZSBsaWdodGx5LiBS ZXNvdXJjZSBpbmRpY2F0b3JzIHVzZSB2ZXJ5IHNpbXBsZSBleGFtcGxlcyAoY29udGFjdHMsIGNh bGVuZGFyKSB0aGF0IGFyZSBoYXJkIHRvIGdlbmVyYWxpemUgdG8gc2NlbmFyaW9zIHdoZXJlIHRo ZSBudW1iZXIgYW5kIGxpZmVjeWNsZSBvZiByZXNvdXJjZXMgdHJ1bHkgY2FsbHMgZm9yIHRoZSB1 c2Ugb2YgaW5kaWNhdG9ycyBpZGVudGlmeWluZyBhIHJlc291cmNlIGluIGEgbGFyZ2UgbXVsdGl0 ZW5hbnQgc3lzdGVtIHVzdWFsbHkgZW50YWlscyBsYXJnZSBpZGVudGlmaWVycywgYW5kIHN0dWZm aW5nIHRob3NlIGluIHRoZSBzY29wZSB0byBwcmV2ZW50IGFtYmlndWl0eSBjYW4gYmUgZXhwZW5z aXZlIGZyb20gYm90aCBwcm92aXNpb25pbmcgYW5kIHRva2VuLCByZXF1ZXN0IHNpemUgYW5nbGVz Lg0KDQoNCg0KPkl0IG1heSBzZWVtIGlubm9jdW91cyB0byByZXF1aXJlIHRoZXNlIGRlcGxveW1l bnRzIHRvIGV4cGxpY2l0bHkgaW5jbHVkZSBhIGJyb2FkIGF1ZGllbmNlIGxpa2UgImFwaS5leGFt cGxlLmNvbSIgYW55d2F5LCB0aGF0IGNhbiBsZWFkIHRvIGltcGxlbWVudGVycyBpZ25vcmluZyB0 aGUgcmVxdWlyZW1lbnQgKGxlYWRpbmcgdG8gaW50ZXJvcCBpc3N1ZXMpLCBub3QgdmFsaWRhdGlu ZyBpdCAoYWxzbyBsZWFkaW5nIHRvIGludGVyb3AgaXNzdWVzIG9yIHNlY3VyaXR5IGlzc3VlcyBp ZiB0aGUgZGVwbG95bWVudCB3YW50cyB0byBzdGFydCBhY3R1YWxseSB1c2luZyBpdCBmb3IgcmVh bCksIG9yIGRvaW5nIHNvbWV0aGluZyBmdW5reSB3aXRoIGl0IHNpbmNlIHRoZXJlIGlzbid0IGFu eXRoaW5nICJyZWFsIiB0aGF0IHRoZSB2YWx1ZSBuZWVkcyB0byBjb25mb3JtIHRvLg0KDQpFdmVy eSBzcGVjIGd1aWRhbmNlIHJpc2tzIG5vdCBiZWluZyBmb2xsb3dlZC4gQnV0IGluIHRoaXMgcGFy dGljdWxhciBjYXNlLCB1c2Ugb2YgYSBsb2dpY2FsIGF1ZGllbmNlIGlzIHF1aXRlIG1haW5zdHJl YW0g4oCTIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBmb3IgcmVzb3VyY2UgaW5kaWNhdG9y cyBhbmQgdGhhdOKAmXMgd2h5IHRoZSBzcGVjIGVuZGVkIHVwIGluY2x1ZGluZyBsb2dpY2FsIGlk ZW50aWZpZXJzIGFzIG9uZSBvZiB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIGZsYXZvci4g4oCccmVh bOKAnSBpcyBhIHJlbGF0aXZlIHRlcm0sIGdpdmVuIHRoYXQgdGhlcmUgYXJlIGFscmVhZHkgbWFu eSBkaWZmZXJlbnQgd2F5cyBpbiB3aGljaCBhIGxvZ2ljYWwgcmVzb3VyY2UgbWlnaHQgbWFwIHRv IGRpZmZlcmVudCDigJxwaHlzaWNhbOKAnSBhcnRpZmFjdHMgKHNlZSBoZXJva3XigJlzIGxhdGUg YmluZGluZyBVUkxzKS4gQ29sbGVjdGl2ZSBhdWRpZW5jZXMgYXJlIGluIGNvbW1vbiB1c2UgZm9y IHBvb3IgbWFu4oCZcyB0cnVzdGVkIHN1YnN5c3RlbXM6IG5vdCBlbmRvcnNpbmcgdGhlIGFwcHJv YWNoLCBidXQgYnJpbmdpbmcgY2lyY3Vtc3RhbnRpYWwgZXZpZGVuY2UgdGhhdCBicm9hZCBhdWRp ZW5jZXMgYXJlbuKAmXQgdGhhdCB1bmNvbW1vbiBvciBoYXJkIHRvIGdyb2sgZm9yIGRldmVsb3Bl cnMgYWxyZWFkeSB0b2RheS4gRmluYWxseSwgdHVybmluZyBvZmYgdmFsaWRhdGlvbiBpcyBhY3R1 YWxseSBub3QgdGhhdCB0cml2aWFsIGluIG1hbnkgU0RLcywgZ2l2ZW4gdGhhdCB0aGV5IG1vc3Rs eSByZXVzZS9kZXJpdmUgZnJvbSBPSURDIGFuZCB0aGUgYXVkaWVuY2UgY2hlY2sgaXMgbWFuZGF0 b3J5OiBJIHNhdyBtb3JlIG9mdGVuIHBlb3BsZSBkaXNhYmxpbmcgaXNzIGNoZWNrIHRoYW4gYXVk LiBOb25lIG9mIHRoaXMgbWVhbnMgdGhhdCB0aGUgZXJyb3JzIHlvdSBkZXNjcmliZSBjYW5ub3Qg aGFwcGVuOiBidXQgSSB0aGluayB0aGV5IGFyZW7igJl0IG1vcmUgbGlrZWx5IHRoYW4gYW55IG90 aGVyIGd1aWRhbmNlIGluIHRoZSBzcGVjLg0KDQpJIGRvIGFjayB0aGUgbW9yZSBnZW5lcmljIHBv aW50IHRoYXQsIGxpa2UgaW4gdGhlIHByZWNlZGluZyBjYXNlLCB0aGlzIG1pZ2h0IHN1Z2dlc3Qg dGhhdCB0aGUgY3VycmVudCBndWlkYW5jZSBpcyB0b28gc3RyaWN0LSBzZWUgKCopDQoNCg0KDQpb R2VvcmdlXQ0KDQo+SSB0aGluayBvbmUgb2YgdGhlIHByb2JsZW1zIHdlIGhhdmUgaW4gYmVpbmcg c3VwZXIgc3BlY2lmaWMgYWJvdXQgaG93IHRoZSBKV1QgYWNjZXNzIHRva2VuIGlzIGNvbnN0cnVj dGVkIGlzIHRoYXQgaXMgbWVhbnMgaXQncyBub3QgcG9zc2libGUgZm9yIG1hbnkgb3JnYW5pemF0 aW9ucyB0byBmb2xsb3cuIEhvdyBzY29wZXMgYXJlIGltcGxlbWVudGVkIGlzIHZlcnkgdmFyaWVk IGFjcm9zcyBkZXBsb3ltZW50cyB3aGljaCBtZWFucyB0aGF0IHNvbWUgbWF5IGNvbmZvcm0gdG8g dGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBzcGVjIGFuZCBtYW55IG1heSBub3QuDQoNCllvdSBhcmUg cmlnaHQsIHRoZSBzcGVjICBpcyBhbiBvcGluaW9uYXRlZCB0YWtlLSBJIGFncmVlIHRoYXQgbWFu eSBvcmdhbml6YXRpb25zIHVzZWQgc2NvcGVzIGluIHZlcnkgZGlmZmVyZW50IHdheXMsIGFuZCBJ IHRoaW5rIGl0IGlzIHRoZSByZXN1bHQgb2YgZ2l2aW5nIHZlcnkgbGl0dGxlIGd1aWRhbmNlIG9u IHNjb3BlcyBhbmQgcmVzb3VyY2VzLCB3aXRoIHRoZSBjb25zZXF1ZW5jZSB0aGF0IHNvbWUgY2hv aWNlcyBtaWdodCBoYXZlIGJlZW4gbGVzcyB3aXNlIHRoYW4gb3RoZXJzLg0KDQpXaXRoIHRoZSBj dXJyZW50IGd1aWRhbmNlIEkgYXR0ZW1wdGVkIHRvIGNhcHR1cmUgYSBuYXJyb3dlciBzZXQgb2Yg c2NlbmFyaW9zIHdoZXJlIHNvbWUgb2YgdGhlIG1vc3Qgb2J2aW91cyBpc3N1ZXMgKGxpa2Ugc2Nv cGUgY29uZnVzaW9uKSBjYW4gYmUgYXZlcnRlZCwgd2hpbGUgc3RpbGwgc2F0aXNmeWluZyBtb3N0 IG9mIHRoZSBjYXNlcyBJIG9ic2VydmVkIGluIHRoZSBzYW1wbGUgSldUIEFUczogSSBhbSBub3Qg dHJ5aW5nIHRvIG92ZXJpbmRleCBvbiB0aG9zZSBjYXNlcywgYW5kIEkgZG9u4oCZdCBtZWFuIHRv IGltcGx5IHRoYXQgdGhlIHByb2ZpbGUgc2hvdWxkIHN0cmljdGx5IGZvbGxvdyB0aG9zZSwgYnV0 IGluIHRoZSBzcGlyaXQgb2YgZWxpbWluYXRpbmcgYW1iaWd1aXR5IGFzIG11Y2ggYXMgcG9zc2li bGUsIHRoaXMgc2luZ2xlIHJlc291cmNlIG5hcnJvd2luZyBzZWVtZWQgYSBzb2xpZCBjb3JlIHRv IGJ1aWxkIHJvYnVzdCBpbXBsZW1lbnRhdGlvbnMgb24tIGZ1bGx5IGF3YXJlIG9mIHRoZSBmYWN0 IHRoYXQgbWFueSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyB3b3VsZCBub3QgY29uZm9ybSAodGhv IEkgYW0gbm90IHN1cmUgaG93IG1hbnkgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgYWRvcHRlZCBy ZXNvdXJjZSBpbmRpY2F0b3JzIG9yIGVxdWl2YWxlbnQpLg0KDQpJbiBhbnkgY2FzZSwgc2VlICgq KS0gSSB0aGluayBJIGNhbiBiZSBjb252aW5jZWQgdG8gdHVybiB0aGUgY3VycmVudCByZXN0cmlj dGlvbnMgaW50byBzZWN1cml0eS9hdXRob3JpemF0aW9uIGNvbnNpZGVyYXRpb25zLSBidXQgSSB3 b3VsZCByZWx1Y3RhbnRseSBkbyBzbyBhcyBJIHRoaW5rIHdl4oCZZCBwZXJwZXR1YXRlIGEgbG90 IG9mIHRoZSBhbWJpZ3VpdHkgd2UgaGF2ZSBpbiB0aGlzIHNwYWNlIHRvZGF5Lg0KDQoNCg0KPlBl cnNvbmFsbHksIEknbSBub3QgYSBiaWcgZmFuIG9mIHRyeWluZyB0byB1c2Ugc2NvcGVzIGZvciBm aW5lLWdyYWluIGF1dGhvcml6YXRpb24uIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyB3aGF0IHRoZXkg d2VyZSBpbnRlbmRlZCBmb3Igd2hlbiBvcmlnaW5hbGx5IGRlc2lnbmVkLiAoVGhpcyBjYW4gYmUg c2VlbiBieSB0aGUgUkFSIHNwZWMgaW50cm9kdWNpbmcgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3 YXkgb2Ygc3BlY2lmeWluZyBmaW5lLWdyYWluIGF1dGhvcml6YXRpb24gY29udGV4dC4pIEV2ZW4g aW4gbXVsdGktdGVuYW50IHN5c3RlbXMsIEkgZG9uJ3Qgc2VlIGlzc3VlcyB3aXRoIHVzaW5nIHN1 Yi1yZXNvdXJjZSBzY29wZXMgYXMgZWFjaCB0ZW5hbnQgc2hvdWxkIGRlZmluZSB0aGUgc2NvcGVz IHRoYXQgbWFrZSBzZW5zZSBmb3IgdGhhdCB0ZW5hbnQuIEkgZG9uJ3QgdGhpbmsgdGhlIEFTIG5l ZWRzIHRvIHVuZGVyc3RhbmQgdGhlIHNjb3BlcywganVzdCBwcm92aWRlIGEgbWVjaGFuaXNtIHRv IGlzc3VlIHRoZSBjb3JyZWN0IHNjb3BlIHVuZGVyIHVzZXIgY29uc2VudCB0byB0aGUgY2xpZW50 IGFuZCBsZXQgdGhlIFJTIGFwcGx5IHRoZSBhdXRob3JpemF0aW9uIHBvbGljeSB3aGVuIGl0IGdl dHMgdGhlIHNjb3BlcyBvdXQgb2YgdGhlIHRva2VuLg0KDQpJIGFtIG5vdCBjcmF6eSBhYm91dCB0 aGF0IGVpdGhlci0gZXNwZWNpYWxseSBnaXZlbiB0aGF0IHdoZW4gZmluZSBncmFpbmVkIGF1dGha IGlzIGludm9sdmVkIHZlcnksIHZlcnkgb2Z0ZW4gd2hhdCBkZXZlbG9wZXJzIHJlYWxseSB3YW50 IGFyZSB1c2VyIHByaXZpbGVnZXMgYW5kIHNjb3BlcyBhcmUganVzdCBhYnVzZWQgaW4gbGlldSBv ZiBwcml2aWxlZ2VzIHNpbXBseSBiZWNhdXNlIHRoZSBzcGVjIGRvZXNu4oCZdCBhZGRyZXNzIHRo ZSBub24tZGVsZWdhdGlvbiBzY2VuYXJpbyBoZW5jZSBhIHNjcmV3ZHJpdmVyIGVuZHMgdXAgYmVp bmcgdXNlZCBhcyBhIGhhbW1lci4NCg0KTm9uZXRoZWxlc3MsIGlmIHNjb3BlcyBhcmUgdXNlZC0g bWFuZGF0aW5nIHRoYXQgZXZlcnkgc2NvcGUgaXMgdGllZCB0byB0aGUgcmVzb3VyY2UgZG9lcyBs ZWFkIHRvIGh1Z2UgdG9rZW5zIGFuZCBzaWduaWZpY2FudCBtYW5hZ2VtZW50IG92ZXJoZWFkIGlm IHlvdSBoYXZlIGxvdHMgb2YgcmVzb3VyY2VzIHdob3NlIGlkZW50aWZpZXIgbXVzdCBiZSBnbG9i YWxseSB1bmlxdWUsIG5vbnJlYXNzaWduYWJsZSBldGMgZXRjIGhlbmNlIHZlcnkgbGFyZ2Ug4oCT IGFuZCB0aGUgQVMgZG9lc27igJl0IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2VtYW50aWMgb2Yg ZWFjaCBzY29wZSBidXQgaXQgZG9lcyBuZWVkIHRvIGtub3cgd2hldGhlciBhIHNjb3BlIGNhbiBi ZSByZXF1ZXN0ZWQgZm9yIGEgZ2l2ZW4gcmVzb3VyY2UsIHBsdXMgYW55IHBvbGljeSB0aGUgYWRt aW4gbWlnaHQgd2FudCB0byBleGVjdXRlIGF0IHRva2VuIGlzc3VhbmNlIHRpbWUgKGVnIHRoaXMg c2NvcGUgcmVxdWlyZXMgMkZBKSBoZW5jZSBqdWdnbGluZyBsYXJnZSBudW1iZXJzIG9mIGxhcmdl IHN0cmluZ3MgY2FuIGJlIGhhcmQgZm9yIHRoZSBBUyDigJMgYW5kIFJTLiBJbiBhbnkgY2FzZSwg dGhlIHVzZSBvZiBtdWx0aXBsZSByZXNvdXJjZXMgaW4gdGhlIGF1ZCBpbiB0aGUgd2lsZCBhcHBl YXJlZCB0byBiZSB2ZXJ5IHJhcmUsIGhlbmNlIGV2ZW4gaWYgdGhlcmUgd291bGQgYmUgYSBmb29s cHJvb2Ygd2F5IG9mIGRlZmluaW5nIGEgcmVzb3VyY2Utc2NvcGUgbWFwcGluZywgSSB3b3VsZCBu b3Qgc3BlbmQgY3ljbGVzIGRlZmluaW5nIGl0IGhlcmXigKYgYW5kIGxlYXZpbmcgaXQgYXMgZXhl cmNpc2UgZm9yIHRoZSByZWFkZXIgd291bGRu4oCZdCB3b3JrIHBlciB0aGUgYWJvdmUuIEFzIGlu ICgqKSB3ZSBjb3VsZCByZWxheCB0aGUgY29uc3RyYWludCBoZXJlIGFuZCBqdXN0IHdhcm4gcGVv cGxlIGFnYWluc3Qgc2NvcGUgY29uZnVzaW9uLCBidXQgSSBmZWVsIHdl4oCZZCBiZSBtaXNzaW5n IGFuIG9wcG9ydHVuaXR5Lg0KDQoNCg0KLS0tLS0tDQoNCg0KDQrvu79PbiAzLzI0LzIwLCAxNzow MCwgIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbT4gd3Jv dGU6DQoNCg0KDQogICAgVG8gYm9ycm93IGEgdGVybSBmcm9tIE1MLCBJIHRoaW5rIHRoZSAiYXVk IiwgInNjb3BlIiwgYW5kIHJlc291cmNlIGluZGljYXRvci1yZWxhdGVkIHRleHQgaXMgb3ZlcmZp dHRlZCB0byBhIHNwZWNpZmljIHNldCBvZiBkZXBsb3ltZW50IHNjZW5hcmlvcywgYW5kIGEgc3Bl Y2lmaWMgd2F5IG9mIHVzaW5nIHNjb3BlcyBhbmQgcmVzb3VyY2UgaW5kaWNhdG9ycy4NCg0KDQoN CiAgICBDb25zaWRlciB0aGUgZm9sbG93aW5nOg0KDQoNCg0KICAgIDEuIFRoZXJlIG1heSBiZSBu byAic2NvcGUiIHBhcmFtZXRlcg0KDQogICAgVGhlICJzY29wZSIgcGFyYW1ldGVyIGlzIE9QVElP TkFMIGluIGF1dGhvcml6YXRpb24gcmVxdWVzdHMuIFNvIGFuIEFTL1JTIG9wZXJhdG9yIGNvdWxk IGRlY2lkZSB0aGV5J3JlIGdvaW5nIHRvIG9taXQgInNjb3BlIiBlbnRpcmVseSBhbmQgdXNlIG11 bHRpcGxlIHJlc291cmNlIHBhcmFtZXRlcnMgaW5zdGVhZC4gU2luY2UgdGhlcmUgYXJlIG5vIHNj b3BlcywgdGhlcmUgaXMgbm8gb3Bwb3J0dW5pdHkgZm9yIGNvbmZ1c2lvbi4gSW4gdGhpcyBjYXNl LCBhIEpXVCBBVCB3aXRoIGEgbXVsdGktdmFsdWVkICJhdWQiIGNsYWltIGFuZCBubyAic2NvcGUi IGNsYWltIHdvdWxkIHNlZW0gYXBwcm9wcmlhdGUuIFdoaWxlIG11bHRpcGxlIHJlc291cmNlIGlu ZGljYXRvcnMgY291bGQgYmUgcHVzaGVkIGludG8gYSBzaW5nbGUgc2NvcGUgc3RyaW5nLCB0aGlz IGludHJvZHVjZXMgb3Bwb3J0dW5pdGllcyBmb3Igc2VyaW91cyBzZWN1cml0eSBpbXBhY3Rpbmcg ZW5jb2RpbmcvZGVjb2RpbmcvcGFyc2luZyBidWdzLiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IGl0 LCB0aGUgbW9yZSAiSSBkb24ndCBoYXZlIHRvIGRlYWwgd2l0aCBwYXJzaW5nIGEgc2NvcGUgc3Ry aW5nIiBzZWVtcyBsaWtlIGEgY29tcGVsbGluZyByZWFzb24gdG8gZ28gdGhpcyByb3V0ZS4uLiBf Xw0KDQoNCg0KICAgIDIuIFRoZSBzY29wZXMgbWF5IGFwcGx5IHRvIGFsbCBhdWRpZW5jZXMNCg0K ICAgIEFuIEFTL1JTIG9wZXJhdG9yIG1heSB1c2UgInNjb3BlIiB0byBpbmRpY2F0ZSBhIHJvbGUg b3IgcG9saWN5IChvciBzZXQgb2YgcG9saWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3YW50cywgYW5k IGFsbG93IHRoZSBjbGllbnQgdG8gbmFycm93IHRoZWlyIHBlcm1pc3Npb25zIHVzaW5nICJyZXNv dXJjZSIgcGFyYW1ldGVycy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG9idGFpbiBu YXJyb3dseSBzY29wZWQgYWNjZXNzIHRva2VucyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpdGhv dXQgbmVlZGluZyB0byBkZWZpbmUgc2VwYXJhdGUgcm9sZXMvcG9saWNpZXMgZm9yIGVhY2guIElu IHRoaXMgY2FzZSwgYSBKV1QgQVQgd2l0aCBhIG11bHRpLXZhbHVlZCAiYXVkIiBjbGFpbSBhbmQg YSAic2NvcGUiIGNsYWltIHdvdWxkIHNlZW0gYXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFp bSBpcyBpbnRlbmRlZCB0byBhcHBseSB0byBhbGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy4NCg0K DQoNCiAgICAzLiBUaGUgbWFwcGluZyBiZXR3ZWVuIGF1ZGllbmNlIGFuZCBzY29wZSBtYXkgYmUg dW5hbWJpZ3VvdXMNCg0KICAgIFRoZXJlIGFyZSBhIGxvdCBvZiBkZXBsb3ltZW50cyB0byB3aGlj aCB0aGUgYmxhc3QgcmFkaXVzIHJpc2sgeW91J3JlIHRyeWluZyB0byBhZGRyZXNzIGJ5IHJlcXVp cmluZyAiYXVkIiBzaW1wbHkgZG9lcyBub3QgYXBwbHkuIEl0IG1heSBzZWVtIGlubm9jdW91cyB0 byByZXF1aXJlIHRoZXNlIGRlcGxveW1lbnRzIHRvIGV4cGxpY2l0bHkgaW5jbHVkZSBhIGJyb2Fk IGF1ZGllbmNlIGxpa2UgImFwaS5leGFtcGxlLmNvbSIgYW55d2F5LCB0aGF0IGNhbiBsZWFkIHRv IGltcGxlbWVudGVycyBpZ25vcmluZyB0aGUgcmVxdWlyZW1lbnQgKGxlYWRpbmcgdG8gaW50ZXJv cCBpc3N1ZXMpLCBub3QgdmFsaWRhdGluZyBpdCAoYWxzbyBsZWFkaW5nIHRvIGludGVyb3AgaXNz dWVzIG9yIHNlY3VyaXR5IGlzc3VlcyBpZiB0aGUgZGVwbG95bWVudCB3YW50cyB0byBzdGFydCBh Y3R1YWxseSB1c2luZyBpdCBmb3IgcmVhbCksIG9yIGRvaW5nIHNvbWV0aGluZyBmdW5reSB3aXRo IGl0IHNpbmNlIHRoZXJlIGlzbid0IGFueXRoaW5nICJyZWFsIiB0aGF0IHRoZSB2YWx1ZSBuZWVk cyB0byBjb25mb3JtIHRvLg0KDQoNCg0KICAgIOKAkw0KDQogICAgQW5uYWJlbGxlIEJhY2ttYW4g KHNoZS9oZXIpDQoNCiAgICBBV1MgSWRlbnRpdHkNCg0KICAgIGh0dHBzOi8vYXdzLmFtYXpvbi5j b20vaWRlbnRpdHkvDQoNCg0KDQoNCg0KICAgIO+7v09uIDMvMjQvMjAsIDM6MzEgUE0sICJPQXV0 aCBvbiBiZWhhbGYgb2YgVml0dG9yaW8gQmVydG9jY2kiIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiB2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9y Zz4gd3JvdGU6DQoNCg0KDQogICAgQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20g b3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhl IGNvbnRlbnQgaXMgc2FmZS4NCg0KDQoNCg0KDQoNCg0KICAgIFRoYW5rcyBHZW9yZ2UgZm9yIHRo ZSBzdXBlciB0aG9yb3VnaCByZXZpZXcgYW5kIGZlZWRiYWNrIQ0KDQogICAgSW5saW5lDQoNCg0K DQogICAgICA+ICBTZWN0aW9uIDEuIEludHJvZHVjdGlvbg0KDQogICAgICAgICDDr8K/wr3Dr8K/ wr3Dr8K/wr0gc2Vjb25kIGxpbmU6IHNjZW5hcmlvIHNob3VsZCBiZSBwbHVyYWwgLS0+IHNjZW5h cmlvcw0KDQogICAgICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gc2Vjb25kIHNlbnRlbmNlOiAiYXJl IG5vdCByYW4gYnkiIC0tPiAiYXJlIG5vdCBydW4gYnkiDQoNCiAgICAgICAgw6/Cv8K9w6/Cv8K9 IGNvZmlkZW50aWFsaXR5IC0tPiBjb25maWRlbnRpYWxpdHkNCg0KICAgIEZpeGVkLiBUaGFua3Mh DQoNCg0KDQogICAgPiAgICAgU2VjdGlvbiAyLjIuMSBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlv biBDbGFpbXMNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IEknbSBub3Qgc3VyZSB0aGF0 IHRoaXMgZGVmaW5pdGlvbiBvZiBgYXV0aF90aW1lYCBhbGxvd3MgZm9yIHRoZQ0KDQogICAgICAg IGNhc2Ugd2hlcmUgYSB1c2VyIGlzIHJlcXVpcmVkIHRvIHNvbHZlIGFuIGFkZGl0aW9uYWwgY2hh bGxlbmdlLg0KDQogICAgSWYgdGhlIGNoYWxsZW5nZSBlbnRhaWxzIGdvaW5nIGJhY2sgdG8gdGhl IEFTLCB0aGVuIEkgYmVsaWV2ZSB0aGUgbGFuZ3VhZ2UgKGluIHRoZSBpbml0aWFsIHBhcmFncmFw aCBvZiAyLjIuMSBhbmQgaW4gYXV0aF90aW1lIGl0c2VsZikgIGFjY29tbW9kYXRlcyBmb3IgdGhh dCBhbmQgZG9lcyByZXF1aXJlIHRoZSBhdXRoX3RpbWUgdG8gYmUgdXBkYXRlZC4NCg0KICAgIElm IHlvdSBoaXQgdGhlIEFTIGFuZCBwcmVzZW50IGFuIGF1dGhlbnRpY2F0aW9uIGZhY3RvciAoc3Vj aCBhcyB5b3VyIGNoYWxsZW5nZSkgYW5kIG9idGFpbiBhIG5ldyB0b2tlbiBpbiB0aGUgcHJvY2Vz cywgdGhlIGF1dGhfdGltZSB3aWxsIHJlZmxlY3QgdGhlIHRpbWUgb2YgeW91ciBsYXRlc3QgYXV0 aGVudGljYXRpb24ganVzdCBsaWtlIGFuIGlkX3Rva2VuIHdvdWxkIGluIHRoZSBzYW1lIGNpcmN1 bXN0YW5jZXMgKHRoaW5rIHByb3RlY3RlZCByb3V0ZSBpbiBhIHdlYiBhcHAgcmVxdWlyaW5nIHN0 ZXAgdXAgYXV0aCkgYW5kIChsaWtlbHkpIGFzc29jaWF0ZWQgc2Vzc2lvbiBhcnRpZmFjdHMgKHRo aW5rIFJUcyBvciBjb29raWVzIHdpdGggc2xpZGluZyBleHBpcmF0aW9uLCB0aGUgY2hhbGxlbmdl IHdvdWxkIGNvdW50IGFzIGFjdGl2aXR5IGFuZCBtb3ZlIHRoZSBleHBpcmF0aW9uKS4NCg0KDQoN CiAgICA+ICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSB0aGluayB0aGVyZSBpcyBhIGRpZmZlcmVu Y2UgYmV0d2VlbiBzZXNzaW9uX3N0YXJ0X3RpbWUgYW5kIGxhc3QNCg0KICAgICAgICBhdXRoX3Rp bWUuIFRoaXMgZmVlbHMgbW9yZSBsaWtlIGl0J3MgZGVmaW5pbmcgdGhlIHNlc3Npb25fc3RhcnRf dGltZQ0KDQogICAgICAgIGNvbmNlcHQuDQoNCiAgICA+ICAgIMOvwr/CvcOvwr/CvSBUaGVzZSBz YW1lIGlzc3VlcyBjYW4gYXBwbHkgdG8gdGhlIGBhY3JgIGFuZCBgYW1yYCB2YWx1ZXMgYXMgd2Vs bC4NCg0KICAgIFBlciB0aGUgYWJvdmUsIHRoZSBpbnRlbnQgaXMgbW9yZSB0byBleHByZXNzIHRo ZSBsYXN0IHRpbWUgdGhlIHVzZXIgcGVyZm9ybWVkIGFueSBhdXRoZW50aWNhdGlvbiBhY3Rpb24g cmF0aGVyIHRoYW4gdGhlIHN0YXJ0IHRpbWUuIFRoZSBpbnRlbnQgaXMgdG8gcHJvdmlkZSBpbmZv cm1hdGlvbiBhcyBjdXJyZW50IGFzIHBvc3NpYmxlLCBhcyBpdCBtaWdodCBiZSByZWxldmFudCB0 byB0aGUgUlMgZGVjaXNpb25zIHdoZXJlYXMgdGhlIGhpc3RvcnkgYmVmb3JlIGN1cnJlbnQgY29u ZGl0aW9ucyBtaWdodCBub3QgYmUgY29uc2VxdWVudGlhbC4NCg0KDQoNCiAgICAgID4gICDDr8K/ wr3Dr8K/wr0gRXZlbiBpZiBmb3IgdGhpcyBzZWNvbmRhcnkgY2hhbGxlbmdlIGEgbmV3IHJlZnJl c2hfdG9rZW4gaXMgaXNzdWVkLA0KDQogICAgICAgIGl0IGlzIHVubGlrZWx5IG1hbnkgcmVseWlu ZyBwYXJ0aWVzIHdpbGwgd2FudCB0byB0cmVhdCB0aGF0IGFzIGlzc3VpbmcgYQ0KDQogICAgICAg IG5ldyBzZXNzaW9uLiBUaGUgZ29hbCBpcyB0byBrZWVwIHRoZSB1c2VyIGxvZ2dlZCBpbiB0byBh IHNpbmdsZSBzZXNzaW9uLg0KDQogICAgQ291bGQgeW91IGV4cGFuZCBvbiB0aGUgcHJhY3RpY2Fs IGltcGxpY2F0aW9ucyBvZiB0aGUgYWJvdmU/IFRoZSBpbnRlbnQgaXNuJ3QgYXMgbXVjaCB0byBy ZWZsZWN0IHNlc3Npb24gaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gcGVyIHNlLCBidXQgdG8gcHJv dmlkZSB0aGUgUlMgd2l0aCB0aGUgbW9zdCB1cCB0byBkYXRlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBjaXJjdW1zdGFuY2VzIGluIHdoaWNoIHRoZSBjdXJyZW50IEFUIHdhcyBvYnRhaW5lZC4gVGhl IGZhY3QgdGhhdCBhIHNlc3Npb24gd2FzIGluaXRpYWxseSBlc3RhYmxpc2hlZCB1c2luZyBhY3Ig bGV2ZWwgMCBkb2VzbuKAmXQgcmVhbGx5IG1hdHRlciBpZiB0aGUgQVQgSSBhbSByZWNlaXZpbmcg bm93IGhhcyBiZWVuIG9idGFpbmVkIGFmdGVyIGEgc3RlcHVwIHRoYXQgYnJvdWdodCBhY3IgdG8g MSwgaWYgbXkgUlMgY2FyZXMgYXV0aCBhdXRoZW50aWNhdGlvbiBsZXZlbHMgbXkgYXV0aG9yaXph dGlvbiBkZWNpc2lvbiBzaG91bGRuJ3QgYmUgaW5mbHVlbmNlZCBieSB3aGV0aGVyIHNvbWV3aGVy ZSB0aGUgc2Vzc2lvbiBhcnRpZmFjdCBkaWRu4oCZdCBjaGFuZ2UgaXRzIHNlc3Npb25JRCBhZnRl ciB0aGUgc3RlcHVwLiBTYW1lIGZvciBhY3IsIGF1dGhfdGltZQ0KDQoNCg0KICAgID4gICAgIFNl Y3Rpb24gMi4yLjMgQXV0aG9yaXphdGlvbiBDbGFpbXMNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9 IEkgZmluZCB0aGUgc3RhdGVtZW50ICJBbGwgdGhlIGluZGl2aWR1YWwgc2NvcGUgc3RyaW5ncyBp biB0aGUgc2NvcGUNCg0KICAgICAgICBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBmb3IgdGhlIHJl c291cmNlIGluZGljYXRlZCBpbiB0aGUgYXVkIGNsYWltIg0KDQogICAgICAgIHNvbWV3aGF0IHBy b2JsZW1hdGljLiBJbiBtYW55IGRlcGxveW1lbnRzIHRvZGF5IGZvciAxc3QgcGFydHkgY2xpZW50 cyB0bw0KDQogICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGFraW5nIGludG8g YWNjb3VudCBtb2JpbGUgYXBwbGljYXRpb25zLA0KDQogICAgICAgIHRoZSBhY2Nlc3MgdG9rZW4g bW9zdCBsaWtlIGNvbnRhaW5zIHNjb3BlcyBmb3IgbWFueSBvZiB0aGUgMXN0IHBhcnR5DQoNCiAg ICAgICAgYmFja2VuZCBBUElzLiBJdCdzIHBvc3NpYmxlIHRvIGdldCBhcm91bmQgdGhpcyBieSBz ZXR0aW5nIHRoZSAnYXVkJw0KDQogICAgICAgIGNsYWltIHRvIHNvbWV0aGluZyBsaWtlICJjb20u ZXhhbXBsZS5hcGlzIiBhbmQgaGVuY2UgYWxsIHRoZSBpc3N1ZWQNCg0KICAgICAgICBzY29wZXMg bWFwIHRvIHRoYXQgYXVkaWVuY2UgY2xhaW0gYnV0IHRoYXQgaXMganVzdCB3b3JraW5nIGFyb3Vu ZCB0aGUNCg0KICAgICAgICBNVVNUIGluIHRoZSBzcGVjLiBHaXZlbiB0aGUgbGFjayBvZiBzcGVj aWZpY2l0eSBvZiB0aGUgJ2F1ZCcgY2xhaW0gYW5kDQoNCiAgICAgICB0aGUgJ3Jlc291cmNlIGlu ZGljYXRvcicgY2xhaW0gZm9yIHRoYXQgbWF0dGVyLCBwcmV0dHkgbXVjaCBhbnl0aGluZyBjYW4N Cg0KICAgICAgICBiZSBtYWRlIHRvIGNvbXBseS4gSW4gdGhhdCBjb250ZXh0LCBpdCBzZWVtcyBs aWtlIFJFQ09NTUVORCBpcyBhIGJldHRlcg0KDQogICAgICAgIG5vcm1hdGl2ZSBjbGF1c2UuDQoN CiAgICBGb3IgMXN0IHBhcnR5IHNvbHV0aW9ucywgSSB3b3VsZCBhcmd1ZSB0aGF0IGRlbGVnYXRp b24gbWlnaHQgbm90IGJlIHRoZSByaWdodCBwcmltaXRpdmUgaGVuY2UgSSB3b3VsZG4ndCBuZWNl c3NhcmlseSB1c2Ugc2NvcGVzIHRvIGV4cHJlc3MgcGVybWlzc2lvbnM7IGJ1dCB0aGF0J3MgYSBy YWJiaXQgaG9sZSBJJ2xsIHRyeSB0byBhdm9pZCBmb3IgdGhlIHRpbWUgYmVpbmcgX18NCg0KICAg IEZvciB0aGUgYXVkLCBJIHRoaW5rIHRoYXQgd2hhdCB5b3UgY2hhcmFjdGVyaXplZCBhcyB3b3Jr YXJvdW5kIHdvdWxkIGFjdHVhbGx5IGJlIGJ5IGRlc2lnbi4gVGhlIGF1ZCBkZWZpbmVzIHRoZSBh cHBsaWNhYmlsaXR5IG9mIHRoZSBjdXJyZW50IHRva2VuLCBzbyB0aGF0IGluIGNhc2Ugb2YgbGVh a2FnZSB0aGUgYmxhc3QgcmFkaXVzIG9mIHRoZSBpbmNpZGVudCBjYW4gYmUgY29udGFpbmVkLiBJ ZiB0aGUgc29sdXRpb24gZGVzaWduZWQgZGVjaWRlcyB0aGF0IHRoaXMgcGFydGljdWxhciB0b2tl biBzaG91bGQgYmUgcmV1c2FibGUgYWNyb3NzIG11bHRpcGxlIGFzc2V0cywgSSB0aGluayBpdCBt YWtlcyBzZW5zZSBmb3IgdGhlIGF1ZCB0byByZWZsZWN0IHRoYXQgZXhwbGljaXRseS4gVGhhdCdz IHRoZSBzeXN0ZW0gZGVzaWduaW5nIHZvbHVudGVlcmluZyBhIHNjb3BlIHhwYW5zaW9uIG9mIHRo ZSBzY29wZSwgYW5kIGdpdmVuIHRoYXQgaXQgaGFzIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBJIHRo aW5rIGl0J3MgZ29vZCB0byByZXF1aXJlIGl0IHRvIGJlIGFuIGV4cGxpY2l0LCBvcHQgaW4gYWN0 aW9uLiBBdCB0aGUgc2FtZSB0aW1lLCBnaXZlbiB0aGF0IHNjb3BlcyBhcmUgb2Z0ZW4gdXNlZCB0 byBkZWZpbmUgcGVybWlzc2lvbnMsIEkgYmVsaWV2ZSBpdCBtYWtlcyBzZW5zZSB0byBmaW5kIG1l Y2hhbmlzbXMgdG8gbWluaW1pemUgdGhlIGNoYW5jZSB0aGF0IFJTZXMgd291bGQgbWlzaW50ZXJw cmV0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIGEgc2NvcGUgKHNlZSBkaXNjdXNzaW9uIHdpdGggVGFr YWhpa28vTmlrb3MpLiBTdW1taW5nIGFsbCB0aGUgYWJvdmUsIEknZCBiZSBpbmNsaW5lZCB0byBr ZWVwIHRoZSBNVVNULg0KDQoNCg0KICAgID4gU2VjdGlvbiAzLiBSZXF1ZXN0aW5nIGEgSldUIEFj Y2VzcyBUb2tlbg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gUGVyIG15IGNvbW1lbnRzIGFib3Zl IEkgc3VzcGVjdCB0aGF0IHJlcXVpcmluZyBhbGwgSldUIGFjY2VzcyB0b2tlbnMNCg0KICAgICAg ICB0byBpbmNsdWRlIGFuIGF1ZGllbmNlIGNsYWltIHdpbGwganVzdCBkZXZvbHZlIHRvIGF1ZGll bmNlIGNsYWltcyB0aGF0DQoNCiAgICAgICAgYXJlIHNvbWV3aGF0IHBvaW50bGVzcyAoaW4gb3Jk ZXIgdG8gbWVldCB0aGlzIE1VU1QgaW4gdGhlIHNwZWMpLiBHaXZlbg0KDQogICAgICAgIHRoZSBt b2JpbGUgYXBwIGVudmlyb25tZW50IHRvZGF5LCBpdCBpcyB1bnJlYXNvbmFibGUgdG8gYXNrIHRo ZSBtb2JpbGUNCg0KICAgICAgICBhcHBzIHRvIGRvd25zY29wZSBldmVyeSBhY2Nlc3MgdG9rZW4g YmVmb3JlIG1ha2luZyBhbiBBUEkgY2FsbCB0byB0aGUNCg0KICAgICAgICBiYWNrZW5kIEFQSXMg d2hpY2ggaXMgd2hhdCB0aGUgc3Bpcml0IG9mIGF1ZGllbmNlIGFuZCByZXNvdXJjZQ0KDQogICAg ICAgIGluZGljYXRvcnMgc2VlbSB0byBpbXBseS4NCg0KICAgIFBhcnRseSBhZGRyZXNzZWQgaW4g dGhlIHByZWNlZGluZyBwb2ludCwgYnV0IHRoaXMgaXMgYSBncmVhdCBvcHBvcnR1bml0eSB0byBj bGFyaWZ5IHRoZSBpbnRlbnQgZnVydGhlci4gVGhlIG1vYmlsZSBjbGllbnQgaXNuJ3QgcmVxdWly ZWQgdG8gZG93bnNjb3BlOyByYXRoZXIsIHRoZSBmYWN0IHRoYXQgYSB0b2tlbiBjYWIgYmUgYXBw bGllZCB0byBhIGJyb2FkIHJhbmdlIG9mIEFQSSBzaG91bGQgYmUgY2xlYXJseSBpZGVudGlmaWVk IGFuZCBleHByZXNzZWQgYnkgdGhlIGxvZ2ljYWwgYXVkaWVuY2UuIFRoZSBzeXN0ZW0gZGVzaWdu ZXIgY2FuIGV2ZW4gY2hvb3NlIHRvIGhhdmUgYSBzaW5nbGUgdG9rZW4gdGhhdCBjYW4gYmUgdXNl ZCB0byBjYWxsIGFueSBBUEksIGNvbnRhaW5pbmcgZXZlcnkgc2NvcGUgZm9yIGV2ZXJ5IEFQSTsg dGhlIHByb2ZpbGUgb25seSBhc2tzIGZvciB0aGlzIGNob2ljZSB0byBiZSBtYW5pZmVzdCwgYnkg Y2hvb3NpbmcgYW4gYXBwcm9wcmlhdGUgYXVkaWVuY2UgaWRlbnRpZmllciBhbmQgYWNrbm93bGVk Z2luZyB0aGF0IGFsbCB0aGUgc2NvcGVzIGluIHRoZSB0b2tlbiBhcmUgYXBwbGljYWJsZSB0byB0 aGUgc2FtZSBsb2dpY2FsIHJlc291cmNlICh0aGF0IGlzLCB0aGUgYWdncmVnYXRlIG9mIGFsbCB0 aGUgQVBJcykuDQoNCg0KDQogICAgICAgICA+ICDDr8K/wr3Dr8K/wr0gV2h5IE1VU1QgdGhlIEFT IHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtb3JlIHRoYW4gb25lIHJlc291cmNlDQoNCiAgICAgICAg cGFyYW1ldGVyPyBJZiBhIHJlcXVlc3QgY29tZXMgaW4gd2l0aCBubyByZXNvdXJjZSBwYXJhbWV0 ZXIgYW5kIG11bHRpcGxlDQoNCiAgICAgICAgc2NvcGVzIHRoZSBBUyBpcyBub3QgcmVxdWlyZWQg dG8gcmVqZWN0IHRoYXQgcmVxdWVzdC4gSXMgdGhlcmUgbXVjaCBvZiBhDQoNCiAgICAgICAgc2Vt YW50aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28/IEluIHRoZSBjYXNlIG9mIG5vIHJlc291 cmNlDQoNCiAgICAgICAgcGFyYW1ldGVyIGFuZCBtdWx0aXBsZSBzY29wZXMgdGhlIEFTIG1pZ2h0 IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoDQoNCiAgICAgICAgbXVsdGlwbGUgYXVkaWVuY2Ug dmFsdWVzIChhcyBpcyBhbGxvd2VkIGJ5IFJGQyA3NTE5KS4NCg0KICAgIFRoaXMgaXMgYW5vdGhl ciBjb25zZXF1ZW5jZSBvZiBtYWtpbmcgZXh0cmEgY2xlYXIgd2hhdCB0aGUgdG9rZW4gcmVmZXJz IHRvLCBhbmQgd2hhdCB0aGUgaW50ZW5kZWQgc2VtYW50aWMgb2YgdGhlIHNjb3BlcyBpcy4gVGhl IGlkZWEgaXMgdGhhdCB0aGUgdG9rZW4gaXMgYWx3YXlzIHJlc3RyaWN0ZWQgdG8gT05FIHNwZWNp ZmljIGF1ZGllbmNlLiBUaGUgcHJvZmlsZSBhbGxvd3MgZm9yIGRpZmZlcmVudCBtZWNoYW5pc21z IGZvciB0aGUgQVMgdG8gZGV0ZXJtaW5lIHdoYXQgdmFsdWUgdGhlIGF1ZGllbmNlIHNob3VsZCBi ZSwgaW5jbHVkaW5nIHZpYSBpbmZlcmVuY2UgZnJvbSBzY29wZXMsIGJ1dCBjb2hlcmVudGx5IHdp dGggdGhlIHNjb3BlIGNvbmZ1c2lvbiBwcmV2ZW50aW9uIHByaW5jaXBsZSwgaWYgdGhhdCBpbmZl cmVuY2UgY2Fubm90IGxlYWQgdG8gYSBzaW5nbGUgcmVzb3VyY2UgaWRlbnRpZmllciBpbiB0aGUg YXVkaWVuY2UsIHRoZSByZXF1ZXN0IHNob3VsZCBiZSByZWplY3RlZC4NCg0KICAgIFRoZSBpbnRl bnQgaXMgcmVhbGx5IHRvIGJlIGFzIHNpbXBsZSBhcyB1bmFtYmlndW91cyBhcyBwb3NzaWJsZSwg YW5kIGNhcHR1cmUgd2hhdCBtb3N0IG1haW5zdHJlYW0gcHJvdmlkZXJzIGFscmVhZHkgZG8gaW4g SldUIEFUcy4gSWYgYSBSUyBoYXMgbW9yZSBzb3BoaXN0aWNhdGVkIHJlcXVpcmVtZW50cywgdGhl eSBjYW4gYWx3YXlzIGRlY2lkZSB0byBkbyBtb3JlIGFuZCBub3QgZm9sbG93IHRoZSBpbnRlcm9w IHByb2ZpbGUuIERlZmluaW5nIG1vcmUgY29tcGxleCBydWxlcyB0byBwcmV2ZW50IHNjb3BlL3Jl c291cmNlIGFzc29jaWF0aW9uIGNvbmZ1c2lvbiBzaW1wbHkgZG9lc27igJl0IHNlZW0gdG8gYmUg anVzdGlmaWVkIGJ5IHRoZSBmcmVxdWVuY3kgb2YgdGhlIHNjZW5hcmlvIGluIHRoZSB3aWxkLg0K DQoNCg0KDQoNCiAgICA+ICBBbHNvLCB0aGUgYXVkaWVuY2UNCg0KICAgICAgICBjbGFpbSBpcyBu b3Qgc29sZWx5IGZvciByZXNvdXJjZSBpbmRpY2F0b3IgdmFsdWVzIGJ1dCBpcyBkZWZpbmVkIHRv IGp1c3QNCg0KICAgICAgICBiZSBhIHN0cmluZy4gVG8gbWUgaXQgZmVlbHMgbGlrZSB0aGUgdGV4 dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5DQoNCiAgICAgICAgdmFsaWQgYXVkaWVuY2UgdmFs dWUgaXMgYWxzbyBhIHJlc291cmNlIGluZGljYXRvciAod2hpY2ggZnJvbSBwcmV2aW91cw0KDQog ICAgICAgIGRpc2N1c3Npb25zIG9uIHRoZSBsaXN0IGl0IHdhcyBpbXBsaWVkIHRoZXkgaGF2ZSBh IHNsaWdodGx5IGRpZmZlcmVudA0KDQogICAgICAgIHNlbWFudGljKS4NCg0KICAgIFNlY3Rpb24g MyBvZiB0aGUgcHJvZmlsZSBkb2VzIGRlZmluZSBhdWQgYXMgYSByZXNvdXJjZSBpbmRpY2F0b3Is IGVudW1lcmF0aW5nIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiBwb3NzaWJsZSByZXF1ZXN0cyB0aGF0 IGFsbCBlbmQgaW4gYSByZXNvdXJjZSBpbmRpY2F0b3IgYXMgYXVkLCBvciBhbiBlcnJvci4gRGlk IEkgbWlzcyBzb21lIGNhc2VzPyBJIGRvbuKAmXQgcmVjYWxsIHNwZWNpZmljcyBhYm91dCBhdWQg dmFsdWVzIGluIHRoaXMgcHJvZmlsZSBoYXZpbmcgb3RoZXIgcG9zc2libGUgdmFsdWVzLCBzb3Jy eSBmb3IgaGF2aW5nIG1pc3NlZCB0aGF0LiBEbyB5b3UgaGF2ZSBhIHNuaXBwZXQgcmVmZXJyaW5n IHRvIHRob3NlIGRpc2N1c3Npb25zPyBUaHgNCg0KDQoNCiAgICAgICAgPiAgw6/Cv8K9w6/Cv8K9 IFRoZSBtb2RlbCBkZXNjcmliZWQgaGVyZSB3b3JrcyB3ZWxsIGlmIG15Y28uZXhhbXBsZSByZWFs bHkgb25seQ0KDQogICAgICAgIHByb3ZpZGVzIGEgc2luZ2xlIHNlcnZpY2UuIEJ1dCBpZiBpbnN0 ZWFkIG15Y28uZXhhbXBsZSBwcm92aWRlcyBtdWx0aXBsZQ0KDQogICAgICAgIHNlcnZpY2VzIGVh Y2ggd2l0aCB0aGVpciBvd24gZW5kcG9pbnRzIChzcnZhLm15Y28uZXhhbXBsZSwNCg0KICAgICAg ICBzcnZiLm15Y28uZXhhbXBsZSkgYW5kIHNjb3BlcywgZm9yIG1lIHRoaXMgbW9kZWwgYmVnaW5z IHRvIGJyZWFrIGRvd24uDQoNCiAgICAgICAgRWl0aGVyIG1vYmlsZSBhcHBzIGFyZSByZXF1aXJl ZCB0byBkb3duc2NvcGUgYWxsIHRva2VucyB0byBqdXN0IHRoZQ0KDQogICAgICAgIHNlcnZpY2Ug dGhleSBhcmUgY2FsbGluZyBhdCB0aGF0IHBvaW50IGluIHRpbWUgKHdoaWNoIGNhbiBoYXZlIGxh dGVuY3kNCg0KICAgICAgICBhbmQgY29ubmVjdGl2aXR5IGlzc3VlcyksIG9yIG15Y28uZXhhbXBs ZSBoYXMgdG8gY3JlYXRlIGEgZ2VuZXJpYw0KDQogICAgICAgICJhdWRpZW5jZSIgc3RyaW5nIHRo YXQgcmVwcmVzZW50cyBhbGwgb2YgZXhhbXBsZS5jb20gd2hpY2ggZG9lc24ndCBzZWVtDQoNCiAg ICAgICAgdG8gYmUgdGhlIHNwaXJpdCBvZiB0aGUgZXhpc3Rpbmcgc3BlY3MuDQoNCiAgICBJIHRo aW5rIHRoYXQgdGhlIGdyYW51bGFyaXR5IG9mIHRoZSBjYWxscyBpcyBmdWxseSB3aXRoaW4gdGhl IGNvbnRyb2wgb2YgdGhlIGRlc2lnbmVyLiBJZiBzcnZhLm15Y28uZXhhbXBsZSBhbmQgc3J2Yi5t eWNvLmV4YW1wbGUgc2hhcmUgYW5hbG9nb3VzIGNoYXJhY3RlcmlzdGljcyAoc2FtZSBwb2xpY2ll cywgbGlmZWN5Y2xlLCByZXNvdXJjZSBvd25lcnNoaXAsIGV0YykgdGhlbSBpdCdzIHBlcmZlY3Rs eSB2YWxpZCB0byBhc3NpZ24gYSBsb2dpY2FsIG15Y28uZXhhbXBsZSBhdWRpZW5jZSBlbmNvbXBh c3NpbmcgdGhlbSBhbGwsIHJlZ2FyZGxlc3Mgb2YgZGVwbG95bWVudCBtb2RlbC4gSWYgdGhlcmUg YXJlIGRpZmZlcmVuY2VzIGluIHRlcm1zIG9mIHBvbGljaWVzLCBhdXRoIHN0cmVuZ3RoIHJlcXVp cmVtZW50cywgbGlmZWN5Y2xlLCByaXNrIGFuZCBpbXBhY3Qgb2YgYSBsZWFrLCBvciBhbnkgb3Ro ZXIgYm91bmRhcnksIHRoZW4gdGhlIGF1ZGllbmNlIHJlcXVpcmVtZW50IHdpbGwgZ3VhcmFudGVl IHRoYXQgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIHJlZmxlY3RlZCBpbiB0b2tlbnMgcmVxdWVzdGVk IGFuZCBjYWNoZWQsIGluIHRoZSB3YXkgaW4gd2hpY2ggYWNjZXNzIGlzIHBhcnRpdGlvbmVkLCBh bmQgc28gb24gYW5kIHNvIGZvcnRoLiBJZiB0aGVyZSBhcmUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IHN1Y2ggYXMgdGhlIG9uZXMgZW51bWVyYXRlZCwgdGhlIGxhdGVuY3kgYW5kIGNvbm5lY3Rpdml0 eSBpc3N1ZXMgYXJlbuKAmXQgYSBibG9ja2luZyBmYWN0b3I7IGFuZCBpZiB0aGVyZSBhcmVuJ3Qs IG5vdGhpbmcgcHJldmVudHMgeW91IGZyb20gaGF2aW5nIGEgbG9naWNhbCBhdWRpZW5jZSB2YWx1 ZS4gRnJvbSB0aGUgZXhwcmVzc2l2ZSBwb3dlciBwb2ludCBvZiB2aWV3LCB0aGUgcmVxdWlyZW1l bnQgb2YgaGF2aW5nIGEgc2luZ2xlIGF1ZGllbmNlIGRvZW5zJ3QgcHJldmVudCB5b3UgZnJvbSBk b2luZyBhbnkgb2YgdGhlIHNpbmdsZSB0b2tlbiBsb2dpYyB5b3UgYXJlIGhpbnRpbmcgYXQtIGVz cGVjaWFsbHkgaWYgeW91IHBsYW4gdG8gdXNlIHNwZWNpYWxpemVkIHNjb3BlcyBhbnl3YXkuDQoN Cg0KDQogICAgICAgPiAgIMOvwr/CvcOvwr/CvSBJbiBzdW1tYXJ5LCBJIGZlZWwgdGhhdCB0aGlz IHRleHQgaXMgYmluZGluZyB0b28gdGlnaHRseSByZXNvdXJjZQ0KDQogICAgICAgIGluZGljYXRv cnMgdG8gdGhlIGF1ZGllbmNlIGNsYWltLiBXaGF0IGlzIGRlc2NyaWJlZCBpcyBwZXJmZWN0bHkN Cg0KICAgICAgICByZWFzb25hYmxlIGluIGEgdXNlIGNhc2UgdGhhdCBpcyBhcHBseWluZyByZXNv dXJjZSBpbmRpY2F0b3JzIGluIHRoaXMNCg0KICAgICAgICB3YXkgYnV0IGlzIG5vdCBpbmRpY2F0 aXZlIG9mIHRoZSB3aWRlbHkgZGVwbG95ZWQgbW9kZWxzIHRoYXQgYWxyZWFkeSBleGlzdC4NCg0K ICAgIFdlIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGV4cGVyaWVuY2VzIGhlcmUuIFRoZSBKV1QgYWNj ZXNzIHRva2VucyBmcm9tIHBvcHVsYXIgcHJvZHVjdHMgSSBzdHVkaWVkIGluIHRoZSByZXNlYXJj aCBJIHByZXNlbnRlZCBpbiBTdHV0dGdhcnQgd2VyZSBhbG1vc3QgYWxsIHVzaW5nIHRoZSBhdWQg Y2xhaW0gaW4gdGhpcyB3YXkuIEkgYW0gc3VyZSB0aGF0IHRoZXJlIGFyZSBvdGhlciBtb2RlbHMs IGFuZCB0aGVyZSB3YXMgYXQgbGVhc3Qgb25lIGV4Y2VwdGlvbiwgYnV0IGluIGludGVyb3AgdGVy bXMgdGhpcyBzZWVtcyB0byBiZSB0aGUgbW9zdCBjb21tb24gd2F5IG9mIHVzaW5nIEpXVCBmb3Ig QVRzLSBhbmQgaXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgYmVpbmcgdmVyeSBzaW1wbGUgYW5kIHVu YW1iaWd1b3VzLg0KDQoNCg0KICAgID4gU2VjdGlvbiA0LiBWYWxpZGF0aW5nIEpXVCBBY2Nlc3Mg VG9rZW5zDQoNCiAgICAgICAgIMOvwr/CvcOvwr/CvSBTdGVwIDQuIC0tIENhbiB3ZSBjaGFuZ2Ug dGhlIHdvcmRpbmcgdG8gbm90IHJlcXVpcmUgcmVzb3VyY2UNCg0KICAgICAgICBpbmRpY2F0b3Jz PyBXaGF0IGFib3V0Li4uICJUaGUgcmVzb3VyY2Ugc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhhdCB0 aGUNCg0KICAgICAgICAnYXVkJyBjbGFpbSBjb250YWlucyBhIHN0cmluZyB0aGF0IHJlcHJlc2Vu dHMgdGhlIGF1ZGllbmNlIG9mIHRoaXMNCg0KICAgICAgICByZXNvdXJjZSBzZXJ2ZXIuIg0KDQog ICAgQ291bGQgeW91IG1ha2UgYW4gZXhhbXBsZSBpbiB3aGljaCB5b3UnZCB3YW50IHRvIHVzZSBh biBpZGVudGlmaWVyIHRoYXQgaXMgbm90IGEgcmVzb3VyY2UgaW5kaWNhdG9yPyBHaXZlbiB0aGF0 IHdlIGhhdmUgdGhlIHNwZWMsIGFuZCAiYXVkaWVuY2Ugb2YgdGhlIHJlc291cmNlIHNlcnZlciIg c2VlbXMgdG8gYmUgdGhlIGV4YWN0IHNlbWFudGljIG9mIHJlc291cmNlIGluZGljYXRvcnMsIGl0 IHNlZW1lZCBhIHNsYW0gZHVuayB0byB1c2UgaXQgaGVyZS4uLg0KDQoNCg0KICAgICAgID4gU2Vj dGlvbiA1LiAiY3Jvc3MtSldUIGNvbmZ1c2lvbiINCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IEkg dGhpbmsgdGhlcmUgbWF5IGJlIGNvbmZ1c2lvbiBhcm91bmQgd2hhdCBpcyBtZWFudCBieSAiZGlz dGluY3QNCg0KICAgICAgICByZXNvdXJjZXMiLiBJbiBteSBleGFtcGxlIGFib3ZlLCBhcmUgc3J2 YS5teWNvLmV4YW1wbGUgYW5kDQoNCiAgICAgICAgc3J2Yi5teWNvLmV4YW1wbGUgImRpc3RpbmN0 IHJlc291cmNlcyI/IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8gc2F5IHRoYXQNCg0KICAgICAgICB3 ZSB3YW50IGRpZmZlcmVudCBhdWRpZW5jZSB2YWx1ZXMgZ2VuZXJhdGVkIGZvciBjcm9zcy1vcmdh bml6YXRpb24NCg0KICAgICAgICByZXNvdXJjZXMuIEZvciBleGFtcGxlLCBhcmUgbWFpbC5nb29n bGUuY29tIGFuZCB5b3V0dWJlLmNvbSAiZGlzdGluY3QNCg0KICAgICAgICByZXNvdXJjZXMiPyBv ciB3b3VsZCBhbiBhdWRpZW5jZSBmb3IgZ29vZ2xlIHN1ZmZpY2UgaW4gbWVldGluZyB0aGUNCg0K ICAgICAgICBtZWFuaW5nIG9mIHRoaXMgcGFyYWdyYXBoPw0KDQogICAgSSB0aGluayB0aGUga2V5 IHBvaW50IGhlcmUgaXMgLSB3ZSBkb27igJl0IGtub3cuIEkgYWdyZWUgdGhlIGxhbmd1YWdlIGlz bid0IGNsZWFyIHRoZXJlLiBMZXQgbWUgZXhwYW5kIG9uIHRoZSBpbnRlbnQsIGFuZCBwZXJoYXBz IHdlIGNhbiBnZXQgdG8gYSBiZXR0ZXIgZm9ybXVsYXRpb24uDQoNCiAgICBPQXV0aDIgZG9lc27i gJl0IGRlbWFuZCB0aGF0IFJTIGFuZCBBUyBhcmUgcnVuIGJ5IHRoZSBzYW1lIGVudGl0eSwgYnV0 IHRoYXQncyB0aGUgbW9zdCBjb21tb24gc2NlbmFyaW8uIEZCIGRvZXNuJ3QgbmVlZCB0byBzcGVj aWZ5IGEgcmVzb3VyY2UsIGJlY2F1c2UgdGhlIHJlc291cmNlIGlzIGltcGxpY2l0Li4gaXQncyB0 aGUgRkIgZ3JhcGgsIHlvdSBjYW7igJl0IGdldCBhIHRva2VuIGZvciBhbnl0aGluZyBlbHNlLiBU aGUgb25seSBkaWZmZXJlbnRpYXRvciBlbmRzIHVwIGJlaW5nIHRoZSBzY29wZXMuIFNhbWUgZm9y IG1hbnkgb3RoZXIgcHJvdmlkZXJzLCBnb29nbGUsIE1pY3Jvc29mdCBmb3IgaXRzIG93biBHcmFw aCwgZXRjLg0KDQogICAgSG93ZXZlciBtYW55IEFTIGFzIGEgc2VydmljZSBkb27igJl0IGhhdmUg dGhlIGJlbmVmaXQgb2YgYSBkZWZhdWx0LCBpbXBsaWNpdCByZXNvdXJjZSwgZXNwZWNpYWxseSBp biBtdWx0aSB0ZW5hbmN5IHNjZW5hcmlvcywgZ2l2ZW4gdGhhdCB0aGV5J2xsIG5lZWQgdG8gaXNz dWUgdG9rZW5zIGZvciBhIG51bWJlciBvZiBkaWZmZXJlbnQgcmVjaXBpZW50cy4gV2hldGhlciBy ZXNvdXJjZXMgYXJlIGNyb3NzIG9yZ2FuaXphdGlvbiwgb3IgY3Jvc3MgZGVwYXJ0bWVudCwgb3Ig Zm9sbG93aW5nIGFueSBvdGhlciBhcmJpdHJhcnkgc2VncmVnYXRpb24vZmFjdG9yaW5nIG1vZGVs IGlzIHNvbWV0aGluZyB3ZSBjYW5ub3QgaW5mZXItIGl0J3MgdXAgdG8gdGhlIGRldmVsb3BlciB0 byBkZXRlcm1pbmUgdGhhdC4gV2hhdCBJIGFtIHRyeWluZyB0byBleHByZXNzIGhlcmUgaXMgdGhh dCB0aGUgb3BlcmF0b3Igb2YgdGhlIEFTIGFzIGEgc2VydmljZSAob3IgYW55IG90aGVyIGZvcm0g b2YgIkFTIGZvciByZW50Iikgc2hvdWxkIHN1cmZhY2UgcmVzb3VyY2VzIGFzIGEgcHJpbWl0aXZl IGZvciBtb2RlbGluZyBhbmQgaWRlbnRpZnlpbmcgaW50ZW5kZWQgcmVjaXBpZW50cyBvZiBBVHMu IERvZXMgdGlzIGhlbHA/IEhvdyB3b3VsZCB5b3UgZXhwcmVzcyB0aGF0Pw0KDQoNCg0KICAgID4g ICAgICDDr8K/wr0gSSdtIGhhdmluZyB0aGUgc2FtZSBjb25mdXNpb24gaW4gdGhlIG5leHQgcGFy YWdyYXBoIHJlZ2FyZGluZyB0aGUNCg0KICAgICAgICBwaHJhc2UgImRpZmZlcmVudCByZXNvdXJj ZXMiLiBBcmUgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhlIHNhbWUgY29tcGFueQ0KDQogICAgICAg ICJkaWZmZXJlbnQgcmVzb3VyY2VzIiBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2Ft ZSByZXNvdXJjZS4gQ2FuDQoNCiAgICAgICAgYW4gYWNjZXNzIHRva2VuIGJlIGlzc3VlZCB3aXRo IHNjb3BlcyBmb3IgYm90aCBtYWlsLmdvb2dsZS5jb20gYW5kDQoNCiAgICAgICAgeW91dHViZS5j b20/IEFuZCBpZiBub3QsIHdoeSBub3RlPyBQcmV2ZW50aW5nIHRoaXMgcHV0cyB1bmR1ZSBidXJk ZW4gb24NCg0KICAgICAgICBtb2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLg0KDQogICAgU2VlIHBy ZWNlZGluZyBwb2ludC4gV2UgY2FuJ3QgZW50ZXIgaW4gdGhlIG1lcml0IG9mIHdoYXQgY29uc3Rp dHV0ZXMgYSByZXNvdXJjZSwgYXMgdGhhdCBkZXBlbmRzIG9uIHRoZSBtb2RlbGluZyBvZiB0aGUg ZG9tYWluIHNwZWNpZmljIHByb2JsZW0gdGhlIGRldmVsb3BlciBpcyB0YWNrbGluZy4gVGhlIGhp Z2hlc3Qgb3JkZXIgYml0IGlzIHRoYXQgaWYgdHdvIGVudGl0aWVzIChBUEksIGV0Yy4uIGludGVu ZGVkIHRva2VuIHJlY2lwaWVudHMpIGhhdmUgZGlmZmVyZW50IHNlY3VyaXR5IGNoYXJhY3Rlcmlz dGljcyAoZS5nLiBsZWFraW5nIGEgdG9rZW4gZm9yIG9uZSBoYXMgZGlmZmVyZW50IGNvbnNlcXVl bmNlcyB0aGFuIGlmIHlvdSdkIGxlYWsgYSB0b2tlbiBmb3IgdGhlIG90aGVyKSwgdGhleSBzaG91 bGQgYmUgbW9kZWxlZCBhcyBkaWZmZXJlbnQgcmVzb3VyY2VzLiBBbmQgaWYgdGhleSBhcmUgZGlm ZmVyZW50IHJlc291cmNlcywgd2Ugc2hvdWxkIGRvIHdoYXQgd2UgY2FuIHRvIGF2b2lkIGNvbmZ1 c2lvbiBpbiBob3cgd2UgZXhwcmVzcyBhY2Nlc3MgZ3JhbnRzIHRvIHRoZW0gKGhlbmNlIHRoZSBi aWcgZGlzY3Vzc2lvbiBvbiBtdWx0aXJlc291cmNlLCBzY29wZSBjb25mdXNpb24sIGV0YykuDQoN Cg0KDQoNCg0KICAgIC0tLS0tLS0tLQ0KDQogICAgT24gMy8yNC8yMCwgMTA6MzksICJHZW9yZ2Ug RmxldGNoZXIiIDxnZmZsZXRjaEBhb2wuY29tPiB3cm90ZToNCg0KDQoNCiAgICAgICAgRmVlZGJh Y2sgb24gdGhlIHNwZWMuLi4NCg0KDQoNCiAgICAgICAgU2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb24N Cg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBsaW5lOiBzY2VuYXJpbyBzaG91 bGQgYmUgcGx1cmFsIC0tPiBzY2VuYXJpb3MNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9 IHNlY29uZCBzZW50ZW5jZTogImFyZSBub3QgcmFuIGJ5IiAtLT4gImFyZSBub3QgcnVuIGJ5Ig0K DQoNCg0KICAgICAgICBTZWN0aW9uIDIuMi4xIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9uIENs YWltcw0KDQogICAgICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSdtIG5vdCBzdXJlIHRoYXQgdGhp cyBkZWZpbml0aW9uIG9mIGBhdXRoX3RpbWVgIGFsbG93cyBmb3IgdGhlDQoNCiAgICAgICAgY2Fz ZSB3aGVyZSBhIHVzZXIgaXMgcmVxdWlyZWQgdG8gc29sdmUgYW4gYWRkaXRpb25hbCBjaGFsbGVu Z2UuIFRha2UgdGhlDQoNCiAgICAgICAgY2FzZSBvZiBhIHVzZXIgd2hvIGlzIHJlcXVpcmVkIHRv IHBhc3MgYSBzZWNvbmRhcnkgY2hhbGxlbmdlIGJlZm9yZSB0aGUNCg0KICAgICAgICAic3RvY2sg cHVyY2hhc2UiIGFjdGlvbiBjYW4gYmUgY29tcGxldGVkLiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgc3BlYw0KDQogICAgICAgIGRlZmluaXRpb24sIHRoZSBgYXV0aF90aW1lYCB2YWx1ZSBNVVNU IE5PVCBiZSB1cGRhdGVkIHdoZW4gdGhpcw0KDQogICAgICAgIHNlY29uZGFyeSBjaGFsbGVuZ2Ug aXMgY29tcGxldGVkLg0KDQoNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IEkgdGhpbmsg dGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gc2Vzc2lvbl9zdGFydF90aW1lIGFuZCBsYXN0 DQoNCiAgICAgICAgYXV0aF90aW1lLiBUaGlzIGZlZWxzIG1vcmUgbGlrZSBpdCdzIGRlZmluaW5n IHRoZSBzZXNzaW9uX3N0YXJ0X3RpbWUNCg0KICAgICAgICBjb25jZXB0Lg0KDQoNCg0KICAgICAg ICAgw6/Cv8K9w6/Cv8K9IFRoZXNlIHNhbWUgaXNzdWVzIGNhbiBhcHBseSB0byB0aGUgYGFjcmAg YW5kIGBhbXJgIHZhbHVlcyBhcyB3ZWxsLg0KDQoNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IEV2 ZW4gaWYgZm9yIHRoaXMgc2Vjb25kYXJ5IGNoYWxsZW5nZSBhIG5ldyByZWZyZXNoX3Rva2VuIGlz IGlzc3VlZCwNCg0KICAgICAgICBpdCBpcyB1bmxpa2VseSBtYW55IHJlbHlpbmcgcGFydGllcyB3 aWxsIHdhbnQgdG8gdHJlYXQgdGhhdCBhcyBpc3N1aW5nIGENCg0KICAgICAgICBuZXcgc2Vzc2lv bi4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgdXNlciBsb2dnZWQgaW4gdG8gYSBzaW5nbGUgc2Vz c2lvbi4NCg0KDQoNCiAgICAgICAgU2VjdGlvbiAyLjIuMyBBdXRob3JpemF0aW9uIENsYWltcw0K DQogICAgICAgICDDr8K/wr3Dr8K/wr0gSSBmaW5kIHRoZSBzdGF0ZW1lbnQgIkFsbCB0aGUgaW5k aXZpZHVhbCBzY29wZSBzdHJpbmdzIGluIHRoZSBzY29wZQ0KDQogICAgICAgIGNsYWltIE1VU1Qg aGF2ZSBtZWFuaW5nIGZvciB0aGUgcmVzb3VyY2UgaW5kaWNhdGVkIGluIHRoZSBhdWQgY2xhaW0i DQoNCiAgICAgICAgc29tZXdoYXQgcHJvYmxlbWF0aWMuIEluIG1hbnkgZGVwbG95bWVudHMgdG9k YXkgZm9yIDFzdCBwYXJ0eSBjbGllbnRzIHRvDQoNCiAgICAgICAgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCB0YWtpbmcgaW50byBhY2NvdW50IG1vYmlsZSBhcHBsaWNhdGlvbnMsDQoNCiAg ICAgICAgdGhlIGFjY2VzcyB0b2tlbiBtb3N0IGxpa2UgY29udGFpbnMgc2NvcGVzIGZvciBtYW55 IG9mIHRoZSAxc3QgcGFydHkNCg0KICAgICAgICBiYWNrZW5kIEFQSXMuIEl0J3MgcG9zc2libGUg dG8gZ2V0IGFyb3VuZCB0aGlzIGJ5IHNldHRpbmcgdGhlICdhdWQnDQoNCiAgICAgICAgY2xhaW0g dG8gc29tZXRoaW5nIGxpa2UgImNvbS5leGFtcGxlLmFwaXMiIGFuZCBoZW5jZSBhbGwgdGhlIGlz c3VlZA0KDQogICAgICAgIHNjb3BlcyBtYXAgdG8gdGhhdCBhdWRpZW5jZSBjbGFpbSBidXQgdGhh dCBpcyBqdXN0IHdvcmtpbmcgYXJvdW5kIHRoZQ0KDQogICAgICAgIE1VU1QgaW4gdGhlIHNwZWMu IEdpdmVuIHRoZSBsYWNrIG9mIHNwZWNpZmljaXR5IG9mIHRoZSAnYXVkJyBjbGFpbSBhbmQNCg0K ICAgICAgICB0aGUgJ3Jlc291cmNlIGluZGljYXRvcicgY2xhaW0gZm9yIHRoYXQgbWF0dGVyLCBw cmV0dHkgbXVjaCBhbnl0aGluZyBjYW4NCg0KICAgICAgICBiZSBtYWRlIHRvIGNvbXBseS4gSW4g dGhhdCBjb250ZXh0LCBpdCBzZWVtcyBsaWtlIFJFQ09NTUVORCBpcyBhIGJldHRlcg0KDQogICAg ICAgIG5vcm1hdGl2ZSBjbGF1c2UuDQoNCg0KDQogICAgICAgIFNlY3Rpb24gMy4gUmVxdWVzdGlu ZyBhIEpXVCBBY2Nlc3MgVG9rZW4NCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IFBlciBteSBjb21t ZW50cyBhYm92ZSBJIHN1c3BlY3QgdGhhdCByZXF1aXJpbmcgYWxsIEpXVCBhY2Nlc3MgdG9rZW5z DQoNCiAgICAgICAgdG8gaW5jbHVkZSBhbiBhdWRpZW5jZSBjbGFpbSB3aWxsIGp1c3QgZGV2b2x2 ZSB0byBhdWRpZW5jZSBjbGFpbXMgdGhhdA0KDQogICAgICAgIGFyZSBzb21ld2hhdCBwb2ludGxl c3MgKGluIG9yZGVyIHRvIG1lZXQgdGhpcyBNVVNUIGluIHRoZSBzcGVjKS4gR2l2ZW4NCg0KICAg ICAgICB0aGUgbW9iaWxlIGFwcCBlbnZpcm9ubWVudCB0b2RheSwgaXQgaXMgdW5yZWFzb25hYmxl IHRvIGFzayB0aGUgbW9iaWxlDQoNCiAgICAgICAgYXBwcyB0byBkb3duc2NvcGUgZXZlcnkgYWNj ZXNzIHRva2VuIGJlZm9yZSBtYWtpbmcgYW4gQVBJIGNhbGwgdG8gdGhlDQoNCiAgICAgICAgYmFj a2VuZCBBUElzIHdoaWNoIGlzIHdoYXQgdGhlIHNwaXJpdCBvZiBhdWRpZW5jZSBhbmQgcmVzb3Vy Y2UNCg0KICAgICAgICBpbmRpY2F0b3JzIHNlZW0gdG8gaW1wbHkuDQoNCg0KDQogICAgICAgICDD r8K/wr3Dr8K/wr0gV2h5IE1VU1QgdGhlIEFTIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtb3JlIHRo YW4gb25lIHJlc291cmNlDQoNCiAgICAgICAgcGFyYW1ldGVyPyBJZiBhIHJlcXVlc3QgY29tZXMg aW4gd2l0aCBubyByZXNvdXJjZSBwYXJhbWV0ZXIgYW5kIG11bHRpcGxlDQoNCiAgICAgICAgc2Nv cGVzIHRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gcmVqZWN0IHRoYXQgcmVxdWVzdC4gSXMgdGhl cmUgbXVjaCBvZiBhDQoNCiAgICAgICAgc2VtYW50aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0 d28/IEluIHRoZSBjYXNlIG9mIG5vIHJlc291cmNlDQoNCiAgICAgICAgcGFyYW1ldGVyIGFuZCBt dWx0aXBsZSBzY29wZXMgdGhlIEFTIG1pZ2h0IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoDQoN CiAgICAgICAgbXVsdGlwbGUgYXVkaWVuY2UgdmFsdWVzIChhcyBpcyBhbGxvd2VkIGJ5IFJGQyA3 NTE5KS4gQWxzbywgdGhlIGF1ZGllbmNlDQoNCiAgICAgICAgY2xhaW0gaXMgbm90IHNvbGVseSBm b3IgcmVzb3VyY2UgaW5kaWNhdG9yIHZhbHVlcyBidXQgaXMgZGVmaW5lZCB0byBqdXN0DQoNCiAg ICAgICAgYmUgYSBzdHJpbmcuIFRvIG1lIGl0IGZlZWxzIGxpa2UgdGhlIHRleHQgaXMgaW1wbHlp bmcgdGhhdCB0aGUgb25seQ0KDQogICAgICAgIHZhbGlkIGF1ZGllbmNlIHZhbHVlIGlzIGFsc28g YSByZXNvdXJjZSBpbmRpY2F0b3IgKHdoaWNoIGZyb20gcHJldmlvdXMNCg0KICAgICAgICBkaXNj dXNzaW9ucyBvbiB0aGUgbGlzdCBpdCB3YXMgaW1wbGllZCB0aGV5IGhhdmUgYSBzbGlnaHRseSBk aWZmZXJlbnQNCg0KICAgICAgICBzZW1hbnRpYykuDQoNCg0KDQogICAgICAgICDDr8K/wr3Dr8K/ wr0gVGhlIG1vZGVsIGRlc2NyaWJlZCBoZXJlIHdvcmtzIHdlbGwgaWYgbXljby5leGFtcGxlIHJl YWxseSBvbmx5DQoNCiAgICAgICAgcHJvdmlkZXMgYSBzaW5nbGUgc2VydmljZS4gQnV0IGlmIGlu c3RlYWQgbXljby5leGFtcGxlIHByb3ZpZGVzIG11bHRpcGxlDQoNCiAgICAgICAgc2VydmljZXMg ZWFjaCB3aXRoIHRoZWlyIG93biBlbmRwb2ludHMgKHNydmEubXljby5leGFtcGxlLA0KDQogICAg ICAgIHNydmIubXljby5leGFtcGxlKSBhbmQgc2NvcGVzLCBmb3IgbWUgdGhpcyBtb2RlbCBiZWdp bnMgdG8gYnJlYWsgZG93bi4NCg0KICAgICAgICBFaXRoZXIgbW9iaWxlIGFwcHMgYXJlIHJlcXVp cmVkIHRvIGRvd25zY29wZSBhbGwgdG9rZW5zIHRvIGp1c3QgdGhlDQoNCiAgICAgICAgc2Vydmlj ZSB0aGV5IGFyZSBjYWxsaW5nIGF0IHRoYXQgcG9pbnQgaW4gdGltZSAod2hpY2ggY2FuIGhhdmUg bGF0ZW5jeQ0KDQogICAgICAgIGFuZCBjb25uZWN0aXZpdHkgaXNzdWVzKSwgb3IgbXljby5leGFt cGxlIGhhcyB0byBjcmVhdGUgYSBnZW5lcmljDQoNCiAgICAgICAgImF1ZGllbmNlIiBzdHJpbmcg dGhhdCByZXByZXNlbnRzIGFsbCBvZiBleGFtcGxlLmNvbSB3aGljaCBkb2Vzbid0IHNlZW0NCg0K ICAgICAgICB0byBiZSB0aGUgc3Bpcml0IG9mIHRoZSBleGlzdGluZyBzcGVjcy4NCg0KDQoNCiAg ICAgICAgIMOvwr/CvcOvwr/CvSBJbiBzdW1tYXJ5LCBJIGZlZWwgdGhhdCB0aGlzIHRleHQgaXMg YmluZGluZyB0b28gdGlnaHRseSByZXNvdXJjZQ0KDQogICAgICAgIGluZGljYXRvcnMgdG8gdGhl IGF1ZGllbmNlIGNsYWltLiBXaGF0IGlzIGRlc2NyaWJlZCBpcyBwZXJmZWN0bHkNCg0KICAgICAg ICByZWFzb25hYmxlIGluIGEgdXNlIGNhc2UgdGhhdCBpcyBhcHBseWluZyByZXNvdXJjZSBpbmRp Y2F0b3JzIGluIHRoaXMNCg0KICAgICAgICB3YXkgYnV0IGlzIG5vdCBpbmRpY2F0aXZlIG9mIHRo ZSB3aWRlbHkgZGVwbG95ZWQgbW9kZWxzIHRoYXQgYWxyZWFkeSBleGlzdC4NCg0KDQoNCiAgICAg ICAgU2VjdGlvbiA0LiBWYWxpZGF0aW5nIEpXVCBBY2Nlc3MgVG9rZW5zDQoNCiAgICAgICAgIMOv wr/CvcOvwr/CvSBTdGVwIDQuIC0tIENhbiB3ZSBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gbm90IHJl cXVpcmUgcmVzb3VyY2UNCg0KICAgICAgICBpbmRpY2F0b3JzPyBXaGF0IGFib3V0Li4uICJUaGUg cmVzb3VyY2Ugc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhhdCB0aGUNCg0KICAgICAgICAnYXVkJyBj bGFpbSBjb250YWlucyBhIHN0cmluZyB0aGF0IHJlcHJlc2VudHMgdGhlIGF1ZGllbmNlIG9mIHRo aXMNCg0KICAgICAgICByZXNvdXJjZSBzZXJ2ZXIuIg0KDQoNCg0KICAgICAgICBTZWN0aW9uIDUu ICJjcm9zcy1KV1QgY29uZnVzaW9uIg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gSSB0aGluayB0 aGVyZSBtYXkgYmUgY29uZnVzaW9uIGFyb3VuZCB3aGF0IGlzIG1lYW50IGJ5ICJkaXN0aW5jdA0K DQogICAgICAgIHJlc291cmNlcyIuIEluIG15IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28u ZXhhbXBsZSBhbmQNCg0KICAgICAgICBzcnZiLm15Y28uZXhhbXBsZSAiZGlzdGluY3QgcmVzb3Vy Y2VzIj8gb3IgaXMgdGhlIGdvYWwgaGVyZSB0byBzYXkgdGhhdA0KDQogICAgICAgIHdlIHdhbnQg ZGlmZmVyZW50IGF1ZGllbmNlIHZhbHVlcyBnZW5lcmF0ZWQgZm9yIGNyb3NzLW9yZ2FuaXphdGlv bg0KDQogICAgICAgIHJlc291cmNlcy4gRm9yIGV4YW1wbGUsIGFyZSBtYWlsLmdvb2dsZS5jb20g YW5kIHlvdXR1YmUuY29tICJkaXN0aW5jdA0KDQogICAgICAgIHJlc291cmNlcyI/IG9yIHdvdWxk IGFuIGF1ZGllbmNlIGZvciBnb29nbGUgc3VmZmljZSBpbiBtZWV0aW5nIHRoZQ0KDQogICAgICAg IG1lYW5pbmcgb2YgdGhpcyBwYXJhZ3JhcGg/DQoNCg0KDQogICAgICAgICDDr8K/wr0gSSdtIGhh dmluZyB0aGUgc2FtZSBjb25mdXNpb24gaW4gdGhlIG5leHQgcGFyYWdyYXBoIHJlZ2FyZGluZyB0 aGUNCg0KICAgICAgICBwaHJhc2UgImRpZmZlcmVudCByZXNvdXJjZXMiLiBBcmUgc2VydmljZXMg cHJvdmlkZWQgYnkgdGhlIHNhbWUgY29tcGFueQ0KDQogICAgICAgICJkaWZmZXJlbnQgcmVzb3Vy Y2VzIiBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2FtZSByZXNvdXJjZS4gQ2FuDQoN CiAgICAgICAgYW4gYWNjZXNzIHRva2VuIGJlIGlzc3VlZCB3aXRoIHNjb3BlcyBmb3IgYm90aCBt YWlsLmdvb2dsZS5jb20gYW5kDQoNCiAgICAgICAgeW91dHViZS5jb20/IEFuZCBpZiBub3QsIHdo eSBub3RlPyBQcmV2ZW50aW5nIHRoaXMgcHV0cyB1bmR1ZSBidXJkZW4gb24NCg0KICAgICAgICBt b2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLg0KDQoNCg0KICAgICAgICBTZWN0aW9uIDYuIFByaXZh Y3kNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IGNvZmlkZW50aWFsaXR5IC0tPiBjb25maWRlbnRp YWxpdHkNCg0KDQoNCg0KDQogICAgICAgIFRoYW5rcywNCg0KICAgICAgICBHZW9yZ2UNCg0KDQoN Cg0KDQoNCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQogICAgT0F1dGggbWFpbGluZyBsaXN0DQoNCiAgICBPQXV0aEBpZXRmLm9yZw0K DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K DQo= --_000_MWHPR19MB1501ACC81394A8D8B19050F1AEC70MWHPR19MB1501namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyBBbm5h YmVsbGUgYW5kIEdlb3JnZSEgJm5ic3A7SSBhbSBjb25zb2xpZGF0aW5nIHJlcGxpZXMgdG8gYm90 aCB5b3VyIGxhdGVzdCBjb21tZW50cyBpbiB0aGlzIG1haWwuIFRoaXMgc2VlbXMgYSBoYXJkIHJv Y2sgdG8gbGlmdCwgYnV0IGl0IGFsc28gc2VlbXMgdG8gYmUgdGhlIGxhc3Qgb25lDQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTIy Ozwvc3Bhbj4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgVEw7 RFIgaXMsIEkgYW0gbm90IGNvbXBsZXRlbHkgb3Bwb3NlZCB0byByZWxheGluZyB0aGUgY29uc3Ry YWludHMgYW5kIHR1cm5pbmcgdGhlbSBpbnRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBidXQg SSB0aGluayB3ZeKAmWQgbWlzcyBhbiBvcHBvcnR1bml0eSB0byBtYWtlIHRoaW5ncyBjbGVhcmVy IGZvciBkZXZlbG9wZXJzLiBBdCB0aGUgc2FtZSB0aW1lIEkgd291bGRu4oCZdCB3YW50IHRvIG1h a2UNCiB0aGlzIHByb2ZpbGUgdG9vIHBhdHJvbml6aW5nLCBoZW5jZSBJIGFwcHJlY2lhdGUgdGhl IG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPltB bm5hYmVsbGVdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsg PGk+Jmd0Oy4gVGhlcmUgbWF5IGJlIG5vICZxdW90O3Njb3BlJnF1b3Q7IHBhcmFtZXRlci4gJm5i c3A7VGhlICZxdW90O3Njb3BlJnF1b3Q7IHBhcmFtZXRlciBpcyBPUFRJT05BTCBpbiBhdXRob3Jp emF0aW9uIHJlcXVlc3RzLiBTbyBhbiBBUy9SUyBvcGVyYXRvciBjb3VsZCBkZWNpZGUgdGhleSdy ZSBnb2luZyB0byBvbWl0ICZxdW90O3Njb3BlJnF1b3Q7IGVudGlyZWx5IGFuZCB1c2UgbXVsdGlw bGUgcmVzb3VyY2UgcGFyYW1ldGVycyBpbnN0ZWFkLiBTaW5jZSB0aGVyZQ0KIGFyZSBubyBzY29w ZXMsIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciBjb25mdXNpb24uPG86cD48L286cD48L2k+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBhbSBhIEJJRyBmYW4gb2YgQVRzIHdpdGgg bm8gc2NvcGUtIGFsbCB0aGUgc2NlbmFyaW9zIHdoZXJlIHRoZXJl4oCZcyBubyBkZWxlZ2F0aW9u ICgxPHN1cD5zdDwvc3VwPiBwYXJ0aWVzIGV0Yykgc2hvdWxkbuKAmXQgdXNlIHNjb3BlcyBhdCBh bGwuIFRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGRvZXMgYWxsb3cgZm9yIHNj b3BlLWxlc3MgQVRzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZ29hbCBpcw0KIHRvIHByZXZlbnQgY29u ZnVzaW9uLCBJIGFncmVlIHRoYXQgdGhlcmXigJlzIG5vIG5lZWQgdG8gcmVzdHJpY3QgdGhlIGF1 ZGllbmNlIHRvIG9uZSBzaW5nbGUgcmVzb3VyY2UgaWYgdGhlcmUgYXJlIG5vIHNjb3BlcyBhdCBh bGwgdG8gbWlzaW50ZXJwcmV0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkkgd291bGQgYmUgaW4gZmF2b3IgdG8gYWxsb3cgbXVsdGlwbGUgcmVzb3VyY2Vz IGluIGF1ZGllbmNlIGluIHRoYXQgY2FzZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+VW5mb3J0dW5hdGVseSBpdOKAmXMgbm90IGFzIHNpbXBsZSBhcyBqdXN0IHNh eWluZyDigJxJZiB0aGUgaW5jb21pbmcgcmVxdWVzdCBpbmN1ZGVzIG11bHRpcGxlIHJlc291cmNl IGluZGljYXRvcnMgYW5kIG5vIHNjb3BlLCBhY2NlcHQgaXQgYW5kIHVzZSB0aGUgaW5jb21pbmcg cmVzb3VyY2UgaW5kaWNhdG9ycyBsaXN0IGFzIGF1ZCB2YWx1ZeKAnSDigJMgbW9zdGx5IGJlY2F1 c2UgdGhlcmUgaXMgYSB2ZXJ5IGxhcmdlDQogbnVtYmVyIG9mIHByb2R1Y3Rpb24gc3lzdGVtcyB3 aGVyZSB0aGUgcmVxdWVzdCBpbmNsdWRlcyBubyBzY29wZXMgYW5kIG9uZSByZXNvdXJjZSBpbmRp Y2F0b3IsIGJ1dCB0aGUgcmVzdWx0aW5nIHRva2VuIGluY2x1ZGVzIGEgY29sbGVjdGlvbiBvZiBz Y29wZXMgdGhlIHVzZXIgYWxyZWFkeSBjb25zZW50ZWQgdG8gZm9yIHRoYXQgcmVzb3VyY2UtIGJ1 dCBJIGFtIHN1cmUgd2UgY2FuIGdldCB0byBhY2NlcHRhYmxlIGxhbmd1YWdlIHRoYXQgZXhwcmVz c2VzDQogdGhlIGNvbmNlcHQg4oCcaWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlc291cmNlIGluZGlj YXRvcnMgaW4gdGhlIHJlcXVlc3QgYW5kIHRoZSByZXN0IG9mIHRoZSBydWxlcyBpbiBTLjMgdGhl IHJlc3VsdGluZyBBVCB3b27igJl0IGNvbnRhaW4gYSBzY29wZSBjbGFpbSwgdGhlIHJlc3VsdGlu ZyBBVCBtdXN0IHVzZSB0aGF0IHJlc291cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXi gJ0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+Jmd0OyBBbiBBUy9SUyBvcGVy YXRvciBtYXkgdXNlICZxdW90O3Njb3BlJnF1b3Q7IHRvIGluZGljYXRlIGEgcm9sZSBvciBwb2xp Y3kgKG9yIHNldCBvZiBwb2xpY2llcykgdGhhdCB0aGUgY2xpZW50IHdhbnRzLCBhbmQgYWxsb3cg dGhlIGNsaWVudCB0byBuYXJyb3cgdGhlaXIgcGVybWlzc2lvbnMgdXNpbmcgJnF1b3Q7cmVzb3Vy Y2UmcXVvdDsgcGFyYW1ldGVycy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG9idGFp biBuYXJyb3dseQ0KIHNjb3BlZCBhY2Nlc3MgdG9rZW5zIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMg d2l0aG91dCBuZWVkaW5nIHRvIGRlZmluZSBzZXBhcmF0ZSByb2xlcy9wb2xpY2llcyBmb3IgZWFj aC4gSW4gdGhpcyBjYXNlLCBhIEpXVCBBVCB3aXRoIGEgbXVsdGktdmFsdWVkICZxdW90O2F1ZCZx dW90OyBjbGFpbSBhbmQgYSAmcXVvdDtzY29wZSZxdW90OyBjbGFpbSB3b3VsZCBzZWVtIGFwcHJv cHJpYXRlLCBhcyB0aGUgc2NvcGUgY2xhaW0gaXMgaW50ZW5kZWQgdG8gYXBwbHkgdG8gYWxsIG9m IHRoZQ0KIGF1ZGllbmNlIHZhbHVlcy48bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGFncmVlIHRoYXQgZGVwbG95bWVudHMgbGlrZSB0aGUgb25lIHlvdSBkZXNj cmliZSBtaWdodCBleGlzdCwgaW4gZmFjdCBJIGFtIHN1cmUgdGhleSBkby4gSG93ZXZlciBpdCBz ZWVtcyByZWFsbHkgYSBicml0dGxlIGFwcHJvYWNoLCBnaXZlbiB0aGF0IGl0IG1ha2VzIGEgc3Bl Y2lmaWMgYXNzdW1wdGlvbiAoc2NvcGVzIGFyZSB2YWxpZCBhY3Jvc3MgYWxsIHRoZSByZXNvdXJj ZXMpIHRoYXQgaXNu4oCZdCBlbnNocmluZWQNCiBhbnl3aGVyZSBhbmQgaWYgZnV0dXJlIHVwZGF0 ZXMgdG8gdGhhdCBkZXBsb3ltZW50IHZpb2xhdGUgdGhhdCBhc3N1bXB0aW9uLCB0aGF0IHdvdWxk IGxlYWQgdG8gdGhlIHNjb3BlIGNvbmZ1c2lvbiB0aGUgY3VycmVudCBsYW5ndWFnZSBpbiB0aGUg cHJvZmlsZSBpcyB0cnlpbmcgdG8gcHJldmVudC4gV2Ugb2ZmZXIgdmVyeSBsaXR0bGUgZ3VpZGFu Y2UgaW4gdGhhdCByZXNwZWN0OiB0aGUgbWFpbiBwbGFjZSB3ZXJlIG11bHRpcGxlIHJlc291cmNl cw0KIGFyZSBldmVuIG1lbnRpb25lZCBpcyByZXNvdXJjZSBpbmRpY2F0b3JzLCBhbmQgYWxsIHRo ZSBzYW1wbGVzIChJIGtub3csIG5vbi1ub3JtYXRpdmUpIHVzZSBzY29wZXMgdW5hbWJpZ3VvdXNs eSB0aWVkIHRvIGEgc3BlY2lmaWMgcmVzb3VyY2UgKG1vcmUgb24gdGhhdCBsYXRlcikgbWFraW5n IHRoZSBtdWx0aS1yZXNvdXJjZSBzY29wZSBldmVuIG1vcmUgb2YgYSBzcGVjaWFsIGNhc2UuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RlcHBpbmcgYmFjayBhIGJpdCAtIHRoZSBp bnRlbnQgYmVoaW5kIHRob3NlIHJlc291cmNlLXNjb3BlIHJlc3RyaWN0aW9ucyBpcyB0byBwcm92 aWRlIGEgYml0IG1vcmUgZ3VpZGFuY2Ugb24gc2NvcGVzIGFuZCByZXNvdXJjZXMgdGhhbiB3ZSBk aWQgaW4gdGhlIHBhc3QsIGFuZCBuYXJyb3dpbmcgdGhlIHJhbmdlIG9mIGNhc2VzIGRldmVsb3Bl cnMgd291bGQgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudA0KIHdoZW4gaW1wbGVtZW50aW5nIHRo ZSBwcm9maWxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gbXkg ZXhwZXJpZW5jZSB0aGUgbGFjayBvZiBtb3JlIHByZXNjcmlwdGl2ZSBndWlkYW5jZSBsZWQgdG8g ZGVwbG95bWVudHMgYW5kIGludGVycHJldGF0aW9ucyB0aGF0LCB3aGlsZSByZW1haW5pbmcgZnVs bHkgd2l0aGluIHRoZSBib3VuZGFyeSBvZiB3aGF0IHRoZSBzcGVjIGFsbG93cywgYXJlIG9mdGVu IHF1ZXN0aW9uYWJsZSBmcm9tIHRoZSBzZWN1cml0eSBhbmQgYXJjaCBwZXJzcGVjdGl2ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPigqKUkgYWNrbm93bGVkZ2UgdGhh dCBJIG1pZ2h0IGJlIHN3aW5naW5nIHRvbyBmYXIgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiwg YW5kIHBlcmhhcHMgYSBzaW1pbGFyIGVmZmVjdCBjb3VsZCBiZSBhY2hpZXZlZCBieSBhZGRpbmcg YW4g4oCcQXV0aG9yaXphdGlvbiBDb25zaWRlcmF0aW9uc+KAnSBzZWN0aW9uIHdoZXJlIGltcGxl bWVudGVycyBhcmUgd2FybmVkIGFib3V0IHRoZSBkYW5nZXIgb2Ygc2NvcGUgY29uZnVzaW9uDQog cmF0aGVyIHRoYW4gZG93bnJpZ2h0IGZvcmJpZGRpbmcgbXVsdGkgcmVzb3VyY2VzIGF1ZGllbmNl cyB3aGVuIGluY2x1ZGluZyBzY29wZXMgYXMgd2VsbC4gSSBzdGlsbCBsaWtlIHRoZSBzaW1wbGlj aXR5IGFuZCBjbGFyaXR5IG9mIHRoZSBjdXJyZW50IHJlc3RyaWN0aW9uLCBidXQgb2YgY291cnNl IEkgYW0gb3BlbiB0byBmZWVkYmFjay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGk+Jmd0OyBUaGUgbWFwcGluZyBiZXR3ZWVuIGF1ZGllbmNlIGFuZCBzY29wZSBt YXkgYmUgdW5hbWJpZ3VvdXMuPC9pPg0KPGk+VGhlcmUgYXJlIGEgbG90IG9mIGRlcGxveW1lbnRz IHRvIHdoaWNoIHRoZSBibGFzdCByYWRpdXMgcmlzayB5b3UncmUgdHJ5aW5nIHRvIGFkZHJlc3Mg YnkgcmVxdWlyaW5nICZxdW90O2F1ZCZxdW90OyBzaW1wbHkgZG9lcyBub3QgYXBwbHk8bzpwPjwv bzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGVyZSBhcmUgY2VydGFpbmx5 IGNhc2VzIHdoZXJlIHNjb3BlIHN0cmluZ3MgdW5hbWJpZ3VvdXNseSBtYXAgdG8gc3BlY2lmaWMg cmVzb3VyY2VzLCBidXQgb25jZSBhZ2FpbiwgdGhhdOKAmXMgYSBzdHJvbmcgYXNzdW1wdGlvbiB0 byBtYWtlIGFuZCBvbmUgSSBmZWVsIGNhbm5vdCBiZSBtYWRlIGxpZ2h0bHkuIFJlc291cmNlIGlu ZGljYXRvcnMgdXNlIHZlcnkgc2ltcGxlIGV4YW1wbGVzIChjb250YWN0cywNCiBjYWxlbmRhcikg dGhhdCBhcmUgaGFyZCB0byBnZW5lcmFsaXplIHRvIHNjZW5hcmlvcyB3aGVyZSB0aGUgbnVtYmVy IGFuZCBsaWZlY3ljbGUgb2YgcmVzb3VyY2VzIHRydWx5IGNhbGxzIGZvciB0aGUgdXNlIG9mIGlu ZGljYXRvcnMgaWRlbnRpZnlpbmcgYSByZXNvdXJjZSBpbiBhIGxhcmdlIG11bHRpdGVuYW50IHN5 c3RlbSB1c3VhbGx5IGVudGFpbHMgbGFyZ2UgaWRlbnRpZmllcnMsIGFuZCBzdHVmZmluZyB0aG9z ZSBpbiB0aGUgc2NvcGUgdG8NCiBwcmV2ZW50IGFtYmlndWl0eSBjYW4gYmUgZXhwZW5zaXZlIGZy b20gYm90aCBwcm92aXNpb25pbmcgYW5kIHRva2VuLCByZXF1ZXN0IHNpemUgYW5nbGVzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48aT4mZ3Q7SXQgbWF5IHNlZW0gaW5ub2N1b3VzIHRv IHJlcXVpcmUgdGhlc2UgZGVwbG95bWVudHMgdG8gZXhwbGljaXRseSBpbmNsdWRlIGEgYnJvYWQg YXVkaWVuY2UgbGlrZSAmcXVvdDthcGkuZXhhbXBsZS5jb20mcXVvdDsgYW55d2F5LCB0aGF0IGNh biBsZWFkIHRvIGltcGxlbWVudGVycyBpZ25vcmluZyB0aGUgcmVxdWlyZW1lbnQgKGxlYWRpbmcg dG8gaW50ZXJvcCBpc3N1ZXMpLCBub3QgdmFsaWRhdGluZyBpdCAoYWxzbw0KIGxlYWRpbmcgdG8g aW50ZXJvcCBpc3N1ZXMgb3Igc2VjdXJpdHkgaXNzdWVzIGlmIHRoZSBkZXBsb3ltZW50IHdhbnRz IHRvIHN0YXJ0IGFjdHVhbGx5IHVzaW5nIGl0IGZvciByZWFsKSwgb3IgZG9pbmcgc29tZXRoaW5n IGZ1bmt5IHdpdGggaXQgc2luY2UgdGhlcmUgaXNuJ3QgYW55dGhpbmcgJnF1b3Q7cmVhbCZxdW90 OyB0aGF0IHRoZSB2YWx1ZSBuZWVkcyB0byBjb25mb3JtIHRvLjwvaT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkV2ZXJ5IHNwZWMgZ3VpZGFuY2Ugcmlza3Mgbm90IGJl aW5nIGZvbGxvd2VkLiBCdXQgaW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHVzZSBvZiBhIGxvZ2lj YWwgYXVkaWVuY2UgaXMgcXVpdGUgbWFpbnN0cmVhbSDigJMgd2UgaGFkIGEgc2ltaWxhciBkaXNj dXNzaW9uIGZvciByZXNvdXJjZSBpbmRpY2F0b3JzIGFuZCB0aGF04oCZcyB3aHkgdGhlIHNwZWMg ZW5kZWQgdXAgaW5jbHVkaW5nIGxvZ2ljYWwgaWRlbnRpZmllcnMNCiBhcyBvbmUgb2YgdGhlIHJl c291cmNlIHBhcmFtZXRlciBmbGF2b3IuIOKAnHJlYWzigJ0gaXMgYSByZWxhdGl2ZSB0ZXJtLCBn aXZlbiB0aGF0IHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgZGlmZmVyZW50IHdheXMgaW4gd2hpY2gg YSBsb2dpY2FsIHJlc291cmNlIG1pZ2h0IG1hcCB0byBkaWZmZXJlbnQg4oCccGh5c2ljYWzigJ0g YXJ0aWZhY3RzIChzZWUgaGVyb2t14oCZcyBsYXRlIGJpbmRpbmcgVVJMcykuIENvbGxlY3RpdmUg YXVkaWVuY2VzIGFyZSBpbiBjb21tb24NCiB1c2UgZm9yIHBvb3IgbWFu4oCZcyB0cnVzdGVkIHN1 YnN5c3RlbXM6IG5vdCBlbmRvcnNpbmcgdGhlIGFwcHJvYWNoLCBidXQgYnJpbmdpbmcgY2lyY3Vt c3RhbnRpYWwgZXZpZGVuY2UgdGhhdCBicm9hZCBhdWRpZW5jZXMgYXJlbuKAmXQgdGhhdCB1bmNv bW1vbiBvciBoYXJkIHRvIGdyb2sgZm9yIGRldmVsb3BlcnMgYWxyZWFkeSB0b2RheS4gRmluYWxs eSwgdHVybmluZyBvZmYgdmFsaWRhdGlvbiBpcyBhY3R1YWxseSBub3QgdGhhdCB0cml2aWFsIGlu DQogbWFueSBTREtzLCBnaXZlbiB0aGF0IHRoZXkgbW9zdGx5IHJldXNlL2Rlcml2ZSBmcm9tIE9J REMgYW5kIHRoZSBhdWRpZW5jZSBjaGVjayBpcyBtYW5kYXRvcnk6IEkgc2F3IG1vcmUgb2Z0ZW4g cGVvcGxlIGRpc2FibGluZyBpc3MgY2hlY2sgdGhhbiBhdWQuIE5vbmUgb2YgdGhpcyBtZWFucyB0 aGF0IHRoZSBlcnJvcnMgeW91IGRlc2NyaWJlIGNhbm5vdCBoYXBwZW46IGJ1dCBJIHRoaW5rIHRo ZXkgYXJlbuKAmXQgbW9yZSBsaWtlbHkgdGhhbiBhbnkNCiBvdGhlciBndWlkYW5jZSBpbiB0aGUg c3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgZG8gYWNrIHRo ZSBtb3JlIGdlbmVyaWMgcG9pbnQgdGhhdCwgbGlrZSBpbiB0aGUgcHJlY2VkaW5nIGNhc2UsIHRo aXMgbWlnaHQgc3VnZ2VzdCB0aGF0IHRoZSBjdXJyZW50IGd1aWRhbmNlIGlzIHRvbyBzdHJpY3Qt IHNlZSAoKikNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5bR2VvcmdlXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGk+Jmd0 O0kgdGhpbmsgb25lIG9mIHRoZSBwcm9ibGVtcyB3ZSBoYXZlIGluIGJlaW5nIHN1cGVyIHNwZWNp ZmljIGFib3V0IGhvdyB0aGUgSldUIGFjY2VzcyB0b2tlbiBpcyBjb25zdHJ1Y3RlZCBpcyB0aGF0 IGlzIG1lYW5zIGl0J3Mgbm90IHBvc3NpYmxlIGZvciBtYW55IG9yZ2FuaXphdGlvbnMgdG8gZm9s bG93LiBIb3cgc2NvcGVzIGFyZSBpbXBsZW1lbnRlZCBpcyB2ZXJ5IHZhcmllZCBhY3Jvc3MgZGVw bG95bWVudHMNCiB3aGljaCBtZWFucyB0aGF0IHNvbWUgbWF5IGNvbmZvcm0gdG8gdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSBzcGVjIGFuZCBtYW55IG1heSBub3QuPG86cD48L286cD48L2k+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WW91IGFyZSByaWdodCwgdGhlIHNwZWMgJm5ic3A7aXMg YW4gb3BpbmlvbmF0ZWQgdGFrZS0gSSBhZ3JlZSB0aGF0IG1hbnkgb3JnYW5pemF0aW9ucyB1c2Vk IHNjb3BlcyBpbiB2ZXJ5IGRpZmZlcmVudCB3YXlzLCBhbmQgSSB0aGluayBpdCBpcyB0aGUgcmVz dWx0IG9mIGdpdmluZyB2ZXJ5IGxpdHRsZSBndWlkYW5jZSBvbiBzY29wZXMgYW5kIHJlc291cmNl cywgd2l0aCB0aGUgY29uc2VxdWVuY2UgdGhhdCBzb21lDQogY2hvaWNlcyBtaWdodCBoYXZlIGJl ZW4gbGVzcyB3aXNlIHRoYW4gb3RoZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2l0aCB0aGUgY3VycmVudCBndWlkYW5jZSBJIGF0dGVtcHRlZCB0byBjYXB0dXJl IGEgbmFycm93ZXIgc2V0IG9mIHNjZW5hcmlvcyB3aGVyZSBzb21lIG9mIHRoZSBtb3N0IG9idmlv dXMgaXNzdWVzIChsaWtlIHNjb3BlIGNvbmZ1c2lvbikgY2FuIGJlIGF2ZXJ0ZWQsIHdoaWxlIHN0 aWxsIHNhdGlzZnlpbmcgbW9zdCBvZiB0aGUgY2FzZXMgSSBvYnNlcnZlZCBpbiB0aGUgc2FtcGxl IEpXVCBBVHM6IEkgYW0NCiBub3QgdHJ5aW5nIHRvIG92ZXJpbmRleCBvbiB0aG9zZSBjYXNlcywg YW5kIEkgZG9u4oCZdCBtZWFuIHRvIGltcGx5IHRoYXQgdGhlIHByb2ZpbGUgc2hvdWxkIHN0cmlj dGx5IGZvbGxvdyB0aG9zZSwgYnV0IGluIHRoZSBzcGlyaXQgb2YgZWxpbWluYXRpbmcgYW1iaWd1 aXR5IGFzIG11Y2ggYXMgcG9zc2libGUsIHRoaXMgc2luZ2xlIHJlc291cmNlIG5hcnJvd2luZyBz ZWVtZWQgYSBzb2xpZCBjb3JlIHRvIGJ1aWxkIHJvYnVzdCBpbXBsZW1lbnRhdGlvbnMNCiBvbi0g ZnVsbHkgYXdhcmUgb2YgdGhlIGZhY3QgdGhhdCBtYW55IGN1cnJlbnQgaW1wbGVtZW50YXRpb25z IHdvdWxkIG5vdCBjb25mb3JtICh0aG8gSSBhbSBub3Qgc3VyZSBob3cgbWFueSBpbXBsZW1lbnRh dGlvbnMgYWxyZWFkeSBhZG9wdGVkIHJlc291cmNlIGluZGljYXRvcnMgb3IgZXF1aXZhbGVudCku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiBhbnkgY2FzZSwgc2Vl ICgqKS0gSSB0aGluayBJIGNhbiBiZSBjb252aW5jZWQgdG8gdHVybiB0aGUgY3VycmVudCByZXN0 cmljdGlvbnMgaW50byBzZWN1cml0eS9hdXRob3JpemF0aW9uIGNvbnNpZGVyYXRpb25zLSBidXQg SSB3b3VsZCByZWx1Y3RhbnRseSBkbyBzbyBhcyBJIHRoaW5rIHdl4oCZZCBwZXJwZXR1YXRlIGEg bG90IG9mIHRoZSBhbWJpZ3VpdHkgd2UgaGF2ZSBpbiB0aGlzIHNwYWNlIHRvZGF5Lg0KICZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48aT4mZ3Q7UGVyc29uYWxseSwg SSdtIG5vdCBhIGJpZyBmYW4gb2YgdHJ5aW5nIHRvIHVzZSBzY29wZXMgZm9yIGZpbmUtZ3JhaW4g YXV0aG9yaXphdGlvbi4gSSBkb24ndCB0aGluayB0aGF0IGlzIHdoYXQgdGhleSB3ZXJlIGludGVu ZGVkIGZvciB3aGVuIG9yaWdpbmFsbHkgZGVzaWduZWQuIChUaGlzIGNhbiBiZSBzZWVuIGJ5IHRo ZSBSQVIgc3BlYyBpbnRyb2R1Y2luZyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50DQogd2F5IG9mIHNw ZWNpZnlpbmcgZmluZS1ncmFpbiBhdXRob3JpemF0aW9uIGNvbnRleHQuKSBFdmVuIGluIG11bHRp LXRlbmFudCBzeXN0ZW1zLCBJIGRvbid0IHNlZSBpc3N1ZXMgd2l0aCB1c2luZyBzdWItcmVzb3Vy Y2Ugc2NvcGVzIGFzIGVhY2ggdGVuYW50IHNob3VsZCBkZWZpbmUgdGhlIHNjb3BlcyB0aGF0IG1h a2Ugc2Vuc2UgZm9yIHRoYXQgdGVuYW50LiBJIGRvbid0IHRoaW5rIHRoZSBBUyBuZWVkcyB0byB1 bmRlcnN0YW5kIHRoZSBzY29wZXMsDQoganVzdCBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIGlzc3Vl IHRoZSBjb3JyZWN0IHNjb3BlIHVuZGVyIHVzZXIgY29uc2VudCB0byB0aGUgY2xpZW50IGFuZCBs ZXQgdGhlIFJTIGFwcGx5IHRoZSBhdXRob3JpemF0aW9uIHBvbGljeSB3aGVuIGl0IGdldHMgdGhl IHNjb3BlcyBvdXQgb2YgdGhlIHRva2VuLjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkgYW0gbm90IGNyYXp5IGFib3V0IHRoYXQgZWl0aGVyLSBlc3BlY2lhbGx5 IGdpdmVuIHRoYXQgd2hlbiBmaW5lIGdyYWluZWQgYXV0aFogaXMgaW52b2x2ZWQgdmVyeSwgdmVy eSBvZnRlbiB3aGF0IGRldmVsb3BlcnMgcmVhbGx5IHdhbnQgYXJlIHVzZXIgcHJpdmlsZWdlcyBh bmQgc2NvcGVzIGFyZSBqdXN0IGFidXNlZCBpbiBsaWV1IG9mIHByaXZpbGVnZXMgc2ltcGx5IGJl Y2F1c2UgdGhlIHNwZWMgZG9lc27igJl0DQogYWRkcmVzcyB0aGUgbm9uLWRlbGVnYXRpb24gc2Nl bmFyaW8gaGVuY2UgYSBzY3Jld2RyaXZlciBlbmRzIHVwIGJlaW5nIHVzZWQgYXMgYSBoYW1tZXIu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5vbmV0aGVsZXNzLCBp ZiBzY29wZXMgYXJlIHVzZWQtIG1hbmRhdGluZyB0aGF0IGV2ZXJ5IHNjb3BlIGlzIHRpZWQgdG8g dGhlIHJlc291cmNlIGRvZXMgbGVhZCB0byBodWdlIHRva2VucyBhbmQgc2lnbmlmaWNhbnQgbWFu YWdlbWVudCBvdmVyaGVhZCBpZiB5b3UgaGF2ZSBsb3RzIG9mIHJlc291cmNlcyB3aG9zZSBpZGVu dGlmaWVyIG11c3QgYmUgZ2xvYmFsbHkgdW5pcXVlLCBub25yZWFzc2lnbmFibGUNCiBldGMgZXRj IGhlbmNlIHZlcnkgbGFyZ2Ug4oCTIGFuZCB0aGUgQVMgZG9lc27igJl0IG5lZWQgdG8gdW5kZXJz dGFuZCB0aGUgc2VtYW50aWMgb2YgZWFjaCBzY29wZSBidXQgaXQgZG9lcyBuZWVkIHRvIGtub3cg d2hldGhlciBhIHNjb3BlIGNhbiBiZSByZXF1ZXN0ZWQgZm9yIGEgZ2l2ZW4gcmVzb3VyY2UsIHBs dXMgYW55IHBvbGljeSB0aGUgYWRtaW4gbWlnaHQgd2FudCB0byBleGVjdXRlIGF0IHRva2VuIGlz c3VhbmNlIHRpbWUgKGVnIHRoaXMgc2NvcGUNCiByZXF1aXJlcyAyRkEpIGhlbmNlIGp1Z2dsaW5n IGxhcmdlIG51bWJlcnMgb2YgbGFyZ2Ugc3RyaW5ncyBjYW4gYmUgaGFyZCBmb3IgdGhlIEFTIOKA kyBhbmQgUlMuIEluIGFueSBjYXNlLCB0aGUgdXNlIG9mIG11bHRpcGxlIHJlc291cmNlcyBpbiB0 aGUgYXVkIGluIHRoZSB3aWxkIGFwcGVhcmVkIHRvIGJlIHZlcnkgcmFyZSwgaGVuY2UgZXZlbiBp ZiB0aGVyZSB3b3VsZCBiZSBhIGZvb2xwcm9vZiB3YXkgb2YgZGVmaW5pbmcgYSByZXNvdXJjZS1z Y29wZQ0KIG1hcHBpbmcsIEkgd291bGQgbm90IHNwZW5kIGN5Y2xlcyBkZWZpbmluZyBpdCBoZXJl 4oCmIGFuZCBsZWF2aW5nIGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIHdvdWxkbuKAmXQg d29yayBwZXIgdGhlIGFib3ZlLiBBcyBpbiAoKikgd2UgY291bGQgcmVsYXggdGhlIGNvbnN0cmFp bnQgaGVyZSBhbmQganVzdCB3YXJuIHBlb3BsZSBhZ2FpbnN0IHNjb3BlIGNvbmZ1c2lvbiwgYnV0 IEkgZmVlbCB3ZeKAmWQgYmUgbWlzc2luZyBhbiBvcHBvcnR1bml0eS4NCiAmbmJzcDsmbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPu+7v09uIDMvMjQvMjAsIDE3OjAwLCAmcXVvdDtSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUbyBib3Jyb3cg YSB0ZXJtIGZyb20gTUwsIEkgdGhpbmsgdGhlICZxdW90O2F1ZCZxdW90OywgJnF1b3Q7c2NvcGUm cXVvdDssIGFuZCByZXNvdXJjZSBpbmRpY2F0b3ItcmVsYXRlZCB0ZXh0IGlzIG92ZXJmaXR0ZWQg dG8gYSBzcGVjaWZpYyBzZXQgb2YgZGVwbG95bWVudCBzY2VuYXJpb3MsIGFuZCBhIHNwZWNpZmlj IHdheSBvZiB1c2luZyBzY29wZXMgYW5kIHJlc291cmNlIGluZGljYXRvcnMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtD b25zaWRlciB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MS4gVGhlcmUgbWF5IGJlIG5vICZxdW90 O3Njb3BlJnF1b3Q7IHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSAmcXVvdDtzY29wZSZxdW90OyBwYXJhbWV0ZXIg aXMgT1BUSU9OQUwgaW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0cy4gU28gYW4gQVMvUlMgb3BlcmF0 b3IgY291bGQgZGVjaWRlIHRoZXkncmUgZ29pbmcgdG8gb21pdCAmcXVvdDtzY29wZSZxdW90OyBl bnRpcmVseSBhbmQgdXNlIG11bHRpcGxlIHJlc291cmNlIHBhcmFtZXRlcnMgaW5zdGVhZC4gU2lu Y2UgdGhlcmUgYXJlIG5vIHNjb3BlcywgdGhlcmUgaXMgbm8gb3Bwb3J0dW5pdHkNCiBmb3IgY29u ZnVzaW9uLiBJbiB0aGlzIGNhc2UsIGEgSldUIEFUIHdpdGggYSBtdWx0aS12YWx1ZWQgJnF1b3Q7 YXVkJnF1b3Q7IGNsYWltIGFuZCBubyAmcXVvdDtzY29wZSZxdW90OyBjbGFpbSB3b3VsZCBzZWVt IGFwcHJvcHJpYXRlLiBXaGlsZSBtdWx0aXBsZSByZXNvdXJjZSBpbmRpY2F0b3JzIGNvdWxkIGJl IHB1c2hlZCBpbnRvIGEgc2luZ2xlIHNjb3BlIHN0cmluZywgdGhpcyBpbnRyb2R1Y2VzIG9wcG9y dHVuaXRpZXMgZm9yIHNlcmlvdXMgc2VjdXJpdHkgaW1wYWN0aW5nIGVuY29kaW5nL2RlY29kaW5n L3BhcnNpbmcNCiBidWdzLiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IGl0LCB0aGUgbW9yZSAmcXVv dDtJIGRvbid0IGhhdmUgdG8gZGVhbCB3aXRoIHBhcnNpbmcgYSBzY29wZSBzdHJpbmcmcXVvdDsg c2VlbXMgbGlrZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGdvIHRoaXMgcm91dGUuLi4gX188bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzIuIFRoZSBzY29wZXMgbWF5IGFwcGx5IHRvIGFsbCBhdWRpZW5jZXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBBbiBBUy9S UyBvcGVyYXRvciBtYXkgdXNlICZxdW90O3Njb3BlJnF1b3Q7IHRvIGluZGljYXRlIGEgcm9sZSBv ciBwb2xpY3kgKG9yIHNldCBvZiBwb2xpY2llcykgdGhhdCB0aGUgY2xpZW50IHdhbnRzLCBhbmQg YWxsb3cgdGhlIGNsaWVudCB0byBuYXJyb3cgdGhlaXIgcGVybWlzc2lvbnMgdXNpbmcgJnF1b3Q7 cmVzb3VyY2UmcXVvdDsgcGFyYW1ldGVycy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRv IG9idGFpbiBuYXJyb3dseQ0KIHNjb3BlZCBhY2Nlc3MgdG9rZW5zIGZvciBzcGVjaWZpYyB1c2Ug Y2FzZXMgd2l0aG91dCBuZWVkaW5nIHRvIGRlZmluZSBzZXBhcmF0ZSByb2xlcy9wb2xpY2llcyBm b3IgZWFjaC4gSW4gdGhpcyBjYXNlLCBhIEpXVCBBVCB3aXRoIGEgbXVsdGktdmFsdWVkICZxdW90 O2F1ZCZxdW90OyBjbGFpbSBhbmQgYSAmcXVvdDtzY29wZSZxdW90OyBjbGFpbSB3b3VsZCBzZWVt IGFwcHJvcHJpYXRlLCBhcyB0aGUgc2NvcGUgY2xhaW0gaXMgaW50ZW5kZWQgdG8gYXBwbHkgdG8g YWxsIG9mIHRoZQ0KIGF1ZGllbmNlIHZhbHVlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzMuIFRoZSBtYXBwaW5nIGJl dHdlZW4gYXVkaWVuY2UgYW5kIHNjb3BlIG1heSBiZSB1bmFtYmlndW91czxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBh IGxvdCBvZiBkZXBsb3ltZW50cyB0byB3aGljaCB0aGUgYmxhc3QgcmFkaXVzIHJpc2sgeW91J3Jl IHRyeWluZyB0byBhZGRyZXNzIGJ5IHJlcXVpcmluZyAmcXVvdDthdWQmcXVvdDsgc2ltcGx5IGRv ZXMgbm90IGFwcGx5LiBJdCBtYXkgc2VlbSBpbm5vY3VvdXMgdG8gcmVxdWlyZSB0aGVzZSBkZXBs b3ltZW50cyB0byBleHBsaWNpdGx5IGluY2x1ZGUgYSBicm9hZCBhdWRpZW5jZSBsaWtlICZxdW90 O2FwaS5leGFtcGxlLmNvbSZxdW90Ow0KIGFueXdheSwgdGhhdCBjYW4gbGVhZCB0byBpbXBsZW1l bnRlcnMgaWdub3JpbmcgdGhlIHJlcXVpcmVtZW50IChsZWFkaW5nIHRvIGludGVyb3AgaXNzdWVz KSwgbm90IHZhbGlkYXRpbmcgaXQgKGFsc28gbGVhZGluZyB0byBpbnRlcm9wIGlzc3VlcyBvciBz ZWN1cml0eSBpc3N1ZXMgaWYgdGhlIGRlcGxveW1lbnQgd2FudHMgdG8gc3RhcnQgYWN0dWFsbHkg dXNpbmcgaXQgZm9yIHJlYWwpLCBvciBkb2luZyBzb21ldGhpbmcgZnVua3kgd2l0aCBpdA0KIHNp bmNlIHRoZXJlIGlzbid0IGFueXRoaW5nICZxdW90O3JlYWwmcXVvdDsgdGhhdCB0aGUgdmFsdWUg bmVlZHMgdG8gY29uZm9ybSB0by4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAkzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFubmFiZWxsZSBCYWNr bWFuIChzaGUvaGVyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRl bnRpdHkvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO++7v09uIDMvMjQvMjAsIDM6MzEgUE0sICZx dW90O09BdXRoIG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSZxdW90OyAmbHQ7b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygdml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5j b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q0FVVElPTjogVGhpcyBlbWFp bCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xp Y2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBz ZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtUaGFua3MgR2VvcmdlIGZvciB0aGUgc3VwZXIgdGhvcm91Z2ggcmV2aWV3IGFuZCBmZWVk YmFjayE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBJbmxpbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgU2VjdGlvbiAx LiBJbnRyb2R1Y3Rpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDr8K/wr3Dr8K/ wr3Dr8K/wr0gc2Vjb25kIGxpbmU6IHNjZW5hcmlvIHNob3VsZCBiZSBwbHVyYWwgLS0mZ3Q7IHNj ZW5hcmlvczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvcOvwr/C vSBzZWNvbmQgc2VudGVuY2U6ICZxdW90O2FyZSBub3QgcmFuIGJ5JnF1b3Q7IC0tJmd0OyAmcXVv dDthcmUgbm90IHJ1biBieSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOv wr/CvSBjb2ZpZGVudGlhbGl0eSAtLSZndDsgY29uZmlkZW50aWFsaXR5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRml4ZWQuIFRoYW5r cyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiAyLjIuMSBB dXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbiBDbGFpbXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBkZWZpbml0 aW9uIG9mIGBhdXRoX3RpbWVgIGFsbG93cyBmb3IgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY2FzZSB3aGVyZSBhIHVzZXIgaXMgcmVxdWlyZWQgdG8gc29sdmUgYW4gYWRkaXRpb25hbCBj aGFsbGVuZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgSWYgdGhlIGNoYWxsZW5nZSBlbnRhaWxzIGdvaW5nIGJhY2sgdG8gdGhlIEFT LCB0aGVuIEkgYmVsaWV2ZSB0aGUgbGFuZ3VhZ2UgKGluIHRoZSBpbml0aWFsIHBhcmFncmFwaCBv ZiAyLjIuMSBhbmQgaW4gYXV0aF90aW1lIGl0c2VsZikmbmJzcDsgYWNjb21tb2RhdGVzIGZvciB0 aGF0IGFuZCBkb2VzIHJlcXVpcmUgdGhlIGF1dGhfdGltZSB0byBiZSB1cGRhdGVkLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHlv dSBoaXQgdGhlIEFTIGFuZCBwcmVzZW50IGFuIGF1dGhlbnRpY2F0aW9uIGZhY3RvciAoc3VjaCBh cyB5b3VyIGNoYWxsZW5nZSkgYW5kIG9idGFpbiBhIG5ldyB0b2tlbiBpbiB0aGUgcHJvY2Vzcywg dGhlIGF1dGhfdGltZSB3aWxsIHJlZmxlY3QgdGhlIHRpbWUgb2YgeW91ciBsYXRlc3QgYXV0aGVu dGljYXRpb24ganVzdCBsaWtlIGFuIGlkX3Rva2VuIHdvdWxkIGluIHRoZSBzYW1lIGNpcmN1bXN0 YW5jZXMNCiAodGhpbmsgcHJvdGVjdGVkIHJvdXRlIGluIGEgd2ViIGFwcCByZXF1aXJpbmcgc3Rl cCB1cCBhdXRoKSBhbmQgKGxpa2VseSkgYXNzb2NpYXRlZCBzZXNzaW9uIGFydGlmYWN0cyAodGhp bmsgUlRzIG9yIGNvb2tpZXMgd2l0aCBzbGlkaW5nIGV4cGlyYXRpb24sIHRoZSBjaGFsbGVuZ2Ug d291bGQgY291bnQgYXMgYWN0aXZpdHkgYW5kIG1vdmUgdGhlIGV4cGlyYXRpb24pLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSB0aGlu ayB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXNzaW9uX3N0YXJ0X3RpbWUgYW5kIGxh c3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoX3RpbWUuIFRoaXMgZmVlbHMgbW9yZSBs aWtlIGl0J3MgZGVmaW5pbmcgdGhlIHNlc3Npb25fc3RhcnRfdGltZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNvbmNlcHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr0g VGhlc2Ugc2FtZSBpc3N1ZXMgY2FuIGFwcGx5IHRvIHRoZSBgYWNyYCBhbmQgYGFtcmAgdmFsdWVz IGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgUGVyIHRoZSBhYm92ZSwgdGhlIGludGVudCBpcyBtb3JlIHRvIGV4cHJlc3Mg dGhlIGxhc3QgdGltZSB0aGUgdXNlciBwZXJmb3JtZWQgYW55IGF1dGhlbnRpY2F0aW9uIGFjdGlv biByYXRoZXIgdGhhbiB0aGUgc3RhcnQgdGltZS4gVGhlIGludGVudCBpcyB0byBwcm92aWRlIGlu Zm9ybWF0aW9uIGFzIGN1cnJlbnQgYXMgcG9zc2libGUsIGFzIGl0IG1pZ2h0IGJlIHJlbGV2YW50 IHRvIHRoZSBSUyBkZWNpc2lvbnMNCiB3aGVyZWFzIHRoZSBoaXN0b3J5IGJlZm9yZSBjdXJyZW50 IGNvbmRpdGlvbnMgbWlnaHQgbm90IGJlIGNvbnNlcXVlbnRpYWwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBFdmVuIGlmIGZvciB0aGlzIHNlY29u ZGFyeSBjaGFsbGVuZ2UgYSBuZXcgcmVmcmVzaF90b2tlbiBpcyBpc3N1ZWQsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaXQgaXMgdW5saWtlbHkgbWFueSByZWx5aW5nIHBhcnRpZXMgd2lsbCB3 YW50IHRvIHRyZWF0IHRoYXQgYXMgaXNzdWluZyBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bmV3IHNlc3Npb24uIFRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIHVzZXIgbG9nZ2VkIGluIHRvIGEg c2luZ2xlIHNlc3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgQ291bGQgeW91IGV4cGFuZCBvbiB0aGUgcHJhY3RpY2FsIGltcGxp Y2F0aW9ucyBvZiB0aGUgYWJvdmU/IFRoZSBpbnRlbnQgaXNuJ3QgYXMgbXVjaCB0byByZWZsZWN0 IHNlc3Npb24gaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gcGVyIHNlLCBidXQgdG8gcHJvdmlkZSB0 aGUgUlMgd2l0aCB0aGUgbW9zdCB1cCB0byBkYXRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjaXJj dW1zdGFuY2VzIGluIHdoaWNoDQogdGhlIGN1cnJlbnQgQVQgd2FzIG9idGFpbmVkLiBUaGUgZmFj dCB0aGF0IGEgc2Vzc2lvbiB3YXMgaW5pdGlhbGx5IGVzdGFibGlzaGVkIHVzaW5nIGFjciBsZXZl bCAwIGRvZXNu4oCZdCByZWFsbHkgbWF0dGVyIGlmIHRoZSBBVCBJIGFtIHJlY2VpdmluZyBub3cg aGFzIGJlZW4gb2J0YWluZWQgYWZ0ZXIgYSBzdGVwdXAgdGhhdCBicm91Z2h0IGFjciB0byAxLCBp ZiBteSBSUyBjYXJlcyBhdXRoIGF1dGhlbnRpY2F0aW9uIGxldmVscyBteSBhdXRob3JpemF0aW9u DQogZGVjaXNpb24gc2hvdWxkbid0IGJlIGluZmx1ZW5jZWQgYnkgd2hldGhlciBzb21ld2hlcmUg dGhlIHNlc3Npb24gYXJ0aWZhY3QgZGlkbuKAmXQgY2hhbmdlIGl0cyBzZXNzaW9uSUQgYWZ0ZXIg dGhlIHN0ZXB1cC4gU2FtZSBmb3IgYWNyLCBhdXRoX3RpbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiAyLjIuMyBBdXRob3JpemF0aW9uIENsYWltczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBJIGZpbmQgdGhlIHN0YXRl bWVudCAmcXVvdDtBbGwgdGhlIGluZGl2aWR1YWwgc2NvcGUgc3RyaW5ncyBpbiB0aGUgc2NvcGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBmb3IgdGhl IHJlc291cmNlIGluZGljYXRlZCBpbiB0aGUgYXVkIGNsYWltJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc29tZXdoYXQgcHJvYmxlbWF0aWMuIEluIG1hbnkgZGVwbG95bWVudHMgdG9k YXkgZm9yIDFzdCBwYXJ0eSBjbGllbnRzIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0YWtpbmcgaW50byBhY2NvdW50IG1vYmlsZSBhcHBs aWNhdGlvbnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGFjY2VzcyB0b2tlbiBtb3N0 IGxpa2UgY29udGFpbnMgc2NvcGVzIGZvciBtYW55IG9mIHRoZSAxc3QgcGFydHk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBiYWNrZW5kIEFQSXMuIEl0J3MgcG9zc2libGUgdG8gZ2V0IGFyb3Vu ZCB0aGlzIGJ5IHNldHRpbmcgdGhlICdhdWQnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xh aW0gdG8gc29tZXRoaW5nIGxpa2UgJnF1b3Q7Y29tLmV4YW1wbGUuYXBpcyZxdW90OyBhbmQgaGVu Y2UgYWxsIHRoZSBpc3N1ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzY29wZXMgbWFwIHRv IHRoYXQgYXVkaWVuY2UgY2xhaW0gYnV0IHRoYXQgaXMganVzdCB3b3JraW5nIGFyb3VuZCB0aGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNVVNUIGluIHRoZSBzcGVjLiBHaXZlbiB0aGUgbGFj ayBvZiBzcGVjaWZpY2l0eSBvZiB0aGUgJ2F1ZCcgY2xhaW0gYW5kPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt0aGUgJ3Jlc291cmNlIGluZGljYXRvcicgY2xhaW0gZm9yIHRoYXQgbWF0dGVyLCBw cmV0dHkgbXVjaCBhbnl0aGluZyBjYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBtYWRl IHRvIGNvbXBseS4gSW4gdGhhdCBjb250ZXh0LCBpdCBzZWVtcyBsaWtlIFJFQ09NTUVORCBpcyBh IGJldHRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vcm1hdGl2ZSBjbGF1c2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRm9y IDFzdCBwYXJ0eSBzb2x1dGlvbnMsIEkgd291bGQgYXJndWUgdGhhdCBkZWxlZ2F0aW9uIG1pZ2h0 IG5vdCBiZSB0aGUgcmlnaHQgcHJpbWl0aXZlIGhlbmNlIEkgd291bGRuJ3QgbmVjZXNzYXJpbHkg dXNlIHNjb3BlcyB0byBleHByZXNzIHBlcm1pc3Npb25zOyBidXQgdGhhdCdzIGEgcmFiYml0IGhv bGUgSSdsbCB0cnkgdG8gYXZvaWQgZm9yIHRoZSB0aW1lIGJlaW5nIF9fPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIHRoZSBhdWQs IEkgdGhpbmsgdGhhdCB3aGF0IHlvdSBjaGFyYWN0ZXJpemVkIGFzIHdvcmthcm91bmQgd291bGQg YWN0dWFsbHkgYmUgYnkgZGVzaWduLiBUaGUgYXVkIGRlZmluZXMgdGhlIGFwcGxpY2FiaWxpdHkg b2YgdGhlIGN1cnJlbnQgdG9rZW4sIHNvIHRoYXQgaW4gY2FzZSBvZiBsZWFrYWdlIHRoZSBibGFz dCByYWRpdXMgb2YgdGhlIGluY2lkZW50IGNhbiBiZSBjb250YWluZWQuIElmDQogdGhlIHNvbHV0 aW9uIGRlc2lnbmVkIGRlY2lkZXMgdGhhdCB0aGlzIHBhcnRpY3VsYXIgdG9rZW4gc2hvdWxkIGJl IHJldXNhYmxlIGFjcm9zcyBtdWx0aXBsZSBhc3NldHMsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2Ug Zm9yIHRoZSBhdWQgdG8gcmVmbGVjdCB0aGF0IGV4cGxpY2l0bHkuIFRoYXQncyB0aGUgc3lzdGVt IGRlc2lnbmluZyB2b2x1bnRlZXJpbmcgYSBzY29wZSB4cGFuc2lvbiBvZiB0aGUgc2NvcGUsIGFu ZCBnaXZlbiB0aGF0IGl0IGhhcw0KIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBJIHRoaW5rIGl0J3Mg Z29vZCB0byByZXF1aXJlIGl0IHRvIGJlIGFuIGV4cGxpY2l0LCBvcHQgaW4gYWN0aW9uLiBBdCB0 aGUgc2FtZSB0aW1lLCBnaXZlbiB0aGF0IHNjb3BlcyBhcmUgb2Z0ZW4gdXNlZCB0byBkZWZpbmUg cGVybWlzc2lvbnMsIEkgYmVsaWV2ZSBpdCBtYWtlcyBzZW5zZSB0byBmaW5kIG1lY2hhbmlzbXMg dG8gbWluaW1pemUgdGhlIGNoYW5jZSB0aGF0IFJTZXMgd291bGQgbWlzaW50ZXJwcmV0DQogdGhl IGFwcGxpY2FiaWxpdHkgb2YgYSBzY29wZSAoc2VlIGRpc2N1c3Npb24gd2l0aCBUYWthaGlrby9O aWtvcykuIFN1bW1pbmcgYWxsIHRoZSBhYm92ZSwgSSdkIGJlIGluY2xpbmVkIHRvIGtlZXAgdGhl IE1VU1QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsgU2VjdGlvbiAzLiBSZXF1ZXN0aW5nIGEgSldUIEFjY2VzcyBU b2tlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBQZXIgbXkg Y29tbWVudHMgYWJvdmUgSSBzdXNwZWN0IHRoYXQgcmVxdWlyaW5nIGFsbCBKV1QgYWNjZXNzIHRv a2VuczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGluY2x1ZGUgYW4gYXVkaWVuY2UgY2xh aW0gd2lsbCBqdXN0IGRldm9sdmUgdG8gYXVkaWVuY2UgY2xhaW1zIHRoYXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhcmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRlciB0byBtZWV0IHRo aXMgTVVTVCBpbiB0aGUgc3BlYykuIEdpdmVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl IG1vYmlsZSBhcHAgZW52aXJvbm1lbnQgdG9kYXksIGl0IGlzIHVucmVhc29uYWJsZSB0byBhc2sg dGhlIG1vYmlsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcHMgdG8gZG93bnNjb3BlIGV2 ZXJ5IGFjY2VzcyB0b2tlbiBiZWZvcmUgbWFraW5nIGFuIEFQSSBjYWxsIHRvIHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJhY2tlbmQgQVBJcyB3aGljaCBpcyB3aGF0IHRoZSBzcGlyaXQg b2YgYXVkaWVuY2UgYW5kIHJlc291cmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNh dG9ycyBzZWVtIHRvIGltcGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhcnRseSBhZGRyZXNzZWQgaW4gdGhlIHByZWNlZGluZyBw b2ludCwgYnV0IHRoaXMgaXMgYSBncmVhdCBvcHBvcnR1bml0eSB0byBjbGFyaWZ5IHRoZSBpbnRl bnQgZnVydGhlci4gVGhlIG1vYmlsZSBjbGllbnQgaXNuJ3QgcmVxdWlyZWQgdG8gZG93bnNjb3Bl OyByYXRoZXIsIHRoZSBmYWN0IHRoYXQgYSB0b2tlbiBjYWIgYmUgYXBwbGllZCB0byBhIGJyb2Fk IHJhbmdlIG9mIEFQSSBzaG91bGQgYmUNCiBjbGVhcmx5IGlkZW50aWZpZWQgYW5kIGV4cHJlc3Nl ZCBieSB0aGUgbG9naWNhbCBhdWRpZW5jZS4gVGhlIHN5c3RlbSBkZXNpZ25lciBjYW4gZXZlbiBj aG9vc2UgdG8gaGF2ZSBhIHNpbmdsZSB0b2tlbiB0aGF0IGNhbiBiZSB1c2VkIHRvIGNhbGwgYW55 IEFQSSwgY29udGFpbmluZyBldmVyeSBzY29wZSBmb3IgZXZlcnkgQVBJOyB0aGUgcHJvZmlsZSBv bmx5IGFza3MgZm9yIHRoaXMgY2hvaWNlIHRvIGJlIG1hbmlmZXN0LCBieSBjaG9vc2luZyBhbg0K IGFwcHJvcHJpYXRlIGF1ZGllbmNlIGlkZW50aWZpZXIgYW5kIGFja25vd2xlZGdpbmcgdGhhdCBh bGwgdGhlIHNjb3BlcyBpbiB0aGUgdG9rZW4gYXJlIGFwcGxpY2FibGUgdG8gdGhlIHNhbWUgbG9n aWNhbCByZXNvdXJjZSAodGhhdCBpcywgdGhlIGFnZ3JlZ2F0ZSBvZiBhbGwgdGhlIEFQSXMpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZuYnNwOyDDr8K/wr3D r8K/wr0gV2h5IE1VU1QgdGhlIEFTIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtb3JlIHRoYW4gb25l IHJlc291cmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVyPyBJZiBhIHJlcXVl c3QgY29tZXMgaW4gd2l0aCBubyByZXNvdXJjZSBwYXJhbWV0ZXIgYW5kIG11bHRpcGxlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NvcGVzIHRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gcmVq ZWN0IHRoYXQgcmVxdWVzdC4gSXMgdGhlcmUgbXVjaCBvZiBhPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2VtYW50aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28/IEluIHRoZSBjYXNlIG9m IG5vIHJlc291cmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVyIGFuZCBtdWx0 aXBsZSBzY29wZXMgdGhlIEFTIG1pZ2h0IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlwbGUgYXVkaWVuY2UgdmFsdWVzIChhcyBpcyBhbGxv d2VkIGJ5IFJGQyA3NTE5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIGFub3RoZXIgY29uc2VxdWVuY2Ugb2YgbWFraW5n IGV4dHJhIGNsZWFyIHdoYXQgdGhlIHRva2VuIHJlZmVycyB0bywgYW5kIHdoYXQgdGhlIGludGVu ZGVkIHNlbWFudGljIG9mIHRoZSBzY29wZXMgaXMuIFRoZSBpZGVhIGlzIHRoYXQgdGhlIHRva2Vu IGlzIGFsd2F5cyByZXN0cmljdGVkIHRvIE9ORSBzcGVjaWZpYyBhdWRpZW5jZS4gVGhlIHByb2Zp bGUgYWxsb3dzIGZvciBkaWZmZXJlbnQNCiBtZWNoYW5pc21zIGZvciB0aGUgQVMgdG8gZGV0ZXJt aW5lIHdoYXQgdmFsdWUgdGhlIGF1ZGllbmNlIHNob3VsZCBiZSwgaW5jbHVkaW5nIHZpYSBpbmZl cmVuY2UgZnJvbSBzY29wZXMsIGJ1dCBjb2hlcmVudGx5IHdpdGggdGhlIHNjb3BlIGNvbmZ1c2lv biBwcmV2ZW50aW9uIHByaW5jaXBsZSwgaWYgdGhhdCBpbmZlcmVuY2UgY2Fubm90IGxlYWQgdG8g YSBzaW5nbGUgcmVzb3VyY2UgaWRlbnRpZmllciBpbiB0aGUgYXVkaWVuY2UsIHRoZSByZXF1ZXN0 DQogc2hvdWxkIGJlIHJlamVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBpbnRlbnQgaXMgcmVhbGx5IHRvIGJlIGFzIHNp bXBsZSBhcyB1bmFtYmlndW91cyBhcyBwb3NzaWJsZSwgYW5kIGNhcHR1cmUgd2hhdCBtb3N0IG1h aW5zdHJlYW0gcHJvdmlkZXJzIGFscmVhZHkgZG8gaW4gSldUIEFUcy4gSWYgYSBSUyBoYXMgbW9y ZSBzb3BoaXN0aWNhdGVkIHJlcXVpcmVtZW50cywgdGhleSBjYW4gYWx3YXlzIGRlY2lkZSB0byBk byBtb3JlIGFuZCBub3QgZm9sbG93IHRoZQ0KIGludGVyb3AgcHJvZmlsZS4gRGVmaW5pbmcgbW9y ZSBjb21wbGV4IHJ1bGVzIHRvIHByZXZlbnQgc2NvcGUvcmVzb3VyY2UgYXNzb2NpYXRpb24gY29u ZnVzaW9uIHNpbXBseSBkb2VzbuKAmXQgc2VlbSB0byBiZSBqdXN0aWZpZWQgYnkgdGhlIGZyZXF1 ZW5jeSBvZiB0aGUgc2NlbmFyaW8gaW4gdGhlIHdpbGQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsm bmJzcDsgQWxzbywgdGhlIGF1ZGllbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhaW0g aXMgbm90IHNvbGVseSBmb3IgcmVzb3VyY2UgaW5kaWNhdG9yIHZhbHVlcyBidXQgaXMgZGVmaW5l ZCB0byBqdXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgYSBzdHJpbmcuIFRvIG1lIGl0 IGZlZWxzIGxpa2UgdGhlIHRleHQgaXMgaW1wbHlpbmcgdGhhdCB0aGUgb25seTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHZhbGlkIGF1ZGllbmNlIHZhbHVlIGlzIGFsc28gYSByZXNvdXJjZSBp bmRpY2F0b3IgKHdoaWNoIGZyb20gcHJldmlvdXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBk aXNjdXNzaW9ucyBvbiB0aGUgbGlzdCBpdCB3YXMgaW1wbGllZCB0aGV5IGhhdmUgYSBzbGlnaHRs eSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZW1hbnRpYykuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlv biAzIG9mIHRoZSBwcm9maWxlIGRvZXMgZGVmaW5lIGF1ZCBhcyBhIHJlc291cmNlIGluZGljYXRv ciwgZW51bWVyYXRpbmcgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHBvc3NpYmxlIHJlcXVlc3RzIHRo YXQgYWxsIGVuZCBpbiBhIHJlc291cmNlIGluZGljYXRvciBhcyBhdWQsIG9yIGFuIGVycm9yLiBE aWQgSSBtaXNzIHNvbWUgY2FzZXM/IEkgZG9u4oCZdCByZWNhbGwgc3BlY2lmaWNzIGFib3V0DQog YXVkIHZhbHVlcyBpbiB0aGlzIHByb2ZpbGUgaGF2aW5nIG90aGVyIHBvc3NpYmxlIHZhbHVlcywg c29ycnkgZm9yIGhhdmluZyBtaXNzZWQgdGhhdC4gRG8geW91IGhhdmUgYSBzbmlwcGV0IHJlZmVy cmluZyB0byB0aG9zZSBkaXNjdXNzaW9ucz8gVGh4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmZ3Q7Jm5ic3A7IMOvwr/CvcOvwr/CvSBUaGUgbW9kZWwgZGVzY3JpYmVkIGhlcmUg d29ya3Mgd2VsbCBpZiBteWNvLmV4YW1wbGUgcmVhbGx5IG9ubHk8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBwcm92aWRlcyBhIHNpbmdsZSBzZXJ2aWNlLiBCdXQgaWYgaW5zdGVhZCBteWNvLmV4 YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNl cyBlYWNoIHdpdGggdGhlaXIgb3duIGVuZHBvaW50cyAoc3J2YS5teWNvLmV4YW1wbGUsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3J2Yi5teWNvLmV4YW1wbGUpIGFuZCBzY29wZXMsIGZvciBt ZSB0aGlzIG1vZGVsIGJlZ2lucyB0byBicmVhayBkb3duLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEVpdGhlciBtb2JpbGUgYXBwcyBhcmUgcmVxdWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tl bnMgdG8ganVzdCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlIHRoZXkgYXJl IGNhbGxpbmcgYXQgdGhhdCBwb2ludCBpbiB0aW1lICh3aGljaCBjYW4gaGF2ZSBsYXRlbmN5PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIGNvbm5lY3Rpdml0eSBpc3N1ZXMpLCBvciBteWNv LmV4YW1wbGUgaGFzIHRvIGNyZWF0ZSBhIGdlbmVyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDthdWRpZW5jZSZxdW90OyBzdHJpbmcgdGhhdCByZXByZXNlbnRzIGFsbCBvZiBleGFt cGxlLmNvbSB3aGljaCBkb2Vzbid0IHNlZW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBi ZSB0aGUgc3Bpcml0IG9mIHRoZSBleGlzdGluZyBzcGVjcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoYXQgdGhlIGdy YW51bGFyaXR5IG9mIHRoZSBjYWxscyBpcyBmdWxseSB3aXRoaW4gdGhlIGNvbnRyb2wgb2YgdGhl IGRlc2lnbmVyLiBJZiBzcnZhLm15Y28uZXhhbXBsZSBhbmQgc3J2Yi5teWNvLmV4YW1wbGUgc2hh cmUgYW5hbG9nb3VzIGNoYXJhY3RlcmlzdGljcyAoc2FtZSBwb2xpY2llcywgbGlmZWN5Y2xlLCBy ZXNvdXJjZSBvd25lcnNoaXAsIGV0YykgdGhlbSBpdCdzIHBlcmZlY3RseQ0KIHZhbGlkIHRvIGFz c2lnbiBhIGxvZ2ljYWwgbXljby5leGFtcGxlIGF1ZGllbmNlIGVuY29tcGFzc2luZyB0aGVtIGFs bCwgcmVnYXJkbGVzcyBvZiBkZXBsb3ltZW50IG1vZGVsLiBJZiB0aGVyZSBhcmUgZGlmZmVyZW5j ZXMgaW4gdGVybXMgb2YgcG9saWNpZXMsIGF1dGggc3RyZW5ndGggcmVxdWlyZW1lbnRzLCBsaWZl Y3ljbGUsIHJpc2sgYW5kIGltcGFjdCBvZiBhIGxlYWssIG9yIGFueSBvdGhlciBib3VuZGFyeSwg dGhlbiB0aGUgYXVkaWVuY2UNCiByZXF1aXJlbWVudCB3aWxsIGd1YXJhbnRlZSB0aGF0IHRob3Nl IGRpZmZlcmVuY2VzIGFyZSByZWZsZWN0ZWQgaW4gdG9rZW5zIHJlcXVlc3RlZCBhbmQgY2FjaGVk LCBpbiB0aGUgd2F5IGluIHdoaWNoIGFjY2VzcyBpcyBwYXJ0aXRpb25lZCwgYW5kIHNvIG9uIGFu ZCBzbyBmb3J0aC4gSWYgdGhlcmUgYXJlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBzdWNoIGFzIHRo ZSBvbmVzIGVudW1lcmF0ZWQsIHRoZSBsYXRlbmN5IGFuZCBjb25uZWN0aXZpdHkNCiBpc3N1ZXMg YXJlbuKAmXQgYSBibG9ja2luZyBmYWN0b3I7IGFuZCBpZiB0aGVyZSBhcmVuJ3QsIG5vdGhpbmcg cHJldmVudHMgeW91IGZyb20gaGF2aW5nIGEgbG9naWNhbCBhdWRpZW5jZSB2YWx1ZS4gRnJvbSB0 aGUgZXhwcmVzc2l2ZSBwb3dlciBwb2ludCBvZiB2aWV3LCB0aGUgcmVxdWlyZW1lbnQgb2YgaGF2 aW5nIGEgc2luZ2xlIGF1ZGllbmNlIGRvZW5zJ3QgcHJldmVudCB5b3UgZnJvbSBkb2luZyBhbnkg b2YgdGhlIHNpbmdsZSB0b2tlbiBsb2dpYw0KIHlvdSBhcmUgaGludGluZyBhdC0gZXNwZWNpYWxs eSBpZiB5b3UgcGxhbiB0byB1c2Ugc3BlY2lhbGl6ZWQgc2NvcGVzIGFueXdheS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IEluIHN1bW1h cnksIEkgZmVlbCB0aGF0IHRoaXMgdGV4dCBpcyBiaW5kaW5nIHRvbyB0aWdodGx5IHJlc291cmNl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdG9ycyB0byB0aGUgYXVkaWVuY2UgY2xh aW0uIFdoYXQgaXMgZGVzY3JpYmVkIGlzIHBlcmZlY3RseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHJlYXNvbmFibGUgaW4gYSB1c2UgY2FzZSB0aGF0IGlzIGFwcGx5aW5nIHJlc291cmNlIGlu ZGljYXRvcnMgaW4gdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3dheSBidXQgaXMgbm90 IGluZGljYXRpdmUgb2YgdGhlIHdpZGVseSBkZXBsb3llZCBtb2RlbHMgdGhhdCBhbHJlYWR5IGV4 aXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFdlIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGV4cGVyaWVuY2VzIGhlcmUuIFRoZSBKV1Qg YWNjZXNzIHRva2VucyBmcm9tIHBvcHVsYXIgcHJvZHVjdHMgSSBzdHVkaWVkIGluIHRoZSByZXNl YXJjaCBJIHByZXNlbnRlZCBpbiBTdHV0dGdhcnQgd2VyZSBhbG1vc3QgYWxsIHVzaW5nIHRoZSBh dWQgY2xhaW0gaW4gdGhpcyB3YXkuIEkgYW0gc3VyZSB0aGF0IHRoZXJlIGFyZSBvdGhlciBtb2Rl bHMsIGFuZA0KIHRoZXJlIHdhcyBhdCBsZWFzdCBvbmUgZXhjZXB0aW9uLCBidXQgaW4gaW50ZXJv cCB0ZXJtcyB0aGlzIHNlZW1zIHRvIGJlIHRoZSBtb3N0IGNvbW1vbiB3YXkgb2YgdXNpbmcgSldU IGZvciBBVHMtIGFuZCBpdCBoYXMgdGhlIGFkdmFudGFnZSBvZiBiZWluZyB2ZXJ5IHNpbXBsZSBh bmQgdW5hbWJpZ3VvdXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IFNlY3Rpb24gNC4gVmFsaWRhdGluZyBKV1Qg QWNjZXNzIFRva2VuczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/C vSBTdGVwIDQuIC0tIENhbiB3ZSBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gbm90IHJlcXVpcmUgcmVz b3VyY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0b3JzPyBXaGF0IGFib3V0Li4u ICZxdW90O1RoZSByZXNvdXJjZSBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGF0IHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdhdWQnIGNsYWltIGNvbnRhaW5zIGEgc3RyaW5nIHRoYXQgcmVw cmVzZW50cyB0aGUgYXVkaWVuY2Ugb2YgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl c291cmNlIHNlcnZlci4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBDb3VsZCB5b3UgbWFrZSBhbiBleGFtcGxlIGluIHdoaWNo IHlvdSdkIHdhbnQgdG8gdXNlIGFuIGlkZW50aWZpZXIgdGhhdCBpcyBub3QgYSByZXNvdXJjZSBp bmRpY2F0b3I/IEdpdmVuIHRoYXQgd2UgaGF2ZSB0aGUgc3BlYywgYW5kICZxdW90O2F1ZGllbmNl IG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXImcXVvdDsgc2VlbXMgdG8gYmUgdGhlIGV4YWN0IHNlbWFu dGljIG9mIHJlc291cmNlIGluZGljYXRvcnMsIGl0IHNlZW1lZA0KIGEgc2xhbSBkdW5rIHRvIHVz ZSBpdCBoZXJlLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IFNlY3Rpb24gNS4g JnF1b3Q7Y3Jvc3MtSldUIGNvbmZ1c2lvbiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IMOvwr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJlIG1heSBiZSBjb25mdXNpb24gYXJvdW5k IHdoYXQgaXMgbWVhbnQgYnkgJnF1b3Q7ZGlzdGluY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyByZXNvdXJjZXMmcXVvdDsuIEluIG15IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhh bXBsZSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcnZiLm15Y28uZXhhbXBsZSAmcXVv dDtkaXN0aW5jdCByZXNvdXJjZXMmcXVvdDs/IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8gc2F5IHRo YXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3ZSB3YW50IGRpZmZlcmVudCBhdWRpZW5jZSB2 YWx1ZXMgZ2VuZXJhdGVkIGZvciBjcm9zcy1vcmdhbml6YXRpb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZXNvdXJjZXMuIEZvciBleGFtcGxlLCBhcmUgbWFpbC5nb29nbGUuY29tIGFuZCB5 b3V0dWJlLmNvbSAmcXVvdDtkaXN0aW5jdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291 cmNlcyZxdW90Oz8gb3Igd291bGQgYW4gYXVkaWVuY2UgZm9yIGdvb2dsZSBzdWZmaWNlIGluIG1l ZXRpbmcgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVhbmluZyBvZiB0aGlzIHBhcmFn cmFwaD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyAtIHdlIGRvbuKAmXQga25vdy4g SSBhZ3JlZSB0aGUgbGFuZ3VhZ2UgaXNuJ3QgY2xlYXIgdGhlcmUuIExldCBtZSBleHBhbmQgb24g dGhlIGludGVudCwgYW5kIHBlcmhhcHMgd2UgY2FuIGdldCB0byBhIGJldHRlciBmb3JtdWxhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyBPQXV0aDIgZG9lc27igJl0IGRlbWFuZCB0aGF0IFJTIGFuZCBBUyBhcmUgcnVuIGJ5IHRo ZSBzYW1lIGVudGl0eSwgYnV0IHRoYXQncyB0aGUgbW9zdCBjb21tb24gc2NlbmFyaW8uIEZCIGRv ZXNuJ3QgbmVlZCB0byBzcGVjaWZ5IGEgcmVzb3VyY2UsIGJlY2F1c2UgdGhlIHJlc291cmNlIGlz IGltcGxpY2l0Li4gaXQncyB0aGUgRkIgZ3JhcGgsIHlvdSBjYW7igJl0IGdldCBhIHRva2VuIGZv ciBhbnl0aGluZw0KIGVsc2UuIFRoZSBvbmx5IGRpZmZlcmVudGlhdG9yIGVuZHMgdXAgYmVpbmcg dGhlIHNjb3Blcy4gU2FtZSBmb3IgbWFueSBvdGhlciBwcm92aWRlcnMsIGdvb2dsZSwgTWljcm9z b2Z0IGZvciBpdHMgb3duIEdyYXBoLCBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSG93ZXZlciBtYW55IEFTIGFzIGEgc2Vydmlj ZSBkb27igJl0IGhhdmUgdGhlIGJlbmVmaXQgb2YgYSBkZWZhdWx0LCBpbXBsaWNpdCByZXNvdXJj ZSwgZXNwZWNpYWxseSBpbiBtdWx0aSB0ZW5hbmN5IHNjZW5hcmlvcywgZ2l2ZW4gdGhhdCB0aGV5 J2xsIG5lZWQgdG8gaXNzdWUgdG9rZW5zIGZvciBhIG51bWJlciBvZiBkaWZmZXJlbnQgcmVjaXBp ZW50cy4gV2hldGhlciByZXNvdXJjZXMgYXJlIGNyb3NzDQogb3JnYW5pemF0aW9uLCBvciBjcm9z cyBkZXBhcnRtZW50LCBvciBmb2xsb3dpbmcgYW55IG90aGVyIGFyYml0cmFyeSBzZWdyZWdhdGlv bi9mYWN0b3JpbmcgbW9kZWwgaXMgc29tZXRoaW5nIHdlIGNhbm5vdCBpbmZlci0gaXQncyB1cCB0 byB0aGUgZGV2ZWxvcGVyIHRvIGRldGVybWluZSB0aGF0LiBXaGF0IEkgYW0gdHJ5aW5nIHRvIGV4 cHJlc3MgaGVyZSBpcyB0aGF0IHRoZSBvcGVyYXRvciBvZiB0aGUgQVMgYXMgYSBzZXJ2aWNlIChv ciBhbnkgb3RoZXINCiBmb3JtIG9mICZxdW90O0FTIGZvciByZW50JnF1b3Q7KSBzaG91bGQgc3Vy ZmFjZSByZXNvdXJjZXMgYXMgYSBwcmltaXRpdmUgZm9yIG1vZGVsaW5nIGFuZCBpZGVudGlmeWlu ZyBpbnRlbmRlZCByZWNpcGllbnRzIG9mIEFUcy4gRG9lcyB0aXMgaGVscD8gSG93IHdvdWxkIHlv dSBleHByZXNzIHRoYXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IMOvwr/CvSBJJ20gaGF2aW5nIHRoZSBzYW1lIGNvbmZ1c2lvbiBpbiB0aGUgbmV4dCBwYXJh Z3JhcGggcmVnYXJkaW5nIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBocmFzZSAmcXVv dDtkaWZmZXJlbnQgcmVzb3VyY2VzJnF1b3Q7LiBBcmUgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhl IHNhbWUgY29tcGFueTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2RpZmZlcmVudCBy ZXNvdXJjZXMmcXVvdDsgb3IgYXJlIHRoZXkgYWxsIGNvbnNpZGVyZWQgdGhlIHNhbWUgcmVzb3Vy Y2UuIENhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIGFjY2VzcyB0b2tlbiBiZSBpc3N1 ZWQgd2l0aCBzY29wZXMgZm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHlvdXR1YmUuY29tPyBBbmQgaWYgbm90LCB3aHkgbm90ZT8gUHJldmVudGlu ZyB0aGlzIHB1dHMgdW5kdWUgYnVyZGVuIG9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9i aWxlIGJhc2VkIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTZWUgcHJlY2VkaW5nIHBvaW50LiBXZSBjYW4ndCBl bnRlciBpbiB0aGUgbWVyaXQgb2Ygd2hhdCBjb25zdGl0dXRlcyBhIHJlc291cmNlLCBhcyB0aGF0 IGRlcGVuZHMgb24gdGhlIG1vZGVsaW5nIG9mIHRoZSBkb21haW4gc3BlY2lmaWMgcHJvYmxlbSB0 aGUgZGV2ZWxvcGVyIGlzIHRhY2tsaW5nLiBUaGUgaGlnaGVzdCBvcmRlciBiaXQgaXMgdGhhdCBp ZiB0d28gZW50aXRpZXMgKEFQSSwgZXRjLi4NCiBpbnRlbmRlZCB0b2tlbiByZWNpcGllbnRzKSBo YXZlIGRpZmZlcmVudCBzZWN1cml0eSBjaGFyYWN0ZXJpc3RpY3MgKGUuZy4gbGVha2luZyBhIHRv a2VuIGZvciBvbmUgaGFzIGRpZmZlcmVudCBjb25zZXF1ZW5jZXMgdGhhbiBpZiB5b3UnZCBsZWFr IGEgdG9rZW4gZm9yIHRoZSBvdGhlciksIHRoZXkgc2hvdWxkIGJlIG1vZGVsZWQgYXMgZGlmZmVy ZW50IHJlc291cmNlcy4gQW5kIGlmIHRoZXkgYXJlIGRpZmZlcmVudCByZXNvdXJjZXMsIHdlIHNo b3VsZA0KIGRvIHdoYXQgd2UgY2FuIHRvIGF2b2lkIGNvbmZ1c2lvbiBpbiBob3cgd2UgZXhwcmVz cyBhY2Nlc3MgZ3JhbnRzIHRvIHRoZW0gKGhlbmNlIHRoZSBiaWcgZGlzY3Vzc2lvbiBvbiBtdWx0 aXJlc291cmNlLCBzY29wZSBjb25mdXNpb24sIGV0YykuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0t LS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9uIDMvMjQvMjAsIDEwOjM5LCAmcXVvdDtHZW9yZ2UgRmxldGNoZXImcXVvdDsgJmx0 O2dmZmxldGNoQGFvbC5jb20mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7RmVlZGJhY2sgb24gdGhlIHNwZWMuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1NlY3Rpb24gMS4gSW50cm9kdWN0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBsaW5lOiBzY2VuYXJpbyBzaG91bGQgYmUg cGx1cmFsIC0tJmd0OyBzY2VuYXJpb3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDD r8K/wr3Dr8K/wr3Dr8K/wr0gc2Vjb25kIHNlbnRlbmNlOiAmcXVvdDthcmUgbm90IHJhbiBieSZx dW90OyAtLSZndDsgJnF1b3Q7YXJlIG5vdCBydW4gYnkmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1NlY3Rpb24gMi4yLjEgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb24g Q2xhaW1zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9w6/Cv8K9 IEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgZGVmaW5pdGlvbiBvZiBgYXV0aF90aW1lYCBhbGxvd3Mg Zm9yIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2Ugd2hlcmUgYSB1c2VyIGlzIHJl cXVpcmVkIHRvIHNvbHZlIGFuIGFkZGl0aW9uYWwgY2hhbGxlbmdlLiBUYWtlIHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2Ugb2YgYSB1c2VyIHdobyBpcyByZXF1aXJlZCB0byBwYXNz IGEgc2Vjb25kYXJ5IGNoYWxsZW5nZSBiZWZvcmUgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7c3RvY2sgcHVyY2hhc2UmcXVvdDsgYWN0aW9uIGNhbiBiZSBjb21wbGV0ZWQuIEFj Y29yZGluZyB0byB0aGUgY3VycmVudCBzcGVjPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVm aW5pdGlvbiwgdGhlIGBhdXRoX3RpbWVgIHZhbHVlIE1VU1QgTk9UIGJlIHVwZGF0ZWQgd2hlbiB0 aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vjb25kYXJ5IGNoYWxsZW5nZSBpcyBjb21w bGV0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvDr8K/wr3Dr8K/ wr3Dr8K/wr0gSSB0aGluayB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXNzaW9uX3N0 YXJ0X3RpbWUgYW5kIGxhc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoX3RpbWUuIFRo aXMgZmVlbHMgbW9yZSBsaWtlIGl0J3MgZGVmaW5pbmcgdGhlIHNlc3Npb25fc3RhcnRfdGltZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmNlcHQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDvDr8K/wr3Dr8K/wr0gVGhlc2Ugc2FtZSBpc3N1ZXMgY2FuIGFwcGx5 IHRvIHRoZSBgYWNyYCBhbmQgYGFtcmAgdmFsdWVzIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvDr8K/wr3Dr8K/wr0gRXZlbiBpZiBmb3IgdGhpcyBzZWNv bmRhcnkgY2hhbGxlbmdlIGEgbmV3IHJlZnJlc2hfdG9rZW4gaXMgaXNzdWVkLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGl0IGlzIHVubGlrZWx5IG1hbnkgcmVseWluZyBwYXJ0aWVzIHdpbGwg d2FudCB0byB0cmVhdCB0aGF0IGFzIGlzc3VpbmcgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O25ldyBzZXNzaW9uLiBUaGUgZ29hbCBpcyB0byBrZWVwIHRoZSB1c2VyIGxvZ2dlZCBpbiB0byBh IHNpbmdsZSBzZXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2VjdGlv biAyLjIuMyBBdXRob3JpemF0aW9uIENsYWltczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IMOvwr/CvcOvwr/CvSBJIGZpbmQgdGhlIHN0YXRlbWVudCAmcXVvdDtBbGwgdGhlIGluZGl2 aWR1YWwgc2NvcGUgc3RyaW5ncyBpbiB0aGUgc2NvcGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBmb3IgdGhlIHJlc291cmNlIGluZGljYXRlZCBpbiB0 aGUgYXVkIGNsYWltJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc29tZXdoYXQgcHJv YmxlbWF0aWMuIEluIG1hbnkgZGVwbG95bWVudHMgdG9kYXkgZm9yIDFzdCBwYXJ0eSBjbGllbnRz IHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCB0YWtpbmcgaW50byBhY2NvdW50IG1vYmlsZSBhcHBsaWNhdGlvbnMsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlIGFjY2VzcyB0b2tlbiBtb3N0IGxpa2UgY29udGFpbnMgc2NvcGVzIGZv ciBtYW55IG9mIHRoZSAxc3QgcGFydHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiYWNrZW5k IEFQSXMuIEl0J3MgcG9zc2libGUgdG8gZ2V0IGFyb3VuZCB0aGlzIGJ5IHNldHRpbmcgdGhlICdh dWQnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhaW0gdG8gc29tZXRoaW5nIGxpa2UgJnF1 b3Q7Y29tLmV4YW1wbGUuYXBpcyZxdW90OyBhbmQgaGVuY2UgYWxsIHRoZSBpc3N1ZWQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzY29wZXMgbWFwIHRvIHRoYXQgYXVkaWVuY2UgY2xhaW0gYnV0 IHRoYXQgaXMganVzdCB3b3JraW5nIGFyb3VuZCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBNVVNUIGluIHRoZSBzcGVjLiBHaXZlbiB0aGUgbGFjayBvZiBzcGVjaWZpY2l0eSBvZiB0aGUg J2F1ZCcgY2xhaW0gYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlICdyZXNvdXJjZSBp bmRpY2F0b3InIGNsYWltIGZvciB0aGF0IG1hdHRlciwgcHJldHR5IG11Y2ggYW55dGhpbmcgY2Fu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgbWFkZSB0byBjb21wbHkuIEluIHRoYXQgY29u dGV4dCwgaXQgc2VlbXMgbGlrZSBSRUNPTU1FTkQgaXMgYSBiZXR0ZXI8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBub3JtYXRpdmUgY2xhdXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7U2VjdGlvbiAzLiBSZXF1ZXN0aW5nIGEgSldUIEFjY2VzcyBUb2tlbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBQZXIgbXkgY29tbWVudHMgYWJvdmUg SSBzdXNwZWN0IHRoYXQgcmVxdWlyaW5nIGFsbCBKV1QgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRvIGluY2x1ZGUgYW4gYXVkaWVuY2UgY2xhaW0gd2lsbCBqdXN0IGRl dm9sdmUgdG8gYXVkaWVuY2UgY2xhaW1zIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh cmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRlciB0byBtZWV0IHRoaXMgTVVTVCBpbiB0aGUg c3BlYykuIEdpdmVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIG1vYmlsZSBhcHAgZW52 aXJvbm1lbnQgdG9kYXksIGl0IGlzIHVucmVhc29uYWJsZSB0byBhc2sgdGhlIG1vYmlsZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcHMgdG8gZG93bnNjb3BlIGV2ZXJ5IGFjY2VzcyB0b2tl biBiZWZvcmUgbWFraW5nIGFuIEFQSSBjYWxsIHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGJhY2tlbmQgQVBJcyB3aGljaCBpcyB3aGF0IHRoZSBzcGlyaXQgb2YgYXVkaWVuY2UgYW5k IHJlc291cmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdG9ycyBzZWVtIHRvIGlt cGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7w6/Cv8K9w6/Cv8K9 IFdoeSBNVVNUIHRoZSBBUyByZWplY3QgYSByZXF1ZXN0IHdpdGggbW9yZSB0aGFuIG9uZSByZXNv dXJjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlcj8gSWYgYSByZXF1ZXN0IGNv bWVzIGluIHdpdGggbm8gcmVzb3VyY2UgcGFyYW1ldGVyIGFuZCBtdWx0aXBsZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNjb3BlcyB0aGUgQVMgaXMgbm90IHJlcXVpcmVkIHRvIHJlamVjdCB0 aGF0IHJlcXVlc3QuIElzIHRoZXJlIG11Y2ggb2YgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNlbWFudGljIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvPyBJbiB0aGUgY2FzZSBvZiBubyBy ZXNvdXJjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlciBhbmQgbXVsdGlwbGUg c2NvcGVzIHRoZSBBUyBtaWdodCBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gd2l0aDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGF1ZGllbmNlIHZhbHVlcyAoYXMgaXMgYWxsb3dlZCBi eSBSRkMgNzUxOSkuIEFsc28sIHRoZSBhdWRpZW5jZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNsYWltIGlzIG5vdCBzb2xlbHkgZm9yIHJlc291cmNlIGluZGljYXRvciB2YWx1ZXMgYnV0IGlz IGRlZmluZWQgdG8ganVzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGEgc3RyaW5nLiBU byBtZSBpdCBmZWVscyBsaWtlIHRoZSB0ZXh0IGlzIGltcGx5aW5nIHRoYXQgdGhlIG9ubHk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWxpZCBhdWRpZW5jZSB2YWx1ZSBpcyBhbHNvIGEgcmVz b3VyY2UgaW5kaWNhdG9yICh3aGljaCBmcm9tIHByZXZpb3VzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGlzY3Vzc2lvbnMgb24gdGhlIGxpc3QgaXQgd2FzIGltcGxpZWQgdGhleSBoYXZlIGEg c2xpZ2h0bHkgZGlmZmVyZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtYW50aWMpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7w6/Cv8K9w6/Cv8K9IFRoZSBt b2RlbCBkZXNjcmliZWQgaGVyZSB3b3JrcyB3ZWxsIGlmIG15Y28uZXhhbXBsZSByZWFsbHkgb25s eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGVzIGEgc2luZ2xlIHNlcnZpY2UuIEJ1 dCBpZiBpbnN0ZWFkIG15Y28uZXhhbXBsZSBwcm92aWRlcyBtdWx0aXBsZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNlcnZpY2VzIGVhY2ggd2l0aCB0aGVpciBvd24gZW5kcG9pbnRzIChzcnZh Lm15Y28uZXhhbXBsZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcnZiLm15Y28uZXhhbXBs ZSkgYW5kIHNjb3BlcywgZm9yIG1lIHRoaXMgbW9kZWwgYmVnaW5zIHRvIGJyZWFrIGRvd24uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRWl0aGVyIG1vYmlsZSBhcHBzIGFyZSByZXF1aXJlZCB0 byBkb3duc2NvcGUgYWxsIHRva2VucyB0byBqdXN0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNlcnZpY2UgdGhleSBhcmUgY2FsbGluZyBhdCB0aGF0IHBvaW50IGluIHRpbWUgKHdoaWNo IGNhbiBoYXZlIGxhdGVuY3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgY29ubmVjdGl2 aXR5IGlzc3VlcyksIG9yIG15Y28uZXhhbXBsZSBoYXMgdG8gY3JlYXRlIGEgZ2VuZXJpYzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2F1ZGllbmNlJnF1b3Q7IHN0cmluZyB0aGF0IHJl cHJlc2VudHMgYWxsIG9mIGV4YW1wbGUuY29tIHdoaWNoIGRvZXNuJ3Qgc2VlbTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3RvIGJlIHRoZSBzcGlyaXQgb2YgdGhlIGV4aXN0aW5nIHNwZWNzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7w6/Cv8K9w6/Cv8K9IEluIHN1 bW1hcnksIEkgZmVlbCB0aGF0IHRoaXMgdGV4dCBpcyBiaW5kaW5nIHRvbyB0aWdodGx5IHJlc291 cmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdG9ycyB0byB0aGUgYXVkaWVuY2Ug Y2xhaW0uIFdoYXQgaXMgZGVzY3JpYmVkIGlzIHBlcmZlY3RseTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlYXNvbmFibGUgaW4gYSB1c2UgY2FzZSB0aGF0IGlzIGFwcGx5aW5nIHJlc291cmNl IGluZGljYXRvcnMgaW4gdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdheSBidXQgaXMg bm90IGluZGljYXRpdmUgb2YgdGhlIHdpZGVseSBkZXBsb3llZCBtb2RlbHMgdGhhdCBhbHJlYWR5 IGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2VjdGlvbiA0LiBWYWxp ZGF0aW5nIEpXVCBBY2Nlc3MgVG9rZW5zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg w6/Cv8K9w6/Cv8K9IFN0ZXAgNC4gLS0gQ2FuIHdlIGNoYW5nZSB0aGUgd29yZGluZyB0byBub3Qg cmVxdWlyZSByZXNvdXJjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGljYXRvcnM/IFdo YXQgYWJvdXQuLi4gJnF1b3Q7VGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoYXQg dGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJ2F1ZCcgY2xhaW0gY29udGFpbnMgYSBzdHJp bmcgdGhhdCByZXByZXNlbnRzIHRoZSBhdWRpZW5jZSBvZiB0aGlzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVzb3VyY2Ugc2VydmVyLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7U2VjdGlvbiA1LiAmcXVvdDtjcm9zcy1KV1QgY29uZnVzaW9uJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IEkgdGhpbmsgdGhlcmUgbWF5 IGJlIGNvbmZ1c2lvbiBhcm91bmQgd2hhdCBpcyBtZWFudCBieSAmcXVvdDtkaXN0aW5jdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNlcyZxdW90Oy4gSW4gbXkgZXhhbXBsZSBhYm92 ZSwgYXJlIHNydmEubXljby5leGFtcGxlIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNy dmIubXljby5leGFtcGxlICZxdW90O2Rpc3RpbmN0IHJlc291cmNlcyZxdW90Oz8gb3IgaXMgdGhl IGdvYWwgaGVyZSB0byBzYXkgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdlIHdhbnQg ZGlmZmVyZW50IGF1ZGllbmNlIHZhbHVlcyBnZW5lcmF0ZWQgZm9yIGNyb3NzLW9yZ2FuaXphdGlv bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNlcy4gRm9yIGV4YW1wbGUsIGFyZSBt YWlsLmdvb2dsZS5jb20gYW5kIHlvdXR1YmUuY29tICZxdW90O2Rpc3RpbmN0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcmVzb3VyY2VzJnF1b3Q7PyBvciB3b3VsZCBhbiBhdWRpZW5jZSBmb3Ig Z29vZ2xlIHN1ZmZpY2UgaW4gbWVldGluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBt ZWFuaW5nIG9mIHRoaXMgcGFyYWdyYXBoPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7w6/Cv8K9IEknbSBoYXZpbmcgdGhlIHNhbWUgY29uZnVzaW9uIGluIHRoZSBuZXh0 IHBhcmFncmFwaCByZWdhcmRpbmcgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGhyYXNl ICZxdW90O2RpZmZlcmVudCByZXNvdXJjZXMmcXVvdDsuIEFyZSBzZXJ2aWNlcyBwcm92aWRlZCBi eSB0aGUgc2FtZSBjb21wYW55PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGlmZmVy ZW50IHJlc291cmNlcyZxdW90OyBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2FtZSBy ZXNvdXJjZS4gQ2FuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW4gYWNjZXNzIHRva2VuIGJl IGlzc3VlZCB3aXRoIHNjb3BlcyBmb3IgYm90aCBtYWlsLmdvb2dsZS5jb20gYW5kPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgeW91dHViZS5jb20/IEFuZCBpZiBub3QsIHdoeSBub3RlPyBQcmV2 ZW50aW5nIHRoaXMgcHV0cyB1bmR1ZSBidXJkZW4gb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBtb2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7U2VjdGlvbiA2LiBQcml2YWN5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg w6/Cv8K9w6/Cv8K9IGNvZmlkZW50aWFsaXR5IC0tJmd0OyBjb25maWRlbnRpYWxpdHk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEdlb3JnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MWHPR19MB1501ACC81394A8D8B19050F1AEC70MWHPR19MB1501namp_-- From nobody Fri Apr 3 06:22:22 2020 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 00B443A0805 for ; Fri, 3 Apr 2020 06:22:21 -0700 (PDT) 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 ag7uD8gCu8Wl for ; Fri, 3 Apr 2020 06:22:16 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 9355C3A0806 for ; Fri, 3 Apr 2020 06:22:16 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id d11so7874227qko.3 for ; Fri, 03 Apr 2020 06:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=I1HA3BjTSn2FN9ey3hwQH8Ey67xvia60Koi7sZkESds=; b=rGj4zHqwNU7XGgohIiaHGW3K9fld8CCNJ+dLqEXX3jCVtsqDNHypHXMiAZ1JfjwoQx oqlAE6ARX/f7fq6CfEL76TEsdq9FVCZns2kdzgIBOEd9i/ynN6u8jq+StRhKTfTyjTLJ NB3JAGLsvanIAcDSTEdFdQm0HhDBDgZV0cryhSiMlMhIcS5NYJelWjjOPF6iAJ1ad1J+ jRaZtoebYtDHZcMv5pwolWmemc56D6EVUHgV5H4fprFN5Hd3VhCqSI6ETpnzzFtba+CZ XM86I1bPBiU5oNbxANNesrm/7HtVFwFpzLtGmmtzvDQ/7mH/KQiCP+xLkLj1jp6GntLB NiAA== 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=I1HA3BjTSn2FN9ey3hwQH8Ey67xvia60Koi7sZkESds=; b=ZjzvTcJEwtM9cOfkw/F1eDCvGHmAedthKPkxR0irxLQOmgHJavLAF/2MqoYayZ9Lbx 9yJMjra2sJGMCybKFiXgq3GssonIdI0eyVYREff7qP+6qlXeaQ1qAaSRuK+vakTL/04Z OJvgByMHeD/QT2miZ9X634GdInQTtgUBfB8kBaHZlf/qn926/QRv3FLeLb/nwABQoX+j iLQ0lpP392kyOKpsQlunxTeQfKIAEX7Yf2rt9MxjOJe5dVdXHntdg387TuRTsJneCx8/ jGcXLosx+OgidW5+t1aj8wwGGmcWgRiO3xbkynX51faivaB7MTNdm0/UTa1XraIPIPTc YtpQ== X-Gm-Message-State: AGi0PubT5C4ZbpOvffq31kSfgWHpPT8J/GvahNAy9laUkU78JJs2BhHz 8ZZMjBlQqA+IOJ6MAXV59Ox2GnKAb6NeHKWG8FYsTauUxDY= X-Google-Smtp-Source: APiQypLzP/8PnEls04naMxI88sVbEjcfFYpyil/yZ1QOrYdo8XYD2XzwC9T/aLqciNtWozlJMy9of8VLTQNAD8Qy1yE= X-Received: by 2002:a37:884:: with SMTP id 126mr8333248qki.72.1585920135340; Fri, 03 Apr 2020 06:22:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andre Triverio Date: Fri, 3 Apr 2020 15:22:04 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f28c105a262ce76" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 110 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, 03 Apr 2020 13:22:21 -0000 --0000000000004f28c105a262ce76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Allez-vous cesser de m'envoyer des mails ! Je n'en veux pas ! Et pour se desabonner, tout est fait pouir ne pas y r=C3=A9ussir ! Le lun. 30 mars 2020 =C3=A0 18:41, a =C3=A9crit : > 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. RAR - Example JWT for Payment (Jared Jennings) > 2. Re: Error Responses in JWT Profile for OAuth 2.0 Access > Tokens (Karl McGuinness) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Mar 2020 08:18:49 -0500 > From: Jared Jennings > To: oauth > Subject: [OAUTH-WG] RAR - Example JWT for Payment > Message-ID: > < > CAMVRk+LP6be1-dZ3bmpsT+3OPXWs_cP7gvsNEA7-T7Km1UEeOQ@mail.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > I have a question about the example and maybe it's more for > clarification than anything. > > The example contains type and also location. > A couple of things > 1. Would it add clarity if the domain was the same for both? vs. > someorg.com > / example.com > 2. While only an example, would it bring clerity to past examples if the > type was https://schema.example.com/payment_initiation and the location > was > https://api.example.com/payments > > or am I missing something what the values represent? > > Here's the example I am referring to on page 17. > > { > "iss": "https://as.example.com", > "sub": "24400320", > "aud": "a7AfcPcsl2", > "exp": 1311281970, > "acr": "psd2_sca", > "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296", > "authorization_details": [ > { > "type": "https://www.someorg.com/payment_initiation", > "actions": [ > "initiate", > "status", > "cancel" > ], > "locations": [ > "https://example.com/payments" > ], > "instructedAmount": { > "currency": "EUR", > "amount": "123.50" > }, > "creditorName": "Merchant123", > "creditorAccount": { > "iban": "DE02100100109307118603" > }, > "remittanceInformationUnstructured": "Ref Number Merchant" > } > ], > "debtorAccount": { > "iban": "DE40100100103307118608", > "user_role": "owner" > } > ] > > > -Jared > Skype:jaredljennings > Signal:+1 816.730.9540 > WhatsApp: +1 816.678.4152 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/cdb44= a38/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Mar 2020 16:38:04 +0000 > From: Karl McGuinness > To: "vittorio.bertocci=3D40auth0.com@dmarc.ietf.org" > > Cc: Aaron Parecki , OAuth WG > Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 > Access Tokens > Message-ID: <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com> > Content-Type: text/plain; charset=3D"utf-8" > > Hi Vittorio, > > I was chatting with Aaron offline about this issue and my concern is the > addition of Authentication Information Claims in this spec opens up more > interoperability issues that can?t be addressed with just a JWT Access > Token spec. > > OAuth 2.0 AFAIK, doesn?t define any behaviors around resource owner > authentication assurance with respect to issuing, introspecting, or > presenting access tokens. > > * Token introspection > * Token validation error responses > * Token refresh > * Client Remediation (oidc defined prompt=3Dlogin, max_age, and > acr_values) > * Metadata > > This spec is defining AS behaviors that are orthogonal to the format and > should be available via token introspection for example > > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-= 2.2.1 > > > The claims listed in this section reflect in the access token the the > types and strength of authentication that the authentication server > enforced prior to returning the authorization response to the client. > Their values are fixed, and remain the same across all access tokens > that derive from a given authorization response, whether the access > token was obtained directly in the response (e.g., via the implicit > flow) or after one or more token exchanges (e.g., obtaining a fresh > access token using a refresh token, or exchanging one access token > for another via [RFC8693]). > > > I was hoping one of the outcomes of this spec was toolkit/sdk interop for > clients and resource servers. I don?t see how this possible if all the > semantics around requesting, validating, and remediating resource owner > authentication assurance is implementation specific. The end-to-end > scenarios are not achievable with just OAuth 2.0 which breaks interop. > > I think there is a real need to define resource owner authentication > assurance interoperability for access tokens, but I fear this may require > its own spec. > > -Karl > > Karl McGuinness > Chief Product Architect > www.okta.com > > On Mar 25, 2020, at 12:59 PM, vittorio.bertocci=3D40auth0.com@dmarc.ietf.= org > wrote: > > This message originated outside your organization. > > Thanks Aaron! > You are right, we could be clearer re:errors. AFAIK the only errors we ca= n > rely on from an RS are in RFC6750, and the entire section is about what t= o > look for in an incoming AT to validate, hence it doesn't look like we hav= e > much choice but to return invalid_token for every error in the validation > checks enumerated in Section 4. I can definitely add a paragraph to that > effect (does it have to be a section?). > > The re-authentication part is tricky. Technically we are still rejecting > the > incoming token, hence the above should still apply. > I am not aware of tools we can use from the primitives defined in the > OAuth2 > family of standards for telling people how to make reauthentication happe= n- > and making reauth happen can be quite involved. In Azure AD there are sem= i > proprietary mechanisms that can be used to signal the need to repeat > authentication, say for triggering a step-up auth, by sending back togeth= er > with the error response a challenge that can in turn be used by the clien= t > to communicate policy requirements to the AS (which is assumed to support > OIDC and accept/understand those policies in form of claim). Giving > equivalent guidance but relying only on standards seems tricky, especiall= y > without making strong assumptions about how auth happens (e.g can we assu= me > OIDC?). > To solve this for the profile, I see two main ways forward: > A) We warn the reader that it's on them to decide how to signal the reaut= h > requirement from the API to the client, and how to use that in the client > to > AS subsequent authorization request > B) We venture in devising a standard mechanism for propagating errors tha= t > require reauth, basically extending RFC6750 with a new use case (perhaps = by > detailing extra info to be put in WWW-Authenticate?). > > I can see how B) might be useful in general, but it doesn't seem > particularly tied to the fact that the ATs being discussed here are JWTs.= .. > hence I'd be inclined to declare it out of scope here, tho I would really > love for us to devise a standard solution for it _somewhere_. > WDYT? > > > > -----Original Message----- > From: OAuth > On > Behalf Of Aaron Parecki > Sent: Wednesday, March 25, 2020 12:07 PM > To: OAuth WG > > Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access > Tokens > > Section 4 talks about validating JWT Access Tokens > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-= 4 > > It has a list of things the RS MUST do when validating a request made wit= h > a > JWT access token. This section contains phrases like "...and reject > tokens..." and "MUST be rejected if...", without clear instructions on > *how* > to reject this request. For these, I could infer that the RFC6750 error > code > "invalid_token" is the correct response, but these could benefit from bei= ng > more explicit about that here. > > Step 7 says: "the resource server SHOULD check the auth_time value and > request re-authentication..." But there are no instructions on how the RS > should respond to indicate that the client should request > re-authentication. > This sounds like a different response than "invalid_token" to me, but in > any > case, regardless of what the correct response is, Section 4 really needs = a > description of how to respond in these error cases. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > _______________________________________________ > 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 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/6db2d= 3fd/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 137, Issue 110 > *************************************** > --=20 Andr=C3=A9 Triverio, CJM --0000000000004f28c105a262ce76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Allez-vous=C2=A0cesser de m'envoyer=C2=A0des mails !Je n'en veux pas !
Et pour se desabonner, tout est fait po= uir=C2=A0ne pas y r=C3=A9ussir !

=
Le=C2=A0lun. 30 mars 2020 =C3=A0=C2= =A018:41, <oauth-request@ietf.= org> a =C3=A9crit=C2=A0:
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.org/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. RAR - Example JWT for Payment (Jared Jennings)
=C2=A0 =C2=A02. Re: Error Responses in JWT Profile for OAuth 2.0 Access
=C2=A0 =C2=A0 =C2=A0 Tokens (Karl McGuinness)


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

Message: 1
Date: Mon, 30 Mar 2020 08:18:49 -0500
From: Jared Jennings <jaredljennings@gmail.com>
To: oauth <oauth@iet= f.org>
Subject: [OAUTH-WG] RAR - Example JWT for Payment
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAMVRk+LP6= be1-dZ3bmpsT+3OPXWs_cP7gvsNEA7-T7Km1UEeOQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

I have a question about the example and maybe it's more for
clarification than anything.

The example contains type and also location.
A couple of things
1. Would it add clarity if the domain was the same for both? vs. someorg.com / examp= le.com
2. While only an example, would it bring clerity to past examples if the type was https://schema.example.com/payment_initiation<= /a> and the location was
https://api.example.com/payments

or am I missing something what the values represent?

Here's the example I am referring to on page 17.

{
=C2=A0 =C2=A0 =C2=A0 "iss": "https://as.example.com",<= br> =C2=A0 =C2=A0 =C2=A0 "sub": "24400320",
=C2=A0 =C2=A0 =C2=A0 "aud": "a7AfcPcsl2",
=C2=A0 =C2=A0 =C2=A0 "exp": 1311281970,
=C2=A0 =C2=A0 =C2=A0 "acr": "psd2_sca",
=C2=A0 =C2=A0 =C2=A0 "txn": "8b4729cc-32e4-4370-8cf0-5796154= d1296",
=C2=A0 =C2=A0 =C2=A0 "authorization_details": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "https://www.someorg.com/payment_initiation",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "actions": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"initiate"= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"status",<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"cancel" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://exa= mple.com/payments"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "instructedAmount": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"currency"= : "EUR",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"amount": = "123.50"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "creditorName": "M= erchant123",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "creditorAccount": { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"iban": &q= uot;DE02100100109307118603"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "remittanceInformationUnstru= ctured": "Ref Number Merchant"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 "debtorAccount": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"iban": "DE401001001033071= 18608",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"user_role": "owner"<= br> =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0]


-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/cdb44a= 38/attachment.html>

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

Message: 2
Date: Mon, 30 Mar 2020 16:38:04 +0000
From: Karl McGuinness <kmcguinness@okta.com>
To: "vittorio.bertocci=3D40auth0.com@dmarc.ietf.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>=
Cc: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Access Tokens
Message-ID: <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com&g= t;
Content-Type: text/plain; charset=3D"utf-8"

Hi Vittorio,

I was chatting with Aaron offline about this issue and my concern is the ad= dition of Authentication Information Claims in this spec opens up more inte= roperability issues that can?t be addressed with just a JWT Access Token sp= ec.

OAuth 2.0 AFAIK, doesn?t define any behaviors around resource owner authent= ication assurance with respect to issuing, introspecting, or presenting acc= ess tokens.

=C2=A0 *=C2=A0 =C2=A0Token introspection
=C2=A0 *=C2=A0 =C2=A0Token validation error responses
=C2=A0 *=C2=A0 =C2=A0Token refresh
=C2=A0 *=C2=A0 =C2=A0Client Remediation (oidc defined prompt=3Dlogin, max_a= ge, and acr_values)
=C2=A0 *=C2=A0 =C2=A0Metadata

This spec is defining AS behaviors that are orthogonal to the format and sh= ould be available via token introspection for example

https://tools.ietf.org= /html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1


The claims listed in this section reflect in the access token the the
=C2=A0 =C2=A0types and strength of authentication that the authentication s= erver
=C2=A0 =C2=A0enforced prior to returning the authorization response to the = client.
=C2=A0 =C2=A0Their values are fixed, and remain the same across all access = tokens
=C2=A0 =C2=A0that derive from a given authorization response, whether the a= ccess
=C2=A0 =C2=A0token was obtained directly in the response (e.g., via the imp= licit
=C2=A0 =C2=A0flow) or after one or more token exchanges (e.g., obtaining a = fresh
=C2=A0 =C2=A0access token using a refresh token, or exchanging one access t= oken
=C2=A0 =C2=A0for another via [RFC8693<https://tools.ietf.org/h= tml/rfc8693>]).


I was hoping one of the outcomes of this spec was toolkit/sdk interop for c= lients and resource servers.=C2=A0 =C2=A0I don?t see how this possible if a= ll the semantics around requesting, validating, and remediating resource ow= ner authentication assurance is implementation specific.=C2=A0 =C2=A0The en= d-to-end scenarios are not achievable with just OAuth 2.0 which breaks inte= rop.

I think there is a real need to define resource owner authentication assura= nce interoperability for access tokens, but I fear this may require its own= spec.

-Karl

Karl McGuinness
Chief Product Architect
www.ok= ta.com<http://www.okta.com/>

On Mar 25, 2020, at 12:59 PM, vittorio.bertocci=3D40auth0.com@dmarc.ietf.org<ma= ilto:vittorio.bertoc= ci=3D40= auth0.com@dmarc.ietf.org> wrote:

This message originated outside your organization.

Thanks Aaron!
You are right, we could be clearer re:errors. AFAIK the only errors we can<= br> rely on from an RS are in RFC6750, and the entire section is about what to<= br> look for in an incoming AT to validate, hence it doesn't look like we h= ave
much choice but to return invalid_token for every error in the validation checks enumerated in Section 4. I can definitely add a paragraph to that effect (does it have to be a section?).

The re-authentication part is tricky. Technically we are still rejecting th= e
incoming token, hence the above should still apply.
I am not aware of tools we can use from the primitives defined in the OAuth= 2
family of standards for telling people how to make reauthentication happen-=
and making reauth happen can be quite involved. In Azure AD there are semi<= br> proprietary mechanisms that can be used to signal the need to repeat
authentication, say for triggering a step-up auth, by sending back together=
with the error response a challenge that can in turn be used by the client<= br> to communicate policy requirements to the AS (which is assumed to support OIDC and accept/understand those policies in form of claim). Giving
equivalent guidance but relying only on standards seems tricky, especially<= br> without making strong assumptions about how auth happens (e.g can we assume=
OIDC?).
To solve this for the profile, I see two main ways forward:
A) We warn the reader that it's on them to decide how to signal the rea= uth
requirement from the API to the client, and how to use that in the client t= o
AS subsequent authorization request
B) We venture in devising a standard mechanism for propagating errors that<= br> require reauth, basically extending RFC6750 with a new use case (perhaps by=
detailing extra info to be put in WWW-Authenticate?).

I can see how B) might be useful in general, but it doesn't seem
particularly tied to the fact that the ATs being discussed here are JWTs...=
hence I'd be inclined to declare it out of scope here, tho I would real= ly
love for us to devise a standard solution for it _somewhere_.
WDYT?



-----Original Message-----
From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> On Behalf Of Aaro= n Parecki
Sent: Wednesday, March 25, 2020 12:07 PM
To: OAuth WG <oauth@= ietf.org<mailto:= oauth@ietf.org>>
Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access
Tokens

Section 4 talks about validating JWT Access Tokens

https://tools.ietf.org/htm= l/draft-ietf-oauth-access-token-jwt-04#section-4

It has a list of things the RS MUST do when validating a request made with = a
JWT access token. This section contains phrases like "...and reject tokens..." and "MUST be rejected if...", without clear instr= uctions on *how*
to reject this request. For these, I could infer that the RFC6750 error cod= e
"invalid_token" is the correct response, but these could benefit = from being
more explicit about that here.

Step 7 says:=C2=A0 "the resource server SHOULD check the auth_time val= ue and
request re-authentication..." But there are no instructions on how the= RS
should respond to indicate that the client should request re-authentication= .
This sounds like a different response than "invalid_token" to me,= but in any
case, regardless of what the correct response is, Section 4 really needs a<= br> description of how to respond in these error cases.

----
Aaron Parecki
aa= ronparecki.com
@aaronpk

_______________________________________________
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/6db2d3= fd/attachment.html>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 137, Issue 110
***************************************


--
Andr=C3=A9 Tri= verio, CJM
--0000000000004f28c105a262ce76-- From nobody Fri Apr 3 12:20:27 2020 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 672163A03EA for ; Fri, 3 Apr 2020 12:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DATE_IN_PAST_12_24=1.049, 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=no 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 72LuqYf-pQhq for ; Fri, 3 Apr 2020 12:20:21 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 915EE3A03EE for ; Fri, 3 Apr 2020 12:20:16 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id z12so7464217qtq.5 for ; Fri, 03 Apr 2020 12:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:savedfromemail:date:subject:importance:from:to :mime-version; bh=T7rk5RKnM5NjMj2jggJGw22kGbEUvZJIqBwuOYSbqSE=; b=dnV+93S3/FxQusF0PgjbYfk9g8S0z/8VFDhJV+1EFl/CUNyPecYiF01tBVsuExZvOt BS/6DU0WVnn6rwi4j+TLLTNNjcZFKIbcRCbD8zJbxJ8ARDk3ERP8EQNwju95uHGaZ1GH SKIPYjYh8HQ9yZv9xi8w7HJgmEHcc/qUO7ShbC0Alv9WUO06sArvjJq6D6xz2MgiCYkp ADmL+CLDBll9WvMOR3XmD7ApNXJc8lqFyD/mnW1audIvc1qCbIMtS5LbBRDrGrZXkhXT SNi0iGsDfHTHvRHcwvIkYgIayvTnAdbCp4IPZP96SmN+xosOyZGJpO59gXXBYiuBiQSz 9+cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:savedfromemail:date:subject :importance:from:to:mime-version; bh=T7rk5RKnM5NjMj2jggJGw22kGbEUvZJIqBwuOYSbqSE=; b=RoTFy2m5JfwRLaI4+EYQclatCdIHHKreHjr68iROBCKcpUCgHY4CkCwrZI5NyqQLbO XTFKtjek7xGtE3tqgh//37DpbzfwEWulKaqiJtZgUaxh2tlPlokqYH+KBZrCHw4K1poh JrhAMTon5Do+jP01EREY0dnDyxQhs2h4rKbG2RF3hYqSJgPuzmZe+hQ/jplR0dtP0wuK opM+tH+Y6xxixObx8LectpMVW/QKsCvI03SHpzLmu1HpTgxPmIXkj0FAb4h0nB6RPNcP iSdCUSZKf2IdNaVv7JFIEES1x8gc4pr1lAEtX8+4E26O5bGHoD2wjFiUY48xw3mMgQvG JFdA== X-Gm-Message-State: AGi0PuaWYRFjREPQ3yBIKK3Y3uw55VyvtQ0Nuc41bT9AFXJAhbF/IKWf kzvViUzIbFpZ7XzjoWQAg4Uyuc4clQk= X-Google-Smtp-Source: APiQypJ8iU0yz/gTNBy3bDnYxASrnY88OghA1LUdX5B3DitsATrKRTaOHlJLpjpO5bwoiRCwEFpMwg== X-Received: by 2002:ac8:2f93:: with SMTP id l19mr9958318qta.14.1585941615018; Fri, 03 Apr 2020 12:20:15 -0700 (PDT) Received: from [192.168.0.14] (S0106bc4dfb1bb4c3.wp.shawcable.net. [24.76.89.102]) by smtp.gmail.com with ESMTPSA id x74sm7093869qkb.40.2020.04.03.12.20.13 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Apr 2020 12:20:14 -0700 (PDT) Message-ID: <5e878c6e.1c69fb81.cbb8f.b5ea@mx.google.com> SavedFromEmail: laylafrobisher1010@gmail.com Date: Thu, 02 Apr 2020 14:19:39 -0600 Importance: normal From: laylafrobisher1010 To: OAuth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_400546405211170" Archived-At: Subject: [OAUTH-WG] I don't feel like it was good night my love 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, 03 Apr 2020 19:20:27 -0000 ----_com.samsung.android.email_400546405211170 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U2VudCBmcm9tIFNhbXN1bmcgdGFibGV0LlJhY2hlbCBpcyBub3QgZ29pbmcgdG8gYmUgYWJsZSB0 byBtYWtlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIGJlaW5nIGluIGRldG94IHByb2dyYW0gaGFzIGJl ZW4gb24gdXNlZCB0byBtYWtlIGl0IGFuIGV4Y2VsbGVudCB3YXkgdG8gZ2V0IG91dCBvZiB0aGUg aG91c2XCoA== ----_com.samsung.android.email_400546405211170 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9z aWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJh dXRvIj5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuUmFjaGVsIGlzIG5vdCBnb2luZyB0byBiZSBh YmxlIHRvIG1ha2UgYSBkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcgaW4gZGV0b3ggcHJvZ3JhbSBo YXMgYmVlbiBvbiB1c2VkIHRvIG1ha2UgaXQgYW4gZXhjZWxsZW50IHdheSB0byBnZXQgb3V0IG9m IHRoZSBob3VzZSZuYnNwOzwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_400546405211170-- From nobody Fri Apr 3 13:21:22 2020 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 90B493A0A0A for ; Fri, 3 Apr 2020 13:21:20 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 KZJQDsNMD54G for ; Fri, 3 Apr 2020 13:21:14 -0700 (PDT) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.148]) (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 A77383A09F9 for ; Fri, 3 Apr 2020 13:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1585945273; bh=IrmSpXyuRo0wa+VpB4jy8O0tON/cb91o2mBq/XgRXc8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Q1xxIYvmLRh8+MFB3QP68l/YfgJTu0W5ozoVvcxaFu8+HuRHYJDW7j71OUtfiQ5sAbcEp+oq3pJNiqOF/GeDFd+BOIDX6sg9vqD2H3DoOMQYt0QHTYnIq3qBnS4vVLrrNNTIUp7Nh++l8x+bS/C62wtaKLH6N52YF9+AEr8LlgrkZ9q4rBMsjn7i2FwZfR+vgiKb/R27njh/UnPAzwi0wq/v3q18l/FLwRHYOWRLNODsEeeiZRjgRdQZGtzwKEtGY+20LbBIZ/7tMyD5ZGpWD7Yt/XjP4EuuhQjQ4ZRczkDXm82ERbARqOuvRC39SJ7kWrKrwszJvJe96TydHOLsbw== X-YMail-OSG: HLO7fOEVM1mYd1qyzho4vVklBvT0ZmEmsYip44nsQ6RoRzPAzmaBn70WoCoUlga zLhgTeVW4jEMAeVc.RvjbKNz5a9djURsLo6XeSVSKidsu5sgK3mh_s9QWsleaRmmoJVD5No4.in0 EX4qsBCc.I1XVKHyGzShvK26UU5GOWomzQzUrX5o.ekY98kkbQdGy_ir7.xbgvW6nmiHx03Dtsuw sa_ZC0jOPhK5vlqldUlzB4UlAnm8ztnNux.x77HpG75eRqJQe_o4Jgk3R2o.t7BgXb7RjVF9iqlo NcvN4Hm3Q0lOj2IXFx3o5bQmeskUq.lO0atbW.lH6ziQoLskzGeLXX0KZe5s6aG1RCt2SL4QWY_k 5bKRDaEwM6bCnL8t74RBxXDfQKsl6.b7O.ET0RiCvcOnOltGOVtompvAArr8rNGaoaRieAjlEQPM wSsVpXlNxHEwqzGToeVfO2pYKzOal2NWkwhPBShisg6OjZ3rN9dZ2Xtr3LEjd5UP9cWqUfuJcxOU r6AR4JjMlDrxA4jcY1ZrlRvq0mOlqd.jYJy7W2U4sQD5w7_.es9GzF6Q56YXBDQjNPW2lH2RQU7I 1pRTSLdMpLqj4.Dd7eG3ifrKDDOYMdyWTqXETtfkG6DYM772t.iZwygGj1PZgozkwhrR4Ftnn.rS OA6dzDw1j_gJorm86Fsa1EjEwsAaxZ5p6bMRO5BI07IqFoXZirbweptgLDXTSTSoRJn2DUKJqHn1 AbohOdAzaTmvwGW4jknjOcd1dNnb7eV1fJ7K8jwBbK5EiCGDLeMMfFmVXpLGIwlaxHGB_ndpqXW2 aAix1UeI_94nFAXRhWuUaHqlPxvMZ_c6TEapGA1rECyTj.D6GvdXH4gPA03g.Nqu76yUavWJgKdQ bhyaskcFVRWrnj3T1WFXFC_1WZ14fq8eWNf_upNnsl6utvSrBkPbw4P77YOsw82Rv1XT3JVa1ySP 2zYQvgEbZbddDWYLeHz5ZxZADENXrwXw12BPhMrFBuZZ_cO6YMkH8NzGyrqao2p1_LVUxx0nkW8i sbMgBYp2fOi6JW2ULwh6IGgsUn2bW9BtuvGIYvlm0gUnsF_yJX6L9PHC.HyRqpt_.XTC.xLGI8HM KSKT7PVWIlbsbNjeOsFQLCa6xPgdp6MrVavFgsCZqinXBg.zCwVAuZRGRYjXOkYX1JWA6PQHnDsV bAMXQc5LhuJafQKOgJsT2Rnr2Ezp1h4XeFMHJFGgID_KSTQ8LFMiJnJ6k0UFDhZLSLcPNXR.W9s2 ItHG87dUAz74a9gxaprGg.fgMND6PLFSsl2KuV.Ev5O9YmRXXlqrluQwWuhR2YjvOp0mx3Hja9yN .Gs3_qaBTSSXbq1udtikxmW1IbRw9OfXSg6A8NoS03DBOxt6cOetzMz5WxY3ymTC..MnAYihVYgP 9mr5czRsPA0fKxCtGUS_tCzL1KA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Apr 2020 20:21:13 +0000 Received: by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 02a1188e4b133ad7793821d86db9769e; Fri, 03 Apr 2020 20:21:10 +0000 (UTC) To: Vittorio Bertocci , "Richard Backman, Annabelle" , Vittorio Bertocci , Hannes Tschofenig , oauth , Vittorio Bertocci References: <760BA08D-CB52-440D-9CDB-699BEE306A31@amazon.com> From: George Fletcher Organization: AOL LLC Message-ID: <24a1db50-c31e-051f-3ec6-ebe3cca1cc16@aol.com> Date: Fri, 3 Apr 2020 16:21:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D59CAA69AA4F0F567A42747A" Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 03 Apr 2020 20:21:21 -0000 This is a multi-part message in MIME format. --------------D59CAA69AA4F0F567A42747A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks Vittorio for the thorough response! I agree that how scopes are handled is very different across=20 deployments. Scopes used for an RP with a mobile app (e.g. something=20 like OpenTable) are going to be very different than a multi-tenant=20 enterprise system with fixed services and roles that all tenants much=20 use. I'm not sure it is possible to clearly map this disparate set of=20 deployments into a common set of spec language. It's possible to define=20 a solution that is maybe "majority" but anyone wanting to conform with a = different deployment strategy will just "munge" the 'aud' value to make=20 their deployment work. I'm not sure that adds a lot of value. I think I=20 would prefer a multi-valued 'aud' claim of "mail.example,=20 contacts.example, news.example" over a generic "api.example". The former = provides value to limit the scope of the token where the latter does not.= I agree that scopes were not well specified in 6749/6750 and now it's a=20 bit of the wild west. Some treat scopes as capabilities, some treat them = as roles, some as attributes, some as flags for specific token behavior=20 and the list goes on:) Personally, I'd prefer using RECOMMENDED for the current defined spec=20 language without making that model required. If we truly want interoperable access_tokens cross IDPs, then I think we = have a lot more spec work to do than describing the token format. This=20 is a important and necessary building block, but behaviors and how they=20 map may be outside the scope of this work. Thanks, George On 4/3/20 5:03 AM, Vittorio Bertocci wrote: > Thanks Annabelle and George! I am consolidating replies to both your l= atest comments in this mail. This seems a hard rock to lift, but it also = seems to be the last one =F0=9F=98=8A. > > The TL;DR is, I am not completely opposed to relaxing the constraints a= nd turning them into security considerations, but I think we=E2=80=99d mi= ss an opportunity to make things clearer for developers. At the same time= I wouldn=E2=80=99t want to make this profile too patronizing, hence I ap= preciate the opportunity to discuss. > > > > [Annabelle] > > >. There may be no "scope" parameter. The "scope" parameter is OPTI= ONAL in authorization requests. So an AS/RS operator could decide they're= going to omit "scope" entirely and use multiple resource parameters inst= ead. Since there are no scopes, there is no opportunity for confusion. > > I am a BIG fan of ATs with no scope- all the scenarios where there=E2=80= =99s no delegation (1st parties etc) shouldn=E2=80=99t use scopes at all.= The current language in the profile does allow for scope-less ATs, and g= iven that the goal is to prevent confusion, I agree that there=E2=80=99s = no need to restrict the audience to one single resource if there are no s= copes at all to misinterpret. > > I would be in favor to allow multiple resources in audience in that cas= e. > > Unfortunately it=E2=80=99s not as simple as just saying =E2=80=9CIf the= incoming request incudes multiple resource indicators and no scope, acce= pt it and use the incoming resource indicators list as aud value=E2=80=9D= =E2=80=93 mostly because there is a very large number of production syst= ems where the request includes no scopes and one resource indicator, but = the resulting token includes a collection of scopes the user already cons= ented to for that resource- but I am sure we can get to acceptable langua= ge that expresses the concept =E2=80=9Cif there are multiple resource ind= icators in the request and the rest of the rules in S.3 the resulting AT = won=E2=80=99t contain a scope claim, the resulting AT must use that resou= rce indicators list as aud value=E2=80=9D. > > > >> An AS/RS operator may use "scope" to indicate a role or policy (or set= of policies) that the client wants, and allow the client to narrow their= permissions using "resource" parameters. This would allow the client to = obtain narrowly scoped access tokens for specific use cases without needi= ng to define separate roles/policies for each. In this case, a JWT AT wit= h a multi-valued "aud" claim and a "scope" claim would seem appropriate, = as the scope claim is intended to apply to all of the audience values. > I agree that deployments like the one you describe might exist, in fact= I am sure they do. However it seems really a brittle approach, given tha= t it makes a specific assumption (scopes are valid across all the resourc= es) that isn=E2=80=99t enshrined anywhere and if future updates to that d= eployment violate that assumption, that would lead to the scope confusion= the current language in the profile is trying to prevent. We offer very = little guidance in that respect: the main place were multiple resources a= re even mentioned is resource indicators, and all the samples (I know, no= n-normative) use scopes unambiguously tied to a specific resource (more o= n that later) making the multi-resource scope even more of a special case= =2E > > > > Stepping back a bit - the intent behind those resource-scope restrictio= ns is to provide a bit more guidance on scopes and resources than we did = in the past, and narrowing the range of cases developers would need to ta= ke into account when implementing the profile. > > In my experience the lack of more prescriptive guidance led to deployme= nts and interpretations that, while remaining fully within the boundary o= f what the spec allows, are often questionable from the security and arch= perspective. > > (*)I acknowledge that I might be swinging too far in the opposite direc= tion, and perhaps a similar effect could be achieved by adding an =E2=80=9C= Authorization Considerations=E2=80=9D section where implementers are warn= ed about the danger of scope confusion rather than downright forbidding m= ulti resources audiences when including scopes as well. I still like the = simplicity and clarity of the current restriction, but of course I am ope= n to feedback. > > > >> The mapping between audience and scope may be unambiguous. There are a= lot of deployments to which the blast radius risk you're trying to addre= ss by requiring "aud" simply does not apply > There are certainly cases where scope strings unambiguously map to spec= ific resources, but once again, that=E2=80=99s a strong assumption to mak= e and one I feel cannot be made lightly. Resource indicators use very sim= ple examples (contacts, calendar) that are hard to generalize to scenario= s where the number and lifecycle of resources truly calls for the use of = indicators identifying a resource in a large multitenant system usually e= ntails large identifiers, and stuffing those in the scope to prevent ambi= guity can be expensive from both provisioning and token, request size ang= les. > > > >> It may seem innocuous to require these deployments to explicitly inclu= de a broad audience like "api.example.com" anyway, that can lead to imple= menters ignoring the requirement (leading to interop issues), not validat= ing it (also leading to interop issues or security issues if the deployme= nt wants to start actually using it for real), or doing something funky w= ith it since there isn't anything "real" that the value needs to conform = to. > Every spec guidance risks not being followed. But in this particular ca= se, use of a logical audience is quite mainstream =E2=80=93 we had a simi= lar discussion for resource indicators and that=E2=80=99s why the spec en= ded up including logical identifiers as one of the resource parameter fla= vor. =E2=80=9Creal=E2=80=9D is a relative term, given that there are alre= ady many different ways in which a logical resource might map to differen= t =E2=80=9Cphysical=E2=80=9D artifacts (see heroku=E2=80=99s late binding= URLs). Collective audiences are in common use for poor man=E2=80=99s tru= sted subsystems: not endorsing the approach, but bringing circumstantial = evidence that broad audiences aren=E2=80=99t that uncommon or hard to gro= k for developers already today. Finally, turning off validation is actual= ly not that trivial in many SDKs, given that they mostly reuse/derive fro= m OIDC and the audience check is mandatory: I saw more often people disab= ling iss check than aud. None of this means that the errors you describe = cannot happen: but I think they aren=E2=80=99t more likely than any other= guidance in the spec. > > I do ack the more generic point that, like in the preceding case, this = might suggest that the current guidance is too strict- see (*) > > > > [George] > >> I think one of the problems we have in being super specific about how = the JWT access token is constructed is that is means it's not possible fo= r many organizations to follow. How scopes are implemented is very varied= across deployments which means that some may conform to the perspective = of the spec and many may not. > You are right, the spec is an opinionated take- I agree that many orga= nizations used scopes in very different ways, and I think it is the resul= t of giving very little guidance on scopes and resources, with the conseq= uence that some choices might have been less wise than others. > > With the current guidance I attempted to capture a narrower set of scen= arios where some of the most obvious issues (like scope confusion) can be= averted, while still satisfying most of the cases I observed in the samp= le JWT ATs: I am not trying to overindex on those cases, and I don=E2=80=99= t mean to imply that the profile should strictly follow those, but in the= spirit of eliminating ambiguity as much as possible, this single resourc= e narrowing seemed a solid core to build robust implementations on- fully= aware of the fact that many current implementations would not conform (t= ho I am not sure how many implementations already adopted resource indica= tors or equivalent). > > In any case, see (*)- I think I can be convinced to turn the current re= strictions into security/authorization considerations- but I would reluct= antly do so as I think we=E2=80=99d perpetuate a lot of the ambiguity we = have in this space today. > > > >> Personally, I'm not a big fan of trying to use scopes for fine-grain a= uthorization. I don't think that is what they were intended for when orig= inally designed. (This can be seen by the RAR spec introducing a complete= ly different way of specifying fine-grain authorization context.) Even in= multi-tenant systems, I don't see issues with using sub-resource scopes = as each tenant should define the scopes that make sense for that tenant. = I don't think the AS needs to understand the scopes, just provide a mecha= nism to issue the correct scope under user consent to the client and let = the RS apply the authorization policy when it gets the scopes out of the = token. > I am not crazy about that either- especially given that when fine grain= ed authZ is involved very, very often what developers really want are use= r privileges and scopes are just abused in lieu of privileges simply beca= use the spec doesn=E2=80=99t address the non-delegation scenario hence a = screwdriver ends up being used as a hammer. > > Nonetheless, if scopes are used- mandating that every scope is tied to = the resource does lead to huge tokens and significant management overhead= if you have lots of resources whose identifier must be globally unique, = nonreassignable etc etc hence very large =E2=80=93 and the AS doesn=E2=80= =99t need to understand the semantic of each scope but it does need to kn= ow whether a scope can be requested for a given resource, plus any policy= the admin might want to execute at token issuance time (eg this scope re= quires 2FA) hence juggling large numbers of large strings can be hard for= the AS =E2=80=93 and RS. In any case, the use of multiple resources in t= he aud in the wild appeared to be very rare, hence even if there would be= a foolproof way of defining a resource-scope mapping, I would not spend = cycles defining it here=E2=80=A6 and leaving it as exercise for the reade= r wouldn=E2=80=99t work per the above. As in (*) we could relax the const= raint here and just warn people against scope confusion, but I feel we=E2= =80=99d be missing an opportunity. > > > > ------ > > > > =EF=BB=BFOn 3/24/20, 17:00, "Richard Backman, Annabelle" wrote: > > > > To borrow a term from ML, I think the "aud", "scope", and resource= indicator-related text is overfitted to a specific set of deployment sce= narios, and a specific way of using scopes and resource indicators. > > > > Consider the following: > > > > 1. There may be no "scope" parameter > > The "scope" parameter is OPTIONAL in authorization requests. So an= AS/RS operator could decide they're going to omit "scope" entirely and u= se multiple resource parameters instead. Since there are no scopes, there= is no opportunity for confusion. In this case, a JWT AT with a multi-val= ued "aud" claim and no "scope" claim would seem appropriate. While multip= le resource indicators could be pushed into a single scope string, this i= ntroduces opportunities for serious security impacting encoding/decoding/= parsing bugs. The more I think about it, the more "I don't have to deal w= ith parsing a scope string" seems like a compelling reason to go this rou= te... __ > > > > 2. The scopes may apply to all audiences > > An AS/RS operator may use "scope" to indicate a role or policy (or= set of policies) that the client wants, and allow the client to narrow t= heir permissions using "resource" parameters. This would allow the client= to obtain narrowly scoped access tokens for specific use cases without n= eeding to define separate roles/policies for each. In this case, a JWT AT= with a multi-valued "aud" claim and a "scope" claim would seem appropria= te, as the scope claim is intended to apply to all of the audience values= =2E > > > > 3. The mapping between audience and scope may be unambiguous > > There are a lot of deployments to which the blast radius risk you'= re trying to address by requiring "aud" simply does not apply. It may see= m innocuous to require these deployments to explicitly include a broad au= dience like "api.example.com" anyway, that can lead to implementers ignor= ing the requirement (leading to interop issues), not validating it (also = leading to interop issues or security issues if the deployment wants to s= tart actually using it for real), or doing something funky with it since = there isn't anything "real" that the value needs to conform to. > > > > =E2=80=93 > > Annabelle Backman (she/her) > > AWS Identity > > https://aws.amazon.com/identity/ > > > > > > =EF=BB=BFOn 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocc= i" wrote: > > > > CAUTION: This email originated from outside of the organization. D= o not click links or open attachments unless you can confirm the sender a= nd know the content is safe. > > > > > > > > Thanks George for the super thorough review and feedback! > > Inline > > > > > Section 1. Introduction > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD second= line: scenario should be plural --> scenarios > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD second= sentence: "are not ran by" --> "are not run by" > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD cofidentiality --> confid= entiality > > Fixed. Thanks! > > > > > Section 2.2.1 Authentication Information Claims > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I'm no= t sure that this definition of `auth_time` allows for the > > case where a user is required to solve an additional challenge= =2E > > If the challenge entails going back to the AS, then I believe the = language (in the initial paragraph of 2.2.1 and in auth_time itself) acc= ommodates for that and does require the auth_time to be updated. > > If you hit the AS and present an authentication factor (such as yo= ur challenge) and obtain a new token in the process, the auth_time will r= eflect the time of your latest authentication just like an id_token would= in the same circumstances (think protected route in a web app requiring = step up auth) and (likely) associated session artifacts (think RTs or coo= kies with sliding expiration, the challenge would count as activity and m= ove the expiration). > > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I thi= nk there is a difference between session_start_time and last > > auth_time. This feels more like it's defining the session_star= t_time > > concept. > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD These same issues can ap= ply to the `acr` and `amr` values as well. > > Per the above, the intent is more to express the last time the use= r performed any authentication action rather than the start time. The int= ent is to provide information as current as possible, as it might be rele= vant to the RS decisions whereas the history before current conditions mi= ght not be consequential. > > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Even if for this second= ary challenge a new refresh_token is issued, > > it is unlikely many relying parties will want to treat that as= issuing a > > new session. The goal is to keep the user logged in to a singl= e session. > > Could you expand on the practical implications of the above? The i= ntent isn't as much to reflect session identifying information per se, bu= t to provide the RS with the most up to date information about the circum= stances in which the current AT was obtained. The fact that a session was= initially established using acr level 0 doesn=E2=80=99t really matter if= the AT I am receiving now has been obtained after a stepup that brought = acr to 1, if my RS cares auth authentication levels my authorization deci= sion shouldn't be influenced by whether somewhere the session artifact di= dn=E2=80=99t change its sessionID after the stepup. Same for acr, auth_ti= me > > > > > Section 2.2.3 Authorization Claims > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I find the statement "Al= l the individual scope strings in the scope > > claim MUST have meaning for the resource indicated in the aud = claim" > > somewhat problematic. In many deployments today for 1st party = clients to > > the authorization server and taking into account mobile applic= ations, > > the access token most like contains scopes for many of the 1st= party > > backend APIs. It's possible to get around this by setting the = 'aud' > > claim to something like "com.example.apis" and hence all the i= ssued > > scopes map to that audience claim but that is just working aro= und the > > MUST in the spec. Given the lack of specificity of the 'aud' c= laim and > > the 'resource indicator' claim for that matter, pretty much any= thing can > > be made to comply. In that context, it seems like RECOMMEND is= a better > > normative clause. > > For 1st party solutions, I would argue that delegation might not b= e the right primitive hence I wouldn't necessarily use scopes to express = permissions; but that's a rabbit hole I'll try to avoid for the time bein= g __ > > For the aud, I think that what you characterized as workaround wou= ld actually be by design. The aud defines the applicability of the curren= t token, so that in case of leakage the blast radius of the incident can = be contained. If the solution designed decides that this particular token= should be reusable across multiple assets, I think it makes sense for th= e aud to reflect that explicitly. That's the system designing volunteerin= g a scope xpansion of the scope, and given that it has security implicati= ons I think it's good to require it to be an explicit, opt in action. At = the same time, given that scopes are often used to define permissions, I = believe it makes sense to find mechanisms to minimize the chance that RSe= s would misinterpret the applicability of a scope (see discussion with Ta= kahiko/Nikos). Summing all the above, I'd be inclined to keep the MUST. > > > > > Section 3. Requesting a JWT Access Token > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Per my comments above I = suspect that requiring all JWT access tokens > > to include an audience claim will just devolve to audience cla= ims that > > are somewhat pointless (in order to meet this MUST in the spec= ). Given > > the mobile app environment today, it is unreasonable to ask th= e mobile > > apps to downscope every access token before making an API call= to the > > backend APIs which is what the spirit of audience and resource= > > indicators seem to imply. > > Partly addressed in the preceding point, but this is a great oppor= tunity to clarify the intent further. The mobile client isn't required to= downscope; rather, the fact that a token cab be applied to a broad range= of API should be clearly identified and expressed by the logical audienc= e. The system designer can even choose to have a single token that can be= used to call any API, containing every scope for every API; the profile = only asks for this choice to be manifest, by choosing an appropriate audi= ence identifier and acknowledging that all the scopes in the token are ap= plicable to the same logical resource (that is, the aggregate of all the = APIs). > > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Why MUST the AS rejec= t a request with more than one resource > > parameter? If a request comes in with no resource parameter an= d multiple > > scopes the AS is not required to reject that request. Is there= much of a > > semantic difference between the two? In the case of no resourc= e > > parameter and multiple scopes the AS might issue an access tok= en with > > multiple audience values (as is allowed by RFC 7519). > > This is another consequence of making extra clear what the token r= efers to, and what the intended semantic of the scopes is. The idea is th= at the token is always restricted to ONE specific audience. The profile a= llows for different mechanisms for the AS to determine what value the aud= ience should be, including via inference from scopes, but coherently with= the scope confusion prevention principle, if that inference cannot lead = to a single resource identifier in the audience, the request should be re= jected. > > The intent is really to be as simple as unambiguous as possible, a= nd capture what most mainstream providers already do in JWT ATs. If a RS = has more sophisticated requirements, they can always decide to do more an= d not follow the interop profile. Defining more complex rules to prevent = scope/resource association confusion simply doesn=E2=80=99t seem to be ju= stified by the frequency of the scenario in the wild. > > > > > > > Also, the audience > > claim is not solely for resource indicator values but is defin= ed to just > > be a string. To me it feels like the text is implying that the= only > > valid audience value is also a resource indicator (which from = previous > > discussions on the list it was implied they have a slightly di= fferent > > semantic). > > Section 3 of the profile does define aud as a resource indicator, = enumerating an exhaustive list of possible requests that all end in a res= ource indicator as aud, or an error. Did I miss some cases? I don=E2=80=99= t recall specifics about aud values in this profile having other possible= values, sorry for having missed that. Do you have a snippet referring to= those discussions? Thx > > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD The model described he= re works well if myco.example really only > > provides a single service. But if instead myco.example provide= s multiple > > services each with their own endpoints (srva.myco.example, > > srvb.myco.example) and scopes, for me this model begins to bre= ak down. > > Either mobile apps are required to downscope all tokens to jus= t the > > service they are calling at that point in time (which can have= latency > > and connectivity issues), or myco.example has to create a gene= ric > > "audience" string that represents all of example.com which doe= sn't seem > > to be the spirit of the existing specs. > > I think that the granularity of the calls is fully within the cont= rol of the designer. If srva.myco.example and srvb.myco.example share ana= logous characteristics (same policies, lifecycle, resource ownership, etc= ) them it's perfectly valid to assign a logical myco.example audience enc= ompassing them all, regardless of deployment model. If there are differen= ces in terms of policies, auth strength requirements, lifecycle, risk and= impact of a leak, or any other boundary, then the audience requirement w= ill guarantee that those differences are reflected in tokens requested an= d cached, in the way in which access is partitioned, and so on and so for= th. If there are security requirements such as the ones enumerated, the l= atency and connectivity issues aren=E2=80=99t a blocking factor; and if t= here aren't, nothing prevents you from having a logical audience value. F= rom the expressive power point of view, the requirement of having a singl= e audience doens't prevent you from doing any of the single token logic y= ou are hinting at- especially if you plan to use specialized scopes anywa= y. > > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD In summary, I feel tha= t this text is binding too tightly resource > > indicators to the audience claim. What is described is perfect= ly > > reasonable in a use case that is applying resource indicators = in this > > way but is not indicative of the widely deployed models that a= lready exist. > > We might have different experiences here. The JWT access tokens fr= om popular products I studied in the research I presented in Stuttgart we= re almost all using the aud claim in this way. I am sure that there are o= ther models, and there was at least one exception, but in interop terms t= his seems to be the most common way of using JWT for ATs- and it has the = advantage of being very simple and unambiguous. > > > > > Section 4. Validating JWT Access Tokens > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Step 4. -- Can we change= the wording to not require resource > > indicators? What about... "The resource server MUST validate t= hat the > > 'aud' claim contains a string that represents the audience of = this > > resource server." > > Could you make an example in which you'd want to use an identifier= that is not a resource indicator? Given that we have the spec, and "audi= ence of the resource server" seems to be the exact semantic of resource i= ndicators, it seemed a slam dunk to use it here... > > > > > Section 5. "cross-JWT confusion" > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I think there may be con= fusion around what is meant by "distinct > > resources". In my example above, are srva.myco.example and > > srvb.myco.example "distinct resources"? or is the goal here to= say that > > we want different audience values generated for cross-organiza= tion > > resources. For example, are mail.google.com and youtube.com "d= istinct > > resources"? or would an audience for google suffice in meeting= the > > meaning of this paragraph? > > I think the key point here is - we don=E2=80=99t know. I agree the= language isn't clear there. Let me expand on the intent, and perhaps we = can get to a better formulation. > > OAuth2 doesn=E2=80=99t demand that RS and AS are run by the same e= ntity, but that's the most common scenario. FB doesn't need to specify a = resource, because the resource is implicit.. it's the FB graph, you can=E2= =80=99t get a token for anything else. The only differentiator ends up be= ing the scopes. Same for many other providers, google, Microsoft for its = own Graph, etc. > > However many AS as a service don=E2=80=99t have the benefit of a d= efault, implicit resource, especially in multi tenancy scenarios, given t= hat they'll need to issue tokens for a number of different recipients. Wh= ether resources are cross organization, or cross department, or following= any other arbitrary segregation/factoring model is something we cannot i= nfer- it's up to the developer to determine that. What I am trying to exp= ress here is that the operator of the AS as a service (or any other form = of "AS for rent") should surface resources as a primitive for modeling an= d identifying intended recipients of ATs. Does tis help? How would you ex= press that? > > > > > =C3=AF=C2=BF=C2=BD I'm having the same confusion in the nex= t paragraph regarding the > > phrase "different resources". Are services provided by the sam= e company > > "different resources" or are they all considered the same reso= urce. Can > > an access token be issued with scopes for both mail.google.com= and > > youtube.com? And if not, why note? Preventing this puts undue = burden on > > mobile based applications. > > See preceding point. We can't enter in the merit of what constitut= es a resource, as that depends on the modeling of the domain specific pro= blem the developer is tackling. The highest order bit is that if two enti= ties (API, etc.. intended token recipients) have different security chara= cteristics (e.g. leaking a token for one has different consequences than = if you'd leak a token for the other), they should be modeled as different= resources. And if they are different resources, we should do what we can= to avoid confusion in how we express access grants to them (hence the bi= g discussion on multiresource, scope confusion, etc). > > > > > > --------- > > On 3/24/20, 10:39, "George Fletcher" wrote: > > > > Feedback on the spec... > > > > Section 1. Introduction > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD second= line: scenario should be plural --> scenarios > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD second= sentence: "are not ran by" --> "are not run by" > > > > Section 2.2.1 Authentication Information Claims > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I'm no= t sure that this definition of `auth_time` allows for the > > case where a user is required to solve an additional challenge= =2E Take the > > case of a user who is required to pass a secondary challenge b= efore the > > "stock purchase" action can be completed. According to the cur= rent spec > > definition, the `auth_time` value MUST NOT be updated when thi= s > > secondary challenge is completed. > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I thin= k there is a difference between session_start_time and last > > auth_time. This feels more like it's defining the session_star= t_time > > concept. > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD These same issues can ap= ply to the `acr` and `amr` values as well. > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Even if for this seconda= ry challenge a new refresh_token is issued, > > it is unlikely many relying parties will want to treat that as= issuing a > > new session. The goal is to keep the user logged in to a singl= e session. > > > > Section 2.2.3 Authorization Claims > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I find the statement "Al= l the individual scope strings in the scope > > claim MUST have meaning for the resource indicated in the aud = claim" > > somewhat problematic. In many deployments today for 1st party = clients to > > the authorization server and taking into account mobile applic= ations, > > the access token most like contains scopes for many of the 1st= party > > backend APIs. It's possible to get around this by setting the = 'aud' > > claim to something like "com.example.apis" and hence all the i= ssued > > scopes map to that audience claim but that is just working aro= und the > > MUST in the spec. Given the lack of specificity of the 'aud' c= laim and > > the 'resource indicator' claim for that matter, pretty much an= ything can > > be made to comply. In that context, it seems like RECOMMEND is= a better > > normative clause. > > > > Section 3. Requesting a JWT Access Token > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Per my comments above I = suspect that requiring all JWT access tokens > > to include an audience claim will just devolve to audience cla= ims that > > are somewhat pointless (in order to meet this MUST in the spec= ). Given > > the mobile app environment today, it is unreasonable to ask th= e mobile > > apps to downscope every access token before making an API call= to the > > backend APIs which is what the spirit of audience and resource= > > indicators seem to imply. > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Why MUST the AS reject a= request with more than one resource > > parameter? If a request comes in with no resource parameter an= d multiple > > scopes the AS is not required to reject that request. Is there= much of a > > semantic difference between the two? In the case of no resourc= e > > parameter and multiple scopes the AS might issue an access tok= en with > > multiple audience values (as is allowed by RFC 7519). Also, th= e audience > > claim is not solely for resource indicator values but is defin= ed to just > > be a string. To me it feels like the text is implying that the= only > > valid audience value is also a resource indicator (which from = previous > > discussions on the list it was implied they have a slightly di= fferent > > semantic). > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD The model described here= works well if myco.example really only > > provides a single service. But if instead myco.example provide= s multiple > > services each with their own endpoints (srva.myco.example, > > srvb.myco.example) and scopes, for me this model begins to bre= ak down. > > Either mobile apps are required to downscope all tokens to jus= t the > > service they are calling at that point in time (which can have= latency > > and connectivity issues), or myco.example has to create a gene= ric > > "audience" string that represents all of example.com which doe= sn't seem > > to be the spirit of the existing specs. > > > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD In summary, I feel that = this text is binding too tightly resource > > indicators to the audience claim. What is described is perfect= ly > > reasonable in a use case that is applying resource indicators = in this > > way but is not indicative of the widely deployed models that a= lready exist. > > > > Section 4. Validating JWT Access Tokens > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD Step 4. -- Can we change= the wording to not require resource > > indicators? What about... "The resource server MUST validate t= hat the > > 'aud' claim contains a string that represents the audience of = this > > resource server." > > > > Section 5. "cross-JWT confusion" > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD I think there may be con= fusion around what is meant by "distinct > > resources". In my example above, are srva.myco.example and > > srvb.myco.example "distinct resources"? or is the goal here to= say that > > we want different audience values generated for cross-organiza= tion > > resources. For example, are mail.google.com and youtube.com "d= istinct > > resources"? or would an audience for google suffice in meeting= the > > meaning of this paragraph? > > > > =C3=AF=C2=BF=C2=BD I'm having the same confusion in the next = paragraph regarding the > > phrase "different resources". Are services provided by the sam= e company > > "different resources" or are they all considered the same reso= urce. Can > > an access token be issued with scopes for both mail.google.com= and > > youtube.com? And if not, why note? Preventing this puts undue = burden on > > mobile based applications. > > > > Section 6. Privacy > > =C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD cofidentiality --> confi= dentiality > > > > > > Thanks, > > George > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > --------------D59CAA69AA4F0F567A42747A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5Pgog ICAgPGZvbnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiI+VGhhbmtzIFZp dHRvcmlvIGZvciB0aGUKICAgICAgdGhvcm91Z2ggcmVzcG9uc2UhPGJyPgogICAgICA8YnI+ CiAgICAgIEkgYWdyZWUgdGhhdCBob3cgc2NvcGVzIGFyZSBoYW5kbGVkIGlzIHZlcnkgZGlm ZmVyZW50IGFjcm9zcwogICAgICBkZXBsb3ltZW50cy4gU2NvcGVzIHVzZWQgZm9yIGFuIFJQ IHdpdGggYSBtb2JpbGUgYXBwIChlLmcuCiAgICAgIHNvbWV0aGluZyBsaWtlIE9wZW5UYWJs ZSkgYXJlIGdvaW5nIHRvIGJlIHZlcnkgZGlmZmVyZW50IHRoYW4gYQogICAgICBtdWx0aS10 ZW5hbnQgZW50ZXJwcmlzZSBzeXN0ZW0gd2l0aCBmaXhlZCBzZXJ2aWNlcyBhbmQgcm9sZXMg dGhhdAogICAgICBhbGwgdGVuYW50cyBtdWNoIHVzZS4gSSdtIG5vdCBzdXJlIGl0IGlzIHBv c3NpYmxlIHRvIGNsZWFybHkgbWFwCiAgICAgIHRoaXMgZGlzcGFyYXRlIHNldCBvZiBkZXBs b3ltZW50cyBpbnRvIGEgY29tbW9uIHNldCBvZiBzcGVjCiAgICAgIGxhbmd1YWdlLiBJdCdz IHBvc3NpYmxlIHRvIGRlZmluZSBhIHNvbHV0aW9uIHRoYXQgaXMgbWF5YmUKICAgICAgIm1h am9yaXR5IiBidXQgYW55b25lIHdhbnRpbmcgdG8gY29uZm9ybSB3aXRoIGEgZGlmZmVyZW50 CiAgICAgIGRlcGxveW1lbnQgc3RyYXRlZ3kgd2lsbCBqdXN0ICJtdW5nZSIgdGhlICdhdWQn IHZhbHVlIHRvIG1ha2UKICAgICAgdGhlaXIgZGVwbG95bWVudCB3b3JrLiBJJ20gbm90IHN1 cmUgdGhhdCBhZGRzIGEgbG90IG9mIHZhbHVlLiBJCiAgICAgIHRoaW5rIEkgd291bGQgcHJl ZmVyIGEgbXVsdGktdmFsdWVkICdhdWQnIGNsYWltIG9mICJtYWlsLmV4YW1wbGUsCiAgICAg IGNvbnRhY3RzLmV4YW1wbGUsIG5ld3MuZXhhbXBsZSIgb3ZlciBhIGdlbmVyaWMgImFwaS5l eGFtcGxlIi4gVGhlCiAgICAgIGZvcm1lciBwcm92aWRlcyB2YWx1ZSB0byBsaW1pdCB0aGUg c2NvcGUgb2YgdGhlIHRva2VuIHdoZXJlIHRoZQogICAgICBsYXR0ZXIgZG9lcyBub3QuPGJy PgogICAgICA8YnI+CiAgICAgIEkgYWdyZWUgdGhhdCBzY29wZXMgd2VyZSBub3Qgd2VsbCBz cGVjaWZpZWQgaW4gNjc0OS82NzUwIGFuZCBub3cKICAgICAgaXQncyBhIGJpdCBvZiB0aGUg d2lsZCB3ZXN0LiBTb21lIHRyZWF0IHNjb3BlcyBhcyBjYXBhYmlsaXRpZXMsCiAgICAgIHNv bWUgdHJlYXQgdGhlbSBhcyByb2xlcywgc29tZSBhcyBhdHRyaWJ1dGVzLCBzb21lIGFzIGZs YWdzIGZvcgogICAgICBzcGVjaWZpYyB0b2tlbiBiZWhhdmlvciBhbmQgdGhlIGxpc3QgZ29l cyBvbjopPGJyPgogICAgICA8YnI+CiAgICAgIFBlcnNvbmFsbHksIEknZCBwcmVmZXIgdXNp bmcgUkVDT01NRU5ERUQgZm9yIHRoZSBjdXJyZW50IGRlZmluZWQKICAgICAgc3BlYyBsYW5n dWFnZSB3aXRob3V0IG1ha2luZyB0aGF0IG1vZGVsIHJlcXVpcmVkLjxicj4KICAgICAgPGJy PgogICAgICBJZiB3ZSB0cnVseSB3YW50IGludGVyb3BlcmFibGUgYWNjZXNzX3Rva2VucyBj cm9zcyBJRFBzLCB0aGVuIEkKICAgICAgdGhpbmsgd2UgaGF2ZSBhIGxvdCBtb3JlIHNwZWMg d29yayB0byBkbyB0aGFuIGRlc2NyaWJpbmcgdGhlIHRva2VuCiAgICAgIGZvcm1hdC4gVGhp cyBpcyBhIGltcG9ydGFudCBhbmQgbmVjZXNzYXJ5IGJ1aWxkaW5nIGJsb2NrLCBidXQKICAg ICAgYmVoYXZpb3JzIGFuZCBob3cgdGhleSBtYXAgbWF5IGJlIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgd29yay48YnI+CiAgICAgIDxicj4KICAgICAgVGhhbmtzLDxicj4KICAgICAg R2VvcmdlPGJyPgogICAgPC9mb250Pjxicj4KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+T24gNC8zLzIwIDU6MDMgQU0sIFZpdHRvcmlvIEJlcnRvY2NpCiAgICAgIHdyb3Rl Ojxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKY2l0ZT0ibWlk Ok1XSFBSMTlNQjE1MDFBQ0M4MTM5NEE4RDhCMTkwNTBGMUFFQzcwQE1XSFBSMTlNQjE1MDEu bmFtcHJkMTkucHJvZC5vdXRsb29rLmNvbSI+CiAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90 ZS1wcmUiIHdyYXA9IiI+VGhhbmtzIEFubmFiZWxsZSBhbmQgR2VvcmdlISAgSSBhbSBjb25z b2xpZGF0aW5nIHJlcGxpZXMgdG8gYm90aCB5b3VyIGxhdGVzdCBjb21tZW50cyBpbiB0aGlz IG1haWwuIFRoaXMgc2VlbXMgYSBoYXJkIHJvY2sgdG8gbGlmdCwgYnV0IGl0IGFsc28gc2Vl bXMgdG8gYmUgdGhlIGxhc3Qgb25lIPCfmIouCgpUaGUgVEw7RFIgaXMsIEkgYW0gbm90IGNv bXBsZXRlbHkgb3Bwb3NlZCB0byByZWxheGluZyB0aGUgY29uc3RyYWludHMgYW5kIHR1cm5p bmcgdGhlbSBpbnRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBidXQgSSB0aGluayB3ZeKA mWQgbWlzcyBhbiBvcHBvcnR1bml0eSB0byBtYWtlIHRoaW5ncyBjbGVhcmVyIGZvciBkZXZl bG9wZXJzLiBBdCB0aGUgc2FtZSB0aW1lIEkgd291bGRu4oCZdCB3YW50IHRvIG1ha2UgdGhp cyBwcm9maWxlIHRvbyBwYXRyb25pemluZywgaGVuY2UgSSBhcHByZWNpYXRlIHRoZSBvcHBv cnR1bml0eSB0byBkaXNjdXNzLgoKCgpbQW5uYWJlbGxlXQoKICAmZ3Q7LiBUaGVyZSBtYXkg YmUgbm8gInNjb3BlIiBwYXJhbWV0ZXIuICBUaGUgInNjb3BlIiBwYXJhbWV0ZXIgaXMgT1BU SU9OQUwgaW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0cy4gU28gYW4gQVMvUlMgb3BlcmF0b3Ig Y291bGQgZGVjaWRlIHRoZXkncmUgZ29pbmcgdG8gb21pdCAic2NvcGUiIGVudGlyZWx5IGFu ZCB1c2UgbXVsdGlwbGUgcmVzb3VyY2UgcGFyYW1ldGVycyBpbnN0ZWFkLiBTaW5jZSB0aGVy ZSBhcmUgbm8gc2NvcGVzLCB0aGVyZSBpcyBubyBvcHBvcnR1bml0eSBmb3IgY29uZnVzaW9u LgoKSSBhbSBhIEJJRyBmYW4gb2YgQVRzIHdpdGggbm8gc2NvcGUtIGFsbCB0aGUgc2NlbmFy aW9zIHdoZXJlIHRoZXJl4oCZcyBubyBkZWxlZ2F0aW9uICgxc3QgcGFydGllcyBldGMpIHNo b3VsZG7igJl0IHVzZSBzY29wZXMgYXQgYWxsLiBUaGUgY3VycmVudCBsYW5ndWFnZSBpbiB0 aGUgcHJvZmlsZSBkb2VzIGFsbG93IGZvciBzY29wZS1sZXNzIEFUcywgYW5kIGdpdmVuIHRo YXQgdGhlIGdvYWwgaXMgdG8gcHJldmVudCBjb25mdXNpb24sIEkgYWdyZWUgdGhhdCB0aGVy ZeKAmXMgbm8gbmVlZCB0byByZXN0cmljdCB0aGUgYXVkaWVuY2UgdG8gb25lIHNpbmdsZSBy ZXNvdXJjZSBpZiB0aGVyZSBhcmUgbm8gc2NvcGVzIGF0IGFsbCB0byBtaXNpbnRlcnByZXQu CgpJIHdvdWxkIGJlIGluIGZhdm9yIHRvIGFsbG93IG11bHRpcGxlIHJlc291cmNlcyBpbiBh dWRpZW5jZSBpbiB0aGF0IGNhc2UuCgpVbmZvcnR1bmF0ZWx5IGl04oCZcyBub3QgYXMgc2lt cGxlIGFzIGp1c3Qgc2F5aW5nIOKAnElmIHRoZSBpbmNvbWluZyByZXF1ZXN0IGluY3VkZXMg bXVsdGlwbGUgcmVzb3VyY2UgaW5kaWNhdG9ycyBhbmQgbm8gc2NvcGUsIGFjY2VwdCBpdCBh bmQgdXNlIHRoZSBpbmNvbWluZyByZXNvdXJjZSBpbmRpY2F0b3JzIGxpc3QgYXMgYXVkIHZh bHVl4oCdIOKAkyBtb3N0bHkgYmVjYXVzZSB0aGVyZSBpcyBhIHZlcnkgbGFyZ2UgbnVtYmVy IG9mIHByb2R1Y3Rpb24gc3lzdGVtcyB3aGVyZSB0aGUgcmVxdWVzdCBpbmNsdWRlcyBubyBz Y29wZXMgYW5kIG9uZSByZXNvdXJjZSBpbmRpY2F0b3IsIGJ1dCB0aGUgcmVzdWx0aW5nIHRv a2VuIGluY2x1ZGVzIGEgY29sbGVjdGlvbiBvZiBzY29wZXMgdGhlIHVzZXIgYWxyZWFkeSBj b25zZW50ZWQgdG8gZm9yIHRoYXQgcmVzb3VyY2UtIGJ1dCBJIGFtIHN1cmUgd2UgY2FuIGdl dCB0byBhY2NlcHRhYmxlIGxhbmd1YWdlIHRoYXQgZXhwcmVzc2VzIHRoZSBjb25jZXB0IOKA nGlmIHRoZXJlIGFyZSBtdWx0aXBsZSByZXNvdXJjZSBpbmRpY2F0b3JzIGluIHRoZSByZXF1 ZXN0IGFuZCB0aGUgcmVzdCBvZiB0aGUgcnVsZXMgaW4gUy4zIHRoZSByZXN1bHRpbmcgQVQg d29u4oCZdCBjb250YWluIGEgc2NvcGUgY2xhaW0sIHRoZSByZXN1bHRpbmcgQVQgbXVzdCB1 c2UgdGhhdCByZXNvdXJjZSBpbmRpY2F0b3JzIGxpc3QgYXMgYXVkIHZhbHVl4oCdLgoKCgo8 L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgICAgPHByZSBjbGFz cz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5BbiBBUy9SUyBvcGVyYXRvciBtYXkgdXNlICJz Y29wZSIgdG8gaW5kaWNhdGUgYSByb2xlIG9yIHBvbGljeSAob3Igc2V0IG9mIHBvbGljaWVz KSB0aGF0IHRoZSBjbGllbnQgd2FudHMsIGFuZCBhbGxvdyB0aGUgY2xpZW50IHRvIG5hcnJv dyB0aGVpciBwZXJtaXNzaW9ucyB1c2luZyAicmVzb3VyY2UiIHBhcmFtZXRlcnMuIFRoaXMg d291bGQgYWxsb3cgdGhlIGNsaWVudCB0byBvYnRhaW4gbmFycm93bHkgc2NvcGVkIGFjY2Vz cyB0b2tlbnMgZm9yIHNwZWNpZmljIHVzZSBjYXNlcyB3aXRob3V0IG5lZWRpbmcgdG8gZGVm aW5lIHNlcGFyYXRlIHJvbGVzL3BvbGljaWVzIGZvciBlYWNoLiBJbiB0aGlzIGNhc2UsIGEg SldUIEFUIHdpdGggYSBtdWx0aS12YWx1ZWQgImF1ZCIgY2xhaW0gYW5kIGEgInNjb3BlIiBj bGFpbSB3b3VsZCBzZWVtIGFwcHJvcHJpYXRlLCBhcyB0aGUgc2NvcGUgY2xhaW0gaXMgaW50 ZW5kZWQgdG8gYXBwbHkgdG8gYWxsIG9mIHRoZSBhdWRpZW5jZSB2YWx1ZXMuCjwvcHJlPgog ICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdy YXA9IiI+CkkgYWdyZWUgdGhhdCBkZXBsb3ltZW50cyBsaWtlIHRoZSBvbmUgeW91IGRlc2Ny aWJlIG1pZ2h0IGV4aXN0LCBpbiBmYWN0IEkgYW0gc3VyZSB0aGV5IGRvLiBIb3dldmVyIGl0 IHNlZW1zIHJlYWxseSBhIGJyaXR0bGUgYXBwcm9hY2gsIGdpdmVuIHRoYXQgaXQgbWFrZXMg YSBzcGVjaWZpYyBhc3N1bXB0aW9uIChzY29wZXMgYXJlIHZhbGlkIGFjcm9zcyBhbGwgdGhl IHJlc291cmNlcykgdGhhdCBpc27igJl0IGVuc2hyaW5lZCBhbnl3aGVyZSBhbmQgaWYgZnV0 dXJlIHVwZGF0ZXMgdG8gdGhhdCBkZXBsb3ltZW50IHZpb2xhdGUgdGhhdCBhc3N1bXB0aW9u LCB0aGF0IHdvdWxkIGxlYWQgdG8gdGhlIHNjb3BlIGNvbmZ1c2lvbiB0aGUgY3VycmVudCBs YW5ndWFnZSBpbiB0aGUgcHJvZmlsZSBpcyB0cnlpbmcgdG8gcHJldmVudC4gV2Ugb2ZmZXIg dmVyeSBsaXR0bGUgZ3VpZGFuY2UgaW4gdGhhdCByZXNwZWN0OiB0aGUgbWFpbiBwbGFjZSB3 ZXJlIG11bHRpcGxlIHJlc291cmNlcyBhcmUgZXZlbiBtZW50aW9uZWQgaXMgcmVzb3VyY2Ug aW5kaWNhdG9ycywgYW5kIGFsbCB0aGUgc2FtcGxlcyAoSSBrbm93LCBub24tbm9ybWF0aXZl KSB1c2Ugc2NvcGVzIHVuYW1iaWd1b3VzbHkgdGllZCB0byBhIHNwZWNpZmljIHJlc291cmNl IChtb3JlIG9uIHRoYXQgbGF0ZXIpIG1ha2luZyB0aGUgbXVsdGktcmVzb3VyY2Ugc2NvcGUg ZXZlbiBtb3JlIG9mIGEgc3BlY2lhbCBjYXNlLgoKCgpTdGVwcGluZyBiYWNrIGEgYml0IC0g dGhlIGludGVudCBiZWhpbmQgdGhvc2UgcmVzb3VyY2Utc2NvcGUgcmVzdHJpY3Rpb25zIGlz IHRvIHByb3ZpZGUgYSBiaXQgbW9yZSBndWlkYW5jZSBvbiBzY29wZXMgYW5kIHJlc291cmNl cyB0aGFuIHdlIGRpZCBpbiB0aGUgcGFzdCwgYW5kIG5hcnJvd2luZyB0aGUgcmFuZ2Ugb2Yg Y2FzZXMgZGV2ZWxvcGVycyB3b3VsZCBuZWVkIHRvIHRha2UgaW50byBhY2NvdW50IHdoZW4g aW1wbGVtZW50aW5nIHRoZSBwcm9maWxlLgoKSW4gbXkgZXhwZXJpZW5jZSB0aGUgbGFjayBv ZiBtb3JlIHByZXNjcmlwdGl2ZSBndWlkYW5jZSBsZWQgdG8gZGVwbG95bWVudHMgYW5kIGlu dGVycHJldGF0aW9ucyB0aGF0LCB3aGlsZSByZW1haW5pbmcgZnVsbHkgd2l0aGluIHRoZSBi b3VuZGFyeSBvZiB3aGF0IHRoZSBzcGVjIGFsbG93cywgYXJlIG9mdGVuIHF1ZXN0aW9uYWJs ZSBmcm9tIHRoZSBzZWN1cml0eSBhbmQgYXJjaCBwZXJzcGVjdGl2ZS4KCigqKUkgYWNrbm93 bGVkZ2UgdGhhdCBJIG1pZ2h0IGJlIHN3aW5naW5nIHRvbyBmYXIgaW4gdGhlIG9wcG9zaXRl IGRpcmVjdGlvbiwgYW5kIHBlcmhhcHMgYSBzaW1pbGFyIGVmZmVjdCBjb3VsZCBiZSBhY2hp ZXZlZCBieSBhZGRpbmcgYW4g4oCcQXV0aG9yaXphdGlvbiBDb25zaWRlcmF0aW9uc+KAnSBz ZWN0aW9uIHdoZXJlIGltcGxlbWVudGVycyBhcmUgd2FybmVkIGFib3V0IHRoZSBkYW5nZXIg b2Ygc2NvcGUgY29uZnVzaW9uIHJhdGhlciB0aGFuIGRvd25yaWdodCBmb3JiaWRkaW5nIG11 bHRpIHJlc291cmNlcyBhdWRpZW5jZXMgd2hlbiBpbmNsdWRpbmcgc2NvcGVzIGFzIHdlbGwu IEkgc3RpbGwgbGlrZSB0aGUgc2ltcGxpY2l0eSBhbmQgY2xhcml0eSBvZiB0aGUgY3VycmVu dCByZXN0cmljdGlvbiwgYnV0IG9mIGNvdXJzZSBJIGFtIG9wZW4gdG8gZmVlZGJhY2suCgoK CjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJlIGNs YXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPlRoZSBtYXBwaW5nIGJldHdlZW4gYXVkaWVu Y2UgYW5kIHNjb3BlIG1heSBiZSB1bmFtYmlndW91cy4gVGhlcmUgYXJlIGEgbG90IG9mIGRl cGxveW1lbnRzIHRvIHdoaWNoIHRoZSBibGFzdCByYWRpdXMgcmlzayB5b3UncmUgdHJ5aW5n IHRvIGFkZHJlc3MgYnkgcmVxdWlyaW5nICJhdWQiIHNpbXBseSBkb2VzIG5vdCBhcHBseQo8 L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgogICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUt cHJlIiB3cmFwPSIiPgpUaGVyZSBhcmUgY2VydGFpbmx5IGNhc2VzIHdoZXJlIHNjb3BlIHN0 cmluZ3MgdW5hbWJpZ3VvdXNseSBtYXAgdG8gc3BlY2lmaWMgcmVzb3VyY2VzLCBidXQgb25j ZSBhZ2FpbiwgdGhhdOKAmXMgYSBzdHJvbmcgYXNzdW1wdGlvbiB0byBtYWtlIGFuZCBvbmUg SSBmZWVsIGNhbm5vdCBiZSBtYWRlIGxpZ2h0bHkuIFJlc291cmNlIGluZGljYXRvcnMgdXNl IHZlcnkgc2ltcGxlIGV4YW1wbGVzIChjb250YWN0cywgY2FsZW5kYXIpIHRoYXQgYXJlIGhh cmQgdG8gZ2VuZXJhbGl6ZSB0byBzY2VuYXJpb3Mgd2hlcmUgdGhlIG51bWJlciBhbmQgbGlm ZWN5Y2xlIG9mIHJlc291cmNlcyB0cnVseSBjYWxscyBmb3IgdGhlIHVzZSBvZiBpbmRpY2F0 b3JzIGlkZW50aWZ5aW5nIGEgcmVzb3VyY2UgaW4gYSBsYXJnZSBtdWx0aXRlbmFudCBzeXN0 ZW0gdXN1YWxseSBlbnRhaWxzIGxhcmdlIGlkZW50aWZpZXJzLCBhbmQgc3R1ZmZpbmcgdGhv c2UgaW4gdGhlIHNjb3BlIHRvIHByZXZlbnQgYW1iaWd1aXR5IGNhbiBiZSBleHBlbnNpdmUg ZnJvbSBib3RoIHByb3Zpc2lvbmluZyBhbmQgdG9rZW4sIHJlcXVlc3Qgc2l6ZSBhbmdsZXMu CgoKCjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJl IGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkl0IG1heSBzZWVtIGlubm9jdW91cyB0 byByZXF1aXJlIHRoZXNlIGRlcGxveW1lbnRzIHRvIGV4cGxpY2l0bHkgaW5jbHVkZSBhIGJy b2FkIGF1ZGllbmNlIGxpa2UgImFwaS5leGFtcGxlLmNvbSIgYW55d2F5LCB0aGF0IGNhbiBs ZWFkIHRvIGltcGxlbWVudGVycyBpZ25vcmluZyB0aGUgcmVxdWlyZW1lbnQgKGxlYWRpbmcg dG8gaW50ZXJvcCBpc3N1ZXMpLCBub3QgdmFsaWRhdGluZyBpdCAoYWxzbyBsZWFkaW5nIHRv IGludGVyb3AgaXNzdWVzIG9yIHNlY3VyaXR5IGlzc3VlcyBpZiB0aGUgZGVwbG95bWVudCB3 YW50cyB0byBzdGFydCBhY3R1YWxseSB1c2luZyBpdCBmb3IgcmVhbCksIG9yIGRvaW5nIHNv bWV0aGluZyBmdW5reSB3aXRoIGl0IHNpbmNlIHRoZXJlIGlzbid0IGFueXRoaW5nICJyZWFs IiB0aGF0IHRoZSB2YWx1ZSBuZWVkcyB0byBjb25mb3JtIHRvLgo8L3ByZT4KICAgICAgPC9i bG9ja3F1b3RlPgogICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPgpF dmVyeSBzcGVjIGd1aWRhbmNlIHJpc2tzIG5vdCBiZWluZyBmb2xsb3dlZC4gQnV0IGluIHRo aXMgcGFydGljdWxhciBjYXNlLCB1c2Ugb2YgYSBsb2dpY2FsIGF1ZGllbmNlIGlzIHF1aXRl IG1haW5zdHJlYW0g4oCTIHdlIGhhZCBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBmb3IgcmVzb3Vy Y2UgaW5kaWNhdG9ycyBhbmQgdGhhdOKAmXMgd2h5IHRoZSBzcGVjIGVuZGVkIHVwIGluY2x1 ZGluZyBsb2dpY2FsIGlkZW50aWZpZXJzIGFzIG9uZSBvZiB0aGUgcmVzb3VyY2UgcGFyYW1l dGVyIGZsYXZvci4g4oCccmVhbOKAnSBpcyBhIHJlbGF0aXZlIHRlcm0sIGdpdmVuIHRoYXQg dGhlcmUgYXJlIGFscmVhZHkgbWFueSBkaWZmZXJlbnQgd2F5cyBpbiB3aGljaCBhIGxvZ2lj YWwgcmVzb3VyY2UgbWlnaHQgbWFwIHRvIGRpZmZlcmVudCDigJxwaHlzaWNhbOKAnSBhcnRp ZmFjdHMgKHNlZSBoZXJva3XigJlzIGxhdGUgYmluZGluZyBVUkxzKS4gQ29sbGVjdGl2ZSBh dWRpZW5jZXMgYXJlIGluIGNvbW1vbiB1c2UgZm9yIHBvb3IgbWFu4oCZcyB0cnVzdGVkIHN1 YnN5c3RlbXM6IG5vdCBlbmRvcnNpbmcgdGhlIGFwcHJvYWNoLCBidXQgYnJpbmdpbmcgY2ly Y3Vtc3RhbnRpYWwgZXZpZGVuY2UgdGhhdCBicm9hZCBhdWRpZW5jZXMgYXJlbuKAmXQgdGhh dCB1bmNvbW1vbiBvciBoYXJkIHRvIGdyb2sgZm9yIGRldmVsb3BlcnMgYWxyZWFkeSB0b2Rh eS4gRmluYWxseSwgdHVybmluZyBvZmYgdmFsaWRhdGlvbiBpcyBhY3R1YWxseSBub3QgdGhh dCB0cml2aWFsIGluIG1hbnkgU0RLcywgZ2l2ZW4gdGhhdCB0aGV5IG1vc3RseSByZXVzZS9k ZXJpdmUgZnJvbSBPSURDIGFuZCB0aGUgYXVkaWVuY2UgY2hlY2sgaXMgbWFuZGF0b3J5OiBJ IHNhdyBtb3JlIG9mdGVuIHBlb3BsZSBkaXNhYmxpbmcgaXNzIGNoZWNrIHRoYW4gYXVkLiBO b25lIG9mIHRoaXMgbWVhbnMgdGhhdCB0aGUgZXJyb3JzIHlvdSBkZXNjcmliZSBjYW5ub3Qg aGFwcGVuOiBidXQgSSB0aGluayB0aGV5IGFyZW7igJl0IG1vcmUgbGlrZWx5IHRoYW4gYW55 IG90aGVyIGd1aWRhbmNlIGluIHRoZSBzcGVjLgoKSSBkbyBhY2sgdGhlIG1vcmUgZ2VuZXJp YyBwb2ludCB0aGF0LCBsaWtlIGluIHRoZSBwcmVjZWRpbmcgY2FzZSwgdGhpcyBtaWdodCBz dWdnZXN0IHRoYXQgdGhlIGN1cnJlbnQgZ3VpZGFuY2UgaXMgdG9vIHN0cmljdC0gc2VlICgq KQoKCgpbR2VvcmdlXQoKPC9wcmU+CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgog ICAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+SSB0aGluayBvbmUg b2YgdGhlIHByb2JsZW1zIHdlIGhhdmUgaW4gYmVpbmcgc3VwZXIgc3BlY2lmaWMgYWJvdXQg aG93IHRoZSBKV1QgYWNjZXNzIHRva2VuIGlzIGNvbnN0cnVjdGVkIGlzIHRoYXQgaXMgbWVh bnMgaXQncyBub3QgcG9zc2libGUgZm9yIG1hbnkgb3JnYW5pemF0aW9ucyB0byBmb2xsb3cu IEhvdyBzY29wZXMgYXJlIGltcGxlbWVudGVkIGlzIHZlcnkgdmFyaWVkIGFjcm9zcyBkZXBs b3ltZW50cyB3aGljaCBtZWFucyB0aGF0IHNvbWUgbWF5IGNvbmZvcm0gdG8gdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSBzcGVjIGFuZCBtYW55IG1heSBub3QuCjwvcHJlPgogICAgICA8L2Js b2NrcXVvdGU+CiAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+Cllv dSBhcmUgcmlnaHQsIHRoZSBzcGVjICBpcyBhbiBvcGluaW9uYXRlZCB0YWtlLSBJIGFncmVl IHRoYXQgbWFueSBvcmdhbml6YXRpb25zIHVzZWQgc2NvcGVzIGluIHZlcnkgZGlmZmVyZW50 IHdheXMsIGFuZCBJIHRoaW5rIGl0IGlzIHRoZSByZXN1bHQgb2YgZ2l2aW5nIHZlcnkgbGl0 dGxlIGd1aWRhbmNlIG9uIHNjb3BlcyBhbmQgcmVzb3VyY2VzLCB3aXRoIHRoZSBjb25zZXF1 ZW5jZSB0aGF0IHNvbWUgY2hvaWNlcyBtaWdodCBoYXZlIGJlZW4gbGVzcyB3aXNlIHRoYW4g b3RoZXJzLgoKV2l0aCB0aGUgY3VycmVudCBndWlkYW5jZSBJIGF0dGVtcHRlZCB0byBjYXB0 dXJlIGEgbmFycm93ZXIgc2V0IG9mIHNjZW5hcmlvcyB3aGVyZSBzb21lIG9mIHRoZSBtb3N0 IG9idmlvdXMgaXNzdWVzIChsaWtlIHNjb3BlIGNvbmZ1c2lvbikgY2FuIGJlIGF2ZXJ0ZWQs IHdoaWxlIHN0aWxsIHNhdGlzZnlpbmcgbW9zdCBvZiB0aGUgY2FzZXMgSSBvYnNlcnZlZCBp biB0aGUgc2FtcGxlIEpXVCBBVHM6IEkgYW0gbm90IHRyeWluZyB0byBvdmVyaW5kZXggb24g dGhvc2UgY2FzZXMsIGFuZCBJIGRvbuKAmXQgbWVhbiB0byBpbXBseSB0aGF0IHRoZSBwcm9m aWxlIHNob3VsZCBzdHJpY3RseSBmb2xsb3cgdGhvc2UsIGJ1dCBpbiB0aGUgc3Bpcml0IG9m IGVsaW1pbmF0aW5nIGFtYmlndWl0eSBhcyBtdWNoIGFzIHBvc3NpYmxlLCB0aGlzIHNpbmds ZSByZXNvdXJjZSBuYXJyb3dpbmcgc2VlbWVkIGEgc29saWQgY29yZSB0byBidWlsZCByb2J1 c3QgaW1wbGVtZW50YXRpb25zIG9uLSBmdWxseSBhd2FyZSBvZiB0aGUgZmFjdCB0aGF0IG1h bnkgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGNvbmZvcm0gKHRobyBJIGFt IG5vdCBzdXJlIGhvdyBtYW55IGltcGxlbWVudGF0aW9ucyBhbHJlYWR5IGFkb3B0ZWQgcmVz b3VyY2UgaW5kaWNhdG9ycyBvciBlcXVpdmFsZW50KS4KCkluIGFueSBjYXNlLCBzZWUgKCop LSBJIHRoaW5rIEkgY2FuIGJlIGNvbnZpbmNlZCB0byB0dXJuIHRoZSBjdXJyZW50IHJlc3Ry aWN0aW9ucyBpbnRvIHNlY3VyaXR5L2F1dGhvcml6YXRpb24gY29uc2lkZXJhdGlvbnMtIGJ1 dCBJIHdvdWxkIHJlbHVjdGFudGx5IGRvIHNvIGFzIEkgdGhpbmsgd2XigJlkIHBlcnBldHVh dGUgYSBsb3Qgb2YgdGhlIGFtYmlndWl0eSB3ZSBoYXZlIGluIHRoaXMgc3BhY2UgdG9kYXku CgoKCjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJl IGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPlBlcnNvbmFsbHksIEknbSBub3QgYSBi aWcgZmFuIG9mIHRyeWluZyB0byB1c2Ugc2NvcGVzIGZvciBmaW5lLWdyYWluIGF1dGhvcml6 YXRpb24uIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyB3aGF0IHRoZXkgd2VyZSBpbnRlbmRlZCBm b3Igd2hlbiBvcmlnaW5hbGx5IGRlc2lnbmVkLiAoVGhpcyBjYW4gYmUgc2VlbiBieSB0aGUg UkFSIHNwZWMgaW50cm9kdWNpbmcgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3YXkgb2Ygc3Bl Y2lmeWluZyBmaW5lLWdyYWluIGF1dGhvcml6YXRpb24gY29udGV4dC4pIEV2ZW4gaW4gbXVs dGktdGVuYW50IHN5c3RlbXMsIEkgZG9uJ3Qgc2VlIGlzc3VlcyB3aXRoIHVzaW5nIHN1Yi1y ZXNvdXJjZSBzY29wZXMgYXMgZWFjaCB0ZW5hbnQgc2hvdWxkIGRlZmluZSB0aGUgc2NvcGVz IHRoYXQgbWFrZSBzZW5zZSBmb3IgdGhhdCB0ZW5hbnQuIEkgZG9uJ3QgdGhpbmsgdGhlIEFT IG5lZWRzIHRvIHVuZGVyc3RhbmQgdGhlIHNjb3BlcywganVzdCBwcm92aWRlIGEgbWVjaGFu aXNtIHRvIGlzc3VlIHRoZSBjb3JyZWN0IHNjb3BlIHVuZGVyIHVzZXIgY29uc2VudCB0byB0 aGUgY2xpZW50IGFuZCBsZXQgdGhlIFJTIGFwcGx5IHRoZSBhdXRob3JpemF0aW9uIHBvbGlj eSB3aGVuIGl0IGdldHMgdGhlIHNjb3BlcyBvdXQgb2YgdGhlIHRva2VuLgo8L3ByZT4KICAg ICAgPC9ibG9ja3F1b3RlPgogICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFw PSIiPgpJIGFtIG5vdCBjcmF6eSBhYm91dCB0aGF0IGVpdGhlci0gZXNwZWNpYWxseSBnaXZl biB0aGF0IHdoZW4gZmluZSBncmFpbmVkIGF1dGhaIGlzIGludm9sdmVkIHZlcnksIHZlcnkg b2Z0ZW4gd2hhdCBkZXZlbG9wZXJzIHJlYWxseSB3YW50IGFyZSB1c2VyIHByaXZpbGVnZXMg YW5kIHNjb3BlcyBhcmUganVzdCBhYnVzZWQgaW4gbGlldSBvZiBwcml2aWxlZ2VzIHNpbXBs eSBiZWNhdXNlIHRoZSBzcGVjIGRvZXNu4oCZdCBhZGRyZXNzIHRoZSBub24tZGVsZWdhdGlv biBzY2VuYXJpbyBoZW5jZSBhIHNjcmV3ZHJpdmVyIGVuZHMgdXAgYmVpbmcgdXNlZCBhcyBh IGhhbW1lci4KCk5vbmV0aGVsZXNzLCBpZiBzY29wZXMgYXJlIHVzZWQtIG1hbmRhdGluZyB0 aGF0IGV2ZXJ5IHNjb3BlIGlzIHRpZWQgdG8gdGhlIHJlc291cmNlIGRvZXMgbGVhZCB0byBo dWdlIHRva2VucyBhbmQgc2lnbmlmaWNhbnQgbWFuYWdlbWVudCBvdmVyaGVhZCBpZiB5b3Ug aGF2ZSBsb3RzIG9mIHJlc291cmNlcyB3aG9zZSBpZGVudGlmaWVyIG11c3QgYmUgZ2xvYmFs bHkgdW5pcXVlLCBub25yZWFzc2lnbmFibGUgZXRjIGV0YyBoZW5jZSB2ZXJ5IGxhcmdlIOKA kyBhbmQgdGhlIEFTIGRvZXNu4oCZdCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGlj IG9mIGVhY2ggc2NvcGUgYnV0IGl0IGRvZXMgbmVlZCB0byBrbm93IHdoZXRoZXIgYSBzY29w ZSBjYW4gYmUgcmVxdWVzdGVkIGZvciBhIGdpdmVuIHJlc291cmNlLCBwbHVzIGFueSBwb2xp Y3kgdGhlIGFkbWluIG1pZ2h0IHdhbnQgdG8gZXhlY3V0ZSBhdCB0b2tlbiBpc3N1YW5jZSB0 aW1lIChlZyB0aGlzIHNjb3BlIHJlcXVpcmVzIDJGQSkgaGVuY2UganVnZ2xpbmcgbGFyZ2Ug bnVtYmVycyBvZiBsYXJnZSBzdHJpbmdzIGNhbiBiZSBoYXJkIGZvciB0aGUgQVMg4oCTIGFu ZCBSUy4gSW4gYW55IGNhc2UsIHRoZSB1c2Ugb2YgbXVsdGlwbGUgcmVzb3VyY2VzIGluIHRo ZSBhdWQgaW4gdGhlIHdpbGQgYXBwZWFyZWQgdG8gYmUgdmVyeSByYXJlLCBoZW5jZSBldmVu IGlmIHRoZXJlIHdvdWxkIGJlIGEgZm9vbHByb29mIHdheSBvZiBkZWZpbmluZyBhIHJlc291 cmNlLXNjb3BlIG1hcHBpbmcsIEkgd291bGQgbm90IHNwZW5kIGN5Y2xlcyBkZWZpbmluZyBp dCBoZXJl4oCmIGFuZCBsZWF2aW5nIGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIHdv dWxkbuKAmXQgd29yayBwZXIgdGhlIGFib3ZlLiBBcyBpbiAoKikgd2UgY291bGQgcmVsYXgg dGhlIGNvbnN0cmFpbnQgaGVyZSBhbmQganVzdCB3YXJuIHBlb3BsZSBhZ2FpbnN0IHNjb3Bl IGNvbmZ1c2lvbiwgYnV0IEkgZmVlbCB3ZeKAmWQgYmUgbWlzc2luZyBhbiBvcHBvcnR1bml0 eS4KCgoKLS0tLS0tCgoKCu+7v09uIDMvMjQvMjAsIDE3OjAwLCAiUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUiIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1h aWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj4mbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8 L2E+IHdyb3RlOgoKCgogICAgVG8gYm9ycm93IGEgdGVybSBmcm9tIE1MLCBJIHRoaW5rIHRo ZSAiYXVkIiwgInNjb3BlIiwgYW5kIHJlc291cmNlIGluZGljYXRvci1yZWxhdGVkIHRleHQg aXMgb3ZlcmZpdHRlZCB0byBhIHNwZWNpZmljIHNldCBvZiBkZXBsb3ltZW50IHNjZW5hcmlv cywgYW5kIGEgc3BlY2lmaWMgd2F5IG9mIHVzaW5nIHNjb3BlcyBhbmQgcmVzb3VyY2UgaW5k aWNhdG9ycy4KCgoKICAgIENvbnNpZGVyIHRoZSBmb2xsb3dpbmc6CgoKCiAgICAxLiBUaGVy ZSBtYXkgYmUgbm8gInNjb3BlIiBwYXJhbWV0ZXIKCiAgICBUaGUgInNjb3BlIiBwYXJhbWV0 ZXIgaXMgT1BUSU9OQUwgaW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0cy4gU28gYW4gQVMvUlMg b3BlcmF0b3IgY291bGQgZGVjaWRlIHRoZXkncmUgZ29pbmcgdG8gb21pdCAic2NvcGUiIGVu dGlyZWx5IGFuZCB1c2UgbXVsdGlwbGUgcmVzb3VyY2UgcGFyYW1ldGVycyBpbnN0ZWFkLiBT aW5jZSB0aGVyZSBhcmUgbm8gc2NvcGVzLCB0aGVyZSBpcyBubyBvcHBvcnR1bml0eSBmb3Ig Y29uZnVzaW9uLiBJbiB0aGlzIGNhc2UsIGEgSldUIEFUIHdpdGggYSBtdWx0aS12YWx1ZWQg ImF1ZCIgY2xhaW0gYW5kIG5vICJzY29wZSIgY2xhaW0gd291bGQgc2VlbSBhcHByb3ByaWF0 ZS4gV2hpbGUgbXVsdGlwbGUgcmVzb3VyY2UgaW5kaWNhdG9ycyBjb3VsZCBiZSBwdXNoZWQg aW50byBhIHNpbmdsZSBzY29wZSBzdHJpbmcsIHRoaXMgaW50cm9kdWNlcyBvcHBvcnR1bml0 aWVzIGZvciBzZXJpb3VzIHNlY3VyaXR5IGltcGFjdGluZyBlbmNvZGluZy9kZWNvZGluZy9w YXJzaW5nIGJ1Z3MuIFRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBtb3JlICJJIGRv bid0IGhhdmUgdG8gZGVhbCB3aXRoIHBhcnNpbmcgYSBzY29wZSBzdHJpbmciIHNlZW1zIGxp a2UgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBnbyB0aGlzIHJvdXRlLi4uIF9fCgoKCiAgICAy LiBUaGUgc2NvcGVzIG1heSBhcHBseSB0byBhbGwgYXVkaWVuY2VzCgogICAgQW4gQVMvUlMg b3BlcmF0b3IgbWF5IHVzZSAic2NvcGUiIHRvIGluZGljYXRlIGEgcm9sZSBvciBwb2xpY3kg KG9yIHNldCBvZiBwb2xpY2llcykgdGhhdCB0aGUgY2xpZW50IHdhbnRzLCBhbmQgYWxsb3cg dGhlIGNsaWVudCB0byBuYXJyb3cgdGhlaXIgcGVybWlzc2lvbnMgdXNpbmcgInJlc291cmNl IiBwYXJhbWV0ZXJzLiBUaGlzIHdvdWxkIGFsbG93IHRoZSBjbGllbnQgdG8gb2J0YWluIG5h cnJvd2x5IHNjb3BlZCBhY2Nlc3MgdG9rZW5zIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMgd2l0 aG91dCBuZWVkaW5nIHRvIGRlZmluZSBzZXBhcmF0ZSByb2xlcy9wb2xpY2llcyBmb3IgZWFj aC4gSW4gdGhpcyBjYXNlLCBhIEpXVCBBVCB3aXRoIGEgbXVsdGktdmFsdWVkICJhdWQiIGNs YWltIGFuZCBhICJzY29wZSIgY2xhaW0gd291bGQgc2VlbSBhcHByb3ByaWF0ZSwgYXMgdGhl IHNjb3BlIGNsYWltIGlzIGludGVuZGVkIHRvIGFwcGx5IHRvIGFsbCBvZiB0aGUgYXVkaWVu Y2UgdmFsdWVzLgoKCgogICAgMy4gVGhlIG1hcHBpbmcgYmV0d2VlbiBhdWRpZW5jZSBhbmQg c2NvcGUgbWF5IGJlIHVuYW1iaWd1b3VzCgogICAgVGhlcmUgYXJlIGEgbG90IG9mIGRlcGxv eW1lbnRzIHRvIHdoaWNoIHRoZSBibGFzdCByYWRpdXMgcmlzayB5b3UncmUgdHJ5aW5nIHRv IGFkZHJlc3MgYnkgcmVxdWlyaW5nICJhdWQiIHNpbXBseSBkb2VzIG5vdCBhcHBseS4gSXQg bWF5IHNlZW0gaW5ub2N1b3VzIHRvIHJlcXVpcmUgdGhlc2UgZGVwbG95bWVudHMgdG8gZXhw bGljaXRseSBpbmNsdWRlIGEgYnJvYWQgYXVkaWVuY2UgbGlrZSAiYXBpLmV4YW1wbGUuY29t IiBhbnl3YXksIHRoYXQgY2FuIGxlYWQgdG8gaW1wbGVtZW50ZXJzIGlnbm9yaW5nIHRoZSBy ZXF1aXJlbWVudCAobGVhZGluZyB0byBpbnRlcm9wIGlzc3VlcyksIG5vdCB2YWxpZGF0aW5n IGl0IChhbHNvIGxlYWRpbmcgdG8gaW50ZXJvcCBpc3N1ZXMgb3Igc2VjdXJpdHkgaXNzdWVz IGlmIHRoZSBkZXBsb3ltZW50IHdhbnRzIHRvIHN0YXJ0IGFjdHVhbGx5IHVzaW5nIGl0IGZv ciByZWFsKSwgb3IgZG9pbmcgc29tZXRoaW5nIGZ1bmt5IHdpdGggaXQgc2luY2UgdGhlcmUg aXNuJ3QgYW55dGhpbmcgInJlYWwiIHRoYXQgdGhlIHZhbHVlIG5lZWRzIHRvIGNvbmZvcm0g dG8uCgoKCiAgICDigJMKCiAgICBBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikKCiAgICBB V1MgSWRlbnRpdHkKCiAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm PSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LyI+aHR0cHM6Ly9hd3MuYW1hem9u LmNvbS9pZGVudGl0eS88L2E+CgoKCgoKICAgIO+7v09uIDMvMjQvMjAsIDM6MzEgUE0sICJP QXV0aCBvbiBiZWhhbGYgb2YgVml0dG9yaW8gQmVydG9jY2kiIDxhIGNsYXNzPSJtb3otdHh0 LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jnb25i ZWhhbGZvZnZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIj4m bHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygdml0dG9yaW8uYmVydG9j Y2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZToKCgoKICAgIENB VVRJT046IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2Fu aXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNz IHlvdSBjYW4gY29uZmlybSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNh ZmUuCgoKCgoKCgogICAgVGhhbmtzIEdlb3JnZSBmb3IgdGhlIHN1cGVyIHRob3JvdWdoIHJl dmlldyBhbmQgZmVlZGJhY2shCgogICAgSW5saW5lCgoKCiAgICAgICZndDsgIFNlY3Rpb24g MS4gSW50cm9kdWN0aW9uCgogICAgICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gc2Vjb25kIGxp bmU6IHNjZW5hcmlvIHNob3VsZCBiZSBwbHVyYWwgLS0mZ3Q7IHNjZW5hcmlvcwoKICAgICAg ICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBzZW50ZW5jZTogImFyZSBub3QgcmFuIGJ5 IiAtLSZndDsgImFyZSBub3QgcnVuIGJ5IgoKICAgICAgICDDr8K/wr3Dr8K/wr0gY29maWRl bnRpYWxpdHkgLS0mZ3Q7IGNvbmZpZGVudGlhbGl0eQoKICAgIEZpeGVkLiBUaGFua3MhCgoK CiAgICAmZ3Q7ICAgICBTZWN0aW9uIDIuMi4xIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9u IENsYWltcwoKICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IEknbSBub3Qgc3VyZSB0aGF0 IHRoaXMgZGVmaW5pdGlvbiBvZiBgYXV0aF90aW1lYCBhbGxvd3MgZm9yIHRoZQoKICAgICAg ICBjYXNlIHdoZXJlIGEgdXNlciBpcyByZXF1aXJlZCB0byBzb2x2ZSBhbiBhZGRpdGlvbmFs IGNoYWxsZW5nZS4KCiAgICBJZiB0aGUgY2hhbGxlbmdlIGVudGFpbHMgZ29pbmcgYmFjayB0 byB0aGUgQVMsIHRoZW4gSSBiZWxpZXZlIHRoZSBsYW5ndWFnZSAoaW4gdGhlIGluaXRpYWwg cGFyYWdyYXBoIG9mIDIuMi4xIGFuZCBpbiBhdXRoX3RpbWUgaXRzZWxmKSAgYWNjb21tb2Rh dGVzIGZvciB0aGF0IGFuZCBkb2VzIHJlcXVpcmUgdGhlIGF1dGhfdGltZSB0byBiZSB1cGRh dGVkLgoKICAgIElmIHlvdSBoaXQgdGhlIEFTIGFuZCBwcmVzZW50IGFuIGF1dGhlbnRpY2F0 aW9uIGZhY3RvciAoc3VjaCBhcyB5b3VyIGNoYWxsZW5nZSkgYW5kIG9idGFpbiBhIG5ldyB0 b2tlbiBpbiB0aGUgcHJvY2VzcywgdGhlIGF1dGhfdGltZSB3aWxsIHJlZmxlY3QgdGhlIHRp bWUgb2YgeW91ciBsYXRlc3QgYXV0aGVudGljYXRpb24ganVzdCBsaWtlIGFuIGlkX3Rva2Vu IHdvdWxkIGluIHRoZSBzYW1lIGNpcmN1bXN0YW5jZXMgKHRoaW5rIHByb3RlY3RlZCByb3V0 ZSBpbiBhIHdlYiBhcHAgcmVxdWlyaW5nIHN0ZXAgdXAgYXV0aCkgYW5kIChsaWtlbHkpIGFz c29jaWF0ZWQgc2Vzc2lvbiBhcnRpZmFjdHMgKHRoaW5rIFJUcyBvciBjb29raWVzIHdpdGgg c2xpZGluZyBleHBpcmF0aW9uLCB0aGUgY2hhbGxlbmdlIHdvdWxkIGNvdW50IGFzIGFjdGl2 aXR5IGFuZCBtb3ZlIHRoZSBleHBpcmF0aW9uKS4KCgoKICAgICZndDsgICAgIMOvwr/CvcOv wr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlc3Np b25fc3RhcnRfdGltZSBhbmQgbGFzdAoKICAgICAgICBhdXRoX3RpbWUuIFRoaXMgZmVlbHMg bW9yZSBsaWtlIGl0J3MgZGVmaW5pbmcgdGhlIHNlc3Npb25fc3RhcnRfdGltZQoKICAgICAg ICBjb25jZXB0LgoKICAgICZndDsgICAgw6/Cv8K9w6/Cv8K9IFRoZXNlIHNhbWUgaXNzdWVz IGNhbiBhcHBseSB0byB0aGUgYGFjcmAgYW5kIGBhbXJgIHZhbHVlcyBhcyB3ZWxsLgoKICAg IFBlciB0aGUgYWJvdmUsIHRoZSBpbnRlbnQgaXMgbW9yZSB0byBleHByZXNzIHRoZSBsYXN0 IHRpbWUgdGhlIHVzZXIgcGVyZm9ybWVkIGFueSBhdXRoZW50aWNhdGlvbiBhY3Rpb24gcmF0 aGVyIHRoYW4gdGhlIHN0YXJ0IHRpbWUuIFRoZSBpbnRlbnQgaXMgdG8gcHJvdmlkZSBpbmZv cm1hdGlvbiBhcyBjdXJyZW50IGFzIHBvc3NpYmxlLCBhcyBpdCBtaWdodCBiZSByZWxldmFu dCB0byB0aGUgUlMgZGVjaXNpb25zIHdoZXJlYXMgdGhlIGhpc3RvcnkgYmVmb3JlIGN1cnJl bnQgY29uZGl0aW9ucyBtaWdodCBub3QgYmUgY29uc2VxdWVudGlhbC4KCgoKICAgICAgJmd0 OyAgIMOvwr/CvcOvwr/CvSBFdmVuIGlmIGZvciB0aGlzIHNlY29uZGFyeSBjaGFsbGVuZ2Ug YSBuZXcgcmVmcmVzaF90b2tlbiBpcyBpc3N1ZWQsCgogICAgICAgIGl0IGlzIHVubGlrZWx5 IG1hbnkgcmVseWluZyBwYXJ0aWVzIHdpbGwgd2FudCB0byB0cmVhdCB0aGF0IGFzIGlzc3Vp bmcgYQoKICAgICAgICBuZXcgc2Vzc2lvbi4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgdXNl ciBsb2dnZWQgaW4gdG8gYSBzaW5nbGUgc2Vzc2lvbi4KCiAgICBDb3VsZCB5b3UgZXhwYW5k IG9uIHRoZSBwcmFjdGljYWwgaW1wbGljYXRpb25zIG9mIHRoZSBhYm92ZT8gVGhlIGludGVu dCBpc24ndCBhcyBtdWNoIHRvIHJlZmxlY3Qgc2Vzc2lvbiBpZGVudGlmeWluZyBpbmZvcm1h dGlvbiBwZXIgc2UsIGJ1dCB0byBwcm92aWRlIHRoZSBSUyB3aXRoIHRoZSBtb3N0IHVwIHRv IGRhdGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNpcmN1bXN0YW5jZXMgaW4gd2hpY2ggdGhl IGN1cnJlbnQgQVQgd2FzIG9idGFpbmVkLiBUaGUgZmFjdCB0aGF0IGEgc2Vzc2lvbiB3YXMg aW5pdGlhbGx5IGVzdGFibGlzaGVkIHVzaW5nIGFjciBsZXZlbCAwIGRvZXNu4oCZdCByZWFs bHkgbWF0dGVyIGlmIHRoZSBBVCBJIGFtIHJlY2VpdmluZyBub3cgaGFzIGJlZW4gb2J0YWlu ZWQgYWZ0ZXIgYSBzdGVwdXAgdGhhdCBicm91Z2h0IGFjciB0byAxLCBpZiBteSBSUyBjYXJl cyBhdXRoIGF1dGhlbnRpY2F0aW9uIGxldmVscyBteSBhdXRob3JpemF0aW9uIGRlY2lzaW9u IHNob3VsZG4ndCBiZSBpbmZsdWVuY2VkIGJ5IHdoZXRoZXIgc29tZXdoZXJlIHRoZSBzZXNz aW9uIGFydGlmYWN0IGRpZG7igJl0IGNoYW5nZSBpdHMgc2Vzc2lvbklEIGFmdGVyIHRoZSBz dGVwdXAuIFNhbWUgZm9yIGFjciwgYXV0aF90aW1lCgoKCiAgICAmZ3Q7ICAgICBTZWN0aW9u IDIuMi4zIEF1dGhvcml6YXRpb24gQ2xhaW1zCgogICAgICAgICDDr8K/wr3Dr8K/wr0gSSBm aW5kIHRoZSBzdGF0ZW1lbnQgIkFsbCB0aGUgaW5kaXZpZHVhbCBzY29wZSBzdHJpbmdzIGlu IHRoZSBzY29wZQoKICAgICAgICBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBmb3IgdGhlIHJl c291cmNlIGluZGljYXRlZCBpbiB0aGUgYXVkIGNsYWltIgoKICAgICAgICBzb21ld2hhdCBw cm9ibGVtYXRpYy4gSW4gbWFueSBkZXBsb3ltZW50cyB0b2RheSBmb3IgMXN0IHBhcnR5IGNs aWVudHMgdG8KCiAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0YWtpbmcg aW50byBhY2NvdW50IG1vYmlsZSBhcHBsaWNhdGlvbnMsCgogICAgICAgIHRoZSBhY2Nlc3Mg dG9rZW4gbW9zdCBsaWtlIGNvbnRhaW5zIHNjb3BlcyBmb3IgbWFueSBvZiB0aGUgMXN0IHBh cnR5CgogICAgICAgIGJhY2tlbmQgQVBJcy4gSXQncyBwb3NzaWJsZSB0byBnZXQgYXJvdW5k IHRoaXMgYnkgc2V0dGluZyB0aGUgJ2F1ZCcKCiAgICAgICAgY2xhaW0gdG8gc29tZXRoaW5n IGxpa2UgImNvbS5leGFtcGxlLmFwaXMiIGFuZCBoZW5jZSBhbGwgdGhlIGlzc3VlZAoKICAg ICAgICBzY29wZXMgbWFwIHRvIHRoYXQgYXVkaWVuY2UgY2xhaW0gYnV0IHRoYXQgaXMganVz dCB3b3JraW5nIGFyb3VuZCB0aGUKCiAgICAgICAgTVVTVCBpbiB0aGUgc3BlYy4gR2l2ZW4g dGhlIGxhY2sgb2Ygc3BlY2lmaWNpdHkgb2YgdGhlICdhdWQnIGNsYWltIGFuZAoKICAgICAg IHRoZSAncmVzb3VyY2UgaW5kaWNhdG9yJyBjbGFpbSBmb3IgdGhhdCBtYXR0ZXIsIHByZXR0 eSBtdWNoIGFueXRoaW5nIGNhbgoKICAgICAgICBiZSBtYWRlIHRvIGNvbXBseS4gSW4gdGhh dCBjb250ZXh0LCBpdCBzZWVtcyBsaWtlIFJFQ09NTUVORCBpcyBhIGJldHRlcgoKICAgICAg ICBub3JtYXRpdmUgY2xhdXNlLgoKICAgIEZvciAxc3QgcGFydHkgc29sdXRpb25zLCBJIHdv dWxkIGFyZ3VlIHRoYXQgZGVsZWdhdGlvbiBtaWdodCBub3QgYmUgdGhlIHJpZ2h0IHByaW1p dGl2ZSBoZW5jZSBJIHdvdWxkbid0IG5lY2Vzc2FyaWx5IHVzZSBzY29wZXMgdG8gZXhwcmVz cyBwZXJtaXNzaW9uczsgYnV0IHRoYXQncyBhIHJhYmJpdCBob2xlIEknbGwgdHJ5IHRvIGF2 b2lkIGZvciB0aGUgdGltZSBiZWluZyBfXwoKICAgIEZvciB0aGUgYXVkLCBJIHRoaW5rIHRo YXQgd2hhdCB5b3UgY2hhcmFjdGVyaXplZCBhcyB3b3JrYXJvdW5kIHdvdWxkIGFjdHVhbGx5 IGJlIGJ5IGRlc2lnbi4gVGhlIGF1ZCBkZWZpbmVzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRo ZSBjdXJyZW50IHRva2VuLCBzbyB0aGF0IGluIGNhc2Ugb2YgbGVha2FnZSB0aGUgYmxhc3Qg cmFkaXVzIG9mIHRoZSBpbmNpZGVudCBjYW4gYmUgY29udGFpbmVkLiBJZiB0aGUgc29sdXRp b24gZGVzaWduZWQgZGVjaWRlcyB0aGF0IHRoaXMgcGFydGljdWxhciB0b2tlbiBzaG91bGQg YmUgcmV1c2FibGUgYWNyb3NzIG11bHRpcGxlIGFzc2V0cywgSSB0aGluayBpdCBtYWtlcyBz ZW5zZSBmb3IgdGhlIGF1ZCB0byByZWZsZWN0IHRoYXQgZXhwbGljaXRseS4gVGhhdCdzIHRo ZSBzeXN0ZW0gZGVzaWduaW5nIHZvbHVudGVlcmluZyBhIHNjb3BlIHhwYW5zaW9uIG9mIHRo ZSBzY29wZSwgYW5kIGdpdmVuIHRoYXQgaXQgaGFzIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBJ IHRoaW5rIGl0J3MgZ29vZCB0byByZXF1aXJlIGl0IHRvIGJlIGFuIGV4cGxpY2l0LCBvcHQg aW4gYWN0aW9uLiBBdCB0aGUgc2FtZSB0aW1lLCBnaXZlbiB0aGF0IHNjb3BlcyBhcmUgb2Z0 ZW4gdXNlZCB0byBkZWZpbmUgcGVybWlzc2lvbnMsIEkgYmVsaWV2ZSBpdCBtYWtlcyBzZW5z ZSB0byBmaW5kIG1lY2hhbmlzbXMgdG8gbWluaW1pemUgdGhlIGNoYW5jZSB0aGF0IFJTZXMg d291bGQgbWlzaW50ZXJwcmV0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIGEgc2NvcGUgKHNlZSBk aXNjdXNzaW9uIHdpdGggVGFrYWhpa28vTmlrb3MpLiBTdW1taW5nIGFsbCB0aGUgYWJvdmUs IEknZCBiZSBpbmNsaW5lZCB0byBrZWVwIHRoZSBNVVNULgoKCgogICAgJmd0OyBTZWN0aW9u IDMuIFJlcXVlc3RpbmcgYSBKV1QgQWNjZXNzIFRva2VuCgogICAgICAgICDDr8K/wr3Dr8K/ wr0gUGVyIG15IGNvbW1lbnRzIGFib3ZlIEkgc3VzcGVjdCB0aGF0IHJlcXVpcmluZyBhbGwg SldUIGFjY2VzcyB0b2tlbnMKCiAgICAgICAgdG8gaW5jbHVkZSBhbiBhdWRpZW5jZSBjbGFp bSB3aWxsIGp1c3QgZGV2b2x2ZSB0byBhdWRpZW5jZSBjbGFpbXMgdGhhdAoKICAgICAgICBh cmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRlciB0byBtZWV0IHRoaXMgTVVTVCBpbiB0 aGUgc3BlYykuIEdpdmVuCgogICAgICAgIHRoZSBtb2JpbGUgYXBwIGVudmlyb25tZW50IHRv ZGF5LCBpdCBpcyB1bnJlYXNvbmFibGUgdG8gYXNrIHRoZSBtb2JpbGUKCiAgICAgICAgYXBw cyB0byBkb3duc2NvcGUgZXZlcnkgYWNjZXNzIHRva2VuIGJlZm9yZSBtYWtpbmcgYW4gQVBJ IGNhbGwgdG8gdGhlCgogICAgICAgIGJhY2tlbmQgQVBJcyB3aGljaCBpcyB3aGF0IHRoZSBz cGlyaXQgb2YgYXVkaWVuY2UgYW5kIHJlc291cmNlCgogICAgICAgIGluZGljYXRvcnMgc2Vl bSB0byBpbXBseS4KCiAgICBQYXJ0bHkgYWRkcmVzc2VkIGluIHRoZSBwcmVjZWRpbmcgcG9p bnQsIGJ1dCB0aGlzIGlzIGEgZ3JlYXQgb3Bwb3J0dW5pdHkgdG8gY2xhcmlmeSB0aGUgaW50 ZW50IGZ1cnRoZXIuIFRoZSBtb2JpbGUgY2xpZW50IGlzbid0IHJlcXVpcmVkIHRvIGRvd25z Y29wZTsgcmF0aGVyLCB0aGUgZmFjdCB0aGF0IGEgdG9rZW4gY2FiIGJlIGFwcGxpZWQgdG8g YSBicm9hZCByYW5nZSBvZiBBUEkgc2hvdWxkIGJlIGNsZWFybHkgaWRlbnRpZmllZCBhbmQg ZXhwcmVzc2VkIGJ5IHRoZSBsb2dpY2FsIGF1ZGllbmNlLiBUaGUgc3lzdGVtIGRlc2lnbmVy IGNhbiBldmVuIGNob29zZSB0byBoYXZlIGEgc2luZ2xlIHRva2VuIHRoYXQgY2FuIGJlIHVz ZWQgdG8gY2FsbCBhbnkgQVBJLCBjb250YWluaW5nIGV2ZXJ5IHNjb3BlIGZvciBldmVyeSBB UEk7IHRoZSBwcm9maWxlIG9ubHkgYXNrcyBmb3IgdGhpcyBjaG9pY2UgdG8gYmUgbWFuaWZl c3QsIGJ5IGNob29zaW5nIGFuIGFwcHJvcHJpYXRlIGF1ZGllbmNlIGlkZW50aWZpZXIgYW5k IGFja25vd2xlZGdpbmcgdGhhdCBhbGwgdGhlIHNjb3BlcyBpbiB0aGUgdG9rZW4gYXJlIGFw cGxpY2FibGUgdG8gdGhlIHNhbWUgbG9naWNhbCByZXNvdXJjZSAodGhhdCBpcywgdGhlIGFn Z3JlZ2F0ZSBvZiBhbGwgdGhlIEFQSXMpLgoKCgogICAgICAgICAmZ3Q7ICDDr8K/wr3Dr8K/ wr0gV2h5IE1VU1QgdGhlIEFTIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtb3JlIHRoYW4gb25l IHJlc291cmNlCgogICAgICAgIHBhcmFtZXRlcj8gSWYgYSByZXF1ZXN0IGNvbWVzIGluIHdp dGggbm8gcmVzb3VyY2UgcGFyYW1ldGVyIGFuZCBtdWx0aXBsZQoKICAgICAgICBzY29wZXMg dGhlIEFTIGlzIG5vdCByZXF1aXJlZCB0byByZWplY3QgdGhhdCByZXF1ZXN0LiBJcyB0aGVy ZSBtdWNoIG9mIGEKCiAgICAgICAgc2VtYW50aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0 d28/IEluIHRoZSBjYXNlIG9mIG5vIHJlc291cmNlCgogICAgICAgIHBhcmFtZXRlciBhbmQg bXVsdGlwbGUgc2NvcGVzIHRoZSBBUyBtaWdodCBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gd2l0 aAoKICAgICAgICBtdWx0aXBsZSBhdWRpZW5jZSB2YWx1ZXMgKGFzIGlzIGFsbG93ZWQgYnkg UkZDIDc1MTkpLgoKICAgIFRoaXMgaXMgYW5vdGhlciBjb25zZXF1ZW5jZSBvZiBtYWtpbmcg ZXh0cmEgY2xlYXIgd2hhdCB0aGUgdG9rZW4gcmVmZXJzIHRvLCBhbmQgd2hhdCB0aGUgaW50 ZW5kZWQgc2VtYW50aWMgb2YgdGhlIHNjb3BlcyBpcy4gVGhlIGlkZWEgaXMgdGhhdCB0aGUg dG9rZW4gaXMgYWx3YXlzIHJlc3RyaWN0ZWQgdG8gT05FIHNwZWNpZmljIGF1ZGllbmNlLiBU aGUgcHJvZmlsZSBhbGxvd3MgZm9yIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciB0aGUgQVMg dG8gZGV0ZXJtaW5lIHdoYXQgdmFsdWUgdGhlIGF1ZGllbmNlIHNob3VsZCBiZSwgaW5jbHVk aW5nIHZpYSBpbmZlcmVuY2UgZnJvbSBzY29wZXMsIGJ1dCBjb2hlcmVudGx5IHdpdGggdGhl IHNjb3BlIGNvbmZ1c2lvbiBwcmV2ZW50aW9uIHByaW5jaXBsZSwgaWYgdGhhdCBpbmZlcmVu Y2UgY2Fubm90IGxlYWQgdG8gYSBzaW5nbGUgcmVzb3VyY2UgaWRlbnRpZmllciBpbiB0aGUg YXVkaWVuY2UsIHRoZSByZXF1ZXN0IHNob3VsZCBiZSByZWplY3RlZC4KCiAgICBUaGUgaW50 ZW50IGlzIHJlYWxseSB0byBiZSBhcyBzaW1wbGUgYXMgdW5hbWJpZ3VvdXMgYXMgcG9zc2li bGUsIGFuZCBjYXB0dXJlIHdoYXQgbW9zdCBtYWluc3RyZWFtIHByb3ZpZGVycyBhbHJlYWR5 IGRvIGluIEpXVCBBVHMuIElmIGEgUlMgaGFzIG1vcmUgc29waGlzdGljYXRlZCByZXF1aXJl bWVudHMsIHRoZXkgY2FuIGFsd2F5cyBkZWNpZGUgdG8gZG8gbW9yZSBhbmQgbm90IGZvbGxv dyB0aGUgaW50ZXJvcCBwcm9maWxlLiBEZWZpbmluZyBtb3JlIGNvbXBsZXggcnVsZXMgdG8g cHJldmVudCBzY29wZS9yZXNvdXJjZSBhc3NvY2lhdGlvbiBjb25mdXNpb24gc2ltcGx5IGRv ZXNu4oCZdCBzZWVtIHRvIGJlIGp1c3RpZmllZCBieSB0aGUgZnJlcXVlbmN5IG9mIHRoZSBz Y2VuYXJpbyBpbiB0aGUgd2lsZC4KCgoKCgogICAgJmd0OyAgQWxzbywgdGhlIGF1ZGllbmNl CgogICAgICAgIGNsYWltIGlzIG5vdCBzb2xlbHkgZm9yIHJlc291cmNlIGluZGljYXRvciB2 YWx1ZXMgYnV0IGlzIGRlZmluZWQgdG8ganVzdAoKICAgICAgICBiZSBhIHN0cmluZy4gVG8g bWUgaXQgZmVlbHMgbGlrZSB0aGUgdGV4dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5Cgog ICAgICAgIHZhbGlkIGF1ZGllbmNlIHZhbHVlIGlzIGFsc28gYSByZXNvdXJjZSBpbmRpY2F0 b3IgKHdoaWNoIGZyb20gcHJldmlvdXMKCiAgICAgICAgZGlzY3Vzc2lvbnMgb24gdGhlIGxp c3QgaXQgd2FzIGltcGxpZWQgdGhleSBoYXZlIGEgc2xpZ2h0bHkgZGlmZmVyZW50CgogICAg ICAgIHNlbWFudGljKS4KCiAgICBTZWN0aW9uIDMgb2YgdGhlIHByb2ZpbGUgZG9lcyBkZWZp bmUgYXVkIGFzIGEgcmVzb3VyY2UgaW5kaWNhdG9yLCBlbnVtZXJhdGluZyBhbiBleGhhdXN0 aXZlIGxpc3Qgb2YgcG9zc2libGUgcmVxdWVzdHMgdGhhdCBhbGwgZW5kIGluIGEgcmVzb3Vy Y2UgaW5kaWNhdG9yIGFzIGF1ZCwgb3IgYW4gZXJyb3IuIERpZCBJIG1pc3Mgc29tZSBjYXNl cz8gSSBkb27igJl0IHJlY2FsbCBzcGVjaWZpY3MgYWJvdXQgYXVkIHZhbHVlcyBpbiB0aGlz IHByb2ZpbGUgaGF2aW5nIG90aGVyIHBvc3NpYmxlIHZhbHVlcywgc29ycnkgZm9yIGhhdmlu ZyBtaXNzZWQgdGhhdC4gRG8geW91IGhhdmUgYSBzbmlwcGV0IHJlZmVycmluZyB0byB0aG9z ZSBkaXNjdXNzaW9ucz8gVGh4CgoKCiAgICAgICAgJmd0OyAgw6/Cv8K9w6/Cv8K9IFRoZSBt b2RlbCBkZXNjcmliZWQgaGVyZSB3b3JrcyB3ZWxsIGlmIG15Y28uZXhhbXBsZSByZWFsbHkg b25seQoKICAgICAgICBwcm92aWRlcyBhIHNpbmdsZSBzZXJ2aWNlLiBCdXQgaWYgaW5zdGVh ZCBteWNvLmV4YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGUKCiAgICAgICAgc2VydmljZXMgZWFj aCB3aXRoIHRoZWlyIG93biBlbmRwb2ludHMgKHNydmEubXljby5leGFtcGxlLAoKICAgICAg ICBzcnZiLm15Y28uZXhhbXBsZSkgYW5kIHNjb3BlcywgZm9yIG1lIHRoaXMgbW9kZWwgYmVn aW5zIHRvIGJyZWFrIGRvd24uCgogICAgICAgIEVpdGhlciBtb2JpbGUgYXBwcyBhcmUgcmVx dWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tlbnMgdG8ganVzdCB0aGUKCiAgICAgICAgc2Vy dmljZSB0aGV5IGFyZSBjYWxsaW5nIGF0IHRoYXQgcG9pbnQgaW4gdGltZSAod2hpY2ggY2Fu IGhhdmUgbGF0ZW5jeQoKICAgICAgICBhbmQgY29ubmVjdGl2aXR5IGlzc3VlcyksIG9yIG15 Y28uZXhhbXBsZSBoYXMgdG8gY3JlYXRlIGEgZ2VuZXJpYwoKICAgICAgICAiYXVkaWVuY2Ui IHN0cmluZyB0aGF0IHJlcHJlc2VudHMgYWxsIG9mIGV4YW1wbGUuY29tIHdoaWNoIGRvZXNu J3Qgc2VlbQoKICAgICAgICB0byBiZSB0aGUgc3Bpcml0IG9mIHRoZSBleGlzdGluZyBzcGVj cy4KCiAgICBJIHRoaW5rIHRoYXQgdGhlIGdyYW51bGFyaXR5IG9mIHRoZSBjYWxscyBpcyBm dWxseSB3aXRoaW4gdGhlIGNvbnRyb2wgb2YgdGhlIGRlc2lnbmVyLiBJZiBzcnZhLm15Y28u ZXhhbXBsZSBhbmQgc3J2Yi5teWNvLmV4YW1wbGUgc2hhcmUgYW5hbG9nb3VzIGNoYXJhY3Rl cmlzdGljcyAoc2FtZSBwb2xpY2llcywgbGlmZWN5Y2xlLCByZXNvdXJjZSBvd25lcnNoaXAs IGV0YykgdGhlbSBpdCdzIHBlcmZlY3RseSB2YWxpZCB0byBhc3NpZ24gYSBsb2dpY2FsIG15 Y28uZXhhbXBsZSBhdWRpZW5jZSBlbmNvbXBhc3NpbmcgdGhlbSBhbGwsIHJlZ2FyZGxlc3Mg b2YgZGVwbG95bWVudCBtb2RlbC4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGluIHRlcm1z IG9mIHBvbGljaWVzLCBhdXRoIHN0cmVuZ3RoIHJlcXVpcmVtZW50cywgbGlmZWN5Y2xlLCBy aXNrIGFuZCBpbXBhY3Qgb2YgYSBsZWFrLCBvciBhbnkgb3RoZXIgYm91bmRhcnksIHRoZW4g dGhlIGF1ZGllbmNlIHJlcXVpcmVtZW50IHdpbGwgZ3VhcmFudGVlIHRoYXQgdGhvc2UgZGlm ZmVyZW5jZXMgYXJlIHJlZmxlY3RlZCBpbiB0b2tlbnMgcmVxdWVzdGVkIGFuZCBjYWNoZWQs IGluIHRoZSB3YXkgaW4gd2hpY2ggYWNjZXNzIGlzIHBhcnRpdGlvbmVkLCBhbmQgc28gb24g YW5kIHNvIGZvcnRoLiBJZiB0aGVyZSBhcmUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHN1Y2gg YXMgdGhlIG9uZXMgZW51bWVyYXRlZCwgdGhlIGxhdGVuY3kgYW5kIGNvbm5lY3Rpdml0eSBp c3N1ZXMgYXJlbuKAmXQgYSBibG9ja2luZyBmYWN0b3I7IGFuZCBpZiB0aGVyZSBhcmVuJ3Qs IG5vdGhpbmcgcHJldmVudHMgeW91IGZyb20gaGF2aW5nIGEgbG9naWNhbCBhdWRpZW5jZSB2 YWx1ZS4gRnJvbSB0aGUgZXhwcmVzc2l2ZSBwb3dlciBwb2ludCBvZiB2aWV3LCB0aGUgcmVx dWlyZW1lbnQgb2YgaGF2aW5nIGEgc2luZ2xlIGF1ZGllbmNlIGRvZW5zJ3QgcHJldmVudCB5 b3UgZnJvbSBkb2luZyBhbnkgb2YgdGhlIHNpbmdsZSB0b2tlbiBsb2dpYyB5b3UgYXJlIGhp bnRpbmcgYXQtIGVzcGVjaWFsbHkgaWYgeW91IHBsYW4gdG8gdXNlIHNwZWNpYWxpemVkIHNj b3BlcyBhbnl3YXkuCgoKCiAgICAgICAmZ3Q7ICAgw6/Cv8K9w6/Cv8K9IEluIHN1bW1hcnks IEkgZmVlbCB0aGF0IHRoaXMgdGV4dCBpcyBiaW5kaW5nIHRvbyB0aWdodGx5IHJlc291cmNl CgogICAgICAgIGluZGljYXRvcnMgdG8gdGhlIGF1ZGllbmNlIGNsYWltLiBXaGF0IGlzIGRl c2NyaWJlZCBpcyBwZXJmZWN0bHkKCiAgICAgICAgcmVhc29uYWJsZSBpbiBhIHVzZSBjYXNl IHRoYXQgaXMgYXBwbHlpbmcgcmVzb3VyY2UgaW5kaWNhdG9ycyBpbiB0aGlzCgogICAgICAg IHdheSBidXQgaXMgbm90IGluZGljYXRpdmUgb2YgdGhlIHdpZGVseSBkZXBsb3llZCBtb2Rl bHMgdGhhdCBhbHJlYWR5IGV4aXN0LgoKICAgIFdlIG1pZ2h0IGhhdmUgZGlmZmVyZW50IGV4 cGVyaWVuY2VzIGhlcmUuIFRoZSBKV1QgYWNjZXNzIHRva2VucyBmcm9tIHBvcHVsYXIgcHJv ZHVjdHMgSSBzdHVkaWVkIGluIHRoZSByZXNlYXJjaCBJIHByZXNlbnRlZCBpbiBTdHV0dGdh cnQgd2VyZSBhbG1vc3QgYWxsIHVzaW5nIHRoZSBhdWQgY2xhaW0gaW4gdGhpcyB3YXkuIEkg YW0gc3VyZSB0aGF0IHRoZXJlIGFyZSBvdGhlciBtb2RlbHMsIGFuZCB0aGVyZSB3YXMgYXQg bGVhc3Qgb25lIGV4Y2VwdGlvbiwgYnV0IGluIGludGVyb3AgdGVybXMgdGhpcyBzZWVtcyB0 byBiZSB0aGUgbW9zdCBjb21tb24gd2F5IG9mIHVzaW5nIEpXVCBmb3IgQVRzLSBhbmQgaXQg aGFzIHRoZSBhZHZhbnRhZ2Ugb2YgYmVpbmcgdmVyeSBzaW1wbGUgYW5kIHVuYW1iaWd1b3Vz LgoKCgogICAgJmd0OyBTZWN0aW9uIDQuIFZhbGlkYXRpbmcgSldUIEFjY2VzcyBUb2tlbnMK CiAgICAgICAgIMOvwr/CvcOvwr/CvSBTdGVwIDQuIC0tIENhbiB3ZSBjaGFuZ2UgdGhlIHdv cmRpbmcgdG8gbm90IHJlcXVpcmUgcmVzb3VyY2UKCiAgICAgICAgaW5kaWNhdG9ycz8gV2hh dCBhYm91dC4uLiAiVGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoYXQgdGhl CgogICAgICAgICdhdWQnIGNsYWltIGNvbnRhaW5zIGEgc3RyaW5nIHRoYXQgcmVwcmVzZW50 cyB0aGUgYXVkaWVuY2Ugb2YgdGhpcwoKICAgICAgICByZXNvdXJjZSBzZXJ2ZXIuIgoKICAg IENvdWxkIHlvdSBtYWtlIGFuIGV4YW1wbGUgaW4gd2hpY2ggeW91J2Qgd2FudCB0byB1c2Ug YW4gaWRlbnRpZmllciB0aGF0IGlzIG5vdCBhIHJlc291cmNlIGluZGljYXRvcj8gR2l2ZW4g dGhhdCB3ZSBoYXZlIHRoZSBzcGVjLCBhbmQgImF1ZGllbmNlIG9mIHRoZSByZXNvdXJjZSBz ZXJ2ZXIiIHNlZW1zIHRvIGJlIHRoZSBleGFjdCBzZW1hbnRpYyBvZiByZXNvdXJjZSBpbmRp Y2F0b3JzLCBpdCBzZWVtZWQgYSBzbGFtIGR1bmsgdG8gdXNlIGl0IGhlcmUuLi4KCgoKICAg ICAgICZndDsgU2VjdGlvbiA1LiAiY3Jvc3MtSldUIGNvbmZ1c2lvbiIKCiAgICAgICAgIMOv wr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJlIG1heSBiZSBjb25mdXNpb24gYXJvdW5kIHdoYXQg aXMgbWVhbnQgYnkgImRpc3RpbmN0CgogICAgICAgIHJlc291cmNlcyIuIEluIG15IGV4YW1w bGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhhbXBsZSBhbmQKCiAgICAgICAgc3J2Yi5teWNv LmV4YW1wbGUgImRpc3RpbmN0IHJlc291cmNlcyI/IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8g c2F5IHRoYXQKCiAgICAgICAgd2Ugd2FudCBkaWZmZXJlbnQgYXVkaWVuY2UgdmFsdWVzIGdl bmVyYXRlZCBmb3IgY3Jvc3Mtb3JnYW5pemF0aW9uCgogICAgICAgIHJlc291cmNlcy4gRm9y IGV4YW1wbGUsIGFyZSBtYWlsLmdvb2dsZS5jb20gYW5kIHlvdXR1YmUuY29tICJkaXN0aW5j dAoKICAgICAgICByZXNvdXJjZXMiPyBvciB3b3VsZCBhbiBhdWRpZW5jZSBmb3IgZ29vZ2xl IHN1ZmZpY2UgaW4gbWVldGluZyB0aGUKCiAgICAgICAgbWVhbmluZyBvZiB0aGlzIHBhcmFn cmFwaD8KCiAgICBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaGVyZSBpcyAtIHdlIGRvbuKAmXQg a25vdy4gSSBhZ3JlZSB0aGUgbGFuZ3VhZ2UgaXNuJ3QgY2xlYXIgdGhlcmUuIExldCBtZSBl eHBhbmQgb24gdGhlIGludGVudCwgYW5kIHBlcmhhcHMgd2UgY2FuIGdldCB0byBhIGJldHRl ciBmb3JtdWxhdGlvbi4KCiAgICBPQXV0aDIgZG9lc27igJl0IGRlbWFuZCB0aGF0IFJTIGFu ZCBBUyBhcmUgcnVuIGJ5IHRoZSBzYW1lIGVudGl0eSwgYnV0IHRoYXQncyB0aGUgbW9zdCBj b21tb24gc2NlbmFyaW8uIEZCIGRvZXNuJ3QgbmVlZCB0byBzcGVjaWZ5IGEgcmVzb3VyY2Us IGJlY2F1c2UgdGhlIHJlc291cmNlIGlzIGltcGxpY2l0Li4gaXQncyB0aGUgRkIgZ3JhcGgs IHlvdSBjYW7igJl0IGdldCBhIHRva2VuIGZvciBhbnl0aGluZyBlbHNlLiBUaGUgb25seSBk aWZmZXJlbnRpYXRvciBlbmRzIHVwIGJlaW5nIHRoZSBzY29wZXMuIFNhbWUgZm9yIG1hbnkg b3RoZXIgcHJvdmlkZXJzLCBnb29nbGUsIE1pY3Jvc29mdCBmb3IgaXRzIG93biBHcmFwaCwg ZXRjLgoKICAgIEhvd2V2ZXIgbWFueSBBUyBhcyBhIHNlcnZpY2UgZG9u4oCZdCBoYXZlIHRo ZSBiZW5lZml0IG9mIGEgZGVmYXVsdCwgaW1wbGljaXQgcmVzb3VyY2UsIGVzcGVjaWFsbHkg aW4gbXVsdGkgdGVuYW5jeSBzY2VuYXJpb3MsIGdpdmVuIHRoYXQgdGhleSdsbCBuZWVkIHRv IGlzc3VlIHRva2VucyBmb3IgYSBudW1iZXIgb2YgZGlmZmVyZW50IHJlY2lwaWVudHMuIFdo ZXRoZXIgcmVzb3VyY2VzIGFyZSBjcm9zcyBvcmdhbml6YXRpb24sIG9yIGNyb3NzIGRlcGFy dG1lbnQsIG9yIGZvbGxvd2luZyBhbnkgb3RoZXIgYXJiaXRyYXJ5IHNlZ3JlZ2F0aW9uL2Zh Y3RvcmluZyBtb2RlbCBpcyBzb21ldGhpbmcgd2UgY2Fubm90IGluZmVyLSBpdCdzIHVwIHRv IHRoZSBkZXZlbG9wZXIgdG8gZGV0ZXJtaW5lIHRoYXQuIFdoYXQgSSBhbSB0cnlpbmcgdG8g ZXhwcmVzcyBoZXJlIGlzIHRoYXQgdGhlIG9wZXJhdG9yIG9mIHRoZSBBUyBhcyBhIHNlcnZp Y2UgKG9yIGFueSBvdGhlciBmb3JtIG9mICJBUyBmb3IgcmVudCIpIHNob3VsZCBzdXJmYWNl IHJlc291cmNlcyBhcyBhIHByaW1pdGl2ZSBmb3IgbW9kZWxpbmcgYW5kIGlkZW50aWZ5aW5n IGludGVuZGVkIHJlY2lwaWVudHMgb2YgQVRzLiBEb2VzIHRpcyBoZWxwPyBIb3cgd291bGQg eW91IGV4cHJlc3MgdGhhdD8KCgoKICAgICZndDsgICAgICDDr8K/wr0gSSdtIGhhdmluZyB0 aGUgc2FtZSBjb25mdXNpb24gaW4gdGhlIG5leHQgcGFyYWdyYXBoIHJlZ2FyZGluZyB0aGUK CiAgICAgICAgcGhyYXNlICJkaWZmZXJlbnQgcmVzb3VyY2VzIi4gQXJlIHNlcnZpY2VzIHBy b3ZpZGVkIGJ5IHRoZSBzYW1lIGNvbXBhbnkKCiAgICAgICAgImRpZmZlcmVudCByZXNvdXJj ZXMiIG9yIGFyZSB0aGV5IGFsbCBjb25zaWRlcmVkIHRoZSBzYW1lIHJlc291cmNlLiBDYW4K CiAgICAgICAgYW4gYWNjZXNzIHRva2VuIGJlIGlzc3VlZCB3aXRoIHNjb3BlcyBmb3IgYm90 aCBtYWlsLmdvb2dsZS5jb20gYW5kCgogICAgICAgIHlvdXR1YmUuY29tPyBBbmQgaWYgbm90 LCB3aHkgbm90ZT8gUHJldmVudGluZyB0aGlzIHB1dHMgdW5kdWUgYnVyZGVuIG9uCgogICAg ICAgIG1vYmlsZSBiYXNlZCBhcHBsaWNhdGlvbnMuCgogICAgU2VlIHByZWNlZGluZyBwb2lu dC4gV2UgY2FuJ3QgZW50ZXIgaW4gdGhlIG1lcml0IG9mIHdoYXQgY29uc3RpdHV0ZXMgYSBy ZXNvdXJjZSwgYXMgdGhhdCBkZXBlbmRzIG9uIHRoZSBtb2RlbGluZyBvZiB0aGUgZG9tYWlu IHNwZWNpZmljIHByb2JsZW0gdGhlIGRldmVsb3BlciBpcyB0YWNrbGluZy4gVGhlIGhpZ2hl c3Qgb3JkZXIgYml0IGlzIHRoYXQgaWYgdHdvIGVudGl0aWVzIChBUEksIGV0Yy4uIGludGVu ZGVkIHRva2VuIHJlY2lwaWVudHMpIGhhdmUgZGlmZmVyZW50IHNlY3VyaXR5IGNoYXJhY3Rl cmlzdGljcyAoZS5nLiBsZWFraW5nIGEgdG9rZW4gZm9yIG9uZSBoYXMgZGlmZmVyZW50IGNv bnNlcXVlbmNlcyB0aGFuIGlmIHlvdSdkIGxlYWsgYSB0b2tlbiBmb3IgdGhlIG90aGVyKSwg dGhleSBzaG91bGQgYmUgbW9kZWxlZCBhcyBkaWZmZXJlbnQgcmVzb3VyY2VzLiBBbmQgaWYg dGhleSBhcmUgZGlmZmVyZW50IHJlc291cmNlcywgd2Ugc2hvdWxkIGRvIHdoYXQgd2UgY2Fu IHRvIGF2b2lkIGNvbmZ1c2lvbiBpbiBob3cgd2UgZXhwcmVzcyBhY2Nlc3MgZ3JhbnRzIHRv IHRoZW0gKGhlbmNlIHRoZSBiaWcgZGlzY3Vzc2lvbiBvbiBtdWx0aXJlc291cmNlLCBzY29w ZSBjb25mdXNpb24sIGV0YykuCgoKCgoKICAgIC0tLS0tLS0tLQoKICAgIE9uIDMvMjQvMjAs IDEwOjM5LCAiR2VvcmdlIEZsZXRjaGVyIiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIz OTZFIiBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+Jmx0O2dmZmxldGNoQGFvbC5j b20mZ3Q7PC9hPiB3cm90ZToKCgoKICAgICAgICBGZWVkYmFjayBvbiB0aGUgc3BlYy4uLgoK CgogICAgICAgIFNlY3Rpb24gMS4gSW50cm9kdWN0aW9uCgogICAgICAgICDDr8K/wr3Dr8K/ wr3Dr8K/wr0gc2Vjb25kIGxpbmU6IHNjZW5hcmlvIHNob3VsZCBiZSBwbHVyYWwgLS0mZ3Q7 IHNjZW5hcmlvcwoKICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBzZW50ZW5j ZTogImFyZSBub3QgcmFuIGJ5IiAtLSZndDsgImFyZSBub3QgcnVuIGJ5IgoKCgogICAgICAg IFNlY3Rpb24gMi4yLjEgQXV0aGVudGljYXRpb24gSW5mb3JtYXRpb24gQ2xhaW1zCgogICAg ICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBkZWZpbml0 aW9uIG9mIGBhdXRoX3RpbWVgIGFsbG93cyBmb3IgdGhlCgogICAgICAgIGNhc2Ugd2hlcmUg YSB1c2VyIGlzIHJlcXVpcmVkIHRvIHNvbHZlIGFuIGFkZGl0aW9uYWwgY2hhbGxlbmdlLiBU YWtlIHRoZQoKICAgICAgICBjYXNlIG9mIGEgdXNlciB3aG8gaXMgcmVxdWlyZWQgdG8gcGFz cyBhIHNlY29uZGFyeSBjaGFsbGVuZ2UgYmVmb3JlIHRoZQoKICAgICAgICAic3RvY2sgcHVy Y2hhc2UiIGFjdGlvbiBjYW4gYmUgY29tcGxldGVkLiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgc3BlYwoKICAgICAgICBkZWZpbml0aW9uLCB0aGUgYGF1dGhfdGltZWAgdmFsdWUgTVVT VCBOT1QgYmUgdXBkYXRlZCB3aGVuIHRoaXMKCiAgICAgICAgc2Vjb25kYXJ5IGNoYWxsZW5n ZSBpcyBjb21wbGV0ZWQuCgoKCiAgICAgICAgIMOvwr/CvcOvwr/CvcOvwr/CvSBJIHRoaW5r IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlc3Npb25fc3RhcnRfdGltZSBhbmQg bGFzdAoKICAgICAgICBhdXRoX3RpbWUuIFRoaXMgZmVlbHMgbW9yZSBsaWtlIGl0J3MgZGVm aW5pbmcgdGhlIHNlc3Npb25fc3RhcnRfdGltZQoKICAgICAgICBjb25jZXB0LgoKCgogICAg ICAgICDDr8K/wr3Dr8K/wr0gVGhlc2Ugc2FtZSBpc3N1ZXMgY2FuIGFwcGx5IHRvIHRoZSBg YWNyYCBhbmQgYGFtcmAgdmFsdWVzIGFzIHdlbGwuCgoKCiAgICAgICAgIMOvwr/CvcOvwr/C vSBFdmVuIGlmIGZvciB0aGlzIHNlY29uZGFyeSBjaGFsbGVuZ2UgYSBuZXcgcmVmcmVzaF90 b2tlbiBpcyBpc3N1ZWQsCgogICAgICAgIGl0IGlzIHVubGlrZWx5IG1hbnkgcmVseWluZyBw YXJ0aWVzIHdpbGwgd2FudCB0byB0cmVhdCB0aGF0IGFzIGlzc3VpbmcgYQoKICAgICAgICBu ZXcgc2Vzc2lvbi4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgdXNlciBsb2dnZWQgaW4gdG8g YSBzaW5nbGUgc2Vzc2lvbi4KCgoKICAgICAgICBTZWN0aW9uIDIuMi4zIEF1dGhvcml6YXRp b24gQ2xhaW1zCgogICAgICAgICDDr8K/wr3Dr8K/wr0gSSBmaW5kIHRoZSBzdGF0ZW1lbnQg IkFsbCB0aGUgaW5kaXZpZHVhbCBzY29wZSBzdHJpbmdzIGluIHRoZSBzY29wZQoKICAgICAg ICBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBmb3IgdGhlIHJlc291cmNlIGluZGljYXRlZCBp biB0aGUgYXVkIGNsYWltIgoKICAgICAgICBzb21ld2hhdCBwcm9ibGVtYXRpYy4gSW4gbWFu eSBkZXBsb3ltZW50cyB0b2RheSBmb3IgMXN0IHBhcnR5IGNsaWVudHMgdG8KCiAgICAgICAg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0YWtpbmcgaW50byBhY2NvdW50IG1vYmls ZSBhcHBsaWNhdGlvbnMsCgogICAgICAgIHRoZSBhY2Nlc3MgdG9rZW4gbW9zdCBsaWtlIGNv bnRhaW5zIHNjb3BlcyBmb3IgbWFueSBvZiB0aGUgMXN0IHBhcnR5CgogICAgICAgIGJhY2tl bmQgQVBJcy4gSXQncyBwb3NzaWJsZSB0byBnZXQgYXJvdW5kIHRoaXMgYnkgc2V0dGluZyB0 aGUgJ2F1ZCcKCiAgICAgICAgY2xhaW0gdG8gc29tZXRoaW5nIGxpa2UgImNvbS5leGFtcGxl LmFwaXMiIGFuZCBoZW5jZSBhbGwgdGhlIGlzc3VlZAoKICAgICAgICBzY29wZXMgbWFwIHRv IHRoYXQgYXVkaWVuY2UgY2xhaW0gYnV0IHRoYXQgaXMganVzdCB3b3JraW5nIGFyb3VuZCB0 aGUKCiAgICAgICAgTVVTVCBpbiB0aGUgc3BlYy4gR2l2ZW4gdGhlIGxhY2sgb2Ygc3BlY2lm aWNpdHkgb2YgdGhlICdhdWQnIGNsYWltIGFuZAoKICAgICAgICB0aGUgJ3Jlc291cmNlIGlu ZGljYXRvcicgY2xhaW0gZm9yIHRoYXQgbWF0dGVyLCBwcmV0dHkgbXVjaCBhbnl0aGluZyBj YW4KCiAgICAgICAgYmUgbWFkZSB0byBjb21wbHkuIEluIHRoYXQgY29udGV4dCwgaXQgc2Vl bXMgbGlrZSBSRUNPTU1FTkQgaXMgYSBiZXR0ZXIKCiAgICAgICAgbm9ybWF0aXZlIGNsYXVz ZS4KCgoKICAgICAgICBTZWN0aW9uIDMuIFJlcXVlc3RpbmcgYSBKV1QgQWNjZXNzIFRva2Vu CgogICAgICAgICDDr8K/wr3Dr8K/wr0gUGVyIG15IGNvbW1lbnRzIGFib3ZlIEkgc3VzcGVj dCB0aGF0IHJlcXVpcmluZyBhbGwgSldUIGFjY2VzcyB0b2tlbnMKCiAgICAgICAgdG8gaW5j bHVkZSBhbiBhdWRpZW5jZSBjbGFpbSB3aWxsIGp1c3QgZGV2b2x2ZSB0byBhdWRpZW5jZSBj bGFpbXMgdGhhdAoKICAgICAgICBhcmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRlciB0 byBtZWV0IHRoaXMgTVVTVCBpbiB0aGUgc3BlYykuIEdpdmVuCgogICAgICAgIHRoZSBtb2Jp bGUgYXBwIGVudmlyb25tZW50IHRvZGF5LCBpdCBpcyB1bnJlYXNvbmFibGUgdG8gYXNrIHRo ZSBtb2JpbGUKCiAgICAgICAgYXBwcyB0byBkb3duc2NvcGUgZXZlcnkgYWNjZXNzIHRva2Vu IGJlZm9yZSBtYWtpbmcgYW4gQVBJIGNhbGwgdG8gdGhlCgogICAgICAgIGJhY2tlbmQgQVBJ cyB3aGljaCBpcyB3aGF0IHRoZSBzcGlyaXQgb2YgYXVkaWVuY2UgYW5kIHJlc291cmNlCgog ICAgICAgIGluZGljYXRvcnMgc2VlbSB0byBpbXBseS4KCgoKICAgICAgICAgw6/Cv8K9w6/C v8K9IFdoeSBNVVNUIHRoZSBBUyByZWplY3QgYSByZXF1ZXN0IHdpdGggbW9yZSB0aGFuIG9u ZSByZXNvdXJjZQoKICAgICAgICBwYXJhbWV0ZXI/IElmIGEgcmVxdWVzdCBjb21lcyBpbiB3 aXRoIG5vIHJlc291cmNlIHBhcmFtZXRlciBhbmQgbXVsdGlwbGUKCiAgICAgICAgc2NvcGVz IHRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gcmVqZWN0IHRoYXQgcmVxdWVzdC4gSXMgdGhl cmUgbXVjaCBvZiBhCgogICAgICAgIHNlbWFudGljIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg dHdvPyBJbiB0aGUgY2FzZSBvZiBubyByZXNvdXJjZQoKICAgICAgICBwYXJhbWV0ZXIgYW5k IG11bHRpcGxlIHNjb3BlcyB0aGUgQVMgbWlnaHQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdp dGgKCiAgICAgICAgbXVsdGlwbGUgYXVkaWVuY2UgdmFsdWVzIChhcyBpcyBhbGxvd2VkIGJ5 IFJGQyA3NTE5KS4gQWxzbywgdGhlIGF1ZGllbmNlCgogICAgICAgIGNsYWltIGlzIG5vdCBz b2xlbHkgZm9yIHJlc291cmNlIGluZGljYXRvciB2YWx1ZXMgYnV0IGlzIGRlZmluZWQgdG8g anVzdAoKICAgICAgICBiZSBhIHN0cmluZy4gVG8gbWUgaXQgZmVlbHMgbGlrZSB0aGUgdGV4 dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5CgogICAgICAgIHZhbGlkIGF1ZGllbmNlIHZh bHVlIGlzIGFsc28gYSByZXNvdXJjZSBpbmRpY2F0b3IgKHdoaWNoIGZyb20gcHJldmlvdXMK CiAgICAgICAgZGlzY3Vzc2lvbnMgb24gdGhlIGxpc3QgaXQgd2FzIGltcGxpZWQgdGhleSBo YXZlIGEgc2xpZ2h0bHkgZGlmZmVyZW50CgogICAgICAgIHNlbWFudGljKS4KCgoKICAgICAg ICAgw6/Cv8K9w6/Cv8K9IFRoZSBtb2RlbCBkZXNjcmliZWQgaGVyZSB3b3JrcyB3ZWxsIGlm IG15Y28uZXhhbXBsZSByZWFsbHkgb25seQoKICAgICAgICBwcm92aWRlcyBhIHNpbmdsZSBz ZXJ2aWNlLiBCdXQgaWYgaW5zdGVhZCBteWNvLmV4YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGUK CiAgICAgICAgc2VydmljZXMgZWFjaCB3aXRoIHRoZWlyIG93biBlbmRwb2ludHMgKHNydmEu bXljby5leGFtcGxlLAoKICAgICAgICBzcnZiLm15Y28uZXhhbXBsZSkgYW5kIHNjb3Blcywg Zm9yIG1lIHRoaXMgbW9kZWwgYmVnaW5zIHRvIGJyZWFrIGRvd24uCgogICAgICAgIEVpdGhl ciBtb2JpbGUgYXBwcyBhcmUgcmVxdWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tlbnMgdG8g anVzdCB0aGUKCiAgICAgICAgc2VydmljZSB0aGV5IGFyZSBjYWxsaW5nIGF0IHRoYXQgcG9p bnQgaW4gdGltZSAod2hpY2ggY2FuIGhhdmUgbGF0ZW5jeQoKICAgICAgICBhbmQgY29ubmVj dGl2aXR5IGlzc3VlcyksIG9yIG15Y28uZXhhbXBsZSBoYXMgdG8gY3JlYXRlIGEgZ2VuZXJp YwoKICAgICAgICAiYXVkaWVuY2UiIHN0cmluZyB0aGF0IHJlcHJlc2VudHMgYWxsIG9mIGV4 YW1wbGUuY29tIHdoaWNoIGRvZXNuJ3Qgc2VlbQoKICAgICAgICB0byBiZSB0aGUgc3Bpcml0 IG9mIHRoZSBleGlzdGluZyBzcGVjcy4KCgoKICAgICAgICAgw6/Cv8K9w6/Cv8K9IEluIHN1 bW1hcnksIEkgZmVlbCB0aGF0IHRoaXMgdGV4dCBpcyBiaW5kaW5nIHRvbyB0aWdodGx5IHJl c291cmNlCgogICAgICAgIGluZGljYXRvcnMgdG8gdGhlIGF1ZGllbmNlIGNsYWltLiBXaGF0 IGlzIGRlc2NyaWJlZCBpcyBwZXJmZWN0bHkKCiAgICAgICAgcmVhc29uYWJsZSBpbiBhIHVz ZSBjYXNlIHRoYXQgaXMgYXBwbHlpbmcgcmVzb3VyY2UgaW5kaWNhdG9ycyBpbiB0aGlzCgog ICAgICAgIHdheSBidXQgaXMgbm90IGluZGljYXRpdmUgb2YgdGhlIHdpZGVseSBkZXBsb3ll ZCBtb2RlbHMgdGhhdCBhbHJlYWR5IGV4aXN0LgoKCgogICAgICAgIFNlY3Rpb24gNC4gVmFs aWRhdGluZyBKV1QgQWNjZXNzIFRva2VucwoKICAgICAgICAgw6/Cv8K9w6/Cv8K9IFN0ZXAg NC4gLS0gQ2FuIHdlIGNoYW5nZSB0aGUgd29yZGluZyB0byBub3QgcmVxdWlyZSByZXNvdXJj ZQoKICAgICAgICBpbmRpY2F0b3JzPyBXaGF0IGFib3V0Li4uICJUaGUgcmVzb3VyY2Ugc2Vy dmVyIE1VU1QgdmFsaWRhdGUgdGhhdCB0aGUKCiAgICAgICAgJ2F1ZCcgY2xhaW0gY29udGFp bnMgYSBzdHJpbmcgdGhhdCByZXByZXNlbnRzIHRoZSBhdWRpZW5jZSBvZiB0aGlzCgogICAg ICAgIHJlc291cmNlIHNlcnZlci4iCgoKCiAgICAgICAgU2VjdGlvbiA1LiAiY3Jvc3MtSldU IGNvbmZ1c2lvbiIKCiAgICAgICAgIMOvwr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJlIG1heSBi ZSBjb25mdXNpb24gYXJvdW5kIHdoYXQgaXMgbWVhbnQgYnkgImRpc3RpbmN0CgogICAgICAg IHJlc291cmNlcyIuIEluIG15IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhhbXBs ZSBhbmQKCiAgICAgICAgc3J2Yi5teWNvLmV4YW1wbGUgImRpc3RpbmN0IHJlc291cmNlcyI/ IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8gc2F5IHRoYXQKCiAgICAgICAgd2Ugd2FudCBkaWZm ZXJlbnQgYXVkaWVuY2UgdmFsdWVzIGdlbmVyYXRlZCBmb3IgY3Jvc3Mtb3JnYW5pemF0aW9u CgogICAgICAgIHJlc291cmNlcy4gRm9yIGV4YW1wbGUsIGFyZSBtYWlsLmdvb2dsZS5jb20g YW5kIHlvdXR1YmUuY29tICJkaXN0aW5jdAoKICAgICAgICByZXNvdXJjZXMiPyBvciB3b3Vs ZCBhbiBhdWRpZW5jZSBmb3IgZ29vZ2xlIHN1ZmZpY2UgaW4gbWVldGluZyB0aGUKCiAgICAg ICAgbWVhbmluZyBvZiB0aGlzIHBhcmFncmFwaD8KCgoKICAgICAgICAgw6/Cv8K9IEknbSBo YXZpbmcgdGhlIHNhbWUgY29uZnVzaW9uIGluIHRoZSBuZXh0IHBhcmFncmFwaCByZWdhcmRp bmcgdGhlCgogICAgICAgIHBocmFzZSAiZGlmZmVyZW50IHJlc291cmNlcyIuIEFyZSBzZXJ2 aWNlcyBwcm92aWRlZCBieSB0aGUgc2FtZSBjb21wYW55CgogICAgICAgICJkaWZmZXJlbnQg cmVzb3VyY2VzIiBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2FtZSByZXNvdXJj ZS4gQ2FuCgogICAgICAgIGFuIGFjY2VzcyB0b2tlbiBiZSBpc3N1ZWQgd2l0aCBzY29wZXMg Zm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZAoKICAgICAgICB5b3V0dWJlLmNvbT8gQW5k IGlmIG5vdCwgd2h5IG5vdGU/IFByZXZlbnRpbmcgdGhpcyBwdXRzIHVuZHVlIGJ1cmRlbiBv bgoKICAgICAgICBtb2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLgoKCgogICAgICAgIFNlY3Rp b24gNi4gUHJpdmFjeQoKICAgICAgICAgw6/Cv8K9w6/Cv8K9IGNvZmlkZW50aWFsaXR5IC0t Jmd0OyBjb25maWRlbnRpYWxpdHkKCgoKCgogICAgICAgIFRoYW5rcywKCiAgICAgICAgR2Vv cmdlCgoKCgoKCgoKCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKICAgIE9BdXRoIG1haWxpbmcgbGlzdAoKICAgIDxhIGNsYXNzPSJtb3ot dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+CgogICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4KCgoKCjwvcHJl PgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogIDwvYm9keT4KPC9odG1sPgo= --------------D59CAA69AA4F0F567A42747A-- From nobody Fri Apr 3 13:39:21 2020 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 EAF443A0A1A for ; Fri, 3 Apr 2020 13:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 WFcBZPuMR8LD for ; Fri, 3 Apr 2020 13:39:13 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 A25903A0A11 for ; Fri, 3 Apr 2020 13:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1585946354; x=1617482354; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=3UwJ3IYIMBbPeajKN7NFlxZjbRb/DpCv2QaZlVoGrUA=; b=OGVmJHCA5sXVrCQn7CyvY7K03KUXKge7TfC8+ssp3mD999bttYvL7bd5 PrQWvD0F4lbKou/bPDt7RS1OFCgcBu71jEaou3kYB7Rt+fkn+RAn1bfAx 50+79YrEnyCWoxLoCFv5YHD0N8LMZWIQ3Z2vHBYLtfmkfzgshTspOldL+ o=; IronPort-SDR: K6i6KCKiPN1sLUqz8zq6nLvfFyTIY7rSsQTTv/xUnXZAlD2p28hgbEzUF9tAylSiVrKK7edW8S gnnVxlvfQA7w== X-IronPort-AV: E=Sophos; i="5.72,341,1580774400"; d="scan'208,217"; a="24442957" Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 03 Apr 2020 20:38:59 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (Postfix) with ESMTPS id 39D51A2E83; Fri, 3 Apr 2020 20:38:55 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 Apr 2020 20:38:55 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 20:38:54 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Fri, 3 Apr 2020 20:38:54 +0000 From: "Richard Backman, Annabelle" To: George Fletcher , Vittorio Bertocci , Vittorio Bertocci , Hannes Tschofenig , oauth , Vittorio Bertocci Thread-Index: AdYBWCr2leQdkb8yTTietiBUObuaNAAqwu8AAAoilwD//6OxgIAPMjYAgAC9YwD//4+jAA== Date: Fri, 3 Apr 2020 20:38:54 +0000 Message-ID: <897809C2-5ABB-43A4-9965-0950EC7126F5@amazon.com> References: <760BA08D-CB52-440D-9CDB-699BEE306A31@amazon.com> <24a1db50-c31e-051f-3ec6-ebe3cca1cc16@aol.com> In-Reply-To: <24a1db50-c31e-051f-3ec6-ebe3cca1cc16@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.147] Content-Type: multipart/alternative; boundary="_000_897809C25ABB43A499650950EC7126F5amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 03 Apr 2020 20:39:19 -0000 --_000_897809C25ABB43A499650950EC7126F5amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzdXBwb3J0IHJlbGF4aW5nIHRoZSBsYW5ndWFnZSB0aGF0IGNsZWFybHkgdGFyZ2V0 cyB0aGUgaXNzdWUg4oCTIGF1dGhvcml6YXRpb24gY29uZnVzaW9uIOKAkyBzdWNoIGFzOg0KDQpU aGUgQVMgTVVTVCBOT1QgaXNzdWUgYSBKV1QgYWNjZXNzIHRva2VuIGlmIHRoZSBhdXRob3JpemF0 aW9uIGdyYW50ZWQgYnkgdGhlIHRva2VuIHdvdWxkIGJlIGFtYmlndW91cy4NCg0KVGhlIGN1cnJl bnQgZHJhZnQgbGFuZ3VhZ2UgYmFzaWNhbGx5IHRha2VzIGEgaGV1cmlzdGljIGFwcHJvYWNoIHRv IHRoaXMsIHByb2hpYml0aW5nIGNlcnRhaW4gcGF0dGVybnMgdGhhdCBtaWdodCBsZWFkIHRvIHRo aXMgc2NlbmFyaW8uIElmIHdlIHRhcmdldCB0aGUgaXNzdWUgZGlyZWN0bHkgYW5kIHByb3ZpZGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGV4dCBlbGFib3JhdGluZyBvbiBzb21lIG9mIHRoZSB3 YXlzIHRoaXMgY2FuIG9jY3VyLCB3ZSBhbGxvdyBkZXBsb3ltZW50cyB0byBkZXRlcm1pbmUgd2hl dGhlciBvciBub3QgaXQgYXBwbGllcyBpbiB0aGVpciBjb250ZXh0Lg0KDQpXZSBjYW7igJl0IGZp eCB0aGUgZmFjdCB0aGF0IHNjb3BlcyBhcmUgYW1iaWd1b3VzIGFuZCBlbnRpcmVseSBpbXBsZW1l bnRhdGlvbiBzcGVjaWZpYy4gVGhhdCBob3JzZSBsZWZ0IHRoZSBiYXJuIHdpdGggNjc0OS4gSWYg d2UgdHJ5IHRvIGFkZHJlc3MgdGhpcyBieSBpbnRyb2R1Y2luZyBuZXcgbGltaXRhdGlvbnMgb24g c2NvcGVzIHdpdGhpbiBzcGVjcyBsaWtlIHRoaXMgb25lLCB3ZeKAmXJlIGdvaW5nIHRvIGVuZCB1 cCB3aXRoIGVhY2ggbmV3IHNwZWMgaW1wb3NpbmcgaXRzIG93biByZXN0cmljdGlvbnMsIHdoaWNo IHdpbGwgYXJ0aWZpY2lhbGx5IGxpbWl0IHRoZSBzcGVj4oCZcyB1dGlsaXR5IGFuZCBtYXkgaW50 cm9kdWNlIGluY29tcGF0aWJpbGl0aWVzIGJldHdlZW4gc3BlY3MgZHVlIHRvIGluY29uc2lzdGVu dCByZXN0cmljdGlvbnMuIERldmVsb3BlcnMgd2lsbCBiZSBsZWZ0IHRvIHRyeSB0byBwaWVjZSBp dCBhbGwgdG9nZXRoZXIgdG8gZmlndXJlIG91dCBpZiB0aGVpciB1c2UgY2FzZSBpcyBwZXJtaXR0 ZWQuDQoNClRoZSB3YXkgd2UgZGlnIG91cnNlbHZlcyBvdXQgb2YgdGhpcyBob2xlIGlzIHRocm91 Z2ggUmljaCBBdXRob3JpemF0aW9uIFJlcXVlc3RzLiBUaGF0IGRyYWZ0IGlzIG91ciBvcHBvcnR1 bml0eSB0byBnZXQgdGhpcyByaWdodCwgdmlhIOKAnGEgbG90IG1vcmUgc3BlYyB3b3Jr4oCdIGFz IEdlb3JnZSBwdXQgaXQuIEluY2lkZW50YWxseSwgaWYgd2UgdGhpbmsgYWJvdXQgUkFSIGluIHRo ZSBjb250ZXh0IG9mIEpXVCBhY2Nlc3MgdG9rZW5zLCBpdOKAmXMgaW1tZWRpYXRlbHkgb2J2aW91 cyB3aHkgYSBtdWx0aS12YWx1ZSBhdWQgY2xhaW0gbmVlZHMgdG8gYmUgYWxsb3dlZC4gSWYgbXkg dG9rZW4gY29udGFpbnMgYW4g4oCcYXV0aG9yaXphdGlvbuKAnSBjbGFpbSBjb250YWluaW5nIGEg UkFSIG9iamVjdCB0aGF0IGdyYW50cyBmaW5lLWdyYWluZWQgYXV0aG9yaXphdGlvbiBvbiBkaWZm ZXJlbnQgcmVzb3VyY2VzIGFjcm9zcyBkaWZmZXJlbnQgZW5kcG9pbnRzLCBteSBhdWQgdmFsdWUg c2hvdWxkIGJlIGFibGUgdG8gbWF0Y2ggdGhhdC4gSXTigJlkIGJlIHNpbGx5IHRvIGhhdmUgdG8g aGF2ZSBhbiBhdWQgY2xhaW0gb2Yg4oCcYXBpLmFwcC5leGFtcGxl4oCdIGlmIG15IGF1dGhvcml6 YXRpb24gaXMgdGlnaHRseSBib3VuZCB0byDigJxlbWFpbC5hcHAuZXhhbXBsZeKAnSBhbmQg4oCc Y29udGFjdHMuYXBwLmV4YW1wbGXigJ0gdGhyb3VnaCBSQVIuDQoNCuKAkw0KQW5uYWJlbGxlIEJh Y2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRl bnRpdHkvDQoNCg0KRnJvbTogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPg0KT3Jn YW5pemF0aW9uOiBBT0wgTExDDQpEYXRlOiBGcmlkYXksIEFwcmlsIDMsIDIwMjAgYXQgMToyMiBQ TQ0KVG86IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+LCAi UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPiwgVml0dG9y aW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3Jn PiwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+LCBvYXV0aCA8 b2F1dGhAaWV0Zi5vcmc+LCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0aDAuY29tPg0K U3ViamVjdDogUkU6IFtFWFRFUk5BTF0gW09BVVRILVdHXSBXR0xDIG9uICJKU09OIFdlYiBUb2tl biAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyINCg0KDQpDQVVUSU9O OiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24u IERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgY2FuIGNv bmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoNClRoYW5r cyBWaXR0b3JpbyBmb3IgdGhlIHRob3JvdWdoIHJlc3BvbnNlIQ0KDQpJIGFncmVlIHRoYXQgaG93 IHNjb3BlcyBhcmUgaGFuZGxlZCBpcyB2ZXJ5IGRpZmZlcmVudCBhY3Jvc3MgZGVwbG95bWVudHMu IFNjb3BlcyB1c2VkIGZvciBhbiBSUCB3aXRoIGEgbW9iaWxlIGFwcCAoZS5nLiBzb21ldGhpbmcg bGlrZSBPcGVuVGFibGUpIGFyZSBnb2luZyB0byBiZSB2ZXJ5IGRpZmZlcmVudCB0aGFuIGEgbXVs dGktdGVuYW50IGVudGVycHJpc2Ugc3lzdGVtIHdpdGggZml4ZWQgc2VydmljZXMgYW5kIHJvbGVz IHRoYXQgYWxsIHRlbmFudHMgbXVjaCB1c2UuIEknbSBub3Qgc3VyZSBpdCBpcyBwb3NzaWJsZSB0 byBjbGVhcmx5IG1hcCB0aGlzIGRpc3BhcmF0ZSBzZXQgb2YgZGVwbG95bWVudHMgaW50byBhIGNv bW1vbiBzZXQgb2Ygc3BlYyBsYW5ndWFnZS4gSXQncyBwb3NzaWJsZSB0byBkZWZpbmUgYSBzb2x1 dGlvbiB0aGF0IGlzIG1heWJlICJtYWpvcml0eSIgYnV0IGFueW9uZSB3YW50aW5nIHRvIGNvbmZv cm0gd2l0aCBhIGRpZmZlcmVudCBkZXBsb3ltZW50IHN0cmF0ZWd5IHdpbGwganVzdCAibXVuZ2Ui IHRoZSAnYXVkJyB2YWx1ZSB0byBtYWtlIHRoZWlyIGRlcGxveW1lbnQgd29yay4gSSdtIG5vdCBz dXJlIHRoYXQgYWRkcyBhIGxvdCBvZiB2YWx1ZS4gSSB0aGluayBJIHdvdWxkIHByZWZlciBhIG11 bHRpLXZhbHVlZCAnYXVkJyBjbGFpbSBvZiAibWFpbC5leGFtcGxlLCBjb250YWN0cy5leGFtcGxl LCBuZXdzLmV4YW1wbGUiIG92ZXIgYSBnZW5lcmljICJhcGkuZXhhbXBsZSIuIFRoZSBmb3JtZXIg cHJvdmlkZXMgdmFsdWUgdG8gbGltaXQgdGhlIHNjb3BlIG9mIHRoZSB0b2tlbiB3aGVyZSB0aGUg bGF0dGVyIGRvZXMgbm90Lg0KDQpJIGFncmVlIHRoYXQgc2NvcGVzIHdlcmUgbm90IHdlbGwgc3Bl Y2lmaWVkIGluIDY3NDkvNjc1MCBhbmQgbm93IGl0J3MgYSBiaXQgb2YgdGhlIHdpbGQgd2VzdC4g U29tZSB0cmVhdCBzY29wZXMgYXMgY2FwYWJpbGl0aWVzLCBzb21lIHRyZWF0IHRoZW0gYXMgcm9s ZXMsIHNvbWUgYXMgYXR0cmlidXRlcywgc29tZSBhcyBmbGFncyBmb3Igc3BlY2lmaWMgdG9rZW4g YmVoYXZpb3IgYW5kIHRoZSBsaXN0IGdvZXMgb246KQ0KDQpQZXJzb25hbGx5LCBJJ2QgcHJlZmVy IHVzaW5nIFJFQ09NTUVOREVEIGZvciB0aGUgY3VycmVudCBkZWZpbmVkIHNwZWMgbGFuZ3VhZ2Ug d2l0aG91dCBtYWtpbmcgdGhhdCBtb2RlbCByZXF1aXJlZC4NCg0KSWYgd2UgdHJ1bHkgd2FudCBp bnRlcm9wZXJhYmxlIGFjY2Vzc190b2tlbnMgY3Jvc3MgSURQcywgdGhlbiBJIHRoaW5rIHdlIGhh dmUgYSBsb3QgbW9yZSBzcGVjIHdvcmsgdG8gZG8gdGhhbiBkZXNjcmliaW5nIHRoZSB0b2tlbiBm b3JtYXQuIFRoaXMgaXMgYSBpbXBvcnRhbnQgYW5kIG5lY2Vzc2FyeSBidWlsZGluZyBibG9jaywg YnV0IGJlaGF2aW9ycyBhbmQgaG93IHRoZXkgbWFwIG1heSBiZSBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIHdvcmsuDQoNClRoYW5rcywNCkdlb3JnZQ0KT24gNC8zLzIwIDU6MDMgQU0sIFZpdHRv cmlvIEJlcnRvY2NpIHdyb3RlOg0KDQpUaGFua3MgQW5uYWJlbGxlIGFuZCBHZW9yZ2UhICBJIGFt IGNvbnNvbGlkYXRpbmcgcmVwbGllcyB0byBib3RoIHlvdXIgbGF0ZXN0IGNvbW1lbnRzIGluIHRo aXMgbWFpbC4gVGhpcyBzZWVtcyBhIGhhcmQgcm9jayB0byBsaWZ0LCBidXQgaXQgYWxzbyBzZWVt cyB0byBiZSB0aGUgbGFzdCBvbmUg8J+Yii4NCg0KDQoNClRoZSBUTDtEUiBpcywgSSBhbSBub3Qg Y29tcGxldGVseSBvcHBvc2VkIHRvIHJlbGF4aW5nIHRoZSBjb25zdHJhaW50cyBhbmQgdHVybmlu ZyB0aGVtIGludG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIGJ1dCBJIHRoaW5rIHdl4oCZZCBt aXNzIGFuIG9wcG9ydHVuaXR5IHRvIG1ha2UgdGhpbmdzIGNsZWFyZXIgZm9yIGRldmVsb3BlcnMu IEF0IHRoZSBzYW1lIHRpbWUgSSB3b3VsZG7igJl0IHdhbnQgdG8gbWFrZSB0aGlzIHByb2ZpbGUg dG9vIHBhdHJvbml6aW5nLCBoZW5jZSBJIGFwcHJlY2lhdGUgdGhlIG9wcG9ydHVuaXR5IHRvIGRp c2N1c3MuDQoNCg0KDQoNCg0KDQoNCltBbm5hYmVsbGVdDQoNCg0KDQogID4uIFRoZXJlIG1heSBi ZSBubyAic2NvcGUiIHBhcmFtZXRlci4gIFRoZSAic2NvcGUiIHBhcmFtZXRlciBpcyBPUFRJT05B TCBpbiBhdXRob3JpemF0aW9uIHJlcXVlc3RzLiBTbyBhbiBBUy9SUyBvcGVyYXRvciBjb3VsZCBk ZWNpZGUgdGhleSdyZSBnb2luZyB0byBvbWl0ICJzY29wZSIgZW50aXJlbHkgYW5kIHVzZSBtdWx0 aXBsZSByZXNvdXJjZSBwYXJhbWV0ZXJzIGluc3RlYWQuIFNpbmNlIHRoZXJlIGFyZSBubyBzY29w ZXMsIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciBjb25mdXNpb24uDQoNCg0KDQpJIGFtIGEg QklHIGZhbiBvZiBBVHMgd2l0aCBubyBzY29wZS0gYWxsIHRoZSBzY2VuYXJpb3Mgd2hlcmUgdGhl cmXigJlzIG5vIGRlbGVnYXRpb24gKDFzdCBwYXJ0aWVzIGV0Yykgc2hvdWxkbuKAmXQgdXNlIHNj b3BlcyBhdCBhbGwuIFRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGRvZXMgYWxs b3cgZm9yIHNjb3BlLWxlc3MgQVRzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZ29hbCBpcyB0byBwcmV2 ZW50IGNvbmZ1c2lvbiwgSSBhZ3JlZSB0aGF0IHRoZXJl4oCZcyBubyBuZWVkIHRvIHJlc3RyaWN0 IHRoZSBhdWRpZW5jZSB0byBvbmUgc2luZ2xlIHJlc291cmNlIGlmIHRoZXJlIGFyZSBubyBzY29w ZXMgYXQgYWxsIHRvIG1pc2ludGVycHJldC4NCg0KDQoNCkkgd291bGQgYmUgaW4gZmF2b3IgdG8g YWxsb3cgbXVsdGlwbGUgcmVzb3VyY2VzIGluIGF1ZGllbmNlIGluIHRoYXQgY2FzZS4NCg0KDQoN ClVuZm9ydHVuYXRlbHkgaXTigJlzIG5vdCBhcyBzaW1wbGUgYXMganVzdCBzYXlpbmcg4oCcSWYg dGhlIGluY29taW5nIHJlcXVlc3QgaW5jdWRlcyBtdWx0aXBsZSByZXNvdXJjZSBpbmRpY2F0b3Jz IGFuZCBubyBzY29wZSwgYWNjZXB0IGl0IGFuZCB1c2UgdGhlIGluY29taW5nIHJlc291cmNlIGlu ZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXigJ0g4oCTIG1vc3RseSBiZWNhdXNlIHRoZXJlIGlz IGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgcHJvZHVjdGlvbiBzeXN0ZW1zIHdoZXJlIHRoZSByZXF1 ZXN0IGluY2x1ZGVzIG5vIHNjb3BlcyBhbmQgb25lIHJlc291cmNlIGluZGljYXRvciwgYnV0IHRo ZSByZXN1bHRpbmcgdG9rZW4gaW5jbHVkZXMgYSBjb2xsZWN0aW9uIG9mIHNjb3BlcyB0aGUgdXNl ciBhbHJlYWR5IGNvbnNlbnRlZCB0byBmb3IgdGhhdCByZXNvdXJjZS0gYnV0IEkgYW0gc3VyZSB3 ZSBjYW4gZ2V0IHRvIGFjY2VwdGFibGUgbGFuZ3VhZ2UgdGhhdCBleHByZXNzZXMgdGhlIGNvbmNl cHQg4oCcaWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlc291cmNlIGluZGljYXRvcnMgaW4gdGhlIHJl cXVlc3QgYW5kIHRoZSByZXN0IG9mIHRoZSBydWxlcyBpbiBTLjMgdGhlIHJlc3VsdGluZyBBVCB3 b27igJl0IGNvbnRhaW4gYSBzY29wZSBjbGFpbSwgdGhlIHJlc3VsdGluZyBBVCBtdXN0IHVzZSB0 aGF0IHJlc291cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXigJ0uDQoNCg0KDQoNCg0K DQoNCkFuIEFTL1JTIG9wZXJhdG9yIG1heSB1c2UgInNjb3BlIiB0byBpbmRpY2F0ZSBhIHJvbGUg b3IgcG9saWN5IChvciBzZXQgb2YgcG9saWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3YW50cywgYW5k IGFsbG93IHRoZSBjbGllbnQgdG8gbmFycm93IHRoZWlyIHBlcm1pc3Npb25zIHVzaW5nICJyZXNv dXJjZSIgcGFyYW1ldGVycy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG9idGFpbiBu YXJyb3dseSBzY29wZWQgYWNjZXNzIHRva2VucyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpdGhv dXQgbmVlZGluZyB0byBkZWZpbmUgc2VwYXJhdGUgcm9sZXMvcG9saWNpZXMgZm9yIGVhY2guIElu IHRoaXMgY2FzZSwgYSBKV1QgQVQgd2l0aCBhIG11bHRpLXZhbHVlZCAiYXVkIiBjbGFpbSBhbmQg YSAic2NvcGUiIGNsYWltIHdvdWxkIHNlZW0gYXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFp bSBpcyBpbnRlbmRlZCB0byBhcHBseSB0byBhbGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy4NCg0K SSBhZ3JlZSB0aGF0IGRlcGxveW1lbnRzIGxpa2UgdGhlIG9uZSB5b3UgZGVzY3JpYmUgbWlnaHQg ZXhpc3QsIGluIGZhY3QgSSBhbSBzdXJlIHRoZXkgZG8uIEhvd2V2ZXIgaXQgc2VlbXMgcmVhbGx5 IGEgYnJpdHRsZSBhcHByb2FjaCwgZ2l2ZW4gdGhhdCBpdCBtYWtlcyBhIHNwZWNpZmljIGFzc3Vt cHRpb24gKHNjb3BlcyBhcmUgdmFsaWQgYWNyb3NzIGFsbCB0aGUgcmVzb3VyY2VzKSB0aGF0IGlz buKAmXQgZW5zaHJpbmVkIGFueXdoZXJlIGFuZCBpZiBmdXR1cmUgdXBkYXRlcyB0byB0aGF0IGRl cGxveW1lbnQgdmlvbGF0ZSB0aGF0IGFzc3VtcHRpb24sIHRoYXQgd291bGQgbGVhZCB0byB0aGUg c2NvcGUgY29uZnVzaW9uIHRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGlzIHRy eWluZyB0byBwcmV2ZW50LiBXZSBvZmZlciB2ZXJ5IGxpdHRsZSBndWlkYW5jZSBpbiB0aGF0IHJl c3BlY3Q6IHRoZSBtYWluIHBsYWNlIHdlcmUgbXVsdGlwbGUgcmVzb3VyY2VzIGFyZSBldmVuIG1l bnRpb25lZCBpcyByZXNvdXJjZSBpbmRpY2F0b3JzLCBhbmQgYWxsIHRoZSBzYW1wbGVzIChJIGtu b3csIG5vbi1ub3JtYXRpdmUpIHVzZSBzY29wZXMgdW5hbWJpZ3VvdXNseSB0aWVkIHRvIGEgc3Bl Y2lmaWMgcmVzb3VyY2UgKG1vcmUgb24gdGhhdCBsYXRlcikgbWFraW5nIHRoZSBtdWx0aS1yZXNv dXJjZSBzY29wZSBldmVuIG1vcmUgb2YgYSBzcGVjaWFsIGNhc2UuDQoNCg0KDQoNCg0KDQoNClN0 ZXBwaW5nIGJhY2sgYSBiaXQgLSB0aGUgaW50ZW50IGJlaGluZCB0aG9zZSByZXNvdXJjZS1zY29w ZSByZXN0cmljdGlvbnMgaXMgdG8gcHJvdmlkZSBhIGJpdCBtb3JlIGd1aWRhbmNlIG9uIHNjb3Bl cyBhbmQgcmVzb3VyY2VzIHRoYW4gd2UgZGlkIGluIHRoZSBwYXN0LCBhbmQgbmFycm93aW5nIHRo ZSByYW5nZSBvZiBjYXNlcyBkZXZlbG9wZXJzIHdvdWxkIG5lZWQgdG8gdGFrZSBpbnRvIGFjY291 bnQgd2hlbiBpbXBsZW1lbnRpbmcgdGhlIHByb2ZpbGUuDQoNCg0KDQpJbiBteSBleHBlcmllbmNl IHRoZSBsYWNrIG9mIG1vcmUgcHJlc2NyaXB0aXZlIGd1aWRhbmNlIGxlZCB0byBkZXBsb3ltZW50 cyBhbmQgaW50ZXJwcmV0YXRpb25zIHRoYXQsIHdoaWxlIHJlbWFpbmluZyBmdWxseSB3aXRoaW4g dGhlIGJvdW5kYXJ5IG9mIHdoYXQgdGhlIHNwZWMgYWxsb3dzLCBhcmUgb2Z0ZW4gcXVlc3Rpb25h YmxlIGZyb20gdGhlIHNlY3VyaXR5IGFuZCBhcmNoIHBlcnNwZWN0aXZlLg0KDQoNCg0KKCopSSBh Y2tub3dsZWRnZSB0aGF0IEkgbWlnaHQgYmUgc3dpbmdpbmcgdG9vIGZhciBpbiB0aGUgb3Bwb3Np dGUgZGlyZWN0aW9uLCBhbmQgcGVyaGFwcyBhIHNpbWlsYXIgZWZmZWN0IGNvdWxkIGJlIGFjaGll dmVkIGJ5IGFkZGluZyBhbiDigJxBdXRob3JpemF0aW9uIENvbnNpZGVyYXRpb25z4oCdIHNlY3Rp b24gd2hlcmUgaW1wbGVtZW50ZXJzIGFyZSB3YXJuZWQgYWJvdXQgdGhlIGRhbmdlciBvZiBzY29w ZSBjb25mdXNpb24gcmF0aGVyIHRoYW4gZG93bnJpZ2h0IGZvcmJpZGRpbmcgbXVsdGkgcmVzb3Vy Y2VzIGF1ZGllbmNlcyB3aGVuIGluY2x1ZGluZyBzY29wZXMgYXMgd2VsbC4gSSBzdGlsbCBsaWtl IHRoZSBzaW1wbGljaXR5IGFuZCBjbGFyaXR5IG9mIHRoZSBjdXJyZW50IHJlc3RyaWN0aW9uLCBi dXQgb2YgY291cnNlIEkgYW0gb3BlbiB0byBmZWVkYmFjay4NCg0KDQoNCg0KDQoNCg0KVGhlIG1h cHBpbmcgYmV0d2VlbiBhdWRpZW5jZSBhbmQgc2NvcGUgbWF5IGJlIHVuYW1iaWd1b3VzLiBUaGVy ZSBhcmUgYSBsb3Qgb2YgZGVwbG95bWVudHMgdG8gd2hpY2ggdGhlIGJsYXN0IHJhZGl1cyByaXNr IHlvdSdyZSB0cnlpbmcgdG8gYWRkcmVzcyBieSByZXF1aXJpbmcgImF1ZCIgc2ltcGx5IGRvZXMg bm90IGFwcGx5DQoNClRoZXJlIGFyZSBjZXJ0YWlubHkgY2FzZXMgd2hlcmUgc2NvcGUgc3RyaW5n cyB1bmFtYmlndW91c2x5IG1hcCB0byBzcGVjaWZpYyByZXNvdXJjZXMsIGJ1dCBvbmNlIGFnYWlu LCB0aGF04oCZcyBhIHN0cm9uZyBhc3N1bXB0aW9uIHRvIG1ha2UgYW5kIG9uZSBJIGZlZWwgY2Fu bm90IGJlIG1hZGUgbGlnaHRseS4gUmVzb3VyY2UgaW5kaWNhdG9ycyB1c2UgdmVyeSBzaW1wbGUg ZXhhbXBsZXMgKGNvbnRhY3RzLCBjYWxlbmRhcikgdGhhdCBhcmUgaGFyZCB0byBnZW5lcmFsaXpl IHRvIHNjZW5hcmlvcyB3aGVyZSB0aGUgbnVtYmVyIGFuZCBsaWZlY3ljbGUgb2YgcmVzb3VyY2Vz IHRydWx5IGNhbGxzIGZvciB0aGUgdXNlIG9mIGluZGljYXRvcnMgaWRlbnRpZnlpbmcgYSByZXNv dXJjZSBpbiBhIGxhcmdlIG11bHRpdGVuYW50IHN5c3RlbSB1c3VhbGx5IGVudGFpbHMgbGFyZ2Ug aWRlbnRpZmllcnMsIGFuZCBzdHVmZmluZyB0aG9zZSBpbiB0aGUgc2NvcGUgdG8gcHJldmVudCBh bWJpZ3VpdHkgY2FuIGJlIGV4cGVuc2l2ZSBmcm9tIGJvdGggcHJvdmlzaW9uaW5nIGFuZCB0b2tl biwgcmVxdWVzdCBzaXplIGFuZ2xlcy4NCg0KDQoNCg0KDQoNCg0KSXQgbWF5IHNlZW0gaW5ub2N1 b3VzIHRvIHJlcXVpcmUgdGhlc2UgZGVwbG95bWVudHMgdG8gZXhwbGljaXRseSBpbmNsdWRlIGEg YnJvYWQgYXVkaWVuY2UgbGlrZSAiYXBpLmV4YW1wbGUuY29tIiBhbnl3YXksIHRoYXQgY2FuIGxl YWQgdG8gaW1wbGVtZW50ZXJzIGlnbm9yaW5nIHRoZSByZXF1aXJlbWVudCAobGVhZGluZyB0byBp bnRlcm9wIGlzc3VlcyksIG5vdCB2YWxpZGF0aW5nIGl0IChhbHNvIGxlYWRpbmcgdG8gaW50ZXJv cCBpc3N1ZXMgb3Igc2VjdXJpdHkgaXNzdWVzIGlmIHRoZSBkZXBsb3ltZW50IHdhbnRzIHRvIHN0 YXJ0IGFjdHVhbGx5IHVzaW5nIGl0IGZvciByZWFsKSwgb3IgZG9pbmcgc29tZXRoaW5nIGZ1bmt5 IHdpdGggaXQgc2luY2UgdGhlcmUgaXNuJ3QgYW55dGhpbmcgInJlYWwiIHRoYXQgdGhlIHZhbHVl IG5lZWRzIHRvIGNvbmZvcm0gdG8uDQoNCkV2ZXJ5IHNwZWMgZ3VpZGFuY2Ugcmlza3Mgbm90IGJl aW5nIGZvbGxvd2VkLiBCdXQgaW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHVzZSBvZiBhIGxvZ2lj YWwgYXVkaWVuY2UgaXMgcXVpdGUgbWFpbnN0cmVhbSDigJMgd2UgaGFkIGEgc2ltaWxhciBkaXNj dXNzaW9uIGZvciByZXNvdXJjZSBpbmRpY2F0b3JzIGFuZCB0aGF04oCZcyB3aHkgdGhlIHNwZWMg ZW5kZWQgdXAgaW5jbHVkaW5nIGxvZ2ljYWwgaWRlbnRpZmllcnMgYXMgb25lIG9mIHRoZSByZXNv dXJjZSBwYXJhbWV0ZXIgZmxhdm9yLiDigJxyZWFs4oCdIGlzIGEgcmVsYXRpdmUgdGVybSwgZ2l2 ZW4gdGhhdCB0aGVyZSBhcmUgYWxyZWFkeSBtYW55IGRpZmZlcmVudCB3YXlzIGluIHdoaWNoIGEg bG9naWNhbCByZXNvdXJjZSBtaWdodCBtYXAgdG8gZGlmZmVyZW50IOKAnHBoeXNpY2Fs4oCdIGFy dGlmYWN0cyAoc2VlIGhlcm9rdeKAmXMgbGF0ZSBiaW5kaW5nIFVSTHMpLiBDb2xsZWN0aXZlIGF1 ZGllbmNlcyBhcmUgaW4gY29tbW9uIHVzZSBmb3IgcG9vciBtYW7igJlzIHRydXN0ZWQgc3Vic3lz dGVtczogbm90IGVuZG9yc2luZyB0aGUgYXBwcm9hY2gsIGJ1dCBicmluZ2luZyBjaXJjdW1zdGFu dGlhbCBldmlkZW5jZSB0aGF0IGJyb2FkIGF1ZGllbmNlcyBhcmVu4oCZdCB0aGF0IHVuY29tbW9u IG9yIGhhcmQgdG8gZ3JvayBmb3IgZGV2ZWxvcGVycyBhbHJlYWR5IHRvZGF5LiBGaW5hbGx5LCB0 dXJuaW5nIG9mZiB2YWxpZGF0aW9uIGlzIGFjdHVhbGx5IG5vdCB0aGF0IHRyaXZpYWwgaW4gbWFu eSBTREtzLCBnaXZlbiB0aGF0IHRoZXkgbW9zdGx5IHJldXNlL2Rlcml2ZSBmcm9tIE9JREMgYW5k IHRoZSBhdWRpZW5jZSBjaGVjayBpcyBtYW5kYXRvcnk6IEkgc2F3IG1vcmUgb2Z0ZW4gcGVvcGxl IGRpc2FibGluZyBpc3MgY2hlY2sgdGhhbiBhdWQuIE5vbmUgb2YgdGhpcyBtZWFucyB0aGF0IHRo ZSBlcnJvcnMgeW91IGRlc2NyaWJlIGNhbm5vdCBoYXBwZW46IGJ1dCBJIHRoaW5rIHRoZXkgYXJl buKAmXQgbW9yZSBsaWtlbHkgdGhhbiBhbnkgb3RoZXIgZ3VpZGFuY2UgaW4gdGhlIHNwZWMuDQoN Cg0KDQpJIGRvIGFjayB0aGUgbW9yZSBnZW5lcmljIHBvaW50IHRoYXQsIGxpa2UgaW4gdGhlIHBy ZWNlZGluZyBjYXNlLCB0aGlzIG1pZ2h0IHN1Z2dlc3QgdGhhdCB0aGUgY3VycmVudCBndWlkYW5j ZSBpcyB0b28gc3RyaWN0LSBzZWUgKCopDQoNCg0KDQoNCg0KDQoNCltHZW9yZ2VdDQoNCg0KDQpJ IHRoaW5rIG9uZSBvZiB0aGUgcHJvYmxlbXMgd2UgaGF2ZSBpbiBiZWluZyBzdXBlciBzcGVjaWZp YyBhYm91dCBob3cgdGhlIEpXVCBhY2Nlc3MgdG9rZW4gaXMgY29uc3RydWN0ZWQgaXMgdGhhdCBp cyBtZWFucyBpdCdzIG5vdCBwb3NzaWJsZSBmb3IgbWFueSBvcmdhbml6YXRpb25zIHRvIGZvbGxv dy4gSG93IHNjb3BlcyBhcmUgaW1wbGVtZW50ZWQgaXMgdmVyeSB2YXJpZWQgYWNyb3NzIGRlcGxv eW1lbnRzIHdoaWNoIG1lYW5zIHRoYXQgc29tZSBtYXkgY29uZm9ybSB0byB0aGUgcGVyc3BlY3Rp dmUgb2YgdGhlIHNwZWMgYW5kIG1hbnkgbWF5IG5vdC4NCg0KWW91IGFyZSByaWdodCwgdGhlIHNw ZWMgIGlzIGFuIG9waW5pb25hdGVkIHRha2UtIEkgYWdyZWUgdGhhdCBtYW55IG9yZ2FuaXphdGlv bnMgdXNlZCBzY29wZXMgaW4gdmVyeSBkaWZmZXJlbnQgd2F5cywgYW5kIEkgdGhpbmsgaXQgaXMg dGhlIHJlc3VsdCBvZiBnaXZpbmcgdmVyeSBsaXR0bGUgZ3VpZGFuY2Ugb24gc2NvcGVzIGFuZCBy ZXNvdXJjZXMsIHdpdGggdGhlIGNvbnNlcXVlbmNlIHRoYXQgc29tZSBjaG9pY2VzIG1pZ2h0IGhh dmUgYmVlbiBsZXNzIHdpc2UgdGhhbiBvdGhlcnMuDQoNCg0KDQpXaXRoIHRoZSBjdXJyZW50IGd1 aWRhbmNlIEkgYXR0ZW1wdGVkIHRvIGNhcHR1cmUgYSBuYXJyb3dlciBzZXQgb2Ygc2NlbmFyaW9z IHdoZXJlIHNvbWUgb2YgdGhlIG1vc3Qgb2J2aW91cyBpc3N1ZXMgKGxpa2Ugc2NvcGUgY29uZnVz aW9uKSBjYW4gYmUgYXZlcnRlZCwgd2hpbGUgc3RpbGwgc2F0aXNmeWluZyBtb3N0IG9mIHRoZSBj YXNlcyBJIG9ic2VydmVkIGluIHRoZSBzYW1wbGUgSldUIEFUczogSSBhbSBub3QgdHJ5aW5nIHRv IG92ZXJpbmRleCBvbiB0aG9zZSBjYXNlcywgYW5kIEkgZG9u4oCZdCBtZWFuIHRvIGltcGx5IHRo YXQgdGhlIHByb2ZpbGUgc2hvdWxkIHN0cmljdGx5IGZvbGxvdyB0aG9zZSwgYnV0IGluIHRoZSBz cGlyaXQgb2YgZWxpbWluYXRpbmcgYW1iaWd1aXR5IGFzIG11Y2ggYXMgcG9zc2libGUsIHRoaXMg c2luZ2xlIHJlc291cmNlIG5hcnJvd2luZyBzZWVtZWQgYSBzb2xpZCBjb3JlIHRvIGJ1aWxkIHJv YnVzdCBpbXBsZW1lbnRhdGlvbnMgb24tIGZ1bGx5IGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQgbWFu eSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyB3b3VsZCBub3QgY29uZm9ybSAodGhvIEkgYW0gbm90 IHN1cmUgaG93IG1hbnkgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgYWRvcHRlZCByZXNvdXJjZSBp bmRpY2F0b3JzIG9yIGVxdWl2YWxlbnQpLg0KDQoNCg0KSW4gYW55IGNhc2UsIHNlZSAoKiktIEkg dGhpbmsgSSBjYW4gYmUgY29udmluY2VkIHRvIHR1cm4gdGhlIGN1cnJlbnQgcmVzdHJpY3Rpb25z IGludG8gc2VjdXJpdHkvYXV0aG9yaXphdGlvbiBjb25zaWRlcmF0aW9ucy0gYnV0IEkgd291bGQg cmVsdWN0YW50bHkgZG8gc28gYXMgSSB0aGluayB3ZeKAmWQgcGVycGV0dWF0ZSBhIGxvdCBvZiB0 aGUgYW1iaWd1aXR5IHdlIGhhdmUgaW4gdGhpcyBzcGFjZSB0b2RheS4NCg0KDQoNCg0KDQoNCg0K UGVyc29uYWxseSwgSSdtIG5vdCBhIGJpZyBmYW4gb2YgdHJ5aW5nIHRvIHVzZSBzY29wZXMgZm9y IGZpbmUtZ3JhaW4gYXV0aG9yaXphdGlvbi4gSSBkb24ndCB0aGluayB0aGF0IGlzIHdoYXQgdGhl eSB3ZXJlIGludGVuZGVkIGZvciB3aGVuIG9yaWdpbmFsbHkgZGVzaWduZWQuIChUaGlzIGNhbiBi ZSBzZWVuIGJ5IHRoZSBSQVIgc3BlYyBpbnRyb2R1Y2luZyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50 IHdheSBvZiBzcGVjaWZ5aW5nIGZpbmUtZ3JhaW4gYXV0aG9yaXphdGlvbiBjb250ZXh0LikgRXZl biBpbiBtdWx0aS10ZW5hbnQgc3lzdGVtcywgSSBkb24ndCBzZWUgaXNzdWVzIHdpdGggdXNpbmcg c3ViLXJlc291cmNlIHNjb3BlcyBhcyBlYWNoIHRlbmFudCBzaG91bGQgZGVmaW5lIHRoZSBzY29w ZXMgdGhhdCBtYWtlIHNlbnNlIGZvciB0aGF0IHRlbmFudC4gSSBkb24ndCB0aGluayB0aGUgQVMg bmVlZHMgdG8gdW5kZXJzdGFuZCB0aGUgc2NvcGVzLCBqdXN0IHByb3ZpZGUgYSBtZWNoYW5pc20g dG8gaXNzdWUgdGhlIGNvcnJlY3Qgc2NvcGUgdW5kZXIgdXNlciBjb25zZW50IHRvIHRoZSBjbGll bnQgYW5kIGxldCB0aGUgUlMgYXBwbHkgdGhlIGF1dGhvcml6YXRpb24gcG9saWN5IHdoZW4gaXQg Z2V0cyB0aGUgc2NvcGVzIG91dCBvZiB0aGUgdG9rZW4uDQoNCkkgYW0gbm90IGNyYXp5IGFib3V0 IHRoYXQgZWl0aGVyLSBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgd2hlbiBmaW5lIGdyYWluZWQgYXV0 aFogaXMgaW52b2x2ZWQgdmVyeSwgdmVyeSBvZnRlbiB3aGF0IGRldmVsb3BlcnMgcmVhbGx5IHdh bnQgYXJlIHVzZXIgcHJpdmlsZWdlcyBhbmQgc2NvcGVzIGFyZSBqdXN0IGFidXNlZCBpbiBsaWV1 IG9mIHByaXZpbGVnZXMgc2ltcGx5IGJlY2F1c2UgdGhlIHNwZWMgZG9lc27igJl0IGFkZHJlc3Mg dGhlIG5vbi1kZWxlZ2F0aW9uIHNjZW5hcmlvIGhlbmNlIGEgc2NyZXdkcml2ZXIgZW5kcyB1cCBi ZWluZyB1c2VkIGFzIGEgaGFtbWVyLg0KDQoNCg0KTm9uZXRoZWxlc3MsIGlmIHNjb3BlcyBhcmUg dXNlZC0gbWFuZGF0aW5nIHRoYXQgZXZlcnkgc2NvcGUgaXMgdGllZCB0byB0aGUgcmVzb3VyY2Ug ZG9lcyBsZWFkIHRvIGh1Z2UgdG9rZW5zIGFuZCBzaWduaWZpY2FudCBtYW5hZ2VtZW50IG92ZXJo ZWFkIGlmIHlvdSBoYXZlIGxvdHMgb2YgcmVzb3VyY2VzIHdob3NlIGlkZW50aWZpZXIgbXVzdCBi ZSBnbG9iYWxseSB1bmlxdWUsIG5vbnJlYXNzaWduYWJsZSBldGMgZXRjIGhlbmNlIHZlcnkgbGFy Z2Ug4oCTIGFuZCB0aGUgQVMgZG9lc27igJl0IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2VtYW50 aWMgb2YgZWFjaCBzY29wZSBidXQgaXQgZG9lcyBuZWVkIHRvIGtub3cgd2hldGhlciBhIHNjb3Bl IGNhbiBiZSByZXF1ZXN0ZWQgZm9yIGEgZ2l2ZW4gcmVzb3VyY2UsIHBsdXMgYW55IHBvbGljeSB0 aGUgYWRtaW4gbWlnaHQgd2FudCB0byBleGVjdXRlIGF0IHRva2VuIGlzc3VhbmNlIHRpbWUgKGVn IHRoaXMgc2NvcGUgcmVxdWlyZXMgMkZBKSBoZW5jZSBqdWdnbGluZyBsYXJnZSBudW1iZXJzIG9m IGxhcmdlIHN0cmluZ3MgY2FuIGJlIGhhcmQgZm9yIHRoZSBBUyDigJMgYW5kIFJTLiBJbiBhbnkg Y2FzZSwgdGhlIHVzZSBvZiBtdWx0aXBsZSByZXNvdXJjZXMgaW4gdGhlIGF1ZCBpbiB0aGUgd2ls ZCBhcHBlYXJlZCB0byBiZSB2ZXJ5IHJhcmUsIGhlbmNlIGV2ZW4gaWYgdGhlcmUgd291bGQgYmUg YSBmb29scHJvb2Ygd2F5IG9mIGRlZmluaW5nIGEgcmVzb3VyY2Utc2NvcGUgbWFwcGluZywgSSB3 b3VsZCBub3Qgc3BlbmQgY3ljbGVzIGRlZmluaW5nIGl0IGhlcmXigKYgYW5kIGxlYXZpbmcgaXQg YXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgd291bGRu4oCZdCB3b3JrIHBlciB0aGUgYWJvdmUu IEFzIGluICgqKSB3ZSBjb3VsZCByZWxheCB0aGUgY29uc3RyYWludCBoZXJlIGFuZCBqdXN0IHdh cm4gcGVvcGxlIGFnYWluc3Qgc2NvcGUgY29uZnVzaW9uLCBidXQgSSBmZWVsIHdl4oCZZCBiZSBt aXNzaW5nIGFuIG9wcG9ydHVuaXR5Lg0KDQoNCg0KDQoNCg0KDQotLS0tLS0NCg0KDQoNCg0KDQoN Cg0K77u/T24gMy8yNC8yMCwgMTc6MDAsICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJp Y2hhbm5hQGFtYXpvbi5jb20+PG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPiB3cm90ZToNCg0K DQoNCg0KDQoNCg0KICAgIFRvIGJvcnJvdyBhIHRlcm0gZnJvbSBNTCwgSSB0aGluayB0aGUgImF1 ZCIsICJzY29wZSIsIGFuZCByZXNvdXJjZSBpbmRpY2F0b3ItcmVsYXRlZCB0ZXh0IGlzIG92ZXJm aXR0ZWQgdG8gYSBzcGVjaWZpYyBzZXQgb2YgZGVwbG95bWVudCBzY2VuYXJpb3MsIGFuZCBhIHNw ZWNpZmljIHdheSBvZiB1c2luZyBzY29wZXMgYW5kIHJlc291cmNlIGluZGljYXRvcnMuDQoNCg0K DQoNCg0KDQoNCiAgICBDb25zaWRlciB0aGUgZm9sbG93aW5nOg0KDQoNCg0KDQoNCg0KDQogICAg MS4gVGhlcmUgbWF5IGJlIG5vICJzY29wZSIgcGFyYW1ldGVyDQoNCg0KDQogICAgVGhlICJzY29w ZSIgcGFyYW1ldGVyIGlzIE9QVElPTkFMIGluIGF1dGhvcml6YXRpb24gcmVxdWVzdHMuIFNvIGFu IEFTL1JTIG9wZXJhdG9yIGNvdWxkIGRlY2lkZSB0aGV5J3JlIGdvaW5nIHRvIG9taXQgInNjb3Bl IiBlbnRpcmVseSBhbmQgdXNlIG11bHRpcGxlIHJlc291cmNlIHBhcmFtZXRlcnMgaW5zdGVhZC4g U2luY2UgdGhlcmUgYXJlIG5vIHNjb3BlcywgdGhlcmUgaXMgbm8gb3Bwb3J0dW5pdHkgZm9yIGNv bmZ1c2lvbi4gSW4gdGhpcyBjYXNlLCBhIEpXVCBBVCB3aXRoIGEgbXVsdGktdmFsdWVkICJhdWQi IGNsYWltIGFuZCBubyAic2NvcGUiIGNsYWltIHdvdWxkIHNlZW0gYXBwcm9wcmlhdGUuIFdoaWxl IG11bHRpcGxlIHJlc291cmNlIGluZGljYXRvcnMgY291bGQgYmUgcHVzaGVkIGludG8gYSBzaW5n bGUgc2NvcGUgc3RyaW5nLCB0aGlzIGludHJvZHVjZXMgb3Bwb3J0dW5pdGllcyBmb3Igc2VyaW91 cyBzZWN1cml0eSBpbXBhY3RpbmcgZW5jb2RpbmcvZGVjb2RpbmcvcGFyc2luZyBidWdzLiBUaGUg bW9yZSBJIHRoaW5rIGFib3V0IGl0LCB0aGUgbW9yZSAiSSBkb24ndCBoYXZlIHRvIGRlYWwgd2l0 aCBwYXJzaW5nIGEgc2NvcGUgc3RyaW5nIiBzZWVtcyBsaWtlIGEgY29tcGVsbGluZyByZWFzb24g dG8gZ28gdGhpcyByb3V0ZS4uLiBfXw0KDQoNCg0KDQoNCg0KDQogICAgMi4gVGhlIHNjb3BlcyBt YXkgYXBwbHkgdG8gYWxsIGF1ZGllbmNlcw0KDQoNCg0KICAgIEFuIEFTL1JTIG9wZXJhdG9yIG1h eSB1c2UgInNjb3BlIiB0byBpbmRpY2F0ZSBhIHJvbGUgb3IgcG9saWN5IChvciBzZXQgb2YgcG9s aWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3YW50cywgYW5kIGFsbG93IHRoZSBjbGllbnQgdG8gbmFy cm93IHRoZWlyIHBlcm1pc3Npb25zIHVzaW5nICJyZXNvdXJjZSIgcGFyYW1ldGVycy4gVGhpcyB3 b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIG9idGFpbiBuYXJyb3dseSBzY29wZWQgYWNjZXNzIHRv a2VucyBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzIHdpdGhvdXQgbmVlZGluZyB0byBkZWZpbmUgc2Vw YXJhdGUgcm9sZXMvcG9saWNpZXMgZm9yIGVhY2guIEluIHRoaXMgY2FzZSwgYSBKV1QgQVQgd2l0 aCBhIG11bHRpLXZhbHVlZCAiYXVkIiBjbGFpbSBhbmQgYSAic2NvcGUiIGNsYWltIHdvdWxkIHNl ZW0gYXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFpbSBpcyBpbnRlbmRlZCB0byBhcHBseSB0 byBhbGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy4NCg0KDQoNCg0KDQoNCg0KICAgIDMuIFRoZSBt YXBwaW5nIGJldHdlZW4gYXVkaWVuY2UgYW5kIHNjb3BlIG1heSBiZSB1bmFtYmlndW91cw0KDQoN Cg0KICAgIFRoZXJlIGFyZSBhIGxvdCBvZiBkZXBsb3ltZW50cyB0byB3aGljaCB0aGUgYmxhc3Qg cmFkaXVzIHJpc2sgeW91J3JlIHRyeWluZyB0byBhZGRyZXNzIGJ5IHJlcXVpcmluZyAiYXVkIiBz aW1wbHkgZG9lcyBub3QgYXBwbHkuIEl0IG1heSBzZWVtIGlubm9jdW91cyB0byByZXF1aXJlIHRo ZXNlIGRlcGxveW1lbnRzIHRvIGV4cGxpY2l0bHkgaW5jbHVkZSBhIGJyb2FkIGF1ZGllbmNlIGxp a2UgImFwaS5leGFtcGxlLmNvbSIgYW55d2F5LCB0aGF0IGNhbiBsZWFkIHRvIGltcGxlbWVudGVy cyBpZ25vcmluZyB0aGUgcmVxdWlyZW1lbnQgKGxlYWRpbmcgdG8gaW50ZXJvcCBpc3N1ZXMpLCBu b3QgdmFsaWRhdGluZyBpdCAoYWxzbyBsZWFkaW5nIHRvIGludGVyb3AgaXNzdWVzIG9yIHNlY3Vy aXR5IGlzc3VlcyBpZiB0aGUgZGVwbG95bWVudCB3YW50cyB0byBzdGFydCBhY3R1YWxseSB1c2lu ZyBpdCBmb3IgcmVhbCksIG9yIGRvaW5nIHNvbWV0aGluZyBmdW5reSB3aXRoIGl0IHNpbmNlIHRo ZXJlIGlzbid0IGFueXRoaW5nICJyZWFsIiB0aGF0IHRoZSB2YWx1ZSBuZWVkcyB0byBjb25mb3Jt IHRvLg0KDQoNCg0KDQoNCg0KDQogICAg4oCTDQoNCg0KDQogICAgQW5uYWJlbGxlIEJhY2ttYW4g KHNoZS9oZXIpDQoNCg0KDQogICAgQVdTIElkZW50aXR5DQoNCg0KDQogICAgaHR0cHM6Ly9hd3Mu YW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgT24gMy8yNC8y MCwgMzozMSBQTSwgIk9BdXRoIG9uIGJlaGFsZiBvZiBWaXR0b3JpbyBCZXJ0b2NjaSIgPG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAu Y29tQGRtYXJjLmlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ29uYmVoYWxm b2Z2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoN Cg0KDQoNCg0KDQoNCiAgICBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRz aWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFj aG1lbnRzIHVubGVzcyB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29u dGVudCBpcyBzYWZlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgIFRoYW5rcyBH ZW9yZ2UgZm9yIHRoZSBzdXBlciB0aG9yb3VnaCByZXZpZXcgYW5kIGZlZWRiYWNrIQ0KDQoNCg0K ICAgIElubGluZQ0KDQoNCg0KDQoNCg0KDQogICAgICA+ICBTZWN0aW9uIDEuIEludHJvZHVjdGlv bg0KDQoNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBsaW5lOiBzY2VuYXJp byBzaG91bGQgYmUgcGx1cmFsIC0tPiBzY2VuYXJpb3MNCg0KDQoNCiAgICAgICAgIMOvwr/CvcOv wr/CvcOvwr/CvSBzZWNvbmQgc2VudGVuY2U6ICJhcmUgbm90IHJhbiBieSIgLS0+ICJhcmUgbm90 IHJ1biBieSINCg0KDQoNCiAgICAgICAgw6/Cv8K9w6/Cv8K9IGNvZmlkZW50aWFsaXR5IC0tPiBj b25maWRlbnRpYWxpdHkNCg0KDQoNCiAgICBGaXhlZC4gVGhhbmtzIQ0KDQoNCg0KDQoNCg0KDQog ICAgPiAgICAgU2VjdGlvbiAyLjIuMSBBdXRoZW50aWNhdGlvbiBJbmZvcm1hdGlvbiBDbGFpbXMN Cg0KDQoNCiAgICAgICAgIMOvwr/CvcOvwr/CvcOvwr/CvSBJJ20gbm90IHN1cmUgdGhhdCB0aGlz IGRlZmluaXRpb24gb2YgYGF1dGhfdGltZWAgYWxsb3dzIGZvciB0aGUNCg0KDQoNCiAgICAgICAg Y2FzZSB3aGVyZSBhIHVzZXIgaXMgcmVxdWlyZWQgdG8gc29sdmUgYW4gYWRkaXRpb25hbCBjaGFs bGVuZ2UuDQoNCg0KDQogICAgSWYgdGhlIGNoYWxsZW5nZSBlbnRhaWxzIGdvaW5nIGJhY2sgdG8g dGhlIEFTLCB0aGVuIEkgYmVsaWV2ZSB0aGUgbGFuZ3VhZ2UgKGluIHRoZSBpbml0aWFsIHBhcmFn cmFwaCBvZiAyLjIuMSBhbmQgaW4gYXV0aF90aW1lIGl0c2VsZikgIGFjY29tbW9kYXRlcyBmb3Ig dGhhdCBhbmQgZG9lcyByZXF1aXJlIHRoZSBhdXRoX3RpbWUgdG8gYmUgdXBkYXRlZC4NCg0KDQoN CiAgICBJZiB5b3UgaGl0IHRoZSBBUyBhbmQgcHJlc2VudCBhbiBhdXRoZW50aWNhdGlvbiBmYWN0 b3IgKHN1Y2ggYXMgeW91ciBjaGFsbGVuZ2UpIGFuZCBvYnRhaW4gYSBuZXcgdG9rZW4gaW4gdGhl IHByb2Nlc3MsIHRoZSBhdXRoX3RpbWUgd2lsbCByZWZsZWN0IHRoZSB0aW1lIG9mIHlvdXIgbGF0 ZXN0IGF1dGhlbnRpY2F0aW9uIGp1c3QgbGlrZSBhbiBpZF90b2tlbiB3b3VsZCBpbiB0aGUgc2Ft ZSBjaXJjdW1zdGFuY2VzICh0aGluayBwcm90ZWN0ZWQgcm91dGUgaW4gYSB3ZWIgYXBwIHJlcXVp cmluZyBzdGVwIHVwIGF1dGgpIGFuZCAobGlrZWx5KSBhc3NvY2lhdGVkIHNlc3Npb24gYXJ0aWZh Y3RzICh0aGluayBSVHMgb3IgY29va2llcyB3aXRoIHNsaWRpbmcgZXhwaXJhdGlvbiwgdGhlIGNo YWxsZW5nZSB3b3VsZCBjb3VudCBhcyBhY3Rpdml0eSBhbmQgbW92ZSB0aGUgZXhwaXJhdGlvbiku DQoNCg0KDQoNCg0KDQoNCiAgICA+ICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSB0aGluayB0aGVy ZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXNzaW9uX3N0YXJ0X3RpbWUgYW5kIGxhc3QNCg0K DQoNCiAgICAgICAgYXV0aF90aW1lLiBUaGlzIGZlZWxzIG1vcmUgbGlrZSBpdCdzIGRlZmluaW5n IHRoZSBzZXNzaW9uX3N0YXJ0X3RpbWUNCg0KDQoNCiAgICAgICAgY29uY2VwdC4NCg0KDQoNCiAg ICA+ICAgIMOvwr/CvcOvwr/CvSBUaGVzZSBzYW1lIGlzc3VlcyBjYW4gYXBwbHkgdG8gdGhlIGBh Y3JgIGFuZCBgYW1yYCB2YWx1ZXMgYXMgd2VsbC4NCg0KDQoNCiAgICBQZXIgdGhlIGFib3ZlLCB0 aGUgaW50ZW50IGlzIG1vcmUgdG8gZXhwcmVzcyB0aGUgbGFzdCB0aW1lIHRoZSB1c2VyIHBlcmZv cm1lZCBhbnkgYXV0aGVudGljYXRpb24gYWN0aW9uIHJhdGhlciB0aGFuIHRoZSBzdGFydCB0aW1l LiBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gYXMgY3VycmVudCBhcyBwb3Nz aWJsZSwgYXMgaXQgbWlnaHQgYmUgcmVsZXZhbnQgdG8gdGhlIFJTIGRlY2lzaW9ucyB3aGVyZWFz IHRoZSBoaXN0b3J5IGJlZm9yZSBjdXJyZW50IGNvbmRpdGlvbnMgbWlnaHQgbm90IGJlIGNvbnNl cXVlbnRpYWwuDQoNCg0KDQoNCg0KDQoNCiAgICAgID4gICDDr8K/wr3Dr8K/wr0gRXZlbiBpZiBm b3IgdGhpcyBzZWNvbmRhcnkgY2hhbGxlbmdlIGEgbmV3IHJlZnJlc2hfdG9rZW4gaXMgaXNzdWVk LA0KDQoNCg0KICAgICAgICBpdCBpcyB1bmxpa2VseSBtYW55IHJlbHlpbmcgcGFydGllcyB3aWxs IHdhbnQgdG8gdHJlYXQgdGhhdCBhcyBpc3N1aW5nIGENCg0KDQoNCiAgICAgICAgbmV3IHNlc3Np b24uIFRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIHVzZXIgbG9nZ2VkIGluIHRvIGEgc2luZ2xlIHNl c3Npb24uDQoNCg0KDQogICAgQ291bGQgeW91IGV4cGFuZCBvbiB0aGUgcHJhY3RpY2FsIGltcGxp Y2F0aW9ucyBvZiB0aGUgYWJvdmU/IFRoZSBpbnRlbnQgaXNuJ3QgYXMgbXVjaCB0byByZWZsZWN0 IHNlc3Npb24gaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gcGVyIHNlLCBidXQgdG8gcHJvdmlkZSB0 aGUgUlMgd2l0aCB0aGUgbW9zdCB1cCB0byBkYXRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjaXJj dW1zdGFuY2VzIGluIHdoaWNoIHRoZSBjdXJyZW50IEFUIHdhcyBvYnRhaW5lZC4gVGhlIGZhY3Qg dGhhdCBhIHNlc3Npb24gd2FzIGluaXRpYWxseSBlc3RhYmxpc2hlZCB1c2luZyBhY3IgbGV2ZWwg MCBkb2VzbuKAmXQgcmVhbGx5IG1hdHRlciBpZiB0aGUgQVQgSSBhbSByZWNlaXZpbmcgbm93IGhh cyBiZWVuIG9idGFpbmVkIGFmdGVyIGEgc3RlcHVwIHRoYXQgYnJvdWdodCBhY3IgdG8gMSwgaWYg bXkgUlMgY2FyZXMgYXV0aCBhdXRoZW50aWNhdGlvbiBsZXZlbHMgbXkgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbiBzaG91bGRuJ3QgYmUgaW5mbHVlbmNlZCBieSB3aGV0aGVyIHNvbWV3aGVyZSB0aGUg c2Vzc2lvbiBhcnRpZmFjdCBkaWRu4oCZdCBjaGFuZ2UgaXRzIHNlc3Npb25JRCBhZnRlciB0aGUg c3RlcHVwLiBTYW1lIGZvciBhY3IsIGF1dGhfdGltZQ0KDQoNCg0KDQoNCg0KDQogICAgPiAgICAg U2VjdGlvbiAyLjIuMyBBdXRob3JpemF0aW9uIENsYWltcw0KDQoNCg0KICAgICAgICAgw6/Cv8K9 w6/Cv8K9IEkgZmluZCB0aGUgc3RhdGVtZW50ICJBbGwgdGhlIGluZGl2aWR1YWwgc2NvcGUgc3Ry aW5ncyBpbiB0aGUgc2NvcGUNCg0KDQoNCiAgICAgICAgY2xhaW0gTVVTVCBoYXZlIG1lYW5pbmcg Zm9yIHRoZSByZXNvdXJjZSBpbmRpY2F0ZWQgaW4gdGhlIGF1ZCBjbGFpbSINCg0KDQoNCiAgICAg ICAgc29tZXdoYXQgcHJvYmxlbWF0aWMuIEluIG1hbnkgZGVwbG95bWVudHMgdG9kYXkgZm9yIDFz dCBwYXJ0eSBjbGllbnRzIHRvDQoNCg0KDQogICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBhbmQgdGFraW5nIGludG8gYWNjb3VudCBtb2JpbGUgYXBwbGljYXRpb25zLA0KDQoNCg0KICAg ICAgICB0aGUgYWNjZXNzIHRva2VuIG1vc3QgbGlrZSBjb250YWlucyBzY29wZXMgZm9yIG1hbnkg b2YgdGhlIDFzdCBwYXJ0eQ0KDQoNCg0KICAgICAgICBiYWNrZW5kIEFQSXMuIEl0J3MgcG9zc2li bGUgdG8gZ2V0IGFyb3VuZCB0aGlzIGJ5IHNldHRpbmcgdGhlICdhdWQnDQoNCg0KDQogICAgICAg IGNsYWltIHRvIHNvbWV0aGluZyBsaWtlICJjb20uZXhhbXBsZS5hcGlzIiBhbmQgaGVuY2UgYWxs IHRoZSBpc3N1ZWQNCg0KDQoNCiAgICAgICAgc2NvcGVzIG1hcCB0byB0aGF0IGF1ZGllbmNlIGNs YWltIGJ1dCB0aGF0IGlzIGp1c3Qgd29ya2luZyBhcm91bmQgdGhlDQoNCg0KDQogICAgICAgIE1V U1QgaW4gdGhlIHNwZWMuIEdpdmVuIHRoZSBsYWNrIG9mIHNwZWNpZmljaXR5IG9mIHRoZSAnYXVk JyBjbGFpbSBhbmQNCg0KDQoNCiAgICAgICB0aGUgJ3Jlc291cmNlIGluZGljYXRvcicgY2xhaW0g Zm9yIHRoYXQgbWF0dGVyLCBwcmV0dHkgbXVjaCBhbnl0aGluZyBjYW4NCg0KDQoNCiAgICAgICAg YmUgbWFkZSB0byBjb21wbHkuIEluIHRoYXQgY29udGV4dCwgaXQgc2VlbXMgbGlrZSBSRUNPTU1F TkQgaXMgYSBiZXR0ZXINCg0KDQoNCiAgICAgICAgbm9ybWF0aXZlIGNsYXVzZS4NCg0KDQoNCiAg ICBGb3IgMXN0IHBhcnR5IHNvbHV0aW9ucywgSSB3b3VsZCBhcmd1ZSB0aGF0IGRlbGVnYXRpb24g bWlnaHQgbm90IGJlIHRoZSByaWdodCBwcmltaXRpdmUgaGVuY2UgSSB3b3VsZG4ndCBuZWNlc3Nh cmlseSB1c2Ugc2NvcGVzIHRvIGV4cHJlc3MgcGVybWlzc2lvbnM7IGJ1dCB0aGF0J3MgYSByYWJi aXQgaG9sZSBJJ2xsIHRyeSB0byBhdm9pZCBmb3IgdGhlIHRpbWUgYmVpbmcgX18NCg0KDQoNCiAg ICBGb3IgdGhlIGF1ZCwgSSB0aGluayB0aGF0IHdoYXQgeW91IGNoYXJhY3Rlcml6ZWQgYXMgd29y a2Fyb3VuZCB3b3VsZCBhY3R1YWxseSBiZSBieSBkZXNpZ24uIFRoZSBhdWQgZGVmaW5lcyB0aGUg YXBwbGljYWJpbGl0eSBvZiB0aGUgY3VycmVudCB0b2tlbiwgc28gdGhhdCBpbiBjYXNlIG9mIGxl YWthZ2UgdGhlIGJsYXN0IHJhZGl1cyBvZiB0aGUgaW5jaWRlbnQgY2FuIGJlIGNvbnRhaW5lZC4g SWYgdGhlIHNvbHV0aW9uIGRlc2lnbmVkIGRlY2lkZXMgdGhhdCB0aGlzIHBhcnRpY3VsYXIgdG9r ZW4gc2hvdWxkIGJlIHJldXNhYmxlIGFjcm9zcyBtdWx0aXBsZSBhc3NldHMsIEkgdGhpbmsgaXQg bWFrZXMgc2Vuc2UgZm9yIHRoZSBhdWQgdG8gcmVmbGVjdCB0aGF0IGV4cGxpY2l0bHkuIFRoYXQn cyB0aGUgc3lzdGVtIGRlc2lnbmluZyB2b2x1bnRlZXJpbmcgYSBzY29wZSB4cGFuc2lvbiBvZiB0 aGUgc2NvcGUsIGFuZCBnaXZlbiB0aGF0IGl0IGhhcyBzZWN1cml0eSBpbXBsaWNhdGlvbnMgSSB0 aGluayBpdCdzIGdvb2QgdG8gcmVxdWlyZSBpdCB0byBiZSBhbiBleHBsaWNpdCwgb3B0IGluIGFj dGlvbi4gQXQgdGhlIHNhbWUgdGltZSwgZ2l2ZW4gdGhhdCBzY29wZXMgYXJlIG9mdGVuIHVzZWQg dG8gZGVmaW5lIHBlcm1pc3Npb25zLCBJIGJlbGlldmUgaXQgbWFrZXMgc2Vuc2UgdG8gZmluZCBt ZWNoYW5pc21zIHRvIG1pbmltaXplIHRoZSBjaGFuY2UgdGhhdCBSU2VzIHdvdWxkIG1pc2ludGVy cHJldCB0aGUgYXBwbGljYWJpbGl0eSBvZiBhIHNjb3BlIChzZWUgZGlzY3Vzc2lvbiB3aXRoIFRh a2FoaWtvL05pa29zKS4gU3VtbWluZyBhbGwgdGhlIGFib3ZlLCBJJ2QgYmUgaW5jbGluZWQgdG8g a2VlcCB0aGUgTVVTVC4NCg0KDQoNCg0KDQoNCg0KICAgID4gU2VjdGlvbiAzLiBSZXF1ZXN0aW5n IGEgSldUIEFjY2VzcyBUb2tlbg0KDQoNCg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IFBlciBteSBj b21tZW50cyBhYm92ZSBJIHN1c3BlY3QgdGhhdCByZXF1aXJpbmcgYWxsIEpXVCBhY2Nlc3MgdG9r ZW5zDQoNCg0KDQogICAgICAgIHRvIGluY2x1ZGUgYW4gYXVkaWVuY2UgY2xhaW0gd2lsbCBqdXN0 IGRldm9sdmUgdG8gYXVkaWVuY2UgY2xhaW1zIHRoYXQNCg0KDQoNCiAgICAgICAgYXJlIHNvbWV3 aGF0IHBvaW50bGVzcyAoaW4gb3JkZXIgdG8gbWVldCB0aGlzIE1VU1QgaW4gdGhlIHNwZWMpLiBH aXZlbg0KDQoNCg0KICAgICAgICB0aGUgbW9iaWxlIGFwcCBlbnZpcm9ubWVudCB0b2RheSwgaXQg aXMgdW5yZWFzb25hYmxlIHRvIGFzayB0aGUgbW9iaWxlDQoNCg0KDQogICAgICAgIGFwcHMgdG8g ZG93bnNjb3BlIGV2ZXJ5IGFjY2VzcyB0b2tlbiBiZWZvcmUgbWFraW5nIGFuIEFQSSBjYWxsIHRv IHRoZQ0KDQoNCg0KICAgICAgICBiYWNrZW5kIEFQSXMgd2hpY2ggaXMgd2hhdCB0aGUgc3Bpcml0 IG9mIGF1ZGllbmNlIGFuZCByZXNvdXJjZQ0KDQoNCg0KICAgICAgICBpbmRpY2F0b3JzIHNlZW0g dG8gaW1wbHkuDQoNCg0KDQogICAgUGFydGx5IGFkZHJlc3NlZCBpbiB0aGUgcHJlY2VkaW5nIHBv aW50LCBidXQgdGhpcyBpcyBhIGdyZWF0IG9wcG9ydHVuaXR5IHRvIGNsYXJpZnkgdGhlIGludGVu dCBmdXJ0aGVyLiBUaGUgbW9iaWxlIGNsaWVudCBpc24ndCByZXF1aXJlZCB0byBkb3duc2NvcGU7 IHJhdGhlciwgdGhlIGZhY3QgdGhhdCBhIHRva2VuIGNhYiBiZSBhcHBsaWVkIHRvIGEgYnJvYWQg cmFuZ2Ugb2YgQVBJIHNob3VsZCBiZSBjbGVhcmx5IGlkZW50aWZpZWQgYW5kIGV4cHJlc3NlZCBi eSB0aGUgbG9naWNhbCBhdWRpZW5jZS4gVGhlIHN5c3RlbSBkZXNpZ25lciBjYW4gZXZlbiBjaG9v c2UgdG8gaGF2ZSBhIHNpbmdsZSB0b2tlbiB0aGF0IGNhbiBiZSB1c2VkIHRvIGNhbGwgYW55IEFQ SSwgY29udGFpbmluZyBldmVyeSBzY29wZSBmb3IgZXZlcnkgQVBJOyB0aGUgcHJvZmlsZSBvbmx5 IGFza3MgZm9yIHRoaXMgY2hvaWNlIHRvIGJlIG1hbmlmZXN0LCBieSBjaG9vc2luZyBhbiBhcHBy b3ByaWF0ZSBhdWRpZW5jZSBpZGVudGlmaWVyIGFuZCBhY2tub3dsZWRnaW5nIHRoYXQgYWxsIHRo ZSBzY29wZXMgaW4gdGhlIHRva2VuIGFyZSBhcHBsaWNhYmxlIHRvIHRoZSBzYW1lIGxvZ2ljYWwg cmVzb3VyY2UgKHRoYXQgaXMsIHRoZSBhZ2dyZWdhdGUgb2YgYWxsIHRoZSBBUElzKS4NCg0KDQoN Cg0KDQoNCg0KICAgICAgICAgPiAgw6/Cv8K9w6/Cv8K9IFdoeSBNVVNUIHRoZSBBUyByZWplY3Qg YSByZXF1ZXN0IHdpdGggbW9yZSB0aGFuIG9uZSByZXNvdXJjZQ0KDQoNCg0KICAgICAgICBwYXJh bWV0ZXI/IElmIGEgcmVxdWVzdCBjb21lcyBpbiB3aXRoIG5vIHJlc291cmNlIHBhcmFtZXRlciBh bmQgbXVsdGlwbGUNCg0KDQoNCiAgICAgICAgc2NvcGVzIHRoZSBBUyBpcyBub3QgcmVxdWlyZWQg dG8gcmVqZWN0IHRoYXQgcmVxdWVzdC4gSXMgdGhlcmUgbXVjaCBvZiBhDQoNCg0KDQogICAgICAg IHNlbWFudGljIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvPyBJbiB0aGUgY2FzZSBvZiBubyBy ZXNvdXJjZQ0KDQoNCg0KICAgICAgICBwYXJhbWV0ZXIgYW5kIG11bHRpcGxlIHNjb3BlcyB0aGUg QVMgbWlnaHQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGgNCg0KDQoNCiAgICAgICAgbXVsdGlw bGUgYXVkaWVuY2UgdmFsdWVzIChhcyBpcyBhbGxvd2VkIGJ5IFJGQyA3NTE5KS4NCg0KDQoNCiAg ICBUaGlzIGlzIGFub3RoZXIgY29uc2VxdWVuY2Ugb2YgbWFraW5nIGV4dHJhIGNsZWFyIHdoYXQg dGhlIHRva2VuIHJlZmVycyB0bywgYW5kIHdoYXQgdGhlIGludGVuZGVkIHNlbWFudGljIG9mIHRo ZSBzY29wZXMgaXMuIFRoZSBpZGVhIGlzIHRoYXQgdGhlIHRva2VuIGlzIGFsd2F5cyByZXN0cmlj dGVkIHRvIE9ORSBzcGVjaWZpYyBhdWRpZW5jZS4gVGhlIHByb2ZpbGUgYWxsb3dzIGZvciBkaWZm ZXJlbnQgbWVjaGFuaXNtcyBmb3IgdGhlIEFTIHRvIGRldGVybWluZSB3aGF0IHZhbHVlIHRoZSBh dWRpZW5jZSBzaG91bGQgYmUsIGluY2x1ZGluZyB2aWEgaW5mZXJlbmNlIGZyb20gc2NvcGVzLCBi dXQgY29oZXJlbnRseSB3aXRoIHRoZSBzY29wZSBjb25mdXNpb24gcHJldmVudGlvbiBwcmluY2lw bGUsIGlmIHRoYXQgaW5mZXJlbmNlIGNhbm5vdCBsZWFkIHRvIGEgc2luZ2xlIHJlc291cmNlIGlk ZW50aWZpZXIgaW4gdGhlIGF1ZGllbmNlLCB0aGUgcmVxdWVzdCBzaG91bGQgYmUgcmVqZWN0ZWQu DQoNCg0KDQogICAgVGhlIGludGVudCBpcyByZWFsbHkgdG8gYmUgYXMgc2ltcGxlIGFzIHVuYW1i aWd1b3VzIGFzIHBvc3NpYmxlLCBhbmQgY2FwdHVyZSB3aGF0IG1vc3QgbWFpbnN0cmVhbSBwcm92 aWRlcnMgYWxyZWFkeSBkbyBpbiBKV1QgQVRzLiBJZiBhIFJTIGhhcyBtb3JlIHNvcGhpc3RpY2F0 ZWQgcmVxdWlyZW1lbnRzLCB0aGV5IGNhbiBhbHdheXMgZGVjaWRlIHRvIGRvIG1vcmUgYW5kIG5v dCBmb2xsb3cgdGhlIGludGVyb3AgcHJvZmlsZS4gRGVmaW5pbmcgbW9yZSBjb21wbGV4IHJ1bGVz IHRvIHByZXZlbnQgc2NvcGUvcmVzb3VyY2UgYXNzb2NpYXRpb24gY29uZnVzaW9uIHNpbXBseSBk b2VzbuKAmXQgc2VlbSB0byBiZSBqdXN0aWZpZWQgYnkgdGhlIGZyZXF1ZW5jeSBvZiB0aGUgc2Nl bmFyaW8gaW4gdGhlIHdpbGQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgID4gIEFsc28sIHRo ZSBhdWRpZW5jZQ0KDQoNCg0KICAgICAgICBjbGFpbSBpcyBub3Qgc29sZWx5IGZvciByZXNvdXJj ZSBpbmRpY2F0b3IgdmFsdWVzIGJ1dCBpcyBkZWZpbmVkIHRvIGp1c3QNCg0KDQoNCiAgICAgICAg YmUgYSBzdHJpbmcuIFRvIG1lIGl0IGZlZWxzIGxpa2UgdGhlIHRleHQgaXMgaW1wbHlpbmcgdGhh dCB0aGUgb25seQ0KDQoNCg0KICAgICAgICB2YWxpZCBhdWRpZW5jZSB2YWx1ZSBpcyBhbHNvIGEg cmVzb3VyY2UgaW5kaWNhdG9yICh3aGljaCBmcm9tIHByZXZpb3VzDQoNCg0KDQogICAgICAgIGRp c2N1c3Npb25zIG9uIHRoZSBsaXN0IGl0IHdhcyBpbXBsaWVkIHRoZXkgaGF2ZSBhIHNsaWdodGx5 IGRpZmZlcmVudA0KDQoNCg0KICAgICAgICBzZW1hbnRpYykuDQoNCg0KDQogICAgU2VjdGlvbiAz IG9mIHRoZSBwcm9maWxlIGRvZXMgZGVmaW5lIGF1ZCBhcyBhIHJlc291cmNlIGluZGljYXRvciwg ZW51bWVyYXRpbmcgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHBvc3NpYmxlIHJlcXVlc3RzIHRoYXQg YWxsIGVuZCBpbiBhIHJlc291cmNlIGluZGljYXRvciBhcyBhdWQsIG9yIGFuIGVycm9yLiBEaWQg SSBtaXNzIHNvbWUgY2FzZXM/IEkgZG9u4oCZdCByZWNhbGwgc3BlY2lmaWNzIGFib3V0IGF1ZCB2 YWx1ZXMgaW4gdGhpcyBwcm9maWxlIGhhdmluZyBvdGhlciBwb3NzaWJsZSB2YWx1ZXMsIHNvcnJ5 IGZvciBoYXZpbmcgbWlzc2VkIHRoYXQuIERvIHlvdSBoYXZlIGEgc25pcHBldCByZWZlcnJpbmcg dG8gdGhvc2UgZGlzY3Vzc2lvbnM/IFRoeA0KDQoNCg0KDQoNCg0KDQogICAgICAgID4gIMOvwr/C vcOvwr/CvSBUaGUgbW9kZWwgZGVzY3JpYmVkIGhlcmUgd29ya3Mgd2VsbCBpZiBteWNvLmV4YW1w bGUgcmVhbGx5IG9ubHkNCg0KDQoNCiAgICAgICAgcHJvdmlkZXMgYSBzaW5nbGUgc2VydmljZS4g QnV0IGlmIGluc3RlYWQgbXljby5leGFtcGxlIHByb3ZpZGVzIG11bHRpcGxlDQoNCg0KDQogICAg ICAgIHNlcnZpY2VzIGVhY2ggd2l0aCB0aGVpciBvd24gZW5kcG9pbnRzIChzcnZhLm15Y28uZXhh bXBsZSwNCg0KDQoNCiAgICAgICAgc3J2Yi5teWNvLmV4YW1wbGUpIGFuZCBzY29wZXMsIGZvciBt ZSB0aGlzIG1vZGVsIGJlZ2lucyB0byBicmVhayBkb3duLg0KDQoNCg0KICAgICAgICBFaXRoZXIg bW9iaWxlIGFwcHMgYXJlIHJlcXVpcmVkIHRvIGRvd25zY29wZSBhbGwgdG9rZW5zIHRvIGp1c3Qg dGhlDQoNCg0KDQogICAgICAgIHNlcnZpY2UgdGhleSBhcmUgY2FsbGluZyBhdCB0aGF0IHBvaW50 IGluIHRpbWUgKHdoaWNoIGNhbiBoYXZlIGxhdGVuY3kNCg0KDQoNCiAgICAgICAgYW5kIGNvbm5l Y3Rpdml0eSBpc3N1ZXMpLCBvciBteWNvLmV4YW1wbGUgaGFzIHRvIGNyZWF0ZSBhIGdlbmVyaWMN Cg0KDQoNCiAgICAgICAgImF1ZGllbmNlIiBzdHJpbmcgdGhhdCByZXByZXNlbnRzIGFsbCBvZiBl eGFtcGxlLmNvbSB3aGljaCBkb2Vzbid0IHNlZW0NCg0KDQoNCiAgICAgICAgdG8gYmUgdGhlIHNw aXJpdCBvZiB0aGUgZXhpc3Rpbmcgc3BlY3MuDQoNCg0KDQogICAgSSB0aGluayB0aGF0IHRoZSBn cmFudWxhcml0eSBvZiB0aGUgY2FsbHMgaXMgZnVsbHkgd2l0aGluIHRoZSBjb250cm9sIG9mIHRo ZSBkZXNpZ25lci4gSWYgc3J2YS5teWNvLmV4YW1wbGUgYW5kIHNydmIubXljby5leGFtcGxlIHNo YXJlIGFuYWxvZ291cyBjaGFyYWN0ZXJpc3RpY3MgKHNhbWUgcG9saWNpZXMsIGxpZmVjeWNsZSwg cmVzb3VyY2Ugb3duZXJzaGlwLCBldGMpIHRoZW0gaXQncyBwZXJmZWN0bHkgdmFsaWQgdG8gYXNz aWduIGEgbG9naWNhbCBteWNvLmV4YW1wbGUgYXVkaWVuY2UgZW5jb21wYXNzaW5nIHRoZW0gYWxs LCByZWdhcmRsZXNzIG9mIGRlcGxveW1lbnQgbW9kZWwuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNl cyBpbiB0ZXJtcyBvZiBwb2xpY2llcywgYXV0aCBzdHJlbmd0aCByZXF1aXJlbWVudHMsIGxpZmVj eWNsZSwgcmlzayBhbmQgaW1wYWN0IG9mIGEgbGVhaywgb3IgYW55IG90aGVyIGJvdW5kYXJ5LCB0 aGVuIHRoZSBhdWRpZW5jZSByZXF1aXJlbWVudCB3aWxsIGd1YXJhbnRlZSB0aGF0IHRob3NlIGRp ZmZlcmVuY2VzIGFyZSByZWZsZWN0ZWQgaW4gdG9rZW5zIHJlcXVlc3RlZCBhbmQgY2FjaGVkLCBp biB0aGUgd2F5IGluIHdoaWNoIGFjY2VzcyBpcyBwYXJ0aXRpb25lZCwgYW5kIHNvIG9uIGFuZCBz byBmb3J0aC4gSWYgdGhlcmUgYXJlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBzdWNoIGFzIHRoZSBv bmVzIGVudW1lcmF0ZWQsIHRoZSBsYXRlbmN5IGFuZCBjb25uZWN0aXZpdHkgaXNzdWVzIGFyZW7i gJl0IGEgYmxvY2tpbmcgZmFjdG9yOyBhbmQgaWYgdGhlcmUgYXJlbid0LCBub3RoaW5nIHByZXZl bnRzIHlvdSBmcm9tIGhhdmluZyBhIGxvZ2ljYWwgYXVkaWVuY2UgdmFsdWUuIEZyb20gdGhlIGV4 cHJlc3NpdmUgcG93ZXIgcG9pbnQgb2YgdmlldywgdGhlIHJlcXVpcmVtZW50IG9mIGhhdmluZyBh IHNpbmdsZSBhdWRpZW5jZSBkb2Vucyd0IHByZXZlbnQgeW91IGZyb20gZG9pbmcgYW55IG9mIHRo ZSBzaW5nbGUgdG9rZW4gbG9naWMgeW91IGFyZSBoaW50aW5nIGF0LSBlc3BlY2lhbGx5IGlmIHlv dSBwbGFuIHRvIHVzZSBzcGVjaWFsaXplZCBzY29wZXMgYW55d2F5Lg0KDQoNCg0KDQoNCg0KDQog ICAgICAgPiAgIMOvwr/CvcOvwr/CvSBJbiBzdW1tYXJ5LCBJIGZlZWwgdGhhdCB0aGlzIHRleHQg aXMgYmluZGluZyB0b28gdGlnaHRseSByZXNvdXJjZQ0KDQoNCg0KICAgICAgICBpbmRpY2F0b3Jz IHRvIHRoZSBhdWRpZW5jZSBjbGFpbS4gV2hhdCBpcyBkZXNjcmliZWQgaXMgcGVyZmVjdGx5DQoN Cg0KDQogICAgICAgIHJlYXNvbmFibGUgaW4gYSB1c2UgY2FzZSB0aGF0IGlzIGFwcGx5aW5nIHJl c291cmNlIGluZGljYXRvcnMgaW4gdGhpcw0KDQoNCg0KICAgICAgICB3YXkgYnV0IGlzIG5vdCBp bmRpY2F0aXZlIG9mIHRoZSB3aWRlbHkgZGVwbG95ZWQgbW9kZWxzIHRoYXQgYWxyZWFkeSBleGlz dC4NCg0KDQoNCiAgICBXZSBtaWdodCBoYXZlIGRpZmZlcmVudCBleHBlcmllbmNlcyBoZXJlLiBU aGUgSldUIGFjY2VzcyB0b2tlbnMgZnJvbSBwb3B1bGFyIHByb2R1Y3RzIEkgc3R1ZGllZCBpbiB0 aGUgcmVzZWFyY2ggSSBwcmVzZW50ZWQgaW4gU3R1dHRnYXJ0IHdlcmUgYWxtb3N0IGFsbCB1c2lu ZyB0aGUgYXVkIGNsYWltIGluIHRoaXMgd2F5LiBJIGFtIHN1cmUgdGhhdCB0aGVyZSBhcmUgb3Ro ZXIgbW9kZWxzLCBhbmQgdGhlcmUgd2FzIGF0IGxlYXN0IG9uZSBleGNlcHRpb24sIGJ1dCBpbiBp bnRlcm9wIHRlcm1zIHRoaXMgc2VlbXMgdG8gYmUgdGhlIG1vc3QgY29tbW9uIHdheSBvZiB1c2lu ZyBKV1QgZm9yIEFUcy0gYW5kIGl0IGhhcyB0aGUgYWR2YW50YWdlIG9mIGJlaW5nIHZlcnkgc2lt cGxlIGFuZCB1bmFtYmlndW91cy4NCg0KDQoNCg0KDQoNCg0KICAgID4gU2VjdGlvbiA0LiBWYWxp ZGF0aW5nIEpXVCBBY2Nlc3MgVG9rZW5zDQoNCg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gU3Rl cCA0LiAtLSBDYW4gd2UgY2hhbmdlIHRoZSB3b3JkaW5nIHRvIG5vdCByZXF1aXJlIHJlc291cmNl DQoNCg0KDQogICAgICAgIGluZGljYXRvcnM/IFdoYXQgYWJvdXQuLi4gIlRoZSByZXNvdXJjZSBz ZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGF0IHRoZQ0KDQoNCg0KICAgICAgICAnYXVkJyBjbGFpbSBj b250YWlucyBhIHN0cmluZyB0aGF0IHJlcHJlc2VudHMgdGhlIGF1ZGllbmNlIG9mIHRoaXMNCg0K DQoNCiAgICAgICAgcmVzb3VyY2Ugc2VydmVyLiINCg0KDQoNCiAgICBDb3VsZCB5b3UgbWFrZSBh biBleGFtcGxlIGluIHdoaWNoIHlvdSdkIHdhbnQgdG8gdXNlIGFuIGlkZW50aWZpZXIgdGhhdCBp cyBub3QgYSByZXNvdXJjZSBpbmRpY2F0b3I/IEdpdmVuIHRoYXQgd2UgaGF2ZSB0aGUgc3BlYywg YW5kICJhdWRpZW5jZSBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIiBzZWVtcyB0byBiZSB0aGUgZXhh Y3Qgc2VtYW50aWMgb2YgcmVzb3VyY2UgaW5kaWNhdG9ycywgaXQgc2VlbWVkIGEgc2xhbSBkdW5r IHRvIHVzZSBpdCBoZXJlLi4uDQoNCg0KDQoNCg0KDQoNCiAgICAgICA+IFNlY3Rpb24gNS4gImNy b3NzLUpXVCBjb25mdXNpb24iDQoNCg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gSSB0aGluayB0 aGVyZSBtYXkgYmUgY29uZnVzaW9uIGFyb3VuZCB3aGF0IGlzIG1lYW50IGJ5ICJkaXN0aW5jdA0K DQoNCg0KICAgICAgICByZXNvdXJjZXMiLiBJbiBteSBleGFtcGxlIGFib3ZlLCBhcmUgc3J2YS5t eWNvLmV4YW1wbGUgYW5kDQoNCg0KDQogICAgICAgIHNydmIubXljby5leGFtcGxlICJkaXN0aW5j dCByZXNvdXJjZXMiPyBvciBpcyB0aGUgZ29hbCBoZXJlIHRvIHNheSB0aGF0DQoNCg0KDQogICAg ICAgIHdlIHdhbnQgZGlmZmVyZW50IGF1ZGllbmNlIHZhbHVlcyBnZW5lcmF0ZWQgZm9yIGNyb3Nz LW9yZ2FuaXphdGlvbg0KDQoNCg0KICAgICAgICByZXNvdXJjZXMuIEZvciBleGFtcGxlLCBhcmUg bWFpbC5nb29nbGUuY29tIGFuZCB5b3V0dWJlLmNvbSAiZGlzdGluY3QNCg0KDQoNCiAgICAgICAg cmVzb3VyY2VzIj8gb3Igd291bGQgYW4gYXVkaWVuY2UgZm9yIGdvb2dsZSBzdWZmaWNlIGluIG1l ZXRpbmcgdGhlDQoNCg0KDQogICAgICAgIG1lYW5pbmcgb2YgdGhpcyBwYXJhZ3JhcGg/DQoNCg0K DQogICAgSSB0aGluayB0aGUga2V5IHBvaW50IGhlcmUgaXMgLSB3ZSBkb27igJl0IGtub3cuIEkg YWdyZWUgdGhlIGxhbmd1YWdlIGlzbid0IGNsZWFyIHRoZXJlLiBMZXQgbWUgZXhwYW5kIG9uIHRo ZSBpbnRlbnQsIGFuZCBwZXJoYXBzIHdlIGNhbiBnZXQgdG8gYSBiZXR0ZXIgZm9ybXVsYXRpb24u DQoNCg0KDQogICAgT0F1dGgyIGRvZXNu4oCZdCBkZW1hbmQgdGhhdCBSUyBhbmQgQVMgYXJlIHJ1 biBieSB0aGUgc2FtZSBlbnRpdHksIGJ1dCB0aGF0J3MgdGhlIG1vc3QgY29tbW9uIHNjZW5hcmlv LiBGQiBkb2Vzbid0IG5lZWQgdG8gc3BlY2lmeSBhIHJlc291cmNlLCBiZWNhdXNlIHRoZSByZXNv dXJjZSBpcyBpbXBsaWNpdC4uIGl0J3MgdGhlIEZCIGdyYXBoLCB5b3UgY2Fu4oCZdCBnZXQgYSB0 b2tlbiBmb3IgYW55dGhpbmcgZWxzZS4gVGhlIG9ubHkgZGlmZmVyZW50aWF0b3IgZW5kcyB1cCBi ZWluZyB0aGUgc2NvcGVzLiBTYW1lIGZvciBtYW55IG90aGVyIHByb3ZpZGVycywgZ29vZ2xlLCBN aWNyb3NvZnQgZm9yIGl0cyBvd24gR3JhcGgsIGV0Yy4NCg0KDQoNCiAgICBIb3dldmVyIG1hbnkg QVMgYXMgYSBzZXJ2aWNlIGRvbuKAmXQgaGF2ZSB0aGUgYmVuZWZpdCBvZiBhIGRlZmF1bHQsIGlt cGxpY2l0IHJlc291cmNlLCBlc3BlY2lhbGx5IGluIG11bHRpIHRlbmFuY3kgc2NlbmFyaW9zLCBn aXZlbiB0aGF0IHRoZXknbGwgbmVlZCB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgbnVtYmVyIG9mIGRp ZmZlcmVudCByZWNpcGllbnRzLiBXaGV0aGVyIHJlc291cmNlcyBhcmUgY3Jvc3Mgb3JnYW5pemF0 aW9uLCBvciBjcm9zcyBkZXBhcnRtZW50LCBvciBmb2xsb3dpbmcgYW55IG90aGVyIGFyYml0cmFy eSBzZWdyZWdhdGlvbi9mYWN0b3JpbmcgbW9kZWwgaXMgc29tZXRoaW5nIHdlIGNhbm5vdCBpbmZl ci0gaXQncyB1cCB0byB0aGUgZGV2ZWxvcGVyIHRvIGRldGVybWluZSB0aGF0LiBXaGF0IEkgYW0g dHJ5aW5nIHRvIGV4cHJlc3MgaGVyZSBpcyB0aGF0IHRoZSBvcGVyYXRvciBvZiB0aGUgQVMgYXMg YSBzZXJ2aWNlIChvciBhbnkgb3RoZXIgZm9ybSBvZiAiQVMgZm9yIHJlbnQiKSBzaG91bGQgc3Vy ZmFjZSByZXNvdXJjZXMgYXMgYSBwcmltaXRpdmUgZm9yIG1vZGVsaW5nIGFuZCBpZGVudGlmeWlu ZyBpbnRlbmRlZCByZWNpcGllbnRzIG9mIEFUcy4gRG9lcyB0aXMgaGVscD8gSG93IHdvdWxkIHlv dSBleHByZXNzIHRoYXQ/DQoNCg0KDQoNCg0KDQoNCiAgICA+ICAgICAgw6/Cv8K9IEknbSBoYXZp bmcgdGhlIHNhbWUgY29uZnVzaW9uIGluIHRoZSBuZXh0IHBhcmFncmFwaCByZWdhcmRpbmcgdGhl DQoNCg0KDQogICAgICAgIHBocmFzZSAiZGlmZmVyZW50IHJlc291cmNlcyIuIEFyZSBzZXJ2aWNl cyBwcm92aWRlZCBieSB0aGUgc2FtZSBjb21wYW55DQoNCg0KDQogICAgICAgICJkaWZmZXJlbnQg cmVzb3VyY2VzIiBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2FtZSByZXNvdXJjZS4g Q2FuDQoNCg0KDQogICAgICAgIGFuIGFjY2VzcyB0b2tlbiBiZSBpc3N1ZWQgd2l0aCBzY29wZXMg Zm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZA0KDQoNCg0KICAgICAgICB5b3V0dWJlLmNvbT8g QW5kIGlmIG5vdCwgd2h5IG5vdGU/IFByZXZlbnRpbmcgdGhpcyBwdXRzIHVuZHVlIGJ1cmRlbiBv bg0KDQoNCg0KICAgICAgICBtb2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLg0KDQoNCg0KICAgIFNl ZSBwcmVjZWRpbmcgcG9pbnQuIFdlIGNhbid0IGVudGVyIGluIHRoZSBtZXJpdCBvZiB3aGF0IGNv bnN0aXR1dGVzIGEgcmVzb3VyY2UsIGFzIHRoYXQgZGVwZW5kcyBvbiB0aGUgbW9kZWxpbmcgb2Yg dGhlIGRvbWFpbiBzcGVjaWZpYyBwcm9ibGVtIHRoZSBkZXZlbG9wZXIgaXMgdGFja2xpbmcuIFRo ZSBoaWdoZXN0IG9yZGVyIGJpdCBpcyB0aGF0IGlmIHR3byBlbnRpdGllcyAoQVBJLCBldGMuLiBp bnRlbmRlZCB0b2tlbiByZWNpcGllbnRzKSBoYXZlIGRpZmZlcmVudCBzZWN1cml0eSBjaGFyYWN0 ZXJpc3RpY3MgKGUuZy4gbGVha2luZyBhIHRva2VuIGZvciBvbmUgaGFzIGRpZmZlcmVudCBjb25z ZXF1ZW5jZXMgdGhhbiBpZiB5b3UnZCBsZWFrIGEgdG9rZW4gZm9yIHRoZSBvdGhlciksIHRoZXkg c2hvdWxkIGJlIG1vZGVsZWQgYXMgZGlmZmVyZW50IHJlc291cmNlcy4gQW5kIGlmIHRoZXkgYXJl IGRpZmZlcmVudCByZXNvdXJjZXMsIHdlIHNob3VsZCBkbyB3aGF0IHdlIGNhbiB0byBhdm9pZCBj b25mdXNpb24gaW4gaG93IHdlIGV4cHJlc3MgYWNjZXNzIGdyYW50cyB0byB0aGVtIChoZW5jZSB0 aGUgYmlnIGRpc2N1c3Npb24gb24gbXVsdGlyZXNvdXJjZSwgc2NvcGUgY29uZnVzaW9uLCBldGMp Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICAtLS0tLS0tLS0NCg0KDQoNCiAgICBPbiAzLzI0 LzIwLCAxMDozOSwgIkdlb3JnZSBGbGV0Y2hlciIgPGdmZmxldGNoQGFvbC5jb20+PG1haWx0bzpn ZmZsZXRjaEBhb2wuY29tPiB3cm90ZToNCg0KDQoNCg0KDQoNCg0KICAgICAgICBGZWVkYmFjayBv biB0aGUgc3BlYy4uLg0KDQoNCg0KDQoNCg0KDQogICAgICAgIFNlY3Rpb24gMS4gSW50cm9kdWN0 aW9uDQoNCg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr3Dr8K/wr0gc2Vjb25kIGxpbmU6IHNjZW5h cmlvIHNob3VsZCBiZSBwbHVyYWwgLS0+IHNjZW5hcmlvcw0KDQoNCg0KICAgICAgICAgw6/Cv8K9 w6/Cv8K9w6/Cv8K9IHNlY29uZCBzZW50ZW5jZTogImFyZSBub3QgcmFuIGJ5IiAtLT4gImFyZSBu b3QgcnVuIGJ5Ig0KDQoNCg0KDQoNCg0KDQogICAgICAgIFNlY3Rpb24gMi4yLjEgQXV0aGVudGlj YXRpb24gSW5mb3JtYXRpb24gQ2xhaW1zDQoNCg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr3Dr8K/ wr0gSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBkZWZpbml0aW9uIG9mIGBhdXRoX3RpbWVgIGFsbG93 cyBmb3IgdGhlDQoNCg0KDQogICAgICAgIGNhc2Ugd2hlcmUgYSB1c2VyIGlzIHJlcXVpcmVkIHRv IHNvbHZlIGFuIGFkZGl0aW9uYWwgY2hhbGxlbmdlLiBUYWtlIHRoZQ0KDQoNCg0KICAgICAgICBj YXNlIG9mIGEgdXNlciB3aG8gaXMgcmVxdWlyZWQgdG8gcGFzcyBhIHNlY29uZGFyeSBjaGFsbGVu Z2UgYmVmb3JlIHRoZQ0KDQoNCg0KICAgICAgICAic3RvY2sgcHVyY2hhc2UiIGFjdGlvbiBjYW4g YmUgY29tcGxldGVkLiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgc3BlYw0KDQoNCg0KICAgICAg ICBkZWZpbml0aW9uLCB0aGUgYGF1dGhfdGltZWAgdmFsdWUgTVVTVCBOT1QgYmUgdXBkYXRlZCB3 aGVuIHRoaXMNCg0KDQoNCiAgICAgICAgc2Vjb25kYXJ5IGNoYWxsZW5nZSBpcyBjb21wbGV0ZWQu DQoNCg0KDQoNCg0KDQoNCiAgICAgICAgIMOvwr/CvcOvwr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJl IGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlc3Npb25fc3RhcnRfdGltZSBhbmQgbGFzdA0KDQoN Cg0KICAgICAgICBhdXRoX3RpbWUuIFRoaXMgZmVlbHMgbW9yZSBsaWtlIGl0J3MgZGVmaW5pbmcg dGhlIHNlc3Npb25fc3RhcnRfdGltZQ0KDQoNCg0KICAgICAgICBjb25jZXB0Lg0KDQoNCg0KDQoN Cg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gVGhlc2Ugc2FtZSBpc3N1ZXMgY2FuIGFwcGx5IHRv IHRoZSBgYWNyYCBhbmQgYGFtcmAgdmFsdWVzIGFzIHdlbGwuDQoNCg0KDQoNCg0KDQoNCiAgICAg ICAgIMOvwr/CvcOvwr/CvSBFdmVuIGlmIGZvciB0aGlzIHNlY29uZGFyeSBjaGFsbGVuZ2UgYSBu ZXcgcmVmcmVzaF90b2tlbiBpcyBpc3N1ZWQsDQoNCg0KDQogICAgICAgIGl0IGlzIHVubGlrZWx5 IG1hbnkgcmVseWluZyBwYXJ0aWVzIHdpbGwgd2FudCB0byB0cmVhdCB0aGF0IGFzIGlzc3Vpbmcg YQ0KDQoNCg0KICAgICAgICBuZXcgc2Vzc2lvbi4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgdXNl ciBsb2dnZWQgaW4gdG8gYSBzaW5nbGUgc2Vzc2lvbi4NCg0KDQoNCg0KDQoNCg0KICAgICAgICBT ZWN0aW9uIDIuMi4zIEF1dGhvcml6YXRpb24gQ2xhaW1zDQoNCg0KDQogICAgICAgICDDr8K/wr3D r8K/wr0gSSBmaW5kIHRoZSBzdGF0ZW1lbnQgIkFsbCB0aGUgaW5kaXZpZHVhbCBzY29wZSBzdHJp bmdzIGluIHRoZSBzY29wZQ0KDQoNCg0KICAgICAgICBjbGFpbSBNVVNUIGhhdmUgbWVhbmluZyBm b3IgdGhlIHJlc291cmNlIGluZGljYXRlZCBpbiB0aGUgYXVkIGNsYWltIg0KDQoNCg0KICAgICAg ICBzb21ld2hhdCBwcm9ibGVtYXRpYy4gSW4gbWFueSBkZXBsb3ltZW50cyB0b2RheSBmb3IgMXN0 IHBhcnR5IGNsaWVudHMgdG8NCg0KDQoNCiAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGFuZCB0YWtpbmcgaW50byBhY2NvdW50IG1vYmlsZSBhcHBsaWNhdGlvbnMsDQoNCg0KDQogICAg ICAgIHRoZSBhY2Nlc3MgdG9rZW4gbW9zdCBsaWtlIGNvbnRhaW5zIHNjb3BlcyBmb3IgbWFueSBv ZiB0aGUgMXN0IHBhcnR5DQoNCg0KDQogICAgICAgIGJhY2tlbmQgQVBJcy4gSXQncyBwb3NzaWJs ZSB0byBnZXQgYXJvdW5kIHRoaXMgYnkgc2V0dGluZyB0aGUgJ2F1ZCcNCg0KDQoNCiAgICAgICAg Y2xhaW0gdG8gc29tZXRoaW5nIGxpa2UgImNvbS5leGFtcGxlLmFwaXMiIGFuZCBoZW5jZSBhbGwg dGhlIGlzc3VlZA0KDQoNCg0KICAgICAgICBzY29wZXMgbWFwIHRvIHRoYXQgYXVkaWVuY2UgY2xh aW0gYnV0IHRoYXQgaXMganVzdCB3b3JraW5nIGFyb3VuZCB0aGUNCg0KDQoNCiAgICAgICAgTVVT VCBpbiB0aGUgc3BlYy4gR2l2ZW4gdGhlIGxhY2sgb2Ygc3BlY2lmaWNpdHkgb2YgdGhlICdhdWQn IGNsYWltIGFuZA0KDQoNCg0KICAgICAgICB0aGUgJ3Jlc291cmNlIGluZGljYXRvcicgY2xhaW0g Zm9yIHRoYXQgbWF0dGVyLCBwcmV0dHkgbXVjaCBhbnl0aGluZyBjYW4NCg0KDQoNCiAgICAgICAg YmUgbWFkZSB0byBjb21wbHkuIEluIHRoYXQgY29udGV4dCwgaXQgc2VlbXMgbGlrZSBSRUNPTU1F TkQgaXMgYSBiZXR0ZXINCg0KDQoNCiAgICAgICAgbm9ybWF0aXZlIGNsYXVzZS4NCg0KDQoNCg0K DQoNCg0KICAgICAgICBTZWN0aW9uIDMuIFJlcXVlc3RpbmcgYSBKV1QgQWNjZXNzIFRva2VuDQoN Cg0KDQogICAgICAgICDDr8K/wr3Dr8K/wr0gUGVyIG15IGNvbW1lbnRzIGFib3ZlIEkgc3VzcGVj dCB0aGF0IHJlcXVpcmluZyBhbGwgSldUIGFjY2VzcyB0b2tlbnMNCg0KDQoNCiAgICAgICAgdG8g aW5jbHVkZSBhbiBhdWRpZW5jZSBjbGFpbSB3aWxsIGp1c3QgZGV2b2x2ZSB0byBhdWRpZW5jZSBj bGFpbXMgdGhhdA0KDQoNCg0KICAgICAgICBhcmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRl ciB0byBtZWV0IHRoaXMgTVVTVCBpbiB0aGUgc3BlYykuIEdpdmVuDQoNCg0KDQogICAgICAgIHRo ZSBtb2JpbGUgYXBwIGVudmlyb25tZW50IHRvZGF5LCBpdCBpcyB1bnJlYXNvbmFibGUgdG8gYXNr IHRoZSBtb2JpbGUNCg0KDQoNCiAgICAgICAgYXBwcyB0byBkb3duc2NvcGUgZXZlcnkgYWNjZXNz IHRva2VuIGJlZm9yZSBtYWtpbmcgYW4gQVBJIGNhbGwgdG8gdGhlDQoNCg0KDQogICAgICAgIGJh Y2tlbmQgQVBJcyB3aGljaCBpcyB3aGF0IHRoZSBzcGlyaXQgb2YgYXVkaWVuY2UgYW5kIHJlc291 cmNlDQoNCg0KDQogICAgICAgIGluZGljYXRvcnMgc2VlbSB0byBpbXBseS4NCg0KDQoNCg0KDQoN Cg0KICAgICAgICAgw6/Cv8K9w6/Cv8K9IFdoeSBNVVNUIHRoZSBBUyByZWplY3QgYSByZXF1ZXN0 IHdpdGggbW9yZSB0aGFuIG9uZSByZXNvdXJjZQ0KDQoNCg0KICAgICAgICBwYXJhbWV0ZXI/IElm IGEgcmVxdWVzdCBjb21lcyBpbiB3aXRoIG5vIHJlc291cmNlIHBhcmFtZXRlciBhbmQgbXVsdGlw bGUNCg0KDQoNCiAgICAgICAgc2NvcGVzIHRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gcmVqZWN0 IHRoYXQgcmVxdWVzdC4gSXMgdGhlcmUgbXVjaCBvZiBhDQoNCg0KDQogICAgICAgIHNlbWFudGlj IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvPyBJbiB0aGUgY2FzZSBvZiBubyByZXNvdXJjZQ0K DQoNCg0KICAgICAgICBwYXJhbWV0ZXIgYW5kIG11bHRpcGxlIHNjb3BlcyB0aGUgQVMgbWlnaHQg aXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGgNCg0KDQoNCiAgICAgICAgbXVsdGlwbGUgYXVkaWVu Y2UgdmFsdWVzIChhcyBpcyBhbGxvd2VkIGJ5IFJGQyA3NTE5KS4gQWxzbywgdGhlIGF1ZGllbmNl DQoNCg0KDQogICAgICAgIGNsYWltIGlzIG5vdCBzb2xlbHkgZm9yIHJlc291cmNlIGluZGljYXRv ciB2YWx1ZXMgYnV0IGlzIGRlZmluZWQgdG8ganVzdA0KDQoNCg0KICAgICAgICBiZSBhIHN0cmlu Zy4gVG8gbWUgaXQgZmVlbHMgbGlrZSB0aGUgdGV4dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5 DQoNCg0KDQogICAgICAgIHZhbGlkIGF1ZGllbmNlIHZhbHVlIGlzIGFsc28gYSByZXNvdXJjZSBp bmRpY2F0b3IgKHdoaWNoIGZyb20gcHJldmlvdXMNCg0KDQoNCiAgICAgICAgZGlzY3Vzc2lvbnMg b24gdGhlIGxpc3QgaXQgd2FzIGltcGxpZWQgdGhleSBoYXZlIGEgc2xpZ2h0bHkgZGlmZmVyZW50 DQoNCg0KDQogICAgICAgIHNlbWFudGljKS4NCg0KDQoNCg0KDQoNCg0KICAgICAgICAgw6/Cv8K9 w6/Cv8K9IFRoZSBtb2RlbCBkZXNjcmliZWQgaGVyZSB3b3JrcyB3ZWxsIGlmIG15Y28uZXhhbXBs ZSByZWFsbHkgb25seQ0KDQoNCg0KICAgICAgICBwcm92aWRlcyBhIHNpbmdsZSBzZXJ2aWNlLiBC dXQgaWYgaW5zdGVhZCBteWNvLmV4YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGUNCg0KDQoNCiAgICAg ICAgc2VydmljZXMgZWFjaCB3aXRoIHRoZWlyIG93biBlbmRwb2ludHMgKHNydmEubXljby5leGFt cGxlLA0KDQoNCg0KICAgICAgICBzcnZiLm15Y28uZXhhbXBsZSkgYW5kIHNjb3BlcywgZm9yIG1l IHRoaXMgbW9kZWwgYmVnaW5zIHRvIGJyZWFrIGRvd24uDQoNCg0KDQogICAgICAgIEVpdGhlciBt b2JpbGUgYXBwcyBhcmUgcmVxdWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tlbnMgdG8ganVzdCB0 aGUNCg0KDQoNCiAgICAgICAgc2VydmljZSB0aGV5IGFyZSBjYWxsaW5nIGF0IHRoYXQgcG9pbnQg aW4gdGltZSAod2hpY2ggY2FuIGhhdmUgbGF0ZW5jeQ0KDQoNCg0KICAgICAgICBhbmQgY29ubmVj dGl2aXR5IGlzc3VlcyksIG9yIG15Y28uZXhhbXBsZSBoYXMgdG8gY3JlYXRlIGEgZ2VuZXJpYw0K DQoNCg0KICAgICAgICAiYXVkaWVuY2UiIHN0cmluZyB0aGF0IHJlcHJlc2VudHMgYWxsIG9mIGV4 YW1wbGUuY29tIHdoaWNoIGRvZXNuJ3Qgc2VlbQ0KDQoNCg0KICAgICAgICB0byBiZSB0aGUgc3Bp cml0IG9mIHRoZSBleGlzdGluZyBzcGVjcy4NCg0KDQoNCg0KDQoNCg0KICAgICAgICAgw6/Cv8K9 w6/Cv8K9IEluIHN1bW1hcnksIEkgZmVlbCB0aGF0IHRoaXMgdGV4dCBpcyBiaW5kaW5nIHRvbyB0 aWdodGx5IHJlc291cmNlDQoNCg0KDQogICAgICAgIGluZGljYXRvcnMgdG8gdGhlIGF1ZGllbmNl IGNsYWltLiBXaGF0IGlzIGRlc2NyaWJlZCBpcyBwZXJmZWN0bHkNCg0KDQoNCiAgICAgICAgcmVh c29uYWJsZSBpbiBhIHVzZSBjYXNlIHRoYXQgaXMgYXBwbHlpbmcgcmVzb3VyY2UgaW5kaWNhdG9y cyBpbiB0aGlzDQoNCg0KDQogICAgICAgIHdheSBidXQgaXMgbm90IGluZGljYXRpdmUgb2YgdGhl IHdpZGVseSBkZXBsb3llZCBtb2RlbHMgdGhhdCBhbHJlYWR5IGV4aXN0Lg0KDQoNCg0KDQoNCg0K DQogICAgICAgIFNlY3Rpb24gNC4gVmFsaWRhdGluZyBKV1QgQWNjZXNzIFRva2Vucw0KDQoNCg0K ICAgICAgICAgw6/Cv8K9w6/Cv8K9IFN0ZXAgNC4gLS0gQ2FuIHdlIGNoYW5nZSB0aGUgd29yZGlu ZyB0byBub3QgcmVxdWlyZSByZXNvdXJjZQ0KDQoNCg0KICAgICAgICBpbmRpY2F0b3JzPyBXaGF0 IGFib3V0Li4uICJUaGUgcmVzb3VyY2Ugc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhhdCB0aGUNCg0K DQoNCiAgICAgICAgJ2F1ZCcgY2xhaW0gY29udGFpbnMgYSBzdHJpbmcgdGhhdCByZXByZXNlbnRz IHRoZSBhdWRpZW5jZSBvZiB0aGlzDQoNCg0KDQogICAgICAgIHJlc291cmNlIHNlcnZlci4iDQoN Cg0KDQoNCg0KDQoNCiAgICAgICAgU2VjdGlvbiA1LiAiY3Jvc3MtSldUIGNvbmZ1c2lvbiINCg0K DQoNCiAgICAgICAgIMOvwr/CvcOvwr/CvSBJIHRoaW5rIHRoZXJlIG1heSBiZSBjb25mdXNpb24g YXJvdW5kIHdoYXQgaXMgbWVhbnQgYnkgImRpc3RpbmN0DQoNCg0KDQogICAgICAgIHJlc291cmNl cyIuIEluIG15IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhhbXBsZSBhbmQNCg0KDQoN CiAgICAgICAgc3J2Yi5teWNvLmV4YW1wbGUgImRpc3RpbmN0IHJlc291cmNlcyI/IG9yIGlzIHRo ZSBnb2FsIGhlcmUgdG8gc2F5IHRoYXQNCg0KDQoNCiAgICAgICAgd2Ugd2FudCBkaWZmZXJlbnQg YXVkaWVuY2UgdmFsdWVzIGdlbmVyYXRlZCBmb3IgY3Jvc3Mtb3JnYW5pemF0aW9uDQoNCg0KDQog ICAgICAgIHJlc291cmNlcy4gRm9yIGV4YW1wbGUsIGFyZSBtYWlsLmdvb2dsZS5jb20gYW5kIHlv dXR1YmUuY29tICJkaXN0aW5jdA0KDQoNCg0KICAgICAgICByZXNvdXJjZXMiPyBvciB3b3VsZCBh biBhdWRpZW5jZSBmb3IgZ29vZ2xlIHN1ZmZpY2UgaW4gbWVldGluZyB0aGUNCg0KDQoNCiAgICAg ICAgbWVhbmluZyBvZiB0aGlzIHBhcmFncmFwaD8NCg0KDQoNCg0KDQoNCg0KICAgICAgICAgw6/C v8K9IEknbSBoYXZpbmcgdGhlIHNhbWUgY29uZnVzaW9uIGluIHRoZSBuZXh0IHBhcmFncmFwaCBy ZWdhcmRpbmcgdGhlDQoNCg0KDQogICAgICAgIHBocmFzZSAiZGlmZmVyZW50IHJlc291cmNlcyIu IEFyZSBzZXJ2aWNlcyBwcm92aWRlZCBieSB0aGUgc2FtZSBjb21wYW55DQoNCg0KDQogICAgICAg ICJkaWZmZXJlbnQgcmVzb3VyY2VzIiBvciBhcmUgdGhleSBhbGwgY29uc2lkZXJlZCB0aGUgc2Ft ZSByZXNvdXJjZS4gQ2FuDQoNCg0KDQogICAgICAgIGFuIGFjY2VzcyB0b2tlbiBiZSBpc3N1ZWQg d2l0aCBzY29wZXMgZm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZA0KDQoNCg0KICAgICAgICB5 b3V0dWJlLmNvbT8gQW5kIGlmIG5vdCwgd2h5IG5vdGU/IFByZXZlbnRpbmcgdGhpcyBwdXRzIHVu ZHVlIGJ1cmRlbiBvbg0KDQoNCg0KICAgICAgICBtb2JpbGUgYmFzZWQgYXBwbGljYXRpb25zLg0K DQoNCg0KDQoNCg0KDQogICAgICAgIFNlY3Rpb24gNi4gUHJpdmFjeQ0KDQoNCg0KICAgICAgICAg w6/Cv8K9w6/Cv8K9IGNvZmlkZW50aWFsaXR5IC0tPiBjb25maWRlbnRpYWxpdHkNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQogICAgICAgIFRoYW5rcywNCg0KDQoNCiAgICAgICAgR2VvcmdlDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KICAgIE9BdXRoIG1haWxpbmcgbGlz dA0KDQoNCg0KICAgIE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KDQoN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoN Cg0KDQoNCg0KDQo= --_000_897809C25ABB43A499650950EC7126F5amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNo byI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzdXBwb3J0IHJlbGF4aW5nIHRoZSBsYW5n dWFnZSB0aGF0IGNsZWFybHkgdGFyZ2V0cyB0aGUgaXNzdWUg4oCTIGF1dGhvcml6YXRpb24gY29u ZnVzaW9uIOKAkyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPlRoZSBBUyBNVVNUIE5PVCBpc3N1 ZSBhIEpXVCBhY2Nlc3MgdG9rZW4gaWYgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnRlZCBieSB0aGUg dG9rZW4gd291bGQgYmUgYW1iaWd1b3VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3Vy cmVudCBkcmFmdCBsYW5ndWFnZSBiYXNpY2FsbHkgdGFrZXMgYSBoZXVyaXN0aWMgYXBwcm9hY2gg dG8gdGhpcywgcHJvaGliaXRpbmcgY2VydGFpbiBwYXR0ZXJucyB0aGF0IG1pZ2h0IGxlYWQgdG8g dGhpcyBzY2VuYXJpby4gSWYgd2UgdGFyZ2V0IHRoZSBpc3N1ZSBkaXJlY3RseSBhbmQgcHJvdmlk ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyB0ZXh0IGVsYWJvcmF0aW5nIG9uIHNvbWUgb2YgdGhl DQogd2F5cyB0aGlzIGNhbiBvY2N1ciwgd2UgYWxsb3cgZGVwbG95bWVudHMgdG8gZGV0ZXJtaW5l IHdoZXRoZXIgb3Igbm90IGl0IGFwcGxpZXMgaW4gdGhlaXIgY29udGV4dC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2UgY2Fu4oCZdCBmaXggdGhlIGZhY3QgdGhhdCBzY29wZXMgYXJlIGFtYmln dW91cyBhbmQgZW50aXJlbHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIFRoYXQgaG9yc2UgbGVm dCB0aGUgYmFybiB3aXRoIDY3NDkuIElmIHdlIHRyeSB0byBhZGRyZXNzIHRoaXMgYnkgaW50cm9k dWNpbmcgbmV3IGxpbWl0YXRpb25zIG9uIHNjb3BlcyB3aXRoaW4gc3BlY3MgbGlrZSB0aGlzIG9u ZSwgd2XigJlyZSBnb2luZyB0byBlbmQNCiB1cCB3aXRoIGVhY2ggbmV3IHNwZWMgaW1wb3Npbmcg aXRzIG93biByZXN0cmljdGlvbnMsIHdoaWNoIHdpbGwgYXJ0aWZpY2lhbGx5IGxpbWl0IHRoZSBz cGVj4oCZcyB1dGlsaXR5IGFuZCBtYXkgaW50cm9kdWNlIGluY29tcGF0aWJpbGl0aWVzIGJldHdl ZW4gc3BlY3MgZHVlIHRvIGluY29uc2lzdGVudCByZXN0cmljdGlvbnMuIERldmVsb3BlcnMgd2ls bCBiZSBsZWZ0IHRvIHRyeSB0byBwaWVjZSBpdCBhbGwgdG9nZXRoZXIgdG8gZmlndXJlIG91dA0K IGlmIHRoZWlyIHVzZSBjYXNlIGlzIHBlcm1pdHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHdheSB3ZSBkaWcgb3Vyc2VsdmVzIG91dCBvZiB0aGlzIGhvbGUgaXMgdGhyb3VnaCBSaWNo IEF1dGhvcml6YXRpb24gUmVxdWVzdHMuIFRoYXQgZHJhZnQgaXMgb3VyIG9wcG9ydHVuaXR5IHRv IGdldCB0aGlzIHJpZ2h0LCB2aWEg4oCcYSBsb3QgbW9yZSBzcGVjIHdvcmvigJ0gYXMgR2Vvcmdl IHB1dCBpdC4gSW5jaWRlbnRhbGx5LCBpZiB3ZSB0aGluayBhYm91dCBSQVIgaW4gdGhlIGNvbnRl eHQgb2YgSldUIGFjY2Vzcw0KIHRva2VucywgaXTigJlzIGltbWVkaWF0ZWx5IG9idmlvdXMgd2h5 IGEgbXVsdGktdmFsdWUgYXVkIGNsYWltIG5lZWRzIHRvIGJlIGFsbG93ZWQuIElmIG15IHRva2Vu IGNvbnRhaW5zIGFuIOKAnGF1dGhvcml6YXRpb27igJ0gY2xhaW0gY29udGFpbmluZyBhIFJBUiBv YmplY3QgdGhhdCBncmFudHMgZmluZS1ncmFpbmVkIGF1dGhvcml6YXRpb24gb24gZGlmZmVyZW50 IHJlc291cmNlcyBhY3Jvc3MgZGlmZmVyZW50IGVuZHBvaW50cywgbXkgYXVkIHZhbHVlIHNob3Vs ZA0KIGJlIGFibGUgdG8gbWF0Y2ggdGhhdC4gSXTigJlkIGJlIHNpbGx5IHRvIGhhdmUgdG8gaGF2 ZSBhbiBhdWQgY2xhaW0gb2Yg4oCcYXBpLmFwcC5leGFtcGxl4oCdIGlmIG15IGF1dGhvcml6YXRp b24gaXMgdGlnaHRseSBib3VuZCB0byDigJxlbWFpbC5hcHAuZXhhbXBsZeKAnSBhbmQg4oCcY29u dGFjdHMuYXBwLmV4YW1wbGXigJ0gdGhyb3VnaCBSQVIuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BV1MgSWRl bnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9p ZGVudGl0eS8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2F3cy5hbWF6b24u Y29tL2lkZW50aXR5Lzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+R2VvcmdlIEZsZXRjaGVyICZs dDtnZmZsZXRjaEBhb2wuY29tJmd0Ozxicj4NCjxiPk9yZ2FuaXphdGlvbjogPC9iPkFPTCBMTEM8 YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBBcHJpbCAzLCAyMDIwIGF0IDE6MjIgUE08YnI+DQo8 Yj5UbzogPC9iPlZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5j b20mZ3Q7LCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFu bmFAYW1hem9uLmNvbSZndDssIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2Nj aT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyZndDssIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tJmd0Oywgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0 OywgVml0dG9yaW8NCiBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW9AYXV0aDAuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SRTogW0VYVEVSTkFMXSBbT0FVVEgtV0ddIFdHTEMgb24gJnF1b3Q7SlNP TiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz cGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjYyMiIgc3R5bGU9IndpZHRoOjQ2Ni41 cHQ7bWFyZ2luLWxlZnQ6LjVpbjtib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0K PHRyIHN0eWxlPSJoZWlnaHQ6MTUuMjVwdCI+DQo8dGQgd2lkdGg9IjYyMiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJ3aWR0aDo0NjYuNXB0O2JvcmRlcjpzb2xpZCAjRUQ3RDMxIDEuNXB0O3BhZGRpbmc6 MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMjVwdCI+DQo8cD48c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2s7YmFja2dyb3VuZDojRkZGRjk5Ij5DQVVUSU9OPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOiNGRkZGOTkiPjogVGhpcyBlbWFpbCBvcmlnaW5hdGVk IGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Ig b3BlbiBhdHRhY2htZW50cyB1bmxlc3MNCiB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlciBhbmQg a25vdyB0aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhhbmtzIFZpdHRvcmlvIGZvciB0aGUgdGhvcm91 Z2ggcmVzcG9uc2UhPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IGhvdyBzY29wZXMgYXJlIGhhbmRs ZWQgaXMgdmVyeSBkaWZmZXJlbnQgYWNyb3NzIGRlcGxveW1lbnRzLiBTY29wZXMgdXNlZCBmb3Ig YW4gUlAgd2l0aCBhIG1vYmlsZSBhcHAgKGUuZy4gc29tZXRoaW5nIGxpa2UgT3BlblRhYmxlKSBh cmUgZ29pbmcgdG8gYmUgdmVyeSBkaWZmZXJlbnQgdGhhbiBhIG11bHRpLXRlbmFudCBlbnRlcnBy aXNlIHN5c3RlbSB3aXRoIGZpeGVkIHNlcnZpY2VzIGFuZCByb2xlcyB0aGF0IGFsbCB0ZW5hbnRz DQogbXVjaCB1c2UuIEknbSBub3Qgc3VyZSBpdCBpcyBwb3NzaWJsZSB0byBjbGVhcmx5IG1hcCB0 aGlzIGRpc3BhcmF0ZSBzZXQgb2YgZGVwbG95bWVudHMgaW50byBhIGNvbW1vbiBzZXQgb2Ygc3Bl YyBsYW5ndWFnZS4gSXQncyBwb3NzaWJsZSB0byBkZWZpbmUgYSBzb2x1dGlvbiB0aGF0IGlzIG1h eWJlICZxdW90O21ham9yaXR5JnF1b3Q7IGJ1dCBhbnlvbmUgd2FudGluZyB0byBjb25mb3JtIHdp dGggYSBkaWZmZXJlbnQgZGVwbG95bWVudCBzdHJhdGVneSB3aWxsIGp1c3QNCiAmcXVvdDttdW5n ZSZxdW90OyB0aGUgJ2F1ZCcgdmFsdWUgdG8gbWFrZSB0aGVpciBkZXBsb3ltZW50IHdvcmsuIEkn bSBub3Qgc3VyZSB0aGF0IGFkZHMgYSBsb3Qgb2YgdmFsdWUuIEkgdGhpbmsgSSB3b3VsZCBwcmVm ZXIgYSBtdWx0aS12YWx1ZWQgJ2F1ZCcgY2xhaW0gb2YgJnF1b3Q7bWFpbC5leGFtcGxlLCBjb250 YWN0cy5leGFtcGxlLCBuZXdzLmV4YW1wbGUmcXVvdDsgb3ZlciBhIGdlbmVyaWMgJnF1b3Q7YXBp LmV4YW1wbGUmcXVvdDsuIFRoZSBmb3JtZXIgcHJvdmlkZXMgdmFsdWUgdG8gbGltaXQNCiB0aGUg c2NvcGUgb2YgdGhlIHRva2VuIHdoZXJlIHRoZSBsYXR0ZXIgZG9lcyBub3QuPGJyPg0KPGJyPg0K SSBhZ3JlZSB0aGF0IHNjb3BlcyB3ZXJlIG5vdCB3ZWxsIHNwZWNpZmllZCBpbiA2NzQ5LzY3NTAg YW5kIG5vdyBpdCdzIGEgYml0IG9mIHRoZSB3aWxkIHdlc3QuIFNvbWUgdHJlYXQgc2NvcGVzIGFz IGNhcGFiaWxpdGllcywgc29tZSB0cmVhdCB0aGVtIGFzIHJvbGVzLCBzb21lIGFzIGF0dHJpYnV0 ZXMsIHNvbWUgYXMgZmxhZ3MgZm9yIHNwZWNpZmljIHRva2VuIGJlaGF2aW9yIGFuZCB0aGUgbGlz dCBnb2VzIG9uOik8YnI+DQo8YnI+DQpQZXJzb25hbGx5LCBJJ2QgcHJlZmVyIHVzaW5nIFJFQ09N TUVOREVEIGZvciB0aGUgY3VycmVudCBkZWZpbmVkIHNwZWMgbGFuZ3VhZ2Ugd2l0aG91dCBtYWtp bmcgdGhhdCBtb2RlbCByZXF1aXJlZC48YnI+DQo8YnI+DQpJZiB3ZSB0cnVseSB3YW50IGludGVy b3BlcmFibGUgYWNjZXNzX3Rva2VucyBjcm9zcyBJRFBzLCB0aGVuIEkgdGhpbmsgd2UgaGF2ZSBh IGxvdCBtb3JlIHNwZWMgd29yayB0byBkbyB0aGFuIGRlc2NyaWJpbmcgdGhlIHRva2VuIGZvcm1h dC4gVGhpcyBpcyBhIGltcG9ydGFudCBhbmQgbmVjZXNzYXJ5IGJ1aWxkaW5nIGJsb2NrLCBidXQg YmVoYXZpb3JzIGFuZCBob3cgdGhleSBtYXAgbWF5IGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgd29yay48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KR2VvcmdlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5PbiA0LzMvMjAgNTowMyBBTSwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmtzIEFubmFi ZWxsZSBhbmQgR2VvcmdlISZuYnNwOyBJIGFtIGNvbnNvbGlkYXRpbmcgcmVwbGllcyB0byBib3Ro IHlvdXIgbGF0ZXN0IGNvbW1lbnRzIGluIHRoaXMgbWFpbC4gVGhpcyBzZWVtcyBhIGhhcmQgcm9j ayB0byBsaWZ0LCBidXQgaXQgYWxzbyBzZWVtcyB0byBiZSB0aGUgbGFzdCBvbmUgPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyODUyMjs8 L3NwYW4+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhl IFRMO0RSIGlzLCBJIGFtIG5vdCBjb21wbGV0ZWx5IG9wcG9zZWQgdG8gcmVsYXhpbmcgdGhlIGNv bnN0cmFpbnRzIGFuZCB0dXJuaW5nIHRoZW0gaW50byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywg YnV0IEkgdGhpbmsgd2XigJlkIG1pc3MgYW4gb3Bwb3J0dW5pdHkgdG8gbWFrZSB0aGluZ3MgY2xl YXJlciBmb3IgZGV2ZWxvcGVycy4gQXQgdGhlIHNhbWUgdGltZSBJIHdvdWxkbuKAmXQgd2FudCB0 byBtYWtlIHRoaXMgcHJvZmlsZSB0b28gcGF0cm9uaXppbmcsIGhlbmNlIEkgYXBwcmVjaWF0ZSB0 aGUgb3Bwb3J0dW5pdHkgdG8gZGlzY3Vzcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+W0FubmFiZWxsZV08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyAmZ3Q7LiBUaGVyZSBtYXkgYmUgbm8gJnF1b3Q7c2NvcGUmcXVv dDsgcGFyYW1ldGVyLiZuYnNwOyBUaGUgJnF1b3Q7c2NvcGUmcXVvdDsgcGFyYW1ldGVyIGlzIE9Q VElPTkFMIGluIGF1dGhvcml6YXRpb24gcmVxdWVzdHMuIFNvIGFuIEFTL1JTIG9wZXJhdG9yIGNv dWxkIGRlY2lkZSB0aGV5J3JlIGdvaW5nIHRvIG9taXQgJnF1b3Q7c2NvcGUmcXVvdDsgZW50aXJl bHkgYW5kIHVzZSBtdWx0aXBsZSByZXNvdXJjZSBwYXJhbWV0ZXJzIGluc3RlYWQuIFNpbmNlIHRo ZXJlIGFyZSBubyBzY29wZXMsIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciBjb25mdXNpb24u PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGFtIGEgQklH IGZhbiBvZiBBVHMgd2l0aCBubyBzY29wZS0gYWxsIHRoZSBzY2VuYXJpb3Mgd2hlcmUgdGhlcmXi gJlzIG5vIGRlbGVnYXRpb24gKDFzdCBwYXJ0aWVzIGV0Yykgc2hvdWxkbuKAmXQgdXNlIHNjb3Bl cyBhdCBhbGwuIFRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGRvZXMgYWxsb3cg Zm9yIHNjb3BlLWxlc3MgQVRzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZ29hbCBpcyB0byBwcmV2ZW50 IGNvbmZ1c2lvbiwgSSBhZ3JlZSB0aGF0IHRoZXJl4oCZcyBubyBuZWVkIHRvIHJlc3RyaWN0IHRo ZSBhdWRpZW5jZSB0byBvbmUgc2luZ2xlIHJlc291cmNlIGlmIHRoZXJlIGFyZSBubyBzY29wZXMg YXQgYWxsIHRvIG1pc2ludGVycHJldC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkkgd291bGQgYmUgaW4gZmF2b3IgdG8gYWxsb3cgbXVsdGlwbGUgcmVzb3Vy Y2VzIGluIGF1ZGllbmNlIGluIHRoYXQgY2FzZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlVuZm9ydHVuYXRlbHkgaXTigJlzIG5vdCBhcyBzaW1wbGUgYXMg anVzdCBzYXlpbmcg4oCcSWYgdGhlIGluY29taW5nIHJlcXVlc3QgaW5jdWRlcyBtdWx0aXBsZSBy ZXNvdXJjZSBpbmRpY2F0b3JzIGFuZCBubyBzY29wZSwgYWNjZXB0IGl0IGFuZCB1c2UgdGhlIGlu Y29taW5nIHJlc291cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFsdWXigJ0g4oCTIG1vc3Rs eSBiZWNhdXNlIHRoZXJlIGlzIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgcHJvZHVjdGlvbiBzeXN0 ZW1zIHdoZXJlIHRoZSByZXF1ZXN0IGluY2x1ZGVzIG5vIHNjb3BlcyBhbmQgb25lIHJlc291cmNl IGluZGljYXRvciwgYnV0IHRoZSByZXN1bHRpbmcgdG9rZW4gaW5jbHVkZXMgYSBjb2xsZWN0aW9u IG9mIHNjb3BlcyB0aGUgdXNlciBhbHJlYWR5IGNvbnNlbnRlZCB0byBmb3IgdGhhdCByZXNvdXJj ZS0gYnV0IEkgYW0gc3VyZSB3ZSBjYW4gZ2V0IHRvIGFjY2VwdGFibGUgbGFuZ3VhZ2UgdGhhdCBl eHByZXNzZXMgdGhlIGNvbmNlcHQg4oCcaWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlc291cmNlIGlu ZGljYXRvcnMgaW4gdGhlIHJlcXVlc3QgYW5kIHRoZSByZXN0IG9mIHRoZSBydWxlcyBpbiBTLjMg dGhlIHJlc3VsdGluZyBBVCB3b27igJl0IGNvbnRhaW4gYSBzY29wZSBjbGFpbSwgdGhlIHJlc3Vs dGluZyBBVCBtdXN0IHVzZSB0aGF0IHJlc291cmNlIGluZGljYXRvcnMgbGlzdCBhcyBhdWQgdmFs dWXigJ0uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gQVMv UlMgb3BlcmF0b3IgbWF5IHVzZSAmcXVvdDtzY29wZSZxdW90OyB0byBpbmRpY2F0ZSBhIHJvbGUg b3IgcG9saWN5IChvciBzZXQgb2YgcG9saWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3YW50cywgYW5k IGFsbG93IHRoZSBjbGllbnQgdG8gbmFycm93IHRoZWlyIHBlcm1pc3Npb25zIHVzaW5nICZxdW90 O3Jlc291cmNlJnF1b3Q7IHBhcmFtZXRlcnMuIFRoaXMgd291bGQgYWxsb3cgdGhlIGNsaWVudCB0 byBvYnRhaW4gbmFycm93bHkgc2NvcGVkIGFjY2VzcyB0b2tlbnMgZm9yIHNwZWNpZmljIHVzZSBj YXNlcyB3aXRob3V0IG5lZWRpbmcgdG8gZGVmaW5lIHNlcGFyYXRlIHJvbGVzL3BvbGljaWVzIGZv ciBlYWNoLiBJbiB0aGlzIGNhc2UsIGEgSldUIEFUIHdpdGggYSBtdWx0aS12YWx1ZWQgJnF1b3Q7 YXVkJnF1b3Q7IGNsYWltIGFuZCBhICZxdW90O3Njb3BlJnF1b3Q7IGNsYWltIHdvdWxkIHNlZW0g YXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFpbSBpcyBpbnRlbmRlZCB0byBhcHBseSB0byBh bGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBhZ3JlZSB0aGF0IGRlcGxveW1lbnRz IGxpa2UgdGhlIG9uZSB5b3UgZGVzY3JpYmUgbWlnaHQgZXhpc3QsIGluIGZhY3QgSSBhbSBzdXJl IHRoZXkgZG8uIEhvd2V2ZXIgaXQgc2VlbXMgcmVhbGx5IGEgYnJpdHRsZSBhcHByb2FjaCwgZ2l2 ZW4gdGhhdCBpdCBtYWtlcyBhIHNwZWNpZmljIGFzc3VtcHRpb24gKHNjb3BlcyBhcmUgdmFsaWQg YWNyb3NzIGFsbCB0aGUgcmVzb3VyY2VzKSB0aGF0IGlzbuKAmXQgZW5zaHJpbmVkIGFueXdoZXJl IGFuZCBpZiBmdXR1cmUgdXBkYXRlcyB0byB0aGF0IGRlcGxveW1lbnQgdmlvbGF0ZSB0aGF0IGFz c3VtcHRpb24sIHRoYXQgd291bGQgbGVhZCB0byB0aGUgc2NvcGUgY29uZnVzaW9uIHRoZSBjdXJy ZW50IGxhbmd1YWdlIGluIHRoZSBwcm9maWxlIGlzIHRyeWluZyB0byBwcmV2ZW50LiBXZSBvZmZl ciB2ZXJ5IGxpdHRsZSBndWlkYW5jZSBpbiB0aGF0IHJlc3BlY3Q6IHRoZSBtYWluIHBsYWNlIHdl cmUgbXVsdGlwbGUgcmVzb3VyY2VzIGFyZSBldmVuIG1lbnRpb25lZCBpcyByZXNvdXJjZSBpbmRp Y2F0b3JzLCBhbmQgYWxsIHRoZSBzYW1wbGVzIChJIGtub3csIG5vbi1ub3JtYXRpdmUpIHVzZSBz Y29wZXMgdW5hbWJpZ3VvdXNseSB0aWVkIHRvIGEgc3BlY2lmaWMgcmVzb3VyY2UgKG1vcmUgb24g dGhhdCBsYXRlcikgbWFraW5nIHRoZSBtdWx0aS1yZXNvdXJjZSBzY29wZSBldmVuIG1vcmUgb2Yg YSBzcGVjaWFsIGNhc2UuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlN0ZXBwaW5nIGJhY2sgYSBiaXQgLSB0aGUgaW50ZW50IGJlaGluZCB0aG9zZSByZXNvdXJjZS1z Y29wZSByZXN0cmljdGlvbnMgaXMgdG8gcHJvdmlkZSBhIGJpdCBtb3JlIGd1aWRhbmNlIG9uIHNj b3BlcyBhbmQgcmVzb3VyY2VzIHRoYW4gd2UgZGlkIGluIHRoZSBwYXN0LCBhbmQgbmFycm93aW5n IHRoZSByYW5nZSBvZiBjYXNlcyBkZXZlbG9wZXJzIHdvdWxkIG5lZWQgdG8gdGFrZSBpbnRvIGFj Y291bnQgd2hlbiBpbXBsZW1lbnRpbmcgdGhlIHByb2ZpbGUuPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbiBteSBleHBlcmllbmNlIHRoZSBsYWNrIG9mIG1v cmUgcHJlc2NyaXB0aXZlIGd1aWRhbmNlIGxlZCB0byBkZXBsb3ltZW50cyBhbmQgaW50ZXJwcmV0 YXRpb25zIHRoYXQsIHdoaWxlIHJlbWFpbmluZyBmdWxseSB3aXRoaW4gdGhlIGJvdW5kYXJ5IG9m IHdoYXQgdGhlIHNwZWMgYWxsb3dzLCBhcmUgb2Z0ZW4gcXVlc3Rpb25hYmxlIGZyb20gdGhlIHNl Y3VyaXR5IGFuZCBhcmNoIHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+KCopSSBhY2tub3dsZWRnZSB0aGF0IEkgbWlnaHQgYmUgc3dpbmdp bmcgdG9vIGZhciBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLCBhbmQgcGVyaGFwcyBhIHNpbWls YXIgZWZmZWN0IGNvdWxkIGJlIGFjaGlldmVkIGJ5IGFkZGluZyBhbiDigJxBdXRob3JpemF0aW9u IENvbnNpZGVyYXRpb25z4oCdIHNlY3Rpb24gd2hlcmUgaW1wbGVtZW50ZXJzIGFyZSB3YXJuZWQg YWJvdXQgdGhlIGRhbmdlciBvZiBzY29wZSBjb25mdXNpb24gcmF0aGVyIHRoYW4gZG93bnJpZ2h0 IGZvcmJpZGRpbmcgbXVsdGkgcmVzb3VyY2VzIGF1ZGllbmNlcyB3aGVuIGluY2x1ZGluZyBzY29w ZXMgYXMgd2VsbC4gSSBzdGlsbCBsaWtlIHRoZSBzaW1wbGljaXR5IGFuZCBjbGFyaXR5IG9mIHRo ZSBjdXJyZW50IHJlc3RyaWN0aW9uLCBidXQgb2YgY291cnNlIEkgYW0gb3BlbiB0byBmZWVkYmFj ay48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgbWFwcGlu ZyBiZXR3ZWVuIGF1ZGllbmNlIGFuZCBzY29wZSBtYXkgYmUgdW5hbWJpZ3VvdXMuIFRoZXJlIGFy ZSBhIGxvdCBvZiBkZXBsb3ltZW50cyB0byB3aGljaCB0aGUgYmxhc3QgcmFkaXVzIHJpc2sgeW91 J3JlIHRyeWluZyB0byBhZGRyZXNzIGJ5IHJlcXVpcmluZyAmcXVvdDthdWQmcXVvdDsgc2ltcGx5 IGRvZXMgbm90IGFwcGx5PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZXJlIGFyZSBjZXJ0YWlubHkgY2FzZXMgd2hlcmUgc2Nv cGUgc3RyaW5ncyB1bmFtYmlndW91c2x5IG1hcCB0byBzcGVjaWZpYyByZXNvdXJjZXMsIGJ1dCBv bmNlIGFnYWluLCB0aGF04oCZcyBhIHN0cm9uZyBhc3N1bXB0aW9uIHRvIG1ha2UgYW5kIG9uZSBJ IGZlZWwgY2Fubm90IGJlIG1hZGUgbGlnaHRseS4gUmVzb3VyY2UgaW5kaWNhdG9ycyB1c2UgdmVy eSBzaW1wbGUgZXhhbXBsZXMgKGNvbnRhY3RzLCBjYWxlbmRhcikgdGhhdCBhcmUgaGFyZCB0byBn ZW5lcmFsaXplIHRvIHNjZW5hcmlvcyB3aGVyZSB0aGUgbnVtYmVyIGFuZCBsaWZlY3ljbGUgb2Yg cmVzb3VyY2VzIHRydWx5IGNhbGxzIGZvciB0aGUgdXNlIG9mIGluZGljYXRvcnMgaWRlbnRpZnlp bmcgYSByZXNvdXJjZSBpbiBhIGxhcmdlIG11bHRpdGVuYW50IHN5c3RlbSB1c3VhbGx5IGVudGFp bHMgbGFyZ2UgaWRlbnRpZmllcnMsIGFuZCBzdHVmZmluZyB0aG9zZSBpbiB0aGUgc2NvcGUgdG8g cHJldmVudCBhbWJpZ3VpdHkgY2FuIGJlIGV4cGVuc2l2ZSBmcm9tIGJvdGggcHJvdmlzaW9uaW5n IGFuZCB0b2tlbiwgcmVxdWVzdCBzaXplIGFuZ2xlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JdCBtYXkgc2VlbSBpbm5vY3VvdXMgdG8gcmVxdWlyZSB0aGVz ZSBkZXBsb3ltZW50cyB0byBleHBsaWNpdGx5IGluY2x1ZGUgYSBicm9hZCBhdWRpZW5jZSBsaWtl ICZxdW90O2FwaS5leGFtcGxlLmNvbSZxdW90OyBhbnl3YXksIHRoYXQgY2FuIGxlYWQgdG8gaW1w bGVtZW50ZXJzIGlnbm9yaW5nIHRoZSByZXF1aXJlbWVudCAobGVhZGluZyB0byBpbnRlcm9wIGlz c3VlcyksIG5vdCB2YWxpZGF0aW5nIGl0IChhbHNvIGxlYWRpbmcgdG8gaW50ZXJvcCBpc3N1ZXMg b3Igc2VjdXJpdHkgaXNzdWVzIGlmIHRoZSBkZXBsb3ltZW50IHdhbnRzIHRvIHN0YXJ0IGFjdHVh bGx5IHVzaW5nIGl0IGZvciByZWFsKSwgb3IgZG9pbmcgc29tZXRoaW5nIGZ1bmt5IHdpdGggaXQg c2luY2UgdGhlcmUgaXNuJ3QgYW55dGhpbmcgJnF1b3Q7cmVhbCZxdW90OyB0aGF0IHRoZSB2YWx1 ZSBuZWVkcyB0byBjb25mb3JtIHRvLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5FdmVyeSBzcGVjIGd1aWRhbmNlIHJpc2tzIG5v dCBiZWluZyBmb2xsb3dlZC4gQnV0IGluIHRoaXMgcGFydGljdWxhciBjYXNlLCB1c2Ugb2YgYSBs b2dpY2FsIGF1ZGllbmNlIGlzIHF1aXRlIG1haW5zdHJlYW0g4oCTIHdlIGhhZCBhIHNpbWlsYXIg ZGlzY3Vzc2lvbiBmb3IgcmVzb3VyY2UgaW5kaWNhdG9ycyBhbmQgdGhhdOKAmXMgd2h5IHRoZSBz cGVjIGVuZGVkIHVwIGluY2x1ZGluZyBsb2dpY2FsIGlkZW50aWZpZXJzIGFzIG9uZSBvZiB0aGUg cmVzb3VyY2UgcGFyYW1ldGVyIGZsYXZvci4g4oCccmVhbOKAnSBpcyBhIHJlbGF0aXZlIHRlcm0s IGdpdmVuIHRoYXQgdGhlcmUgYXJlIGFscmVhZHkgbWFueSBkaWZmZXJlbnQgd2F5cyBpbiB3aGlj aCBhIGxvZ2ljYWwgcmVzb3VyY2UgbWlnaHQgbWFwIHRvIGRpZmZlcmVudCDigJxwaHlzaWNhbOKA nSBhcnRpZmFjdHMgKHNlZSBoZXJva3XigJlzIGxhdGUgYmluZGluZyBVUkxzKS4gQ29sbGVjdGl2 ZSBhdWRpZW5jZXMgYXJlIGluIGNvbW1vbiB1c2UgZm9yIHBvb3IgbWFu4oCZcyB0cnVzdGVkIHN1 YnN5c3RlbXM6IG5vdCBlbmRvcnNpbmcgdGhlIGFwcHJvYWNoLCBidXQgYnJpbmdpbmcgY2lyY3Vt c3RhbnRpYWwgZXZpZGVuY2UgdGhhdCBicm9hZCBhdWRpZW5jZXMgYXJlbuKAmXQgdGhhdCB1bmNv bW1vbiBvciBoYXJkIHRvIGdyb2sgZm9yIGRldmVsb3BlcnMgYWxyZWFkeSB0b2RheS4gRmluYWxs eSwgdHVybmluZyBvZmYgdmFsaWRhdGlvbiBpcyBhY3R1YWxseSBub3QgdGhhdCB0cml2aWFsIGlu IG1hbnkgU0RLcywgZ2l2ZW4gdGhhdCB0aGV5IG1vc3RseSByZXVzZS9kZXJpdmUgZnJvbSBPSURD IGFuZCB0aGUgYXVkaWVuY2UgY2hlY2sgaXMgbWFuZGF0b3J5OiBJIHNhdyBtb3JlIG9mdGVuIHBl b3BsZSBkaXNhYmxpbmcgaXNzIGNoZWNrIHRoYW4gYXVkLiBOb25lIG9mIHRoaXMgbWVhbnMgdGhh dCB0aGUgZXJyb3JzIHlvdSBkZXNjcmliZSBjYW5ub3QgaGFwcGVuOiBidXQgSSB0aGluayB0aGV5 IGFyZW7igJl0IG1vcmUgbGlrZWx5IHRoYW4gYW55IG90aGVyIGd1aWRhbmNlIGluIHRoZSBzcGVj LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkbyBhY2sg dGhlIG1vcmUgZ2VuZXJpYyBwb2ludCB0aGF0LCBsaWtlIGluIHRoZSBwcmVjZWRpbmcgY2FzZSwg dGhpcyBtaWdodCBzdWdnZXN0IHRoYXQgdGhlIGN1cnJlbnQgZ3VpZGFuY2UgaXMgdG9vIHN0cmlj dC0gc2VlICgqKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bR2Vv cmdlXTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRo aW5rIG9uZSBvZiB0aGUgcHJvYmxlbXMgd2UgaGF2ZSBpbiBiZWluZyBzdXBlciBzcGVjaWZpYyBh Ym91dCBob3cgdGhlIEpXVCBhY2Nlc3MgdG9rZW4gaXMgY29uc3RydWN0ZWQgaXMgdGhhdCBpcyBt ZWFucyBpdCdzIG5vdCBwb3NzaWJsZSBmb3IgbWFueSBvcmdhbml6YXRpb25zIHRvIGZvbGxvdy4g SG93IHNjb3BlcyBhcmUgaW1wbGVtZW50ZWQgaXMgdmVyeSB2YXJpZWQgYWNyb3NzIGRlcGxveW1l bnRzIHdoaWNoIG1lYW5zIHRoYXQgc29tZSBtYXkgY29uZm9ybSB0byB0aGUgcGVyc3BlY3RpdmUg b2YgdGhlIHNwZWMgYW5kIG1hbnkgbWF5IG5vdC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WW91IGFyZSByaWdodCwgdGhlIHNw ZWMmbmJzcDsgaXMgYW4gb3BpbmlvbmF0ZWQgdGFrZS0gSSBhZ3JlZSB0aGF0IG1hbnkgb3JnYW5p emF0aW9ucyB1c2VkIHNjb3BlcyBpbiB2ZXJ5IGRpZmZlcmVudCB3YXlzLCBhbmQgSSB0aGluayBp dCBpcyB0aGUgcmVzdWx0IG9mIGdpdmluZyB2ZXJ5IGxpdHRsZSBndWlkYW5jZSBvbiBzY29wZXMg YW5kIHJlc291cmNlcywgd2l0aCB0aGUgY29uc2VxdWVuY2UgdGhhdCBzb21lIGNob2ljZXMgbWln aHQgaGF2ZSBiZWVuIGxlc3Mgd2lzZSB0aGFuIG90aGVycy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldpdGggdGhlIGN1cnJlbnQgZ3VpZGFuY2UgSSBhdHRl bXB0ZWQgdG8gY2FwdHVyZSBhIG5hcnJvd2VyIHNldCBvZiBzY2VuYXJpb3Mgd2hlcmUgc29tZSBv ZiB0aGUgbW9zdCBvYnZpb3VzIGlzc3VlcyAobGlrZSBzY29wZSBjb25mdXNpb24pIGNhbiBiZSBh dmVydGVkLCB3aGlsZSBzdGlsbCBzYXRpc2Z5aW5nIG1vc3Qgb2YgdGhlIGNhc2VzIEkgb2JzZXJ2 ZWQgaW4gdGhlIHNhbXBsZSBKV1QgQVRzOiBJIGFtIG5vdCB0cnlpbmcgdG8gb3ZlcmluZGV4IG9u IHRob3NlIGNhc2VzLCBhbmQgSSBkb27igJl0IG1lYW4gdG8gaW1wbHkgdGhhdCB0aGUgcHJvZmls ZSBzaG91bGQgc3RyaWN0bHkgZm9sbG93IHRob3NlLCBidXQgaW4gdGhlIHNwaXJpdCBvZiBlbGlt aW5hdGluZyBhbWJpZ3VpdHkgYXMgbXVjaCBhcyBwb3NzaWJsZSwgdGhpcyBzaW5nbGUgcmVzb3Vy Y2UgbmFycm93aW5nIHNlZW1lZCBhIHNvbGlkIGNvcmUgdG8gYnVpbGQgcm9idXN0IGltcGxlbWVu dGF0aW9ucyBvbi0gZnVsbHkgYXdhcmUgb2YgdGhlIGZhY3QgdGhhdCBtYW55IGN1cnJlbnQgaW1w bGVtZW50YXRpb25zIHdvdWxkIG5vdCBjb25mb3JtICh0aG8gSSBhbSBub3Qgc3VyZSBob3cgbWFu eSBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSBhZG9wdGVkIHJlc291cmNlIGluZGljYXRvcnMgb3Ig ZXF1aXZhbGVudCkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JbiBhbnkgY2FzZSwgc2VlICgqKS0gSSB0aGluayBJIGNhbiBiZSBjb252aW5jZWQgdG8gdHVy biB0aGUgY3VycmVudCByZXN0cmljdGlvbnMgaW50byBzZWN1cml0eS9hdXRob3JpemF0aW9uIGNv bnNpZGVyYXRpb25zLSBidXQgSSB3b3VsZCByZWx1Y3RhbnRseSBkbyBzbyBhcyBJIHRoaW5rIHdl 4oCZZCBwZXJwZXR1YXRlIGEgbG90IG9mIHRoZSBhbWJpZ3VpdHkgd2UgaGF2ZSBpbiB0aGlzIHNw YWNlIHRvZGF5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBl cnNvbmFsbHksIEknbSBub3QgYSBiaWcgZmFuIG9mIHRyeWluZyB0byB1c2Ugc2NvcGVzIGZvciBm aW5lLWdyYWluIGF1dGhvcml6YXRpb24uIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyB3aGF0IHRoZXkg d2VyZSBpbnRlbmRlZCBmb3Igd2hlbiBvcmlnaW5hbGx5IGRlc2lnbmVkLiAoVGhpcyBjYW4gYmUg c2VlbiBieSB0aGUgUkFSIHNwZWMgaW50cm9kdWNpbmcgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3 YXkgb2Ygc3BlY2lmeWluZyBmaW5lLWdyYWluIGF1dGhvcml6YXRpb24gY29udGV4dC4pIEV2ZW4g aW4gbXVsdGktdGVuYW50IHN5c3RlbXMsIEkgZG9uJ3Qgc2VlIGlzc3VlcyB3aXRoIHVzaW5nIHN1 Yi1yZXNvdXJjZSBzY29wZXMgYXMgZWFjaCB0ZW5hbnQgc2hvdWxkIGRlZmluZSB0aGUgc2NvcGVz IHRoYXQgbWFrZSBzZW5zZSBmb3IgdGhhdCB0ZW5hbnQuIEkgZG9uJ3QgdGhpbmsgdGhlIEFTIG5l ZWRzIHRvIHVuZGVyc3RhbmQgdGhlIHNjb3BlcywganVzdCBwcm92aWRlIGEgbWVjaGFuaXNtIHRv IGlzc3VlIHRoZSBjb3JyZWN0IHNjb3BlIHVuZGVyIHVzZXIgY29uc2VudCB0byB0aGUgY2xpZW50 IGFuZCBsZXQgdGhlIFJTIGFwcGx5IHRoZSBhdXRob3JpemF0aW9uIHBvbGljeSB3aGVuIGl0IGdl dHMgdGhlIHNjb3BlcyBvdXQgb2YgdGhlIHRva2VuLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGFtIG5vdCBjcmF6eSBhYm91 dCB0aGF0IGVpdGhlci0gZXNwZWNpYWxseSBnaXZlbiB0aGF0IHdoZW4gZmluZSBncmFpbmVkIGF1 dGhaIGlzIGludm9sdmVkIHZlcnksIHZlcnkgb2Z0ZW4gd2hhdCBkZXZlbG9wZXJzIHJlYWxseSB3 YW50IGFyZSB1c2VyIHByaXZpbGVnZXMgYW5kIHNjb3BlcyBhcmUganVzdCBhYnVzZWQgaW4gbGll dSBvZiBwcml2aWxlZ2VzIHNpbXBseSBiZWNhdXNlIHRoZSBzcGVjIGRvZXNu4oCZdCBhZGRyZXNz IHRoZSBub24tZGVsZWdhdGlvbiBzY2VuYXJpbyBoZW5jZSBhIHNjcmV3ZHJpdmVyIGVuZHMgdXAg YmVpbmcgdXNlZCBhcyBhIGhhbW1lci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPk5vbmV0aGVsZXNzLCBpZiBzY29wZXMgYXJlIHVzZWQtIG1hbmRhdGluZyB0 aGF0IGV2ZXJ5IHNjb3BlIGlzIHRpZWQgdG8gdGhlIHJlc291cmNlIGRvZXMgbGVhZCB0byBodWdl IHRva2VucyBhbmQgc2lnbmlmaWNhbnQgbWFuYWdlbWVudCBvdmVyaGVhZCBpZiB5b3UgaGF2ZSBs b3RzIG9mIHJlc291cmNlcyB3aG9zZSBpZGVudGlmaWVyIG11c3QgYmUgZ2xvYmFsbHkgdW5pcXVl LCBub25yZWFzc2lnbmFibGUgZXRjIGV0YyBoZW5jZSB2ZXJ5IGxhcmdlIOKAkyBhbmQgdGhlIEFT IGRvZXNu4oCZdCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHNlbWFudGljIG9mIGVhY2ggc2NvcGUg YnV0IGl0IGRvZXMgbmVlZCB0byBrbm93IHdoZXRoZXIgYSBzY29wZSBjYW4gYmUgcmVxdWVzdGVk IGZvciBhIGdpdmVuIHJlc291cmNlLCBwbHVzIGFueSBwb2xpY3kgdGhlIGFkbWluIG1pZ2h0IHdh bnQgdG8gZXhlY3V0ZSBhdCB0b2tlbiBpc3N1YW5jZSB0aW1lIChlZyB0aGlzIHNjb3BlIHJlcXVp cmVzIDJGQSkgaGVuY2UganVnZ2xpbmcgbGFyZ2UgbnVtYmVycyBvZiBsYXJnZSBzdHJpbmdzIGNh biBiZSBoYXJkIGZvciB0aGUgQVMg4oCTIGFuZCBSUy4gSW4gYW55IGNhc2UsIHRoZSB1c2Ugb2Yg bXVsdGlwbGUgcmVzb3VyY2VzIGluIHRoZSBhdWQgaW4gdGhlIHdpbGQgYXBwZWFyZWQgdG8gYmUg dmVyeSByYXJlLCBoZW5jZSBldmVuIGlmIHRoZXJlIHdvdWxkIGJlIGEgZm9vbHByb29mIHdheSBv ZiBkZWZpbmluZyBhIHJlc291cmNlLXNjb3BlIG1hcHBpbmcsIEkgd291bGQgbm90IHNwZW5kIGN5 Y2xlcyBkZWZpbmluZyBpdCBoZXJl4oCmIGFuZCBsZWF2aW5nIGl0IGFzIGV4ZXJjaXNlIGZvciB0 aGUgcmVhZGVyIHdvdWxkbuKAmXQgd29yayBwZXIgdGhlIGFib3ZlLiBBcyBpbiAoKikgd2UgY291 bGQgcmVsYXggdGhlIGNvbnN0cmFpbnQgaGVyZSBhbmQganVzdCB3YXJuIHBlb3BsZSBhZ2FpbnN0 IHNjb3BlIGNvbmZ1c2lvbiwgYnV0IEkgZmVlbCB3ZeKAmWQgYmUgbWlzc2luZyBhbiBvcHBvcnR1 bml0eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0tLS0tPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPu+7v09uIDMvMjQvMjAsIDE3 OjAwLCAmcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyA8YSBocmVmPSJtYWls dG86cmljaGFubmFAYW1hem9uLmNvbSI+Jmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7PC9hPiB3 cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRvIGJvcnJvdyBhIHRlcm0gZnJvbSBNTCwgSSB0aGluayB0aGUgJnF1b3Q7YXVk JnF1b3Q7LCAmcXVvdDtzY29wZSZxdW90OywgYW5kIHJlc291cmNlIGluZGljYXRvci1yZWxhdGVk IHRleHQgaXMgb3ZlcmZpdHRlZCB0byBhIHNwZWNpZmljIHNldCBvZiBkZXBsb3ltZW50IHNjZW5h cmlvcywgYW5kIGEgc3BlY2lmaWMgd2F5IG9mIHVzaW5nIHNjb3BlcyBhbmQgcmVzb3VyY2UgaW5k aWNhdG9ycy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENvbnNpZGVyIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAxLiBUaGVyZSBtYXkgYmUg bm8gJnF1b3Q7c2NvcGUmcXVvdDsgcGFyYW1ldGVyPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlICZxdW90O3Njb3BlJnF1 b3Q7IHBhcmFtZXRlciBpcyBPUFRJT05BTCBpbiBhdXRob3JpemF0aW9uIHJlcXVlc3RzLiBTbyBh biBBUy9SUyBvcGVyYXRvciBjb3VsZCBkZWNpZGUgdGhleSdyZSBnb2luZyB0byBvbWl0ICZxdW90 O3Njb3BlJnF1b3Q7IGVudGlyZWx5IGFuZCB1c2UgbXVsdGlwbGUgcmVzb3VyY2UgcGFyYW1ldGVy cyBpbnN0ZWFkLiBTaW5jZSB0aGVyZSBhcmUgbm8gc2NvcGVzLCB0aGVyZSBpcyBubyBvcHBvcnR1 bml0eSBmb3IgY29uZnVzaW9uLiBJbiB0aGlzIGNhc2UsIGEgSldUIEFUIHdpdGggYSBtdWx0aS12 YWx1ZWQgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIGFuZCBubyAmcXVvdDtzY29wZSZxdW90OyBjbGFp bSB3b3VsZCBzZWVtIGFwcHJvcHJpYXRlLiBXaGlsZSBtdWx0aXBsZSByZXNvdXJjZSBpbmRpY2F0 b3JzIGNvdWxkIGJlIHB1c2hlZCBpbnRvIGEgc2luZ2xlIHNjb3BlIHN0cmluZywgdGhpcyBpbnRy b2R1Y2VzIG9wcG9ydHVuaXRpZXMgZm9yIHNlcmlvdXMgc2VjdXJpdHkgaW1wYWN0aW5nIGVuY29k aW5nL2RlY29kaW5nL3BhcnNpbmcgYnVncy4gVGhlIG1vcmUgSSB0aGluayBhYm91dCBpdCwgdGhl IG1vcmUgJnF1b3Q7SSBkb24ndCBoYXZlIHRvIGRlYWwgd2l0aCBwYXJzaW5nIGEgc2NvcGUgc3Ry aW5nJnF1b3Q7IHNlZW1zIGxpa2UgYSBjb21wZWxsaW5nIHJlYXNvbiB0byBnbyB0aGlzIHJvdXRl Li4uIF9fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyAyLiBUaGUgc2NvcGVzIG1heSBhcHBseSB0byBhbGwgYXVkaWVuY2VzPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsgQW4gQVMvUlMgb3BlcmF0b3IgbWF5IHVzZSAmcXVvdDtzY29wZSZxdW90OyB0byBpbmRpY2F0 ZSBhIHJvbGUgb3IgcG9saWN5IChvciBzZXQgb2YgcG9saWNpZXMpIHRoYXQgdGhlIGNsaWVudCB3 YW50cywgYW5kIGFsbG93IHRoZSBjbGllbnQgdG8gbmFycm93IHRoZWlyIHBlcm1pc3Npb25zIHVz aW5nICZxdW90O3Jlc291cmNlJnF1b3Q7IHBhcmFtZXRlcnMuIFRoaXMgd291bGQgYWxsb3cgdGhl IGNsaWVudCB0byBvYnRhaW4gbmFycm93bHkgc2NvcGVkIGFjY2VzcyB0b2tlbnMgZm9yIHNwZWNp ZmljIHVzZSBjYXNlcyB3aXRob3V0IG5lZWRpbmcgdG8gZGVmaW5lIHNlcGFyYXRlIHJvbGVzL3Bv bGljaWVzIGZvciBlYWNoLiBJbiB0aGlzIGNhc2UsIGEgSldUIEFUIHdpdGggYSBtdWx0aS12YWx1 ZWQgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIGFuZCBhICZxdW90O3Njb3BlJnF1b3Q7IGNsYWltIHdv dWxkIHNlZW0gYXBwcm9wcmlhdGUsIGFzIHRoZSBzY29wZSBjbGFpbSBpcyBpbnRlbmRlZCB0byBh cHBseSB0byBhbGwgb2YgdGhlIGF1ZGllbmNlIHZhbHVlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuIFRoZSBtYXBwaW5nIGJl dHdlZW4gYXVkaWVuY2UgYW5kIHNjb3BlIG1heSBiZSB1bmFtYmlndW91czxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJl IGFyZSBhIGxvdCBvZiBkZXBsb3ltZW50cyB0byB3aGljaCB0aGUgYmxhc3QgcmFkaXVzIHJpc2sg eW91J3JlIHRyeWluZyB0byBhZGRyZXNzIGJ5IHJlcXVpcmluZyAmcXVvdDthdWQmcXVvdDsgc2lt cGx5IGRvZXMgbm90IGFwcGx5LiBJdCBtYXkgc2VlbSBpbm5vY3VvdXMgdG8gcmVxdWlyZSB0aGVz ZSBkZXBsb3ltZW50cyB0byBleHBsaWNpdGx5IGluY2x1ZGUgYSBicm9hZCBhdWRpZW5jZSBsaWtl ICZxdW90O2FwaS5leGFtcGxlLmNvbSZxdW90OyBhbnl3YXksIHRoYXQgY2FuIGxlYWQgdG8gaW1w bGVtZW50ZXJzIGlnbm9yaW5nIHRoZSByZXF1aXJlbWVudCAobGVhZGluZyB0byBpbnRlcm9wIGlz c3VlcyksIG5vdCB2YWxpZGF0aW5nIGl0IChhbHNvIGxlYWRpbmcgdG8gaW50ZXJvcCBpc3N1ZXMg b3Igc2VjdXJpdHkgaXNzdWVzIGlmIHRoZSBkZXBsb3ltZW50IHdhbnRzIHRvIHN0YXJ0IGFjdHVh bGx5IHVzaW5nIGl0IGZvciByZWFsKSwgb3IgZG9pbmcgc29tZXRoaW5nIGZ1bmt5IHdpdGggaXQg c2luY2UgdGhlcmUgaXNuJ3QgYW55dGhpbmcgJnF1b3Q7cmVhbCZxdW90OyB0aGF0IHRoZSB2YWx1 ZSBuZWVkcyB0byBjb25mb3JtIHRvLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsg4oCTPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgQW5uYWJlbGxlIEJhY2ttYW4g KHNoZS9oZXIpPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsgQVdTIElkZW50aXR5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9h d3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkv PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyBPbiAzLzI0LzIwLCAzOjMxIFBNLCAmcXVvdDtPQXV0aCBvbiBiZWhhbGYgb2YgVml0dG9y aW8gQmVydG9jY2kmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdv bmJlaGFsZm9mdml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciPiZs dDtvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB2aXR0b3Jpby5iZXJ0b2NjaT00 MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgJm5ic3A7Q0FVVElPTjogVGhp cyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBu b3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJt IHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgR2VvcmdlIGZvciB0 aGUgc3VwZXIgdGhvcm91Z2ggcmV2aWV3IGFuZCBmZWVkYmFjayE8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBJbmxpbmU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZndDsmbmJzcDsgU2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb248bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr3Dr8K/wr0gc2Vjb25kIGxp bmU6IHNjZW5hcmlvIHNob3VsZCBiZSBwbHVyYWwgLS0mZ3Q7IHNjZW5hcmlvczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvcOvwr/CvSBzZWNvbmQgc2Vu dGVuY2U6ICZxdW90O2FyZSBub3QgcmFuIGJ5JnF1b3Q7IC0tJmd0OyAmcXVvdDthcmUgbm90IHJ1 biBieSZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBj b2ZpZGVudGlhbGl0eSAtLSZndDsgY29uZmlkZW50aWFsaXR5PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgRml4ZWQuIFRoYW5r cyE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiAyLjIuMSBBdXRoZW50 aWNhdGlvbiBJbmZvcm1hdGlvbiBDbGFpbXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyDDr8K/wr3Dr8K/wr3Dr8K/wr0gSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBkZWZpbml0 aW9uIG9mIGBhdXRoX3RpbWVgIGFsbG93cyBmb3IgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgY2FzZSB3aGVyZSBhIHVzZXIgaXMgcmVxdWlyZWQgdG8gc29sdmUgYW4gYWRkaXRp b25hbCBjaGFsbGVuZ2UuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIGNoYWxsZW5nZSBlbnRhaWxzIGdvaW5nIGJh Y2sgdG8gdGhlIEFTLCB0aGVuIEkgYmVsaWV2ZSB0aGUgbGFuZ3VhZ2UgKGluIHRoZSBpbml0aWFs IHBhcmFncmFwaCBvZiAyLjIuMSBhbmQgaW4gYXV0aF90aW1lIGl0c2VsZikmbmJzcDsgYWNjb21t b2RhdGVzIGZvciB0aGF0IGFuZCBkb2VzIHJlcXVpcmUgdGhlIGF1dGhfdGltZSB0byBiZSB1cGRh dGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IElmIHlvdSBoaXQgdGhlIEFTIGFuZCBwcmVzZW50IGFuIGF1dGhlbnRpY2F0 aW9uIGZhY3RvciAoc3VjaCBhcyB5b3VyIGNoYWxsZW5nZSkgYW5kIG9idGFpbiBhIG5ldyB0b2tl biBpbiB0aGUgcHJvY2VzcywgdGhlIGF1dGhfdGltZSB3aWxsIHJlZmxlY3QgdGhlIHRpbWUgb2Yg eW91ciBsYXRlc3QgYXV0aGVudGljYXRpb24ganVzdCBsaWtlIGFuIGlkX3Rva2VuIHdvdWxkIGlu IHRoZSBzYW1lIGNpcmN1bXN0YW5jZXMgKHRoaW5rIHByb3RlY3RlZCByb3V0ZSBpbiBhIHdlYiBh cHAgcmVxdWlyaW5nIHN0ZXAgdXAgYXV0aCkgYW5kIChsaWtlbHkpIGFzc29jaWF0ZWQgc2Vzc2lv biBhcnRpZmFjdHMgKHRoaW5rIFJUcyBvciBjb29raWVzIHdpdGggc2xpZGluZyBleHBpcmF0aW9u LCB0aGUgY2hhbGxlbmdlIHdvdWxkIGNvdW50IGFzIGFjdGl2aXR5IGFuZCBtb3ZlIHRoZSBleHBp cmF0aW9uKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9w6/C v8K9IEkgdGhpbmsgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gc2Vzc2lvbl9zdGFydF90 aW1lIGFuZCBsYXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aF90aW1lLiBU aGlzIGZlZWxzIG1vcmUgbGlrZSBpdCdzIGRlZmluaW5nIHRoZSBzZXNzaW9uX3N0YXJ0X3RpbWU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25jZXB0LjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IFRoZXNlIHNhbWUgaXNzdWVzIGNhbiBhcHBseSB0 byB0aGUgYGFjcmAgYW5kIGBhbXJgIHZhbHVlcyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBlciB0aGUgYWJv dmUsIHRoZSBpbnRlbnQgaXMgbW9yZSB0byBleHByZXNzIHRoZSBsYXN0IHRpbWUgdGhlIHVzZXIg cGVyZm9ybWVkIGFueSBhdXRoZW50aWNhdGlvbiBhY3Rpb24gcmF0aGVyIHRoYW4gdGhlIHN0YXJ0 IHRpbWUuIFRoZSBpbnRlbnQgaXMgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhcyBjdXJyZW50IGFz IHBvc3NpYmxlLCBhcyBpdCBtaWdodCBiZSByZWxldmFudCB0byB0aGUgUlMgZGVjaXNpb25zIHdo ZXJlYXMgdGhlIGhpc3RvcnkgYmVmb3JlIGN1cnJlbnQgY29uZGl0aW9ucyBtaWdodCBub3QgYmUg Y29uc2VxdWVudGlhbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/C v8K9IEV2ZW4gaWYgZm9yIHRoaXMgc2Vjb25kYXJ5IGNoYWxsZW5nZSBhIG5ldyByZWZyZXNoX3Rv a2VuIGlzIGlzc3VlZCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBpcyB1bmxp a2VseSBtYW55IHJlbHlpbmcgcGFydGllcyB3aWxsIHdhbnQgdG8gdHJlYXQgdGhhdCBhcyBpc3N1 aW5nIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZXcgc2Vzc2lvbi4gVGhlIGdv YWwgaXMgdG8ga2VlcCB0aGUgdXNlciBsb2dnZWQgaW4gdG8gYSBzaW5nbGUgc2Vzc2lvbi48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyBDb3VsZCB5b3UgZXhwYW5kIG9uIHRoZSBwcmFjdGljYWwgaW1wbGljYXRpb25zIG9mIHRo ZSBhYm92ZT8gVGhlIGludGVudCBpc24ndCBhcyBtdWNoIHRvIHJlZmxlY3Qgc2Vzc2lvbiBpZGVu dGlmeWluZyBpbmZvcm1hdGlvbiBwZXIgc2UsIGJ1dCB0byBwcm92aWRlIHRoZSBSUyB3aXRoIHRo ZSBtb3N0IHVwIHRvIGRhdGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNpcmN1bXN0YW5jZXMgaW4g d2hpY2ggdGhlIGN1cnJlbnQgQVQgd2FzIG9idGFpbmVkLiBUaGUgZmFjdCB0aGF0IGEgc2Vzc2lv biB3YXMgaW5pdGlhbGx5IGVzdGFibGlzaGVkIHVzaW5nIGFjciBsZXZlbCAwIGRvZXNu4oCZdCBy ZWFsbHkgbWF0dGVyIGlmIHRoZSBBVCBJIGFtIHJlY2VpdmluZyBub3cgaGFzIGJlZW4gb2J0YWlu ZWQgYWZ0ZXIgYSBzdGVwdXAgdGhhdCBicm91Z2h0IGFjciB0byAxLCBpZiBteSBSUyBjYXJlcyBh dXRoIGF1dGhlbnRpY2F0aW9uIGxldmVscyBteSBhdXRob3JpemF0aW9uIGRlY2lzaW9uIHNob3Vs ZG4ndCBiZSBpbmZsdWVuY2VkIGJ5IHdoZXRoZXIgc29tZXdoZXJlIHRoZSBzZXNzaW9uIGFydGlm YWN0IGRpZG7igJl0IGNoYW5nZSBpdHMgc2Vzc2lvbklEIGFmdGVyIHRoZSBzdGVwdXAuIFNhbWUg Zm9yIGFjciwgYXV0aF90aW1lPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rp b24gMi4yLjMgQXV0aG9yaXphdGlvbiBDbGFpbXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr0gSSBmaW5kIHRoZSBzdGF0ZW1lbnQgJnF1b3Q7QWxsIHRo ZSBpbmRpdmlkdWFsIHNjb3BlIHN0cmluZ3MgaW4gdGhlIHNjb3BlPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2xhaW0gTVVTVCBoYXZlIG1lYW5pbmcgZm9yIHRoZSByZXNvdXJjZSBp bmRpY2F0ZWQgaW4gdGhlIGF1ZCBjbGFpbSZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNvbWV3aGF0IHByb2JsZW1hdGljLiBJbiBtYW55IGRlcGxveW1lbnRzIHRvZGF5IGZv ciAxc3QgcGFydHkgY2xpZW50cyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGFraW5nIGludG8gYWNjb3VudCBtb2JpbGUgYXBw bGljYXRpb25zLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhY2Nlc3MgdG9r ZW4gbW9zdCBsaWtlIGNvbnRhaW5zIHNjb3BlcyBmb3IgbWFueSBvZiB0aGUgMXN0IHBhcnR5PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmFja2VuZCBBUElzLiBJdCdzIHBvc3NpYmxl IHRvIGdldCBhcm91bmQgdGhpcyBieSBzZXR0aW5nIHRoZSAnYXVkJzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNsYWltIHRvIHNvbWV0aGluZyBsaWtlICZxdW90O2NvbS5leGFtcGxl LmFwaXMmcXVvdDsgYW5kIGhlbmNlIGFsbCB0aGUgaXNzdWVkPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2NvcGVzIG1hcCB0byB0aGF0IGF1ZGllbmNlIGNsYWltIGJ1dCB0aGF0IGlz IGp1c3Qgd29ya2luZyBhcm91bmQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TVVTVCBpbiB0aGUgc3BlYy4gR2l2ZW4gdGhlIGxhY2sgb2Ygc3BlY2lmaWNpdHkgb2YgdGhlICdh dWQnIGNsYWltIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSAncmVzb3VyY2UgaW5k aWNhdG9yJyBjbGFpbSBmb3IgdGhhdCBtYXR0ZXIsIHByZXR0eSBtdWNoIGFueXRoaW5nIGNhbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIG1hZGUgdG8gY29tcGx5LiBJbiB0aGF0 IGNvbnRleHQsIGl0IHNlZW1zIGxpa2UgUkVDT01NRU5EIGlzIGEgYmV0dGVyPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbm9ybWF0aXZlIGNsYXVzZS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgMXN0IHBh cnR5IHNvbHV0aW9ucywgSSB3b3VsZCBhcmd1ZSB0aGF0IGRlbGVnYXRpb24gbWlnaHQgbm90IGJl IHRoZSByaWdodCBwcmltaXRpdmUgaGVuY2UgSSB3b3VsZG4ndCBuZWNlc3NhcmlseSB1c2Ugc2Nv cGVzIHRvIGV4cHJlc3MgcGVybWlzc2lvbnM7IGJ1dCB0aGF0J3MgYSByYWJiaXQgaG9sZSBJJ2xs IHRyeSB0byBhdm9pZCBmb3IgdGhlIHRpbWUgYmVpbmcgX188bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgdGhlIGF1ZCwg SSB0aGluayB0aGF0IHdoYXQgeW91IGNoYXJhY3Rlcml6ZWQgYXMgd29ya2Fyb3VuZCB3b3VsZCBh Y3R1YWxseSBiZSBieSBkZXNpZ24uIFRoZSBhdWQgZGVmaW5lcyB0aGUgYXBwbGljYWJpbGl0eSBv ZiB0aGUgY3VycmVudCB0b2tlbiwgc28gdGhhdCBpbiBjYXNlIG9mIGxlYWthZ2UgdGhlIGJsYXN0 IHJhZGl1cyBvZiB0aGUgaW5jaWRlbnQgY2FuIGJlIGNvbnRhaW5lZC4gSWYgdGhlIHNvbHV0aW9u IGRlc2lnbmVkIGRlY2lkZXMgdGhhdCB0aGlzIHBhcnRpY3VsYXIgdG9rZW4gc2hvdWxkIGJlIHJl dXNhYmxlIGFjcm9zcyBtdWx0aXBsZSBhc3NldHMsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgZm9y IHRoZSBhdWQgdG8gcmVmbGVjdCB0aGF0IGV4cGxpY2l0bHkuIFRoYXQncyB0aGUgc3lzdGVtIGRl c2lnbmluZyB2b2x1bnRlZXJpbmcgYSBzY29wZSB4cGFuc2lvbiBvZiB0aGUgc2NvcGUsIGFuZCBn aXZlbiB0aGF0IGl0IGhhcyBzZWN1cml0eSBpbXBsaWNhdGlvbnMgSSB0aGluayBpdCdzIGdvb2Qg dG8gcmVxdWlyZSBpdCB0byBiZSBhbiBleHBsaWNpdCwgb3B0IGluIGFjdGlvbi4gQXQgdGhlIHNh bWUgdGltZSwgZ2l2ZW4gdGhhdCBzY29wZXMgYXJlIG9mdGVuIHVzZWQgdG8gZGVmaW5lIHBlcm1p c3Npb25zLCBJIGJlbGlldmUgaXQgbWFrZXMgc2Vuc2UgdG8gZmluZCBtZWNoYW5pc21zIHRvIG1p bmltaXplIHRoZSBjaGFuY2UgdGhhdCBSU2VzIHdvdWxkIG1pc2ludGVycHJldCB0aGUgYXBwbGlj YWJpbGl0eSBvZiBhIHNjb3BlIChzZWUgZGlzY3Vzc2lvbiB3aXRoIFRha2FoaWtvL05pa29zKS4g U3VtbWluZyBhbGwgdGhlIGFib3ZlLCBJJ2QgYmUgaW5jbGluZWQgdG8ga2VlcCB0aGUgTVVTVC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ICZuYnNwOyZuYnNwOyZu YnNwOyZndDsgU2VjdGlvbiAzLiBSZXF1ZXN0aW5nIGEgSldUIEFjY2VzcyBUb2tlbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBQZXIgbXkgY29tbWVu dHMgYWJvdmUgSSBzdXNwZWN0IHRoYXQgcmVxdWlyaW5nIGFsbCBKV1QgYWNjZXNzIHRva2Vuczxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGluY2x1ZGUgYW4gYXVkaWVuY2UgY2xh aW0gd2lsbCBqdXN0IGRldm9sdmUgdG8gYXVkaWVuY2UgY2xhaW1zIHRoYXQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgc29tZXdoYXQgcG9pbnRsZXNzIChpbiBvcmRlciB0byBt ZWV0IHRoaXMgTVVTVCBpbiB0aGUgc3BlYykuIEdpdmVuPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGhlIG1vYmlsZSBhcHAgZW52aXJvbm1lbnQgdG9kYXksIGl0IGlzIHVucmVhc29u YWJsZSB0byBhc2sgdGhlIG1vYmlsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFw cHMgdG8gZG93bnNjb3BlIGV2ZXJ5IGFjY2VzcyB0b2tlbiBiZWZvcmUgbWFraW5nIGFuIEFQSSBj YWxsIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJhY2tlbmQgQVBJcyB3 aGljaCBpcyB3aGF0IHRoZSBzcGlyaXQgb2YgYXVkaWVuY2UgYW5kIHJlc291cmNlPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdG9ycyBzZWVtIHRvIGltcGx5LjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFBhcnRseSBhZGRyZXNzZWQgaW4gdGhlIHByZWNlZGluZyBwb2ludCwgYnV0IHRoaXMgaXMgYSBn cmVhdCBvcHBvcnR1bml0eSB0byBjbGFyaWZ5IHRoZSBpbnRlbnQgZnVydGhlci4gVGhlIG1vYmls ZSBjbGllbnQgaXNuJ3QgcmVxdWlyZWQgdG8gZG93bnNjb3BlOyByYXRoZXIsIHRoZSBmYWN0IHRo YXQgYSB0b2tlbiBjYWIgYmUgYXBwbGllZCB0byBhIGJyb2FkIHJhbmdlIG9mIEFQSSBzaG91bGQg YmUgY2xlYXJseSBpZGVudGlmaWVkIGFuZCBleHByZXNzZWQgYnkgdGhlIGxvZ2ljYWwgYXVkaWVu Y2UuIFRoZSBzeXN0ZW0gZGVzaWduZXIgY2FuIGV2ZW4gY2hvb3NlIHRvIGhhdmUgYSBzaW5nbGUg dG9rZW4gdGhhdCBjYW4gYmUgdXNlZCB0byBjYWxsIGFueSBBUEksIGNvbnRhaW5pbmcgZXZlcnkg c2NvcGUgZm9yIGV2ZXJ5IEFQSTsgdGhlIHByb2ZpbGUgb25seSBhc2tzIGZvciB0aGlzIGNob2lj ZSB0byBiZSBtYW5pZmVzdCwgYnkgY2hvb3NpbmcgYW4gYXBwcm9wcmlhdGUgYXVkaWVuY2UgaWRl bnRpZmllciBhbmQgYWNrbm93bGVkZ2luZyB0aGF0IGFsbCB0aGUgc2NvcGVzIGluIHRoZSB0b2tl biBhcmUgYXBwbGljYWJsZSB0byB0aGUgc2FtZSBsb2dpY2FsIHJlc291cmNlICh0aGF0IGlzLCB0 aGUgYWdncmVnYXRlIG9mIGFsbCB0aGUgQVBJcykuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jm5ic3A7IMOvwr/CvcOvwr/CvSBXaHkgTVVTVCB0aGUgQVMgcmVqZWN0IGEg cmVxdWVzdCB3aXRoIG1vcmUgdGhhbiBvbmUgcmVzb3VyY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBwYXJhbWV0ZXI/IElmIGEgcmVxdWVzdCBjb21lcyBpbiB3aXRoIG5vIHJlc291 cmNlIHBhcmFtZXRlciBhbmQgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzY29wZXMgdGhlIEFTIGlzIG5vdCByZXF1aXJlZCB0byByZWplY3QgdGhhdCByZXF1ZXN0LiBJ cyB0aGVyZSBtdWNoIG9mIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZW1hbnRp YyBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3bz8gSW4gdGhlIGNhc2Ugb2Ygbm8gcmVzb3VyY2U8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgYW5kIG11bHRpcGxlIHNj b3BlcyB0aGUgQVMgbWlnaHQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGg8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0aXBsZSBhdWRpZW5jZSB2YWx1ZXMgKGFzIGlzIGFsbG93 ZWQgYnkgUkZDIDc1MTkpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYW5vdGhlciBjb25zZXF1ZW5jZSBvZiBt YWtpbmcgZXh0cmEgY2xlYXIgd2hhdCB0aGUgdG9rZW4gcmVmZXJzIHRvLCBhbmQgd2hhdCB0aGUg aW50ZW5kZWQgc2VtYW50aWMgb2YgdGhlIHNjb3BlcyBpcy4gVGhlIGlkZWEgaXMgdGhhdCB0aGUg dG9rZW4gaXMgYWx3YXlzIHJlc3RyaWN0ZWQgdG8gT05FIHNwZWNpZmljIGF1ZGllbmNlLiBUaGUg cHJvZmlsZSBhbGxvd3MgZm9yIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciB0aGUgQVMgdG8gZGV0 ZXJtaW5lIHdoYXQgdmFsdWUgdGhlIGF1ZGllbmNlIHNob3VsZCBiZSwgaW5jbHVkaW5nIHZpYSBp bmZlcmVuY2UgZnJvbSBzY29wZXMsIGJ1dCBjb2hlcmVudGx5IHdpdGggdGhlIHNjb3BlIGNvbmZ1 c2lvbiBwcmV2ZW50aW9uIHByaW5jaXBsZSwgaWYgdGhhdCBpbmZlcmVuY2UgY2Fubm90IGxlYWQg dG8gYSBzaW5nbGUgcmVzb3VyY2UgaWRlbnRpZmllciBpbiB0aGUgYXVkaWVuY2UsIHRoZSByZXF1 ZXN0IHNob3VsZCBiZSByZWplY3RlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgaW50ZW50IGlzIHJlYWxseSB0byBi ZSBhcyBzaW1wbGUgYXMgdW5hbWJpZ3VvdXMgYXMgcG9zc2libGUsIGFuZCBjYXB0dXJlIHdoYXQg bW9zdCBtYWluc3RyZWFtIHByb3ZpZGVycyBhbHJlYWR5IGRvIGluIEpXVCBBVHMuIElmIGEgUlMg aGFzIG1vcmUgc29waGlzdGljYXRlZCByZXF1aXJlbWVudHMsIHRoZXkgY2FuIGFsd2F5cyBkZWNp ZGUgdG8gZG8gbW9yZSBhbmQgbm90IGZvbGxvdyB0aGUgaW50ZXJvcCBwcm9maWxlLiBEZWZpbmlu ZyBtb3JlIGNvbXBsZXggcnVsZXMgdG8gcHJldmVudCBzY29wZS9yZXNvdXJjZSBhc3NvY2lhdGlv biBjb25mdXNpb24gc2ltcGx5IGRvZXNu4oCZdCBzZWVtIHRvIGJlIGp1c3RpZmllZCBieSB0aGUg ZnJlcXVlbmN5IG9mIHRoZSBzY2VuYXJpbyBpbiB0aGUgd2lsZC48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyBBbHNvLCB0 aGUgYXVkaWVuY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpbSBpcyBub3Qg c29sZWx5IGZvciByZXNvdXJjZSBpbmRpY2F0b3IgdmFsdWVzIGJ1dCBpcyBkZWZpbmVkIHRvIGp1 c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBhIHN0cmluZy4gVG8gbWUgaXQg ZmVlbHMgbGlrZSB0aGUgdGV4dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsaWQgYXVkaWVuY2UgdmFsdWUgaXMgYWxzbyBhIHJlc291 cmNlIGluZGljYXRvciAod2hpY2ggZnJvbSBwcmV2aW91czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRpc2N1c3Npb25zIG9uIHRoZSBsaXN0IGl0IHdhcyBpbXBsaWVkIHRoZXkgaGF2 ZSBhIHNsaWdodGx5IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNl bWFudGljKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDMgb2YgdGhlIHByb2ZpbGUgZG9lcyBkZWZpbmUgYXVk IGFzIGEgcmVzb3VyY2UgaW5kaWNhdG9yLCBlbnVtZXJhdGluZyBhbiBleGhhdXN0aXZlIGxpc3Qg b2YgcG9zc2libGUgcmVxdWVzdHMgdGhhdCBhbGwgZW5kIGluIGEgcmVzb3VyY2UgaW5kaWNhdG9y IGFzIGF1ZCwgb3IgYW4gZXJyb3IuIERpZCBJIG1pc3Mgc29tZSBjYXNlcz8gSSBkb27igJl0IHJl Y2FsbCBzcGVjaWZpY3MgYWJvdXQgYXVkIHZhbHVlcyBpbiB0aGlzIHByb2ZpbGUgaGF2aW5nIG90 aGVyIHBvc3NpYmxlIHZhbHVlcywgc29ycnkgZm9yIGhhdmluZyBtaXNzZWQgdGhhdC4gRG8geW91 IGhhdmUgYSBzbmlwcGV0IHJlZmVycmluZyB0byB0aG9zZSBkaXNjdXNzaW9ucz8gVGh4PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7IMOvwr/CvcOvwr/CvSBUaGUgbW9kZWwg ZGVzY3JpYmVkIGhlcmUgd29ya3Mgd2VsbCBpZiBteWNvLmV4YW1wbGUgcmVhbGx5IG9ubHk8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlcyBhIHNpbmdsZSBzZXJ2aWNlLiBC dXQgaWYgaW5zdGVhZCBteWNvLmV4YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlcyBlYWNoIHdpdGggdGhlaXIgb3duIGVuZHBvaW50 cyAoc3J2YS5teWNvLmV4YW1wbGUsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3J2 Yi5teWNvLmV4YW1wbGUpIGFuZCBzY29wZXMsIGZvciBtZSB0aGlzIG1vZGVsIGJlZ2lucyB0byBi cmVhayBkb3duLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVpdGhlciBtb2JpbGUg YXBwcyBhcmUgcmVxdWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tlbnMgdG8ganVzdCB0aGU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlIHRoZXkgYXJlIGNhbGxpbmcgYXQg dGhhdCBwb2ludCBpbiB0aW1lICh3aGljaCBjYW4gaGF2ZSBsYXRlbmN5PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIGNvbm5lY3Rpdml0eSBpc3N1ZXMpLCBvciBteWNvLmV4YW1w bGUgaGFzIHRvIGNyZWF0ZSBhIGdlbmVyaWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDthdWRpZW5jZSZxdW90OyBzdHJpbmcgdGhhdCByZXByZXNlbnRzIGFsbCBvZiBleGFt cGxlLmNvbSB3aGljaCBkb2Vzbid0IHNlZW08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0byBiZSB0aGUgc3Bpcml0IG9mIHRoZSBleGlzdGluZyBzcGVjcy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5r IHRoYXQgdGhlIGdyYW51bGFyaXR5IG9mIHRoZSBjYWxscyBpcyBmdWxseSB3aXRoaW4gdGhlIGNv bnRyb2wgb2YgdGhlIGRlc2lnbmVyLiBJZiBzcnZhLm15Y28uZXhhbXBsZSBhbmQgc3J2Yi5teWNv LmV4YW1wbGUgc2hhcmUgYW5hbG9nb3VzIGNoYXJhY3RlcmlzdGljcyAoc2FtZSBwb2xpY2llcywg bGlmZWN5Y2xlLCByZXNvdXJjZSBvd25lcnNoaXAsIGV0YykgdGhlbSBpdCdzIHBlcmZlY3RseSB2 YWxpZCB0byBhc3NpZ24gYSBsb2dpY2FsIG15Y28uZXhhbXBsZSBhdWRpZW5jZSBlbmNvbXBhc3Np bmcgdGhlbSBhbGwsIHJlZ2FyZGxlc3Mgb2YgZGVwbG95bWVudCBtb2RlbC4gSWYgdGhlcmUgYXJl IGRpZmZlcmVuY2VzIGluIHRlcm1zIG9mIHBvbGljaWVzLCBhdXRoIHN0cmVuZ3RoIHJlcXVpcmVt ZW50cywgbGlmZWN5Y2xlLCByaXNrIGFuZCBpbXBhY3Qgb2YgYSBsZWFrLCBvciBhbnkgb3RoZXIg Ym91bmRhcnksIHRoZW4gdGhlIGF1ZGllbmNlIHJlcXVpcmVtZW50IHdpbGwgZ3VhcmFudGVlIHRo YXQgdGhvc2UgZGlmZmVyZW5jZXMgYXJlIHJlZmxlY3RlZCBpbiB0b2tlbnMgcmVxdWVzdGVkIGFu ZCBjYWNoZWQsIGluIHRoZSB3YXkgaW4gd2hpY2ggYWNjZXNzIGlzIHBhcnRpdGlvbmVkLCBhbmQg c28gb24gYW5kIHNvIGZvcnRoLiBJZiB0aGVyZSBhcmUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHN1 Y2ggYXMgdGhlIG9uZXMgZW51bWVyYXRlZCwgdGhlIGxhdGVuY3kgYW5kIGNvbm5lY3Rpdml0eSBp c3N1ZXMgYXJlbuKAmXQgYSBibG9ja2luZyBmYWN0b3I7IGFuZCBpZiB0aGVyZSBhcmVuJ3QsIG5v dGhpbmcgcHJldmVudHMgeW91IGZyb20gaGF2aW5nIGEgbG9naWNhbCBhdWRpZW5jZSB2YWx1ZS4g RnJvbSB0aGUgZXhwcmVzc2l2ZSBwb3dlciBwb2ludCBvZiB2aWV3LCB0aGUgcmVxdWlyZW1lbnQg b2YgaGF2aW5nIGEgc2luZ2xlIGF1ZGllbmNlIGRvZW5zJ3QgcHJldmVudCB5b3UgZnJvbSBkb2lu ZyBhbnkgb2YgdGhlIHNpbmdsZSB0b2tlbiBsb2dpYyB5b3UgYXJlIGhpbnRpbmcgYXQtIGVzcGVj aWFsbHkgaWYgeW91IHBsYW4gdG8gdXNlIHNwZWNpYWxpemVkIHNjb3BlcyBhbnl3YXkuPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBJbiBzdW1tYXJ5 LCBJIGZlZWwgdGhhdCB0aGlzIHRleHQgaXMgYmluZGluZyB0b28gdGlnaHRseSByZXNvdXJjZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGljYXRvcnMgdG8gdGhlIGF1ZGllbmNl IGNsYWltLiBXaGF0IGlzIGRlc2NyaWJlZCBpcyBwZXJmZWN0bHk8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyByZWFzb25hYmxlIGluIGEgdXNlIGNhc2UgdGhhdCBpcyBhcHBseWluZyBy ZXNvdXJjZSBpbmRpY2F0b3JzIGluIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3YXkgYnV0IGlzIG5vdCBpbmRpY2F0aXZlIG9mIHRoZSB3aWRlbHkgZGVwbG95ZWQgbW9kZWxz IHRoYXQgYWxyZWFkeSBleGlzdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBtaWdodCBoYXZlIGRpZmZlcmVudCBleHBl cmllbmNlcyBoZXJlLiBUaGUgSldUIGFjY2VzcyB0b2tlbnMgZnJvbSBwb3B1bGFyIHByb2R1Y3Rz IEkgc3R1ZGllZCBpbiB0aGUgcmVzZWFyY2ggSSBwcmVzZW50ZWQgaW4gU3R1dHRnYXJ0IHdlcmUg YWxtb3N0IGFsbCB1c2luZyB0aGUgYXVkIGNsYWltIGluIHRoaXMgd2F5LiBJIGFtIHN1cmUgdGhh dCB0aGVyZSBhcmUgb3RoZXIgbW9kZWxzLCBhbmQgdGhlcmUgd2FzIGF0IGxlYXN0IG9uZSBleGNl cHRpb24sIGJ1dCBpbiBpbnRlcm9wIHRlcm1zIHRoaXMgc2VlbXMgdG8gYmUgdGhlIG1vc3QgY29t bW9uIHdheSBvZiB1c2luZyBKV1QgZm9yIEFUcy0gYW5kIGl0IGhhcyB0aGUgYWR2YW50YWdlIG9m IGJlaW5nIHZlcnkgc2ltcGxlIGFuZCB1bmFtYmlndW91cy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgU2VjdGlvbiA0LiBW YWxpZGF0aW5nIEpXVCBBY2Nlc3MgVG9rZW5zPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IFN0ZXAgNC4gLS0gQ2FuIHdlIGNoYW5nZSB0aGUgd29yZGlu ZyB0byBub3QgcmVxdWlyZSByZXNvdXJjZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluZGljYXRvcnM/IFdoYXQgYWJvdXQuLi4gJnF1b3Q7VGhlIHJlc291cmNlIHNlcnZlciBNVVNU IHZhbGlkYXRlIHRoYXQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJ2F1ZCcg Y2xhaW0gY29udGFpbnMgYSBzdHJpbmcgdGhhdCByZXByZXNlbnRzIHRoZSBhdWRpZW5jZSBvZiB0 aGlzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzb3VyY2Ugc2VydmVyLiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IENvdWxkIHlvdSBtYWtlIGFuIGV4YW1wbGUgaW4gd2hpY2ggeW91J2Qgd2FudCB0 byB1c2UgYW4gaWRlbnRpZmllciB0aGF0IGlzIG5vdCBhIHJlc291cmNlIGluZGljYXRvcj8gR2l2 ZW4gdGhhdCB3ZSBoYXZlIHRoZSBzcGVjLCBhbmQgJnF1b3Q7YXVkaWVuY2Ugb2YgdGhlIHJlc291 cmNlIHNlcnZlciZxdW90OyBzZWVtcyB0byBiZSB0aGUgZXhhY3Qgc2VtYW50aWMgb2YgcmVzb3Vy Y2UgaW5kaWNhdG9ycywgaXQgc2VlbWVkIGEgc2xhbSBkdW5rIHRvIHVzZSBpdCBoZXJlLi4uPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFNlY3Rpb24gNS4gJnF1b3Q7Y3Jvc3MtSldUIGNvbmZ1 c2lvbiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOv wr/CvSBJIHRoaW5rIHRoZXJlIG1heSBiZSBjb25mdXNpb24gYXJvdW5kIHdoYXQgaXMgbWVhbnQg YnkgJnF1b3Q7ZGlzdGluY3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvdXJj ZXMmcXVvdDsuIEluIG15IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhhbXBsZSBhbmQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcnZiLm15Y28uZXhhbXBsZSAmcXVvdDtk aXN0aW5jdCByZXNvdXJjZXMmcXVvdDs/IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8gc2F5IHRoYXQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3ZSB3YW50IGRpZmZlcmVudCBhdWRpZW5j ZSB2YWx1ZXMgZ2VuZXJhdGVkIGZvciBjcm9zcy1vcmdhbml6YXRpb248bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyByZXNvdXJjZXMuIEZvciBleGFtcGxlLCBhcmUgbWFpbC5nb29nbGUu Y29tIGFuZCB5b3V0dWJlLmNvbSAmcXVvdDtkaXN0aW5jdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJlc291cmNlcyZxdW90Oz8gb3Igd291bGQgYW4gYXVkaWVuY2UgZm9yIGdvb2ds ZSBzdWZmaWNlIGluIG1lZXRpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWVhbmluZyBvZiB0aGlzIHBhcmFncmFwaD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoZSBrZXkgcG9pbnQg aGVyZSBpcyAtIHdlIGRvbuKAmXQga25vdy4gSSBhZ3JlZSB0aGUgbGFuZ3VhZ2UgaXNuJ3QgY2xl YXIgdGhlcmUuIExldCBtZSBleHBhbmQgb24gdGhlIGludGVudCwgYW5kIHBlcmhhcHMgd2UgY2Fu IGdldCB0byBhIGJldHRlciBmb3JtdWxhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aDIgZG9lc27igJl0IGRl bWFuZCB0aGF0IFJTIGFuZCBBUyBhcmUgcnVuIGJ5IHRoZSBzYW1lIGVudGl0eSwgYnV0IHRoYXQn cyB0aGUgbW9zdCBjb21tb24gc2NlbmFyaW8uIEZCIGRvZXNuJ3QgbmVlZCB0byBzcGVjaWZ5IGEg cmVzb3VyY2UsIGJlY2F1c2UgdGhlIHJlc291cmNlIGlzIGltcGxpY2l0Li4gaXQncyB0aGUgRkIg Z3JhcGgsIHlvdSBjYW7igJl0IGdldCBhIHRva2VuIGZvciBhbnl0aGluZyBlbHNlLiBUaGUgb25s eSBkaWZmZXJlbnRpYXRvciBlbmRzIHVwIGJlaW5nIHRoZSBzY29wZXMuIFNhbWUgZm9yIG1hbnkg b3RoZXIgcHJvdmlkZXJzLCBnb29nbGUsIE1pY3Jvc29mdCBmb3IgaXRzIG93biBHcmFwaCwgZXRj LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZu YnNwOyZuYnNwO0hvd2V2ZXIgbWFueSBBUyBhcyBhIHNlcnZpY2UgZG9u4oCZdCBoYXZlIHRoZSBi ZW5lZml0IG9mIGEgZGVmYXVsdCwgaW1wbGljaXQgcmVzb3VyY2UsIGVzcGVjaWFsbHkgaW4gbXVs dGkgdGVuYW5jeSBzY2VuYXJpb3MsIGdpdmVuIHRoYXQgdGhleSdsbCBuZWVkIHRvIGlzc3VlIHRv a2VucyBmb3IgYSBudW1iZXIgb2YgZGlmZmVyZW50IHJlY2lwaWVudHMuIFdoZXRoZXIgcmVzb3Vy Y2VzIGFyZSBjcm9zcyBvcmdhbml6YXRpb24sIG9yIGNyb3NzIGRlcGFydG1lbnQsIG9yIGZvbGxv d2luZyBhbnkgb3RoZXIgYXJiaXRyYXJ5IHNlZ3JlZ2F0aW9uL2ZhY3RvcmluZyBtb2RlbCBpcyBz b21ldGhpbmcgd2UgY2Fubm90IGluZmVyLSBpdCdzIHVwIHRvIHRoZSBkZXZlbG9wZXIgdG8gZGV0 ZXJtaW5lIHRoYXQuIFdoYXQgSSBhbSB0cnlpbmcgdG8gZXhwcmVzcyBoZXJlIGlzIHRoYXQgdGhl IG9wZXJhdG9yIG9mIHRoZSBBUyBhcyBhIHNlcnZpY2UgKG9yIGFueSBvdGhlciBmb3JtIG9mICZx dW90O0FTIGZvciByZW50JnF1b3Q7KSBzaG91bGQgc3VyZmFjZSByZXNvdXJjZXMgYXMgYSBwcmlt aXRpdmUgZm9yIG1vZGVsaW5nIGFuZCBpZGVudGlmeWluZyBpbnRlbmRlZCByZWNpcGllbnRzIG9m IEFUcy4gRG9lcyB0aXMgaGVscD8gSG93IHdvdWxkIHlvdSBleHByZXNzIHRoYXQ/PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvSBJJ20gaGF2aW5nIHRoZSBzYW1l IGNvbmZ1c2lvbiBpbiB0aGUgbmV4dCBwYXJhZ3JhcGggcmVnYXJkaW5nIHRoZTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBocmFzZSAmcXVvdDtkaWZmZXJlbnQgcmVzb3VyY2VzJnF1 b3Q7LiBBcmUgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhlIHNhbWUgY29tcGFueTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2RpZmZlcmVudCByZXNvdXJjZXMmcXVvdDsgb3Ig YXJlIHRoZXkgYWxsIGNvbnNpZGVyZWQgdGhlIHNhbWUgcmVzb3VyY2UuIENhbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIGFjY2VzcyB0b2tlbiBiZSBpc3N1ZWQgd2l0aCBzY29w ZXMgZm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHlvdXR1YmUuY29tPyBBbmQgaWYgbm90LCB3aHkgbm90ZT8gUHJldmVudGluZyB0aGlz IHB1dHMgdW5kdWUgYnVyZGVuIG9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9i aWxlIGJhc2VkIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBTZWUgcHJlY2VkaW5nIHBvaW50LiBXZSBj YW4ndCBlbnRlciBpbiB0aGUgbWVyaXQgb2Ygd2hhdCBjb25zdGl0dXRlcyBhIHJlc291cmNlLCBh cyB0aGF0IGRlcGVuZHMgb24gdGhlIG1vZGVsaW5nIG9mIHRoZSBkb21haW4gc3BlY2lmaWMgcHJv YmxlbSB0aGUgZGV2ZWxvcGVyIGlzIHRhY2tsaW5nLiBUaGUgaGlnaGVzdCBvcmRlciBiaXQgaXMg dGhhdCBpZiB0d28gZW50aXRpZXMgKEFQSSwgZXRjLi4gaW50ZW5kZWQgdG9rZW4gcmVjaXBpZW50 cykgaGF2ZSBkaWZmZXJlbnQgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIChlLmcuIGxlYWtpbmcg YSB0b2tlbiBmb3Igb25lIGhhcyBkaWZmZXJlbnQgY29uc2VxdWVuY2VzIHRoYW4gaWYgeW91J2Qg bGVhayBhIHRva2VuIGZvciB0aGUgb3RoZXIpLCB0aGV5IHNob3VsZCBiZSBtb2RlbGVkIGFzIGRp ZmZlcmVudCByZXNvdXJjZXMuIEFuZCBpZiB0aGV5IGFyZSBkaWZmZXJlbnQgcmVzb3VyY2VzLCB3 ZSBzaG91bGQgZG8gd2hhdCB3ZSBjYW4gdG8gYXZvaWQgY29uZnVzaW9uIGluIGhvdyB3ZSBleHBy ZXNzIGFjY2VzcyBncmFudHMgdG8gdGhlbSAoaGVuY2UgdGhlIGJpZyBkaXNjdXNzaW9uIG9uIG11 bHRpcmVzb3VyY2UsIHNjb3BlIGNvbmZ1c2lvbiwgZXRjKS48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgT24g My8yNC8yMCwgMTA6MzksICZxdW90O0dlb3JnZSBGbGV0Y2hlciZxdW90OyA8YSBocmVmPSJtYWls dG86Z2ZmbGV0Y2hAYW9sLmNvbSI+Jmx0O2dmZmxldGNoQGFvbC5jb20mZ3Q7PC9hPiB3cm90ZTo8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZlZWRiYWNrIG9uIHRoZSBzcGVjLi4uPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDEuIEludHJvZHVjdGlvbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO8Ovwr/CvcOvwr/CvcOvwr/CvSBzZWNvbmQgbGlu ZTogc2NlbmFyaW8gc2hvdWxkIGJlIHBsdXJhbCAtLSZndDsgc2NlbmFyaW9zPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9w6/Cv8K9IHNlY29uZCBzZW50 ZW5jZTogJnF1b3Q7YXJlIG5vdCByYW4gYnkmcXVvdDsgLS0mZ3Q7ICZxdW90O2FyZSBub3QgcnVu IGJ5JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDIuMi4xIEF1dGhl bnRpY2F0aW9uIEluZm9ybWF0aW9uIENsYWltczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IMOvwr/CvcOvwr/CvcOvwr/CvSBJJ20gbm90IHN1cmUgdGhhdCB0aGlzIGRlZmlu aXRpb24gb2YgYGF1dGhfdGltZWAgYWxsb3dzIGZvciB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjYXNlIHdoZXJlIGEgdXNlciBpcyByZXF1aXJlZCB0byBzb2x2ZSBhbiBhZGRp dGlvbmFsIGNoYWxsZW5nZS4gVGFrZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjYXNlIG9mIGEgdXNlciB3aG8gaXMgcmVxdWlyZWQgdG8gcGFzcyBhIHNlY29uZGFyeSBjaGFs bGVuZ2UgYmVmb3JlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3N0 b2NrIHB1cmNoYXNlJnF1b3Q7IGFjdGlvbiBjYW4gYmUgY29tcGxldGVkLiBBY2NvcmRpbmcgdG8g dGhlIGN1cnJlbnQgc3BlYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluaXRp b24sIHRoZSBgYXV0aF90aW1lYCB2YWx1ZSBNVVNUIE5PVCBiZSB1cGRhdGVkIHdoZW4gdGhpczxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlY29uZGFyeSBjaGFsbGVuZ2UgaXMgY29t cGxldGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9w6/C v8K9IEkgdGhpbmsgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4gc2Vzc2lvbl9zdGFydF90 aW1lIGFuZCBsYXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aF90aW1lLiBU aGlzIGZlZWxzIG1vcmUgbGlrZSBpdCdzIGRlZmluaW5nIHRoZSBzZXNzaW9uX3N0YXJ0X3RpbWU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25jZXB0LjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IFRoZXNlIHNhbWUgaXNzdWVzIGNhbiBhcHBs eSB0byB0aGUgYGFjcmAgYW5kIGBhbXJgIHZhbHVlcyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgw6/Cv8K9w6/Cv8K9IEV2ZW4gaWYgZm9yIHRoaXMgc2Vjb25kYXJ5 IGNoYWxsZW5nZSBhIG5ldyByZWZyZXNoX3Rva2VuIGlzIGlzc3VlZCw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpdCBpcyB1bmxpa2VseSBtYW55IHJlbHlpbmcgcGFydGllcyB3aWxs IHdhbnQgdG8gdHJlYXQgdGhhdCBhcyBpc3N1aW5nIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBuZXcgc2Vzc2lvbi4gVGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgdXNlciBsb2dnZWQg aW4gdG8gYSBzaW5nbGUgc2Vzc2lvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rp b24gMi4yLjMgQXV0aG9yaXphdGlvbiBDbGFpbXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr0gSSBmaW5kIHRoZSBzdGF0ZW1lbnQgJnF1b3Q7QWxsIHRo ZSBpbmRpdmlkdWFsIHNjb3BlIHN0cmluZ3MgaW4gdGhlIHNjb3BlPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2xhaW0gTVVTVCBoYXZlIG1lYW5pbmcgZm9yIHRoZSByZXNvdXJjZSBp bmRpY2F0ZWQgaW4gdGhlIGF1ZCBjbGFpbSZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNvbWV3aGF0IHByb2JsZW1hdGljLiBJbiBtYW55IGRlcGxveW1lbnRzIHRvZGF5IGZv ciAxc3QgcGFydHkgY2xpZW50cyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdGFraW5nIGludG8gYWNjb3VudCBtb2JpbGUgYXBw bGljYXRpb25zLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhY2Nlc3MgdG9r ZW4gbW9zdCBsaWtlIGNvbnRhaW5zIHNjb3BlcyBmb3IgbWFueSBvZiB0aGUgMXN0IHBhcnR5PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmFja2VuZCBBUElzLiBJdCdzIHBvc3NpYmxl IHRvIGdldCBhcm91bmQgdGhpcyBieSBzZXR0aW5nIHRoZSAnYXVkJzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2NsYWltIHRvIHNvbWV0aGluZyBsaWtlICZxdW90O2NvbS5leGFtcGxl LmFwaXMmcXVvdDsgYW5kIGhlbmNlIGFsbCB0aGUgaXNzdWVkPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2NvcGVzIG1hcCB0byB0aGF0IGF1ZGllbmNlIGNsYWltIGJ1dCB0aGF0IGlz IGp1c3Qgd29ya2luZyBhcm91bmQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TVVTVCBpbiB0aGUgc3BlYy4gR2l2ZW4gdGhlIGxhY2sgb2Ygc3BlY2lmaWNpdHkgb2YgdGhlICdh dWQnIGNsYWltIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSAncmVzb3Vy Y2UgaW5kaWNhdG9yJyBjbGFpbSBmb3IgdGhhdCBtYXR0ZXIsIHByZXR0eSBtdWNoIGFueXRoaW5n IGNhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIG1hZGUgdG8gY29tcGx5LiBJ biB0aGF0IGNvbnRleHQsIGl0IHNlZW1zIGxpa2UgUkVDT01NRU5EIGlzIGEgYmV0dGVyPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm9ybWF0aXZlIGNsYXVzZS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gMy4gUmVxdWVzdGluZyBhIEpXVCBBY2Nlc3MgVG9rZW48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDr8K/wr3Dr8K/wr0gUGVyIG15 IGNvbW1lbnRzIGFib3ZlIEkgc3VzcGVjdCB0aGF0IHJlcXVpcmluZyBhbGwgSldUIGFjY2VzcyB0 b2tlbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBpbmNsdWRlIGFuIGF1ZGll bmNlIGNsYWltIHdpbGwganVzdCBkZXZvbHZlIHRvIGF1ZGllbmNlIGNsYWltcyB0aGF0PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIHNvbWV3aGF0IHBvaW50bGVzcyAoaW4gb3Jk ZXIgdG8gbWVldCB0aGlzIE1VU1QgaW4gdGhlIHNwZWMpLiBHaXZlbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBtb2JpbGUgYXBwIGVudmlyb25tZW50IHRvZGF5LCBpdCBpcyB1 bnJlYXNvbmFibGUgdG8gYXNrIHRoZSBtb2JpbGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhcHBzIHRvIGRvd25zY29wZSBldmVyeSBhY2Nlc3MgdG9rZW4gYmVmb3JlIG1ha2luZyBh biBBUEkgY2FsbCB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiYWNrZW5k IEFQSXMgd2hpY2ggaXMgd2hhdCB0aGUgc3Bpcml0IG9mIGF1ZGllbmNlIGFuZCByZXNvdXJjZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGljYXRvcnMgc2VlbSB0byBpbXBseS48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBXaHkgTVVTVCB0 aGUgQVMgcmVqZWN0IGEgcmVxdWVzdCB3aXRoIG1vcmUgdGhhbiBvbmUgcmVzb3VyY2U8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXI/IElmIGEgcmVxdWVzdCBjb21lcyBp biB3aXRoIG5vIHJlc291cmNlIHBhcmFtZXRlciBhbmQgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzY29wZXMgdGhlIEFTIGlzIG5vdCByZXF1aXJlZCB0byByZWplY3Qg dGhhdCByZXF1ZXN0LiBJcyB0aGVyZSBtdWNoIG9mIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzZW1hbnRpYyBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3bz8gSW4gdGhlIGNhc2Ug b2Ygbm8gcmVzb3VyY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIg YW5kIG11bHRpcGxlIHNjb3BlcyB0aGUgQVMgbWlnaHQgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdp dGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0aXBsZSBhdWRpZW5jZSB2YWx1 ZXMgKGFzIGlzIGFsbG93ZWQgYnkgUkZDIDc1MTkpLiBBbHNvLCB0aGUgYXVkaWVuY2U8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpbSBpcyBub3Qgc29sZWx5IGZvciByZXNvdXJj ZSBpbmRpY2F0b3IgdmFsdWVzIGJ1dCBpcyBkZWZpbmVkIHRvIGp1c3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBiZSBhIHN0cmluZy4gVG8gbWUgaXQgZmVlbHMgbGlrZSB0aGUgdGV4 dCBpcyBpbXBseWluZyB0aGF0IHRoZSBvbmx5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdmFsaWQgYXVkaWVuY2UgdmFsdWUgaXMgYWxzbyBhIHJlc291cmNlIGluZGljYXRvciAod2hp Y2ggZnJvbSBwcmV2aW91czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc2N1c3Np b25zIG9uIHRoZSBsaXN0IGl0IHdhcyBpbXBsaWVkIHRoZXkgaGF2ZSBhIHNsaWdodGx5IGRpZmZl cmVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbWFudGljKS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBUaGUgbW9kZWwgZGVzY3JpYmVk IGhlcmUgd29ya3Mgd2VsbCBpZiBteWNvLmV4YW1wbGUgcmVhbGx5IG9ubHk8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRlcyBhIHNpbmdsZSBzZXJ2aWNlLiBCdXQgaWYgaW5z dGVhZCBteWNvLmV4YW1wbGUgcHJvdmlkZXMgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzZXJ2aWNlcyBlYWNoIHdpdGggdGhlaXIgb3duIGVuZHBvaW50cyAoc3J2YS5t eWNvLmV4YW1wbGUsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3J2Yi5teWNvLmV4 YW1wbGUpIGFuZCBzY29wZXMsIGZvciBtZSB0aGlzIG1vZGVsIGJlZ2lucyB0byBicmVhayBkb3du LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVpdGhlciBtb2JpbGUgYXBwcyBhcmUg cmVxdWlyZWQgdG8gZG93bnNjb3BlIGFsbCB0b2tlbnMgdG8ganVzdCB0aGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlIHRoZXkgYXJlIGNhbGxpbmcgYXQgdGhhdCBwb2lu dCBpbiB0aW1lICh3aGljaCBjYW4gaGF2ZSBsYXRlbmN5PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYW5kIGNvbm5lY3Rpdml0eSBpc3N1ZXMpLCBvciBteWNvLmV4YW1wbGUgaGFzIHRv IGNyZWF0ZSBhIGdlbmVyaWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDth dWRpZW5jZSZxdW90OyBzdHJpbmcgdGhhdCByZXByZXNlbnRzIGFsbCBvZiBleGFtcGxlLmNvbSB3 aGljaCBkb2Vzbid0IHNlZW08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBiZSB0 aGUgc3Bpcml0IG9mIHRoZSBleGlzdGluZyBzcGVjcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBJbiBzdW1tYXJ5LCBJIGZlZWwgdGhhdCB0aGlzIHRleHQg aXMgYmluZGluZyB0b28gdGlnaHRseSByZXNvdXJjZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGluZGljYXRvcnMgdG8gdGhlIGF1ZGllbmNlIGNsYWltLiBXaGF0IGlzIGRlc2NyaWJl ZCBpcyBwZXJmZWN0bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWFzb25hYmxl IGluIGEgdXNlIGNhc2UgdGhhdCBpcyBhcHBseWluZyByZXNvdXJjZSBpbmRpY2F0b3JzIGluIHRo aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3YXkgYnV0IGlzIG5vdCBpbmRpY2F0 aXZlIG9mIHRoZSB3aWRlbHkgZGVwbG95ZWQgbW9kZWxzIHRoYXQgYWxyZWFkeSBleGlzdC48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNC4gVmFsaWRhdGluZyBKV1QgQWNjZXNz IFRva2VuczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/C vSBTdGVwIDQuIC0tIENhbiB3ZSBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gbm90IHJlcXVpcmUgcmVz b3VyY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0b3JzPyBXaGF0IGFi b3V0Li4uICZxdW90O1RoZSByZXNvdXJjZSBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGF0IHRoZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdhdWQnIGNsYWltIGNvbnRhaW5zIGEgc3Ry aW5nIHRoYXQgcmVwcmVzZW50cyB0aGUgYXVkaWVuY2Ugb2YgdGhpczxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNlIHNlcnZlci4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNlY3Rpb24gNS4gJnF1b3Q7Y3Jvc3MtSldUIGNvbmZ1c2lvbiZxdW90OzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBJIHRoaW5rIHRo ZXJlIG1heSBiZSBjb25mdXNpb24gYXJvdW5kIHdoYXQgaXMgbWVhbnQgYnkgJnF1b3Q7ZGlzdGlu Y3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvdXJjZXMmcXVvdDsuIEluIG15 IGV4YW1wbGUgYWJvdmUsIGFyZSBzcnZhLm15Y28uZXhhbXBsZSBhbmQ8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzcnZiLm15Y28uZXhhbXBsZSAmcXVvdDtkaXN0aW5jdCByZXNvdXJj ZXMmcXVvdDs/IG9yIGlzIHRoZSBnb2FsIGhlcmUgdG8gc2F5IHRoYXQ8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB3ZSB3YW50IGRpZmZlcmVudCBhdWRpZW5jZSB2YWx1ZXMgZ2VuZXJh dGVkIGZvciBjcm9zcy1vcmdhbml6YXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyByZXNvdXJjZXMuIEZvciBleGFtcGxlLCBhcmUgbWFpbC5nb29nbGUuY29tIGFuZCB5b3V0dWJl LmNvbSAmcXVvdDtkaXN0aW5jdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291 cmNlcyZxdW90Oz8gb3Igd291bGQgYW4gYXVkaWVuY2UgZm9yIGdvb2dsZSBzdWZmaWNlIGluIG1l ZXRpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVhbmluZyBvZiB0aGlz IHBhcmFncmFwaD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMOvwr/CvSBJJ20g aGF2aW5nIHRoZSBzYW1lIGNvbmZ1c2lvbiBpbiB0aGUgbmV4dCBwYXJhZ3JhcGggcmVnYXJkaW5n IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBocmFzZSAmcXVvdDtkaWZmZXJl bnQgcmVzb3VyY2VzJnF1b3Q7LiBBcmUgc2VydmljZXMgcHJvdmlkZWQgYnkgdGhlIHNhbWUgY29t cGFueTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2RpZmZlcmVudCByZXNv dXJjZXMmcXVvdDsgb3IgYXJlIHRoZXkgYWxsIGNvbnNpZGVyZWQgdGhlIHNhbWUgcmVzb3VyY2Uu IENhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIGFjY2VzcyB0b2tlbiBiZSBp c3N1ZWQgd2l0aCBzY29wZXMgZm9yIGJvdGggbWFpbC5nb29nbGUuY29tIGFuZDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlvdXR1YmUuY29tPyBBbmQgaWYgbm90LCB3aHkgbm90ZT8g UHJldmVudGluZyB0aGlzIHB1dHMgdW5kdWUgYnVyZGVuIG9uPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbW9iaWxlIGJhc2VkIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNlY3Rpb24gNi4gUHJpdmFjeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IMOvwr/CvcOvwr/CvSBjb2ZpZGVudGlhbGl0eSAtLSZndDsgY29uZmlkZW50aWFs aXR5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBHZW9yZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_897809C25ABB43A499650950EC7126F5amazoncom_-- From nobody Sun Apr 5 05:11:34 2020 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 8C5763A017E; Sun, 5 Apr 2020 05:11:29 -0700 (PDT) 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: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158608868945.18323.557347538112056951@ietfa.amsl.com> Date: Sun, 05 Apr 2020 05:11:29 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.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: Sun, 05 Apr 2020 12:11:30 -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 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-15.txt Pages : 46 Date : 2020-04-05 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15 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 Sun Apr 5 11:43:36 2020 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 8EA433A0A97 for ; Sun, 5 Apr 2020 11:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqSQUiihrKnY for ; Sun, 5 Apr 2020 11:43:04 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 325183A0A8C for ; Sun, 5 Apr 2020 11:43:03 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id o3so13413743ioh.2 for ; Sun, 05 Apr 2020 11:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=dvaMRC4Y5XuS6t9q1MW1/+R0JMgyDly1y6uJuh0BqPY=; b=jzIB7DkZeobf3BJXTKpsPRkCh00VoO8xhdSd4/aj/Xwlcl9iazLisFSMa1+b3uy4bA 1Rsn80oTMxA8wLwDDPGas4H4uN/MHdnz3VGGPBm3biMwILFjZgwPR01ikYRVCS7RO6iu JEJSzyMWmEldzT1b67vNwEZEeIDjG1k1GMoYBUxFsYMVfV4pZWrFOVF4GwH1FuIaujtS oR7NJHyVL55EuEBxy/CF81f/s24dLpHUZ9z8/+CZPriOgg0W3zjh7ylCyra8IJa3R1MU xv8sTTiSL57WJqd3PkE/UMmi91O40ak93dqEhlMVuMt2G5M1ORR1FJuKEeqI0lzixr5d NHkQ== 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:cc; bh=dvaMRC4Y5XuS6t9q1MW1/+R0JMgyDly1y6uJuh0BqPY=; b=pOfaemWYd1AjfDArQY14r3TftnbiPPFsmE930e6nSpccinrnM8sIvve9HfEYf4X1we rZ+SHVV9Shg0lnHKJ7AxWeHB2+6YX6gA/KjF7ZsesEMzg0bYpxnStwuHrXyiLMUpBgrG rfh1NML032AgW68fRiXZLVFbfSDcIC0ynCEjIXPJL1AaTa1C1xO0+2QARQydxFr+J29N AAnw42W/70AY084h+vlispyGTdY25kbNVsyb8Oi5dbFOMWDI/BLa+xcbAx4V3OIlGrxH YcItjbSgoNGgp5ZG5TIdgS3IR5Eg6N2jSF8s4nbnq8FyDqzqibuHpMjwnePmuMZF0FLj XU/g== X-Gm-Message-State: AGi0PuYXajEX2ENzqWHpwuoINU+SElRbU7SwqaPLPZwPcUIvJ8cxFcl6 R8U+JENUyYoCHkp5j2CbIGSwo2MfYYA= X-Google-Smtp-Source: APiQypIEMI2pd0UJlkHHGp8IJ//G76/rBnSBdsTGJx2Dy8gaOWTrxGb9llCBSRos3ZwCtLJ3TUFx6A== X-Received: by 2002:a02:2a4a:: with SMTP id w71mr17705720jaw.75.1586112181798; Sun, 05 Apr 2020 11:43:01 -0700 (PDT) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id h29sm5159055ili.19.2020.04.05.11.43.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Apr 2020 11:43:00 -0700 (PDT) Received: by mail-il1-f170.google.com with SMTP id i75so12508508ild.13 for ; Sun, 05 Apr 2020 11:43:00 -0700 (PDT) X-Received: by 2002:a05:6e02:54e:: with SMTP id i14mr18905658ils.166.1586112180106; Sun, 05 Apr 2020 11:43:00 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Sun, 5 Apr 2020 11:42:49 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="00000000000011be9905a28f856f" Archived-At: Subject: [OAUTH-WG] OAuth Security BCP -15 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: Sun, 05 Apr 2020 18:43:19 -0000 --00000000000011be9905a28f856f Content-Type: text/plain; charset="UTF-8" Section 2.1.1 says: Clients MUST prevent injection (replay) of authorization codes into > the authorization response by attackers. The use of PKCE [RFC7636] > is RECOMMENDED to this end. The OpenID Connect "nonce" parameter and > ID Token Claim [OpenID] MAY be used as well. Minor nit: this should be "ID Token claim" with a lowercase "c". I spent a while trying to figure out what an "ID Token Claim" is before realizing this sentence was referring to the "nonce" claim in an ID Token. Aside from that, I'm struggling to understand what this section is actually saying to do. Since this is in the "Authorization Code Grant" section, is this saying that using response_type=code is fine as long as the client checks the "nonce" in the ID Token obtained after it uses the authorization code? It seems like that would still allow an authorization code to be injected. I don't see how the "nonce" parameter solves anything to do with the authorization code, it seems like it only solves ID token injections via response_type=id_token. In any case, this section could benefit from some more explicit instructions on how exactly to prevent authorization code injection attacks. ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000011be9905a28f856f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 2.1.1 says:

=C2=A0 =C2=A0Clients MUST prevent inje= ction (replay) of authorization codes into
=C2=A0 =C2=A0the authorizatio= n response by attackers.=C2=A0 The use of PKCE [RFC7636]
=C2=A0 =C2=A0is= RECOMMENDED to this end.=C2=A0 The OpenID Connect "nonce" parame= ter and
=C2=A0 =C2=A0ID Token Claim [OpenID] MAY be used as well.

Minor nit: this should be "ID Token claim&qu= ot; with a lowercase "c". I spent a while trying to figure out wh= at an "ID Token Claim" is before realizing this sentence was refe= rring to the "nonce" claim in an ID Token.

Aside from that, I'm struggling to understand what this section is a= ctually saying to do. Since this is in the "Authorization Code Grant&q= uot; section,=C2=A0is this saying that using response_type=3Dcode is fine a= s long as the client checks the "nonce" in the ID Token obtained = after it uses the authorization code? It seems like that would still allow = an authorization code to be injected. I don't see how the "nonce&q= uot; parameter solves anything to do with the authorization code, it seems = like it only solves ID token injections via response_type=3Did_token.
=

In any case, this section could benefit from some more = explicit instructions on how exactly to prevent authorization code injectio= n attacks.

----
Aaron Parecki
=
--00000000000011be9905a28f856f-- From nobody Sun Apr 5 12:25:06 2020 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 49FF63A065A for ; Sun, 5 Apr 2020 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cks9TqnGy6bp for ; Sun, 5 Apr 2020 12:25:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 25CAE3A08B6 for ; Sun, 5 Apr 2020 12:24:56 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id y14so13395404iol.12 for ; Sun, 05 Apr 2020 12:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=f3V3RZ/rLtolN65iZ1HwIqlW725wV0jJcIsnZlr88pw=; b=SIXTgmPsAdsbqLciE/nDGaUTVsC2aeVau4Z8sF0QOQpCcTvpuKI9K07XjTBFmpC7vM PseGpoBlslpZoEYT79Nmkw2AqinQtRE8QP5BGkRQ3DbDZy+Mrv+g2H3YuNugkyoC6Ai/ VCNYtqI3NRXBoVaFZ0WOPO9n1ruUWvFS99TBe//vq8FfwYuNgaEHq9ePURouDdnTq9Jf Xl1bVVVVgJys9PdncShHMFKCXreuof0chMmKdKZEj5P0acK/bJphgzOIJVCjFmkxOrCH qTl/TnYkYYnaMZrdgSZP2AhS3gO9GaIfzzMipeICYhs+rQV89Z1CwQ/VOTyS78MWqDiK /w2A== 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:cc; bh=f3V3RZ/rLtolN65iZ1HwIqlW725wV0jJcIsnZlr88pw=; b=oCfI+tV4rmiD0icUGzP8KB6zGaBFsgijL4H5A3ww+GHHx7PVpOvDwIr5s9X8OFvZPY 5vAJqr4trim6hv/nnc+xjR9ZYAzY2ieUPbGFxNz1P7W2lv/540HmuEadmBl8HzL/LJvU hNXN7WfUfx2LuntwM7FFLWZVOHpb8uajQH5d+b+L1BsqJCn5yaBi9QdjWMGBQbIM8X7o tfohOqQBDPgUGxiOHROuINd9hAX+37bhCXxKJI97v+yCRiEB9nNgEc53P49cxCC6ZTxF ldeesFbTeQsetmIrF6butEekfPAkNzrTSaV/ehic1dYg+WuAiD71F7RNHwQLGT/9zlgc ouew== X-Gm-Message-State: AGi0PuYIMYcea2RsoYKnvyk0/271YcCX0g8bzzRXhMHS37jdBJFgUYpo +vFbGU145sldByTss+dO/cPAXvCmdEM= X-Google-Smtp-Source: APiQypKq2bRxdrzIbtLBKdH110lj6ue0lA7Sn//E9l9vcdeT1s8YJXzL5IdHlxMewdU82yzOZSLHHw== X-Received: by 2002:a5e:a504:: with SMTP id 4mr16546505iog.210.1586114695375; Sun, 05 Apr 2020 12:24:55 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id z15sm5256543ilf.0.2020.04.05.12.24.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Apr 2020 12:24:54 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id y17so11345172iow.9 for ; Sun, 05 Apr 2020 12:24:54 -0700 (PDT) X-Received: by 2002:a02:e81:: with SMTP id 123mr17945613jae.0.1586114694115; Sun, 05 Apr 2020 12:24:54 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Sun, 5 Apr 2020 12:24:43 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000ea763305a2901a81" Archived-At: Subject: [OAUTH-WG] Refresh tokens in Security BCP -15 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: Sun, 05 Apr 2020 19:25:05 -0000 --000000000000ea763305a2901a81 Content-Type: text/plain; charset="UTF-8" I believe the document would flow better if section 4.12 about Refresh Tokens were moved into section 2. The Refresh Token section contains descriptions of some pretty significant normative behavior, and I worry that it will get lost in the long list of attacks and mitigations. Section 2 starts with a description: "This section describes the set of security mechanisms the OAuth working group recommends to OAuth implementers.", and the whole section on refresh tokens seems like a pretty significant recommendation. ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000ea763305a2901a81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the document would flow better if section 4= .12 about Refresh Tokens were moved into section 2. The Refresh Token secti= on contains descriptions of some pretty significant normative behavior, and= I worry that it will get lost in the long list of attacks and mitigations.=

Section 2 starts with a description: "This s= ection describes the set of security mechanisms the OAuth working group rec= ommends to OAuth implementers.", and the whole section on refresh toke= ns seems like a pretty significant recommendation.

----
--000000000000ea763305a2901a81-- From nobody Sun Apr 5 14:16:51 2020 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 59DF83A0E0D; Sun, 5 Apr 2020 14:16:48 -0700 (PDT) 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: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <158612140822.18232.15128182245846119504@ietfa.amsl.com> Date: Sun, 05 Apr 2020 14:16:48 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-06.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: Sun, 05 Apr 2020 21:16:49 -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 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-06.txt Pages : 21 Date : 2020-04-05 Abstract: This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-06 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 Sun Apr 5 14:47:37 2020 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 54B793A0E7E for ; Sun, 5 Apr 2020 14:47:34 -0700 (PDT) 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 m_YNihPkcVMn for ; Sun, 5 Apr 2020 14:47:32 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51003A0E7C for ; Sun, 5 Apr 2020 14:47:31 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id u2so197342iop.10 for ; Sun, 05 Apr 2020 14:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WUsZqZBMO6Cw9xint2aJ8ureDnKZL5lco3E7r0LPEGs=; b=GZNo7AYPWVlbCSvrdNL0CdQ+F1lGqWDeqFc+3ZrsCMPyikEusMQE+0KIQQVg3Aalwi SFi+yLXBuoyiqIn6hjLGVAY6iUtpUNDxgInpm0RnOu+PxK7rH6jJrQmRHmKKPH82HIYV kfz3YuY3GC5W15/a/9mIdqcdGsV8crR+r4gYv9qfgafOyoEckwfbTyktLfj5sr0yZ1No VMwVKUw0jhlQgMAMOq6UCSLRAJyzPhHyhl4MoerGrGlZ0eRzyEzI59uVu2GyXDMwYAk2 d891gKe4jwFsXu8AgPotYTYZfXPXjXBP4qF+QXGZjVTwobyVO5YSlzPx9/9cr3R90Ukx s6JQ== 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=WUsZqZBMO6Cw9xint2aJ8ureDnKZL5lco3E7r0LPEGs=; b=ctTMdrepGbw/FfKGdlH8uZGrGppX/XDNqBm9SPcsEL2qPMM1m1+YvgjdIxfUWjoELk RKdZBMVEItWcv9OAOeTHjJTzfKiE8/Jv3eA48lbT4Ga5Ji1sDNCRYtvHkq7lE0jH++iM 3sEUh8HxcZkpYoJU3fpg4pZj7yBU1QvlXNBMb5YH1AHtNU2YHsFQSlvHwFeL9k4+KWuw B6vR9euvy2ZX9xLF005uuHlnpP3tOgNrLqUE1Dr+5nN1nDrho029Gw6nrjqRDPhqIbvc lXDims5DQPpkDYlLMx6nXFaZdII5lxiVc+vaJh886iOZY2U7+lCk9TsD+6oM7CSVPc0r bcLg== X-Gm-Message-State: AGi0PuYExW63UMlYey8kR6xw5/kpL3izNQRiCNhil/m7133BPAL5gUMd sUiYjFmEHDFpbCGiydCIkCBgLZytQn9a6X7A4nnTe2VL X-Google-Smtp-Source: APiQypJgHm6vjAMSo1clOe9HcP0xl+OoegvZ73gkOn25vwkyNUXOek5wSBwLvtq5MTohenn5VRl4BuMUESMG8yLtuLQ= X-Received: by 2002:a05:6638:626:: with SMTP id h6mr15480804jar.70.1586123250356; Sun, 05 Apr 2020 14:47:30 -0700 (PDT) MIME-Version: 1.0 References: <158583623802.26510.6501784119483278282@ietfa.amsl.com> In-Reply-To: <158583623802.26510.6501784119483278282@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Sun, 5 Apr 2020 17:47:19 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000e856e905a29218c7" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-06 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: Sun, 05 Apr 2020 21:47:34 -0000 --000000000000e856e905a29218c7 Content-Type: text/plain; charset="UTF-8" All, You can find the slides for tomorrow's meeting at the following link: https://datatracker.ietf.org/meeting/interim-2020-oauth-03/session/oauth Regards, Rifaat On Thu, Apr 2, 2020 at 10:06 AM IESG Secretary wrote: > The Web Authorization Protocol (oauth) Working Group will hold > a virtual interim meeting on 2020-04-06 from 18:00 to 19:00 Europe/Vienna > (16:00 to 17:00 UTC). > > Agenda: > Two documents: > > 1) OAuth Security Topics > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 > 2) Browser-Based Apps > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 > > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m7e39bc19240468eafc9b00a0ebc673b0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --000000000000e856e905a29218c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

You can find the slides for tomorr= ow's meeting at the following link:

Regards,
=C2=A0Rifaat
=C2=A0

On Thu, Apr 2, 2020 at 10:06 AM IESG Secretary <iesg-secretary@ietf.org> wrote:
The Web Authorization Protocol (= oauth) Working Group will hold
a virtual interim meeting on 2020-04-06 from 18:00 to 19:00 Europe/Vienna (= 16:00 to 17:00 UTC).

Agenda:
Two documents:

1) OAuth Security Topics
https://tools.ietf.org/html/draft-iet= f-oauth-security-topics-14
2) Browser-Based Apps
https://tools.ietf.org/html/draft-= ietf-oauth-browser-based-apps-05


Information about remote participation:
https://ietf.webex.com/iet= f/j.php?MTID=3Dm7e39bc19240468eafc9b00a0ebc673b0

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--000000000000e856e905a29218c7-- From nobody Sun Apr 5 15:13:03 2020 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 68E003A0CCD for ; Sun, 5 Apr 2020 15:13:00 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alkaline-solutions.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 AKUMYkUaCBhm for ; Sun, 5 Apr 2020 15:12:58 -0700 (PDT) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227633A0CCA for ; Sun, 5 Apr 2020 15:12:57 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 0854A38492A; Sun, 5 Apr 2020 22:12:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1586124776; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LXVc1pqrw53sbYfUa9op6VIFxQqosyQIrV4QkMNkykM=; b=Zw3kcBlt3g6N/LmB1VkmUxGT/R8SP/Taf+4GhLiz8fO9/dZV8qwVkgjv8mP/OMgODVwoFw veQ5cnEywM5Zt8c49FncqEtxhqsoAVxXLElDaEiArR/4/6AKzxby2lgoAPeL1cnIWPilBd gjFTmPlDOaQQkQ2Y52EgToj/m9uEewk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From: David Waite In-Reply-To: Date: Sun, 5 Apr 2020 16:12:54 -0600 Cc: OAuth WG Content-Transfer-Encoding: quoted-printable Message-Id: <6C67B4E7-678B-43ED-BECF-53E7AAA21872@alkaline-solutions.com> References: To: Aaron Parecki ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1586124777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LXVc1pqrw53sbYfUa9op6VIFxQqosyQIrV4QkMNkykM=; b=ffe1i6iM/WOOA19+UAW/x5q6LKHIXzyqwcoJTBflqk8fSVwgsevVHxpHv8qQbPFNlIFJ45 4BLlC84opaqrjDh7c8Rr3fmt8JUbglXZhzQzTuXGmVfFVaeiJZ+J65N7joFrAtucj7tl8b E865Ht8UuQZvOP9fYUtf+L4qZsya3nM= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1586124777; a=rsa-sha256; cv=none; b=Lebh0piWnAiHgR01+yz29+wkWnt87caNVg0PzaLaaejIS5g3euTkW4FbM40p4R1dhk17FG UpTkVahg13sXtnfoJunAAJ/2veM8VgVBpdnnW0lo5puq2dWXi9t4Y4MD5n1BFTek8K8uo6 5M14C9X+Rhr2+/Pu6GyofVhLj7oTr2s= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] OAuth Security BCP -15 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: Sun, 05 Apr 2020 22:13:01 -0000 On Apr 5, 2020, at 12:42 PM, Aaron Parecki wrote: > Aside from that, I'm struggling to understand what this section is = actually saying to do. Since this is in the "Authorization Code Grant" = section, is this saying that using response_type=3Dcode is fine as long = as the client checks the "nonce" in the ID Token obtained after it uses = the authorization code? It seems like that would still allow an = authorization code to be injected. I don't see how the "nonce" parameter = solves anything to do with the authorization code, it seems like it only = solves ID token injections via response_type=3Did_token. With PKCE, the client sends a challenge value to the authorization = endpoint and a verifier value to the token endpoint. The authorization = server will thus be able to correlate the request and response were made = by the same client instance, and reject issuing tokens if there is an = issue. With OIDC nonce, the client sends a nonce value to the auth endpoint and = _receives_ that nonce back inside the id_token. The client can verify = that the response corresponds to the request it made and reject = requesting/using tokens if there is an issue. The first solution will almost inarguably lead to better = implementations, as the single AS is taking responsibility for = verification before issuing tokens, vs relying on potentially many = client instances to do proper verification. But both do solve the = problem. The problem I have with this choice is that a client library will not = necessarily know PKCE is being honored vs ignored by the AS. So a client = would need to always do _both_ to be a good citizen in some cases. So I = would prefer that clients and servers MUST support PKCE, but servers MAY = also allow nonce usage for security in the case of non-compliant clients = (with appropriately vetted conformance to OIDC). > In any case, this section could benefit from some more explicit = instructions on how exactly to prevent authorization code injection = attacks. Indeed. -DW= From nobody Mon Apr 6 00:09:35 2020 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 06BEC3A083D for ; Mon, 6 Apr 2020 00:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 kAcJcymU6rPs for ; Mon, 6 Apr 2020 00:09:27 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAF93A0832 for ; Mon, 6 Apr 2020 00:09:27 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id C6CFA3288; Mon, 6 Apr 2020 07:09:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586156965; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=smqiPpjLdvmoRY3MrMEodb4LloLcEFKX3BIqj76wPaI=; b=Jojw1Vv/8Sg5WvFM2KDYtPv/F4E+jPO3Ak55+F/zlg38VQvjPPC8vsUGkp8NlMZQZ9nFGf mgNUD9IMjuzpHMCgGpcsgV325YreLpGEJYOE5RR8m02fD0HiA4P1xnvOA8o/9sKjercqcD QZM1QxlOOCikUkrW45UdxgGlYvrm76A= To: Aaron Parecki , OAuth WG References: From: Daniel Fett Message-ID: <91012825-2bef-297a-1d9a-89c8c9e1f7f3@danielfett.de> Date: Mon, 6 Apr 2020 09:09:23 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D83C959481BB5C12878B4191" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586156965; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=smqiPpjLdvmoRY3MrMEodb4LloLcEFKX3BIqj76wPaI=; b=scZd73ttEN5wvREJU9EIfBR+/LcLxmHXr9/n0ex1JZ+oN7dlwWR/mItZuPwMThasg8Wyjb ErYqXzv8wBbsDbxFjmZBK6YuXj3TuQTBmI5QfgUtEWA7jc4GtPFVQ92o0UziCfTiUmfqi0 rxdlmo/RyVNNa64q+muQZLDxGdiQHP4= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1586156965; a=rsa-sha256; cv=none; b=WKssrMGc25+0MWaUPL3Wa0F4UbKxJ7qKvCBsy0XLJgD56WIuEuoNYy5UGBz4JEMZpyyuTD r4iUNS9BRd57htjFNAx/n2P47UmFNgmiv8Gp+NFuUtLo1Ea9d4KK38SL5QlfxWyPhIf1MG Wypt2K1HqMsOOm/abRBuwQINLV9C2X0= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] OAuth Security BCP -15 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, 06 Apr 2020 07:09:31 -0000 This is a multi-part message in MIME format. --------------D83C959481BB5C12878B4191 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Aaron, Thanks for your feedback! Am 05.04.20 um 20:42 schrieb Aaron Parecki: > Section 2.1.1 says: > >    Clients MUST prevent injection (replay) of authorization codes into >    the authorization response by attackers.  The use of PKCE [RFC7636] >    is RECOMMENDED to this end.  The OpenID Connect "nonce" > parameter and >    ID Token Claim [OpenID] MAY be used as well. > > > Minor nit: this should be "ID Token claim" with a lowercase "c". I > spent a while trying to figure out what an "ID Token Claim" is before > realizing this sentence was referring to the "nonce" claim in an ID Token. Upper case "Claim" follows the convention in OIDC Core, which says for example, "these additional requirements for the following ID Token Claims apply". To keep the documents consistent, I will change the sentence above to "The OpenID Connect "nonce" parameter and the respective Claim in the ID Token [OpenID] MAY be used as well." > > Aside from that, I'm struggling to understand what this section is > actually saying to do. Since this is in the "Authorization Code Grant" > section, is this saying that using response_type=code is fine as long > as the client checks the "nonce" in the ID Token obtained after it > uses the authorization code? It seems like that would still allow an > authorization code to be injected. I don't see how the "nonce" > parameter solves anything to do with the authorization code, it seems > like it only solves ID token injections via response_type=id_token. The injected authorization code would always refer to a different session (started with a different nonce). The client would therefore get an ID Token with a different nonce. The assumption is that the client would then throw away both the ID Token and the access token. Does that make sense? > > In any case, this section could benefit from some more explicit > instructions on how exactly to prevent authorization code injection > attacks. Indeed, we should add a sentence or two on that. -Daniel --------------D83C959481BB5C12878B4191 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Aaron,

Thanks for your feedback!

Am 05.04.20 um 20:42 schrieb Aaron Parecki:
Section 2.1.1 says:

   Clients MUST prevent injection (replay) of authorization codes into
   the authorization response by attackers.  The use of PKCE [RFC7636]
   is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
   ID Token Claim [OpenID] MAY be used as well.

Minor nit: this should be "ID Token claim" with a lowercase "c". I spent a while trying to figure out what an "ID Token Claim" is before realizing this sentence was referring to the "nonce" claim in an ID Token.

Upper case "Claim" follows the convention in OIDC Core, which says for example, "these additional requirements for the following ID Token Claims apply".

To keep the documents consistent, I will change the sentence above to

"The OpenID Connect "nonce" parameter and the respective Claim in the ID Token [OpenID] MAY be used as well."


Aside from that, I'm struggling to understand what this section is actually saying to do. Since this is in the "Authorization Code Grant" section, is this saying that using response_type=code is fine as long as the client checks the "nonce" in the ID Token obtained after it uses the authorization code? It seems like that would still allow an authorization code to be injected. I don't see how the "nonce" parameter solves anything to do with the authorization code, it seems like it only solves ID token injections via response_type=id_token.

The injected authorization code would always refer to a different session (started with a different nonce). The client would therefore get an ID Token with a different nonce. The assumption is that the client would then throw away both the ID Token and the access token.

Does that make sense?


In any case, this section could benefit from some more explicit instructions on how exactly to prevent authorization code injection attacks.

Indeed, we should add a sentence or two on that.

-Daniel

--------------D83C959481BB5C12878B4191-- From nobody Mon Apr 6 06:59:47 2020 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 5FF723A0140 for ; Mon, 6 Apr 2020 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVw3nKm0zLZX for ; Mon, 6 Apr 2020 06:59:42 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 87B8C3A012A for ; Mon, 6 Apr 2020 06:59:41 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id t11so14762314ils.1 for ; Mon, 06 Apr 2020 06:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L+G4eNM21YKrbigQFAMb6zUn5s3bjTAJmCzztPLNK+E=; b=UBRfUmd3QIcFCxw8w1qjW6cc9mf6KvU9u33YK/7EJSjsDiIIDrCsEs9ZlknIdz5b5u ogkBOMhdUp1S8e2WfNR1tgVqPnB+9HaneNHHKvRcqP+MplgB85+frin+gyIB8WZUXAOd 4DB7HI5+J6/qO6PEKiL92Q1w13FwFovFXi5gxKJIj6oXOsGItEWr6hF4GJAStAvhMzoS tfgXHMeMNaZaiB/hCX8IOX7ea2oSHx2fk740lHd+UOwD7ov5UvDlGR1uZkpViqmgCztp PtqYyBVhiIY4fUcJX1Q1Il9fXYR67oy22KnbiDjA6JwEztfd7uVKkZp2UyCP52r4ikXE SPoQ== 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=L+G4eNM21YKrbigQFAMb6zUn5s3bjTAJmCzztPLNK+E=; b=mNblJQijovsNsUXmixGvnPbhCSqBYlHN7+yR/GHao9EUd/YmJKGtXYnsh1r/RD5Snl 8M95h+KjwkVJxd/o/bc6pYuPUb1GoU6y+c5akzPzoja6sG78ev3apL0C2VIH+Pl7K6l0 JxmA6l4PKfShAS6wMJDjEji0VHkcQfJ/8aATOjVsEDf2QM5cc+5vXsvrJYUU6cjVE0BF TVcYteJaoLnHoKrMKrFT2jIDK+xkWz1AwCT5Fvd0TPSc/YM2St0VKChLdWqFi5dP4xjk vx+9lbJlVVgf+ulNAW4zJGFwopvsZi5JTSgV+pxmsc0XNuGVPPubftKMbC5lJi4xtvgX NKrA== X-Gm-Message-State: AGi0PuYsogBSiJK87jmBDtppyJN889Ox2FKRUZr/Vkb+9wlyBaYgqNAP 0IQrgEiRWJFRGS6+1jQ1iNbJRQogq+k= X-Google-Smtp-Source: APiQypJEN2DsdktuR0fQx1ke8bMZaw5pLdU4Mvpia7MJHtqWFdKWqQ3GhCjyRMJLBmKs+CfHVFu5gA== X-Received: by 2002:a92:c00e:: with SMTP id q14mr19804278ild.124.1586181580738; Mon, 06 Apr 2020 06:59:40 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id e62sm5981033ill.52.2020.04.06.06.59.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 06:59:39 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id i3so15789510ioo.13 for ; Mon, 06 Apr 2020 06:59:39 -0700 (PDT) X-Received: by 2002:a5d:9cc3:: with SMTP id w3mr6450569iow.14.1586181579203; Mon, 06 Apr 2020 06:59:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Mon, 6 Apr 2020 06:59:28 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Daniel Fett Cc: OAuth WG , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="00000000000093ee1005a29fadf3" Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens in Security BCP -15 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, 06 Apr 2020 13:59:45 -0000 --00000000000093ee1005a29fadf3 Content-Type: text/plain; charset="UTF-8" Keeping the details in section 4 makes sense. I think why I was confused is that there isn't a subheader in section 2 for refresh tokens so it's not immediately obvious until you get to section 4. What about adding a new subhead in section 2 with just that short summary and referring to section 4 for details? Aaron On Mon, Apr 6, 2020 at 12:24 AM Daniel Fett wrote: > Hi Aaron, > > Am 05.04.20 um 21:24 schrieb Aaron Parecki: > > I believe the document would flow better if section 4.12 about Refresh > Tokens were moved into section 2. The Refresh Token section contains > descriptions of some pretty significant normative behavior, and I worry > that it will get lost in the long list of attacks and mitigations. > > Section 2 starts with a description: "This section describes the set of > security mechanisms the OAuth working group recommends to OAuth > implementers.", and the whole section on refresh tokens seems like a pretty > significant recommendation. > > So far the approach was to keep the recommendations in Section 2 rather > brief and to have the details in Section 4. I would like to keep it that > way. > > The Refresh Token section in Section 4 has a lot of discussion that puts > the recommendations in context. Section 2 refers to that section with the > sentence "Refresh tokens MUST be sender-constrained or use refresh token > rotation as described in Section 4.12.". It catches the main normative > change and refers Section 4 for details. > > I propose to just highlight that sentence a little bit more (make it its > own paragraph). > > -Daniel > -- ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000093ee1005a29fadf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Keeping the details in section 4 makes sense. I thin= k why I was confused is that there isn't a subheader in section 2 for r= efresh tokens so it's not immediately obvious until you get to section = 4. What about adding a new subhead in section 2 with just that short summar= y and referring to section 4 for details?

=
Aaron




On Mon, Apr 6, 2020 at 12:24 AM = Daniel Fett <fett@danielfett.de> wrote:
=20 =20 =20
Hi Aaron,

Am 05.04.20 um 21:24 schrieb Aaron Parecki:
=20
I believe the document would flow better if section 4.12 about Refresh Tokens were moved into section 2. The Refresh Token section contains descriptions of some pretty significant normative behavior, and I worry that it will get lost in the long list of attacks and mitigations.

Section 2 starts with a description: "This section describes the set of security mechanisms the OAuth working group recommends to OAuth implementers.", and the whole section on refresh tokens seems like a pretty significant recommendation.

So far the approach was to keep the recommendations in Section 2 rather brief and to have the details in Section 4. I would like to keep it that way.

The Refresh Token section in Section 4 has a lot of discussion that puts the recommendations in context. Section 2 refers to that section with the sentence "Refresh tokens MUST be sender-constrained or use refresh token rotation as described in Section 4.12.". It catches the main normative change and refers Section 4 for details.

I propose to just highlight that sentence a little bit more (make it its own paragraph).

-Daniel

--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--00000000000093ee1005a29fadf3-- From nobody Mon Apr 6 07:10:13 2020 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 57BF13A045B for ; Mon, 6 Apr 2020 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSUCRWKFpbZQ for ; Mon, 6 Apr 2020 07:10:05 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 9B8F53A058F for ; Mon, 6 Apr 2020 07:09:24 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id m4so31554ioq.6 for ; Mon, 06 Apr 2020 07:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKqpjzcQvFPRALqy7QcKPRYAFwQcpy0V49hQ7nbUPHo=; b=WMJ1girFd2k+J9vzq5d3HeHI9nVN3lnnzcg9JDWCSDEV/0fBcm1KWLCPE4gFwsZbL6 n5+dKFjAcs2S745ojmCnU2ZjA5I6NC3yzVr7zzjeVh3P9cujzDzAbZp41tcImSE5o9OW GHGROm8CvRgB0BJ37RsvkRa+ujzQ7tMrI2LHFXgQDWuI2/y2S0c6X0j6I/MtTUXWQtvS nIhuMlpxGpKMmZMVAx+taV0CxnXn+vkvXXhezlRwTy/oenbpyUJaPT+yoN5uSTTzV4y8 SWr8PIs26KCfsXuQeOi1SN8esqS2Xc0SdMyy3RWqDz3DgAwVSYEbXdhi6+xFDfAETjnE Eg2g== 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=bKqpjzcQvFPRALqy7QcKPRYAFwQcpy0V49hQ7nbUPHo=; b=eNVjOvlPTEUPl1A35mcHps4xM1rpjeCYlIQo5E0U8bImgzIOLxOpMFfs839ArmCSmn 8wobSB7RBgZqw06aao6x+w8odHrE8hI+40u6q7X0CcZ5FNBMAtdq+21SFV4/bbOXW1zI 4R/uuEsaOU5RyPJ9hVY63YGZcn/h9ljE/W6S0+z33uRyW9z8U13umwyw2Y7hteL33DlW 9VPHfiV5PA4xstx9gU7YngKJ6DDgd5GRcRST4JXktJ3h0h5E0FoBZOZnbFmvX3RTO4KJ Jy/E94JUO6BrA/Ep7XUtEd8Ml9wYRveuFYL+8Jjhy9NId7xzLSeMfwVmrhGSQdrVa446 4U+Q== X-Gm-Message-State: AGi0PubPOSowuhbmwRzPurzvle6+Dgh02I5a0RRZX7Cm9/cUwDS0dlzJ 7Boyi6GIx0TDfURgVAfALWuSoTZL568= X-Google-Smtp-Source: APiQypJfFFpZXIxbovbciWnahU+uT9RT6dJLoCjLfsWHIMfLMpx5wveTE3Ou8/rdC4Eeh2QGe9U6Nw== X-Received: by 2002:a5d:984b:: with SMTP id p11mr19807944ios.175.1586182163098; Mon, 06 Apr 2020 07:09:23 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id k16sm6004361ila.38.2020.04.06.07.09.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 07:09:22 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id t6so14737977ilj.8 for ; Mon, 06 Apr 2020 07:09:22 -0700 (PDT) X-Received: by 2002:a92:b74d:: with SMTP id c13mr21655271ilm.105.1586182161691; Mon, 06 Apr 2020 07:09:21 -0700 (PDT) MIME-Version: 1.0 References: <91012825-2bef-297a-1d9a-89c8c9e1f7f3@danielfett.de> In-Reply-To: <91012825-2bef-297a-1d9a-89c8c9e1f7f3@danielfett.de> From: Aaron Parecki Date: Mon, 6 Apr 2020 07:09:10 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Daniel Fett Cc: OAuth WG , Torsten Lodderstedt Content-Type: multipart/alternative; boundary="0000000000004c0f0905a29fd0dc" Archived-At: Subject: Re: [OAUTH-WG] OAuth Security BCP -15 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, 06 Apr 2020 14:10:11 -0000 --0000000000004c0f0905a29fd0dc Content-Type: text/plain; charset="UTF-8" > > The injected authorization code would always refer to a different session > (started with a different nonce). The client would therefore get an ID > Token with a different nonce. The assumption is that the client would then > throw away both the ID Token and the access token. This is true as long as the client actually validates the ID token it obtained at the token endpoint, even though it may have already obtained one from the authorization response. (e.g. response_type=code+id_token). It feels like this should be explained in a little more detail, since having to validate two ID tokens to protect against this attack is not necessarily obvious. Aaron ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Apr 6, 2020 at 12:09 AM Daniel Fett wrote: > Hi Aaron, > > Thanks for your feedback! > > Am 05.04.20 um 20:42 schrieb Aaron Parecki: > > Section 2.1.1 says: > > Clients MUST prevent injection (replay) of authorization codes into >> the authorization response by attackers. The use of PKCE [RFC7636] >> is RECOMMENDED to this end. The OpenID Connect "nonce" parameter and >> ID Token Claim [OpenID] MAY be used as well. > > > Minor nit: this should be "ID Token claim" with a lowercase "c". I spent a > while trying to figure out what an "ID Token Claim" is before realizing > this sentence was referring to the "nonce" claim in an ID Token. > > Upper case "Claim" follows the convention in OIDC Core, which says for > example, "these additional requirements for the following ID Token Claims > apply". > > To keep the documents consistent, I will change the sentence above to > > "The OpenID Connect "nonce" parameter and the respective Claim in the ID > Token [OpenID] MAY be used as well." > > > Aside from that, I'm struggling to understand what this section is > actually saying to do. Since this is in the "Authorization Code Grant" > section, is this saying that using response_type=code is fine as long as > the client checks the "nonce" in the ID Token obtained after it uses the > authorization code? It seems like that would still allow an authorization > code to be injected. I don't see how the "nonce" parameter solves anything > to do with the authorization code, it seems like it only solves ID token > injections via response_type=id_token. > > The injected authorization code would always refer to a different session > (started with a different nonce). The client would therefore get an ID > Token with a different nonce. The assumption is that the client would then > throw away both the ID Token and the access token. > > Does that make sense? > > > In any case, this section could benefit from some more explicit > instructions on how exactly to prevent authorization code injection attacks. > > Indeed, we should add a sentence or two on that. > > -Daniel > --0000000000004c0f0905a29fd0dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The inje= cted authorization code would always refer to a different session (started = with a different nonce). The client would therefore get an ID Token with a = different nonce. The assumption is that the client would then throw away bo= th the ID Token and the access token.

This = is true as long as the client actually validates the ID token it obtained a= t the token endpoint, even though it may have already obtained one from the= authorization response. (e.g. response_type=3Dcode+id_token). It feels lik= e this should be explained in a little more detail, since having to validat= e two ID tokens to protect against this attack is not necessarily obvious.<= /div>

Aaron

----
Aaron Parecki
@aaronpk



On Mon, Apr 6, 2020 at 12:09 AM Daniel Fett &= lt;fett@danielfett.de> wrote:<= br>
=20 =20 =20
Hi Aaron,

Thanks for your feedback!

Am 05.04.20 um 20:42 schrieb Aaron Parecki:
=20
Section 2.1.1 says:

=C2=A0 =C2=A0Clients MUST prevent injection (replay) of authorization codes into
=C2=A0 =C2=A0the authorization response by attackers.=C2=A0 The u= se of PKCE [RFC7636]
=C2=A0 =C2=A0is RECOMMENDED to this end.=C2=A0 The OpenID Connect= "nonce" parameter and
=C2=A0 =C2=A0ID Token Claim [OpenID] MAY be used as well.

Minor nit: this should be "ID Token claim" with a lo= wercase "c". I spent a while trying to figure out what an "= ;ID Token Claim" is before realizing this sentence was referring to th= e "nonce" claim in an ID Token.

Upper case "Claim" follows the convention in OIDC Core, wh= ich says for example, "these additional requirements for the followi= ng ID Token Claims apply".

To keep the documents consistent, I will change the sentence above to

"The OpenID Connect "nonce" parameter and the respect= ive Claim in the ID Token [OpenID] MAY be used as well."


Aside from that, I'm struggling to understand what this section is actually saying to do. Since this is in the "Authorization Code Grant" section,=C2=A0is this saying= that using response_type=3Dcode is fine as long as the client checks the "nonce" in the ID Token obtained after it uses the authorization code? It seems like that would still allow an authorization code to be injected. I don't see how the "= nonce" parameter solves anything to do with the authorization code, it seems like it only solves ID token injections via response_type=3Did_token.

The injected authorization code would always refer to a different session (started with a different nonce). The client would therefore get an ID Token with a different nonce. The assumption is that the client would then throw away both the ID Token and the access token.

Does that make sense?


In any case, this section could benefit from some more explicit instructions on how exactly to prevent authorization code injection attacks.

Indeed, we should add a sentence or two on that.

-Daniel

--0000000000004c0f0905a29fd0dc-- From nobody Mon Apr 6 11:06:16 2020 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 67D8E3A0A10 for ; Mon, 6 Apr 2020 11:06:00 -0700 (PDT) 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=pingidentity.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 MUOVvOQhJrsa for ; Mon, 6 Apr 2020 11:05:58 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 90FB43A0A08 for ; Mon, 6 Apr 2020 11:05:57 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id m2so234278lfo.6 for ; Mon, 06 Apr 2020 11:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9kT/GHNpHxImwmzOs1mTDBaonTvPpB/maSdGCFGO2TQ=; b=AgJz10ovYecbiglwMCJRELltfKOlogEmfyX59B3sBdfN4ubZ9zeRWoBbdblHKl6RFr z9HQCmQk+CCqlSfTR+nfVY+K46MlekLrj/XPNo/qSHXTVyIEySOcGiUss514OCVR4Bhj rVlea2HQFRFBJkQGwzBDMfZFcQeGAjWIIVHNogvtchhh6eKlKvnB0uGSnY05vfP48x/3 +rT+mC+lXVoWg6g2eA07aC0FIforaA5GnsMR5ha5TrB0Q42P44kM1tUU1Picq4S5+zJD YkmWW3aGIKJNZcvRZRKd3sJ/xHKKLYFITx0bNDEYr/9cVv173ILVA8oW6SisRUf3hXtK 6wow== 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=9kT/GHNpHxImwmzOs1mTDBaonTvPpB/maSdGCFGO2TQ=; b=s4twsIHdr7GcNy2LQcw3O8TQNJ0eQbxeVn0g2uKB6uz9IKbIZAHQ9EgE9pV4E9/50C rJNbPFAesgrrCjMWlxcvbUklLscD7BypYyaNHkqiGNC9zovpXxNbgb6TJj5F2osLkymN 5xNC0/VcKThYT4F4UzPQtdHxCmwGEz4j/lLgGkfG99AxEiqK2vVi683D7WEt0//EgWGa onIebyUjPuJmnYpZzetx3L+bnUdSe3ZR7UC1iZEqbGOnPOHPSxWSLGZIi1eu6s2Rq/5y zTdq9MeSZ4MFJk+ynp6LI+tF7gmy6585kPWb715kaiaqA/+nGHfxSvYGiWKEqisfi+v7 M6KQ== X-Gm-Message-State: AGi0PubGYtA6K7/2KuntJfdtOIbr1BxK1PbBnf7MpI19FUi+O4HnSnys i8BUQIzX/XYfPN0LfyBCuZdPIC8bxWJ8oLVxDpIu0KS8CDXiKVBcs8qopR/JaPQQ9TLgMS6RASH DR8K4aH+lXJguqw== X-Google-Smtp-Source: APiQypKX4nEFDpPcKV09ewCWWBl4Drc/cDlG5vm72WZ7FVIFi7O2neO0dvqtTxgc0Umhf9zz+lJABFz4qVfz5rHla1w= X-Received: by 2002:a19:f719:: with SMTP id z25mr4655507lfe.63.1586196355301; Mon, 06 Apr 2020 11:05:55 -0700 (PDT) MIME-Version: 1.0 References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> In-Reply-To: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> From: Brian Campbell Date: Mon, 6 Apr 2020 12:05:28 -0600 Message-ID: To: "Peck, Michael A" Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d57a805a2a31eaf" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 06 Apr 2020 18:06:00 -0000 --0000000000004d57a805a2a31eaf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike, Thanks for your interest in the work and review of the draft. As one of the too-many authors on the document, I attempt to answer questions and respond to comments inline below. Though I admit to not having necessarily adequate answers to everything at the ready. And also apologize for the slow response, which is somewhat related to not having necessarily adequate answers. On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A wrote: > Hi, > > Glad to see DPoP moving forward as a working group item. > I have a couple of comments on the current draft: > > 1. > I recommend expanding the description of the threat model. > It's not entirely clear to me what threats DPoP is expected to address, > which makes it hard to evaluate whether DPoP meets its objectives. > Yeah, there's definitely some room for improvement in this area. And you are not the first to note the need. Complicating matters somewhat, however, is that there's some disparity of opinions about the specifics of the threat model and objectives. Despite that I do plan to work on trying to expand and clarify the threat model, objectives, expected applicability, etc. in the next revision of the draft. > Section 2 states that the main objective is to prevent an adversary who > set up a counterfeit AS or RS from replaying a received refresh token or > access token at another server. Would it be possible to expand upon the > description of this threat and how it may occur? > I'm hoping perhaps Daniel can help expand on this as the current text originated with him. Although I think separate consideration of AS and RS would be helpful because I think the factors involved in counterfeiting or confusing them are pretty different. > Are there other situations where an adversary may be able to capture a > refresh token or access token that should be mentioned as objectives to > address - e.g. malicious / third-party JavaScript code? > Probably, yeah. Although any JavaScript code that could exfiltrate tokens could also likely be used to drive an attack directly. And that possibility can devolve into questioning the value of key-binding or preventing exfiltration at all (similarish criticisms have been levied at the HttpOnly cookie flag and HTTP Token Binding). I'm sympathetic to that line of reasoning to the point of finding it somewhat depressing. But I try and avoid falling into full-blown XSS nihilism and (maybe stubbornly/naively) still think there's some value in key constraining tokens. And, to your point, a more detailed look at potential leakage/theft situations would be useful. > > Presumably the counterfeit AS or RS will not have the same hostname (e.g. > with an illegitimately issued server certificate) as the legitimate serve= r, > as otherwise DPoP wouldn=E2=80=99t provide protection. Yeah, an assumption (that admittedly should be made more explicit) is that TLS/HTTPS with server authentication isn't broken. > Why would the client send the refresh token to the wrong AS? > Daniel maybe has some more ideas here but social engineering is the one reason that I keep hearing. It's not super compelling but is a reason. > For resource servers, why wouldn=E2=80=99t an access token audience restr= iction > suffice? Is the concern that the access token might not contain an audien= ce > restriction, or might contain multiple audiences? (If the concern is that > the resource server wouldn=E2=80=99t check the audience, I=E2=80=99d have= a similar concern > that it wouldn=E2=80=99t check a DPoP proof.) > Audience restriction can work to prevent RS to RS token usage. But in practice it has turned out that properly getting and using audience restricted ATs is prohibitively cumbersome for many deployments. > > 2. > DPoP currently does not provide any guarantees that the DPoP signature wa= s > freshly generated, as there is no nonce from the server incorporated into > the signature. > I assume there is no practical means for the server to send a nonce to th= e > client to use with each request that wouldn't over-complicate DPoP. > Keeping it relatively simple has definitely been a goal. And yeah, I can't think of a practical way to do something like that without big changes. If big changes are needed, the whole approach might be in question and something like Neil's key agreement scheme that I mentioned in the last interim https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth could well be a better overall approach to consider. > I also don't see any guidance in the draft about lifetime/rotation of eac= h > DPoP key or whether the same key can be used with multiple servers. > Some guidance would probably be useful. > > My concern is that something analogous to this Kerberos PKINIT attack - > https://mailarchive.ietf.org/arch/msg/krb-wg/pLgID35fNG1Zh_QJjgXH9vEbwoQ/ > - could occur if DPoP signatures can be pre-computed by an adversary that > somehow gains the ability to compute signatures with the private key but > doesn't gain access to the private key itself. Could that potentially > happen with malicious JavaScript code? > Trying to wrap my head around this and how it might happen but yes it would seem that the kind of malicious JavaScript code (like XSS) that could exfiltrate tokens or drive an attack directly could also pre-compute and exfiltrate some DPoP proofs. I hadn't considered this and am honestly not sure how problematic it is. > > The iat timestamp is insufficient since future values could be inputted > with the signatures stored for later use. I could envision a private key > potentially being re-used for a long period of time, and depending on how > DPoP ends up getting used in practice, a private key being used with > multiple servers? > > If guaranteeing some degree of freshness of the signature is a concern, > one solution could be to incorporate the authorization code into the DPoP > signature for token requests to the AS with grant_type=3Dauthorization_co= de, > incorporate the refresh token into the DPoP signature for token requests = to > the AS with grant_type=3Drefresh_token, and incorporate the access token = into > the DPoP signature for requests to a resource server. That would prevent > pre-computing DPoP signatures before the authorization code / refresh tok= en > / access token is generated by the AS, as long as the recipient properly > checks the DPoP proof. > That's an interesting consideration and along the lines (at least with authorization code) of some of the conversations we had early on before the first -00 draft was even written. And I've noticed that other signature based proof concepts do typically propose having the signature cover the access token (or hash thereof). Personally, I've gotten kind of attached to the simplicity and consistency in the current draft of having the DPoP proof be the same regardless of where it's presented. And I kind of cringe at having to dig into the application layer to get at an authorization code or refresh token value in order to verify the DPoP proof. Also considering other grant types. So I don't want to move away from that too hastily. But I suppose it depends on how much of a concern it is to ensure some degree of freshness. And weighing that against the potential added complexity of doing something like the above to try and get freshness. I'm honestly not sure where I sit on it. > > I'd also suggest adding guidance on rotating the DPoP key - e.g. > mandate/recommend that the client create a new keypair for each token > request? > A recommendation like that (new keypair per token request and subsequent access token usage) probably makes sense. I think. In the case of a bound refresh token issued to a public client, the lifetime of the keypair would need to correlate with the refresh token (unless facilities are added to enable dpop key rotation in that scenario). > > Thanks, > Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000004d57a805a2a31eaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

Thanks for your int= erest in the work and review of the draft. As one of the too-many authors o= n the document, I attempt to answer questions and respond to comments inlin= e below. Though I admit to not having necessarily adequate answers to every= thing at the ready. And also apologize for the slow response, which is some= what related to not having necessarily adequate answers.

On Wed, Apr 1,= 2020 at 11:15 AM Peck, Michael A <mpeck@mitre.org> wrote:
Hi,

Glad to see DPoP moving forward as a working group item.
I have a couple of comments on the current draft:

1.
I recommend expanding the description of the threat model.
It's not entirely clear to me what threats DPoP is expected to address,= which makes it hard to evaluate whether DPoP meets its objectives.

Yeah, there's definitely some room for imp= rovement in this area. And you are not the first to note the need. Complica= ting matters somewhat, however, is that there's some disparity of opini= ons about the specifics of the threat model and objectives. Despite that I = do plan to work on trying to expand and clarify the threat model, objective= s, expected applicability, etc. in the next revision of the draft.
=C2=A0
Section 2 states that the main objective is to prevent an adversary who set= up a counterfeit AS or RS from replaying a received refresh token or acces= s token at another server. Would it be possible to expand upon the descript= ion of this threat and how it may occur?

I'm hoping perhaps Daniel can help expand on this as the current text= originated with him. Although I think separate consideration of AS and RS = would be helpful because I think the factors involved in counterfeiting or = confusing them are pretty different.
=C2=A0
Are there other situations where an adversary may be able to capture a refr= esh token or access token that should be mentioned as objectives to address= - e.g. malicious / third-party JavaScript code?

<= /div>
Probably, yeah. Although any JavaScript code that could exfiltrat= e tokens could also likely be used to drive an attack directly. And that po= ssibility can devolve into questioning the value of key-binding or preventi= ng exfiltration at all (similarish criticisms have been levied at the HttpO= nly cookie flag and HTTP Token Binding). I'm sympathetic to that line o= f reasoning to the point of finding it somewhat depressing. But I try and a= void falling into full-blown XSS nihilism and (maybe stubbornly/naively) st= ill think there's some value in key constraining tokens. And, to your p= oint, a more detailed look at potential leakage/theft situations would be u= seful.

=C2=A0

Presumably the counterfeit AS or RS will not have the same hostname (e.g. w= ith an illegitimately issued server certificate) as the legitimate server, = as otherwise DPoP wouldn=E2=80=99t provide protection.
Yeah, an assumption (that admittedly should be made more explic= it) is that TLS/HTTPS with server authentication isn't broken.=C2=A0

=C2=A0
Why would the client send the refresh token to the wrong AS= ?

=C2=A0Daniel maybe has some more idea= s here but social engineering is the one reason that I keep hearing. It'= ;s not super compelling but is a reason.

=C2=A0
For resource servers, why wouldn=E2=80=99t an access token audience restric= tion suffice? Is the concern that the access token might not contain an aud= ience restriction, or might contain multiple audiences? (If the concern is = that the resource server wouldn=E2=80=99t check the audience, I=E2=80=99d h= ave a similar concern that it wouldn=E2=80=99t check a DPoP proof.)

Audience restriction can work to prevent RS to= RS token usage. But in practice it has turned out that properly getting an= d using audience restricted ATs is prohibitively cumbersome for many deploy= ments.
=C2=A0

2.
DPoP currently does not provide any guarantees that the DPoP signature was = freshly generated, as there is no nonce from the server incorporated into t= he signature.
I assume there is no practical means for the server to send a nonce to the = client to use with each request that wouldn't over-complicate DPoP.
=

Keeping it relatively simple has definitel= y been a goal. And yeah, I can't think of a practical way to do somethi= ng like that without big changes. If big changes are needed, the whole appr= oach might be in question and something like Neil's key agreement schem= e that I mentioned in the last interim https://= datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth could = well be a better overall approach to consider.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> I also don't see any guidance in the draft about lifetime/rotation of e= ach DPoP key or whether the same key can be used with multiple servers.
=

Some guidance would probably be useful.
=C2=A0

My concern is that something analogous to this Kerberos PKINIT attack - https://mailarchive.ietf.org/a= rch/msg/krb-wg/pLgID35fNG1Zh_QJjgXH9vEbwoQ/ - could occur if DPoP signa= tures can be pre-computed by an adversary that somehow gains the ability to= compute signatures with the private key but doesn't gain access to the= private key itself. Could that potentially happen with malicious JavaScrip= t code?

Trying to wrap my head around t= his and how it might happen but yes it would seem that the kind of maliciou= s JavaScript code (like XSS) that could exfiltrate tokens or drive an attac= k directly could also pre-compute and exfiltrate some DPoP proofs. I hadn&#= 39;t considered this and am honestly not sure how problematic it is.
=C2=A0

The iat timestamp is insufficient since future values could be inputted wit= h the signatures stored for later use. I could envision a private key poten= tially being re-used for a long period of time, and depending on how DPoP e= nds up getting used in practice, a private key being used with multiple ser= vers?

If guaranteeing some degree of freshness of the signature is a concern, one= solution could be to incorporate the authorization code into the DPoP sign= ature for token requests to the AS with grant_type=3Dauthorization_code, in= corporate the refresh token into the DPoP signature for token requests to t= he AS with grant_type=3Drefresh_token, and incorporate the access token int= o the DPoP signature for requests to a resource server. That would prevent = pre-computing DPoP signatures before the authorization code / refresh token= / access token is generated by the AS, as long as the recipient properly c= hecks the DPoP proof.

That's an int= eresting consideration and along the lines (at least with authorization cod= e) of some of the conversations we had early on before the first -00 draft= was even written. And I've noticed that other signature based proof co= ncepts do typically propose having the signature cover the access token (or= hash thereof). Personally, I've gotten kind of attached to the simplic= ity and consistency in the current draft of having the DPoP proof be the sa= me regardless of where it's presented. And I kind of cringe at having t= o dig into the application layer to get at an authorization code or refresh= token value in order to verify the DPoP proof. Also considering other gran= t types. So I don't want to move away from that too hastily.
=

But I suppose it depends on how much of a concern it is= to ensure some degree of freshness. And weighing that against the potentia= l added complexity of doing something like the above to try and get freshne= ss. I'm honestly not sure where I sit on it.=C2=A0
=C2= =A0

I'd also suggest adding guidance on rotating the DPoP key - e.g. mandat= e/recommend that the client create a new keypair for each token request?

A recommendation like that (new keypair p= er token request and subsequent access token usage) probably makes sense. I= think. In the case of a bound refresh token issued to a public client, the= lifetime of the keypair would need to correlate with the refresh token (un= less facilities are added to enable dpop key rotation in that scenario).
=C2=A0

Thanks,
Mike


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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000004d57a805a2a31eaf-- From nobody Mon Apr 6 13:06:58 2020 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 59F533A0E7D for ; Mon, 6 Apr 2020 13:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 q-OHmVUs1NI3 for ; Mon, 6 Apr 2020 13:06:55 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC5B3A0E79 for ; Mon, 6 Apr 2020 13:06:54 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 5FD9C3401; Mon, 6 Apr 2020 20:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586203613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lwBmDkuktw+SUTEmQ3pCLTcVsJEXkBIo+Tfu5rOtsFg=; b=d/SQSrsB6d0MPjd/+3PVvpeotysaqTLk+hVTpcDV52hvN4a5MovhIk/lJ0ijV4S7oJV+zl LA7tqBLhVkbcVkMCCyJqt75crkGixI4ZTzAbrTwwOK189hb7JecQImbJjZ/+DsGVoO6pWZ WS/fHvDAXGrcTI9Zyb0/TeRnJ+9YI6Y= To: Aaron Parecki Cc: OAuth WG , Torsten Lodderstedt References: <91012825-2bef-297a-1d9a-89c8c9e1f7f3@danielfett.de> From: Daniel Fett Message-ID: <24c2249b-24ce-0335-cde2-e75c9d0d2172@danielfett.de> Date: Mon, 6 Apr 2020 22:06:52 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F9989EBF0FB6A44B7CB895BB" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586203613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lwBmDkuktw+SUTEmQ3pCLTcVsJEXkBIo+Tfu5rOtsFg=; b=I4jpN8S6bBNdM3u8B/0Q8DC4cfiTjAL/rsvy5AJOLteF45ibGkcAundr9xzBLX863LZdVq DPQIKNkkmNa/cnFVAfojeFfNX3+cPIOEt7rNuBBdrVQex4ewGs2tBRPDwD6ibWj02ivWix nQ2jMkBXOviU8WvqRREhXXbnP16dthk= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1586203613; a=rsa-sha256; cv=none; b=u3RjAeKLU27PtY+MN4LRa9iEDMY8sMlwTDgxmD7+Lca/AIoHJh1aZPNkqphZVr2QXwbDxi yEmpGVtKKehrw3/tf+57uxV4GTFeYx9Kugd3tCHFuV02oXBsOvnPv58Oz8J9vKDNlqMfyA qB3CH3Tof9ciuMTWLFefmOhfjkITPls= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] OAuth Security BCP -15 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, 06 Apr 2020 20:06:56 -0000 This is a multi-part message in MIME format. --------------F9989EBF0FB6A44B7CB895BB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 06.04.20 um 16:09 schrieb Aaron Parecki: > > The injected authorization code would always refer to a different > session (started with a different nonce). The client would > therefore get an ID Token with a different nonce. The assumption > is that the client would then throw away both the ID Token and the > access token. > > > This is true as long as the client actually validates the ID token it > obtained at the token endpoint, even though it may have already > obtained one from the authorization response. (e.g. > response_type=code+id_token). It feels like this should be explained > in a little more detail, since having to validate two ID tokens to > protect against this attack is not necessarily obvious. Thanks, that is an important point. I will propose some text on that. -Daniel --------------F9989EBF0FB6A44B7CB895BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 06.04.20 um 16:09 schrieb Aaron Parecki:
The injected authorization code would always refer to a different session (started with a different nonce). The client would therefore get an ID Token with a different nonce. The assumption is that the client would then throw away both the ID Token and the access token.

This is true as long as the client actually validates the ID token it obtained at the token endpoint, even though it may have already obtained one from the authorization response. (e.g. response_type=code+id_token). It feels like this should be explained in a little more detail, since having to validate two ID tokens to protect against this attack is not necessarily obvious.

Thanks, that is an important point. I will propose some text on that.

-Daniel

--------------F9989EBF0FB6A44B7CB895BB-- From nobody Mon Apr 6 13:08:25 2020 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 850823A0E96 for ; Mon, 6 Apr 2020 13:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 YbxMc8o5m7XZ for ; Mon, 6 Apr 2020 13:08:22 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B98F3A0E95 for ; Mon, 6 Apr 2020 13:08:22 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 09381317F; Mon, 6 Apr 2020 20:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586203701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vE0rsMeeRBM2SuIJrN98zrtejg+TMU/zbSF/nzikT6w=; b=UyLReB1Alr0Ll26BeSeyYwFFvN2XEWs/nZ8yDOzkQ0Vmvj9ajoyBAVcCZoskMg3WZ67Mtb Bgb3g/CWuaIOuDAU4ZY2r0GFEkQup+8S3z5I0tFMwGylFf5W83ot/3+rStlakfvnIHHx4l dzfxSlC6uXDF/WRBvIOuEnrpXPV8j1w= To: Aaron Parecki Cc: OAuth WG , Torsten Lodderstedt References: From: Daniel Fett Message-ID: <527a1c60-132a-5441-5c98-95693b91be80@danielfett.de> Date: Mon, 6 Apr 2020 22:08:20 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6CDD534818242FB62545CC2B" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586203701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vE0rsMeeRBM2SuIJrN98zrtejg+TMU/zbSF/nzikT6w=; b=KL+B4JtdRVRUh0ngS8Nhi0ARCGnumwEQJy/UH6kE/7JN/fjbtA0qjNJigbDYDEGbnpppEO UxlXlmCR0gKpj2J4YEzEw+y3bC+mlQYuXsasTq6ZsDo1jeafAH2yNOSFvZYaKrmRnOcZXc bzJyAqwgRltRMLLi/QWeo1sf0V2XHRA= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1586203701; a=rsa-sha256; cv=none; b=cNbO7F8Tj5M0GlmcNLclEhz6WCEOgYrb9cc6u2KzHUKz0nynACvJ9DFJ+C1r/zB6VF1QEu KZvizgkRO1warZDUKpHZ/29u7nTJPCMMEIqPzCKpOTPxNCZODdpPcru4uwved6WwR1DUcA Id4kK/HChq4Adiu/sS3G4Guzv/0w+gs= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens in Security BCP -15 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, 06 Apr 2020 20:08:24 -0000 This is a multi-part message in MIME format. --------------6CDD534818242FB62545CC2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 06.04.20 um 15:59 schrieb Aaron Parecki: > Keeping the details in section 4 makes sense. I think why I was > confused is that there isn't a subheader in section 2 for refresh > tokens so it's not immediately obvious until you get to section 4. > What about adding a new subhead in section 2 with just that short > summary and referring to section 4 for details? Sounds good to me. I will do that for the next version. -Daniel --------------6CDD534818242FB62545CC2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 06.04.20 um 15:59 schrieb Aaron Parecki:
Keeping the details in section 4 makes sense. I think why I was confused is that there isn't a subheader in section 2 for refresh tokens so it's not immediately obvious until you get to section 4. What about adding a new subhead in section 2 with just that short summary and referring to section 4 for details?

Sounds good to me. I will do that for the next version.

-Daniel

--------------6CDD534818242FB62545CC2B-- From nobody Mon Apr 6 14:35:51 2020 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 62BBA3A0C5F for ; Mon, 6 Apr 2020 14:35:50 -0700 (PDT) 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 tOlOcVQPK96D for ; Mon, 6 Apr 2020 14:35:48 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 1902B3A0CEB for ; Mon, 6 Apr 2020 14:35:45 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id g2so385826plo.3 for ; Mon, 06 Apr 2020 14:35:45 -0700 (PDT) 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=q2UXj+5n3x+K/hNWYZ6hCTM2Cvjb+gV1lwWQmXl9jO0=; b=jJe1epndhOxavBQwkkYgnrTjh7KPr3O6dfA5mROJh8zZrJm7GALfQR8kVjIsjXFy5O OcB7a/Yo99y0e3g+fh+lPmSaBg2Mh3j3Ee2AcsJ21S4F85F1jnZCw4BTqYbnuMsD+3Qm sA9p8t9RnN8NgmQcrvENiV26dSF8cTC4NlAFIR8dszC5SMx6btodvuljGg4uZiCSXmsD 3k/nYF907J1abXMYZpClVlOIitBhOGDMPWW37ezFArky1ANtZYU8kzN3p1TDyCYFhLY9 ki22gOmjXFwlyjrYATmea+3G7+MTFTdog/EpEs5yrrd3MG6fR6cNN58SuNZFSBxbV2HR hweQ== 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=q2UXj+5n3x+K/hNWYZ6hCTM2Cvjb+gV1lwWQmXl9jO0=; b=GfTbOD+EchHxOp664rnIu+9EbgBdSEpTAVV9yqaszb4bHNObr5mBjzE7YNPpJxiu2f V2vpT7vcOsjhTHjVDes2yexUA5YMF7w200dXXEB2CywwlWOh2Qz3yBXPFLzgAfQ8M+TG PEYOs1b+MzOZKfifI0y8LX5FQtfB+YvMK9i5Ejee2OYBLWZxxaBk3MkjOjAROxaANcRf IANilCX2UysoaxLyqEjqO16Quo4yCUPJQFKkgwyy9I51hJFXd+sTtPpo36I3UmcGZg+R PtwLbv7ZjqdIZKoFo7yfPzZIzMhGh0p50tBSrix0xgDeMa1YzaGHb8AmhyGzl3Jqrtri Ievg== X-Gm-Message-State: AGi0Puafz2M7R5V8V1v+mDoNRwsrvyEV1Ke7mm8x5sqTQ3fCC3s9pp0f dUvP6zcj9uiWNHjtyhG56HMz9C0Qz2Z23HmGyR3DddApmgg8UXZvHz5VAm5EqdVPmc91J93FfGW xyEYlivMMCEhlFJ0C1Vh70m6v5MJBl4xrGkq69prqq/5Kv3/DpHqd2jtpw0vgMGxl7Q== X-Google-Smtp-Source: APiQypLlVTysT6Ci67f6ojv3wjIlr9SfWDj2fcuots841aGizFx7v3iZHIb5xwdoHK4AvIvgOesJWw== X-Received: by 2002:a17:90a:1101:: with SMTP id d1mr1368950pja.113.1586208943799; Mon, 06 Apr 2020 14:35:43 -0700 (PDT) Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id i2sm12375627pfr.203.2020.04.06.14.35.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2020 14:35:43 -0700 (PDT) From: Vittorio Bertocci To: "oauth@ietf.org" , "aaron@parecki.com" Thread-Topic: oauth-browser-based-apps-05 - BFF Thread-Index: AQHWDFtSACwH0zlpuEuhJugkyhq6cA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 6 Apr 2020 21:35:42 +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_MWHPR19MB1501CE53F9A1EB1ABD7E95A6AEC20MWHPR19MB1501namp_" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] oauth-browser-based-apps-05 - BFF 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, 06 Apr 2020 21:35:50 -0000 --_000_MWHPR19MB1501CE53F9A1EB1ABD7E95A6AEC20MWHPR19MB1501namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey Aaron, Thanks for today=92s update on oauth-browser-based-apps, very useful. As agreed, here=92s the summary of the point mentioned during today=92s cal= l. 1. The last paragraph of 6.2 mentions that an access token could be used= as session between the JS frontend and its backend, but no details are giv= en about the security characteristics of making that choice vs using cookie= s. I would suggest that we either give more guidance on the mechanics of ho= w that would happen (how does the AT get delivered to the JS frontend, what= attacks developers should watch out for, etc) or that we recommend the tra= ditional cookie based session approach only. 2. Currently 6.2 doesn=92t mention topologies where the backend obtains = ATs and forwards them to the JS frontend, where they are used to perform th= e actual API calls. Those topologies do exist in the wild, and I know there= are practitioner advocates for that approach on this list too, hence it se= ems we should at least acknowledge those topologies and give some guidance. If we do position those topologies as legitimate: given that the chatter be= tween JS frontend and backend could in some cases reach sophistication comp= arable to the client-AS dialog (token requests, renewals, etc), it seems we= should either warn people about the security pitfalls they have to watch o= ut for (shorter task for us, but not very actionable) or actually invest so= me time in specifying how a JS frontend should talk to its backend to deleg= ate its client duties to it and safely retrieve/renew the artifacts the bac= kend obtains on the JS frontend=92s behalf (much bigger task for us, but un= ambiguous guidance and solid threat model developers can safely rely on). Thanks! V. --_000_MWHPR19MB1501CE53F9A1EB1ABD7E95A6AEC20MWHPR19MB1501namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hey Aaron,

Thanks for today=92= s update on oauth-browser-based-apps, very useful.

As agreed, here=92s= the summary of the point mentioned during today=92s call.

 

  1. The last paragraph of 6.2 mentions t= hat an access token could be used as session between the JS frontend and it= s backend, but no details are given about the security characteristics of making that choice vs using cookies. I wou= ld suggest that we either give more guidance on the mechanics of how that w= ould happen (how does the AT get delivered to the JS frontend, what attacks= developers should watch out for, etc) or that we recommend the traditional cookie based session approach on= ly.
  2. Currently = 6.2 doesn=92t mention topologies where the backend obtains ATs and forwards= them to the JS frontend, where they are used to perform the actual API calls. Those topologies do exist in the wild, and I know there are pra= ctitioner advocates for that approach on this list too, hence it seems we s= hould at least acknowledge those topologies and give some guidance.
    If we do position those topologies as legitimate: given that the chatter be= tween JS frontend and backend could in some cases reach sophistication comp= arable to the client-AS dialog (token requests, renewals, etc), it seems we= should either warn people about the security pitfalls they have to watch out for (shorter task for us, but= not very actionable) or actually invest some time in specifying how a JS f= rontend should talk to its backend to delegate its client duties to it and = safely retrieve/renew the artifacts the backend obtains on the JS frontend=92s behalf (much bigger task for us= , but unambiguous guidance and solid threat model developers can safely rel= y on).

 

Thanks!<= /span>

V.   

--_000_MWHPR19MB1501CE53F9A1EB1ABD7E95A6AEC20MWHPR19MB1501namp_-- From nobody Mon Apr 6 14:37:11 2020 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 93B013A0C63 for ; Mon, 6 Apr 2020 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SUOwAbJbJTp for ; Mon, 6 Apr 2020 14:37:07 -0700 (PDT) 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 6E1AA3A0C60 for ; Mon, 6 Apr 2020 14:37:07 -0700 (PDT) Received: from [192.168.1.13] (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 036Lb3DA023790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 17:37:04 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_61494626-6209-4D28-B3C5-0EE9BDB25418" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 6 Apr 2020 17:37:03 -0400 In-Reply-To: Cc: "Peck, Michael A" , "oauth@ietf.org" To: Brian Campbell References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 06 Apr 2020 21:37:10 -0000 --Apple-Mail=_61494626-6209-4D28-B3C5-0EE9BDB25418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I want to add my perspective to the question of audience restriction, = below: One of the problems with implementing audience restriction of RS=E2=80=99s= in the wild has actually turned into a problem of audience = identification instead. In other words, the client needs to know some = identifier that the RS will recognize as itself, and the RS needs to be = configured with that identifier in some way. DPoP does a nice side-step = of that entire issue by signing some very limited aspects of the request = itself. This type of check is much easier for an RS (or a filter sitting = in front of it) to check for consistency, without a lot of = pre-configuration. The http-signing based PoP draft took the same = approach, albeit with more expanded coverage, and the HTTP Signatures = draft from the HTTP WG will do the same.=20 I=E2=80=99ll also note that this does not get in the way of DPoP being = used with an access token that also has additional audience restrictions = on it. And RS can both check the DPoP signature matches the incoming = request as well as checking some audience notation on the token itself, = just like we=E2=80=99d expect an RS to check the scope values bound to = the access token as well as the presentation mechanism.=20 They=E2=80=99re two parts of the puzzle, and they shouldn=E2=80=99t be = conflated at the presentation layer (DPoP) since they can be mixed in = orthogonal ways for different use cases and solutions. =E2=80=94 Justin > On Apr 6, 2020, at 2:05 PM, Brian Campbell = wrote: >=20 > Hi Mike, >=20 > Thanks for your interest in the work and review of the draft. As one = of the too-many authors on the document, I attempt to answer questions = and respond to comments inline below. Though I admit to not having = necessarily adequate answers to everything at the ready. And also = apologize for the slow response, which is somewhat related to not having = necessarily adequate answers.=20 >=20 > On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A > wrote: > Hi, >=20 > Glad to see DPoP moving forward as a working group item. > I have a couple of comments on the current draft: >=20 > 1. > I recommend expanding the description of the threat model. > It's not entirely clear to me what threats DPoP is expected to = address, which makes it hard to evaluate whether DPoP meets its = objectives. >=20 > Yeah, there's definitely some room for improvement in this area. And = you are not the first to note the need. Complicating matters somewhat, = however, is that there's some disparity of opinions about the specifics = of the threat model and objectives. Despite that I do plan to work on = trying to expand and clarify the threat model, objectives, expected = applicability, etc. in the next revision of the draft.=20 > =20 > Section 2 states that the main objective is to prevent an adversary = who set up a counterfeit AS or RS from replaying a received refresh = token or access token at another server. Would it be possible to expand = upon the description of this threat and how it may occur? >=20 > I'm hoping perhaps Daniel can help expand on this as the current text = originated with him. Although I think separate consideration of AS and = RS would be helpful because I think the factors involved in = counterfeiting or confusing them are pretty different. > =20 > Are there other situations where an adversary may be able to capture a = refresh token or access token that should be mentioned as objectives to = address - e.g. malicious / third-party JavaScript code? >=20 > Probably, yeah. Although any JavaScript code that could exfiltrate = tokens could also likely be used to drive an attack directly. And that = possibility can devolve into questioning the value of key-binding or = preventing exfiltration at all (similarish criticisms have been levied = at the HttpOnly cookie flag and HTTP Token Binding). I'm sympathetic to = that line of reasoning to the point of finding it somewhat depressing. = But I try and avoid falling into full-blown XSS nihilism and (maybe = stubbornly/naively) still think there's some value in key constraining = tokens. And, to your point, a more detailed look at potential = leakage/theft situations would be useful. >=20 > =20 >=20 > Presumably the counterfeit AS or RS will not have the same hostname = (e.g. with an illegitimately issued server certificate) as the = legitimate server, as otherwise DPoP wouldn=E2=80=99t provide = protection. >=20 > Yeah, an assumption (that admittedly should be made more explicit) is = that TLS/HTTPS with server authentication isn't broken. =20 >=20 > =20 > Why would the client send the refresh token to the wrong AS? >=20 > Daniel maybe has some more ideas here but social engineering is the = one reason that I keep hearing. It's not super compelling but is a = reason. >=20 > =20 > For resource servers, why wouldn=E2=80=99t an access token audience = restriction suffice? Is the concern that the access token might not = contain an audience restriction, or might contain multiple audiences? = (If the concern is that the resource server wouldn=E2=80=99t check the = audience, I=E2=80=99d have a similar concern that it wouldn=E2=80=99t = check a DPoP proof.) >=20 > Audience restriction can work to prevent RS to RS token usage. But in = practice it has turned out that properly getting and using audience = restricted ATs is prohibitively cumbersome for many deployments.=20 > =20 >=20 > 2. > DPoP currently does not provide any guarantees that the DPoP signature = was freshly generated, as there is no nonce from the server incorporated = into the signature. > I assume there is no practical means for the server to send a nonce to = the client to use with each request that wouldn't over-complicate DPoP. >=20 > Keeping it relatively simple has definitely been a goal. And yeah, I = can't think of a practical way to do something like that without big = changes. If big changes are needed, the whole approach might be in = question and something like Neil's key agreement scheme that I mentioned = in the last interim = https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth = = could well be a better overall approach to consider.=20 > =20 > I also don't see any guidance in the draft about lifetime/rotation of = each DPoP key or whether the same key can be used with multiple servers. >=20 > Some guidance would probably be useful.=20 > =20 >=20 > My concern is that something analogous to this Kerberos PKINIT attack = - = https://mailarchive.ietf.org/arch/msg/krb-wg/pLgID35fNG1Zh_QJjgXH9vEbwoQ/ = - could occur if DPoP signatures can be pre-computed by an adversary = that somehow gains the ability to compute signatures with the private = key but doesn't gain access to the private key itself. Could that = potentially happen with malicious JavaScript code? >=20 > Trying to wrap my head around this and how it might happen but yes it = would seem that the kind of malicious JavaScript code (like XSS) that = could exfiltrate tokens or drive an attack directly could also = pre-compute and exfiltrate some DPoP proofs. I hadn't considered this = and am honestly not sure how problematic it is. > =20 >=20 > The iat timestamp is insufficient since future values could be = inputted with the signatures stored for later use. I could envision a = private key potentially being re-used for a long period of time, and = depending on how DPoP ends up getting used in practice, a private key = being used with multiple servers? >=20 > If guaranteeing some degree of freshness of the signature is a = concern, one solution could be to incorporate the authorization code = into the DPoP signature for token requests to the AS with = grant_type=3Dauthorization_code, incorporate the refresh token into the = DPoP signature for token requests to the AS with = grant_type=3Drefresh_token, and incorporate the access token into the = DPoP signature for requests to a resource server. That would prevent = pre-computing DPoP signatures before the authorization code / refresh = token / access token is generated by the AS, as long as the recipient = properly checks the DPoP proof. >=20 > That's an interesting consideration and along the lines (at least with = authorization code) of some of the conversations we had early on before = the first -00 draft was even written. And I've noticed that other = signature based proof concepts do typically propose having the signature = cover the access token (or hash thereof). Personally, I've gotten kind = of attached to the simplicity and consistency in the current draft of = having the DPoP proof be the same regardless of where it's presented. = And I kind of cringe at having to dig into the application layer to get = at an authorization code or refresh token value in order to verify the = DPoP proof. Also considering other grant types. So I don't want to move = away from that too hastily.=20 >=20 > But I suppose it depends on how much of a concern it is to ensure some = degree of freshness. And weighing that against the potential added = complexity of doing something like the above to try and get freshness. = I'm honestly not sure where I sit on it. =20 > =20 >=20 > I'd also suggest adding guidance on rotating the DPoP key - e.g. = mandate/recommend that the client create a new keypair for each token = request? >=20 > A recommendation like that (new keypair per token request and = subsequent access token usage) probably makes sense. I think. In the = case of a bound refresh token issued to a public client, the lifetime of = the keypair would need to correlate with the refresh token (unless = facilities are added to enable dpop key rotation in that scenario).=20 > =20 >=20 > Thanks, > Mike >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_61494626-6209-4D28-B3C5-0EE9BDB25418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = want to add my perspective to the question of audience restriction, = below:

One of the = problems with implementing audience restriction of RS=E2=80=99s in the = wild has actually turned into a problem of audience identification instead. In other words, the client needs to know some = identifier that the RS will recognize as itself, and the RS needs to be = configured with that identifier in some way. DPoP does a nice side-step = of that entire issue by signing some very limited aspects of the request = itself. This type of check is much easier for an RS (or a filter sitting = in front of it) to check for consistency, without a lot of = pre-configuration. The http-signing based PoP draft took the same = approach, albeit with more expanded coverage, and the HTTP Signatures = draft from the HTTP WG will do the same. 

I=E2=80=99ll also note = that this does not get in the way of DPoP being used with an access = token that also has additional audience restrictions on it. And RS can = both check the DPoP signature matches the incoming request as well as = checking some audience notation on the token itself, just like we=E2=80=99= d expect an RS to check the scope values bound to the access token as = well as the presentation mechanism. 

They=E2=80=99re two parts of the = puzzle, and they shouldn=E2=80=99t be conflated at the presentation = layer (DPoP) since they can be mixed in orthogonal ways for different = use cases and solutions.

 =E2=80=94 Justin

On Apr = 6, 2020, at 2:05 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

Hi = Mike,

Thanks = for your interest in the work and review of the draft. As one of the = too-many authors on the document, I attempt to answer questions and = respond to comments inline below. Though I admit to not having = necessarily adequate answers to everything at the ready. And also = apologize for the slow response, which is somewhat related to not having = necessarily adequate answers.

On Wed, Apr = 1, 2020 at 11:15 AM Peck, Michael A <mpeck@mitre.org> wrote:
Hi,

Glad to see DPoP moving forward as a working group item.
I have a couple of comments on the current draft:

1.
I recommend expanding the description of the threat model.
It's not entirely clear to me what threats DPoP is expected to address, = which makes it hard to evaluate whether DPoP meets its objectives.

Yeah, there's definitely some room for improvement in this = area. And you are not the first to note the need. Complicating matters = somewhat, however, is that there's some disparity of opinions about the = specifics of the threat model and objectives. Despite that I do plan to = work on trying to expand and clarify the threat model, objectives, = expected applicability, etc. in the next revision of the draft.
 
Section 2 states that the main objective is to prevent an adversary who = set up a counterfeit AS or RS from replaying a received refresh token or = access token at another server. Would it be possible to expand upon the = description of this threat and how it may occur?

I'm hoping perhaps Daniel can help expand on this as the = current text originated with him. Although I think separate = consideration of AS and RS would be helpful because I think the factors = involved in counterfeiting or confusing them are pretty different.
 
Are there other situations where an adversary may be able to capture a = refresh token or access token that should be mentioned as objectives to = address - e.g. malicious / third-party JavaScript code?

Probably, yeah. Although any JavaScript code that could = exfiltrate tokens could also likely be used to drive an attack directly. = And that possibility can devolve into questioning the value of = key-binding or preventing exfiltration at all (similarish criticisms = have been levied at the HttpOnly cookie flag and HTTP Token Binding). = I'm sympathetic to that line of reasoning to the point of finding it = somewhat depressing. But I try and avoid falling into full-blown XSS = nihilism and (maybe stubbornly/naively) still think there's some value = in key constraining tokens. And, to your point, a more detailed look at = potential leakage/theft situations would be useful.

 

Presumably the counterfeit AS or RS will not have the same hostname = (e.g. with an illegitimately issued server certificate) as the = legitimate server, as otherwise DPoP wouldn=E2=80=99t provide = protection.

Yeah, an assumption (that admittedly should be made more = explicit) is that TLS/HTTPS with server authentication isn't = broken. 

 
Why would the client send the = refresh token to the wrong AS?

 Daniel maybe has = some more ideas here but social engineering is the one reason that I = keep hearing. It's not super compelling but is a reason.

 
For resource servers, why wouldn=E2=80=99t an access token audience = restriction suffice? Is the concern that the access token might not = contain an audience restriction, or might contain multiple audiences? = (If the concern is that the resource server wouldn=E2=80=99t check the = audience, I=E2=80=99d have a similar concern that it wouldn=E2=80=99t = check a DPoP proof.)

Audience restriction can work to = prevent RS to RS token usage. But in practice it has turned out that = properly getting and using audience restricted ATs is prohibitively = cumbersome for many deployments.
 

2.
DPoP currently does not provide any guarantees that the DPoP signature = was freshly generated, as there is no nonce from the server incorporated = into the signature.
I assume there is no practical means for the server to send a nonce to = the client to use with each request that wouldn't over-complicate = DPoP.

Keeping it relatively simple has definitely been a goal. And = yeah, I can't think of a practical way to do something like that without = big changes. If big changes are needed, the whole approach might be in = question and something like Neil's key agreement scheme that I mentioned = in the last interim https://datatracker.ietf.org/meeting/interim-2020-oauth-02/sess= ion/oauth could well be a better overall approach to consider.
 
I also don't see any guidance in the draft about lifetime/rotation of = each DPoP key or whether the same key can be used with multiple = servers.

Some guidance would probably be useful. =
 

My concern is that something analogous to this Kerberos PKINIT attack - = https://mailarchive.ietf.org/arch/msg/krb-wg/pLgID35fNG1Zh_QJjg= XH9vEbwoQ/ - could occur if DPoP signatures can be pre-computed by = an adversary that somehow gains the ability to compute signatures with = the private key but doesn't gain access to the private key itself. Could = that potentially happen with malicious JavaScript code?

Trying to wrap my head around this and how it might happen = but yes it would seem that the kind of malicious JavaScript code (like = XSS) that could exfiltrate tokens or drive an attack directly could also = pre-compute and exfiltrate some DPoP proofs. I hadn't considered this = and am honestly not sure how problematic it is.
 

The iat timestamp is insufficient since future values could be inputted = with the signatures stored for later use. I could envision a private key = potentially being re-used for a long period of time, and depending on = how DPoP ends up getting used in practice, a private key being used with = multiple servers?

If guaranteeing some degree of freshness of the signature is a concern, = one solution could be to incorporate the authorization code into the = DPoP signature for token requests to the AS with = grant_type=3Dauthorization_code, incorporate the refresh token into the = DPoP signature for token requests to the AS with = grant_type=3Drefresh_token, and incorporate the access token into the = DPoP signature for requests to a resource server. That would prevent = pre-computing DPoP signatures before the authorization code / refresh = token / access token is generated by the AS, as long as the recipient = properly checks the DPoP proof.

That's an interesting = consideration and along the lines (at least with authorization code) of = some of the conversations we had early on before the first -00 draft = was even written. And I've noticed that other signature based proof = concepts do typically propose having the signature cover the access = token (or hash thereof). Personally, I've gotten kind of attached to the = simplicity and consistency in the current draft of having the DPoP proof = be the same regardless of where it's presented. And I kind of cringe at = having to dig into the application layer to get at an authorization code = or refresh token value in order to verify the DPoP proof. Also = considering other grant types. So I don't want to move away from that = too hastily.

But I suppose it depends on how much of = a concern it is to ensure some degree of freshness. And weighing that = against the potential added complexity of doing something like the above = to try and get freshness. I'm honestly not sure where I sit on it.  =
 

I'd also suggest adding guidance on rotating the DPoP key - e.g. = mandate/recommend that the client create a new keypair for each token = request?

A recommendation like that (new keypair = per token request and subsequent access token usage) probably makes = sense. I think. In the case of a bound refresh token issued to a public = client, the lifetime of the keypair would need to correlate with the = refresh token (unless facilities are added to enable dpop key rotation = in that scenario).
 

Thanks,
Mike


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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited..  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_61494626-6209-4D28-B3C5-0EE9BDB25418-- From nobody Mon Apr 6 20:54:31 2020 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 2829E3A14C4 for ; Mon, 6 Apr 2020 20:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtnvZ0kaWA-I for ; Mon, 6 Apr 2020 20:54:28 -0700 (PDT) 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 9FF713A14C2 for ; Mon, 6 Apr 2020 20:54:28 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0373sMVY029323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Apr 2020 23:54:24 -0400 Date: Mon, 6 Apr 2020 20:54:22 -0700 From: Benjamin Kaduk To: Brian Campbell Cc: "Peck, Michael A" , "oauth@ietf.org" Message-ID: <20200407035422.GG88064@kduck.mit.edu> References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 07 Apr 2020 03:54:30 -0000 On Mon, Apr 06, 2020 at 12:05:28PM -0600, Brian Campbell wrote: > Hi Mike, > > Thanks for your interest in the work and review of the draft. As one of the > too-many authors on the document, I attempt to answer questions and respond > to comments inline below. Though I admit to not having necessarily adequate > answers to everything at the ready. And also apologize for the slow > response, which is somewhat related to not having necessarily adequate > answers. > > On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A wrote: > > > Hi, > > > > Glad to see DPoP moving forward as a working group item. > > I have a couple of comments on the current draft: > > > > 1. > > I recommend expanding the description of the threat model. > > It's not entirely clear to me what threats DPoP is expected to address, > > which makes it hard to evaluate whether DPoP meets its objectives. > > > > Yeah, there's definitely some room for improvement in this area. And you > are not the first to note the need. Complicating matters somewhat, however, > is that there's some disparity of opinions about the specifics of the > threat model and objectives. Despite that I do plan to work on trying to > expand and clarify the threat model, objectives, expected applicability, > etc. in the next revision of the draft. > > > > Section 2 states that the main objective is to prevent an adversary who > > set up a counterfeit AS or RS from replaying a received refresh token or > > access token at another server. Would it be possible to expand upon the > > description of this threat and how it may occur? > > > > I'm hoping perhaps Daniel can help expand on this as the current text > originated with him. Although I think separate consideration of AS and RS > would be helpful because I think the factors involved in counterfeiting or > confusing them are pretty different. > > > > Are there other situations where an adversary may be able to capture a > > refresh token or access token that should be mentioned as objectives to > > address - e.g. malicious / third-party JavaScript code? > > > > Probably, yeah. Although any JavaScript code that could exfiltrate tokens > could also likely be used to drive an attack directly. And that possibility > can devolve into questioning the value of key-binding or preventing > exfiltration at all (similarish criticisms have been levied at the HttpOnly > cookie flag and HTTP Token Binding). I'm sympathetic to that line of > reasoning to the point of finding it somewhat depressing. But I try and > avoid falling into full-blown XSS nihilism and (maybe stubbornly/naively) > still think there's some value in key constraining tokens. And, to your > point, a more detailed look at potential leakage/theft situations would be > useful. One point to consider is whether the exfiltrated material can be widely replicated to turn into a distributed attack. > > > > > > Presumably the counterfeit AS or RS will not have the same hostname (e.g. > > with an illegitimately issued server certificate) as the legitimate server, > > as otherwise DPoP wouldn’t provide protection. > > > Yeah, an assumption (that admittedly should be made more explicit) is that > TLS/HTTPS with server authentication isn't broken. > > > > > Why would the client send the refresh token to the wrong AS? > > > > Daniel maybe has some more ideas here but social engineering is the one > reason that I keep hearing. It's not super compelling but is a reason. > > > > > For resource servers, why wouldn’t an access token audience restriction > > suffice? Is the concern that the access token might not contain an audience > > restriction, or might contain multiple audiences? (If the concern is that > > the resource server wouldn’t check the audience, I’d have a similar concern > > that it wouldn’t check a DPoP proof.) > > > > Audience restriction can work to prevent RS to RS token usage. But in > practice it has turned out that properly getting and using audience > restricted ATs is prohibitively cumbersome for many deployments. > > > > > > 2. > > DPoP currently does not provide any guarantees that the DPoP signature was > > freshly generated, as there is no nonce from the server incorporated into > > the signature. > > I assume there is no practical means for the server to send a nonce to the > > client to use with each request that wouldn't over-complicate DPoP. > > > > Keeping it relatively simple has definitely been a goal. And yeah, I can't > think of a practical way to do something like that without big changes. If > big changes are needed, the whole approach might be in question and > something like Neil's key agreement scheme that I mentioned in the last > interim > https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth > could well be a better overall approach to consider. > > > > I also don't see any guidance in the draft about lifetime/rotation of each > > DPoP key or whether the same key can be used with multiple servers. > > > > Some guidance would probably be useful. > > > > > > My concern is that something analogous to this Kerberos PKINIT attack - > > https://mailarchive.ietf.org/arch/msg/krb-wg/pLgID35fNG1Zh_QJjgXH9vEbwoQ/ > > - could occur if DPoP signatures can be pre-computed by an adversary that > > somehow gains the ability to compute signatures with the private key but > > doesn't gain access to the private key itself. Could that potentially > > happen with malicious JavaScript code? > > > > Trying to wrap my head around this and how it might happen but yes it would > seem that the kind of malicious JavaScript code (like XSS) that could > exfiltrate tokens or drive an attack directly could also pre-compute and > exfiltrate some DPoP proofs. I hadn't considered this and am honestly not > sure how problematic it is. There should be plenty of ways to include a server contribution into the DPoP proof (e.g., a TLS exporter value). > > > > > The iat timestamp is insufficient since future values could be inputted > > with the signatures stored for later use. I could envision a private key > > potentially being re-used for a long period of time, and depending on how > > DPoP ends up getting used in practice, a private key being used with > > multiple servers? > > > > If guaranteeing some degree of freshness of the signature is a concern, > > one solution could be to incorporate the authorization code into the DPoP > > signature for token requests to the AS with grant_type=authorization_code, > > incorporate the refresh token into the DPoP signature for token requests to > > the AS with grant_type=refresh_token, and incorporate the access token into > > the DPoP signature for requests to a resource server. That would prevent > > pre-computing DPoP signatures before the authorization code / refresh token > > / access token is generated by the AS, as long as the recipient properly > > checks the DPoP proof. > > > > That's an interesting consideration and along the lines (at least with > authorization code) of some of the conversations we had early on before the > first -00 draft was even written. And I've noticed that other signature > based proof concepts do typically propose having the signature cover the > access token (or hash thereof). Personally, I've gotten kind of attached to > the simplicity and consistency in the current draft of having the DPoP > proof be the same regardless of where it's presented. And I kind of cringe > at having to dig into the application layer to get at an authorization code > or refresh token value in order to verify the DPoP proof. Also considering > other grant types. So I don't want to move away from that too hastily. > > But I suppose it depends on how much of a concern it is to ensure some > degree of freshness. And weighing that against the potential added > complexity of doing something like the above to try and get freshness. I'm > honestly not sure where I sit on it. I think I've forgotten some of the context here, but will note that in general at IESG evaluation time we end up asking whether there are more parameters that make sense to be covered by the signature/proof/etc. -Ben > > > > > I'd also suggest adding guidance on rotating the DPoP key - e.g. > > mandate/recommend that the client create a new keypair for each token > > request? > > > > A recommendation like that (new keypair per token request and subsequent > access token usage) probably makes sense. I think. In the case of a bound > refresh token issued to a public client, the lifetime of the keypair would > need to correlate with the refresh token (unless facilities are added to > enable dpop key rotation in that scenario). > > > > > > Thanks, > > Mike > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.  If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Apr 7 06:51:36 2020 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 D18C93A0A2F for ; Tue, 7 Apr 2020 06:51:34 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=aol.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 N8ee6UBadJD0 for ; Tue, 7 Apr 2020 06:51:33 -0700 (PDT) Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (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 468993A0A20 for ; Tue, 7 Apr 2020 06:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1586267492; bh=FndW3W0uWamAkyAmPhiDN7/TXYkzk3XRJqkftx+cqSE=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=nuQdU8UuwhmevhE0R9wEa9cujTEOhFQa56E6zRgEhDAWTucVKGT9DbQrZEZSFPNGyRpciwo6gJmOyt/bm0r3W+S89JkpOsj3eFuIOQt2tYJGBIHJ3WLlULRY5eCykWQ38pkLnB1gpM6Ca5neq4DX1/Ymj3cFQOqeDHw4LNCba4INywN+iqvlfiCcoRP3+9Wh0vPLOWphRSMA08x6xqNw3z9bVfOrRnJxi7cZNSdkksU/QfrpOOH3hqRchfkFgxJJ0GYi2CL6B16H0oJmLflcuyFoz7/gramM82nCWoYwQ25Pj/8C5+qgVhSgRs71X+0yqU70O9PqY05rvnTHEzv6Tw== X-YMail-OSG: LNUs2bcVM1k4wLaPu.JA0I32XLiBY1LHqJIRAeR5DALNdzzohK71F6TPbfwibrb .ipB1jU8uOYlVXcjzajrqWvEy0bjOYXZTUzHzM0.cbhQvkgZyrVzqmUfuMRBrpbckhCfEzRC42rC JxCrirNdHLAThEFg8YVEPaOmNlwDmHpnUsHdRLvgjr6i2FW3OAQqQSKvyrm3KCnuYm5BxMxITgHb mptVxsVhlhz_oFSTwXEVZC2N5BGHAcfgAhsgWbsvof3rzt0OTEC8oLZNTCEasjEF2IjZHFG8pPX5 kmBQW.L5OuV_tPEZ5SLc3Xr9cpG_UZJ.iWz8c.pn46FlX5SPE5ZjktLgQ.ow_Tz.mqy68tSIG0pL SS2mQ8ldvbf8x9sBShB8T5Ax4yS6Z0KpI86NelpeJY9FGWPZzjggODmHtWH7gcA40j5aMgnb_r7Q CxDmadiwbcwCgFDK5fB02lSmyIHcN3Ot0z7fMnBOxRbV.pkjW8O8_WzWCi87ihiHrCq8kEH60G6A ZAQXksF1RnbQ4tfsdmnrxPC5FURWZv.g0IBzFy8Oz0fsEJ.8ta_aF_q74u9dRI_MLpjji0ohG7Es fbJo71SkyKe2Gj1axStJBprnQsFNI_Lgu9sbB6y0bGk6MBSTHcoIqJ7EKUzCexLO4zOVNDAtEedR kGtKIkf.qgF4nR4Qrzojd7V4eQAzNRc5vEbFMBeDKu2Og.nkQyMGJRO_wLdwfFWr02Aj_jXkA_cl ST_Wsw.u1wNJJoe1ocMXocQ_nN3xNoIucxbNHsQmgTGqdSMKZFjZ9p7JV.PRiOMZlffRP8ViZTya Re0g1vXabijVqe1cURDciLXx527oH9Q6h5qTp4.pwP2AEe9HH0vvmkkBE.TS4MTaA1czdeJQ.OaR KkWKDhpSIImDt0zhBCuxGuO5em3OAX1oqtOudtXgY3Dv0yCLKkFPvYNJlTN5kKbMhvWVLA8O2K61 MklzUWke.EgYWychlC6fRFQAKcPx1p3Ag_nA0S6fP1Q586S97HjvQ6jaEzSvsOB5oBHRfWN5iaGv ZnfSB1bzY0tui4CWUrYKh7HhxFp9tdg7p5rBhOBvQvXjMZ_Mfr9DFxvpUWbmQlJ69l1lIlJFJu_y 8nhq6mlx8tu4FEqSHHsu5qrFvmigCZDbMim4ZmG_TKj8CTC2xcftp9OlddHOjzgUYDVPOQrqid1N 45ZKstdPadABik9dWbsykXBjVJ3BbM1FXB0lbUw.J5un6d58Q6MBsqFWNsqkvLyIqtNiv4S6kqMY MTJAFehLA4uq4RoVXRvZZECdbyq2dTNU9PgYF6a6cj5e5mxg3jgw5ITGuVZN6RSku3wn1xeTu2v0 mOZZ.uGpBgpnYHllEcCcVHpbsK7PgUo.0p70gXBVE2gwxuJzBaOkJ.RHfmEF1fg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 7 Apr 2020 13:51:32 +0000 Received: by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4e0a9430dcee86f68e6a9ea858f1b2a7; Tue, 07 Apr 2020 13:51:27 +0000 (UTC) To: Vittorio Bertocci , "oauth@ietf.org" , "aaron@parecki.com" References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 7 Apr 2020 09:51:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------807DFE58BE20C5ACC41A195B" Content-Language: en-US X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [OAUTH-WG] oauth-browser-based-apps-05 - BFF 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, 07 Apr 2020 13:51:35 -0000 This is a multi-part message in MIME format. --------------807DFE58BE20C5ACC41A195B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sorry to have missed the meeting. To your second point, I think we should provide guidance in this area. Currently section 6.2 requires all requests to be proxied via the application server. Should we add an additional section for the use case Vittorio mentions? Also there is no mention of DPoP (which of course is a draft) but if the private key is stored in the secure enclave of the browser/device and all requests to the Authorization server and Resource server are signed, is that not strong protection of the access_token/refresh_token? Even if an attacker can obtain the tokens some how, they would also need to be able to run JS to build the appropriate DPoP header in order to use the tokens. Finally, in the cookie models, I don't see any security considerations around things like Server Side Request Forgery or logging the cookies. As these cookies are all bearer tokens, if they are exposed they can be replayed. On 4/6/20 5:35 PM, Vittorio Bertocci wrote: > Hey Aaron, > Thanks for today�s update on oauth-browser-based-apps, very useful. > As agreed, here�s the summary of the point mentioned during today�s call. > > > 1. The last paragraph of 6.2 mentions that an access token could be used as session between the JS frontend and its backend, but no details are given about the security characteristics of making that choice vs using cookies. I would suggest that we either give more guidance on the mechanics of how that would happen (how does the AT get delivered to the JS frontend, what attacks developers should watch out for, etc) or that we recommend the traditional cookie based session approach only. > 2. Currently 6.2 doesn�t mention topologies where the backend obtains ATs and forwards them to the JS frontend, where they are used to perform the actual API calls. Those topologies do exist in the wild, and I know there are practitioner advocates for that approach on this list too, hence it seems we should at least acknowledge those topologies and give some guidance. > If we do position those topologies as legitimate: given that the chatter between JS frontend and backend could in some cases reach sophistication comparable to the client-AS dialog (token requests, renewals, etc), it seems we should either warn people about the security pitfalls they have to watch out for (shorter task for us, but not very actionable) or actually invest some time in specifying how a JS frontend should talk to its backend to delegate its client duties to it and safely retrieve/renew the artifacts the backend obtains on the JS frontend�s behalf (much bigger task for us, but unambiguous guidance and solid threat model developers can safely rely on). > > Thanks! > V. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------807DFE58BE20C5ACC41A195B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sorry to have missed the meeting.

To your second point, I think we should provide guidance in this area. Currently section 6.2 requires all requests to be proxied via the application server. Should we add an additional section for the use case Vittorio mentions?

Also there is no mention of DPoP (which of course is a draft) but if the private key is stored in the secure enclave of the browser/device and all requests to the Authorization server and Resource server are signed, is that not strong protection of the access_token/refresh_token? Even if an attacker can obtain the tokens some how, they would also need to be able to run JS to build the appropriate DPoP header in order to use the tokens.

Finally, in the cookie models, I don't see any security considerations around things like Server Side Request Forgery or logging the cookies. As these cookies are all bearer tokens, if they are exposed they can be replayed.

On 4/6/20 5:35 PM, Vittorio Bertocci wrote:
Hey Aaron,
Thanks for today�s update on oauth-browser-based-apps, very useful.
As agreed, here�s the summary of the point mentioned during today�s call.


  1.  The last paragraph of 6.2 mentions that an access token could be used as session between the JS frontend and its backend, but no details are given about the security characteristics of making that choice vs using cookies. I would suggest that we either give more guidance on the mechanics of how that would happen (how does the AT get delivered to the JS frontend, what attacks developers should watch out for, etc) or that we recommend the traditional cookie based session approach only.
  2.  Currently 6.2 doesn�t mention topologies where the backend obtains ATs and forwards them to the JS frontend, where they are used to perform the actual API calls. Those topologies do exist in the wild, and I know there are practitioner advocates for that approach on this list too, hence it seems we should at least acknowledge those topologies and give some guidance.
If we do position those topologies as legitimate: given that the chatter between JS frontend and backend could in some cases reach sophistication comparable to the client-AS dialog (token requests, renewals, etc), it seems we should either warn people about the security pitfalls they have to watch out for (shorter task for us, but not very actionable) or actually invest some time in specifying how a JS frontend should talk to its backend to delegate its client duties to it and safely retrieve/renew the artifacts the backend obtains on the JS frontend�s behalf (much bigger task for us, but unambiguous guidance and solid threat model developers can safely rely on).

Thanks!
V.



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

--------------807DFE58BE20C5ACC41A195B-- From nobody Tue Apr 7 07:34:24 2020 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 1888B3A0B83; Tue, 7 Apr 2020 07:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: oauth@ietf.org, rdd@cert.org, rifaat.ietf@gmail.com, oauth-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158627006196.19088.1333228887901663878@ietfa.amsl.com> Date: Tue, 07 Apr 2020 07:34:22 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 07 Apr 2020 14:34:22 -0000 A new interim meeting request has just been submitted by Rifaat Shekh-Yusef. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-04 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Meeting Type: Virtual Meeting Session 1: Date: 2020-04-13 Start Time: 12:00 America/Toronto Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0 Agenda Note: --------------------------------------------------------- From nobody Tue Apr 7 07:38:01 2020 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 6FEF03A0B38; Tue, 7 Apr 2020 07:37:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158627027927.18547.16597992395827569585@ietfa.amsl.com> Date: Tue, 07 Apr 2020 07:37:59 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 07 Apr 2020 14:37:59 -0000 A new interim meeting request has just been submitted by Rifaat Shekh-Yusef. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-05 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Meeting Type: Virtual Meeting Session 1: Date: 2020-04-20 Start Time: 12:00 America/Toronto Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=ma2406d0d665d68cf51297c0544e429bf Agenda Note: --------------------------------------------------------- From nobody Tue Apr 7 07:40:41 2020 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 356523A0BC6; Tue, 7 Apr 2020 07:40:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, rdd@cert.org, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158627043613.31464.4547263960290437415@ietfa.amsl.com> Date: Tue, 07 Apr 2020 07:40:36 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 07 Apr 2020 14:40:40 -0000 A new interim meeting request has just been submitted by Rifaat Shekh-Yusef. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-06 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Meeting Type: Virtual Meeting Session 1: Date: 2020-04-27 Start Time: 12:00 America/Toronto Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=mec2af7ee3fbb8c161501b6294c762114 Agenda Note: --------------------------------------------------------- From nobody Tue Apr 7 07:43:10 2020 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 E01A43A0B38; Tue, 7 Apr 2020 07:43:07 -0700 (PDT) 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.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158627058756.29802.16641808201919924882@ietfa.amsl.com> Date: Tue, 07 Apr 2020 07:43:07 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 07 Apr 2020 14:43:08 -0000 A new interim meeting request has just been submitted by Rifaat Shekh-Yusef. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-07 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Meeting Type: Virtual Meeting Session 1: Date: 2020-05-04 Start Time: 12:00 America/Toronto Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m64d7f0045380133e7df9485d3e159a28 Agenda Note: --------------------------------------------------------- From nobody Tue Apr 7 07:46:24 2020 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 9F7FF3A0B3D; Tue, 7 Apr 2020 07:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rifaat.ietf@gmail.com, rdd@cert.org, oauth-chairs@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158627078263.31464.17791185737306172876@ietfa.amsl.com> Date: Tue, 07 Apr 2020 07:46:22 -0700 Archived-At: Subject: [OAUTH-WG] oauth - New Interim Meeting Request 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, 07 Apr 2020 14:46:23 -0000 A new interim meeting request has just been submitted by Rifaat Shekh-Yusef. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-oauth-08 --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Meeting Type: Virtual Meeting Session 1: Date: 2020-05-11 Start Time: 12:00 America/Toronto Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m0ac0dd18a603ddeb755019f0060bffe1 Agenda Note: --------------------------------------------------------- From nobody Tue Apr 7 09:38:39 2020 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 4FF143A0E73 for ; Tue, 7 Apr 2020 09:38:37 -0700 (PDT) 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 Zhbtlw5cTCIA for ; Tue, 7 Apr 2020 09:38:31 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 61CB33A0E46 for ; Tue, 7 Apr 2020 09:38:27 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id a6so3859115ilr.4 for ; Tue, 07 Apr 2020 09:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=q/ABrdezZcjJ33S9k5wHlqhG1i405HRgQ1hz17v+/rw=; b=KKvoq93A2sEW1/2NtN2OyIPXRXb3Y2WRPM0hFSVmrdj5Ooaxpv+5/WjJr71P2WRlwQ JLBP/bHp4HYd5pDYPniEYwFNBABiK8WwY3foOedEjnjgIJF9i8RS65PE9rL8XUZoB4Ft gvIZkvi15XIbcVrH97MJEwHZStLJmjpzMhZlv8iZZQNstqC7/PJtwKqVi+RfnkBP/e/U EBvZvkESPzXF+EFp9qS1MGg5gVcKNO0XHy3JF2I071DAuIEXHqS9y9VlxNjtvJlwr9L/ g6Sum8cykLzIP7/Ka+JPQ80WYBl/PAfLKMUWCE4G4oTFfEI7S0j9Nl5dtTFw+bJ5KzlA VspQ== 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=q/ABrdezZcjJ33S9k5wHlqhG1i405HRgQ1hz17v+/rw=; b=rKuYG8i/enB2PI2kVJYu1JcEE5rXx6Mm0vry6jYaGgLrE1xhBPcMxFtQWuRXsGowJS 0EfRwuXBv/PBrWE0TMKwIIGZG7yKF81fCeks8AjFx4B6sRV3kSgdiJRlLXdB1M7UM5uh 5i1bl3duOY4Q+Y+8KRk0yUaEFXogH8URN6zjNAepIM1hluecVApKPFPOI44xnuuQ3d6i M6Si0Zbnl2pOSB9omNhVTR6lBHpcvEGtZVP0diynXfYgshgaCBE7yK9kaxTYWEd6v7nA +Tv6IqGU3m9REK6HQcGOhVTXcOP1kP4/DKWFXHbuau2v2jW4RWghO+TmAL7xCklkwV/j jB8g== X-Gm-Message-State: AGi0PuaPxvXxu+TfgKze1NIbVDXtfDG3NGV5IxDVqOtjfXjuY9bUcOaH nW2s87AqFnBOGBqah4cdmFy9E0z214LwPbWiQhjKng== X-Google-Smtp-Source: APiQypIGx/jW6RkTFYbV1SPZ1evQpOKWgYW7WNjWl1yfUR7oLaNyZb1tZ7fg+ft9xuYfJn9PcZVE9xspV0pGTZY0f4A= X-Received: by 2002:a92:5d8f:: with SMTP id e15mr2582656ilg.255.1586277506230; Tue, 07 Apr 2020 09:38:26 -0700 (PDT) MIME-Version: 1.0 References: <122442811.9938891586268821154.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <122442811.9938891586268821154.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Tue, 7 Apr 2020 12:38:15 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="000000000000465b1105a2b603ac" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 13th 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, 07 Apr 2020 16:38:37 -0000 --000000000000465b1105a2b603ac Content-Type: multipart/alternative; boundary="000000000000465b0d05a2b603aa" --000000000000465b0d05a2b603aa Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Tue, Apr 7, 2020 at 10:13 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 13th To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 613 372 917 Meeting password: yuXVpKA3j85 Monday, April 13, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*613372917%23%23*01*> Call-in toll number (US/Canada) 1-877-668-4493 <1-877-668-4493,,*01*613372917%23%23*01*> Call-in toll free number (US/Canada) Global call-in numbers | Toll-free calling restrictions *Join from a video system or application* Dial 613372917@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 613372917.ietf@lync.webex.com Need help? Go to http://help.webex.com --000000000000465b0d05a2b603aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Tue, Apr 7, 2020 at 10:13 AM
= Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Int= erim Meeting - April 13th
To: <oauth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 613 372 917
Meeting password: yuXVpKA3j85
=20
=C2= =A0
Monday, April 13, 2020
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0= |=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Join from a video system or appli= cation
Dial 613372917@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 613372917.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--000000000000465b0d05a2b603aa Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200407T141341Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20200413T120000 DTEND;TZID=3DAmerica/New_York:20200413T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm776932cd87f84cbceb34ae90= 7027b0f0 TRANSP:OPAQUE SEQUENCE:1586268821 UID:2668f264-5386-486a-893b-60d2461cf516 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dm776932cd87f84cbceb34ae907027b0f0\nMeeting number (access code): 613 = 372 917\n\n\nMeeting password: yuXVpKA3j85\n\n\n\nJOIN BY PHONE\n1-650-479-= 3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only,= hosts not supported): tel:%2B1-650-479-3208,,*01*613372917%23%23*01*\n1-87= 7-668-4493 Call-in toll free number (US/Canada)\nTap here to call (mobile p= hones only, hosts not supported): tel:1-877-668-4493,,*01*613372917%23%23*0= 1*\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?= MTID=3Dm6baf6ec840ecbe59c0115990eda1e4b5\n\nToll-free calling restrictions\= nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO= SYSTEM OR APPLICATION\nDial sip:613372917@ietf.webex.com\nYou can also dia= l 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lyn= c or Microsoft Skype for Business\nDial sip:613372917.ietf@lync.webex.com\n= \n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/= WBX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all= ows audio and other information sent during the session to be recorded, whi= ch may be discoverable in a legal matter. By joining this session, you auto= matically consent to such recordings. If you do not consent to being record= ed, discuss your concerns with the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n
&= nbsp;
\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the We= bex meeting here.\n
 
\= n Meeting number (ac= cess code): 613 372 917\n
\n \n =
Meeting p= assword:= yuXVpKA3j85
\n\n \n \n = \n \n
 
\n \n \n \n \n
Join meeting
\n \n
\n\n \n 
&nbs= p;
\n\n 
Join by phone  
1-650-479-3208<= /b> Call-in toll number (US/Canada)  
1-877-668-4493 Call-in toll= free number (US/Canada)  
Global call-in numbers  | &nbs= p;Toll-free calling restri= ctions 


\n\n
 
\n\nJoin from= a video system or application
Dial 613372917@ietf.webex.com=  
You can al= so dial 173.243.2.68 and enter your meeting number.  
 
\n\n
Join using Microsoft Lync or Microsoft Skype for Bus= iness
Dial 613372917.ietf@lync.webex.com
\n\n \n \n \n \n = \n \n \n \n \n
 
Need help? Go to http://help.webex.com\n
 
\n SUMMARY:OAuth WG Virtual Interim Meeting - April 13th PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --000000000000465b0d05a2b603aa-- --000000000000465b1105a2b603ac Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <171558137cec1ce7aee1> X-Attachment-Id: 171558137cec1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDA3 VDE0MTM0MVoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMDQxM1QxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMDQxM1QxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW03NzY5MzJjZDg3Zjg0Y2JjZWIzNGFlOTA3MDI3YjBmMA0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTU4NjI2ODgyMQ0KVUlEOjI2NjhmMjY0LTUzODYtNDg2YS04OTNiLTYwZDI0 NjFjZjUxNg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW03NzY5MzJjZDg3Zjg0Y2JjZWIzNGFlOTA3 MDI3YjBmMFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjEzIDM3MiA5MTdcblxuXG5N ZWV0aW5nIHBhc3N3b3JkOiB5dVhWcEtBM2o4NVxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUgdG8gY2Fs bCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjEzMzcyOTE3JTIzJTIzKjAxKlxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTMzNzI5MTclMjMlMjMqMDEqXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTZiYWY2ZWM4NDBlY2Jl NTljMDExNTk5MGVkYTFlNGI1XG5cblRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uc1xuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2MTMzNzI5MTdA aWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjYxMzM3MjkxNy5pZXRmQGx5bmMu d2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJv cmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4N ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbiog e1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjEzIDM3MiA5MTc8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+eXVYVnBLQTNqODU8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5c bgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3 aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0Mjsg Ym9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDox NjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIg c3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTc3NjkzMmNkODdmODRjYmNlYjM0YWU5MDcwMjdiMGYwIiBzdHls ZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwv dGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAw MDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBG QUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxMzM3MjkxNyUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTMzNzI5MTclMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS04NzctNjY4LTQ0OTM8L2E+PC9iPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW02YmFmNmVjODQwZWNiZTU5YzAxMTU5OTBlZGExZTRiNSIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkds b2JhbCBjYWxsLWluIG51bWJlcnM8L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPlRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lw OjYxMzM3MjkxN0BpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj42MTMzNzI5MTdAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFs c28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05U PiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdo dDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBl IGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjEzMzcyOTE3LmlldGZAbHlu Yy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjki PjYxMzM3MjkxNy5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4J CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8 L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIC0gQXByaWwgMTN0aA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpW QUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRl cg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --000000000000465b1105a2b603ac-- From nobody Tue Apr 7 09:39:11 2020 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 ADBC83A0E73 for ; Tue, 7 Apr 2020 09:39:09 -0700 (PDT) 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 ZXJOB-YFc6bj for ; Tue, 7 Apr 2020 09:39:08 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 7BAE53A0E46 for ; Tue, 7 Apr 2020 09:39:03 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id g15so3824706ilj.10 for ; Tue, 07 Apr 2020 09:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Omhe7Auemr6AScUja3hwM1xkC7cjSqMaUKgWMoV+Zx4=; b=CdrN/D8oZxZWIIS6lZoJVrZqqrpGGGBaDzUDGz9sgozfxgqvd9A82yP8Pk/8YXOSI+ +GmDYwP2wtXH6W2s/m8onvAFZZWT9bJIndq3isMcsAbkPvZ2AhJzihv3RroyrHaQMY17 lKODIeADrFdKrha7M68FxrH7aJeDr/Bz+GPTNzeYofzmO+Pg2EpjccKNuRCtkv1o51DY VX/hz8PFA43mXc2kCgVyv19Lzn8EL97vhDvdn/nQ4OHXHQr4plAmX8buM9gYHU1kNAXv LEuB0rYbkZUXW1LEqR9AJkl9ZT6rIptYodVAV8NBMo5vKAFYzj3+4AT69D7kGQjhNL6Y +c9g== 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=Omhe7Auemr6AScUja3hwM1xkC7cjSqMaUKgWMoV+Zx4=; b=o7KGXDjtjEHCOjp3+XbCi3x9uzsY4Jn2flBdXCqzLp5xYpSFzVJwLlQaGdj5VKPZhQ auTi/ey9EMOvLEazH5YmFnvQFq3hjs1RJqWElZ221JVejBjlu4JXBf7PK+QIY3AoUwSP wRtHeDy2YiZLAuGllOqKuYImKIC5FRdWmp77ul1MNfN3fujSyyCHGzbTAwyryi7x0UWk iy62jbjjy+exIDoQ9zn/xaiNJx6M/L4AjPGm5wQI5G1CDjVE6TaeTEBSmK/IRNJFc5/R gIbxdt6WllFnmtmqZjRfgGUi7UBrtxur1u4QCrYZiGoQTZvdeWzeQSLo+/PiIu+NZL+H 4SUg== X-Gm-Message-State: AGi0PuYwXYN3E+e/oHTwDqUjsAor9aYa14KRDLQz//0FrCJDtxa6R43u Uqs4CeepFnSjzHqEdeWtmuIc1/Qlp5eyucRzekyIjQ== X-Google-Smtp-Source: APiQypJgucB19QxtdvGgRbEm6zDC4ZVo3dcSRjKobpTdbvBMMOGg8X8WrrO9NlSPByJM/QnMoVhqfPWaa6G9TgJFgQQ= X-Received: by 2002:a05:6e02:8b3:: with SMTP id a19mr3204109ilt.36.1586277542484; Tue, 07 Apr 2020 09:39:02 -0700 (PDT) MIME-Version: 1.0 References: <2034808448.9941031586268924837.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <2034808448.9941031586268924837.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Tue, 7 Apr 2020 12:38:51 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="000000000000708b5105a2b60588" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 20th 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, 07 Apr 2020 16:39:10 -0000 --000000000000708b5105a2b60588 Content-Type: multipart/alternative; boundary="000000000000708b4e05a2b60586" --000000000000708b4e05a2b60586 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Tue, Apr 7, 2020 at 10:15 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 20th To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 610 005 584 Meeting password: PVe2mESQb23 Monday, April 20, 2020 6:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*610005584%23%23*01*> Call-in toll number (US/Canada) 1-877-668-4493 <1-877-668-4493,,*01*610005584%23%23*01*> Call-in toll free number (US/Canada) Global call-in numbers | Toll-free calling restrictions *Join from a video system or application* Dial 610005584@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 610005584.ietf@lync.webex.com Need help? Go to http://help.webex.com --000000000000708b4e05a2b60586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Tue, Apr 7, 2020 at 10:15 AM
= Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Int= erim Meeting - April 20th
To: <oauth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 610 005 584
Meeting password: PVe2mESQb23
=20
=C2= =A0
Monday, April 20, 2020
6:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) Easte= rn Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0= |=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Join from a video system or appli= cation
Dial 610005584@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 610005584.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--000000000000708b4e05a2b60586 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200407T141524Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20200420T060000 DTEND;TZID=3DAmerica/New_York:20200420T070000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dma2406d0d665d68cf51297c05= 44e429bf TRANSP:OPAQUE SEQUENCE:1586268924 UID:51099ddc-0247-4ff6-8dde-c6c0302bfcdf DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dma2406d0d665d68cf51297c0544e429bf\nMeeting number (access code): 610 = 005 584\n\n\nMeeting password: PVe2mESQb23\n\n\n\nJOIN BY PHONE\n1-650-479-= 3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only,= hosts not supported): tel:%2B1-650-479-3208,,*01*610005584%23%23*01*\n1-87= 7-668-4493 Call-in toll free number (US/Canada)\nTap here to call (mobile p= hones only, hosts not supported): tel:1-877-668-4493,,*01*610005584%23%23*0= 1*\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?= MTID=3Dm283b029635a7e09717e83e0c1ee39ef6\n\nToll-free calling restrictions\= nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO= SYSTEM OR APPLICATION\nDial sip:610005584@ietf.webex.com\nYou can also dia= l 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lyn= c or Microsoft Skype for Business\nDial sip:610005584.ietf@lync.webex.com\n= \n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/= WBX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all= ows audio and other information sent during the session to be recorded, whi= ch may be discoverable in a legal matter. By joining this session, you auto= matically consent to such recordings. If you do not consent to being record= ed, discuss your concerns with the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n
&= nbsp;
\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the We= bex meeting here.\n
 
\= n Meeting number (ac= cess code): 610 005 584\n
\n \n =
Meeting p= assword:= PVe2mESQb23
\n\n \n \n = \n \n
 
\n \n \n \n \n
Join meeting
\n \n
\n\n \n 
&nbs= p;
\n\n 
Join by phone  
1-650-479-3208<= /b> Call-in toll number (US/Canada)  
1-877-668-4493 Call-in toll= free number (US/Canada)  
Global call-in numbers  | &nbs= p;Toll-free calling restri= ctions 


\n\n
 
\n\nJoin from= a video system or application
Dial 610005584@ietf.webex.com=  
You can al= so dial 173.243.2.68 and enter your meeting number.  
 
\n\n
Join using Microsoft Lync or Microsoft Skype for Bus= iness
Dial 610005584.ietf@lync.webex.com
\n\n \n \n \n \n = \n \n \n \n \n
 
Need help? Go to http://help.webex.com\n
 
\n SUMMARY:OAuth WG Virtual Interim Meeting - April 20th PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR --000000000000708b4e05a2b60586-- --000000000000708b5105a2b60588 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1715582292cc1ce7aee1> X-Attachment-Id: 1715582292cc1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDA3 VDE0MTUyNFoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMDQyMFQwNjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMDQyMFQwNzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1hMjQwNmQwZDY2NWQ2OGNmNTEyOTdjMDU0NGU0MjliZg0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTU4NjI2ODkyNA0KVUlEOjUxMDk5ZGRjLTAyNDctNGZmNi04ZGRlLWM2YzAz MDJiZmNkZg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1hMjQwNmQwZDY2NWQ2OGNmNTEyOTdjMDU0 NGU0MjliZlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjEwIDAwNSA1ODRcblxuXG5N ZWV0aW5nIHBhc3N3b3JkOiBQVmUybUVTUWIyM1xuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUgdG8gY2Fs bCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjEwMDA1NTg0JTIzJTIzKjAxKlxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTAwMDU1ODQlMjMlMjMqMDEqXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTI4M2IwMjk2MzVhN2Uw OTcxN2U4M2UwYzFlZTM5ZWY2XG5cblRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uc1xuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2MTAwMDU1ODRA aWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjYxMDAwNTU4NC5pZXRmQGx5bmMu d2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJv cmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4N ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbiog e1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjEwIDAwNSA1ODQ8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+UFZlMm1FU1FiMjM8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5c bgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3 aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0Mjsg Ym9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDox NjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIg c3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bWEyNDA2ZDBkNjY1ZDY4Y2Y1MTI5N2MwNTQ0ZTQyOWJmIiBzdHls ZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwv dGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAw MDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBG QUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxMDAwNTU4NCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTAwMDU1ODQlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS04NzctNjY4LTQ0OTM8L2E+PC9iPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW0yODNiMDI5NjM1YTdlMDk3MTdlODNlMGMxZWUzOWVmNiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkds b2JhbCBjYWxsLWluIG51bWJlcnM8L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPlRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lw OjYxMDAwNTU4NEBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj42MTAwMDU1ODRAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFs c28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05U PiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdo dDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBl IGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjEwMDA1NTg0LmlldGZAbHlu Yy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjki PjYxMDAwNTU4NC5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4J CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8 L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIC0gQXByaWwgMjB0aA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpFTkQ6VkVW RU5UDQpFTkQ6VkNBTEVOREFSDQo= --000000000000708b5105a2b60588-- From nobody Tue Apr 7 09:39:30 2020 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 2759F3A0F1B for ; Tue, 7 Apr 2020 09:39:24 -0700 (PDT) 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 waBP_1XjuKZ6 for ; Tue, 7 Apr 2020 09:39:22 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 59BD13A0EDA for ; Tue, 7 Apr 2020 09:39:20 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id f3so4082820ioj.1 for ; Tue, 07 Apr 2020 09:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=en2YMzqrcztCarFQAqzKJNQQD2qwvZVxbLi8pIDHla4=; b=mJBMIKddaeaEk01vyCYAfd3L3sDB6HsCn4PaMtLSwM6KN2Z2lL7ZOSF9qOm0geMoq8 R9sdYedgH4DvIeft1h9UYUjZ5K5B58ofBw253zStsvosJhVqNz+Jnywfjh4Pt1MUHE35 Jork7niVB5OYdaD3AdhleO1zUBSiNIwlv7PdKSLGhKWJRHjay32gTyKyO3OSjidBv5jk 1gZYUIXiT2A0/LBogvJ0PmgilzPGyv12+azsPmf0FTNtILEXWMna5+huglGhSGXnc3ed MDdwwk8yu1EbT5liXNnEr8nFxTzHYn9ZLNmeFx5dRt0YDw2z4Ab9nYtvC8RsOMmGRM5e qvgw== 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=en2YMzqrcztCarFQAqzKJNQQD2qwvZVxbLi8pIDHla4=; b=NEBgt2SQWlnI22qvGbsGZyh2pTeH7zhyF1fT/7OLVObvvylwCqpGhJ5OyU+XtvS8av zW+/jDCyvaYCRSWhcQ1PmWNzio0uq+bWDLJLbUijJJSVdccyyP0TFPY6gQLtKsvG8gkP gEzY77jHA6Ma8Ou6eibbgfJrdwY3UHLjFh0UUqGcc8YjYASBq2rw+UOa9WUIPNouYdwr F0VANsNPG3xlhQpZBGMYX/DL7SlVGvIQLBm91d5XqwK+0kX3Ac/23gwxdLsDlaBkd4tT Ju2A7WD9u1asDcddwvUlcjJyo3hi9Vp9/v3Ia2zkGl/KjSwsm+DJVvexWgzyzMAPkUTK 1LPw== X-Gm-Message-State: AGi0PuZz0x2fw29eKr2RueTGNhr+2VV4oOaM+wsMPVLP6IqNXl1YaQt2 ExjThLyq/30Mk02xPZIc9hc330CIOTt7nXvBUpFQTg== X-Google-Smtp-Source: APiQypKwfzv1+a256dZAgMjEYPNudhmohO5k3vZxVLBoPVIKrOIsP1fFzQS0KgGlEwWZ4/ROuIwadTCrRQF42I2FAX4= X-Received: by 2002:a5d:8946:: with SMTP id b6mr2964778iot.51.1586277559263; Tue, 07 Apr 2020 09:39:19 -0700 (PDT) MIME-Version: 1.0 References: <931566412.5885791586269087093.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <931566412.5885791586269087093.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Tue, 7 Apr 2020 12:39:08 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000006f8c9f05a2b606a5" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 27th 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, 07 Apr 2020 16:39:29 -0000 --0000000000006f8c9f05a2b606a5 Content-Type: multipart/alternative; boundary="0000000000006f8c9d05a2b606a3" --0000000000006f8c9d05a2b606a3 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Tue, Apr 7, 2020 at 10:18 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - April 27th To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 617 192 377 Meeting password: mKU3PATiM32 Monday, April 27, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*617192377%23%23*01*> Call-in toll number (US/Canada) 1-877-668-4493 <1-877-668-4493,,*01*617192377%23%23*01*> Call-in toll free number (US/Canada) Global call-in numbers | Toll-free calling restrictions *Join from a video system or application* Dial 617192377@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 617192377.ietf@lync.webex.com Need help? Go to http://help.webex.com --0000000000006f8c9d05a2b606a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Tue, Apr 7, 2020 at 10:18 AM
= Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Int= erim Meeting - April 27th
To: <oauth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 617 192 377
Meeting password: mKU3PATiM32
=20
=C2= =A0
Monday, April 27, 2020
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0= |=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Join from a video system or appli= cation
Dial 617192377@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 617192377.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--0000000000006f8c9d05a2b606a3 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200407T141806Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20200427T120000 DTEND;TZID=3DAmerica/New_York:20200427T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dmec2af7ee3fbb8c161501b629= 4c762114 TRANSP:OPAQUE SEQUENCE:1586269086 UID:3f4f0722-fe63-49a1-af3f-3e461fa6ddc0 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dmec2af7ee3fbb8c161501b6294c762114\nMeeting number (access code): 617 = 192 377\n\n\nMeeting password: mKU3PATiM32\n\n\n\nJOIN BY PHONE\n1-650-479-= 3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only,= hosts not supported): tel:%2B1-650-479-3208,,*01*617192377%23%23*01*\n1-87= 7-668-4493 Call-in toll free number (US/Canada)\nTap here to call (mobile p= hones only, hosts not supported): tel:1-877-668-4493,,*01*617192377%23%23*0= 1*\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?= MTID=3Dm9a82be5a5d483cf8bb94006261d0fa0b\n\nToll-free calling restrictions\= nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO= SYSTEM OR APPLICATION\nDial sip:617192377@ietf.webex.com\nYou can also dia= l 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lyn= c or Microsoft Skype for Business\nDial sip:617192377.ietf@lync.webex.com\n= \n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/= WBX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all= ows audio and other information sent during the session to be recorded, whi= ch may be discoverable in a legal matter. By joining this session, you auto= matically consent to such recordings. If you do not consent to being record= ed, discuss your concerns with the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n
&= nbsp;
\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the We= bex meeting here.\n
 
\= n Meeting number (ac= cess code): 617 192 377\n
\n \n =
Meeting p= assword:= mKU3PATiM32
\n\n \n \n = \n \n
 
\n \n \n \n \n
Join meeting
\n \n
\n\n \n 
&nbs= p;
\n\n 
Join by phone  
1-650-479-3208<= /b> Call-in toll number (US/Canada)  
1-877-668-4493 Call-in toll= free number (US/Canada)  
Global call-in numbers  | &nbs= p;Toll-free calling restri= ctions 


\n\n
 
\n\nJoin from= a video system or application
Dial 617192377@ietf.webex.com=  
You can al= so dial 173.243.2.68 and enter your meeting number.  
 
\n\n
Join using Microsoft Lync or Microsoft Skype for Bus= iness
Dial 617192377.ietf@lync.webex.com
\n\n \n \n \n \n = \n \n \n \n \n
 
Need help? Go to http://help.webex.com\n
 
\n SUMMARY:OAuth WG Virtual Interim Meeting - April 27th PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR --0000000000006f8c9d05a2b606a3-- --0000000000006f8c9f05a2b606a5 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <17155826c88c1ce7aee1> X-Attachment-Id: 17155826c88c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDA3 VDE0MTgwNloNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMDQyN1QxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMDQyN1QxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1lYzJhZjdlZTNmYmI4YzE2MTUwMWI2Mjk0Yzc2MjExNA0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTU4NjI2OTA4Ng0KVUlEOjNmNGYwNzIyLWZlNjMtNDlhMS1hZjNmLTNlNDYx ZmE2ZGRjMA0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lYzJhZjdlZTNmYmI4YzE2MTUwMWI2Mjk0 Yzc2MjExNFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjE3IDE5MiAzNzdcblxuXG5N ZWV0aW5nIHBhc3N3b3JkOiBtS1UzUEFUaU0zMlxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUgdG8gY2Fs bCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjE3MTkyMzc3JTIzJTIzKjAxKlxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTcxOTIzNzclMjMlMjMqMDEqXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTlhODJiZTVhNWQ0ODNj ZjhiYjk0MDA2MjYxZDBmYTBiXG5cblRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uc1xuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2MTcxOTIzNzdA aWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjYxNzE5MjM3Ny5pZXRmQGx5bmMu d2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJv cmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4N ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbiog e1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjE3IDE5MiAzNzc8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+bUtVM1BBVGlNMzI8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5c bgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3 aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0Mjsg Ym9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDox NjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIg c3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bWVjMmFmN2VlM2ZiYjhjMTYxNTAxYjYyOTRjNzYyMTE0IiBzdHls ZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwv dGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAw MDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBG QUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxNzE5MjM3NyUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTcxOTIzNzclMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS04NzctNjY4LTQ0OTM8L2E+PC9iPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW05YTgyYmU1YTVkNDgzY2Y4YmI5NDAwNjI2MWQwZmEwYiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkds b2JhbCBjYWxsLWluIG51bWJlcnM8L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPlRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lw OjYxNzE5MjM3N0BpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj42MTcxOTIzNzdAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFs c28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05U PiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdo dDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBl IGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjE3MTkyMzc3LmlldGZAbHlu Yy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjki PjYxNzE5MjM3Ny5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4J CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8 L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIC0gQXByaWwgMjd0aA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpFTkQ6VkVW RU5UDQpFTkQ6VkNBTEVOREFSDQo= --0000000000006f8c9f05a2b606a5-- From nobody Tue Apr 7 09:39:58 2020 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 DFB173A0F9F for ; Tue, 7 Apr 2020 09:39:50 -0700 (PDT) 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 nA94O_VUnx84 for ; Tue, 7 Apr 2020 09:39:49 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 294E83A0FA1 for ; Tue, 7 Apr 2020 09:39:37 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id i3so3986666ioo.13 for ; Tue, 07 Apr 2020 09:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1RvEu8Ad0f49id9R1yrNKDCg2wgYbsUyKHd86AHp9vA=; b=WfmgHbk/+vQmamu703KbC1ecaQM0zUgS/TZz+sUkF68o8wrHdCk9bW2bF3n0ARMPn5 GXrS4G1DeJdcG2XWcoOWh918se7BGQYOKXrWrvaGEE3u6eka/dbPKOs/kjQReNaWxd6k knxwI/tnIAAXqSLnAiwoIbTUEpDoqUBWuRPaHdVMftrSgYRokvxC32h+cTpp28miI98D HfDO0zxRZMr2uTnYKgEianhlvEaFqI5nkn8QOL0C+ZkLyMqx3dAJgzD1JMWnSHIIq3zg r0X7s7JP8hybp5b0G+0t8zYP9Az5DKX0wAU+vkyuHISqHeqwJGKeMfcnUlnmG37Ocpor s9bw== 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=1RvEu8Ad0f49id9R1yrNKDCg2wgYbsUyKHd86AHp9vA=; b=qx1kcBTMDi/IiMA23pRqce4SoWLVknJcJdENXoc2z31xFPJLw7O870upk7WOfHcKKy EYYXFngQovq5kapVQBw3l63sweY/I/YTZ5AGvaxPS2nILAGeLGaRiRs8bG8+6R/ngVwT uU19q8PY6mrXAx+JAgXIdts42ojp432ElV2ng8NT+vNFZoqr9/Y2LD4lT6V3obvoaq5C SmubtY5nyQkJoZx4UU/rcuJv3pbUghS3zURAhGxbGpxBJo6Db2Z8TF72fYC0QSIzXmfe 7Pw5I38FzejrrnF9sAm3Qg+SYKHgzdpVQgHvWO0iAGvDrreOM1i5JSAZx3rSPo7T26Di 1W0A== X-Gm-Message-State: AGi0PubcnEZlypcUrTjeUwXSPDrjetFu07TtWQ+WtMb5DAB0gIi7WmV2 XTbSMNm7iaTutpUt5tbChdcOffJxHd8mSOM/610qag== X-Google-Smtp-Source: APiQypIYpeDo3lTNWzDxIe/I2tL47pGMrdeLSfcFzji/jN099U+20Gy0F4bJKwkJIrUyrXa4FZuFCwdL5j17xmQ56/4= X-Received: by 2002:a6b:fc0c:: with SMTP id r12mr2848788ioh.147.1586277575201; Tue, 07 Apr 2020 09:39:35 -0700 (PDT) MIME-Version: 1.0 References: <1501545390.9960361586269294432.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <1501545390.9960361586269294432.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Tue, 7 Apr 2020 12:39:24 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="00000000000062c09c05a2b60798" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - May 4th 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, 07 Apr 2020 16:39:56 -0000 --00000000000062c09c05a2b60798 Content-Type: multipart/alternative; boundary="00000000000062c09a05a2b60796" --00000000000062c09a05a2b60796 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Tue, Apr 7, 2020 at 10:21 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - May 4th To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 613 704 738 Meeting password: tpGbjNXj652 Monday, May 4, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*613704738%23%23*01*> Call-in toll number (US/Canada) 1-877-668-4493 <1-877-668-4493,,*01*613704738%23%23*01*> Call-in toll free number (US/Canada) Global call-in numbers | Toll-free calling restrictions *Join from a video system or application* Dial 613704738@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 613704738.ietf@lync.webex.com Need help? Go to http://help.webex.com --00000000000062c09a05a2b60796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Tue, Apr 7, 2020 at 10:21 AM
= Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Int= erim Meeting - May 4th
To: <oauth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 613 704 738
Meeting password: tpGbjNXj652
=20
=C2= =A0
Monday, May 4, 2020
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0= |=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Join from a video system or appli= cation
Dial 613704738@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 613704738.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--00000000000062c09a05a2b60796 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200407T142134Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20200504T120000 DTEND;TZID=3DAmerica/New_York:20200504T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm64d7f0045380133e7df9485d= 3e159a28 TRANSP:OPAQUE SEQUENCE:1586269294 UID:382065ef-de03-4d74-b787-897e2f6ef6c0 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dm64d7f0045380133e7df9485d3e159a28\nMeeting number (access code): 613 = 704 738\n\n\nMeeting password: tpGbjNXj652\n\n\n\nJOIN BY PHONE\n1-650-479-= 3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only,= hosts not supported): tel:%2B1-650-479-3208,,*01*613704738%23%23*01*\n1-87= 7-668-4493 Call-in toll free number (US/Canada)\nTap here to call (mobile p= hones only, hosts not supported): tel:1-877-668-4493,,*01*613704738%23%23*0= 1*\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?= MTID=3Dmf16e1049c98b7511a4c27488216064d1\n\nToll-free calling restrictions\= nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO= SYSTEM OR APPLICATION\nDial sip:613704738@ietf.webex.com\nYou can also dia= l 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lyn= c or Microsoft Skype for Business\nDial sip:613704738.ietf@lync.webex.com\n= \n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/= WBX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all= ows audio and other information sent during the session to be recorded, whi= ch may be discoverable in a legal matter. By joining this session, you auto= matically consent to such recordings. If you do not consent to being record= ed, discuss your concerns with the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n =
&= nbsp;
\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the We= bex meeting here.\n
 
\= n Meeting number (ac= cess code): 613 704 738\n
\n \n =
Meeting p= assword:= tpGbjNXj652
\n\n \n \n = \n \n
 
\n \n \n \n \n
Join meeting
\n \n
\n\n \n 
&nbs= p;
\n\n 
Join by phone  
1-650-479-3208<= /b> Call-in toll number (US/Canada)  
1-877-668-4493 Call-in toll= free number (US/Canada)  
Global call-in numbers  | &nbs= p;Toll-free calling restri= ctions 


\n\n
 
\n\nJoin from= a video system or application
Dial 613704738@ietf.webex.com=  
You can al= so dial 173.243.2.68 and enter your meeting number.  
 
\n\n
Join using Microsoft Lync or Microsoft Skype for Bus= iness
Dial 613704738.ietf@lync.webex.com
\n\n \n \n \n \n = \n \n \n \n \n
 
Need help? Go to http://help.webex.com\n
 
\n SUMMARY:OAuth WG Virtual Interim Meeting - May 4th PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR --00000000000062c09a05a2b60796-- --00000000000062c09c05a2b60798 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1715582acc4c1ce7aee1> X-Attachment-Id: 1715582acc4c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDA3 VDE0MjEzNFoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMDUwNFQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMDUwNFQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW02NGQ3ZjAwNDUzODAxMzNlN2RmOTQ4NWQzZTE1OWEyOA0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTU4NjI2OTI5NA0KVUlEOjM4MjA2NWVmLWRlMDMtNGQ3NC1iNzg3LTg5N2Uy ZjZlZjZjMA0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW02NGQ3ZjAwNDUzODAxMzNlN2RmOTQ4NWQz ZTE1OWEyOFxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjEzIDcwNCA3MzhcblxuXG5N ZWV0aW5nIHBhc3N3b3JkOiB0cEdiak5YajY1MlxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUgdG8gY2Fs bCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjEzNzA0NzM4JTIzJTIzKjAxKlxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTM3MDQ3MzglMjMlMjMqMDEqXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bWYxNmUxMDQ5Yzk4Yjc1 MTFhNGMyNzQ4ODIxNjA2NGQxXG5cblRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uc1xuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2MTM3MDQ3MzhA aWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjYxMzcwNDczOC5pZXRmQGx5bmMu d2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJv cmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4N ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbiog e1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjEzIDcwNCA3Mzg8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+dHBHYmpOWGo2NTI8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5c bgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3 aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0Mjsg Ym9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDox NjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIg c3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTY0ZDdmMDA0NTM4MDEzM2U3ZGY5NDg1ZDNlMTU5YTI4IiBzdHls ZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwv dGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAw MDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBG QUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxMzcwNDczOCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTM3MDQ3MzglMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS04NzctNjY4LTQ0OTM8L2E+PC9iPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW1mMTZlMTA0OWM5OGI3NTExYTRjMjc0ODgyMTYwNjRkMSIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkds b2JhbCBjYWxsLWluIG51bWJlcnM8L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPlRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lw OjYxMzcwNDczOEBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj42MTM3MDQ3MzhAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFs c28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05U PiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdo dDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBl IGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjEzNzA0NzM4LmlldGZAbHlu Yy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjki PjYxMzcwNDczOC5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4J CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8 L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIC0gTWF5IDR0aA0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpFTkQ6VkVWRU5U DQpFTkQ6VkNBTEVOREFSDQo= --00000000000062c09c05a2b60798-- From nobody Tue Apr 7 09:40:28 2020 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 9755E3A12F6 for ; Tue, 7 Apr 2020 09:40:20 -0700 (PDT) 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 Nw-5CcejUrMN for ; Tue, 7 Apr 2020 09:40:15 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 35DCC3A1029 for ; Tue, 7 Apr 2020 09:39:52 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id i3so3987712ioo.13 for ; Tue, 07 Apr 2020 09:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1z8AZvIPEyi8iTIJMD6WOnb+7LdYym49Dx/fKpRLtQk=; b=ZvSLNu0CyGUrYieePfdq6WPTQ7H77MICUlg2J3gOeLke550VIg+zzsVd3jfX+Qa4k9 WBdazalmhwYVkrX9Sr60KAY4IS2c/R4xrZq2tFKlWJmU9N4qxbQ7OyPHVZxOkKoIZe2P TfCTNzi+HfDp5Xqi0UM3O2V42beQky2JAF5kFc1v3aE6GDefUn9p449S7OrF6x6N/XXe EGHP2KVBlcipsiUeIMef4oUlgw6y3u8GS8bBosoHctG96C6FJOuGu/N0eMFBN7MgqHBU OQb8NKczUD5i6PaBg7GO+NUd2lcpb2wP35TqDA27stQRuScN86x7RLiCQLMLiARhoJMZ gwQg== 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=1z8AZvIPEyi8iTIJMD6WOnb+7LdYym49Dx/fKpRLtQk=; b=HlWnGyQ8XY1Kc5bm2jl21yyd0oYfgFrDvqrg6D+biKyc/fsaaF9gXvl7jC17aaAy4O 2WK6xHsB9kb/kWkDkNmodejfzm/QAHacb6cmuXd9OkETm085q6ZUm+sp+ukezW0+KTD5 oqHvHxdbU1uzd9hEb52chDJn5TYGOgOnesJfOkRk9LZUXKiWD4pdgWlbNOo8kOgJTXkF 3MvSMFijDKcRg0UAr5umAs6jrgj7VC6E8HABqg4pICTJLlbqqhUMyncTu8KXlbFrnLVR EUGpBA8WmFq9Hd/dOkqOiGqO6YCERbRTlwgcTDBp3zj3EesLUMo7u19wLxk+M+PM0Ks1 iBKA== X-Gm-Message-State: AGi0Pua4Q5JzTZ9NQqpu/5DDaDAV3W2zi2MmSRrer2Ciaz47hKmeAB9M K0vH8sjWKMrcwjim+5g4ie3bxpYNYUn7UQ1KKZ3caQ== X-Google-Smtp-Source: APiQypJlbTzZi4EcQ0Nc1azQHLmleLMqWgxCafPJcT323vLj2y57fcL8zo9glqwZbATL4hoZ0VuqXJ+cCg3flRS6Jpk= X-Received: by 2002:a02:5249:: with SMTP id d70mr2850646jab.121.1586277590697; Tue, 07 Apr 2020 09:39:50 -0700 (PDT) MIME-Version: 1.0 References: <1641230492.9961261586269362020.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <1641230492.9961261586269362020.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Tue, 7 Apr 2020 12:39:39 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000004f7ffe05a2b60805" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - May 11th 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, 07 Apr 2020 16:40:26 -0000 --0000000000004f7ffe05a2b60805 Content-Type: multipart/alternative; boundary="0000000000004f7ffb05a2b60803" --0000000000004f7ffb05a2b60803 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Tue, Apr 7, 2020 at 10:22 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Interim Meeting - May 11th To: You can forward this invitation to others. Web Authorization Protocol Working Group invites you to join this Webex meeting. Meeting number (access code): 614 129 530 Meeting password: bP7yd9wNR3u Monday, May 11, 2020 12:00 pm | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Join meeting *Join by phone* Tap to call in from a mobile device (attendees only) 1-650-479-3208 <%2B1-650-479-3208,,*01*614129530%23%23*01*> Call-in toll number (US/Canada) 1-877-668-4493 <1-877-668-4493,,*01*614129530%23%23*01*> Call-in toll free number (US/Canada) Global call-in numbers | Toll-free calling restrictions *Join from a video system or application* Dial 614129530@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 614129530.ietf@lync.webex.com Need help? Go to http://help.webex.com --0000000000004f7ffb05a2b60803 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro= up <m= essenger@webex.com>
Date: Tue, Apr 7, 2020 at 10:22 AM
= Subject: (Forward to others) Webex meeting invitation: OAuth WG Virtual Int= erim Meeting - May 11th
To: <oauth-chairs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group invites you to joi= n this Webex meeting.
=C2= =A0
Meeting number (access code): 614 129 530
Meeting password: bP7yd9wNR3u
=20
=C2= =A0
Monday, May 11, 2020
12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=20
=C2=A0
Join meeting
= =C2=A0
Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0= |=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0
Join from a video system or appli= cation
Dial 614129530@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu= mber.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 614129530.ietf@lync.webex.com
=C2=A0
Need help? Go to http://help.webe= x.com
=C2=A0
--0000000000004f7ffb05a2b60803 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20200407T142241Z ATTENDEE;CN=3D"Web Authorization Protocol Working Group";ROLE=3DREQ-PARTICI= PANT;RSVP=3DTRUE:MAILTO:oauth-chairs@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20200511T120000 DTEND;TZID=3DAmerica/New_York:20200511T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm0ac0dd18a603ddeb755019f0= 060bffe1 TRANSP:OPAQUE SEQUENCE:1586269361 UID:65a10b11-7b94-4f68-be15-eb12be22eb9d DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M= TID=3Dm0ac0dd18a603ddeb755019f0060bffe1\nMeeting number (access code): 614 = 129 530\n\n\nMeeting password: bP7yd9wNR3u\n\n\n\nJOIN BY PHONE\n1-650-479-= 3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only,= hosts not supported): tel:%2B1-650-479-3208,,*01*614129530%23%23*01*\n1-87= 7-668-4493 Call-in toll free number (US/Canada)\nTap here to call (mobile p= hones only, hosts not supported): tel:1-877-668-4493,,*01*614129530%23%23*0= 1*\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?= MTID=3Dmc3c37a63532bbd0c3b22da4a9063688f\n\nToll-free calling restrictions\= nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO= SYSTEM OR APPLICATION\nDial sip:614129530@ietf.webex.com\nYou can also dia= l 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lyn= c or Microsoft Skype for Business\nDial sip:614129530.ietf@lync.webex.com\n= \n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/= WBX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all= ows audio and other information sent during the session to be recorded, whi= ch may be discoverable in a legal matter. By joining this session, you auto= matically consent to such recordings. If you do not consent to being record= ed, discuss your concerns with the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n =
&= nbsp;
\n \n\n\n\n\n\n \n \n \n \n \n \n \n \n
\n When it's time, join the We= bex meeting here.\n
 
\= n Meeting number (ac= cess code): 614 129 530\n
\n \n =
Meeting p= assword:= bP7yd9wNR3u
\n\n \n \n = \n \n
 
\n \n \n \n \n
Join meeting
\n \n
\n\n \n 
&nbs= p;
\n\n 
Join by phone  
1-650-479-3208<= /b> Call-in toll number (US/Canada)  
1-877-668-4493 Call-in toll= free number (US/Canada)  
Global call-in numbers  | &nbs= p;Toll-free calling restri= ctions 


\n\n
 
\n\nJoin from= a video system or application
Dial 614129530@ietf.webex.com=  
You can al= so dial 173.243.2.68 and enter your meeting number.  
 
\n\n
Join using Microsoft Lync or Microsoft Skype for Bus= iness
Dial 614129530.ietf@lync.webex.com
\n\n \n \n \n \n = \n \n \n \n \n
 
Need help? Go to http://help.webex.com\n
 
\n SUMMARY:OAuth WG Virtual Interim Meeting - May 11th PRIORITY:5 CLASS:PUBLIC END:VEVENT END:VCALENDAR --0000000000004f7ffb05a2b60803-- --0000000000004f7ffe05a2b60805 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <1715582e84bc1ce7aee1> X-Attachment-Id: 1715582e84bc1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDA3 VDE0MjI0MVoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRoLWNoYWly c0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIjpNQUlMVE86b2F1dGgtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9QW1l cmljYS9OZXdfWW9yazoyMDIwMDUxMVQxMjAwMDANCkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9y azoyMDIwMDUxMVQxMzAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW0wYWMwZGQxOGE2MDNkZGViNzU1MDE5ZjAwNjBiZmZlMQ0KVFJBTlNQOk9QQVFV RQ0KU0VRVUVOQ0U6MTU4NjI2OTM2MQ0KVUlEOjY1YTEwYjExLTdiOTQtNGY2OC1iZTE1LWViMTJi ZTIyZWI5ZA0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0wYWMwZGQxOGE2MDNkZGViNzU1MDE5ZjAw NjBiZmZlMVxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjE0IDEyOSA1MzBcblxuXG5N ZWV0aW5nIHBhc3N3b3JkOiBiUDd5ZDl3TlIzdVxuXG5cblxuSk9JTiBCWSBQSE9ORVxuMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuVGFwIGhlcmUgdG8gY2Fs bCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUw LTQ3OS0zMjA4LCwqMDEqNjE0MTI5NTMwJTIzJTIzKjAxKlxuMS04NzctNjY4LTQ0OTMgQ2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTQxMjk1MzAlMjMlMjMqMDEqXG5cbkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bWMzYzM3YTYzNTMyYmJk MGMzYjIyZGE0YTkwNjM2ODhmXG5cblRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uc1xuaHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuSk9J TiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDo2MTQxMjk1MzBA aWV0Zi53ZWJleC5jb21cbllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIg eW91ciBtZWV0aW5nIG51bWJlci5cblxuXG5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3NcbkRpYWwgc2lwOjYxNDEyOTUzMC5pZXRmQGx5bmMu d2ViZXguY29tXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJv cmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4N ClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbiog e1xuICAgIHBhZGRpbmc6IDA7ICAgIG1hcmdpbjogMDt9XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxh cHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7 fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAx NHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1z aXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31c blxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVl biBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXpl OiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEw MCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7 XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRc bgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRp bmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5c bgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4J CTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJ CTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDog MTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249Imxl ZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxp Z249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxu XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpF PSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJ PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjE0IDEyOSA1MzA8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+ XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YlA3eWQ5d05SM3U8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5c bgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxuCQkJCQk8 dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJ3 aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQzQTk0Mjsg Ym9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13aWR0aDox NjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNlbnRlciIg c3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTBhYzBkZDE4YTYwM2RkZWI3NTUwMTlmMDA2MGJmZmUxIiBzdHls ZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxuCQkJCTwv dGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAw MDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpFPSIxIiBG QUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00 NzktMzIwOCwsKjAxKjYxNDEyOTUzMCUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAg dGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7 bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6MS04NzctNjY4LTQ0OTMsLCow MSo2MTQxMjk1MzAlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS04NzctNjY4LTQ0OTM8L2E+PC9iPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xv YmFsY2FsbGluLnBocD9NVElEPW1jM2MzN2E2MzUzMmJiZDBjM2IyMmRhNGE5MDYzNjg4ZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkds b2JhbCBjYWxsLWluIG51bWJlcnM8L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPlRv bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNF PSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2lu IGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lw OjYxNDEyOTUzMEBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj42MTQxMjk1MzBAaWV0Zi53ZWJleC5jb208L0ZPTlQ+PC9hPiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Zb3UgY2FuIGFs c28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC9GT05U PiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJSPlxuXG48dGFibGUgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdo dDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBl IGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5 bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6NjE0MTI5NTMwLmlldGZAbHlu Yy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjki PjYxNDEyOTUzMC5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4J CQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAw MDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0 cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5 bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2Vi ZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0 eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8 L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOk9BdXRoIFdHIFZpcnR1YWwgSW50ZXJp bSBNZWV0aW5nIC0gTWF5IDExdGgNClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0KRU5EOlZFVkVO VA0KRU5EOlZDQUxFTkRBUg0K --0000000000004f7ffe05a2b60805-- From nobody Tue Apr 7 10:52:38 2020 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 438F83A0B15; Tue, 7 Apr 2020 10:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158628195716.9275.10690808358259357603@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:52:37 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13 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, 07 Apr 2020 17:52:37 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: 1. Nested JWT https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt 2. JWT Profile for Access Tokens https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0 From nobody Tue Apr 7 10:53:00 2020 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 8D6B53A0C16; Tue, 7 Apr 2020 10:52:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158628197554.14474.15774407124067121648@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:52:55 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-20 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, 07 Apr 2020 17:53:00 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-04-20 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: 1. Pushed Authorization Requests https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ 2. Rich Authorization Requests https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=ma2406d0d665d68cf51297c0544e429bf From nobody Tue Apr 7 10:53:15 2020 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 817BA3A0D13; Tue, 7 Apr 2020 10:53:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158628198850.16776.4589163530948810762@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:53:08 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-27 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, 07 Apr 2020 17:53:13 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-04-27 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: 1. The OAuth 2.1 Authorization Framework https://datatracker.ietf.org/doc/draft-parecki-oauth-v2-1/ 2. JWT Response for OAuth Token Introspection https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mec2af7ee3fbb8c161501b6294c762114 From nobody Tue Apr 7 10:53:26 2020 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 264A23A0DCC; Tue, 7 Apr 2020 10:53:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158628199814.9275.16272770722309920962@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:53:18 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-04 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, 07 Apr 2020 17:53:22 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-05-04 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: 1. Demonstration of Proof-of-Possession at the Application Layer https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ 2. Incremental Authorization https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m64d7f0045380133e7df9485d3e159a28 From nobody Tue Apr 7 10:53:42 2020 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 2DB4A3A0C86; Tue, 7 Apr 2020 10:53:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158628200993.31608.8262593721643752978@ietfa.amsl.com> Date: Tue, 07 Apr 2020 10:53:29 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-11 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, 07 Apr 2020 17:53:38 -0000 The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-05-11 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: 1. Client Intermediary Metadata https://tools.ietf.org/html/draft-parecki-oauth-client-intermediary-metadata-00 2. Reciprocal OAuth https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-04 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m0ac0dd18a603ddeb755019f0060bffe1 From nobody Tue Apr 7 14:31:41 2020 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 517343A00D3 for ; Tue, 7 Apr 2020 14:31:39 -0700 (PDT) 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=pingidentity.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 G4qnfsTomMhK for ; Tue, 7 Apr 2020 14:31:38 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 BBEC73A00D2 for ; Tue, 7 Apr 2020 14:31:37 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id x23so3560267lfq.1 for ; Tue, 07 Apr 2020 14:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/njkQzYEMhjEivADldNPIkvLgf5nSxYnyPFlLllxrhk=; b=XlLoGxjLPfY/IyDYhnE7MX/RO2CN6s2T31UaZX5B3kF+pTyFeNRP1O2we/6GzmsGm8 vqFC0F8MNiCBmCcUjCXQvkHXEqmAk/HPMzZxzcm9bMewe994O0YMnWqx3hB3h3jSI6Md m8C42Hm5ntQ12Loc4IpAeWVpWP5VbZq4aicx9pbtCQYv8baiuwoUqLkKZGLEPZHzST9H 1nt8kGIOqlh4ltfOINKCcYo8ev6QzizsihDISiFvaev8cSMRKblWAWpfIU/6lZx7GLzw lR82/GA8e2/N3oUr36GOc29WumMIOwPPt689WOYo8gZBUyZevUxqK7LKKbbffqfa1omV HQyw== 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=/njkQzYEMhjEivADldNPIkvLgf5nSxYnyPFlLllxrhk=; b=RPEZ6jUOnLsgCVjvftCQvU4yDGwr5+qd7Tsx7tVyRmWfk4uaDNYXw3vTMYcyB+I/ab rp5oAIM5QUxYhntdXNTWbxWGG2w8wm3hH9HSSosXs+OY89HBGM+FaIlvRD0phlIQbIRs 9bBFRMXYivdMbKo+S5NZb+rPm26y7HuJE1nIV8jRXQYLpe1bDYJZ5Xm50RUSYU/ADGbt ceo5gjVAs32w4edkQvBT0Xj2jz0N7DTxeovLb4vLaUcE5dpnjZrL4N5AAmCmoOqNjqb6 hwxziKDTlPk5QBWuqVjIqPoYDAoTXHxmPz2AxyLYRZb1wOcU6zeb9LLEo4k5GN9N0oHY B9Jg== X-Gm-Message-State: AGi0PubVvPMAAEEwT37cp+vwikOijCM7jb7nmbTJLn1j9b1iaGnzprNL 9jmkjNaODjtr4YSkT0/Vx0FZ79He6SXbIklaWVhrVSYicTakR3xaDtnwn7gjZn2qIoKUFfjjxA5 Z0ZDB+vSHHWFguQ== X-Google-Smtp-Source: APiQypIB95R2Ua7sylTcT4ZMoI7Gm3zot1aioLobMEfgLvZw1TfmK4/M2t7zG6fbkisKfWH/OLgVaS3Nouw3BIM+rwc= X-Received: by 2002:a05:6512:d1:: with SMTP id c17mr2639838lfp.167.1586295095789; Tue, 07 Apr 2020 14:31:35 -0700 (PDT) MIME-Version: 1.0 References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> <20200407035422.GG88064@kduck.mit.edu> In-Reply-To: <20200407035422.GG88064@kduck.mit.edu> From: Brian Campbell Date: Tue, 7 Apr 2020 15:31:09 -0600 Message-ID: To: Benjamin Kaduk Cc: "Peck, Michael A" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1a27c05a2ba1b49" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 07 Apr 2020 21:31:40 -0000 --000000000000b1a27c05a2ba1b49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One of the primary motivations for the proof-of-possession mechanism of DPoP being at the application layer was to hopefully enable implementation and deployment by regular application developers. A lesson learned from the difficulties and lack of adoption around Token Binding was that access to TLS exporters is non-existent or prohibitively cumbersome in many development environments. Browsers, for example, don't expose any such API to javascript. And that's a non-starter here. Are there other practical ways to include a server contribution that have been overlooked? On Mon, Apr 6, 2020 at 9:54 PM Benjamin Kaduk wrote: > > There should be plenty of ways to include a server contribution into the > DPoP proof (e.g., a TLS exporter value). > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000b1a27c05a2ba1b49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the primary motivations for the proof-of-poss= ession mechanism of DPoP being at the application layer was to hopefully en= able implementation and deployment by regular application developers. A les= son learned from the difficulties and lack of adoption around Token Binding= was that access to TLS exporters is non-existent or prohibitively cumbers= ome in many development environments. Browsers, for example, don't expo= se any such API to javascript. And that's a non-starter here.

Are there other practical ways to include a server contribu= tion that have been overlooked?=C2=A0

=
On Mon, Apr 6, 2020 at 9:54 PM Benjam= in Kaduk <kaduk@mit.edu> wrote:<= br>

There should be plenty of ways to include a server contribution into the DPoP proof (e.g., a TLS exporter value).


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000b1a27c05a2ba1b49-- From nobody Tue Apr 7 21:51:27 2020 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 718613A0C20 for ; Tue, 7 Apr 2020 21:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 3TfYXWzmTXk7 for ; Tue, 7 Apr 2020 21:51:23 -0700 (PDT) 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 4ED6C3A0C1C for ; Tue, 7 Apr 2020 21:51:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0384pJqg017263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 00:51:21 -0400 Date: Tue, 7 Apr 2020 21:51:18 -0700 From: Benjamin Kaduk To: Brian Campbell Cc: "Peck, Michael A" , "oauth@ietf.org" Message-ID: <20200408045118.GP88064@kduck.mit.edu> References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> <20200407035422.GG88064@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments 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, 08 Apr 2020 04:51:26 -0000 On Tue, Apr 07, 2020 at 03:31:09PM -0600, Brian Campbell wrote: > One of the primary motivations for the proof-of-possession mechanism of > DPoP being at the application layer was to hopefully enable implementation > and deployment by regular application developers. A lesson learned from the > difficulties and lack of adoption around Token Binding was that access to > TLS exporters is non-existent or prohibitively cumbersome in many > development environments. Browsers, for example, don't expose any such API > to javascript. And that's a non-starter here. > > Are there other practical ways to include a server contribution that have > been overlooked? the main thing that comes to mind is (basically) an explicti nonce, which costs an extra round trip unless you get clever. In particular, "get clever" can be something that amortizes a single extra round trip across *all* interactions with that server, akin to how ACME requires a fresh nonce (and signature) for each request (RFC 8555). -Ben From nobody Wed Apr 8 02:10:53 2020 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 77CE83A0ECC for ; Wed, 8 Apr 2020 02:10:50 -0700 (PDT) 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 wryD8IaLLjQ7 for ; Wed, 8 Apr 2020 02:10:49 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 F14AD3A0EC9 for ; Wed, 8 Apr 2020 02:10:48 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id i19so4406065ioh.12 for ; Wed, 08 Apr 2020 02:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vGfmJE7h6GIfL0g8yDgOElzkmBaeRrRQM4zPJJiuZCU=; b=JR6xhPc733b1UiFt2ur75tetrA5WqfyLOIFIkh2bIhlFu3BE/C1z7E4iu/YiDEVo6d uIfMXcZ28RNmf6SbWoMk/Qqjfsf2gqMBNA/f8P6Qp26V8686u9OX4dddjG4DRqeC3GCo fP4456c/8uwdURd8wsazIPNrMC8J3dW1G6aNFjuGCZ7z8wThuHSMWZbhDKi5OtlpGmRj 6ZtXKsmDEwxrP7WlejnHiZewPDLQtZsfiqKibWgpvlFRPc5iOBQKbGYrv9Yq5PWM+Mt7 DM8FPuRoZQnocstqNlpkFI0kjn0FWQ5CPmu+EXKC3Mn9T/shU4vYsAq9P5jYSFXQONSA RR9w== 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=vGfmJE7h6GIfL0g8yDgOElzkmBaeRrRQM4zPJJiuZCU=; b=U22yEqewim84sgfNEEwyt489Am1lgCFobOqoOZpNmPDogkraN+2JstmKaFMNkFhx2Y Y6vf58vLj60DNKVcBDVpgoW5yNr088dSXbeYf48oczUHMzBdI4Fh0kHgKdGLsVNuFfKy R6/3Sv0xTvt7SshagkBOfTYANDajnzfUJ+Hnd1x1e8v15wSYJBJQIK0VGEc0oz5YUe7X wP243zSwVfH4kaqwzVrhS8yDd/qzg/IfrRZ+3uofa35rOs344qLWAgvPsr3Sa0zla58+ iEa3G3NhX9q0+0dWA14NExRzz/I7QEN9wl9GG7hD6NHptzpJCISCJbTTRyN5rB7SFOFO neAA== X-Gm-Message-State: AGi0PuY3F6qTUQKq97a+dvxMBZS+h5k8a28jeyNxvkvUFG+zDwtlgeo6 6ab2e4ZsBl8SgJn6QlKsIzxVQGQinnp7jkoRqecL00Mo X-Google-Smtp-Source: APiQypI2S4bnUynMGTHzh08stp/yuz+XsT4gvrfF+Y1n/Q7Nk5CsBUie36QfizgBSx5x0RtTOnAV2R/e/DhFfX74rXA= X-Received: by 2002:a02:290f:: with SMTP id p15mr5993758jap.73.1586337047907; Wed, 08 Apr 2020 02:10:47 -0700 (PDT) MIME-Version: 1.0 References: <158583623802.26510.6501784119483278282@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 8 Apr 2020 05:10:36 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000003c120405a2c3e095" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-06 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, 08 Apr 2020 09:10:51 -0000 --0000000000003c120405a2c3e095 Content-Type: text/plain; charset="UTF-8" You can find the minutes of the meeting on the link below: https://datatracker.ietf.org/meeting/interim-2020-oauth-03/materials/minutes-interim-2020-oauth-03-202004061800 Thanks to *Jared Jennings* for taking these notes. Regards, Rifaat On Sun, Apr 5, 2020 at 5:47 PM Rifaat Shekh-Yusef wrote: > All, > > You can find the slides for tomorrow's meeting at the following link: > https://datatracker.ietf.org/meeting/interim-2020-oauth-03/session/oauth > > Regards, > Rifaat > > > On Thu, Apr 2, 2020 at 10:06 AM IESG Secretary > wrote: > >> The Web Authorization Protocol (oauth) Working Group will hold >> a virtual interim meeting on 2020-04-06 from 18:00 to 19:00 Europe/Vienna >> (16:00 to 17:00 UTC). >> >> Agenda: >> Two documents: >> >> 1) OAuth Security Topics >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 >> 2) Browser-Based Apps >> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 >> >> >> Information about remote participation: >> https://ietf.webex.com/ietf/j.php?MTID=m7e39bc19240468eafc9b00a0ebc673b0 >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > --0000000000003c120405a2c3e095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can find the minutes of the meeting on the=C2=A0link b= elow:

Thanks to=C2=A0J= ared Jennings for taking these notes.

Rega= rds,
=C2=A0Rifaat


On Sun, Apr 5, 2020 at = 5:47 PM Rifaat Shekh-Yusef <rif= aat.ietf@gmail.com> wrote:
All,

You can find the= slides for tomorrow's meeting at the following link:

Regards,
= =C2=A0Rifaat
=C2=A0

On Thu, Apr 2, 2020 at 10:06 AM IESG= Secretary <iesg-secretary@ietf.org> wrote:
The Web Authorization Protocol (oauth) Working Grou= p will hold
a virtual interim meeting on 2020-04-06 from 18:00 to 19:00 Europe/Vienna (= 16:00 to 17:00 UTC).

Agenda:
Two documents:

1) OAuth Security Topics
https://tools.ietf.org/html/draft-iet= f-oauth-security-topics-14
2) Browser-Based Apps
https://tools.ietf.org/html/draft-= ietf-oauth-browser-based-apps-05


Information about remote participation:
https://ietf.webex.com/iet= f/j.php?MTID=3Dm7e39bc19240468eafc9b00a0ebc673b0

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--0000000000003c120405a2c3e095-- From nobody Wed Apr 8 14:59:20 2020 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 D70983A185B for ; Wed, 8 Apr 2020 14:59:17 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.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 twZvKwYd2S08 for ; Wed, 8 Apr 2020 14:59:15 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DA4E73A185F for ; Wed, 8 Apr 2020 14:59:14 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id r24so9365645ljd.4 for ; Wed, 08 Apr 2020 14:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=pvfeR3T4V06XDgGHiOutRuEVMSKICE2Gqb+FNYi1VIM=; b=duisv2YdVWZs5kzVQNHZMO+rf44zKjwRI4HSmCaChyYXHCSzXPFHuz8lYf4bAHkzT0 6dD2saM6spyZPN9TTYJyfHev5TAF11rmSQLomWRU11KpjsFpDRl7G1ImZH5XxeIs46N4 IRzhRMuZshYeS5Q5PDYAWiA8ca+nOx6vn2Op4= 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:cc; bh=pvfeR3T4V06XDgGHiOutRuEVMSKICE2Gqb+FNYi1VIM=; b=F8DygMamw27Y6mcMurIzOo2FRNxsDH/7MEmFw1JZOk9fqYRqBoU02nnF1cJVeNA9OA c4TzJ9Eh8ZK3ujz0ikm483sDq0ct0plE0Gcl0Ern7sm4eU1M3Eab9vKnJISTmXr/WW/S 2lu0nyB9li9Jazx71T2w8pAhMQmggRok5gLgdwzG2nkl0MQrOYH8EKZc/hP0UPIm8qa2 jvF1yCYZAm1giYN2CZIYaEJhDIrM9XV8JYPcTDr/qEIMjTcgl6zGYEVqEEgL5etXG170 UnjYamoyQ7jXMsk8T9w6qg4v7WL6wD0tn4EabhQMqJYKYvsXc2GBV8e0M7A3S8qQFzsj uuYQ== X-Gm-Message-State: AGi0PuZklvb2Wz3d2RAQRVf19QDUFk6XMzA33s/lXHylgLgjEB8pKXh0 soaHrqZT68KXLEJapXBC0dp+O6bQNKVU+wwuSYS2QQj8tEvu1w== X-Google-Smtp-Source: APiQypK/Mi8qNIZzYWRzosW1ZG5KMlQM0WWCE3zPeprUgXjynoMpd7GZMtFyjAIC766qhs3/s8xExsnWCrzIzYcZpgA= X-Received: by 2002:a05:651c:113:: with SMTP id a19mr6173785ljb.167.1586383152759; Wed, 08 Apr 2020 14:59:12 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Wed, 8 Apr 2020 17:59:01 -0400 Message-ID: To: oauth@ietf.org Cc: draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c550805a2ce9c52" Archived-At: Subject: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 08 Apr 2020 21:59:19 -0000 --0000000000004c550805a2ce9c52 Content-Type: text/plain; charset="UTF-8" As a replacement of RFC 6749 I am missing a "Direct Grant" with the same simplicity as the "Resource Owner Password Credentials" grant of RFC 6749. The reason is that browser redirects are too complex and most of the time badly implemented by small teams. For the sake of having SMEs use oAuth 2.1 with their limited development capacities, I suggest keeping the simple "Resource Owner Password Credentials" with an OTP replacing the permanent password. We also have sample implementations working on the market with OTP based "Resource Owner Password Credentials" with full compatibility to RFC 6749. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --0000000000004c550805a2ce9c52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a replacement of=C2=A0RFC 6749 I am missing a "Direct Grant" wit= h the same simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.=

The reason is that browser redirects are=C2= =A0too complex and most of the time badly implemented by small teams. For t= he sake of having SMEs use oAuth 2.1 with their limited development capacit= ies, I suggest keeping the simple=C2=A0"Resource Owner Password Credentials" with an OTP replacing the permanent pa= ssword.

We also have sample implementations working on the market with OTP ba= sed "Resource Owner Pass= word Credentials" with full compatibility to RFC 6749.

--=C2= =A0
Francis Pouatcha
Co-Founder and Technical Lead at adorys
=
--0000000000004c550805a2ce9c52-- From nobody Wed Apr 8 15:01:22 2020 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 C4F9E3A1866 for ; Wed, 8 Apr 2020 15:01:19 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.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 cyg7By2-vetw for ; Wed, 8 Apr 2020 15:01:17 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AE33A1860 for ; Wed, 8 Apr 2020 15:01:17 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id j17so6359171lfe.7 for ; Wed, 08 Apr 2020 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=beQExBkz+RNMxK5LetOkWXDEMHZyeL7o5FaqqurKyXw=; b=fwuwmhR/YPd3cZ3A0zy/hwZTCAcDi0QeUQtOvhlYbMCn6hp4N5Xg6qHDZVhm4P+zcA jIybd1r0sSqj2A/nidsxvonwL8Kbofi26OwwkkhZWaSQ7Om5pkXuw4pGd1arOMUsKF+/ pbhzmafbizaunhJpA3YaUk5xo/IPvjnr6vbv0= 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:cc; bh=beQExBkz+RNMxK5LetOkWXDEMHZyeL7o5FaqqurKyXw=; b=ZnEu8m4vskKvtp7R1tX++GGBIwYzsFT12/AvIuczaEs9zA9U/8XDs7vf3z6UJzNGrO zVs8ISh5Yz9ev5Gd0a113xFTa7jJHnNtNbHNe4t2UoJf4i+Dtp6/7F/C+r5AzUerNrlU PJzjBfW4rCOAPZ/44PiP6ua6asPrIx2hfW+j3DN/GNyZP76sfjMkdH3b0eTK0Vg1JrZW p/NDwKvzBHfU7J0WJcNTolfom1jxVQ4Lwk+96DkqmhW2kTNnkXj38Dq0KrPXZCxKi9SV BtJnNvbRvO+LaH7s9kz9HwWEbtLGIKs51ldyCwhV2x8n/XyA2dGLMuZnpcKoHjzLxGQE EKNw== X-Gm-Message-State: AGi0PuaY+ZF0y5iY4g5RLdh65/oqeYYaI21Oi1vohEIEoHei+pPS7BOv iFFaYGmsoAoNk8ajfWMDIoaEiHkt0KtuyZ1Jp9GME2f7nryROA== X-Google-Smtp-Source: APiQypIXwgbYZEt3Pqgvn35ZsSzmV31SwUPk6Y6ian3zekg+htIRy+TPtdaVuiLLldDEjDNOR2Fk2JMuuenzSRqWbxI= X-Received: by 2002:a05:6512:308e:: with SMTP id z14mr5930290lfd.110.1586383275306; Wed, 08 Apr 2020 15:01:15 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Wed, 8 Apr 2020 18:01:04 -0400 Message-ID: To: oauth@ietf.org Cc: draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a4cba05a2cea30a" Archived-At: Subject: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint 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, 08 Apr 2020 22:01:20 -0000 --0000000000009a4cba05a2cea30a Content-Type: text/plain; charset="UTF-8" There is a lot of effort associated with the handling and correct validation of a redirect_uri sent to the AS as part of the front channel authorization request, as this gets transported by user agents. The draft-parecki-oauth-v2-1 as a replacement of RFC 6749 must make sure redirect_uri is only sent to the AS through the back channel. This of course requires the implementation of a new "authorization request initiation endpoint". The draft-ietf-oauth-par-01 provides a guidance on how to design this initiation endpoint. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --0000000000009a4cba05a2cea30a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a lot of effort associated with the handling an= d correct validation of a redirect_uri sent to the AS as part of the front = channel authorization=C2=A0request, as this gets transported by user agents= .

The=C2=A0draft-parecki-oauth-v2-1 as a replaceme= nt of RFC 6749 must make sure redirect_uri is only sent to the AS through t= he back channel. This of course requires the implementation of a new "= authorization request = initiation endpoint". The=C2=A0draft-ietf-oauth-par-01 provides= a guidance on how to design this initiation endpoint.

= --=C2=A0
Francis Pouatcha
C= o-Founder and Technical Lead at adorys
--0000000000009a4cba05a2cea30a-- From nobody Wed Apr 8 15:03:31 2020 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 9A61F3A1869 for ; Wed, 8 Apr 2020 15:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ym3ugFYHeXI for ; Wed, 8 Apr 2020 15:03:28 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 0FC7E3A186A for ; Wed, 8 Apr 2020 15:03:27 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id i75so8272325ild.13 for ; Wed, 08 Apr 2020 15:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QeWDMAOolvQyeLnElLeTuJz+XzhggI7ANeyhfeJYu2Q=; b=M1nF7MTnl/r/1Hdy6H+VtTWhQFOOrOGv6bgJAAB3hR+dE1Q5h7veMDOO+2bH+M5Si+ ewm8r01WZZIGil/jLZB1zTsSmcs5ridj6G9rcubC7uMui55/YB90JfQE3H/aOCKYU8Ii UuRI8yfU82283nEcURclxUezFVF3LEzLYowR72M4tykaebG09VM3txtBMK33kgqAHoiB IF6EKM/HGW+5RKyy95fxgGep9hmiVVQAUz9n8QgXT+TtmNflL8vvegaPnVGDk3LgsF33 1x12NNF+g24Bs6wwPdrb8/vJvYIpxM9qpUOJkQ5kAqFnPXR/ovcCZlEQpvW8oy1Ej8SF AzkQ== 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=QeWDMAOolvQyeLnElLeTuJz+XzhggI7ANeyhfeJYu2Q=; b=TKTMZVXlxkVBr+ehX9fIs/RmexAPDZcGM1eKmIr2dUI32MVDi7XB4NLDerD+MyHrt5 BvWRumnNaZN7RrEOuFvAdt9jKKiglgrmR8j5Nme2BUCAEpOJGpCZ6pKg1SwI82h/STmW yko/iezABwOUCqeie34OuNGw7+tt4cFE/wjNu93JWa2IdUVIkIWVA2ElOWJB24tuEmEp 2kGJsUALV5jeIUJWfY+JtIRNe23Ojvu1fU9ipXeOtrDHy1HPvimzoyS/4UmDXzNA36R7 WpTHyIsD8gtZcXZ2XhQhlAVlNEJlzDOlyU+TpX70n9C8Bd3Dmq1DQvMxYjb1bccfndST oPtQ== X-Gm-Message-State: AGi0Pua00OO2meJhtwnjfIAOrWXWWmQhVrHxGOR8VSIosdwofLUEbXIS idE+pbSVWnxuo5QTSpnv+SP0ir6kR4k= X-Google-Smtp-Source: APiQypLMmP6SSfrg5KRZrKo9yZ3c9acrYAygidHW9eb1S+f43IvkXCsek5XWhIjWgExEqEKK6kOVjQ== X-Received: by 2002:a92:8499:: with SMTP id y25mr2139839ilk.268.1586383406765; Wed, 08 Apr 2020 15:03:26 -0700 (PDT) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id h12sm8516253ilq.66.2020.04.08.15.03.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 15:03:25 -0700 (PDT) Received: by mail-il1-f171.google.com with SMTP id n13so8358536ilm.5; Wed, 08 Apr 2020 15:03:25 -0700 (PDT) X-Received: by 2002:a92:d083:: with SMTP id h3mr10233560ilh.28.1586383405446; Wed, 08 Apr 2020 15:03:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 8 Apr 2020 15:03:12 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Francis Pouatcha Cc: OAuth WG , draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="0000000000005bffba05a2ceabb2" Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 08 Apr 2020 22:03:30 -0000 --0000000000005bffba05a2ceabb2 Content-Type: text/plain; charset="UTF-8" Hi Francis, The Resource Owner Password Credentials grant is being deprecated in the OAuth 2.0 Security BCP: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4 > The resource owner password credentials grant MUST NOT be used. As this OAuth 2.1 draft is meant to consolidate the best practices across the existing OAuth 2.0 documents, and is explicitly not intended to define any new behavior that is not already in an adopted document, we can't accept your suggestion of adding a new OTP-based grant in this document. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha wrote: > As a replacement of RFC 6749 I am missing a "Direct Grant" with the same > simplicity as the "Resource Owner Password Credentials" grant of RFC 6749. > > The reason is that browser redirects are too complex and most of the time > badly implemented by small teams. For the sake of having SMEs use oAuth 2.1 > with their limited development capacities, I suggest keeping the simple "Resource > Owner Password Credentials" with an OTP replacing the permanent password. > > We also have sample implementations working on the market with OTP based "Resource > Owner Password Credentials" with full compatibility to RFC 6749. > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > --0000000000005bffba05a2ceabb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

The Resource Owner Password= Credentials grant is being deprecated in the OAuth 2.0 Security BCP:
=


>=C2= =A0The resource owner password credentials grant MUST NOT be used.

As this OAuth 2.1 draft is meant to consolidate the best p= ractices across the existing OAuth 2.0 documents, and is explicitly not int= ended to define any new behavior that is not already in an adopted document= , we can't accept your suggestion of adding a new OTP-based grant in th= is document.

----
Aaron = Parecki


On Wed, = Apr 8, 2020 at 2:59 PM Francis Pouatcha <fpo@adorsys.de> wrote:
As a replacement of=C2=A0RFC 6749 I am missing a = "Direct Grant" with the same simplicity as the "Resource Owner Password Cre= dentials"= grant of RFC 6749.

The reason is that = browser redirects are=C2=A0too complex and most of the time badly implement= ed by small teams. For the sake of having SMEs use oAuth 2.1 with their lim= ited development capacities, I suggest keeping the simple=C2=A0"Resource Owner Password Credentials" with an OTP r= eplacing the permanent password.

We also have sample implementations working = on the market with OTP based "Resource Owner Password Credentials" with full compatibility to RFC 6749.

--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead at adorys
=
--0000000000005bffba05a2ceabb2-- From nobody Wed Apr 8 15:05:44 2020 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 14C013A186D for ; Wed, 8 Apr 2020 15:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpdz2PXu3G96 for ; Wed, 8 Apr 2020 15:05:41 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 5A9C03A186F for ; Wed, 8 Apr 2020 15:05:41 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id t6so8322094ilj.8 for ; Wed, 08 Apr 2020 15:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3umazo2NnI8fMChTMONV6eHudP/TZFvckGVwpADDlA=; b=JUoSBMfHjr8lD2/67BCWpm22ZQkIbd3x4f5LvRFFkXWGHMOU8o9ZpdgltOLzvfNTKh VBXNnIgnDO2I0Sgk35DP+Mz3lB2YCqMQ2Njql6aR+y5r9u+3z81zxXOcIi1YYqOiQfIV hGAF7VtiRrnmonZ1fWMnunX9H8uAPga2hmkgBMRxr0NDRrG3vJkLA5UjM3jZ9a4e2SoT nK/Uw90OU8+NlaT9p901fnVXwF03R6cH49DwjUfBkamdYFL2IT+nJCCsspowW4GE53h8 hG3le6VwOxlTGFKeN1Lm0eybtriq7LzZKJ92EKiWIf4eyQe8mCsR3sBe9NN9xLf9/q8k BQ+Q== 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=w3umazo2NnI8fMChTMONV6eHudP/TZFvckGVwpADDlA=; b=RV/1u2FCGDfcGLMzKjZg1FdQnNMia0A40TRjK5/2krGpuM8WEaCQllpq+tLTlwB50C 3ziCfUgY5zv8Az3vScqMdUNSuxG4+3WtK7HtRxlTHj1T9uHmZ1cKaoGWOeCzPugXmWlJ fyi54mef3LkfLwptT3+LbTAb8ZtcxnrIWdNKjfQuZlclZVce88G2sOGNfzLla1DHq5qd UzcLLs6BFk0qkolzcmjAqYPlyVvWrnSMvCDz9GwpnC4JpVV1aKO8HuiGYQwzgewLmWZX 7Tw+TMfpX2ukrzmAUetUB0MR5oakU9X0EDJi3OewDxCVs9N+4O0umkbBA4IFz6ccec1Y Ro7w== X-Gm-Message-State: AGi0PuapUvSpxUAOsnBB3Z6MqpgnbgftSTqUDV2iVoImqe+GY4P0ubZ9 tq+cQsyW6ZEluuk9As/qPaEV6B10G20= X-Google-Smtp-Source: APiQypLF/4b5HTaH+Is7oVNzhMjMfB2fOSieAzyCXluhcAdspRBY5vNmGlCujDBiPeHbdcTAdsEy0g== X-Received: by 2002:a92:c6cb:: with SMTP id v11mr10167359ilm.41.1586383540272; Wed, 08 Apr 2020 15:05:40 -0700 (PDT) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id q1sm492926iop.15.2020.04.08.15.05.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 15:05:39 -0700 (PDT) Received: by mail-il1-f170.google.com with SMTP id i75so8277799ild.13; Wed, 08 Apr 2020 15:05:39 -0700 (PDT) X-Received: by 2002:a92:d083:: with SMTP id h3mr10244387ilh.28.1586383539212; Wed, 08 Apr 2020 15:05:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 8 Apr 2020 15:05:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Francis Pouatcha Cc: OAuth WG , draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="00000000000055165305a2ceb323" Archived-At: Subject: Re: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint 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, 08 Apr 2020 22:05:43 -0000 --00000000000055165305a2ceb323 Content-Type: text/plain; charset="UTF-8" Hi Francis, As much as I would love to require that all authorization requests are initiated via a back channel, that is unfortunately not something that is in scope of the current OAuth 2.1 document. The OAuth 2.0 Security BCP and this document require strict redirect URI matching, which should help simplify the AS, since simple string matching is sufficient now. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Apr 8, 2020 at 3:01 PM Francis Pouatcha wrote: > There is a lot of effort associated with the handling and correct > validation of a redirect_uri sent to the AS as part of the front channel > authorization request, as this gets transported by user agents. > > The draft-parecki-oauth-v2-1 as a replacement of RFC 6749 must make sure > redirect_uri is only sent to the AS through the back channel. This of > course requires the implementation of a new "authorization request > initiation endpoint". The draft-ietf-oauth-par-01 provides a guidance on > how to design this initiation endpoint. > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > --00000000000055165305a2ceb323 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

As much as I would love to = require that all authorization requests are initiated via a back channel, t= hat is unfortunately not something that is in scope of the current OAuth 2.= 1 document.

The OAuth 2.0 Security BCP and this do= cument require strict redirect URI matching, which should help simplify the= AS, since simple string matching is sufficient now.

----
Aaron Parecki


On Wed, Apr 8, 2020 at 3:01 PM Francis Pouatc= ha <fpo@adorsys.de> wrote:
<= /div>
=
There is a lot of effort associated with the handling and correct= validation of a redirect_uri sent to the AS as part of the front channel a= uthorization=C2=A0request, as this gets transported by user agents.

The=C2=A0draft-parecki-oauth-v2-1 as a replacement of RFC= 6749 must make sure redirect_uri is only sent to the AS through the back c= hannel. This of course requires the implementation of a new "authorization request initiatio= n endpoint". The=C2=A0draft-ietf-oauth-par-01 provides a guidan= ce on how to design this initiation endpoint.

--=C2=A0<= div dir=3D"ltr">
Francis Pouatcha
Co-Founder= and Technical Lead at adorys
https://= adorsys-platform.de/solutions/
--00000000000055165305a2ceb323-- From nobody Wed Apr 8 15:25:53 2020 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 9433D3A0820 for ; Wed, 8 Apr 2020 15:25:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.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 JbTAtqfl2OaY for ; Wed, 8 Apr 2020 15:25:50 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 AC9A83A082B for ; Wed, 8 Apr 2020 15:25:49 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id l11so6400898lfc.5 for ; Wed, 08 Apr 2020 15:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SgRfMqEJn5l/24who1c2GgQZ9Hj6G5dIZltK4Ey1Pq8=; b=XAziJBKDgIpI0Nep7SWoBgjBmMf5AGp8jufIyfI0/ScTkbrUtsGj0C+26EvmW0iVFx O7kfuB5PgIbh8juJAA+J84tXFnv9NUxxHcU6zYFZ7T6MMnwbcX1xTbqKFdHj0NygQ1hW 6n6z/dYZlc4X+Xhj++Kimk+8n0pDIxuInGE0s= 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=SgRfMqEJn5l/24who1c2GgQZ9Hj6G5dIZltK4Ey1Pq8=; b=pywDvy8QFwkqQjIOmi0i6JwITJzk9yWqPxJrF734pdplFugtlSKtKBvrW7bIIIye5m MO6YcMchtS32XDOmHBGc8VSc5v1nt23BwRHWzop9SCse1lJz6nmLVXwIPmBC92OTRUcp C1A0CjiE4ZitAyKqBlaaRLDgXzFqehAxFYDbf4LM4WfcCw4uHpA/AKZY6krP4ga+YvCL WBO7pOdT0SfSRYWpZS4pyjRfb9JSZ3Z51Q02eSVaeWIDHWsM2/uQS0dqX3xX513mDc+b e/iTtixnAFzqn2JfQWEiocI7hT4PHXunsTpHaKa+FjSCpGf2SyGA2GFFiiBDPZavxZEI IuYg== X-Gm-Message-State: AGi0PubstYBwVyu2AV1CrHY98xPrs52He/Bk4qJb3kFvOZ3FBMKGkyFA ttZE0/IjHpZDHMB+kgi83qukRxP6Xg/UQTs/HNsWXigOM+YnyA== X-Google-Smtp-Source: APiQypJO1BixN7D+Pl3nkq5YgIHY+Z1pTy7NXUUZz6iaffu4nncgg1ATWYsJ/xE186lh1MNEjkgt2kkBHWpB3npsiLs= X-Received: by 2002:a19:6b03:: with SMTP id d3mr1099720lfa.209.1586384747587; Wed, 08 Apr 2020 15:25:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Wed, 8 Apr 2020 18:25:36 -0400 Message-ID: To: Aaron Parecki Cc: OAuth WG , draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="0000000000005bcc7705a2cefbfb" Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 08 Apr 2020 22:25:53 -0000 --0000000000005bcc7705a2cefbfb Content-Type: text/plain; charset="UTF-8" Hello Aaron, Deprecating Resource Owner Password Credentials Flow (Direct Grant) without replacement might make a strict oAuth 2.1 server (with no backward compatibility to oAuth2.0) unusable for a good part of "First Party" applications on the market. These are application environments where the operator of the AS is the same one deploying the mobile App using Direct Grant. Not sure it is a good idea to limit scope oAuth 2.1 on existing functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ On Wed, Apr 8, 2020 at 6:03 PM Aaron Parecki wrote: > Hi Francis, > > The Resource Owner Password Credentials grant is being deprecated in the > OAuth 2.0 Security BCP: > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4 > > > The resource owner password credentials grant MUST NOT be used. > > As this OAuth 2.1 draft is meant to consolidate the best practices across > the existing OAuth 2.0 documents, and is explicitly not intended to define > any new behavior that is not already in an adopted document, we can't > accept your suggestion of adding a new OTP-based grant in this document. > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha wrote: > >> As a replacement of RFC 6749 I am missing a "Direct Grant" with the same >> simplicity as the "Resource Owner Password Credentials" grant of RFC >> 6749. >> >> The reason is that browser redirects are too complex and most of the time >> badly implemented by small teams. For the sake of having SMEs use oAuth 2.1 >> with their limited development capacities, I suggest keeping the simple "Resource >> Owner Password Credentials" with an OTP replacing the permanent >> password. >> >> We also have sample implementations working on the market with OTP based >> "Resource Owner Password Credentials" with full compatibility to RFC >> 6749. >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead at adorys >> https://adorsys-platform.de/solutions/ >> > --0000000000005bcc7705a2cefbfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Aaron,

Depr= ecating Resource Owner Password Credentials Flow (Direct Grant) without rep= lacement might make a strict oAuth 2.1 server (with no backward compatibili= ty to oAuth2.0) unusable for a good part of "First Party" applica= tions on the market. These are application environments where the operator = of the AS is the same one deploying the mobile App using Direct Grant.

Not sure it is a good idea to limit scope oAuth 2.1 on= existing functionality=C2=A0of oAuth 2.0 unless we are planning an oAuth 3= .0 soon.
--=C2=A0
Francis Pouatcha
Co-Founder and T= echnical Lead at adorys

On Wed, Apr 8, 2020 at 6:03 PM A= aron Parecki <aaron@parecki.com= > wrote:
Hi Francis,

The Resource Owner Password Cre= dentials grant is being deprecated in the OAuth 2.0 Security BCP:


>=C2=A0The resource owner password credentials grant MUST NOT be u= sed.

As this OAuth 2.1 draft is meant to consolida= te the best practices across the existing OAuth 2.0 documents, and is expli= citly not intended to define any new behavior that is not already in an ado= pted document, we can't accept your suggestion of adding a new OTP-base= d grant in this document.

----
Aaron Parecki



On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha <fpo@adorsys.de> wrote:=
As a replacement of=C2=A0RFC 6749 I am missing a "Direct Grant" with th= e same simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.

The reason is that browser redirects are=C2=A0too c= omplex and most of the time badly implemented by small teams. For the sake = of having SMEs use oAuth 2.1 with their limited development capacities, I s= uggest keeping the simple=C2=A0"Resource Owner Password Credentials" with an OTP replacing the permanent password. =
We= also have sample implementations working on the market with OTP based "Resource Owner Password Cre= dentials"= with full compatibility to RFC 6749.

--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead at adorys
=

--0000000000005bcc7705a2cefbfb-- From nobody Wed Apr 8 15:31:07 2020 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 0433C3A09AF for ; Wed, 8 Apr 2020 15:31:05 -0700 (PDT) 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 (1024-bit key) header.d=adorsys.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 LSshLe5x2EcO for ; Wed, 8 Apr 2020 15:31:03 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 620453A090E for ; Wed, 8 Apr 2020 15:31:03 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id s13so6399337lfb.9 for ; Wed, 08 Apr 2020 15:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BB7cMGaxTP2jrNV+KquLtkciNhr+d5SIw4VEeatD0CE=; b=adjYdyB7R5wSBMbdj5tvfh3CfeK6gGZzioDVgt09vdwM0Bdp9p9ABzLxZ7BszIKnQl W8YAJhNv1C0MhD/eEZww53WVoKIx6nCC4Hu9UoSciWAWljqztktoDJw+cKXTHoyiwQ+V DqU8k0l0nGSYV023f9QI1Y7lEUAgq5u0CgtvU= 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=BB7cMGaxTP2jrNV+KquLtkciNhr+d5SIw4VEeatD0CE=; b=LqHb6D6K109wvMQyDnCXF/EGtSBV9D0GM3lAiIcESi1LZBcAFLIPzERKiCRNTvbjbb +fdprYcqnwtoKhn8RddAMNYTJ7jOI/O4eCwPwF6gACBGPVggIwu48C0IYvS+MzP5o96S x+FUJ78e2z4iHnU5RIRZgHPjrI7WPYtFclcFWa2l8ywG1ZSdFn6hSJZDF1kb59JbP+9X JkhDVB7PjPn7c5yVgBFZX4gqW99tlxIha4eNpWVgZWP1RX+0V4f1Mqewo6ExhyHKXO4P +TU3jFl3hCdcn2RrvUZ536ZGwsvDGj5Qj4pH+yBWvTvY+EKqwoNmVEwInghlKsM5GSR2 u36A== X-Gm-Message-State: AGi0PuaYiL31k4d4IUgJTnIbmXa6//IwLVTJu+pEK1oUpcNcBNVMciKk MCTiUaxnHiCtAJ6mjS/Zuq8qWHnBaqjbQSOJ9VyUIA== X-Google-Smtp-Source: APiQypIMQeswXw0iRRlKR8UBLv0RWBclLMtEcDDy+NK7bf/Hra3ejUpo+ZNH2PxMwIqADlascdUIepbl6lkCZlgmEfM= X-Received: by 2002:ac2:5dd7:: with SMTP id x23mr5882163lfq.48.1586385061332; Wed, 08 Apr 2020 15:31:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Wed, 8 Apr 2020 18:30:50 -0400 Message-ID: To: Aaron Parecki Cc: OAuth WG , draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="0000000000000ee8cb05a2cf0e80" Archived-At: Subject: Re: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint 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, 08 Apr 2020 22:31:05 -0000 --0000000000000ee8cb05a2cf0e80 Content-Type: text/plain; charset="UTF-8" Hello Aaron, > As much as I would love to require that all authorization requests are > initiated via a back channel, that is unfortunately not something that is > in scope of the current OAuth 2.1 document. > > The OAuth 2.0 Security BCP and this document require strict redirect URI > matching, which should help simplify the AS, since simple string matching > is sufficient now. > Not sure it is a good idea to limit scope oAuth 2.1 on existing functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --0000000000000ee8cb05a2cf0e80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Aaron,
As much as I would love to require that all authorization requests are ini= tiated via a back channel, that is unfortunately not something that is in s= cope of the current OAuth 2.1 document.

The OAuth = 2.0 Security BCP and this document require strict redirect URI matching, wh= ich should help simplify the AS, since simple string matching is sufficient= now.
Not sure it is a good idea to limit scop= e oAuth 2.1 on existing functionality=C2=A0of oAuth 2.0 unless we are plann= ing an oAuth 3.0 soon.=C2=A0
<= span style=3D"color:rgb(80,0,80)">--=C2=A0
Francis Pouatcha
Co-Fou= nder and Technical Lead at adorys
<= /div>
--0000000000000ee8cb05a2cf0e80-- From nobody Wed Apr 8 16:20:26 2020 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 C09C83A199F for ; Wed, 8 Apr 2020 16:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.092 X-Spam-Level: X-Spam-Status: No, score=0.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.989, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5HZdynia7CK7 for ; Wed, 8 Apr 2020 16:20:23 -0700 (PDT) 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 50FD73A19A1 for ; Wed, 8 Apr 2020 16:20:22 -0700 (PDT) Received: from [192.168.1.13] (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 038NKJNV007957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 19:20:20 -0400 From: Justin Richer Message-Id: <2BEADDCF-646B-4F86-8204-36A42C12F466@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_EC1401BE-9AC7-469B-B727-BC85A613789E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 8 Apr 2020 19:20:19 -0400 In-Reply-To: Cc: Aaron Parecki , OAuth WG To: Francis Pouatcha References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint 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, 08 Apr 2020 23:20:25 -0000 --Apple-Mail=_EC1401BE-9AC7-469B-B727-BC85A613789E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Francis, The backchannel-first pattern that you are discussing is one of the key = components of TxAuth, which we are discussing on the txauth@ietf.org = mailing list, and I invite you to join the = conversation there. I have a project to implement these ideas that=E2=80=99= s documented at https://oauth.xyz/ , and it=E2=80=99s = been submitted as a draft to what will hopefully become the TxAuth = Working Group in the near future.=20 https://tools.ietf.org/html/draft-richer-transactional-authz = =E2=80=94 Justin > On Apr 8, 2020, at 6:30 PM, Francis Pouatcha = wrote: >=20 > Hello Aaron, > As much as I would love to require that all authorization requests are = initiated via a back channel, that is unfortunately not something that = is in scope of the current OAuth 2.1 document. >=20 > The OAuth 2.0 Security BCP and this document require strict redirect = URI matching, which should help simplify the AS, since simple string = matching is sufficient now. > Not sure it is a good idea to limit scope oAuth 2.1 on existing = functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon.=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ = __________________________________= _____________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_EC1401BE-9AC7-469B-B727-BC85A613789E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Francis,

The backchannel-first pattern that you are discussing is one = of the key components of TxAuth, which we are discussing on the txauth@ietf.org mailing list, and I invite you to = join the conversation there. I have a project to implement these ideas = that=E2=80=99s documented at https://oauth.xyz/, and it=E2=80=99s been submitted as a = draft to what will hopefully become the TxAuth Working Group in the near = future. 

https://tools.ietf.org/html/draft-richer-transactional-authz

 =E2=80=94= Justin

On Apr 8, 2020, at 6:30 PM, Francis Pouatcha = <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

Hello = Aaron,
As much as I would love to require that all authorization = requests are initiated via a back channel, that is unfortunately not = something that is in scope of the current OAuth 2.1 document.

The OAuth 2.0 Security = BCP and this document require strict redirect URI matching, which should = help simplify the AS, since simple string matching is sufficient = now.
Not sure it is a good idea = to limit scope oAuth 2.1 on existing functionality of oAuth 2.0 = unless we are planning an oAuth 3.0 soon. 
-- 
Francis = Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_EC1401BE-9AC7-469B-B727-BC85A613789E-- From nobody Wed Apr 8 17:10:17 2020 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 9FB9E3A1A52; Wed, 8 Apr 2020 17:10:15 -0700 (PDT) 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 0sPJtYzulw9f; Wed, 8 Apr 2020 17:10:13 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 8791E3A1A51; Wed, 8 Apr 2020 17:10:13 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id q19so9564381ljp.9; Wed, 08 Apr 2020 17:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pdCtZjeGozxgD/RMz8HUra5uHHgAuXg1pPkeEbjWq6g=; b=hOFRJCV/bM+lOn8qF8ism4ZMt32BdKsxJU+MqWoH91g0dQwcOKKBVxyamUYrI47see WuNCF8GCjK7TRHNLNGr3ixF2DHJf3UobzMj0Ju6VVxIPnZi46Je+/4F/ROkOj2KmgVHP RJjwzec1PrKa1xg3VHfS3nkstWY3p87aA5xoT8vVEEF5pvJhTsB9J8ppZ08CziY0vUpL 8xfOASxHGsGme0PhYAoGv8riStlBM0ywN1pp66k8WVkH4+0lyjLKqLEOAQm8an8suoxT CEK69nfonVfn29mAlQ04TtSOaLb4cAx1XOqS/x3+nyh4l+gDHck4i4CxMNOH7GBsw9p8 JwCw== 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=pdCtZjeGozxgD/RMz8HUra5uHHgAuXg1pPkeEbjWq6g=; b=ViVxe/2MPHl16o6gBtb++YdHyBwxjODJuybSHjK7o03gkOU9OFi9MeyuL0FiUfWW/s udpRMmhLWvy5NrnUONXkqGY7DEAO/ewMdjw64s2zbk/16tM1bRh/Y+XHnikcjljWcrMk W3c7ljYRdBVpYTV+6sbcUOOzaI+wYmzgsMaUfHoEwc4sMAMPqmdZdutGpxudFX+MqLm2 kNOaSlOO/Fu7nQVjlwCQVL0ev6kH3wIXObn1cf0Vvelw3bsl8CDaVWzNQjffTN6SKbc8 CxLFTyaFplyYKwsa2/wmZcvtY0vRTueckHo+BhtUnObNqwx3msKZYuXO5oKnP5ZSWz11 FF5g== X-Gm-Message-State: AGi0PubBnUP2nwxE9/9OnCIfad24E0v6W/VE1/UovPQy5U+mbjD75LfL 4H8NRufgilVfQrUn5bfeD7DuHPipQ9hqGaGCQt0= X-Google-Smtp-Source: APiQypLooKL8ZlfQ4TdjGR+xBy6JJJxUVndZWMxaf/RttoZTz4VVcovFWQgjGexDzKK3q2XQbAPCGKooF5JP9TaPGT8= X-Received: by 2002:a05:651c:20d:: with SMTP id y13mr6801812ljn.112.1586391011651; Wed, 08 Apr 2020 17:10:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 8 Apr 2020 17:09:45 -0700 Message-ID: To: Francis Pouatcha Cc: Aaron Parecki , OAuth WG , draft-parecki-oauth-v2-1@ietf.org Content-Type: multipart/alternative; boundary="000000000000b9757405a2d0702c" Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 00:10:16 -0000 --000000000000b9757405a2d0702c Content-Type: text/plain; charset="UTF-8" Francis We had a long discussion on this topic earlier this year: https://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/ On Wed, Apr 8, 2020 at 3:25 PM Francis Pouatcha wrote: > Hello Aaron, > > Deprecating Resource Owner Password Credentials Flow (Direct Grant) > without replacement might make a strict oAuth 2.1 server (with no backward > compatibility to oAuth2.0) unusable for a good part of "First Party" > applications on the market. These are application environments where the > operator of the AS is the same one deploying the mobile App using Direct > Grant. > > Not sure it is a good idea to limit scope oAuth 2.1 on existing > functionality of oAuth 2.0 unless we are planning an oAuth 3.0 soon. > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ > > On Wed, Apr 8, 2020 at 6:03 PM Aaron Parecki wrote: > >> Hi Francis, >> >> The Resource Owner Password Credentials grant is being deprecated in the >> OAuth 2.0 Security BCP: >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4 >> >> > The resource owner password credentials grant MUST NOT be used. >> >> As this OAuth 2.1 draft is meant to consolidate the best practices across >> the existing OAuth 2.0 documents, and is explicitly not intended to define >> any new behavior that is not already in an adopted document, we can't >> accept your suggestion of adding a new OTP-based grant in this document. >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> >> On Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha wrote: >> >>> As a replacement of RFC 6749 I am missing a "Direct Grant" with the >>> same simplicity as the "Resource Owner Password Credentials" grant of RFC >>> 6749. >>> >>> The reason is that browser redirects are too complex and most of the >>> time badly implemented by small teams. For the sake of having SMEs use >>> oAuth 2.1 with their limited development capacities, I suggest keeping the >>> simple "Resource Owner Password Credentials" with an OTP replacing the >>> permanent password. >>> >>> We also have sample implementations working on the market with OTP based >>> "Resource Owner Password Credentials" with full compatibility to RFC >>> 6749. >>> >>> -- >>> Francis Pouatcha >>> Co-Founder and Technical Lead at adorys >>> https://adorsys-platform.de/solutions/ >>> >> > --000000000000b9757405a2d0702c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Francis

We had a long discussion on thi= s topic earlier this year:



On Wed, Apr 8, 2020 at 3:25 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hel= lo=C2=A0Aaron,

Deprecating Resource Owner Password Crede= ntials Flow (Direct Grant) without replacement might make a strict oAuth 2.= 1 server (with no backward compatibility to oAuth2.0) unusable for a good p= art of "First Party" applications on the market. These are applic= ation environments where the operator of the AS is the same one deploying t= he mobile App using Direct Grant.

Not sure it is a= good idea to limit scope oAuth 2.1 on existing functionality=C2=A0of oAuth= 2.0 unless we are planning an oAuth 3.0 soon.
--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead at adorys
=

On Wed, Apr 8, 2020 at 6:03 PM Aaron Parecki <aaron@parecki.com> wrote:
Hi Fra= ncis,

The Resource Owner Password Credentials grant is b= eing deprecated in the OAuth 2.0 Security BCP:


>=C2=A0The= resource owner password credentials grant MUST NOT be used.

=
As this OAuth 2.1 draft is meant to consolidate the best practic= es across the existing OAuth 2.0 documents, and is explicitly not intended = to define any new behavior that is not already in an adopted document, we c= an't accept your suggestion of adding a new OTP-based grant in this doc= ument.

----
Aaron Parecki



On= Wed, Apr 8, 2020 at 2:59 PM Francis Pouatcha <fpo@adorsys.de> wrote:
=
As a= replacement of=C2=A0= RFC 6749 I am missing a "Direct Grant" with the same simplicity a= s the "Res= ource Owner Password Credentials" grant of RFC 6749.

=
The reason is that browser redirects are=C2=A0too complex and most of = the time badly implemented by small teams. For the sake of having SMEs use = oAuth 2.1 with their limited development capacities, I suggest keeping the = simple=C2=A0"Resource Owner Pas= sword Credentials" with an OTP replacing the permanent password.
<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">
= We also have sample i= mplementations working on the market with OTP based "Resource Owner Password Credentials" with full compatib= ility to RFC 6749.

--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead at adorys
=

--000000000000b9757405a2d0702c-- From nobody Wed Apr 8 18:39:57 2020 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 971DC3A1D65 for ; Wed, 8 Apr 2020 18:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id8XRCKruuTw for ; Wed, 8 Apr 2020 18:39:49 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0: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 1ABC93A1D5D for ; Wed, 8 Apr 2020 18:39:49 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id n13so8779073ilm.5 for ; Wed, 08 Apr 2020 18:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ujZ8asu3yPefCHFIMPts9fPhNbI9ag1Y1n/Oel2jez4=; b=cmy4Jyiq6R9rcoxRG2PeihUWWlCx77E1QsFa84spFQadIrruiJBzgZ8m8hBt+TfwsH cpzxVHVh34H1n4HzVgVhsgtC0VtyH+Q2lH7k3DdLtIMC8AnYmr2Qj76nJOox/8ymDhgS 3yCQasHffSG7bQKkxmaqdp4nEncHdEpiy+9zgjk/kSR3cATCi7ORYjmPlV+dFoYL7ZY8 wND/EdrqQBf7Tsf3gcv9OKsYaV2KJmKRxgZHYg4iA8Ruq+o9IgY5QR0pADZarKLGs9HE K738aI8aLI57DVgXdhUjq0Vbv7svL7r18w4TMOHBbwDaRYJLLGzopkP/7yKyJ370Q/fc 7IVQ== 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=ujZ8asu3yPefCHFIMPts9fPhNbI9ag1Y1n/Oel2jez4=; b=eiwX3LBzSonBD9GF7HPiBS5a3cZqgaJAs6MM390RE2GrBxagfu5TrM096djKqPutpA rR0px7ov8E7mWudW5MbS5OTXxaxLdVOTFtsax0ztRimi8k8cgb9tHVi3CJ3jgLZMGMLz m5oH6Uwd0LoykxjhZRk56vqIJWFSEGIvvayXbQPEdLJV5hccVEZWxe5kj9o0nkQzdSL7 VxdGcnNPtUE9Ij7QAOPcycsrYAPAgk9lmjnk47R/pH6M0gtc++A0Q8zAQVcK+8sBtJ/z 7rwwp6J557PAkMZefjtpSj6dF0XHOeQLOxefwpxkxTWvLteenUDJxUpjJZl6sLC58pth +uXQ== X-Gm-Message-State: AGi0Pub7esuMeErYQAA3Tz9UXoVMmeR1JT+XawkVAImdU3qmoYoNfcuO reRkub2CSm0UcDzdoUs9uLB3Pw7+LFI= X-Google-Smtp-Source: APiQypIF0Hos9lLU8Y4ET78ePL3pfq+6rfxKgswLlHVKyeo+SLImz/HbANcx4l3bbcaNfGoVX+c5eQ== X-Received: by 2002:a92:da4a:: with SMTP id p10mr10440622ilq.34.1586396386711; Wed, 08 Apr 2020 18:39:46 -0700 (PDT) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id s8sm2279267iln.56.2020.04.08.18.39.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Apr 2020 18:39:45 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id t6so8737037ilj.8 for ; Wed, 08 Apr 2020 18:39:45 -0700 (PDT) X-Received: by 2002:a92:1b59:: with SMTP id b86mr10976357ilb.291.1586396385309; Wed, 08 Apr 2020 18:39:45 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 8 Apr 2020 18:39:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="00000000000004fabc05a2d1b1a2" Archived-At: Subject: [OAUTH-WG] Upcoming interim meetings 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, 09 Apr 2020 01:39:56 -0000 --00000000000004fabc05a2d1b1a2 Content-Type: text/plain; charset="UTF-8" Hi all, I find it particularly difficult to follow the list of upcoming meetings in email threads, and given that there are a whole host of upcoming interim meetings, I thought I would put together an easier way to find the agendas and webex links. You can find the list of upcoming meetings here: https://events.oauth.net/tag/ietf Each meeting page contains the agenda, a link to view the meeting time in your local timezone, and the WebEx link to join the meeting. I'll update the page with the link to the minutes afterwards. There is also an iCal link at the bottom you can use to add this page to your calendar of choice. Hope this helps! ---- Aaron Parecki aaronparecki.com @aaronpk --00000000000004fabc05a2d1b1a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I find it particular= ly difficult to follow the list of upcoming meetings in email threads, and = given that there are a whole host of upcoming interim meetings, I thought= =C2=A0I would put together an easier way to find the agendas and webex link= s.

You can find the list of upcoming meetings here= :=C2=A0https://events.oauth.n= et/tag/ietf

Each meeting page contains the age= nda, a link to view the meeting time in your local timezone, and the WebEx = link to join the meeting. I'll update the page with the link to the min= utes afterwards.

There is also an iCal link at the= bottom you can use to add this page to your calendar of choice.
=
Hope this helps!

----
Aaron Parecki

--00000000000004fabc05a2d1b1a2-- From nobody Wed Apr 8 19:11:16 2020 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 F1F133A1DA2 for ; Wed, 8 Apr 2020 19:11:14 -0700 (PDT) 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 (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 6TB55PT_jX68 for ; Wed, 8 Apr 2020 19:11:12 -0700 (PDT) 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 58C7C3A1D9F for ; Wed, 8 Apr 2020 19:11:12 -0700 (PDT) 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 0392BAsV018661; Wed, 8 Apr 2020 22:11:10 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 0392BAsV018661 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1586398270; bh=yome4XCytorTEXFuM/D1SN4lNGx34qfi/9GXytjs2OA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=ilPuPUw5Qw7loV7uc1tgI+NtQpANka5THYXOZQKku0/unRMMp1IZtdPWjoEXg/6TY yiGyvHqov46nQW6USa5wSbUHOtgqBtCIyrbsMDXrVFF4JZbvaE4cdSyQ1FJNfHrVWy 2kr6qRbRVNUd0eqQ8htbe28JZlprQUxSrMMj+qfE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0392B7bl025315; Wed, 8 Apr 2020 22:11:07 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0487.000; Wed, 8 Apr 2020 22:11:06 -0400 From: Roman Danyliw To: Aaron Parecki , OAuth WG Thread-Topic: [OAUTH-WG] Upcoming interim meetings Thread-Index: AQHWDg/SNHPH/6ZIwkS6flCoiP3+RqhwBoHg Date: Thu, 9 Apr 2020 02:11:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216FEE4D2@marchand> 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.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0216FEE4D2marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Upcoming interim meetings 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, 09 Apr 2020 02:11:15 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC0216FEE4D2marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkluZGVlZCwgdGhhbmtzIGZvciB0aGlzIE9BdXRoIHNwZWNpZmljIGxpc3QuDQoNCkFz IGEgUFNBLCB0aGUg4oCcb2ZmaWNpYWwgcGFnZeKAnSBvZiB1cGNvbWluZyBtZWV0aW5ncyAoT0F1 dGgsIG9yIG90aGVyd2lzZSkgd2lsbCBhbHNvIGhhdmUgcG9pbnRzIHRvIHRoZSB3ZWJleCwgYWdl bmRhIGFuZCBtYXRlcmlhbHMgdG9vLiAgU2VlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvdXBjb21pbmcuDQoNClJvbWFuDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWFyb24gUGFyZWNraQ0KU2VudDogV2VkbmVzZGF5LCBB cHJpbCA4LCAyMDIwIDk6NDAgUE0NClRvOiBPQXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbT0FVVEgtV0ddIFVwY29taW5nIGludGVyaW0gbWVldGluZ3MNCg0KSGkgYWxsLA0KDQpJ IGZpbmQgaXQgcGFydGljdWxhcmx5IGRpZmZpY3VsdCB0byBmb2xsb3cgdGhlIGxpc3Qgb2YgdXBj b21pbmcgbWVldGluZ3MgaW4gZW1haWwgdGhyZWFkcywgYW5kIGdpdmVuIHRoYXQgdGhlcmUgYXJl IGEgd2hvbGUgaG9zdCBvZiB1cGNvbWluZyBpbnRlcmltIG1lZXRpbmdzLCBJIHRob3VnaHQgSSB3 b3VsZCBwdXQgdG9nZXRoZXIgYW4gZWFzaWVyIHdheSB0byBmaW5kIHRoZSBhZ2VuZGFzIGFuZCB3 ZWJleCBsaW5rcy4NCg0KWW91IGNhbiBmaW5kIHRoZSBsaXN0IG9mIHVwY29taW5nIG1lZXRpbmdz IGhlcmU6IGh0dHBzOi8vZXZlbnRzLm9hdXRoLm5ldC90YWcvaWV0Zg0KDQpFYWNoIG1lZXRpbmcg cGFnZSBjb250YWlucyB0aGUgYWdlbmRhLCBhIGxpbmsgdG8gdmlldyB0aGUgbWVldGluZyB0aW1l IGluIHlvdXIgbG9jYWwgdGltZXpvbmUsIGFuZCB0aGUgV2ViRXggbGluayB0byBqb2luIHRoZSBt ZWV0aW5nLiBJJ2xsIHVwZGF0ZSB0aGUgcGFnZSB3aXRoIHRoZSBsaW5rIHRvIHRoZSBtaW51dGVz IGFmdGVyd2FyZHMuDQoNClRoZXJlIGlzIGFsc28gYW4gaUNhbCBsaW5rIGF0IHRoZSBib3R0b20g eW91IGNhbiB1c2UgdG8gYWRkIHRoaXMgcGFnZSB0byB5b3VyIGNhbGVuZGFyIG9mIGNob2ljZS4N Cg0KSG9wZSB0aGlzIGhlbHBzIQ0KDQotLS0tDQpBYXJvbiBQYXJlY2tpDQphYXJvbnBhcmVja2ku Y29tPGh0dHA6Ly9hYXJvbnBhcmVja2kuY29tPg0KQGFhcm9ucGs8aHR0cDovL3R3aXR0ZXIuY29t L2Fhcm9ucGs+DQoNCg== --_000_359EC4B99E040048A7131E0F4E113AFC0216FEE4D2marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5kZWVkLCB0aGFua3MgZm9yIHRoaXMgT0F1dGgg c3BlY2lmaWMgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSBQU0EsIHRoZSDigJxv ZmZpY2lhbCBwYWdl4oCdIG9mIHVwY29taW5nIG1lZXRpbmdzIChPQXV0aCwgb3Igb3RoZXJ3aXNl KSB3aWxsIGFsc28gaGF2ZSBwb2ludHMgdG8gdGhlIHdlYmV4LCBhZ2VuZGEgYW5kIG1hdGVyaWFs cyB0b28uJm5ic3A7IFNlZToNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bWVldGluZy91cGNvbWluZyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL3Vw Y29taW5nPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9tYW48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0 OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQWFyb24gUGFyZWNraTxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEFwcmlsIDgsIDIwMjAgOTo0MCBQTTxicj4NCjxiPlRvOjwvYj4gT0F1dGggV0cg Jmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFVw Y29taW5nIGludGVyaW0gbWVldGluZ3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgZmluZCBpdCBwYXJ0aWN1bGFybHkgZGlmZmljdWx0IHRvIGZvbGxvdyB0aGUg bGlzdCBvZiB1cGNvbWluZyBtZWV0aW5ncyBpbiBlbWFpbCB0aHJlYWRzLCBhbmQgZ2l2ZW4gdGhh dCB0aGVyZSBhcmUgYSB3aG9sZSBob3N0IG9mIHVwY29taW5nIGludGVyaW0gbWVldGluZ3MsIEkg dGhvdWdodCZuYnNwO0kgd291bGQgcHV0IHRvZ2V0aGVyIGFuIGVhc2llciB3YXkgdG8gZmluZCB0 aGUgYWdlbmRhcyBhbmQgd2ViZXggbGlua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4gZmluZCB0aGUgbGlzdCBvZiB1cGNvbWlu ZyBtZWV0aW5ncyBoZXJlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZXZlbnRzLm9hdXRoLm5ldC90 YWcvaWV0ZiI+aHR0cHM6Ly9ldmVudHMub2F1dGgubmV0L3RhZy9pZXRmPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FYWNoIG1lZXRpbmcg cGFnZSBjb250YWlucyB0aGUgYWdlbmRhLCBhIGxpbmsgdG8gdmlldyB0aGUgbWVldGluZyB0aW1l IGluIHlvdXIgbG9jYWwgdGltZXpvbmUsIGFuZCB0aGUgV2ViRXggbGluayB0byBqb2luIHRoZSBt ZWV0aW5nLiBJJ2xsIHVwZGF0ZSB0aGUgcGFnZSB3aXRoIHRoZSBsaW5rIHRvIHRoZSBtaW51dGVz IGFmdGVyd2FyZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIGFsc28gYW4gaUNhbCBsaW5rIGF0IHRoZSBib3R0b20geW91IGNh biB1c2UgdG8gYWRkIHRoaXMgcGFnZSB0byB5b3VyIGNhbGVuZGFyIG9mIGNob2ljZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3BlIHRoaXMgaGVscHMh PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BYXJvbiBQYXJlY2tpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYWFyb25wYXJlY2tpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmFhcm9ucGFyZWNraS5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vYWFy b25wayIgdGFyZ2V0PSJfYmxhbmsiPkBhYXJvbnBrPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_359EC4B99E040048A7131E0F4E113AFC0216FEE4D2marchand_-- From nobody Thu Apr 9 00:25:43 2020 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 AB6033A0D6D for ; Thu, 9 Apr 2020 00:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 3tN2X6nBVZfL for ; Thu, 9 Apr 2020 00:25:39 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8402E3A0D6A for ; Thu, 9 Apr 2020 00:25:39 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 0A08E376A for ; Thu, 9 Apr 2020 07:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586417138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HvO524faZUUVYOAW4xWnvg8AYfPY5WbL5E5DwRvJyXY=; b=e2zOYePZKuW3rHIhvFoYIagsMdrCP+d4+laFz0Fk0N0EmpT4N/UZXpCliGqbrfuqutnSNN rn1xn/CL6DZoS/7Cq6y/Ln+B5dM505DHiEOrwbBRODXLQBLDTpotZmBB6FofFSoqJqZUmK YYXRiHJpTp1Fomx7K0tMmJys7wFf+Tg= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <07ef79c7-9ae7-98ee-d3d2-b4e7fa68644c@danielfett.de> Date: Thu, 9 Apr 2020 09:25:37 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------98E9CAD9F043AB08948F20C1" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586417138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HvO524faZUUVYOAW4xWnvg8AYfPY5WbL5E5DwRvJyXY=; b=cui0Ae14gpipuO92rKd720nnaMPR25RCBzZ8fJs8BbbDeVAHGvR4e07dB1ns2Q/0Gt9Cu5 1vlrCBHZprXdGXnGl0chBkL1RvhWD5wPEzQbQCin4MKUehHK8SIv6h+mf1vQOWc18y26Kd ZDSDZypb1ZtdZ9p61tVDEM4wjPvBQX8= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1586417138; a=rsa-sha256; cv=none; b=or2y39Sm1AHh0udk3YH3yJSVfLsxyBOOQPaBYtRyCPWjT7CertoyBIW0WW9vr9IhbAcCF4 02AUkDroEk3cCQWNKDv5TkFoFAnckBpBGnNmb0hXfCMMjKkFFXJt8zaO4N0hj/EeWZHne2 HA0zHdZNeihJC/TCrJrUvfopWL3Ed5k= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 07:25:41 -0000 This is a multi-part message in MIME format. --------------98E9CAD9F043AB08948F20C1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Francis, Am 08.04.20 um 23:59 schrieb Francis Pouatcha: > As a replacement of RFC 6749 I am missing a "Direct Grant" with the > same simplicity as the "Resource Owner Password Credentials" grant of > RFC 6749. > > The reason is that browser redirects are too complex and most of the > time badly implemented by small teams. For the sake of having SMEs use > oAuth 2.1 with their limited development capacities, I suggest keeping > the simple "Resource Owner Password Credentials" with an OTP replacing > the permanent password. How does the Client get the OTP in that case? -Daniel --------------98E9CAD9F043AB08948F20C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Francis,

Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
As a replacement of RFC 6749 I am missing a "Direct Grant" with the same simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.

The reason is that browser redirects are too complex and most of the time badly implemented by small teams. For the sake of having SMEs use oAuth 2.1 with their limited development capacities, I suggest keeping the simple "Resource Owner Password Credentials" with an OTP replacing the permanent password.

How does the Client get the OTP in that case?

-Daniel


--------------98E9CAD9F043AB08948F20C1-- From nobody Thu Apr 9 00:56:02 2020 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 1FD6F3A096E for ; Thu, 9 Apr 2020 00:56:02 -0700 (PDT) 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=pingidentity.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 u03dx51OveeS for ; Thu, 9 Apr 2020 00:56:00 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 5DC413A0DF8 for ; Thu, 9 Apr 2020 00:56:00 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id l14so4639825pgb.1 for ; Thu, 09 Apr 2020 00:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7awJcDxYmyhRANjDya2nt9byVl6oy8Lb1wdnKeeAe2g=; b=OXxdX7R39lNgniuAloCQDD5ikWaV3lvQywekRvfvejyfuIph+vXGf1dzwcolw1Ph66 aM7q0YgcgLjVqmYN01CetF9M5zZ4HP1pwoDhIAD6pnANRlRkgxNQ5tlLxIGbFWESS0o2 QaiiMtLruhnhLtuzWhPpUSd+d6ir1UiWoJqoA3nV3i0pClj5zXEscLnUcY1KJaCkYueg /b0ZDXzDsVp6/xVo8xa+92d8g6WH95de72Eha/UsQYAXlIRZ77cSnHzi8w3+fBE9eony T3oZjXzFTYTR9oJ8YLItjvT2XOIO8nzwkmJYsRoCCUOmJNROxx3KN1tAg5gqa0ctU+j5 qJdg== 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=7awJcDxYmyhRANjDya2nt9byVl6oy8Lb1wdnKeeAe2g=; b=IgCfIzxXDwks4PJKwngH+COQBTqT/wdzbMYxFqUUkBaKSALt9y6bmdofh9MKXx67jF Fg18IBjKYdcnnmMV0rsLu6g0qFwYfOpAgwEhv+4OVNaGzWIgiSAl7Xvezs9YEnVYxcMq XJkaORgbxkyzN5nGuGK5uwJkIPUANnYMk1R/jSNSXUD5wEwZuzWBJ2dO0QOovBVUoYWA xKo4FpJHqNUWGvsKHvWUh7F2RV+EYLJbP3dsvWQwRYCc7j3rN79gkcVPXyOginXo9z0E VgpbGjbKNPWJNQuefWv62DeyQAj2vEXXWOzB+sIBskf0Pm6OD//S7tW9735KLiPjX8oD gSaQ== X-Gm-Message-State: AGi0PuZv2yLnUOBS8mHe49yZg87onjJjfPh0ZRvMaFHNT7GmH1qnKhi1 p/8NXHjyURwXLBV7MG8YMO+BYTB5AjqFLh1xgglv9Nw6NrdXq74L+vV4OvpnJLUx9g7O36kKgZk nbVWhEOCESpps8Crm X-Google-Smtp-Source: APiQypIDRStG3rsiuB7Xiu7ZdTE/hewzkrDCf/Xunwm6oD82TyvwQiwLG0v0J1AidGsMNdQgAfImEDE1JSNf6N49jLA= X-Received: by 2002:a63:f615:: with SMTP id m21mr10637184pgh.107.1586418959443; Thu, 09 Apr 2020 00:55:59 -0700 (PDT) MIME-Version: 1.0 References: <07ef79c7-9ae7-98ee-d3d2-b4e7fa68644c@danielfett.de> In-Reply-To: <07ef79c7-9ae7-98ee-d3d2-b4e7fa68644c@danielfett.de> From: Rob Otto Date: Thu, 9 Apr 2020 08:55:48 +0100 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008b56e105a2d6f20d" Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 07:56:02 -0000 --0000000000008b56e105a2d6f20d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd imagine you have to pre-register each client and then use HOTP or TOTP to generate one-time passcodes. On Thu, 9 Apr 2020 at 08:25, Daniel Fett wrote: > Hi Francis, > > Am 08.04.20 um 23:59 schrieb Francis Pouatcha: > > As a replacement of RFC 6749 I am missing a "Direct Grant" with the same > simplicity as the "Resource Owner Password Credentials" grant of RFC 6749= . > > The reason is that browser redirects are too complex and most of the time > badly implemented by small teams. For the sake of having SMEs use oAuth 2= .1 > with their limited development capacities, I suggest keeping the simple "= Resource > Owner Password Credentials" with an OTP replacing the permanent password. > > How does the Client get the OTP in that case? > > -Daniel > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 [image: Ping Identity] Rob Otto EMEA Field CTO/Solutions Architect robertotto@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Blog logo] *If you=E2=80=99re not a current customer, click here for a more relevant offer.* --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008b56e105a2d6f20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd imagine you have to pre-register each clie= nt and then use HOTP or TOTP to generate one-time passcodes.=C2=A0



On Thu, 9 Apr 2020 at 08:25, Daniel Fett &= lt;fett@danielfett.de> wrote:<= br>
=20 =20 =20
Hi Francis,

Am 08.04.20 um 23:59 schrieb Francis Pouatcha:
=20
As a replacement of=C2=A0RFC 6749 I am missing a "Direct Grant&q= uot; with the same simplicity as the "Resource Owner Password Credentials" grant of RFC 6749.

The reason is that browser redirects are=C2=A0to= o complex and most of the time badly implemented by small teams. For the sake of having SMEs use oAuth 2.1 with their limited development capacities, I suggest keeping the simple=C2=A0"Resourc= e Owner Password Credentials" with an OTP replacing the perm= anent password.

How does the Client get the OTP in that case?

-Daniel


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


--
3D"Ping <= table>
= Rob Otto
EMEA Field CTO/Solutions Architect
robertotto@pingidentity.com<= /a>

c: +44 (0) 7= 77 135 6092
<= tbody>
Connect with us: 3D"Glassdoor= 3D"L= 3D"twitter 3D"facebook 3D"youtube = 3D"Blog
=
If you=E2=80=99= re not a current customer, click=C2=A0here=C2=A0for a = more relevant offer.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008b56e105a2d6f20d-- From nobody Thu Apr 9 01:09:20 2020 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 BDCC63A0E38 for ; Thu, 9 Apr 2020 01:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 JnoQMLZ-Zn6N for ; Thu, 9 Apr 2020 01:09:17 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8B13A0E36 for ; Thu, 9 Apr 2020 01:09:17 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id B8D2736E4; Thu, 9 Apr 2020 08:09:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586419754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lnpp8cdeIJloDFAqMuLXq9scyh3crpPZKJOCLhvUv7c=; b=ZNw6owwetIOIzykNrOrZkornwJyMTFwiPpl4OA+HwBQtablBq1AxAwfi3w+Uv8U8A1yoE1 fgdbBzFVZwAYHnMe2GSk9M0URKZlcO69twowSVG09p2ANuLz1NDp05u1tau8qQJAISzuTz //1EcMIKR+N027QbuW1LpQcLbfKCdE4= To: Rob Otto Cc: oauth References: <07ef79c7-9ae7-98ee-d3d2-b4e7fa68644c@danielfett.de> From: Daniel Fett Message-ID: <36be532a-dca5-da55-ffdc-a283724df824@danielfett.de> Date: Thu, 9 Apr 2020 10:09:13 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E02E07D23554C4CA4378E8FD" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1586419754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lnpp8cdeIJloDFAqMuLXq9scyh3crpPZKJOCLhvUv7c=; b=mwHimOmsfTwx4JNu2pMuMXg8E3N3GuIP5QgCDGFD7UyPrPD3xbuwt3PXrUw3AtMduJuxxI mPmFnpvN4K5ho/uf8M+K25lBEYfvrcK8a+S6j/fgcTfORk+bmZV+jUUaLYd+S827Qjb/KG rC6jpmmMdgxo5VljcoLz6NlpQ9GyBZ8= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1586419754; a=rsa-sha256; cv=none; b=OfmtOJK4S1svcxyquU+C817mrutbgd/a5J561kpW45MgyfXp+2IkwHqhQkZbzasPYJOoYO 5/zAMm0KnW5RuPvAlQNXcxhCJD8Q8XVm+0aKm1yQubWFgE+aBTmjTjJPpesXh2AG6NNcWm QqfJopzZutrSAN6xzxDbSLgq3roJ8ts= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 08:09:19 -0000 This is a multi-part message in MIME format. --------------E02E07D23554C4CA4378E8FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 09.04.20 um 09:55 schrieb Rob Otto: > I'd imagine you have to pre-register each client and then use HOTP or > TOTP to generate one-time passcodes.  > I can come up with a couple of other ways as well, but I'm interested to hear what Francis sees "in the wild". -Daniel --------------E02E07D23554C4CA4378E8FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 09.04.20 um 09:55 schrieb Rob Otto:
I'd imagine you have to pre-register each client and then use HOTP or TOTP to generate one-time passcodes. 


I can come up with a couple of other ways as well, but I'm interested to hear what Francis sees "in the wild".

-Daniel

--------------E02E07D23554C4CA4378E8FD-- From nobody Thu Apr 9 04:30:47 2020 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 490513A08BA for ; Thu, 9 Apr 2020 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 du0bHUPd1vVc for ; Thu, 9 Apr 2020 04:30:38 -0700 (PDT) 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 F02AB3A08C6 for ; Thu, 9 Apr 2020 04:30:36 -0700 (PDT) Received: from [192.168.1.13] (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 039BUWCB002822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 07:30:32 -0400 From: Justin Richer Message-Id: <0EC51F1E-689E-475D-8F3C-B17A6C5B794C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7DDA9C2D-5169-495C-912F-3D382C8E4DD4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 07:30:32 -0400 In-Reply-To: <36be532a-dca5-da55-ffdc-a283724df824@danielfett.de> Cc: Rob Otto , oauth To: Daniel Fett References: <07ef79c7-9ae7-98ee-d3d2-b4e7fa68644c@danielfett.de> <36be532a-dca5-da55-ffdc-a283724df824@danielfett.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 11:30:46 -0000 --Apple-Mail=_7DDA9C2D-5169-495C-912F-3D382C8E4DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99ve looked at this with XYZ, and one of the patterns that=E2=80=99= s possible with the backchannel-first flow is to have the server send a = challenge back to the client which the client can then respond to, for = example by signing it with a FIDO style device key. Depending on the = system, the client could identify the user in the first request or the = credential could carry the identification directly. You need an = =E2=80=9Cextra=E2=80=9D round trip compared to OAuth2 style flows, but = it makes life a whole lot simpler for this kind of user authn. =E2=80=94 Justin > On Apr 9, 2020, at 4:09 AM, Daniel Fett wrote: >=20 >=20 > Am 09.04.20 um 09:55 schrieb Rob Otto: >> I'd imagine you have to pre-register each client and then use HOTP or = TOTP to generate one-time passcodes.=20 >>=20 >=20 > I can come up with a couple of other ways as well, but I'm interested = to hear what Francis sees "in the wild". >=20 > -Daniel >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7DDA9C2D-5169-495C-912F-3D382C8E4DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99ve looked at this with XYZ, and one of the = patterns that=E2=80=99s possible with the backchannel-first flow is to = have the server send a challenge back to the client which the client can = then respond to, for example by signing it with a FIDO style device key. = Depending on the system, the client could identify the user in the first = request or the credential could carry the identification directly. You = need an =E2=80=9Cextra=E2=80=9D round trip compared to OAuth2 style = flows, but it makes life a whole lot simpler for this kind of user = authn.

 =E2=80=94= Justin

On Apr 9, 2020, at 4:09 AM, Daniel Fett = <fett@danielfett.de> wrote:

=20

Am 09.04.20 um 09:55 schrieb Rob = Otto:
=20
I'd imagine you have to pre-register each client and then use HOTP or TOTP to generate one-time passcodes. 


I can come up with a couple of other ways as well, but I'm interested to hear what Francis sees "in the wild".

-Daniel

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

= --Apple-Mail=_7DDA9C2D-5169-495C-912F-3D382C8E4DD4-- From nobody Thu Apr 9 09:25:54 2020 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 8DD873A0AB6 for ; Thu, 9 Apr 2020 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 YGZwogN8kNpC for ; Thu, 9 Apr 2020 09:25:52 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE3B3A0AA8 for ; Thu, 9 Apr 2020 09:25:50 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d61 with ME id QgRl2200D4FMSmm03gRmc2; Thu, 09 Apr 2020 18:25:49 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 09 Apr 2020 18:25:49 +0200 X-ME-IP: 86.238.65.197 To: oauth References: From: Denis Message-ID: Date: Thu, 9 Apr 2020 18:25:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E16F839B93017BD34C9E2ED4" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 09 Apr 2020 16:25:54 -0000 This is a multi-part message in MIME format. --------------E16F839B93017BD34C9E2ED4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I have three concerns, two of them being related to privacy. 1) Privacy has not really been a concern in the WG since originally the AT and the RS were co-located. However, this draft now recognizes that there may exist cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated by some boundary". *In such cases*, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used: *Authorization servers SHALL not have the **capability to act as "Big Brother"* and thus SHALL not be able to know which resources are going to be accessed by clients. This means that, in such cases, an authorization server SHALL not be able to know for which resource server an AT has been targeted. It is a fact that most solutions currently deployed support a built-in *"Spy by desig**n"* architecture instead of a *"Privacy by design"* architecture. However, for security reasons an AT still needs to be targeted. The problem to be solved is the following: * for security reasons, the AT must be targeted. * for privacy reasons, the AS must be kept ignorant of the name of the target. One way to solve the problem is to consider that the AT is composed of a sequence of two structures: a signed structure and an unsigned structure. The signed structure contains a "salted aud claim". The unsigned structure contains a "aud salt claim". In practice, the "salted aud claim" will be composed of both a one way hash function algorithm identifier and a hash value. Before requesting an AT to an AS, the client chooses a resource server and select a resource indicator value corresponding to the identifier the resource server. It then chooses a random value which it uses as a "aud salt claim" and then computes a hash value by using a one-way hash function which combines one of the resource indicators of the RS with the "aud salt claim". Both the one way hash function algorithm identifier and the computed hash value are then included into the "salted aud claim". The AT request then contains a "salted aud claim" instead of an"aud claim". The AT blindly copies this value into the AT which is then identified as a "salted aud claim" instead of an "aud claim". When the AT is received by the client, it adds to the AT the unsigned part to the AT which contains the "aud salt claim" and sends both the signed and the unsigned part of the AT to the RS. When the RS receives the AT, using the one way hash function algorithm identifier contained in the "salted aud claim", it combines each of its resource indicators with the "aud salt claim" contained in the unsigned part of the AT and verifies whether it matches with the hash value contained in the "salted aud claim". If none of these resource indicators is providing a match, then the RS SHALL rejected the AT. The implication is to allow an AT to contain both a signed part and an unsigned part. In addition, the "aud claim" should be multi-valued where, as a consequence, both the "salted aud claim" with the "aud salt claim" would also be multi-valued. 2) Within clause 6, "Privacy Considerations", the text states: As JWT access tokens carry information by value, it now becomes possible for requestors and receivers 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 (...). On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch with the RS. Since there are now cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated by some boundary", a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop) This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions. In any case, the "MUST NOT" in the quoted sentence should be removed or changed or the whole sentence should be removed.. 3) Within clause 2.2.2 (second paragraph): This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking in consideration the client_id of the client, the scope and the resource parameters included in the request. Allowing a client to only specify a scope and a resource is very restrictive. What would be the title of an RFC that would allow the client to request the presence of specific claims in JWT access ? If such a restriction is kept, would the current title of this RFC still be inappropriate "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ? Denis DP Security Consulting --------------E16F839B93017BD34C9E2ED4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in "Spy by design" architecture instead of a "Privacy by design" architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  • for security reasons, the AT must be targeted.
  • for privacy reasons, the AS must be kept ignorant of the name of the target.

One way to solve the problem is to consider that the AT is composed of a sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource server and select a resource indicator value corresponding to the identifier the resource server.
It then chooses a random value which it uses as a "aud salt claim" and then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both the one way hash function algorithm identifier and the computed hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud claim". The AT blindly copies this value into the AT which is then identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned part to the AT which contains the "aud salt claim" and sends both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm identifier contained in the "salted aud claim", it combines each of its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and verifies whether it matches with the hash value contained in the "salted aud claim".
If none of these resource indicators is providing a match, then the RS SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an unsigned part.

In addition, the "aud claim" should be multi-valued where, as a consequence, both the "salted aud claim" with the "aud salt claim" would also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:

As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers 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 (...).

On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

This profile does not introduce any mechanism for a client to
directly request the presence of specific claims in JWT access
tokens, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Allowing a client to only specify a scope and a resource is very restrictive.

What would be the title of an RFC that would allow the client to request the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting

--------------E16F839B93017BD34C9E2ED4-- From nobody Thu Apr 9 10:07:17 2020 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 720113A0CD3 for ; Thu, 9 Apr 2020 10:07:16 -0700 (PDT) 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 (1024-bit key) header.d=adorsys.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 NQyB8tQ2t-_w for ; Thu, 9 Apr 2020 10:07:14 -0700 (PDT) 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 BEF113A0CCE for ; Thu, 9 Apr 2020 10:07:14 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id s13so189172lfb.9 for ; Thu, 09 Apr 2020 10:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LWKoP9davg3zptAp54o1xhv81QoYrPZgC/4I16NbNHM=; b=LvaWOhYPdBsLsH8N8JXAE60hlZe3+rXGB5hBvwh530eYcFRizvuU0IMCuE5T2JEXs7 axyeZi2mEtzbQYPUeUgm7cs7n0E1tuorcqxkjt6enA+AuECqeOUY3jVi32ZrfclnPTZx +NvXpYVPomTQX6VLtWhYU2eyMxqVaze267No0= 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=LWKoP9davg3zptAp54o1xhv81QoYrPZgC/4I16NbNHM=; b=HWYyF6terjjSskoDrKTh9P/YdFNcc/L8TRgU38VK9WYVd45dzpLXZsAp2bEi3T4HMJ h7WP6A9OV5JQb/l7eXCB2KaT1Uno4qSa2RV9Oox0Mr8Oek7QRiP9FUHpPET3cEt8HPvD QVY62XRRwNexvRJCixVuyvH287MnlZt6sWPcacfstfyLPrm8yxke17oDeGRz1aice5YY xqljylhwVN/pTngD/zU//L4PEgVMXZLZa2zDw15lFuhAF1ydlQ+eZUy8YU18xwAlAdnG vJ1LT9yEV8wT58UPQOyb5vOFGu4aodQmEr1bUcWQGU+kDdSo59miRQSn6azaG/6O+dlr BKRQ== X-Gm-Message-State: AGi0PubqDMKX/jngaw5xYsT3LH4q92ScQ9tWnaVf/0BbUiiMAQeim/X1 p/tTi4W5AXLBad5mVsNUiWGXPxcRDthlrX9ArmA2I9XSR58= X-Google-Smtp-Source: APiQypI3R/ey8VMxWKIXv667rUtzb5ztwsFWvqN96Ka0YDhF8dZZVz3LEG1VWbFkvAMNG/NiT1UgH6WhT7b4WX0C/cs= X-Received: by 2002:a05:6512:308e:: with SMTP id z14mr182917lfd.110.1586452032396; Thu, 09 Apr 2020 10:07:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Thu, 9 Apr 2020 13:07:01 -0400 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000d83b9505a2dea5be" Archived-At: Subject: Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1 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, 09 Apr 2020 17:07:17 -0000 --000000000000d83b9505a2dea5be Content-Type: text/plain; charset="UTF-8" > > > Am 09.04.20 um 09:55 schrieb Rob Otto: > > I'd imagine you have to pre-register each client and then use HOTP or > > TOTP to generate one-time passcodes.? > > > > I can come up with a couple of other ways as well, but I'm interested to > hear what Francis sees "in the wild". There are many ways of implementing "Direct Grant". We shall distinguish between approaches which reuse the ROPC-Flow as is, and those which require an extension of the ROPC-Flow (e.g. with initialization steps which return challenges). For a customer project we had it simply done with a TOPT without extension of the ROPC grant oAuth2.0. We extended AS to check {username, TOTP} instead of a permanent password. -> The login page embedded in the RP user agent displays a form requesting {username, TOTP} -> For registration and OTP setup we display a link to the AS (no redirect). -> Main purpose was mitigating hazard associated with user agent redirect. -> FreeOTP is the reference APP for OTP. Remember my initial message requested an alternative "DIRECT GRANT" flow (means WITHOUT REDIRECT). BTW: I went through Dick's reference https://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/. We might want to continue there or stay here if the foccuss shifts away of oAuth2.1. --000000000000d83b9505a2dea5be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Am 09.04.20 um 09:55 schrieb Rob Otto:
> I'd imagine you have to pre-register each client and then use HOTP= or
> TOTP to generate one-time passcodes.?
>

I can come up with a couple of other ways as well, but I'm interested t= o
hear what Francis sees "in the wild".
There are = many ways of implementing "Direct Grant". We shall distinguish be= tween approaches which reuse the ROPC-Flow as is, and those which require a= n extension of the ROPC-Flow (e.g. with initialization steps which return c= hallenges).
=C2=A0
For a customer project we had it simply done with a TOPT without extensio= n of the ROPC grant oAuth2.0. We extended AS to check {username, TOTP} inst= ead of a permanent password.
-> The login page embedded in the= RP user agent displays a form requesting {username, TOTP}
-> = For registration and OTP setup we display a link to the AS (no redirect).
-> Main purpose was mitigating hazard associated with user agen= t redirect.
-> FreeOTP is the reference APP for OTP.

Remember my initial message requested an alternative "= DIRECT GRANT" flow (means WITHOUT REDIRECT).

= BTW: I went through Dick's reference=C2=A0h= ttps://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/= . We might want to continue there or stay here if the foccuss shifts away o= f oAuth2.1.

--000000000000d83b9505a2dea5be-- From nobody Thu Apr 9 23:29:07 2020 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 C30093A1844 for ; Thu, 9 Apr 2020 23:29:05 -0700 (PDT) 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 V41eB2jtZN2x for ; Thu, 9 Apr 2020 23:29:02 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 AA4633A1845 for ; Thu, 9 Apr 2020 23:29:02 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id p8so614350pgi.5 for ; Thu, 09 Apr 2020 23:29:02 -0700 (PDT) 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 :mime-version; bh=FbFJKvcy5oR1jzw833FrarXVYUeXS0MGmD1IvUQqi94=; b=hnjI1jpOAAXLfNEfv16b4lj//Jooo9EkrNn075Gy3zaBZTBV51PDTACwP+WOeEr3CQ xO8etdVULHOT3qM5EdCIHSr4aSgj7lXojlwmqWLRU2nJB6/7D037SzNX4a5f5raMNfCB U74PjCC3jz2NsLuY0bBx09azAT7bGDc8qA5v0t6cWFIQTfzce3HQVSVmWIrIYrl2DR/u OTjWO3MzzdL+Pv/iCq//K8GCx19KlFY619tW8i4ry/uM8DkMCqm3gpgq3hAjiqu3pSxU Kya+nvW51lq9wDWZuuXktBXWcDCY8rUYTytloZO0L4If2zPJPYMDgQJC1R9j2ftRG98F HEEQ== 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 :mime-version; bh=FbFJKvcy5oR1jzw833FrarXVYUeXS0MGmD1IvUQqi94=; b=U1LENpz9jTO3G8loLK/4wwsQy9Gw8/Rnyicrtev5A4X6nD6eKAwNzT4W75T/WEG7+l KGzO7uGT5m+oIvkWgIwjuWq7IctQkHrjm9Fv7EUqJiaZwFzMnQfYlBe1DO09uQF7U7PE UCf9XR8FGUxxBngV4QhkoinWbzy/G+z8RyQZaXTqwQAsh6Ki4R0eW54gL6aGX+vX/eQH HOdw3RlFxvRc3XDLY0yd7noYTt0O0tVSwzgo/ZgyOSahW+SLkiLwZqp9172OczQzA2B9 OboFirU7vLwRDzUmOiYXG1q7b0ZWK5C5sJz+jzKw3DvGpO/QxotcXJXUlI/fKkRFkd8a lEfw== X-Gm-Message-State: AGi0PuZDjGr8E6RqXALRt8xdc2Hk6SVAkKEV+rBaH88mCmd7TJ7kRWv+ WcWW5fJLERUOSIwNRz9aD449oQXNhv8= X-Google-Smtp-Source: APiQypKAnVbhoeVbDsHchtZVrJ1pG3fKdCAKkin/SzdQUqhUZhy0mItKUiyTaXw7nYPXknv6CsPFdg== X-Received: by 2002:a62:2547:: with SMTP id l68mr3342129pfl.175.1586500141692; Thu, 09 Apr 2020 23:29:01 -0700 (PDT) Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id o3sm818425pgk.21.2020.04.09.23.29.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 23:29:00 -0700 (PDT) From: Vittorio Bertocci To: Denis , oauth Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Thread-Index: ATBEMUEzVgkZHyweZLG8Yidi1aurtmQ4ODA2yHPeXX4= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 10 Apr 2020 06:28:59 +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: multipart/alternative; boundary="_000_MWHPR19MB1501C653DA4955BAB101C315AEDE0MWHPR19MB1501namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 10 Apr 2020 06:29:06 -0000 --_000_MWHPR19MB1501C653DA4955BAB101C315AEDE0MWHPR19MB1501namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Denis, Thank you for your feedback! Inline > Privacy has not really been a concern in the WG since originally the AT a= nd the RS were co-located. Colocation of AS and RS was a frequent occurrence, but by no mean mandatory= =85 AFAIK one of the drivers for the changes between OAuth1 and OAuth2 was = providing the ability of supporting topologies where AS and RS are distinct= right out of the box. The scenario where AS and RS are distinct was always possible in Outh2, and= and not by accident. The JWT AT just happens to be particularly handy in e= mpowering the RS to validate incoming tokens without having to phone home t= o the AS every time, hence it gives the opportunity to discuss implications= of that scenario more in depth, but doesn=92t really introduce anything th= at wasn=92t possible before. Even the possibility of a token format passing= info by value isn=92t forbidden, default OAuth2 ATs are not mandatorily op= aque- they just happen not to have a well defined format. >In such cases, it is important to be able to make sure that an authorizati= on server will NOT be able to know where the authorizations tokens that it issues will be used. Using another wording, an AS SHALL NOT = be able to know where an AT requested by a given client will be used: Authorization servers SHALL not have the capability to act as "Big Brother"= and thus SHALL not be able to know which resources are going to be accessed by clients. The scenario in which a token issuer isn=92t aware of where the client will= spend the corresponding token is important, but it is more the province of= SSI than mainstream OAuth2 usage today. Mainstream OAuth2 in current use, regardless of the AT format, typically do= know for whom the token is being issued: a great deal of logic is predicat= ed on that knowledge. Did the user consent for this client to access this p= articular resource? Does access to this resource warrant presenting a stron= ger authentication prompt? Are there other authorization considerations tha= t influences whether the requested token should be issued? Those are consid= erations an AS need to be able to perform in the general case, regardless o= f the AT format. That doesn=92t mean they MUST be done in every case, but m= aking them impossible would deny a lot of very important scenarios for whic= h JWT ATs (and ATs in general) are used for today. The split structure you suggest is interesting, but I would recommend is en= shrined in its own spec (maybe in the SSI orbit) rather than in an interop = profile for the general AT case. >On the contrary, a client SHALL be able to inspect the content of the acce= ss token to make sure that the AS has not included in the AT some private i= nformation that should not be present, before forwarding the AT to the RS. It is possi= ble for an AS to change the format of the AT, but the RS will not necessari= ly be in synch with the RS. I can see the value in doing what we can to prevent abuses, but I find this= requirement problematic. The access token is an artifact meant to enable t= he client to access a resource. Its format remains a private matter between= the RS and the AS, which retains the freedom to change it as they see fit = without worrying about client code that takes a dependency on characteristi= cs of the AT that might very well be transient. As far the client is concer= ned, the RS and the AS might switch their agreement from JWT AT to opaque t= okens to be validated via introspection at any time, which would break any = client side logic inspecting the AT and expecting it to be a JWT. The clien= t has no control whatsoever on the content that is transmitted via opaque t= oken, hence privacy-wise the fact that the content of the JWT is visible is= more of a concern about such content being accessible on the client. One a= dditional point: even if clients would be able to safely peek inside an AT = without risking breaking their code, there=92s no guarantee that the client= would understand the semantic of the claims in the AT, as those are meant = for consumption by the RS which can assign any semantic to them; nor the cl= ient can reliably trust the content of the claims, given that the AS could = and sometimes will encrypt their content for the intended recipient (anothe= r reason for which the AS in the general case needs to know the intended re= cipient). >. It is possible for an AS to change the format of the AT, but the RS will= not necessarily be in synch with the RS. I don=92t understand this sentence. Is the last RS meant to be AS? Assuming that=92s the case: It doesn=92t look very likely that an RS would = simply accept tokens from an AS without some out of band negotiation, nor i= t seems very likely that an AS would issue tokens for resources it doesn=92= t know- see above. Such scenarios might exist, but they don=92t seem to mod= el common business solutions or the typical deployment, where an API will b= e protected by middleware/gateway with precise assumptions on how to valida= te incoming tokens. There might be changes that are inconsequential (order = of claims, additional claims) but anything more substantive would likely si= mply break the solution. > This means that an identifier of the profile of the AT should be able to = be included into the AT. This allows for future extensions. Can you expand on the exact scenario you are thinking of that calls for a v= ersion? If it=92s a matter of extensions, those should always be possible = =96 it=92s more breaking changes that require versioning, but I don=92t rec= all precedents in similar specs. If this is aimed at mitigating the =93AS changes format without telling RS= =94, I don=92t think that would work =96 besides of being unnecessary per t= he above considerations, this wouldn=92t protect the RS from changes well w= ithin the current spec (which allows adding arbitrary claims as long as it= =92s done according to JWT rules), from changes within the claim content (e= g private string formats) and from complete departures from the use of JWT = for ATs. > Allowing a client to only specify a scope and a resource is very restrict= ive. Specifying scope or using resource indicators are all the mechanisms I am a= ware of that OAuth2 offers for specifying what an access token should be fo= r- at least at the time in which the spec was incepted. In fact, resource i= ndicators was not even RFC and in market vendors used proprietary functiona= l equivalents. What other interoperable mechanisms would you offer in addit= ion to the ones listed here? From: OAuth on behalf of Denis Date: Thursday, April 9, 2020 at 09:26 To: oauth Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0= Access Tokens" I have three concerns, two of them being related to privacy. 1) Privacy has not really been a concern in the WG since originally the AT = and the RS were co-located. However, this draft now recognizes that there may exist cases where "the authorization server and resource ser= ver are not co-located, are not ran by the same entity, or are otherwise separated by some boundary". In such cases, it is important to be able to make sure that an authorizatio= n server will NOT be able to know where the authorizations tokens that it issues will be used. Using another wording, an AS SHALL NOT = be able to know where an AT requested by a given client will be used: Authorization servers SHALL not have the capability to act as "Big Brother"= and thus SHALL not be able to know which resources are going to be accessed by clients. This means that, in such cases, an authorization server SHALL not be able t= o know for which resource server an AT has been targeted. It is a fact that most solutions currently deployed support a built-in "Spy= by design" architecture instead of a "Privacy by design" architecture. However, for security reasons an AT still needs to be targeted. The problem to be solved is the following: * for security reasons, the AT must be targeted. * for privacy reasons, the AS must be kept ignorant of the name of the = target. One way to solve the problem is to consider that the AT is composed of a se= quence of two structures: a signed structure and an unsigned structure. The signed structure contains a "salted aud claim". The unsigned structure contains a "aud salt claim". In practice, the "salted aud claim" will be composed of both a one way hash= function algorithm identifier and a hash value. Before requesting an AT to an AS, the client chooses a resource server and = select a resource indicator value corresponding to the identifier the resou= rce server. It then chooses a random value which it uses as a "aud salt claim" and then= computes a hash value by using a one-way hash function which combines one of the resource indicators of the RS with the "aud salt claim". Both th= e one way hash function algorithm identifier and the computed hash value are then included into the "salted aud claim". The AT request then contains a "salted aud claim" instead of an"aud claim".= The AT blindly copies this value into the AT which is then identified as a "salted aud claim" instead of an "aud claim". When the AT is received by the client, it adds to the AT the unsigned part = to the AT which contains the "aud salt claim" and sends both the signed and the unsigned part of the AT to the RS. When the RS receives the AT, using the one way hash function algorithm iden= tifier contained in the "salted aud claim", it combines each of its resourc= e indicators with the "aud salt claim" contained in the unsigned part of the AT and veri= fies whether it matches with the hash value contained in the "salted aud cl= aim". If none of these resource indicators is providing a match, then the RS SHAL= L rejected the AT. The implication is to allow an AT to contain both a signed part and an unsi= gned part. In addition, the "aud claim" should be multi-valued where, as a consequence= , both the "salted aud claim" with the "aud salt claim" would also be multi= -valued. 2) Within clause 6, "Privacy Considerations", the text states: As JWT access tokens carry information by value, it now becomes possible for requestors and receivers 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 (...). On the contrary, a client SHALL be able to inspect the content of the acces= s token to make sure that the AS has not included in the AT some private in= formation that should not be present, before forwarding the AT to the RS. It is possi= ble for an AS to change the format of the AT, but the RS will not necessari= ly be in synch with the RS. Since there are now cases where "the authorization server and resource serv= er are not co-located, are not ran by the same entity, or are otherwise sep= arated by some boundary", a key point is that an AS and a RS DO NOT necessarily ne= ed to know each other. The RS only needs to trust the AS. (full stop) This means that an identifier of the profile of the AT should be able to be= included into the AT. This allows for future extensions. In any case, the "MUST NOT" in the quoted sentence should be removed or cha= nged or the whole sentence should be removed.. 3) Within clause 2.2.2 (second paragraph): This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking in consideration the client_id of the client, the scope and the resource parameters included in the request. Allowing a client to only specify a scope and a resource is very restrictiv= e. What would be the title of an RFC that would allow the client to request th= e presence of specific claims in JWT access ? If such a restriction is kept, would the current title of this RFC still be= inappropriate "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ? Denis DP Security Consulting --_000_MWHPR19MB1501C653DA4955BAB101C315AEDE0MWHPR19MB1501namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thank you for your feedback!

Inline

 

> Privacy has not really been a concern in the= WG since originally the AT and the RS were co-located.

Colocation of AS and RS was a frequent occurrence, b= ut by no mean mandatory=85 AFAIK one of the drivers for the changes between= OAuth1 and OAuth2 was providing the ability of supporting topologies where= AS and RS are distinct right out of the box.

The scenario where AS and RS are distinct was always= possible in Outh2, and and not by accident. The JWT AT just happens to be = particularly handy in empowering the RS to validate incoming tokens without= having to phone home to the AS every time, hence it gives the opportunity to discuss implications of that scena= rio more in depth, but doesn=92t really introduce anything that wasn=92t po= ssible before. Even the possibility of a token format passing info by value= isn=92t forbidden, default OAuth2 ATs are not mandatorily opaque- they just happen not to have a well defined fo= rmat.

 

>In such cases, it is important = to be able to make sure that an authorization server will NOT be able to kn= ow where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT = be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big = Brother" and thus SHALL not be able to know which resources are go= ing
to be accessed by clients.

The scenario in which a token issuer isn=92t aware o= f where the client will spend the corresponding token is important, but it = is more the province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format, typically do= know for whom the token is being issued: a great deal of logic is predicat= ed on that knowledge. Did the user consent for this client to access this p= articular resource? Does access to this resource warrant presenting a stronger authentication prompt? Are = there other authorization considerations that influences whether the reques= ted token should be issued? Those are considerations an AS need to be able = to perform in the general case, regardless of the AT format. That doesn=92t mean they MUST be done in ever= y case, but making them impossible would deny a lot of very important scena= rios for which JWT ATs (and ATs in general) are used for today.<= /p>

The split structure you suggest is interesting, but = I would recommend is enshrined in its own spec (maybe in the SSI orbit) rat= her than in an interop profile for the general AT case.

 

>On the contrary, a client SHALL be able to in= spect the content of the access token to make sure that the AS has not incl= uded in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possi= ble for an AS to change the format of the AT, but the RS will not necessari= ly be in synch
with the RS.

I can see the value in doing what we can to prevent = abuses, but I find this requirement problematic. The access token is an art= ifact meant to enable the client to access a resource. Its format remains a= private matter between the RS and the AS, which retains the freedom to change it as they see fit without wor= rying about client code that takes a dependency on characteristics of the A= T that might very well be transient. As far the client is concerned, the RS= and the AS might switch their agreement from JWT AT to opaque tokens to be validated via introspection at any time= , which would break any client side logic inspecting the AT and expecting i= t to be a JWT. The client has no control whatsoever on the content that is = transmitted via opaque token, hence privacy-wise the fact that the content of the JWT is visible is more of a = concern about such content being accessible on the client. One additional p= oint: even if clients would be able to safely peek inside an AT without ris= king breaking their code, there=92s no guarantee that the client would understand the semantic of the claims i= n the AT, as those are meant for consumption by the RS which can assign any= semantic to them; nor the client can reliably trust the content of the cla= ims, given that the AS could and sometimes will encrypt their content for the intended recipient (another r= eason for which the AS in the general case needs to know the intended recip= ient).

 

>. It is possible for an AS to change the form= at of the AT, but the RS will not necessarily be in synch with the RS.

I don=92t understand this sentence. Is the last RS m= eant to be AS?

Assuming that=92s the case: It doesn=92t look very l= ikely that an RS would simply accept tokens from an AS without some out of = band negotiation, nor it seems very likely that an AS would issue tokens fo= r resources it doesn=92t know- see above. Such scenarios might exist, but they don=92t seem to model common business= solutions or the typical deployment, where an API will be protected by mid= dleware/gateway with precise assumptions on how to validate incoming tokens= . There might be changes that are inconsequential (order of claims, additional claims) but anything more sub= stantive would likely simply break the solution.

 

> This means that an identifier of the profile= of the AT should be able to be included into the AT. This allows for futur= e extensions.

Can you expand on the exact scenario you are thinkin= g of that calls for a version? If it=92s a matter of extensions, those shou= ld always be possible =96 it=92s more breaking changes that require version= ing, but I don=92t recall precedents in similar specs.

If this is aimed at mitigating the =93AS changes for= mat without telling RS=94, I don=92t think that would work =96 besides of b= eing unnecessary per the above considerations, this wouldn=92t protect the = RS from changes well within the current spec (which allows adding arbitrary claims as long as it=92s done according to = JWT rules), from changes within the claim content (eg private string format= s) and from complete departures from the use of JWT for ATs.

 

> Allowing a client to only specify a scope and a resource is very re= strictive.

Specifying scope or using resource indicators are al= l the mechanisms I am aware of that OAuth2 offers for specifying what an ac= cess token should be for- at least at the time in which the spec was incept= ed. In fact, resource indicators was not even RFC and in market vendors used proprietary functional equivalents= . What other interoperable mechanisms would you offer in addition to the on= es listed here?

 

 

From= : OAuth <oauth-b= ounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
Date: Thursday, April 9, 2020 at 09:26
To: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile f= or OAuth 2.0 Access Tokens"

 

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the AT = and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resourc= e server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an autho= rization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT = be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big = Brother" and thus SHALL not be able to know which resources are go= ing
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not = be able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a buil= t-in "Spy by design" architecture instead of a "Privacy= by design" architecture.

However, for security reasons an AT still needs to be targeted.
The problem to be solved is the following:

  • for security reasons, the AT must be targeted.
  • for privacy reasons, the AS must be kept ignorant of the name of the target= .

One way to solve the problem is to consider that the AT is compose= d of a sequence of two structures: a signed structure and an unsigned struc= ture.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a on= e way hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource se= rver and select a resource indicator value corresponding to the identifier = the resource server.
It then chooses a random value which it uses as a "aud salt claim"= ; and then computes a hash value by using a one-way hash function which com= bines
one of the resource indicators of the RS with the "aud salt claim"= ;. Both the one way hash function algorithm identifier and the computed&nbs= p; hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instea= d of an"aud claim". The AT blindly copies this value into the AT = which is then identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsig= ned part to the AT which contains the "aud salt claim" and sends = both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm iden= tifier contained in the "salted aud claim", it combines each of i= ts resource indicators
with the "aud salt claim" contained in the unsigned part of the A= T and verifies whether it matches with the hash value contained in the &quo= t;salted aud claim".
If none of these resource indicators is providing a match, then the RS SHAL= L rejected the AT.

The implication is to allow an AT to contain both a signed part and an unsi= gned part.

In addition, the "aud claim" should be multi-valued where, as a c= onsequence, both the "salted aud claim" with the "aud salt c= laim" would also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:
   As JWT access tokens carry information by value, it now become= s
   possible for requestors and receivers 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 se= rver
   might decide to change token format at any time (...).

On the contrary, a client SHALL be able to inspect the content of the acces= s token to make sure that the AS has not included in the AT some private in= formation
that should not be present, before forwarding the AT to the RS. It is possi= ble for an AS to change the format of the AT, but the RS will not necessari= ly be in synch
with the RS.

Since there are now cases where "the authorization server and resource= server are not co-located, are not ran by the same entity, or are otherwis= e separated
by some boundary", a key point is that an AS and a RS DO NOT necessari= ly need to know each other. The RS only needs to trust the AS. (full stop)<= br>
This means that an identifier of the profile of the AT should be able to be= included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be remo= ved or changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

   This profile does not introduce any mechanism for a client to<= br>    directly request the presence of specific claims in JWT access=
   tokens, as the authorization server can determine what additio= nal
   claims are required by a particular resource server by taking = in
   consideration the client_id of the client, the scope and the r= esource
   parameters included in the request.

Allowing a client to only specify a scope and a resource is very restrictiv= e.

What would be the title of an RFC that would allow the client to request th= e presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still be= inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting

--_000_MWHPR19MB1501C653DA4955BAB101C315AEDE0MWHPR19MB1501namp_-- From nobody Fri Apr 10 02:07:43 2020 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 B19173A1A6E for ; Fri, 10 Apr 2020 02:07:41 -0700 (PDT) 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.398, 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 LreESQYkEH_3 for ; Fri, 10 Apr 2020 02:07:38 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E1B3A1A69 for ; Fri, 10 Apr 2020 02:07:37 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d38 with ME id Qx7Z2200J4FMSmm03x7ZbT; Fri, 10 Apr 2020 11:07:35 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 10 Apr 2020 11:07:35 +0200 X-ME-IP: 86.238.65.197 To: Vittorio Bertocci , oauth References: From: Denis Message-ID: <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr> Date: Fri, 10 Apr 2020 11:07:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CEA99C6E8BA4A3B775161A4C" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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, 10 Apr 2020 09:07:42 -0000 This is a multi-part message in MIME format. --------------CEA99C6E8BA4A3B775161A4C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Vittorio, Thank you for your fast response. You wrote: "/It doesnt look very likely that an RS would simply accept tokens from an AS without some out of band negotiatio/n, " and also: "/As far the client is concerned, the RS and the AS might switch their agreement/" With such sentences, it seems that you mandate a direct negotiation between the AS and the RS which, by implication, means that the AS and the RS must know each other, which is exactly what I want to avoid. Such some out of band negotiation can simply be done by publishing which AT formats the AS is able to generate and which AT formats the RS is able to accept. An AS can publish metadata relevant to the JWT access tokens it issues and a RS can do the same. In this way, the client could consult both published lists and choose which common format, if any, would be appropriate. This means that the client should be able in its AT request to specify the format of the AT, thus avoiding any direct some out of band negotiation between the AS and the RS. You continue saying: " /nor it seems very likely that an AS would issue tokens for resources it doesnt know/". This is where we have a major difference in our points of views. The number of AS is likely to be several order of magnitudes higher compared to the number of RS. Every time a RS is being established, it should not have to make itself known to any AS. This is why I wrote: /"a key point is that an AS and a RS DO NOT necessarily need to know each other. *The RS only needs to trust the AS*/*.*/(full stop)"/ You are assuming that an AS and a RS necessarily need to know each other. You wrote: "/The scenario in which a token issuer isnt aware of where the client will spend the corresponding token is important, but it is more the province of SSI than mainstream OAuth2 usage today"./ Today, as soon as an AT is targeted, the AS will be aware where the client is likely to spend the AT. The reality is that the scenario in which a token issuer will not be aware of where the client will spend the corresponding token is today completely out of the scope of OAuth2 usages (unfortunately, it is not a matter of mainstream or not). For that reason, if the spec. continues to prevent to implement "Privacy by design" architectures and worse, mandates "Spy by design" architectures, this should be clearly advertised in the Privacy Considerations section. You recommend to specify the split AT structure I suggest in its own spec rather than in an interop profile for the general AT case. The current title of the document is: "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens". The content of the document is much more than what the title implies since the introduction states : "Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how determine the content of the issued JWT access token, how an authorization server can publish metadata relevant to the JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens". The document specifies a protocol with severe limitations in the authorization requests parameters and with severe limitations for the validation of AT. If the spec. stays like that, it should rather be called: * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0 Access Tokens". In the future, a true Profile for OAuth 2.0 Access Tokens could then be written. The case where a client would be able to inspect the content of a generated AT, indeed comes into contradiction with the case where the AS would encrypt its content for the intended recipient and you advocate that it is another reason "for which the AS in the general case needs to know the intended recipient". It is not the general case, but a specific case, which is more difficult to deploy than the simplest case where RS only need to know the AS that they trust. It is a trade off /for the client/ to be able to inspect itself the AT of to make sure that only the RS will be able to inspect the AT. I wrote: "This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions." You replied: "Can you expand on the exact scenario you are thinking of that calls for a version?" Identifier formats for AT should be able to be included into : * the metadata published by the AS, * the metadata published by the RS, and * the AT itself. The sketch of the scenario would be as follows. The client consults both the metadata published by the AS and the metadata published by the RS and tries to find matches between token formats. If there are several matches, it will choose,if possible, a match where it can access and understand the content of the AT. It will then inform the AS of its choice by adding the identifier of the profile of the AT in the AT request. The AS will also include the identifier of the profile of the AT in the AT so that the RS, when it receives the AT, can unambiguously decode the AT. Finally, I will copy the end of your email. > Allowing a client to only specify a scope and a resource is very restrictive. Specifying scope or using resource indicators are all the mechanisms I am aware of that OAuth2 offers for specifying what an access token should be for - at least at the time in which the spec was incepted. (...) . What other interoperable mechanisms would you offer in addition to the ones listed here? The client should be able to specify in its AT request additional attributes whose semantic is well described by the attributes description found in section 5.1 of [OpenID.Core] or the attributes description found in [RFC7662] or other identity related specifications. *Another new and last comment*: it is quite odd that there is no formal description of an AT profile anywhere in the current document. A syntax description would greatly enhance interoperability. Denis > Hi Denis, > > Thank you for your feedback! > > Inline > > /> Privacy has not really been a concern in the WG since originally > the AT and the RS were co-located./ > > Colocation of AS and RS was a frequent occurrence, but by no mean > mandatory AFAIK one of the drivers for the changes between OAuth1 and > OAuth2 was providing the ability of supporting topologies where AS and > RS are distinct right out of the box. > > The scenario where AS and RS are distinct was always possible in > Outh2, and and not by accident. The JWT AT just happens to be > particularly handy in empowering the RS to validate incoming tokens > without having to phone home to the AS every time, hence it gives the > opportunity to discuss implications of that scenario more in depth, > but doesnt really introduce anything that wasnt possible before. > Even the possibility of a token format passing info by value isnt > forbidden, default OAuth2 ATs are not mandatorily opaque- they just > happen not to have a well defined format. > > */>In such cases/*/, it is important to be able to make sure that an > authorization server will NOT be able to know where the authorizations > tokens that it issues will be used. Using another wording, an AS SHALL > NOT be able to know where an AT requested by a given client will be used: > *Authorization servers SHALL not have the capability to act as "Big > Brother"* and thus SHALL not be able to know which resources are going > to be accessed by clients./ > > The scenario in which a token issuer isnt aware of where the client > will spend the corresponding token is important, but it is more the > province of SSI than mainstream OAuth2 usage today. > Mainstream OAuth2 in current use, regardless of the AT format, > typically do know for whom the token is being issued: a great deal of > logic is predicated on that knowledge. Did the user consent for this > client to access this particular resource? Does access to this > resource warrant presenting a stronger authentication prompt? Are > there other authorization considerations that influences whether the > requested token should be issued? Those are considerations an AS need > to be able to perform in the general case, regardless of the AT > format. That doesnt mean they MUST be done in every case, but making > them impossible would deny a lot of very important scenarios for which > JWT ATs (and ATs in general) are used for today. > > The split structure you suggest is interesting, but I would recommend > is enshrined in its own spec (maybe in the SSI orbit) rather than in > an interop profile for the general AT case. > > />On the contrary, a client SHALL be able to inspect the content of > the access token to make sure that the AS has not included in the AT > some private information > that should not be present, before forwarding the AT to the RS. It is > possible for an AS to change the format of the AT, but the RS will not > necessarily be in synch > with the RS./// > > I can see the value in doing what we can to prevent abuses, but I find > this requirement problematic. The access token is an artifact meant to > enable the client to access a resource. Its format remains a private > matter between the RS and the AS, which retains the freedom to change > it as they see fit without worrying about client code that takes a > dependency on characteristics of the AT that might very well be > transient. As far the client is concerned, the RS and the AS might > switch their agreement from JWT AT to opaque tokens to be validated > via introspection at any time, which would break any client side logic > inspecting the AT and expecting it to be a JWT. The client has no > control whatsoever on the content that is transmitted via opaque > token, hence privacy-wise the fact that the content of the JWT is > visible is more of a concern about such content being accessible on > the client. One additional point: even if clients would be able to > safely peek inside an AT without risking breaking their code, theres > no guarantee that the client would understand the semantic of the > claims in the AT, as those are meant for consumption by the RS which > can assign any semantic to them; nor the client can reliably trust the > content of the claims, given that the AS could and sometimes will > encrypt their content for the intended recipient (another reason for > which the AS in the general case needs to know the intended recipient). > > />. It is possible for an AS to change the format of the AT, but the > RS will not necessarily be in synch with the RS. / > > I dont understand this sentence. Is the last RS meant to be AS? > > Assuming thats the case: It doesnt look very likely that an RS would > simply accept tokens from an AS without some out of band negotiation, > nor it seems very likely that an AS would issue tokens for resources > it doesnt know- see above. Such scenarios might exist, but they dont > seem to model common business solutions or the typical deployment, > where an API will be protected by middleware/gateway with precise > assumptions on how to validate incoming tokens. There might be changes > that are inconsequential (order of claims, additional claims) but > anything more substantive would likely simply break the solution. > > /> This means that an identifier of the profile of the AT should be > able to be included into the AT. This allows for future extensions./// > > Can you expand on the exact scenario you are thinking of that calls > for a version? If its a matter of extensions, those should always be > possible its more breaking changes that require versioning, but I > dont recall precedents in similar specs. > > If this is aimed at mitigating the AS changes format without telling > RS, I dont think that would work besides of being unnecessary per > the above considerations, this wouldnt protect the RS from changes > well within the current spec (which allows adding arbitrary claims as > long as its done according to JWT rules), from changes within the > claim content (eg private string formats) and from complete departures > from the use of JWT for ATs. > > />//Allowing a client to only specify a scope and a resource is very > restrictive./ > > Specifying scope or using resource indicators are all the mechanisms I > am aware of that OAuth2 offers for specifying what an access token > should be for- at least at the time in which the spec was incepted. In > fact, resource indicators was not even RFC and in market vendors used > proprietary functional equivalents. What other interoperable > mechanisms would you offer in addition to the ones listed here? > > *From: *OAuth on behalf of Denis > > *Date: *Thursday, April 9, 2020 at 09:26 > *To: *oauth > *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for > OAuth 2.0 Access Tokens" > > I have three concerns, two of them being related to privacy. > > 1) Privacy has not really been a concern in the WG since originally > the AT and the RS were co-located. However, this draft now recognizes > that there may exist cases where "the authorization server and > resource server are not co-located, are not ran by the same entity, > or are otherwise separated by some boundary". > > *In such cases*, it is important to be able to make sure that an > authorization server will NOT be able to know where the authorizations > tokens that it issues will be used. Using another wording, an AS SHALL > NOT be able to know where an AT requested by a given client will be used: > *Authorization servers SHALL not have the capability to act as "Big > Brother"* and thus SHALL not be able to know which resources are going > to be accessed by clients. > > This means that, in such cases, an authorization server SHALL not be > able to know for which resource server an AT has been targeted. > > It is a fact that most solutions currently deployed support a built-in > *"Spy by design"* architecture instead of a *"Privacy by design"* > architecture. > > However, for security reasons an AT still needs to be targeted. > > The problem to be solved is the following: > > * for security reasons, the AT must be targeted. > * for privacy reasons, the AS must be kept ignorant of the name of > the target. > > One way to solve the problem is to consider that the AT is composed of > a sequence of two structures: a signed structure and an unsigned > structure. > > The signed structure contains a "salted aud claim". > The unsigned structure contains a "aud salt claim". > > In practice, the "salted aud claim" will be composed of both a one way > hash function algorithm identifier and a hash value. > > Before requesting an AT to an AS, the client chooses a resource server > and select a resource indicator value corresponding to the identifier > the resource server. > It then chooses a random value which it uses as a "aud salt claim" and > then computes a hash value by using a one-way hash function which > combines > one of the resource indicators of the RS with the "aud salt claim". > Both the one way hash function algorithm identifier and the computed > hash value > are then included into the "salted aud claim". > > The AT request then contains a "salted aud claim" instead of an"aud > claim". The AT blindly copies this value into the AT which is then > identified as > a "salted aud claim" instead of an "aud claim". > > When the AT is received by the client, it adds to the AT the unsigned > part to the AT which contains the "aud salt claim" and sends both the > signed > and the unsigned part of the AT to the RS. > > When the RS receives the AT, using the one way hash function algorithm > identifier contained in the "salted aud claim", it combines each of > its resource indicators > with the "aud salt claim" contained in the unsigned part of the AT and > verifies whether it matches with the hash value contained in the > "salted aud claim". > If none of these resource indicators is providing a match, then the RS > SHALL rejected the AT. > > The implication is to allow an AT to contain both a signed part and an > unsigned part. > > In addition, the "aud claim" should be multi-valued where, as a > consequence, both the "salted aud claim" with the "aud salt claim" > would also be multi-valued. > > > 2) Within clause 6, "Privacy Considerations", the text states: > > As JWT access tokens carry information by value, it now becomes > possible for requestors and receivers 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 (...). > > On the contrary, a client SHALL be able to inspect the content of the > access token to make sure that the AS has not included in the AT some > private information > that should not be present, before forwarding the AT to the RS. It is > possible for an AS to change the format of the AT, but the RS will not > necessarily be in synch > with the RS. > > Since there are now cases where "the authorization server and resource > server are not co-located, are not ran by the same entity, or are > otherwise separated > by some boundary", a key point is that an AS and a RS DO NOT > necessarily need to know each other. The RS only needs to trust the > AS. (full stop) > > This means that an identifier of the profile of the AT should be able > to be included into the AT. This allows for future extensions. > > In any case, the "MUST NOT" in the quoted sentence should be removed > or changed or the whole sentence should be removed.. > > > 3) Within clause 2.2.2 (second paragraph): > > This profile does not introduce any mechanism for a client to > directly request the presence of specific claims in JWT access > tokens, as the authorization server can determine what additional > claims are required by a particular resource server by taking in > consideration the client_id of the client, the scope and the resource > parameters included in the request. > > Allowing a client to only specify a scope and a resource is very > restrictive. > > What would be the title of an RFC that would allow the client to > request the presence of specific claims in JWT access ? > > If such a restriction is kept, would the current title of this RFC > still be inappropriate > "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ? > > Denis > > DP Security Consulting > --------------CEA99C6E8BA4A3B775161A4C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Vittorio,

Thank you for your fast response.

You wrote:
"It doesnt look very likely that an RS would simply accept tokens from an AS without some out of band negotiation, "
and also:
"As far the client is concerned, the RS and the AS might switch their agreement"
With such sentences, it seems that you mandate a direct negotiation between the AS and the RS which, by implication,
means that the AS and the RS must know each other, which is exactly what I want to avoid. Such some out of band negotiation
can simply be done by publishing which AT formats the AS is able to generate and which AT formats the RS is able to accept.
An AS can publish metadata relevant to the JWT access tokens it issues and a RS can do the same.

In this way, the client could consult both published lists and choose which common format, if any, would be appropriate.
This means that the client should be able in its AT request to specify the format of the AT, thus avoiding any direct some
out of band negotiation between the AS and the RS.

You continue saying:
" nor it seems very likely that an AS would issue tokens for resources it doesnt know".
This is where we have a major difference in our points of views. The number of AS is likely to be several order of magnitudes higher
compared to the number of RS. Every time a RS is being established, it should not have to make itself known to any AS.

This is why I wrote:
"a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop)"
You are assuming that an AS and a RS necessarily need to know each other.

You wrote:
"The scenario in which a token issuer isnt aware of where the client will spend the corresponding token is important,
but it is more the province of SSI than mainstream OAuth2 usage today".
Today, as soon as an AT is targeted, the AS will be aware where the client is likely to spend the AT. The reality is that the scenario
in which a token issuer will not be aware of where the client will spend the corresponding token is today completely out of the scope
of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).

For that reason, if the spec. continues to prevent to implement "Privacy by design" architectures and worse, mandates "Spy by design"
architectures, this should be clearly advertised in the Privacy Considerations section.

You recommend to specify the split AT structure I suggest in its own spec rather than in an interop profile for the general AT case.
The current title of the document is: "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens". The content of the document
is much more than what the title implies since the introduction states :
"Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how determine the content of
the issued JWT access token, how an authorization server can publish metadata relevant to the JWT access tokens it issues, and how
a resource server should validate incoming JWT access tokens".
The document specifies a protocol with severe limitations in the authorization requests parameters and with severe limitations for the validation of AT.
If the spec. stays like that, it should rather be called:
  • "JSON Web Token (JWT) Basic Protocol for OAuth 2.0 Access Tokens" or
  • "JSON Web Token (JWT) Basic Protocol and Profile for OAuth 2.0 Access Tokens".

In the future, a true Profile for OAuth 2.0 Access Tokens could then be written.

The case where a client would be able to inspect the content of a generated AT, indeed comes into contradiction with the case where the AS would encrypt
its content for the intended recipient and you advocate that it is another reason "for which the AS in the general case needs to know the intended recipient".
It is not the general case, but a specific case, which is more difficult to deploy than the simplest case where RS only need to know the AS that they trust.
It is a trade off for the client to be able to inspect itself the AT of to make sure that only the RS will be able to inspect the AT.

I wrote:
"This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions."
You replied:
"Can you expand on the exact scenario you are thinking of that calls for a version?"
Identifier formats for AT should be able to be included into :
  • the metadata published by the AS,
  • the metadata published by the RS, and
  • the AT itself.

The sketch of the scenario would be as follows.

The client consults both the metadata published by the AS and the metadata published by the RS and tries to find matches between token formats.
If there are several matches, it will choose,if possible, a match where it can access and understand the content of the AT. It will then inform the AS
of its choice by adding the identifier of the profile of the AT in the AT request. The AS will also include the identifier of the profile of the AT in the AT
so that the RS, when it receives the AT, can unambiguously decode the AT.

Finally, I will copy the end of your email.
> Allowing a client to only specify a scope and a resource is very restrictive.
Specifying scope or using resource indicators are all the mechanisms I am aware of that OAuth2 offers for specifying what an access token
should be for - at least at the time in which the spec was incepted. (...) .

What other interoperable mechanisms would you offer in addition to the ones listed here?
The client should be able to specify in its AT request additional attributes whose semantic is well described by the attributes description
found in section 5.1 of [OpenID.Core] or the attributes description found in [RFC7662] or other identity related specifications.

Another new and last comment: it is quite odd that there is no formal description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis

Hi Denis,

Thank you for your feedback!

Inline

> Privacy has not really been a concern in the WG since originally the AT and the RS were co-located.

Colocation of AS and RS was a frequent occurrence, but by no mean mandatory AFAIK one of the drivers for the changes between OAuth1 and OAuth2 was providing the ability of supporting topologies where AS and RS are distinct right out of the box.

The scenario where AS and RS are distinct was always possible in Outh2, and and not by accident. The JWT AT just happens to be particularly handy in empowering the RS to validate incoming tokens without having to phone home to the AS every time, hence it gives the opportunity to discuss implications of that scenario more in depth, but doesnt really introduce anything that wasnt possible before. Even the possibility of a token format passing info by value isnt forbidden, default OAuth2 ATs are not mandatorily opaque- they just happen not to have a well defined format.

>In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.

The scenario in which a token issuer isnt aware of where the client will spend the corresponding token is important, but it is more the province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format, typically do know for whom the token is being issued: a great deal of logic is predicated on that knowledge. Did the user consent for this client to access this particular resource? Does access to this resource warrant presenting a stronger authentication prompt? Are there other authorization considerations that influences whether the requested token should be issued? Those are considerations an AS need to be able to perform in the general case, regardless of the AT format. That doesnt mean they MUST be done in every case, but making them impossible would deny a lot of very important scenarios for which JWT ATs (and ATs in general) are used for today.

The split structure you suggest is interesting, but I would recommend is enshrined in its own spec (maybe in the SSI orbit) rather than in an interop profile for the general AT case.

>On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.

I can see the value in doing what we can to prevent abuses, but I find this requirement problematic. The access token is an artifact meant to enable the client to access a resource. Its format remains a private matter between the RS and the AS, which retains the freedom to change it as they see fit without worrying about client code that takes a dependency on characteristics of the AT that might very well be transient. As far the client is concerned, the RS and the AS might switch their agreement from JWT AT to opaque tokens to be validated via introspection at any time, which would break any client side logic inspecting the AT and expecting it to be a JWT. The client has no control whatsoever on the content that is transmitted via opaque token, hence privacy-wise the fact that the content of the JWT is visible is more of a concern about such content being accessible on the client. One additional point: even if clients would be able to safely peek inside an AT without risking breaking their code, theres no guarantee that the client would understand the semantic of the claims in the AT, as those are meant for consumption by the RS which can assign any semantic to them; nor the client can reliably trust the content of the claims, given that the AS could and sometimes will encrypt their content for the intended recipient (another reason for which the AS in the general case needs to know the intended recipient).

>. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch with the RS.

I dont understand this sentence. Is the last RS meant to be AS?

Assuming thats the case: It doesnt look very likely that an RS would simply accept tokens from an AS without some out of band negotiation, nor it seems very likely that an AS would issue tokens for resources it doesnt know- see above. Such scenarios might exist, but they dont seem to model common business solutions or the typical deployment, where an API will be protected by middleware/gateway with precise assumptions on how to validate incoming tokens. There might be changes that are inconsequential (order of claims, additional claims) but anything more substantive would likely simply break the solution.

> This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.

Can you expand on the exact scenario you are thinking of that calls for a version? If its a matter of extensions, those should always be possible its more breaking changes that require versioning, but I dont recall precedents in similar specs.

If this is aimed at mitigating the AS changes format without telling RS, I dont think that would work besides of being unnecessary per the above considerations, this wouldnt protect the RS from changes well within the current spec (which allows adding arbitrary claims as long as its done according to JWT rules), from changes within the claim content (eg private string formats) and from complete departures from the use of JWT for ATs.

> Allowing a client to only specify a scope and a resource is very restrictive.

Specifying scope or using resource indicators are all the mechanisms I am aware of that OAuth2 offers for specifying what an access token should be for- at least at the time in which the spec was incepted. In fact, resource indicators was not even RFC and in market vendors used proprietary functional equivalents. What other interoperable mechanisms would you offer in addition to the ones listed here?

From: OAuth <oauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
Date: Thursday, April 9, 2020 at 09:26
To: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in "Spy by design" architecture instead of a "Privacy by design" architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  • for security reasons, the AT must be targeted.
  • for privacy reasons, the AS must be kept ignorant of the name of the target.

One way to solve the problem is to consider that the AT is composed of a sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource server and select a resource indicator value corresponding to the identifier the resource server.
It then chooses a random value which it uses as a "aud salt claim" and then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both the one way hash function algorithm identifier and the computed hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud claim". The AT blindly copies this value into the AT which is then identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned part to the AT which contains the "aud salt claim" and sends both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm identifier contained in the "salted aud claim", it combines each of its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and verifies whether it matches with the hash value contained in the "salted aud claim".
If none of these resource indicators is providing a match, then the RS SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an unsigned part.

In addition, the "aud claim" should be multi-valued where, as a consequence, both the "salted aud claim" with the "aud salt claim" would also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:

As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers 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 (...).

On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

This profile does not introduce any mechanism for a client to
directly request the presence of specific claims in JWT access
tokens, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Allowing a client to only specify a scope and a resource is very restrictive.

What would be the title of an RFC that would allow the client to request the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting


--------------CEA99C6E8BA4A3B775161A4C-- From nobody Fri Apr 10 06:35:19 2020 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 7CC663A0A3D; Fri, 10 Apr 2020 06:35:17 -0700 (PDT) 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 8ISsd49WsrlB; Fri, 10 Apr 2020 06:35:16 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBEF3A0A3C; Fri, 10 Apr 2020 06:35:15 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id w1so1734871iot.7; Fri, 10 Apr 2020 06:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WXRU0hV8wlYRHjDX9j6iXM2/KjSihyev+nfZ1jgu/qA=; b=gg94RMHXKkn2sGFXZQGJ6fQG0+AqqBu/qBmeg6NANsh5Ro1VkGxnd+LdTBGLdLfJyc P0GrpysRh4amWuYHVEj/h78i51HHy1SmFWH2xet4Ygpc8bzxxDvI1Ijb/FVG3BDanJS8 +Mbx/99Y2qtNxEjTlx9g81Mni7ZgKoGsa6eNrZpJCYCBrm98wyUYcGTGeE4UN+X+EZEt E92MRGKsn5apsouD2eoZ7pOxfe0tynaWy04uXY7ASwN37RMNd+Q4gye7qmDqujpbDyqK Zl8ZhSQj7smmt/s3AQDnlQKxEUmMLm0rP32ad+4CL6dvJMz99aqAUapUXKiTFgSJ9sz8 CrmA== 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=WXRU0hV8wlYRHjDX9j6iXM2/KjSihyev+nfZ1jgu/qA=; b=QSig3KFERibwKTMOCR0d9wyt89oPbDXk1A93jwoG/KIt0Ij2WKe75rCOyyGC2M7It7 DkP2MoXj9riaoaRAq216oRk5ALmXZ+WpaeSMDeEQdCZ6oApRQIc9YrpuMmYBrRrdiVkp oh4GDXjcRo+4U0XLcxdZZoIGevfUKnPL4jmqDPE8RpKftKo+6pGKnE8/xp6VQ6Zj6oZh v8xlTvjR2rLRQE6lSTQwgttq2Rkw6z54/NnB7XB3fo5Nqw0PnfTx3r12AWU8v0dlmaoF fow+eLVnqoc1tKCLmAVNHd2DLrO6O4pGov93df+KnHixbWH/cdp1l5WF9SsaZVJZzqyd Sgjg== X-Gm-Message-State: AGi0Pub4qkV4aznW6e8inMSZPgdn4hJeeyNzL9sX0hn+qfINLnvfAXEN bWIghmI/dY4JRqnb8HRLnsztcp5tOjJONqWxIDC8vfg3 X-Google-Smtp-Source: APiQypJjX4B1xOQ1Zods9L1YCerMJ/ZAYi+u70syQrHU2RKMKK7O/YFm1jRvvyi+MsdJ4H2B/p87j9BTL+o1/M4yUD8= X-Received: by 2002:a05:6602:224d:: with SMTP id o13mr2070711ioo.147.1586525714873; Fri, 10 Apr 2020 06:35:14 -0700 (PDT) MIME-Version: 1.0 References: <158628195716.9275.10690808358259357603@ietfa.amsl.com> In-Reply-To: <158628195716.9275.10690808358259357603@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Fri, 10 Apr 2020 09:35:04 -0400 Message-ID: To: IESG Secretary Cc: IETF-Announce , oauth Content-Type: multipart/alternative; boundary="000000000000a9800a05a2efcd56" Archived-At: Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Fri, 10 Apr 2020 13:35:18 -0000 --000000000000a9800a05a2efcd56 Content-Type: text/plain; charset="UTF-8" The following is a link to the coming interim meeting materials: https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth It has the chairs and Nested JWT slides. Will upload the JWT Profile for AT slides as soon as I get it. Regards, Rifaat On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary wrote: > The Web Authorization Protocol (oauth) Working Group will hold > a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 > America/Toronto (16:00 to 17:00 UTC). > > Agenda: > 1. Nested JWT > https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt > > 2. JWT Profile for Access Tokens > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a9800a05a2efcd56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The following is a link to the coming interim meeting mate= rials:

It has the = chairs and Nested JWT slides.
Will upload the JWT Profile for AT = slides as soon as I get it.

Regards,
=C2= =A0Rifaat
=C2=A0

On Tue, Apr 7, 2020 at 1:52 PM IESG Secreta= ry <iesg-secretary@ietf.org> wrote:
Th= e Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 America/Toronto= (16:00 to 17:00 UTC).

Agenda:
1. Nested JWT
https://www.ietf.org/archive/id/d= raft-yusef-oauth-nested-jwt-03.txt

2. JWT Profile for Access Tokens
https://datatracker.ietf.org/doc/= draft-ietf-oauth-access-token-jwt/

Information about remote participation:
https://ietf.webex.com/iet= f/j.php?MTID=3Dm776932cd87f84cbceb34ae907027b0f0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a9800a05a2efcd56-- From nobody Sat Apr 11 19:15:05 2020 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 8281A3A1BF5 for ; Sat, 11 Apr 2020 19:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QPVeEbQuHsCl for ; Sat, 11 Apr 2020 19:14:57 -0700 (PDT) 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 C93623A1BF4 for ; Sat, 11 Apr 2020 19:14:56 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03C2EnnY023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Apr 2020 22:14:51 -0400 Date: Sat, 11 Apr 2020 19:14:49 -0700 From: Benjamin Kaduk To: Denis Cc: Vittorio Bertocci , oauth Message-ID: <20200412021449.GM88064@mit.edu> References: <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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: Sun, 12 Apr 2020 02:15:04 -0000 Hi Denis, I am going to top-post because the quoting in this thread has become pretty mangled. First off, thank you for calling out the text in the document about scenarios where "the authorization server and resource server are not co-located, are not run by the same entity, or are otherwise separated by some boundary"; this does indeed present some consequences for the privacy considerations of the protocol that will need to be addressed in some manner, though not necessarily the one that you envision. I will try to remember to check for this point when the document progresses to IESG Evaluation. You outline some interesting protocol proposals, such as letting the client choose the token profile type, mandating (in at least some cases) visibility into the token contents for the client, and letting the client add additional token parameters in its request, but it seems pretty clear to me that while these would make for an interesting protocol, that protocol would fundamentally not be OAuth 2.0. As such, it doesn't seem appropriate to attempt to require them as part of this specific document. I would also note that framing things as a contrast between "privacy by design" and "spy by design" seems designed to evoke an emotional reaction, and as such are actively harmful to rational technical debate. I implore you to focus on the facts of what data flows where and which aspects of such flows are desirable and undesirable in the various situations under consideration. Finally, I'll note that though I am mostly just an observer here and not an implementor, it's my sense that OAuth 2.0 as currently deployed involves a relatively large number of RSes speaking to a comparable or smaller number of ASes, and that it is common for AS implementations to have significant amounts of logic dedicated to knowing the capabilities of the RSes they serve. Many of your comments do not seem consistent with this worldview, and I invite the other WG participants to clarify if my understanding is incorrect. Thanks, Ben On Fri, Apr 10, 2020 at 11:07:35AM +0200, Denis wrote: > Hi Vittorio, > > Thank you for your fast response. > > You wrote: > > "/It doesn’t look very likely that an RS would simply accept tokens > from an AS without some out of band negotiatio/n, " > > and also: > > "/As far the client is concerned, the RS and the AS might switch > their agreement/" > > With such sentences, it seems that you mandate a direct negotiation > between the AS and the RS which, by implication, > means that the AS and the RS must know each other, which is exactly what > I want to avoid. Such some out of band negotiation > can simply be done by publishing which AT formats the AS is able to > generate and which AT formats the RS is able to accept. > An AS can publish metadata relevant to the JWT access tokens it issues > and a RS can do the same. > > In this way, the client could consult both published lists and choose > which common format, if any, would be appropriate. > This means that the client should be able in its AT request to specify > the format of the AT, thus avoiding any direct some > out of band negotiation between the AS and the RS. > > You continue saying: > > " /nor it seems very likely that an AS would issue tokens for > resources it doesn’t know/". > > This is where we have a major difference in our points of views. The > number of AS is likely to be several order of magnitudes higher > compared to the number of RS. Every time a RS is being established, it > should not have to make itself known to any AS. > > This is why I wrote: > > /"a key point is that an AS and a RS DO NOT necessarily need to know > each other. *The RS only needs to trust the AS*/*.*/(full stop)"/ > > You are assuming that an AS and a RS necessarily need to know each other. > > You wrote: > > "/The scenario in which a token issuer isn’t aware of where the > client will spend the corresponding token is important, > but it is more the province of SSI than mainstream OAuth2 usage today"./ > > Today, as soon as an AT is targeted, the AS will be aware where the > client is likely to spend the AT. The reality is that the scenario > in which a token issuer will not be aware of where the client will spend > the corresponding token is today completely out of the scope > of OAuth2 usages (unfortunately, it is not a matter of mainstream or not). > > For that reason, if the spec. continues to prevent to implement "Privacy > by design" architectures and worse, mandates "Spy by design" > architectures, this should be clearly advertised in the Privacy > Considerations section. > > You recommend to specify the split AT structure I suggest in its own > spec rather than in an interop profile for the general AT case. > The current title of the document is: "JSON Web Token (JWT) Profile for > OAuth 2.0 Access Tokens". The content of the document > is much more than what the title implies since the introduction states : > > "Besides defining a common set of mandatory and optional claims, the > profile provides clear indications on how determine the content of > the issued JWT access token, how an authorization server can publish > metadata relevant to the JWT access tokens it issues, and how > a resource server should validate incoming JWT access tokens". > > The document specifies a protocol with severe limitations in the > authorization requests parameters and with severe limitations for the > validation of AT. > If the spec. stays like that, it should rather be called: > > * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or > * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0 > Access Tokens". > > > In the future, a true Profile for OAuth 2.0 Access Tokens could then be > written. > > The case where a client would be able to inspect the content of a > generated AT, indeed comes into contradiction with the case where the AS > would encrypt > its content for the intended recipient and you advocate that it is > another reason "for which the AS in the general case needs to know the > intended recipient". > It is not the general case, but a specific case, which is more difficult > to deploy than the simplest case where RS only need to know the AS that > they trust. > It is a trade off /for the client/ to be able to inspect itself the AT > of to make sure that only the RS will be able to inspect the AT. > > I wrote: > > "This means that an identifier of the profile of the AT should be > able to be included into the AT. This allows for future extensions." > > You replied: > > "Can you expand on the exact scenario you are thinking of that calls > for a version?" > > Identifier formats for AT should be able to be included into : > > * the metadata published by the AS, > * the metadata published by the RS, and > * the AT itself. > > > The sketch of the scenario would be as follows. > > The client consults both the metadata published by the AS and the > metadata published by the RS and tries to find matches between token > formats. > If there are several matches, it will choose,if possible, a match where > it can access and understand the content of the AT. It will then inform > the AS > of its choice by adding the identifier of the profile of the AT in the > AT request. The AS will also include the identifier of the profile of > the AT in the AT > so that the RS, when it receives the AT, can unambiguously decode the AT. > > Finally, I will copy the end of your email. > > > Allowing a client to only specify a scope and a resource is very > restrictive. > Specifying scope or using resource indicators are all the mechanisms > I am aware of that OAuth2 offers for specifying what an access token > should be for - at least at the time in which the spec was incepted. > (...) . > > What other interoperable mechanisms would you offer in addition to > the ones listed here? > > The client should be able to specify in its AT request additional > attributes whose semantic is well described by the attributes description > found in section 5.1 of [OpenID.Core] or the attributes description > found in [RFC7662] or other identity related specifications. > > *Another new and last comment*: it is quite odd that there is no formal > description of an AT profile anywhere in the current document. > A syntax description would greatly enhance interoperability. > > Denis > > > Hi Denis, > > > > Thank you for your feedback! > > > > Inline > > > > /> Privacy has not really been a concern in the WG since originally > > the AT and the RS were co-located./ > > > > Colocation of AS and RS was a frequent occurrence, but by no mean > > mandatory… AFAIK one of the drivers for the changes between OAuth1 and > > OAuth2 was providing the ability of supporting topologies where AS and > > RS are distinct right out of the box. > > > > The scenario where AS and RS are distinct was always possible in > > Outh2, and and not by accident. The JWT AT just happens to be > > particularly handy in empowering the RS to validate incoming tokens > > without having to phone home to the AS every time, hence it gives the > > opportunity to discuss implications of that scenario more in depth, > > but doesn’t really introduce anything that wasn’t possible before. > > Even the possibility of a token format passing info by value isn’t > > forbidden, default OAuth2 ATs are not mandatorily opaque- they just > > happen not to have a well defined format. > > > > */>In such cases/*/, it is important to be able to make sure that an > > authorization server will NOT be able to know where the authorizations > > tokens that it issues will be used. Using another wording, an AS SHALL > > NOT be able to know where an AT requested by a given client will be used: > > *Authorization servers SHALL not have the capability to act as "Big > > Brother"* and thus SHALL not be able to know which resources are going > > to be accessed by clients./ > > > > The scenario in which a token issuer isn’t aware of where the client > > will spend the corresponding token is important, but it is more the > > province of SSI than mainstream OAuth2 usage today. > > Mainstream OAuth2 in current use, regardless of the AT format, > > typically do know for whom the token is being issued: a great deal of > > logic is predicated on that knowledge. Did the user consent for this > > client to access this particular resource? Does access to this > > resource warrant presenting a stronger authentication prompt? Are > > there other authorization considerations that influences whether the > > requested token should be issued? Those are considerations an AS need > > to be able to perform in the general case, regardless of the AT > > format. That doesn’t mean they MUST be done in every case, but making > > them impossible would deny a lot of very important scenarios for which > > JWT ATs (and ATs in general) are used for today. > > > > The split structure you suggest is interesting, but I would recommend > > is enshrined in its own spec (maybe in the SSI orbit) rather than in > > an interop profile for the general AT case. > > > > />On the contrary, a client SHALL be able to inspect the content of > > the access token to make sure that the AS has not included in the AT > > some private information > > that should not be present, before forwarding the AT to the RS. It is > > possible for an AS to change the format of the AT, but the RS will not > > necessarily be in synch > > with the RS./// > > > > I can see the value in doing what we can to prevent abuses, but I find > > this requirement problematic. The access token is an artifact meant to > > enable the client to access a resource. Its format remains a private > > matter between the RS and the AS, which retains the freedom to change > > it as they see fit without worrying about client code that takes a > > dependency on characteristics of the AT that might very well be > > transient. As far the client is concerned, the RS and the AS might > > switch their agreement from JWT AT to opaque tokens to be validated > > via introspection at any time, which would break any client side logic > > inspecting the AT and expecting it to be a JWT. The client has no > > control whatsoever on the content that is transmitted via opaque > > token, hence privacy-wise the fact that the content of the JWT is > > visible is more of a concern about such content being accessible on > > the client. One additional point: even if clients would be able to > > safely peek inside an AT without risking breaking their code, there’s > > no guarantee that the client would understand the semantic of the > > claims in the AT, as those are meant for consumption by the RS which > > can assign any semantic to them; nor the client can reliably trust the > > content of the claims, given that the AS could and sometimes will > > encrypt their content for the intended recipient (another reason for > > which the AS in the general case needs to know the intended recipient). > > > > />. It is possible for an AS to change the format of the AT, but the > > RS will not necessarily be in synch with the RS. / > > > > I don’t understand this sentence. Is the last RS meant to be AS? > > > > Assuming that’s the case: It doesn’t look very likely that an RS would > > simply accept tokens from an AS without some out of band negotiation, > > nor it seems very likely that an AS would issue tokens for resources > > it doesn’t know- see above. Such scenarios might exist, but they don’t > > seem to model common business solutions or the typical deployment, > > where an API will be protected by middleware/gateway with precise > > assumptions on how to validate incoming tokens. There might be changes > > that are inconsequential (order of claims, additional claims) but > > anything more substantive would likely simply break the solution. > > > > /> This means that an identifier of the profile of the AT should be > > able to be included into the AT. This allows for future extensions./// > > > > Can you expand on the exact scenario you are thinking of that calls > > for a version? If it’s a matter of extensions, those should always be > > possible – it’s more breaking changes that require versioning, but I > > don’t recall precedents in similar specs. > > > > If this is aimed at mitigating the “AS changes format without telling > > RS”, I don’t think that would work – besides of being unnecessary per > > the above considerations, this wouldn’t protect the RS from changes > > well within the current spec (which allows adding arbitrary claims as > > long as it’s done according to JWT rules), from changes within the > > claim content (eg private string formats) and from complete departures > > from the use of JWT for ATs. > > > > />//Allowing a client to only specify a scope and a resource is very > > restrictive./ > > > > Specifying scope or using resource indicators are all the mechanisms I > > am aware of that OAuth2 offers for specifying what an access token > > should be for- at least at the time in which the spec was incepted. In > > fact, resource indicators was not even RFC and in market vendors used > > proprietary functional equivalents. What other interoperable > > mechanisms would you offer in addition to the ones listed here? > > > > *From: *OAuth on behalf of Denis > > > > *Date: *Thursday, April 9, 2020 at 09:26 > > *To: *oauth > > *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for > > OAuth 2.0 Access Tokens" > > > > I have three concerns, two of them being related to privacy. > > > > 1) Privacy has not really been a concern in the WG since originally > > the AT and the RS were co-located. However, this draft now recognizes > > that there may exist cases where "the authorization server and > > resource server are not co-located, are not ran by the same entity, > > or are otherwise separated by some boundary". > > > > *In such cases*, it is important to be able to make sure that an > > authorization server will NOT be able to know where the authorizations > > tokens that it issues will be used. Using another wording, an AS SHALL > > NOT be able to know where an AT requested by a given client will be used: > > *Authorization servers SHALL not have the capability to act as "Big > > Brother"* and thus SHALL not be able to know which resources are going > > to be accessed by clients. > > > > This means that, in such cases, an authorization server SHALL not be > > able to know for which resource server an AT has been targeted. > > > > It is a fact that most solutions currently deployed support a built-in > > *"Spy by design"* architecture instead of a *"Privacy by design"* > > architecture. > > > > However, for security reasons an AT still needs to be targeted. > > > > The problem to be solved is the following: > > > > * for security reasons, the AT must be targeted. > > * for privacy reasons, the AS must be kept ignorant of the name of > > the target. > > > > One way to solve the problem is to consider that the AT is composed of > > a sequence of two structures: a signed structure and an unsigned > > structure. > > > > The signed structure contains a "salted aud claim". > > The unsigned structure contains a "aud salt claim". > > > > In practice, the "salted aud claim" will be composed of both a one way > > hash function algorithm identifier and a hash value. > > > > Before requesting an AT to an AS, the client chooses a resource server > > and select a resource indicator value corresponding to the identifier > > the resource server. > > It then chooses a random value which it uses as a "aud salt claim" and > > then computes a hash value by using a one-way hash function which > > combines > > one of the resource indicators of the RS with the "aud salt claim". > > Both the one way hash function algorithm identifier and the computed  > > hash value > > are then included into the "salted aud claim". > > > > The AT request then contains a "salted aud claim" instead of an"aud > > claim". The AT blindly copies this value into the AT which is then > > identified as > > a "salted aud claim" instead of an "aud claim". > > > > When the AT is received by the client, it adds to the AT the unsigned > > part to the AT which contains the "aud salt claim" and sends both the > > signed > > and the unsigned part of the AT to the RS. > > > > When the RS receives the AT, using the one way hash function algorithm > > identifier contained in the "salted aud claim", it combines each of > > its resource indicators > > with the "aud salt claim" contained in the unsigned part of the AT and > > verifies whether it matches with the hash value contained in the > > "salted aud claim". > > If none of these resource indicators is providing a match, then the RS > > SHALL rejected the AT. > > > > The implication is to allow an AT to contain both a signed part and an > > unsigned part. > > > > In addition, the "aud claim" should be multi-valued where, as a > > consequence, both the "salted aud claim" with the "aud salt claim" > > would also be multi-valued. > > > > > > 2) Within clause 6, "Privacy Considerations", the text states: > > > >    As JWT access tokens carry information by value, it now becomes > >    possible for requestors and receivers 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 (...). > > > > On the contrary, a client SHALL be able to inspect the content of the > > access token to make sure that the AS has not included in the AT some > > private information > > that should not be present, before forwarding the AT to the RS. It is > > possible for an AS to change the format of the AT, but the RS will not > > necessarily be in synch > > with the RS. > > > > Since there are now cases where "the authorization server and resource > > server are not co-located, are not ran by the same entity, or are > > otherwise separated > > by some boundary", a key point is that an AS and a RS DO NOT > > necessarily need to know each other. The RS only needs to trust the > > AS. (full stop) > > > > This means that an identifier of the profile of the AT should be able > > to be included into the AT. This allows for future extensions. > > > > In any case, the "MUST NOT" in the quoted sentence should be removed > > or changed or the whole sentence should be removed.. > > > > > > 3) Within clause 2.2.2 (second paragraph): > > > >    This profile does not introduce any mechanism for a client to > >    directly request the presence of specific claims in JWT access > >    tokens, as the authorization server can determine what additional > >    claims are required by a particular resource server by taking in > >    consideration the client_id of the client, the scope and the resource > >    parameters included in the request. > > > > Allowing a client to only specify a scope and a resource is very > > restrictive. > > > > What would be the title of an RFC that would allow the client to > > request the presence of specific claims in JWT access ? > > > > If such a restriction is kept, would the current title of this RFC > > still be inappropriate > > "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ? > > > > Denis > > > > DP Security Consulting > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sun Apr 12 08:47:19 2020 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 6B41F3A0E9D for ; Sun, 12 Apr 2020 08:47:16 -0700 (PDT) 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.398, 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 0wUyQFsYOk5A for ; Sun, 12 Apr 2020 08:47:13 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1090F3A0E9B for ; Sun, 12 Apr 2020 08:47:10 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d55 with ME id Rrn22200X4FMSmm03rn61B; Sun, 12 Apr 2020 17:47:08 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Sun, 12 Apr 2020 17:47:08 +0200 X-ME-IP: 86.238.65.197 To: Benjamin Kaduk Cc: Vittorio Bertocci , oauth References: <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr> <20200412021449.GM88064@mit.edu> From: Denis Message-ID: <370dcb87-17c1-cc06-f724-5ee19a9b0d6a@free.fr> Date: Sun, 12 Apr 2020 17:47:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200412021449.GM88064@mit.edu> Content-Type: multipart/alternative; boundary="------------D1CEED51ED51298D92FBB61C" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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: Sun, 12 Apr 2020 15:47:17 -0000 This is a multi-part message in MIME format. --------------D1CEED51ED51298D92FBB61C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Benjamin, Since there is tomorrow a virtual meeting and additionally I am locked down, by exception, I reply today. We both agree that when the authorization server and resource server are not co-located, are not run by the same entity, or are otherwise separated by some boundary" this does indeed present some consequences for the privacy considerations of the protocol that will need to be addressed in some manner. Today OAuth 2.0 has not been constructed taking into consideration this case, i.e. it has not been designed taking into consideration "Privacy by Design". The fact is that OAuth 2.0 has nothing specific to take care of privacy principles. There would be a simple way to solve some of my concerns: to remove in the Introduction (Section 1) lines 7 to 10 :    The approach is particularly common in    topologies where the authorization server and resource server are not    co-located, are not ran by the same entity, or are otherwise    separated by some boundary. Let us now assume that privacy concerns would be addressed in either OAuth 2.1. or OAuth 3.0. This spec. is supposed to be targeted to OAuth 2.0 but the header at the top of the page omits to mention it. Currently, it is : Internet-Draft       OAuth Access Token JWT Profile           March 2020 It should rather be: Internet-Draft       OAuth *2.0* Access Token JWT Profile           March 2020 There is however a problem to be solved now: to allow to easily distinguish between OAuth 2.0 JWT and future JWT versions. In addition, there will be the need to be able to carry unsigned parameters associated with an OAuth 2.1. or OAuth 3.0 JWT. An historical example was to be able to distinguish the version of a X.509 public key certificate using a version parameter. Something similar should be done. Section 6 (Privacy Considerations) should be modified. The MUST NOT (inspect the content of the access token) should be removed. Some text, like the following text, should be added: In topologies where the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated by some boundary, some privacy concerns arise. For security reasons, some clients may want to target their access tokens but, for privacy reasons, may be unwilling to disclose to authorization servers an identification of the resource servers they will access, so that authorisation servers will be unable to know which resources servers are being accessed. This profile does not contain provisions to address this case. For data minimization, openness and transparency, some clients may want to be able to specify with a fine granularity which of their identity attributes should be incorporated into an access token and may want verify that only the requested identity attributes have indeed been incorporated. This profile supports a scope parameter that allows to specify in advance which identity attributes should be incorporated, but the semantics of this parameter is specific to every authorisation server. Presently, there is not standardized way to define, with a fine granularity, which identity attributes will be incorporated into an access token. My last new comment remains valid: it is quite odd that there is no formal description of an AT profile anywhere in the current document. A syntax description would greatly enhance interoperability. Denis > Hi Denis, > > I am going to top-post because the quoting in this thread has become pretty > mangled. > > First off, thank you for calling out the text in the document about > scenarios where "the authorization server and resource server are not > co-located, are not run by the same entity, or are otherwise separated by > some boundary"; this does indeed present some consequences for the privacy > considerations of the protocol that will need to be addressed in some > manner, though not necessarily the one that you envision. I will try to > remember to check for this point when the document progresses to IESG > Evaluation. > > You outline some interesting protocol proposals, such as letting the client > choose the token profile type, mandating (in at least some cases) > visibility into the token contents for the client, and letting the client > add additional token parameters in its request, but it seems pretty clear > to me that while these would make for an interesting protocol, that > protocol would fundamentally not be OAuth 2.0. As such, it doesn't seem > appropriate to attempt to require them as part of this specific document. > > I would also note that framing things as a contrast between "privacy by > design" and "spy by design" seems designed to evoke an emotional reaction, > and as such are actively harmful to rational technical debate. I implore > you to focus on the facts of what data flows where and which aspects of > such flows are desirable and undesirable in the various situations under > consideration. > > Finally, I'll note that though I am mostly just an observer here and not an > implementor, it's my sense that OAuth 2.0 as currently deployed involves a > relatively large number of RSes speaking to a comparable or smaller number of > ASes, and that it is common for AS implementations to have significant > amounts of logic dedicated to knowing the capabilities of the RSes they > serve. Many of your comments do not seem consistent with this worldview, > and I invite the other WG participants to clarify if my understanding is > incorrect. > > Thanks, > > Ben > > On Fri, Apr 10, 2020 at 11:07:35AM +0200, Denis wrote: >> Hi Vittorio, >> >> Thank you for your fast response. >> >> You wrote: >> >> "/It doesn’t look very likely that an RS would simply accept tokens >> from an AS without some out of band negotiatio/n, " >> >> and also: >> >> "/As far the client is concerned, the RS and the AS might switch >> their agreement/" >> >> With such sentences, it seems that you mandate a direct negotiation >> between the AS and the RS which, by implication, >> means that the AS and the RS must know each other, which is exactly what >> I want to avoid. Such some out of band negotiation >> can simply be done by publishing which AT formats the AS is able to >> generate and which AT formats the RS is able to accept. >> An AS can publish metadata relevant to the JWT access tokens it issues >> and a RS can do the same. >> >> In this way, the client could consult both published lists and choose >> which common format, if any, would be appropriate. >> This means that the client should be able in its AT request to specify >> the format of the AT, thus avoiding any direct some >> out of band negotiation between the AS and the RS. >> >> You continue saying: >> >> " /nor it seems very likely that an AS would issue tokens for >> resources it doesn’t know/". >> >> This is where we have a major difference in our points of views. The >> number of AS is likely to be several order of magnitudes higher >> compared to the number of RS. Every time a RS is being established, it >> should not have to make itself known to any AS. >> >> This is why I wrote: >> >> /"a key point is that an AS and a RS DO NOT necessarily need to know >> each other. *The RS only needs to trust the AS*/*.*/(full stop)"/ >> >> You are assuming that an AS and a RS necessarily need to know each other. >> >> You wrote: >> >> "/The scenario in which a token issuer isn’t aware of where the >> client will spend the corresponding token is important, >> but it is more the province of SSI than mainstream OAuth2 usage today"./ >> >> Today, as soon as an AT is targeted, the AS will be aware where the >> client is likely to spend the AT. The reality is that the scenario >> in which a token issuer will not be aware of where the client will spend >> the corresponding token is today completely out of the scope >> of OAuth2 usages (unfortunately, it is not a matter of mainstream or not). >> >> For that reason, if the spec. continues to prevent to implement "Privacy >> by design" architectures and worse, mandates "Spy by design" >> architectures, this should be clearly advertised in the Privacy >> Considerations section. >> >> You recommend to specify the split AT structure I suggest in its own >> spec rather than in an interop profile for the general AT case. >> The current title of the document is: "JSON Web Token (JWT) Profile for >> OAuth 2.0 Access Tokens". The content of the document >> is much more than what the title implies since the introduction states : >> >> "Besides defining a common set of mandatory and optional claims, the >> profile provides clear indications on how determine the content of >> the issued JWT access token, how an authorization server can publish >> metadata relevant to the JWT access tokens it issues, and how >> a resource server should validate incoming JWT access tokens". >> >> The document specifies a protocol with severe limitations in the >> authorization requests parameters and with severe limitations for the >> validation of AT. >> If the spec. stays like that, it should rather be called: >> >> * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or >> * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0 >> Access Tokens". >> >> >> In the future, a true Profile for OAuth 2.0 Access Tokens could then be >> written. >> >> The case where a client would be able to inspect the content of a >> generated AT, indeed comes into contradiction with the case where the AS >> would encrypt >> its content for the intended recipient and you advocate that it is >> another reason "for which the AS in the general case needs to know the >> intended recipient". >> It is not the general case, but a specific case, which is more difficult >> to deploy than the simplest case where RS only need to know the AS that >> they trust. >> It is a trade off /for the client/ to be able to inspect itself the AT >> of to make sure that only the RS will be able to inspect the AT. >> >> I wrote: >> >> "This means that an identifier of the profile of the AT should be >> able to be included into the AT. This allows for future extensions." >> >> You replied: >> >> "Can you expand on the exact scenario you are thinking of that calls >> for a version?" >> >> Identifier formats for AT should be able to be included into : >> >> * the metadata published by the AS, >> * the metadata published by the RS, and >> * the AT itself. >> >> >> The sketch of the scenario would be as follows. >> >> The client consults both the metadata published by the AS and the >> metadata published by the RS and tries to find matches between token >> formats. >> If there are several matches, it will choose,if possible, a match where >> it can access and understand the content of the AT. It will then inform >> the AS >> of its choice by adding the identifier of the profile of the AT in the >> AT request. The AS will also include the identifier of the profile of >> the AT in the AT >> so that the RS, when it receives the AT, can unambiguously decode the AT. >> >> Finally, I will copy the end of your email. >> >> > Allowing a client to only specify a scope and a resource is very >> restrictive. >> Specifying scope or using resource indicators are all the mechanisms >> I am aware of that OAuth2 offers for specifying what an access token >> should be for - at least at the time in which the spec was incepted. >> (...) . >> >> What other interoperable mechanisms would you offer in addition to >> the ones listed here? >> >> The client should be able to specify in its AT request additional >> attributes whose semantic is well described by the attributes description >> found in section 5.1 of [OpenID.Core] or the attributes description >> found in [RFC7662] or other identity related specifications. >> >> *Another new and last comment*: it is quite odd that there is no formal >> description of an AT profile anywhere in the current document. >> A syntax description would greatly enhance interoperability. >> >> Denis >> >>> Hi Denis, >>> >>> Thank you for your feedback! >>> >>> Inline >>> >>> /> Privacy has not really been a concern in the WG since originally >>> the AT and the RS were co-located./ >>> >>> Colocation of AS and RS was a frequent occurrence, but by no mean >>> mandatory… AFAIK one of the drivers for the changes between OAuth1 and >>> OAuth2 was providing the ability of supporting topologies where AS and >>> RS are distinct right out of the box. >>> >>> The scenario where AS and RS are distinct was always possible in >>> Outh2, and and not by accident. The JWT AT just happens to be >>> particularly handy in empowering the RS to validate incoming tokens >>> without having to phone home to the AS every time, hence it gives the >>> opportunity to discuss implications of that scenario more in depth, >>> but doesn’t really introduce anything that wasn’t possible before. >>> Even the possibility of a token format passing info by value isn’t >>> forbidden, default OAuth2 ATs are not mandatorily opaque- they just >>> happen not to have a well defined format. >>> >>> */>In such cases/*/, it is important to be able to make sure that an >>> authorization server will NOT be able to know where the authorizations >>> tokens that it issues will be used. Using another wording, an AS SHALL >>> NOT be able to know where an AT requested by a given client will be used: >>> *Authorization servers SHALL not have the capability to act as "Big >>> Brother"* and thus SHALL not be able to know which resources are going >>> to be accessed by clients./ >>> >>> The scenario in which a token issuer isn’t aware of where the client >>> will spend the corresponding token is important, but it is more the >>> province of SSI than mainstream OAuth2 usage today. >>> Mainstream OAuth2 in current use, regardless of the AT format, >>> typically do know for whom the token is being issued: a great deal of >>> logic is predicated on that knowledge. Did the user consent for this >>> client to access this particular resource? Does access to this >>> resource warrant presenting a stronger authentication prompt? Are >>> there other authorization considerations that influences whether the >>> requested token should be issued? Those are considerations an AS need >>> to be able to perform in the general case, regardless of the AT >>> format. That doesn’t mean they MUST be done in every case, but making >>> them impossible would deny a lot of very important scenarios for which >>> JWT ATs (and ATs in general) are used for today. >>> >>> The split structure you suggest is interesting, but I would recommend >>> is enshrined in its own spec (maybe in the SSI orbit) rather than in >>> an interop profile for the general AT case. >>> >>> />On the contrary, a client SHALL be able to inspect the content of >>> the access token to make sure that the AS has not included in the AT >>> some private information >>> that should not be present, before forwarding the AT to the RS. It is >>> possible for an AS to change the format of the AT, but the RS will not >>> necessarily be in synch >>> with the RS./// >>> >>> I can see the value in doing what we can to prevent abuses, but I find >>> this requirement problematic. The access token is an artifact meant to >>> enable the client to access a resource. Its format remains a private >>> matter between the RS and the AS, which retains the freedom to change >>> it as they see fit without worrying about client code that takes a >>> dependency on characteristics of the AT that might very well be >>> transient. As far the client is concerned, the RS and the AS might >>> switch their agreement from JWT AT to opaque tokens to be validated >>> via introspection at any time, which would break any client side logic >>> inspecting the AT and expecting it to be a JWT. The client has no >>> control whatsoever on the content that is transmitted via opaque >>> token, hence privacy-wise the fact that the content of the JWT is >>> visible is more of a concern about such content being accessible on >>> the client. One additional point: even if clients would be able to >>> safely peek inside an AT without risking breaking their code, there’s >>> no guarantee that the client would understand the semantic of the >>> claims in the AT, as those are meant for consumption by the RS which >>> can assign any semantic to them; nor the client can reliably trust the >>> content of the claims, given that the AS could and sometimes will >>> encrypt their content for the intended recipient (another reason for >>> which the AS in the general case needs to know the intended recipient). >>> >>> />. It is possible for an AS to change the format of the AT, but the >>> RS will not necessarily be in synch with the RS. / >>> >>> I don’t understand this sentence. Is the last RS meant to be AS? >>> >>> Assuming that’s the case: It doesn’t look very likely that an RS would >>> simply accept tokens from an AS without some out of band negotiation, >>> nor it seems very likely that an AS would issue tokens for resources >>> it doesn’t know- see above. Such scenarios might exist, but they don’t >>> seem to model common business solutions or the typical deployment, >>> where an API will be protected by middleware/gateway with precise >>> assumptions on how to validate incoming tokens. There might be changes >>> that are inconsequential (order of claims, additional claims) but >>> anything more substantive would likely simply break the solution. >>> >>> /> This means that an identifier of the profile of the AT should be >>> able to be included into the AT. This allows for future extensions./// >>> >>> Can you expand on the exact scenario you are thinking of that calls >>> for a version? If it’s a matter of extensions, those should always be >>> possible – it’s more breaking changes that require versioning, but I >>> don’t recall precedents in similar specs. >>> >>> If this is aimed at mitigating the “AS changes format without telling >>> RS”, I don’t think that would work – besides of being unnecessary per >>> the above considerations, this wouldn’t protect the RS from changes >>> well within the current spec (which allows adding arbitrary claims as >>> long as it’s done according to JWT rules), from changes within the >>> claim content (eg private string formats) and from complete departures >>> from the use of JWT for ATs. >>> >>> />//Allowing a client to only specify a scope and a resource is very >>> restrictive./ >>> >>> Specifying scope or using resource indicators are all the mechanisms I >>> am aware of that OAuth2 offers for specifying what an access token >>> should be for- at least at the time in which the spec was incepted. In >>> fact, resource indicators was not even RFC and in market vendors used >>> proprietary functional equivalents. What other interoperable >>> mechanisms would you offer in addition to the ones listed here? >>> >>> *From: *OAuth on behalf of Denis >>> >>> *Date: *Thursday, April 9, 2020 at 09:26 >>> *To: *oauth >>> *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for >>> OAuth 2.0 Access Tokens" >>> >>> I have three concerns, two of them being related to privacy. >>> >>> 1) Privacy has not really been a concern in the WG since originally >>> the AT and the RS were co-located. However, this draft now recognizes >>> that there may exist cases where "the authorization server and >>> resource server are not co-located, are not ran by the same entity, >>> or are otherwise separated by some boundary". >>> >>> *In such cases*, it is important to be able to make sure that an >>> authorization server will NOT be able to know where the authorizations >>> tokens that it issues will be used. Using another wording, an AS SHALL >>> NOT be able to know where an AT requested by a given client will be used: >>> *Authorization servers SHALL not have the capability to act as "Big >>> Brother"* and thus SHALL not be able to know which resources are going >>> to be accessed by clients. >>> >>> This means that, in such cases, an authorization server SHALL not be >>> able to know for which resource server an AT has been targeted. >>> >>> It is a fact that most solutions currently deployed support a built-in >>> *"Spy by design"* architecture instead of a *"Privacy by design"* >>> architecture. >>> >>> However, for security reasons an AT still needs to be targeted. >>> >>> The problem to be solved is the following: >>> >>> * for security reasons, the AT must be targeted. >>> * for privacy reasons, the AS must be kept ignorant of the name of >>> the target. >>> >>> One way to solve the problem is to consider that the AT is composed of >>> a sequence of two structures: a signed structure and an unsigned >>> structure. >>> >>> The signed structure contains a "salted aud claim". >>> The unsigned structure contains a "aud salt claim". >>> >>> In practice, the "salted aud claim" will be composed of both a one way >>> hash function algorithm identifier and a hash value. >>> >>> Before requesting an AT to an AS, the client chooses a resource server >>> and select a resource indicator value corresponding to the identifier >>> the resource server. >>> It then chooses a random value which it uses as a "aud salt claim" and >>> then computes a hash value by using a one-way hash function which >>> combines >>> one of the resource indicators of the RS with the "aud salt claim". >>> Both the one way hash function algorithm identifier and the computed >>> hash value >>> are then included into the "salted aud claim". >>> >>> The AT request then contains a "salted aud claim" instead of an"aud >>> claim". The AT blindly copies this value into the AT which is then >>> identified as >>> a "salted aud claim" instead of an "aud claim". >>> >>> When the AT is received by the client, it adds to the AT the unsigned >>> part to the AT which contains the "aud salt claim" and sends both the >>> signed >>> and the unsigned part of the AT to the RS. >>> >>> When the RS receives the AT, using the one way hash function algorithm >>> identifier contained in the "salted aud claim", it combines each of >>> its resource indicators >>> with the "aud salt claim" contained in the unsigned part of the AT and >>> verifies whether it matches with the hash value contained in the >>> "salted aud claim". >>> If none of these resource indicators is providing a match, then the RS >>> SHALL rejected the AT. >>> >>> The implication is to allow an AT to contain both a signed part and an >>> unsigned part. >>> >>> In addition, the "aud claim" should be multi-valued where, as a >>> consequence, both the "salted aud claim" with the "aud salt claim" >>> would also be multi-valued. >>> >>> >>> 2) Within clause 6, "Privacy Considerations", the text states: >>> >>>    As JWT access tokens carry information by value, it now becomes >>>    possible for requestors and receivers 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 (...). >>> >>> On the contrary, a client SHALL be able to inspect the content of the >>> access token to make sure that the AS has not included in the AT some >>> private information >>> that should not be present, before forwarding the AT to the RS. It is >>> possible for an AS to change the format of the AT, but the RS will not >>> necessarily be in synch >>> with the RS. >>> >>> Since there are now cases where "the authorization server and resource >>> server are not co-located, are not ran by the same entity, or are >>> otherwise separated >>> by some boundary", a key point is that an AS and a RS DO NOT >>> necessarily need to know each other. The RS only needs to trust the >>> AS. (full stop) >>> >>> This means that an identifier of the profile of the AT should be able >>> to be included into the AT. This allows for future extensions. >>> >>> In any case, the "MUST NOT" in the quoted sentence should be removed >>> or changed or the whole sentence should be removed.. >>> >>> >>> 3) Within clause 2.2.2 (second paragraph): >>> >>>    This profile does not introduce any mechanism for a client to >>>    directly request the presence of specific claims in JWT access >>>    tokens, as the authorization server can determine what additional >>>    claims are required by a particular resource server by taking in >>>    consideration the client_id of the client, the scope and the resource >>>    parameters included in the request. >>> >>> Allowing a client to only specify a scope and a resource is very >>> restrictive. >>> >>> What would be the title of an RFC that would allow the client to >>> request the presence of specific claims in JWT access ? >>> >>> If such a restriction is kept, would the current title of this RFC >>> still be inappropriate >>> "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ? >>> >>> Denis >>> >>> DP Security Consulting >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------D1CEED51ED51298D92FBB61C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Benjamin,

Since there is tomorrow a virtual meeting and additionally I am locked down, by exception, I reply today.

We both agree that when the authorization server and resource server are not co-located, are not run by the same entity,
or are otherwise separated by some boundary" this does indeed present some consequences for the privacy considerations
of the protocol that will need to be addressed in some manner.

Today OAuth 2.0 has not been constructed taking into consideration this case, i.e. it has not been designed taking into consideration
"Privacy by Design". The fact is that OAuth 2.0 has nothing specific to take care of privacy principles.

There would be a simple way to solve some of my concerns: to remove in the Introduction (Section 1) lines 7 to 10 :

   The approach is particularly common in
   topologies where the authorization server and resource server are not
   co-located, are not ran by the same entity, or are otherwise
   separated by some boundary.

Let us now assume that privacy concerns would be addressed in either OAuth 2.1. or OAuth 3.0.

This spec. is supposed to be targeted to OAuth 2.0 but the header at the top of the page omits to mention it. Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           March 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           March 2020
There is however a problem to be solved now: to allow to easily distinguish between OAuth 2.0 JWT and future JWT versions.

In addition, there will be the need to be able to carry unsigned parameters associated with an OAuth 2.1. or OAuth 3.0 JWT.

An historical example was to be able to distinguish the version of a X.509 public key certificate using a version parameter.
Something similar should be done.

Section 6 (Privacy Considerations) should be modified.

The MUST NOT (inspect the content of the access token) should be removed.

Some text, like the following text, should be added:
In topologies where the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise
separated by some boundary, some privacy concerns arise. For security reasons, some clients may want to target their access tokens
but, for privacy reasons, may be unwilling to disclose to authorization servers an identification of the resource servers they will access,
so that authorisation servers will be unable to know which resources servers are being accessed. This profile does not contain provisions
to address this case.

For data minimization, openness and transparency, some clients may want to be able to specify with a fine granularity which of their identity attributes
should be incorporated into an access token and may want verify that only the requested identity attributes have indeed been incorporated. This profile
supports a scope parameter that allows to specify in advance which identity attributes should be incorporated, but the semantics of this parameter
is specific to every authorisation server. Presently, there is not standardized way to define, with a fine granularity, which identity attributes will be
incorporated into an access token.
My last new comment remains valid: it is quite odd that there is no formal description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.             

Denis

Hi Denis,

I am going to top-post because the quoting in this thread has become pretty
mangled.

First off, thank you for calling out the text in the document about
scenarios where "the authorization server and resource server are not
co-located, are not run by the same entity, or are otherwise separated by
some boundary"; this does indeed present some consequences for the privacy
considerations of the protocol that will need to be addressed in some
manner, though not necessarily the one that you envision.  I will try to
remember to check for this point when the document progresses to IESG
Evaluation.

You outline some interesting protocol proposals, such as letting the client
choose the token profile type, mandating (in at least some cases)
visibility into the token contents for the client, and letting the client
add additional token parameters in its request, but it seems pretty clear
to me that while these would make for an interesting protocol, that
protocol would fundamentally not be OAuth 2.0.  As such, it doesn't seem
appropriate to attempt to require them as part of this specific document.

I would also note that framing things as a contrast between "privacy by
design" and "spy by design" seems designed to evoke an emotional reaction,
and as such are actively harmful to rational technical debate.  I implore
you to focus on the facts of what data flows where and which aspects of
such flows are desirable and undesirable in the various situations under
consideration.

Finally, I'll note that though I am mostly just an observer here and not an
implementor, it's my sense that OAuth 2.0 as currently deployed involves a
relatively large number of RSes speaking to a comparable or smaller number of
ASes, and that it is common for AS implementations to have significant
amounts of logic dedicated to knowing the capabilities of the RSes they
serve.  Many of your comments do not seem consistent with this worldview,
and I invite the other WG participants to clarify if my understanding is
incorrect.

Thanks,

Ben

On Fri, Apr 10, 2020 at 11:07:35AM +0200, Denis wrote:

Hi Vittorio,

Thank you for your fast response.

You wrote:

    "/It doesn’t look very likely that an RS would simply accept tokens
    from an AS without some out of band negotiatio/n, "

and also:

    "/As far the client is concerned, the RS and the AS might switch
    their agreement/"

With such sentences, it seems that you mandate a direct negotiation 
between the AS and the RS which, by implication,
means that the AS and the RS must know each other, which is exactly what 
I want to avoid. Such some out of band negotiation
can simply be done by publishing which AT formats the AS is able to 
generate and which AT formats the RS is able to accept.
An AS can publish metadata relevant to the JWT access tokens it issues 
and a RS can do the same.

In this way, the client could consult both published lists and choose 
which common format, if any, would be appropriate.
This means that the client should be able in its AT request to specify 
the format of the AT, thus avoiding any direct some
out of band negotiation between the AS and the RS.

You continue saying:

    " /nor it seems very likely that an AS would issue tokens for
    resources it doesn’t know/".

This is where we have a major difference in our points of views. The 
number of AS is likely to be several order of magnitudes higher
compared to the number of RS. Every time a RS is being established, it 
should not have to make itself known to any AS.

This is why I wrote:

    /"a key point is that an AS and a RS DO NOT necessarily need to know
    each other. *The RS only needs to trust the AS*/*.*/(full stop)"/

You are assuming that an AS and a RS necessarily need to know each other.

You wrote:

    "/The scenario in which a token issuer isn’t aware of where the
    client will spend the corresponding token is important,
    but it is more the province of SSI than mainstream OAuth2 usage today"./

Today, as soon as an AT is targeted, the AS will be aware where the 
client is likely to spend the AT. The reality is that the scenario
in which a token issuer will not be aware of where the client will spend 
the corresponding token is today completely out of the scope
of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).

For that reason, if the spec. continues to prevent to implement "Privacy 
by design" architectures and worse, mandates "Spy by design"
architectures, this should be clearly advertised in the Privacy 
Considerations section.

You recommend to specify the split AT structure I suggest in its own 
spec rather than in an interop profile for the general AT case.
The current title of the document is: "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens". The content of the document
is much more than what the title implies since the introduction states :

    "Besides defining a common set of mandatory and optional claims, the
    profile provides clear indications on how determine the content of
    the issued JWT access token, how an authorization server can publish
    metadata relevant to the JWT access tokens it issues, and how
    a resource server should validate incoming JWT access tokens".

The document specifies a protocol with severe limitations in the 
authorization requests parameters and with severe limitations for the 
validation of AT.
If the spec. stays like that, it should rather be called:

  * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or
  * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0
    Access Tokens".


In the future, a true Profile for OAuth 2.0 Access Tokens could then be 
written.

The case where a client would be able to inspect the content of a 
generated AT, indeed comes into contradiction with the case where the AS 
would encrypt
its content for the intended recipient and you advocate that it is 
another reason "for which the AS in the general case needs to know the 
intended recipient".
It is not the general case, but a specific case, which is more difficult 
to deploy than the simplest case where RS only need to know the AS that 
they trust.
It is a trade off /for the client/ to be able to inspect itself the AT 
of to make sure that only the RS will be able to inspect the AT.

I wrote:

    "This means that an identifier of the profile of the AT should be
    able to be included into the AT. This allows for future extensions."

You replied:

    "Can you expand on the exact scenario you are thinking of that calls
    for a version?"

Identifier formats for AT should be able to be included into :

  * the metadata published by the AS,
  * the metadata published by the RS, and
  * the AT itself.


The sketch of the scenario would be as follows.

The client consults both the metadata published by the AS and the 
metadata published by the RS and tries to find matches between token 
formats.
If there are several matches, it will choose,if possible, a match where 
it can access and understand the content of the AT. It will then inform 
the AS
of its choice by adding the identifier of the profile of the AT in the 
AT request. The AS will also include the identifier of the profile of 
the AT in the AT
so that the RS, when it receives the AT, can unambiguously decode the AT.

Finally, I will copy the end of your email.

     > Allowing a client to only specify a scope and a resource is very
    restrictive.
    Specifying scope or using resource indicators are all the mechanisms
    I am aware of that OAuth2 offers for specifying what an access token
    should be for - at least at the time in which the spec was incepted.
    (...) .

    What other interoperable mechanisms would you offer in addition to
    the ones listed here?

The client should be able to specify in its AT request additional 
attributes whose semantic is well described by the attributes description
found in section 5.1 of [OpenID.Core] or the attributes description 
found in [RFC7662] or other identity related specifications.

*Another new and last comment*: it is quite odd that there is no formal 
description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis


Hi Denis,

Thank you for your feedback!

Inline

/> Privacy has not really been a concern in the WG since originally 
the AT and the RS were co-located./

Colocation of AS and RS was a frequent occurrence, but by no mean 
mandatory… AFAIK one of the drivers for the changes between OAuth1 and 
OAuth2 was providing the ability of supporting topologies where AS and 
RS are distinct right out of the box.

The scenario where AS and RS are distinct was always possible in 
Outh2, and and not by accident. The JWT AT just happens to be 
particularly handy in empowering the RS to validate incoming tokens 
without having to phone home to the AS every time, hence it gives the 
opportunity to discuss implications of that scenario more in depth, 
but doesn’t really introduce anything that wasn’t possible before. 
Even the possibility of a token format passing info by value isn’t 
forbidden, default OAuth2 ATs are not mandatorily opaque- they just 
happen not to have a well defined format.

*/>In such cases/*/, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients./

The scenario in which a token issuer isn’t aware of where the client 
will spend the corresponding token is important, but it is more the 
province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format, 
typically do know for whom the token is being issued: a great deal of 
logic is predicated on that knowledge. Did the user consent for this 
client to access this particular resource? Does access to this 
resource warrant presenting a stronger authentication prompt? Are 
there other authorization considerations that influences whether the 
requested token should be issued? Those are considerations an AS need 
to be able to perform in the general case, regardless of the AT 
format. That doesn’t mean they MUST be done in every case, but making 
them impossible would deny a lot of very important scenarios for which 
JWT ATs (and ATs in general) are used for today.

The split structure you suggest is interesting, but I would recommend 
is enshrined in its own spec (maybe in the SSI orbit) rather than in 
an interop profile for the general AT case.

/>On the contrary, a client SHALL be able to inspect the content of 
the access token to make sure that the AS has not included in the AT 
some private information
that should not be present, before forwarding the AT to the RS. It is 
possible for an AS to change the format of the AT, but the RS will not 
necessarily be in synch
with the RS.///

I can see the value in doing what we can to prevent abuses, but I find 
this requirement problematic. The access token is an artifact meant to 
enable the client to access a resource. Its format remains a private 
matter between the RS and the AS, which retains the freedom to change 
it as they see fit without worrying about client code that takes a 
dependency on characteristics of the AT that might very well be 
transient. As far the client is concerned, the RS and the AS might 
switch their agreement from JWT AT to opaque tokens to be validated 
via introspection at any time, which would break any client side logic 
inspecting the AT and expecting it to be a JWT. The client has no 
control whatsoever on the content that is transmitted via opaque 
token, hence privacy-wise the fact that the content of the JWT is 
visible is more of a concern about such content being accessible on 
the client. One additional point: even if clients would be able to 
safely peek inside an AT without risking breaking their code, there’s 
no guarantee that the client would understand the semantic of the 
claims in the AT, as those are meant for consumption by the RS which 
can assign any semantic to them; nor the client can reliably trust the 
content of the claims, given that the AS could and sometimes will 
encrypt their content for the intended recipient (another reason for 
which the AS in the general case needs to know the intended recipient).

/>. It is possible for an AS to change the format of the AT, but the 
RS will not necessarily be in synch with the RS. /

I don’t understand this sentence. Is the last RS meant to be AS?

Assuming that’s the case: It doesn’t look very likely that an RS would 
simply accept tokens from an AS without some out of band negotiation, 
nor it seems very likely that an AS would issue tokens for resources 
it doesn’t know- see above. Such scenarios might exist, but they don’t 
seem to model common business solutions or the typical deployment, 
where an API will be protected by middleware/gateway with precise 
assumptions on how to validate incoming tokens. There might be changes 
that are inconsequential (order of claims, additional claims) but 
anything more substantive would likely simply break the solution.

/> This means that an identifier of the profile of the AT should be 
able to be included into the AT. This allows for future extensions.///

Can you expand on the exact scenario you are thinking of that calls 
for a version? If it’s a matter of extensions, those should always be 
possible – it’s more breaking changes that require versioning, but I 
don’t recall precedents in similar specs.

If this is aimed at mitigating the “AS changes format without telling 
RS”, I don’t think that would work – besides of being unnecessary per 
the above considerations, this wouldn’t protect the RS from changes 
well within the current spec (which allows adding arbitrary claims as 
long as it’s done according to JWT rules), from changes within the 
claim content (eg private string formats) and from complete departures 
from the use of JWT for ATs.

/>//Allowing a client to only specify a scope and a resource is very 
restrictive./

Specifying scope or using resource indicators are all the mechanisms I 
am aware of that OAuth2 offers for specifying what an access token 
should be for- at least at the time in which the spec was incepted. In 
fact, resource indicators was not even RFC and in market vendors used 
proprietary functional equivalents. What other interoperable 
mechanisms would you offer in addition to the ones listed here?

*From: *OAuth <oauth-bounces@ietf.org> on behalf of Denis 
<denis.ietf@free.fr>
*Date: *Thursday, April 9, 2020 at 09:26
*To: *oauth <oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens"

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally 
the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and 
resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be 
able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in 
*"Spy by design"* architecture instead of a *"Privacy by design"* 
architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  * for security reasons, the AT must be targeted.
  * for privacy reasons, the AS must be kept ignorant of the name of
    the target.

One way to solve the problem is to consider that the AT is composed of 
a sequence of two structures: a signed structure and an unsigned 
structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way 
hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource server 
and select a resource indicator value corresponding to the identifier 
the resource server.
It then chooses a random value which it uses as a "aud salt claim" and 
then computes a hash value by using a one-way hash function which 
combines
one of the resource indicators of the RS with the "aud salt claim". 
Both the one way hash function algorithm identifier and the computed  
hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud 
claim". The AT blindly copies this value into the AT which is then 
identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned 
part to the AT which contains the "aud salt claim" and sends both the 
signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm 
identifier contained in the "salted aud claim", it combines each of 
its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and 
verifies whether it matches with the hash value contained in the 
"salted aud claim".
If none of these resource indicators is providing a match, then the RS 
SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an 
unsigned part.

In addition, the "aud claim" should be multi-valued where, as a 
consequence, both the "salted aud claim" with the "aud salt claim" 
would also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:

   As JWT access tokens carry information by value, it now becomes
   possible for requestors and receivers 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 (...).

On the contrary, a client SHALL be able to inspect the content of the 
access token to make sure that the AS has not included in the AT some 
private information
that should not be present, before forwarding the AT to the RS. It is 
possible for an AS to change the format of the AT, but the RS will not 
necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity, or are 
otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT 
necessarily need to know each other. The RS only needs to trust the 
AS. (full stop)

This means that an identifier of the profile of the AT should be able 
to be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed 
or changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

   This profile does not introduce any mechanism for a client to
   directly request the presence of specific claims in JWT access
   tokens, as the authorization server can determine what additional
   claims are required by a particular resource server by taking in
   consideration the client_id of the client, the scope and the resource
   parameters included in the request.

Allowing a client to only specify a scope and a resource is very 
restrictive.

What would be the title of an RFC that would allow the client to 
request the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC 
still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting



      

      

      

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


      

      

    

    


    

  


--------------D1CEED51ED51298D92FBB61C--


From nobody Mon Apr 13 03:25:16 2020
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 8E1463A1360 for ; Mon, 13 Apr 2020 03:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=0.01, 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 OoAgSD6KjCcI for ; Mon, 13 Apr 2020 03:24:58 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 32A733A135D for ; Mon, 13 Apr 2020 03:24:53 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id i75so8021318ild.13 for ; Mon, 13 Apr 2020 03:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=Jd/opKTe0/S0sMP7Hc3NTR0yofwOgkdKsEhYRg1nRrM=; b=eIxuzw7xtPz8wNYQIkAC/jsYON6S0i5c6o+3vWlqe6N2tB/hIWJeVYg+vHgHwHGZC3 GvMJeNueY+2JNZ9hi3LQ9hXr89yFBrLfo+AdjAXoV+nxy+pTZpU39isVWY/ocuLqYjHI 5Q/CEWKpEVd6us7qMES0ihOEnXTyahn/XkJs/KPYwu+I34JkWbL9Q9i/DvCrzA1oaRjM yir7hrxi4aQTLdT45+uuDnWFV75N9XEkYFmuy+cBHI2RtN/hWhVZ9OlxGI/nXjO0emTE L5ljAi1ENpIzM3ouR94O4zTTNMJNfBBerSwt2OrQ61M8PzrGJU6/edtmlbTpcA4Kuonh F2nQ==
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=Jd/opKTe0/S0sMP7Hc3NTR0yofwOgkdKsEhYRg1nRrM=; b=oYuFgqCAL1jSZpqe56Np/aNjjF1PqX3j5FP7kvdeEsMuoy1KoZLXwn50Bwkts/29YA ba+ESEuL4EyoIqS/PKetgDECrUpzkd0f7bALNUCJGuyz3rE2mwVfdsaniUfOgdIGNr42 RoD6W92VzXAj0bFOCmuNbP9v/h4H94ZojIjV96dRagnH0dVq1Xh8vKL9xXZWqi+XkH3R qPi8QC0WXiEW2wqqCVh34vN0KZWOwVpPUZQMoTunnUymQCVwgzBFCPPcPWuF+7TAoDRq fboko1Sg7x12rr6VJaErtSWn267Zx2SrinP087FlNSRxTvTcbJcZJia53ZhjB242ohpb 5fSQ==
X-Gm-Message-State: AGi0Pub1ugTsMtTsYKZCwuvB9UyEApHJvt8LxAjX1W3vD2pZ2Ufn3EeG AKGm/q6CLeSga8TAWt+DYO9I64sVsP4dPMbiBFQEafHxmYA=
X-Google-Smtp-Source: APiQypJysIhpP4FzLjR/CKP+Ci48nIU/gNqryK+u25TW4sKpzBCXbguawm1uCuoSdM+i9YSniOZv8Nf2RCTVU8iQI+Q=
X-Received: by 2002:a92:d90d:: with SMTP id s13mr17167022iln.255.1586773492012;  Mon, 13 Apr 2020 03:24:52 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com> 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Mon, 13 Apr 2020 06:24:40 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000549d9305a3297ef2"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 10:25:08 -0000

--000000000000549d9305a3297ef2
Content-Type: text/plain; charset="UTF-8"

I have uploaded the second presentation for today's session, the JWT
Profile for Access Tokens.
https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth

Regards,
 Rifaat


On Fri, Apr 10, 2020 at 9:35 AM Rifaat Shekh-Yusef 
wrote:

> The following is a link to the coming interim meeting materials:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>
> It has the chairs and Nested JWT slides.
> Will upload the JWT Profile for AT slides as soon as I get it.
>
> Regards,
>  Rifaat
>
>
> On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary 
> wrote:
>
>> The Web Authorization Protocol (oauth) Working Group will hold
>> a virtual interim meeting on 2020-04-13 from 12:00 to 13:00
>> America/Toronto (16:00 to 17:00 UTC).
>>
>> Agenda:
>> 1. Nested JWT
>> https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt
>>
>> 2. JWT Profile for Access Tokens
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>>
>> Information about remote participation:
>> https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--000000000000549d9305a3297ef2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have uploaded the second presentation for today's se=
ssion, the=C2=A0JWT Profile for Access Tokens.<=
div>
Regards,
=C2=A0Rifaat
=C2=A0

On Fri, Apr 10, 2020 at 9:35 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
The following =
is a link to the coming interim meeting materials:

It has the chairs and Ne=
sted JWT slides.
Will upload the JWT Profile for AT slides as soo=
n as I get it.

Regards,
=C2=A0Rifaat
=C2=A0

On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary <iesg-secretary@ietf.=
org> wrote:
The Web Authorization Protocol (oauth) Working Group will hold

a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 America/Toronto=
 (16:00 to 17:00 UTC).



Agenda:

1. Nested JWT

https://www.ietf.org/archive/id/d=
raft-yusef-oauth-nested-jwt-03.txt



2. JWT Profile for Access Tokens

https://datatracker.ietf.org/doc/=
draft-ietf-oauth-access-token-jwt/



Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dm776932cd87f84cbceb34ae907027b0f0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--000000000000549d9305a3297ef2--


From nobody Mon Apr 13 08:15:33 2020
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 EE20E3A1752 for ; Mon, 13 Apr 2020 08:15:31 -0700 (PDT)
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.398, 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 YmUd-PtR-LZc for ; Mon, 13 Apr 2020 08:15:30 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8943A17B2 for ; Mon, 13 Apr 2020 08:15:23 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d89 with ME id SFFH220084FMSmm03FFHlc; Mon, 13 Apr 2020 17:15:18 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Apr 2020 17:15:18 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>  
From: Denis 
Message-ID: <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>
Date: Mon, 13 Apr 2020 17:15:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DDBFB801289E5E6826556362"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 15:15:32 -0000

This is a multi-part message in MIME format.
--------------DDBFB801289E5E6826556362
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

More on privacy about "JWT Profile for Access Tokens".

The current document REQUIRES the claim names *sub* and *client_id*.

  * sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
  * client_id  REQUIRED - as defined in section 4.3 of [RFC8693]

*1) **sub  REQUIRED*

RFC 7519 states:

    4.1.2.  "sub" (Subject) Claim
        The "sub" (subject) claim identifies the principal that is the
        subject of the JWT.  The claims in a JWT are normally statements
        about the subject.  The subject value MUST either be scoped to**
    *be locally unique in the context of the issuer or be globally unique*.
        The processing of this claim is generally application specific.  The
        "sub" value is a case-sensitive string containing a StringOrURI
        value. *Use of this claim is OPTIONAL.*

If *sub *is *REQUIRED *for this profile, then this allows all resource 
servers to link accesses made by the same client on different servers.

*2) client_id  REQUIRED*

RFC 8693 states:

    4.3. "client_id" (Client Identifier) Claim
    The client_id claim carries the client identifier of the OAuth 2.0
    [RFC 6749] client that requested the token.

RFC 6749 states:

    2.2.  Client Identifier
        The authorization server issues the registered client a client
        identifier -- a unique string representing the registration
        information provided by the client.  The client identifier is not a
        secret; it is exposed to the resource owner and MUST NOT be used
        alone for client authentication. *The client identifier is
    unique to**
    **   the authorization server.*

If *client_id* is REQUIRED for this profile, this also allows all 
resource servers to link accesses made by the same client on different 
servers.

*Both claim names should be OPTIONAL *to allow to support the privacy 
principle of unlinkability.

Would both names remain *REQUIRED*, the Privacy considerations section 
should mention that such a linkage by different resource servers
will always be possible when using this profile.

Denis

> I have uploaded the second presentation for today's session, the JWT 
> Profile for Access Tokens.
> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>
> Regards,
>  Rifaat
>


--------------DDBFB801289E5E6826556362
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub  REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
    • 
      
  • client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
    • 
    

    
1) sub  REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.  "sub" (Subject) Claim

           The "sub" (subject) claim identifies the principal that is
        the

           subject of the JWT.  The claims in a JWT are normally
        statements

           about the subject.  The subject value MUST either be scoped
        to 

           be locally unique in the context of the issuer or be
          globally unique.

           The processing of this claim is generally application
        specific.  The

           "sub" value is a case-sensitive string containing a
        StringOrURI

           value.  Use of this claim is OPTIONAL.

    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id  REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identifier)
        Claim 

        The client_id claim carries the client identifier of the OAuth
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.  Client Identifier

           The authorization server issues the registered client a
        client

           identifier -- a unique string representing the registration

           information provided by the client.  The client identifier is
        not a

           secret; it is exposed to the resource owner and MUST NOT be
        used

           alone for client authentication.  The client identifier
          is unique to

           the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

      
      
I have uploaded the second presentation for today's
        session, the JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
 Rifaat

        
 

        

      

    

    

  


--------------DDBFB801289E5E6826556362--


From nobody Mon Apr 13 10:08:15 2020
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 78F6B3A1B81 for ; Mon, 13 Apr 2020 10:08:13 -0700 (PDT)
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 PRIKYHtxU7AP for ; Mon, 13 Apr 2020 10:08:11 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 6D4053A1A50 for ; Mon, 13 Apr 2020 10:08:11 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id m8so9491090lji.1 for ; Mon, 13 Apr 2020 10:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BZMOH6Ed7aRD7UJNqPo9gfOGLMArtyq0pXfNJmxJhwY=; b=dyiko5pPhbXuR/rWIahOKnMyQJTm00scFpxlq+eLAMrI4z9ogkE+1l6YglagscHH4t wFOMoj9Sg2KksDYUio2aNatRz6tUuxVZlx5b3IKFY0Ai3jtaPRv/Q5tyzuorWn/LRi/l krdfmHMDwwE+0ELE2JMdHl26K4JRyUQQK+WhF9hKyqQcgRo4WLGHe7EWA/sNRZk7dziG m0cyVM/egUgkw451c7UZbDEGyGb+tN++3PzO6FzOi4hsO7Qu8Du+o827koozEw8EL6LF kvcZmzjFgqEK/u8Rje2rZrnTbsEh+Pz7xyDQNFRt6cvntLmICouPS+3wi3F+uMWTrFja eLyg==
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=BZMOH6Ed7aRD7UJNqPo9gfOGLMArtyq0pXfNJmxJhwY=; b=oTpqrzlE1BVtiLIwab5mUKMsYdc9qi4g5TMIK7RGcv/fzTy7SnsjKY+vyGrNNmer6J MWFXttfXbJThYMKCDGenmIkQEhUiU7qBS116xI4cVKsG3AcrNzHqxexxoedhLjywCnF8 VcWMwsmQPEiAjLTeM0M5+U+q39xYNkZM64gtnTAnMQ3/WQ3l2qk3M/XZ0nC3lErxCUI9 DSVm627ZAwBu+LAYKBvwlFFEMhtV6IghiMf5UpzldixLcYR14lOt3lUoYWL/7ncsrY0N SdaUdlwVXlRirj2NaBb15d4F5E2n+UWVF+FuvgxpRz4bIARal45Jqk37PCylYH+kqhyz eheQ==
X-Gm-Message-State: AGi0PuZ0JbXmxBeAXAYLG1sDz9zSMKm8TdwjFcMQQHp/g7MCmtR+JSZm t/zDTxmMFVRjVaOMCttm6w37/pVfDcGz1zj+GdE=
X-Google-Smtp-Source: APiQypLS+jS4z/Vk5IdAmCStmdk7XbQ58gPifxQ/2LEOq6am5gEghJpLuh7r6y0/Zq+mZQ7nou93vlfIe7UJFA8TIoo=
X-Received: by 2002:a2e:b004:: with SMTP id y4mr3127119ljk.138.1586797689508;  Mon, 13 Apr 2020 10:08:09 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>
In-Reply-To: <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>
From: Dick Hardt 
Date: Mon, 13 Apr 2020 10:07:43 -0700
Message-ID: 
To: Denis 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009d173d05a32f20e2"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 17:08:14 -0000

--0000000000009d173d05a32f20e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Why does the "sub" need to be required?

An access token is to prove authorization. The RS may not need "sub" to
constrain fulfilling the client request.

For example, it the access token has the same properties as a movie ticket,
the RS does not need to have any identifier for who purchased the movie
ticket.

The privacy implication is the RS can correlate across API calls to know it
is the same subject.




On Mon, Apr 13, 2020 at 8:16 AM Denis  wrote:

> Hello,
>
> More on privacy about "JWT Profile for Access Tokens".
>
> The current document REQUIRES the claim names *sub* and *client_id*.
>
>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>
> *1) **sub  REQUIRED*
>
> RFC 7519 states:
>
> 4.1.2.  "sub" (Subject) Claim
>    The "sub" (subject) claim identifies the principal that is the
>    subject of the JWT.  The claims in a JWT are normally statements
>    about the subject.  The subject value MUST either be scoped to
>    *be locally unique in the context of the issuer or be globally unique*=
.
>    The processing of this claim is generally application specific.  The
>    "sub" value is a case-sensitive string containing a StringOrURI
>    value.  *Use of this claim is OPTIONAL.*
>
> If *sub *is *REQUIRED *for this profile, then this allows all resource
> servers to link accesses made by the same client on different servers.
>
> *2) client_id  REQUIRED*
>
> RFC 8693 states:
>
> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
> The client_id claim carries the client identi=EF=AC=81er of the OAuth 2.0=
 [RFC
> 6749] client that requested the token.
>
> RFC 6749 states:
>
> 2.2.  Client Identifier
>    The authorization server issues the registered client a client
>    identifier -- a unique string representing the registration
>    information provided by the client.  The client identifier is not a
>    secret; it is exposed to the resource owner and MUST NOT be used
>    alone for client authentication.  *The client identifier is unique to*
> *   the authorization server.*
>
> If *client_id* is REQUIRED for this profile, this also allows all
> resource servers to link accesses made by the same client on different
> servers.
>
> *Both claim names should be OPTIONAL *to allow to support the privacy
> principle of unlinkability.
>
> Would both names remain *REQUIRED*, the Privacy considerations section
> should mention that such a linkage by different resource servers
> will always be possible when using this profile.
>
> Denis
>
> I have uploaded the second presentation for today's session, the JWT
> Profile for Access Tokens.
> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>
> Regards,
>  Rifaat
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000009d173d05a32f20e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Why does the "sub" need to be required?

=

An access token is to prove authorization. The RS may not need &=
quot;sub" to constrain fulfilling=C2=A0the client request.=C2=A0
=


For example, it the=C2=A0access token has the same prop=
erties as a movie ticket, the RS does not need to have any identifier for w=
ho purchased the movie ticket.=C2=A0

The privacy i=
mplication is the RS can correlate across API calls to know it is the same =
subject.=C2=A0




=

On Mon, Ap=
r 13, 2020 at 8:16 AM Denis <denis=
.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=C2=A0

        

      

    

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000009d173d05a32f20e2--


From nobody Mon Apr 13 10:16:03 2020
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 C47293A1BB4 for ; Mon, 13 Apr 2020 10:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2xkpeuMLkqJ for ; Mon, 13 Apr 2020 10:15:54 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 A90513A1B98 for ; Mon, 13 Apr 2020 10:15:53 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id n10so10125659iom.3 for ; Mon, 13 Apr 2020 10:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=03aIuWJAdho2DmesuEVJF/BScjcYpR66efgEGq2JRps=; b=V46W8mSQHW5E2IEUY+rEylsPaHUC4q4MEN4JojZIyx2BrmpqOXoSTnUUhqM4eP9AN/ 9eLDhy4WBONMYElQ4/YrlJvAunBgx3QRxVqvNP+F55E8JqGdUYvyN22KXBnkYbHZA+eN 1AypXzezcz+4rtYGhr6C2QyWe/qryUuyIV4XNzTTBVSczgIQM9iXCvi/CAosp/M0oT5i AG/Rd1npRmtwxTDm/8I8LMqu9VjOd9FFWCYQeO1z+IOkwntAzBHj2qrLf/nPPtp6LmGX rNQ7/zfPebFREaSZdaQIRQvkMI35AsbmNz4EVyPsyn+wLqRE+wWZVTNPQ2tmHGNnMIXJ vB/w==
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=03aIuWJAdho2DmesuEVJF/BScjcYpR66efgEGq2JRps=; b=AmInoSIbbduksQXlDT5l21Qy9y5TL3aBGyi1bTL7bVHY5sfB8OTCsNanUN7UhzLuHq JI5FJHx0+RYDJTfGowMoLbI0VPQBVB9+IPXhmrVFZ6qAH/FTTpAghCshU6wg2+lNB5n2 AOB8vxOpDzpC7II3Y0QwPH+0noiBOKt27YqfDbyUwUMwp6sFSNAfWp9S9fMO4PK+O0OU JlyupBvLdGaTYqdYGe3P+2xfy3Q2luE53ghfJfL7+2EE/a4psUB9c+ETrMXpCF3NsK7+ c99JxR5M5UbYNXZrWHkbvJoOWHryF7mcHlx7tTx8xKq2sgNHexMrvvzmT3ZxOmkuzGHF L6AQ==
X-Gm-Message-State: AGi0PubrizfiyfPRLNpNkTEM1BTklNWuZ7UkWQQHag7ShM5busR2nL/z Ye/Nv+KOkvrFElYq+079Vx0e/n9EfNI=
X-Google-Smtp-Source: APiQypKVJi9+QmFefv6FMOsh9GQKqgvzJ8lLvlD2NbrJpYnFlg9Kk6sBLRgXdb2zDcNFh4uhylaDcw==
X-Received: by 2002:a02:3e14:: with SMTP id s20mr11189950jas.131.1586798152048;  Mon, 13 Apr 2020 10:15:52 -0700 (PDT)
Received: from mail-il1-f175.google.com (mail-il1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id b15sm2486331ilc.28.2020.04.13.10.15.50 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2020 10:15:51 -0700 (PDT)
Received: by mail-il1-f175.google.com with SMTP id o11so9177496ilq.7 for ; Mon, 13 Apr 2020 10:15:50 -0700 (PDT)
X-Received: by 2002:a92:d083:: with SMTP id h3mr18157620ilh.28.1586798150605;  Mon, 13 Apr 2020 10:15:50 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr> 
In-Reply-To: 
From: Aaron Parecki 
Date: Mon, 13 Apr 2020 10:15:39 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dick Hardt 
Cc: Denis , oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000018e70d05a32f3c0d"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 17:16:03 -0000

--00000000000018e70d05a32f3c0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is a good point, I often use the hotel key analogy as well. The room
door is the RS, the key is the access token, the door does not need to know
who the user is in order to know if it=E2=80=99s okay to unlock given a par=
ticular
key.

If sub is required, then this profile is limited in use to cases where user
identifiers are part of the system, and there will be situations in which
it=E2=80=99s not appropriate to use this profile for access tokens. If that=
=E2=80=99s okay,
this should be clarified in the overview section to describe when this
profile should be used.

Aaron



On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt  wrote:

> Why does the "sub" need to be required?
>
> An access token is to prove authorization. The RS may not need "sub" to
> constrain fulfilling the client request.
>
> For example, it the access token has the same properties as a movie
> ticket, the RS does not need to have any identifier for who purchased the
> movie ticket.
>
> The privacy implication is the RS can correlate across API calls to know
> it is the same subject.
>
>
>
>
> On Mon, Apr 13, 2020 at 8:16 AM Denis  > wrote:
>
>> Hello,
>>
>> More on privacy about "JWT Profile for Access Tokens".
>>
>> The current document REQUIRES the claim names *sub* and *client_id*.
>>
>>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>>
>> *1) **sub  REQUIRED*
>>
>> RFC 7519 states:
>>
>> 4.1.2.  "sub" (Subject) Claim
>>    The "sub" (subject) claim identifies the principal that is the
>>    subject of the JWT.  The claims in a JWT are normally statements
>>    about the subject.  The subject value MUST either be scoped to
>>    *be locally unique in the context of the issuer or be globally unique=
*
>> .
>>    The processing of this claim is generally application specific.  The
>>    "sub" value is a case-sensitive string containing a StringOrURI
>>    value.  *Use of this claim is OPTIONAL.*
>>
>> If *sub *is *REQUIRED *for this profile, then this allows all resource
>> servers to link accesses made by the same client on different servers.
>>
>> *2) client_id  REQUIRED*
>>
>> RFC 8693 states:
>>
>> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
>> The client_id claim carries the client identi=EF=AC=81er of the OAuth 2.=
0 [RFC
>> 6749] client that requested the token.
>>
>> RFC 6749 states:
>>
>> 2.2.  Client Identifier
>>    The authorization server issues the registered client a client
>>    identifier -- a unique string representing the registration
>>    information provided by the client.  The client identifier is not a
>>    secret; it is exposed to the resource owner and MUST NOT be used
>>    alone for client authentication.  *The client identifier is unique to=
*
>> *   the authorization server.*
>>
>> If *client_id* is REQUIRED for this profile, this also allows all
>> resource servers to link accesses made by the same client on different
>> servers.
>>
>> *Both claim names should be OPTIONAL *to allow to support the privacy
>> principle of unlinkability.
>>
>> Would both names remain *REQUIRED*, the Privacy considerations section
>> should mention that such a linkage by different resource servers
>> will always be possible when using this profile.
>>
>> Denis
>>
>> I have uploaded the second presentation for today's session, the JWT
>> Profile for Access Tokens.
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>>
>> Regards,
>>  Rifaat
>>
>>
>>
>> _______________________________________________
>> 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
----
Aaron Parecki
aaronparecki.com
@aaronpk 

--00000000000018e70d05a32f3c0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is a good point, I often use the hotel key anal=
ogy as well. The room door is the RS, the key is the access token, the door=
 does not need to know who the user is in order to know if it=E2=80=99s oka=
y to unlock given a particular key.

=

If sub is required, then this profile is limited in use t=
o cases where user identifiers are part of the system, and there will be si=
tuations in which it=E2=80=99s not appropriate to use this profile for acce=
ss tokens. If that=E2=80=99s okay, this should be clarified in the overview=
 section to describe when this profile should be used.

Aaron



On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <dick.hardt@gmail.com> wrote:
<=
/div>
Why does the "sub=
" need to be required?

An access token is to prove =
authorization. The RS may not need "sub" to constrain fulfilling=
=C2=A0the client request.=C2=A0

For example, it th=
e=C2=A0access token has the same properties as a movie ticket, the RS does =
not need to have any identifier for who purchased the movie ticket.=C2=A0

The privacy implication is the RS can correlate acr=
oss API calls to know it is the same subject.=C2=A0




On Mon, Apr 13, 2020 at 8:16 AM Denis <denis..ietf@free.fr&g=
t; wrote:

 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=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


-- 
----
Aaron Parecki
<=
div>aaronparecki.com<=
/a>



--00000000000018e70d05a32f3c0d--


From nobody Mon Apr 13 13:13:00 2020
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 C48903A1D69 for ; Mon, 13 Apr 2020 13:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.766
X-Spam-Level: 
X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 qF32j9yai8rJ for ; Mon, 13 Apr 2020 13:12:55 -0700 (PDT)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 4D53C3A1D6A for ; Mon, 13 Apr 2020 13:12:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1586808775; x=1618344775; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Q0J2/gs0FEAGsfuUvdTVQQo5PA0+SzI7uHpdd4AadQk=; b=G6rit4MibR6/D0yFZTVOTez2hK90yfj0PBvPBGzM3bCxuoDTEMBIje9G rMdU/2a0L7RIvlWXp0Fm7tz9q34YugcrspiKsIxsWU3q5VRolMYTD/Zgq JKVFVHmKEgetyVIZioSxMgkYGya+2bDqr2Dyc73Uv9cuazFvJARKb4dAo w=;
IronPort-SDR: MEo+wPtivPv72w+rNeq4/p6wEfMglMylNUEmBHkH66B/lgdW/5TxqEJ74fvtUqTws2OxJ6GOXm QUbPyX04U1eA==
X-IronPort-AV: E=Sophos; i="5.72,380,1580774400"; d="scan'208,217"; a="38224068"
Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 13 Apr 2020 20:12:52 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (Postfix) with ESMTPS id 571CCA232E; Mon, 13 Apr 2020 20:12:51 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Apr 2020 20:12:50 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Apr 2020 20:12:50 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Mon, 13 Apr 2020 20:12:50 +0000
From: "Richard Backman, Annabelle" 
To: Denis , Benjamin Kaduk 
CC: Vittorio Bertocci , oauth 
Thread-Index: AdYBWCr2leQdkb8yTTietiBUObuaNANM1q0AAB1y8oAABYn/gABWKsmAABxd7oAALOengA==
Date: Mon, 13 Apr 2020 20:12:50 +0000
Message-ID: 
References:    <363d6dbc-33e4-7ee6-8af3-075b0fb8a7b2@free.fr> <20200412021449.GM88064@mit.edu> <370dcb87-17c1-cc06-f724-5ee19a9b0d6a@free.fr>
In-Reply-To: <370dcb87-17c1-cc06-f724-5ee19a9b0d6a@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.90]
Content-Type: multipart/alternative; boundary="_000_ECADC22B22BE4656B925F2E84C86DADFamazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 13 Apr 2020 20:12:59 -0000

--_000_ECADC22B22BE4656B925F2E84C86DADFamazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSB0aGUgQVMgY2FuIGJlIGV4cGVjdGVkIHRvIGtub3cg
KGFuZCBpbiBmYWN0IG5lZWRzIHRvIGtub3cpIHdoaWNoIFJTZXMgYSB0b2tlbiB3aWxsIGJlIHVz
ZWQgd2l0aCwgYW5kIHVzZSBjYXNlcyB3aGVyZSB0aGVyZSBpcyB2YWx1ZSBpbiBvYnNjdXJpbmcg
dGhpcyBmYWN0LiBUaGlzIHNwZWMgc2hvdWxkIG5vdCBiZSBsaW1pdGVkIHRvIG9ubHkgb25lIG9y
IHRoZSBvdGhlci4gVGhlIHdvcmsgeW91IHN1Z2dlc3QgdG8gc3VwcG9ydCBvYnNjdXJpbmcgdGhl
IFJTIGlkZW50aXR5IGlzIG5vdCB1bmlxdWUgdG8gYW55IHBhcnRpY3VsYXIgYWNjZXNzIHRva2Vu
IGZvcm1hdCwgYW5kIGlzIHRoZXJlZm9yZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQu
DQoNCkxpa2V3aXNlLCB0b2tlbiBmb3JtYXQgbmVnb3RpYXRpb24gaXMgYW4gaW50ZXJlc3Rpbmcg
Y29uY2VwdCwgYnV0IGJ5IGl0cyBuYXR1cmUgaXMgbm90IGJvdW5kIHRvIGFueSBzcGVjaWZpYyBm
b3JtYXQuIElmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBwdXJzdWluZyB0aGF0IHdvcmssIEkgc3Vn
Z2VzdCBzdWJtaXR0aW5nIGl0IGFzIGEgc2VwYXJhdGUgSS1ELiBBIEpXVCBhY2Nlc3MgdG9rZW4g
cHJvZmlsZSBwcm92aWRlcyBzaWduaWZpY2FudCB2YWx1ZSB3aXRob3V0IHRoaXMgYWRkaXRpb24s
IHNvIEkgZG9u4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4gdHJ5aW5nIHRvIGluY29ycG9yYXRlIGl0
IGludG8gdGhpcyBkcmFmdC4NCg0KTm90ZSB0aGF0IHBlcm1pdHRpbmcgdGhlIGNsaWVudCB0byBp
bnNwZWN0IHRoZSBhY2Nlc3MgdG9rZW4gZG9lcyBub3QgcHJldmVudCB0aGUgQVMgYW5kIFJTIGZy
b20gZXhjaGFuZ2luZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2xpZW50IG9yIHJlc291cmNlIG93
bmVyLCBhcyB0aGlzIGNvdWxkIGJlIGRvbmUgdmlhIHByb3ByaWV0YXJ5IGNsYWltcyB3aXRoIGVu
Y3J5cHRlZCB2YWx1ZXMgb3IgdmlhIHNlcGFyYXRlIHNlcnZpY2UtdG8tc2VydmljZSBpbnRlcmFj
dGlvbnMgYmV0d2VlbiB0aGUgUlMgYW5kIEFTLiBJdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0
IGluIG1hbnkgY2FzZXMgKG5vdGFibHkgb25lcyB3aGVyZSB0aGUgQVMgYW5kIFJTIGFyZSBjbG9z
ZWx5IGFmZmlsaWF0ZWQpIGVuY3J5cHRpbmcgdGhlIGFjY2VzcyB0b2tlbiBwcmVzZXJ2ZXMgdGhl
IHJlc291cmNlIG93bmVy4oCZcyBwcml2YWN5IGJ5IHByZXZlbnRpbmcgdGhlIGNsaWVudCBmcm9t
IHNlZWluZyBpbmZvcm1hdGlvbiB0aGF0IHRoZSByZXNvdXJjZSBvd25lciBoYXMgc2hhcmVkIHdp
dGggdGhlIEFTIGFuZCBSUyBidXQgbm90IHRoZSBjbGllbnQuDQoNCkxhc3RseSBJIGFtIGFnYWlu
c3QgYWRkaW5nIGEgbWVjaGFuaXNtIGZvciByZXF1ZXN0aW5nIGFyYml0cmFyeSBjbGFpbXMgdG8g
YmUgaW5jbHVkZWQgaW4gdGhlIGFjY2VzcyB0b2tlbi4gVGhlIHB1cnBvc2Ugb2YgdGhlIGFjY2Vz
cyB0b2tlbiBpcyB0byBzZXJ2ZSBhcyBjcmVkZW50aWFscyB0aGF0IHRoZSBjbGllbnQgY2FuIHVz
ZSB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4gSWYgdGhlIGNsaWVudCB3YW50cyBjbGFp
bXMsIHRoZXkgc2hvdWxkIHJlcXVlc3QgdGhlIGFwcHJvcHJpYXRlIHNjb3BlcyBhbmQgcmV0cmll
dmUgdGhlbSBmcm9tIGEgcHJvZmlsZSBvciB1c2VyaW5mbyBlbmRwb2ludCwgb3IgdXNlIE9JREMu
IFRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBi
ZSB1bmRlcnN0b29kIGJ5IHRoZSBBUyBiYXNlZCBvbiB0aGUgcmVzb3VyY2UgaW5kaWNhdG9ycyBh
bmQgc2NvcGVzIGluIHRoZSByZXF1ZXN0LiBJZiB0aGlzIGlzIG5vdCB0aGUgY2FzZSwgdGhlbiB0
aGF0IHN1Z2dlc3RzIHRoZXJlIGlzIGEgdHJ1c3QgYm91bmRhcnkgYmV0d2VlbiB0aGUgQVMgYW5k
IFJTIGFuZCB0aGVyZWZvcmUgbmVlZHMgdG8gbWFrZSBpdHMgb3duIGF1dGhvcml6YXRpb24gcmVx
dWVzdC4gU2luY2UgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMgcmVwcmVzZW50IGFuIGF1dGhvcml6
YXRpb24gZ3JhbnQgdG8gdGhlIGNsaWVudCwgaXQgd291bGQgYmUgaW5hcHByb3ByaWF0ZSB0byBi
dW5kbGUgdGhlIHJlc291cmNlIHNlcnZlcuKAmXMgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGludG8g
dGhlIGNsaWVudOKAmXMgYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KDQrigJMNCkFubmFiZWxsZSBC
YWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5hbWF6b24uY29tL2lk
ZW50aXR5Lw0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh
bGYgb2YgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NCkRhdGU6IFN1bmRheSwgQXByaWwgMTIs
IDIwMjAgYXQgODo0OCBBTQ0KVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KQ2M6
IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+LCBvYXV0aCA8
b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0VYVEVSTkFMXSBbT0FVVEgtV0ddIFdHTEMg
b24gIkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9r
ZW5zIg0KDQoNCkNBVVRJT046IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2Yg
dGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMg
dW5sZXNzIHlvdSBjYW4gY29uZmlybSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlz
IHNhZmUuDQoNCg0KSGkgQmVuamFtaW4sDQoNClNpbmNlIHRoZXJlIGlzIHRvbW9ycm93IGEgdmly
dHVhbCBtZWV0aW5nIGFuZCBhZGRpdGlvbmFsbHkgSSBhbSBsb2NrZWQgZG93biwgYnkgZXhjZXB0
aW9uLCBJIHJlcGx5IHRvZGF5Lg0KDQpXZSBib3RoIGFncmVlIHRoYXQgd2hlbiB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBhcmUgbm90IGNvLWxvY2F0ZWQsIGFy
ZSBub3QgcnVuIGJ5IHRoZSBzYW1lIGVudGl0eSwNCm9yIGFyZSBvdGhlcndpc2Ugc2VwYXJhdGVk
IGJ5IHNvbWUgYm91bmRhcnkiIHRoaXMgZG9lcyBpbmRlZWQgcHJlc2VudCBzb21lIGNvbnNlcXVl
bmNlcyBmb3IgdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMNCm9mIHRoZSBwcm90b2NvbCB0aGF0
IHdpbGwgbmVlZCB0byBiZSBhZGRyZXNzZWQgaW4gc29tZSBtYW5uZXIuDQoNClRvZGF5IE9BdXRo
IDIuMCBoYXMgbm90IGJlZW4gY29uc3RydWN0ZWQgdGFraW5nIGludG8gY29uc2lkZXJhdGlvbiB0
aGlzIGNhc2UsIGkuZS4gaXQgaGFzIG5vdCBiZWVuIGRlc2lnbmVkIHRha2luZyBpbnRvIGNvbnNp
ZGVyYXRpb24NCiJQcml2YWN5IGJ5IERlc2lnbiIuIFRoZSBmYWN0IGlzIHRoYXQgT0F1dGggMi4w
IGhhcyBub3RoaW5nIHNwZWNpZmljIHRvIHRha2UgY2FyZSBvZiBwcml2YWN5IHByaW5jaXBsZXMu
DQoNClRoZXJlIHdvdWxkIGJlIGEgc2ltcGxlIHdheSB0byBzb2x2ZSBzb21lIG9mIG15IGNvbmNl
cm5zOiB0byByZW1vdmUgaW4gdGhlIEludHJvZHVjdGlvbiAoU2VjdGlvbiAxKSBsaW5lcyA3IHRv
IDEwIDoNCg0KICAgVGhlIGFwcHJvYWNoIGlzIHBhcnRpY3VsYXJseSBjb21tb24gaW4NCiAgIHRv
cG9sb2dpZXMgd2hlcmUgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2
ZXIgYXJlIG5vdA0KICAgY28tbG9jYXRlZCwgYXJlIG5vdCByYW4gYnkgdGhlIHNhbWUgZW50aXR5
LCBvciBhcmUgb3RoZXJ3aXNlDQogICBzZXBhcmF0ZWQgYnkgc29tZSBib3VuZGFyeS4NCg0KTGV0
IHVzIG5vdyBhc3N1bWUgdGhhdCBwcml2YWN5IGNvbmNlcm5zIHdvdWxkIGJlIGFkZHJlc3NlZCBp
biBlaXRoZXIgT0F1dGggMi4xLiBvciBPQXV0aCAzLjAuDQoNClRoaXMgc3BlYy4gaXMgc3VwcG9z
ZWQgdG8gYmUgdGFyZ2V0ZWQgdG8gT0F1dGggMi4wIGJ1dCB0aGUgaGVhZGVyIGF0IHRoZSB0b3Ag
b2YgdGhlIHBhZ2Ugb21pdHMgdG8gbWVudGlvbiBpdC4gQ3VycmVudGx5LCBpdCBpcyA6DQpJbnRl
cm5ldC1EcmFmdCAgICAgICBPQXV0aCBBY2Nlc3MgVG9rZW4gSldUIFByb2ZpbGUgICAgICAgICAg
IE1hcmNoIDIwMjANCkl0IHNob3VsZCByYXRoZXIgYmU6DQpJbnRlcm5ldC1EcmFmdCAgICAgICBP
QXV0aCAyLjAgQWNjZXNzIFRva2VuIEpXVCBQcm9maWxlICAgICAgICAgICBNYXJjaCAyMDIwDQpU
aGVyZSBpcyBob3dldmVyIGEgcHJvYmxlbSB0byBiZSBzb2x2ZWQgbm93OiB0byBhbGxvdyB0byBl
YXNpbHkgZGlzdGluZ3Vpc2ggYmV0d2VlbiBPQXV0aCAyLjAgSldUIGFuZCBmdXR1cmUgSldUIHZl
cnNpb25zLg0KDQpJbiBhZGRpdGlvbiwgdGhlcmUgd2lsbCBiZSB0aGUgbmVlZCB0byBiZSBhYmxl
IHRvIGNhcnJ5IHVuc2lnbmVkIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGFuIE9BdXRoIDIu
MS4gb3IgT0F1dGggMy4wIEpXVC4NCg0KQW4gaGlzdG9yaWNhbCBleGFtcGxlIHdhcyB0byBiZSBh
YmxlIHRvIGRpc3Rpbmd1aXNoIHRoZSB2ZXJzaW9uIG9mIGEgWC41MDkgcHVibGljIGtleSBjZXJ0
aWZpY2F0ZSB1c2luZyBhIHZlcnNpb24gcGFyYW1ldGVyLg0KU29tZXRoaW5nIHNpbWlsYXIgc2hv
dWxkIGJlIGRvbmUuDQoNClNlY3Rpb24gNiAoUHJpdmFjeSBDb25zaWRlcmF0aW9ucykgc2hvdWxk
IGJlIG1vZGlmaWVkLg0KDQpUaGUgTVVTVCBOT1QgKGluc3BlY3QgdGhlIGNvbnRlbnQgb2YgdGhl
IGFjY2VzcyB0b2tlbikgc2hvdWxkIGJlIHJlbW92ZWQuDQoNClNvbWUgdGV4dCwgbGlrZSB0aGUg
Zm9sbG93aW5nIHRleHQsIHNob3VsZCBiZSBhZGRlZDoNCkluIHRvcG9sb2dpZXMgd2hlcmUgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgYXJlIG5vdCBjby1sb2Nh
dGVkLCBhcmUgbm90IHJhbiBieSB0aGUgc2FtZSBlbnRpdHksIG9yIGFyZSBvdGhlcndpc2UNCnNl
cGFyYXRlZCBieSBzb21lIGJvdW5kYXJ5LCBzb21lIHByaXZhY3kgY29uY2VybnMgYXJpc2UuIEZv
ciBzZWN1cml0eSByZWFzb25zLCBzb21lIGNsaWVudHMgbWF5IHdhbnQgdG8gdGFyZ2V0IHRoZWly
IGFjY2VzcyB0b2tlbnMNCmJ1dCwgZm9yIHByaXZhY3kgcmVhc29ucywgbWF5IGJlIHVud2lsbGlu
ZyB0byBkaXNjbG9zZSB0byBhdXRob3JpemF0aW9uIHNlcnZlcnMgYW4gaWRlbnRpZmljYXRpb24g
b2YgdGhlIHJlc291cmNlIHNlcnZlcnMgdGhleSB3aWxsIGFjY2VzcywNCnNvIHRoYXQgYXV0aG9y
aXNhdGlvbiBzZXJ2ZXJzIHdpbGwgYmUgdW5hYmxlIHRvIGtub3cgd2hpY2ggcmVzb3VyY2VzIHNl
cnZlcnMgYXJlIGJlaW5nIGFjY2Vzc2VkLiBUaGlzIHByb2ZpbGUgZG9lcyBub3QgY29udGFpbiBw
cm92aXNpb25zDQp0byBhZGRyZXNzIHRoaXMgY2FzZS4NCg0KRm9yIGRhdGEgbWluaW1pemF0aW9u
LCBvcGVubmVzcyBhbmQgdHJhbnNwYXJlbmN5LCBzb21lIGNsaWVudHMgbWF5IHdhbnQgdG8gYmUg
YWJsZSB0byBzcGVjaWZ5IHdpdGggYSBmaW5lIGdyYW51bGFyaXR5IHdoaWNoIG9mIHRoZWlyIGlk
ZW50aXR5IGF0dHJpYnV0ZXMNCnNob3VsZCBiZSBpbmNvcnBvcmF0ZWQgaW50byBhbiBhY2Nlc3Mg
dG9rZW4gYW5kIG1heSB3YW50IHZlcmlmeSB0aGF0IG9ubHkgdGhlIHJlcXVlc3RlZCBpZGVudGl0
eSBhdHRyaWJ1dGVzIGhhdmUgaW5kZWVkIGJlZW4gaW5jb3Jwb3JhdGVkLiBUaGlzIHByb2ZpbGUN
CnN1cHBvcnRzIGEgc2NvcGUgcGFyYW1ldGVyIHRoYXQgYWxsb3dzIHRvIHNwZWNpZnkgaW4gYWR2
YW5jZSB3aGljaCBpZGVudGl0eSBhdHRyaWJ1dGVzIHNob3VsZCBiZSBpbmNvcnBvcmF0ZWQsIGJ1
dCB0aGUgc2VtYW50aWNzIG9mIHRoaXMgcGFyYW1ldGVyDQppcyBzcGVjaWZpYyB0byBldmVyeSBh
dXRob3Jpc2F0aW9uIHNlcnZlci4gUHJlc2VudGx5LCB0aGVyZSBpcyBub3Qgc3RhbmRhcmRpemVk
IHdheSB0byBkZWZpbmUsIHdpdGggYSBmaW5lIGdyYW51bGFyaXR5LCB3aGljaCBpZGVudGl0eSBh
dHRyaWJ1dGVzIHdpbGwgYmUNCmluY29ycG9yYXRlZCBpbnRvIGFuIGFjY2VzcyB0b2tlbi4NCk15
IGxhc3QgbmV3IGNvbW1lbnQgcmVtYWlucyB2YWxpZDogaXQgaXMgcXVpdGUgb2RkIHRoYXQgdGhl
cmUgaXMgbm8gZm9ybWFsIGRlc2NyaXB0aW9uIG9mIGFuIEFUIHByb2ZpbGUgYW55d2hlcmUgaW4g
dGhlIGN1cnJlbnQgZG9jdW1lbnQuDQpBIHN5bnRheCBkZXNjcmlwdGlvbiB3b3VsZCBncmVhdGx5
IGVuaGFuY2UgaW50ZXJvcGVyYWJpbGl0eS4NCg0KRGVuaXMNCg0KDQoNCkhpIERlbmlzLA0KDQoN
Cg0KSSBhbSBnb2luZyB0byB0b3AtcG9zdCBiZWNhdXNlIHRoZSBxdW90aW5nIGluIHRoaXMgdGhy
ZWFkIGhhcyBiZWNvbWUgcHJldHR5DQoNCm1hbmdsZWQuDQoNCg0KDQpGaXJzdCBvZmYsIHRoYW5r
IHlvdSBmb3IgY2FsbGluZyBvdXQgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50IGFib3V0DQoNCnNj
ZW5hcmlvcyB3aGVyZSAidGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2
ZXIgYXJlIG5vdA0KDQpjby1sb2NhdGVkLCBhcmUgbm90IHJ1biBieSB0aGUgc2FtZSBlbnRpdHks
IG9yIGFyZSBvdGhlcndpc2Ugc2VwYXJhdGVkIGJ5DQoNCnNvbWUgYm91bmRhcnkiOyB0aGlzIGRv
ZXMgaW5kZWVkIHByZXNlbnQgc29tZSBjb25zZXF1ZW5jZXMgZm9yIHRoZSBwcml2YWN5DQoNCmNv
bnNpZGVyYXRpb25zIG9mIHRoZSBwcm90b2NvbCB0aGF0IHdpbGwgbmVlZCB0byBiZSBhZGRyZXNz
ZWQgaW4gc29tZQ0KDQptYW5uZXIsIHRob3VnaCBub3QgbmVjZXNzYXJpbHkgdGhlIG9uZSB0aGF0
IHlvdSBlbnZpc2lvbi4gIEkgd2lsbCB0cnkgdG8NCg0KcmVtZW1iZXIgdG8gY2hlY2sgZm9yIHRo
aXMgcG9pbnQgd2hlbiB0aGUgZG9jdW1lbnQgcHJvZ3Jlc3NlcyB0byBJRVNHDQoNCkV2YWx1YXRp
b24uDQoNCg0KDQpZb3Ugb3V0bGluZSBzb21lIGludGVyZXN0aW5nIHByb3RvY29sIHByb3Bvc2Fs
cywgc3VjaCBhcyBsZXR0aW5nIHRoZSBjbGllbnQNCg0KY2hvb3NlIHRoZSB0b2tlbiBwcm9maWxl
IHR5cGUsIG1hbmRhdGluZyAoaW4gYXQgbGVhc3Qgc29tZSBjYXNlcykNCg0KdmlzaWJpbGl0eSBp
bnRvIHRoZSB0b2tlbiBjb250ZW50cyBmb3IgdGhlIGNsaWVudCwgYW5kIGxldHRpbmcgdGhlIGNs
aWVudA0KDQphZGQgYWRkaXRpb25hbCB0b2tlbiBwYXJhbWV0ZXJzIGluIGl0cyByZXF1ZXN0LCBi
dXQgaXQgc2VlbXMgcHJldHR5IGNsZWFyDQoNCnRvIG1lIHRoYXQgd2hpbGUgdGhlc2Ugd291bGQg
bWFrZSBmb3IgYW4gaW50ZXJlc3RpbmcgcHJvdG9jb2wsIHRoYXQNCg0KcHJvdG9jb2wgd291bGQg
ZnVuZGFtZW50YWxseSBub3QgYmUgT0F1dGggMi4wLiAgQXMgc3VjaCwgaXQgZG9lc24ndCBzZWVt
DQoNCmFwcHJvcHJpYXRlIHRvIGF0dGVtcHQgdG8gcmVxdWlyZSB0aGVtIGFzIHBhcnQgb2YgdGhp
cyBzcGVjaWZpYyBkb2N1bWVudC4NCg0KDQoNCkkgd291bGQgYWxzbyBub3RlIHRoYXQgZnJhbWlu
ZyB0aGluZ3MgYXMgYSBjb250cmFzdCBiZXR3ZWVuICJwcml2YWN5IGJ5DQoNCmRlc2lnbiIgYW5k
ICJzcHkgYnkgZGVzaWduIiBzZWVtcyBkZXNpZ25lZCB0byBldm9rZSBhbiBlbW90aW9uYWwgcmVh
Y3Rpb24sDQoNCmFuZCBhcyBzdWNoIGFyZSBhY3RpdmVseSBoYXJtZnVsIHRvIHJhdGlvbmFsIHRl
Y2huaWNhbCBkZWJhdGUuICBJIGltcGxvcmUNCg0KeW91IHRvIGZvY3VzIG9uIHRoZSBmYWN0cyBv
ZiB3aGF0IGRhdGEgZmxvd3Mgd2hlcmUgYW5kIHdoaWNoIGFzcGVjdHMgb2YNCg0Kc3VjaCBmbG93
cyBhcmUgZGVzaXJhYmxlIGFuZCB1bmRlc2lyYWJsZSBpbiB0aGUgdmFyaW91cyBzaXR1YXRpb25z
IHVuZGVyDQoNCmNvbnNpZGVyYXRpb24uDQoNCg0KDQpGaW5hbGx5LCBJJ2xsIG5vdGUgdGhhdCB0
aG91Z2ggSSBhbSBtb3N0bHkganVzdCBhbiBvYnNlcnZlciBoZXJlIGFuZCBub3QgYW4NCg0KaW1w
bGVtZW50b3IsIGl0J3MgbXkgc2Vuc2UgdGhhdCBPQXV0aCAyLjAgYXMgY3VycmVudGx5IGRlcGxv
eWVkIGludm9sdmVzIGENCg0KcmVsYXRpdmVseSBsYXJnZSBudW1iZXIgb2YgUlNlcyBzcGVha2lu
ZyB0byBhIGNvbXBhcmFibGUgb3Igc21hbGxlciBudW1iZXIgb2YNCg0KQVNlcywgYW5kIHRoYXQg
aXQgaXMgY29tbW9uIGZvciBBUyBpbXBsZW1lbnRhdGlvbnMgdG8gaGF2ZSBzaWduaWZpY2FudA0K
DQphbW91bnRzIG9mIGxvZ2ljIGRlZGljYXRlZCB0byBrbm93aW5nIHRoZSBjYXBhYmlsaXRpZXMg
b2YgdGhlIFJTZXMgdGhleQ0KDQpzZXJ2ZS4gIE1hbnkgb2YgeW91ciBjb21tZW50cyBkbyBub3Qg
c2VlbSBjb25zaXN0ZW50IHdpdGggdGhpcyB3b3JsZHZpZXcsDQoNCmFuZCBJIGludml0ZSB0aGUg
b3RoZXIgV0cgcGFydGljaXBhbnRzIHRvIGNsYXJpZnkgaWYgbXkgdW5kZXJzdGFuZGluZyBpcw0K
DQppbmNvcnJlY3QuDQoNCg0KDQpUaGFua3MsDQoNCg0KDQpCZW4NCg0KDQoNCk9uIEZyaSwgQXBy
IDEwLCAyMDIwIGF0IDExOjA3OjM1QU0gKzAyMDAsIERlbmlzIHdyb3RlOg0KDQpIaSBWaXR0b3Jp
bywNCg0KDQoNClRoYW5rIHlvdSBmb3IgeW91ciBmYXN0IHJlc3BvbnNlLg0KDQoNCg0KWW91IHdy
b3RlOg0KDQoNCg0KICAgICIvSXQgZG9lc27igJl0IGxvb2sgdmVyeSBsaWtlbHkgdGhhdCBhbiBS
UyB3b3VsZCBzaW1wbHkgYWNjZXB0IHRva2Vucw0KDQogICAgZnJvbSBhbiBBUyB3aXRob3V0IHNv
bWUgb3V0IG9mIGJhbmQgbmVnb3RpYXRpby9uLCAiDQoNCg0KDQphbmQgYWxzbzoNCg0KDQoNCiAg
ICAiL0FzIGZhciB0aGUgY2xpZW50IGlzIGNvbmNlcm5lZCwgdGhlIFJTIGFuZCB0aGUgQVMgbWln
aHQgc3dpdGNoDQoNCiAgICB0aGVpciBhZ3JlZW1lbnQvIg0KDQoNCg0KV2l0aCBzdWNoIHNlbnRl
bmNlcywgaXQgc2VlbXMgdGhhdCB5b3UgbWFuZGF0ZSBhIGRpcmVjdCBuZWdvdGlhdGlvbg0KDQpi
ZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTIHdoaWNoLCBieSBpbXBsaWNhdGlvbiwNCg0KbWVhbnMg
dGhhdCB0aGUgQVMgYW5kIHRoZSBSUyBtdXN0IGtub3cgZWFjaCBvdGhlciwgd2hpY2ggaXMgZXhh
Y3RseSB3aGF0DQoNCkkgd2FudCB0byBhdm9pZC4gU3VjaCBzb21lIG91dCBvZiBiYW5kIG5lZ290
aWF0aW9uDQoNCmNhbiBzaW1wbHkgYmUgZG9uZSBieSBwdWJsaXNoaW5nIHdoaWNoIEFUIGZvcm1h
dHMgdGhlIEFTIGlzIGFibGUgdG8NCg0KZ2VuZXJhdGUgYW5kIHdoaWNoIEFUIGZvcm1hdHMgdGhl
IFJTIGlzIGFibGUgdG8gYWNjZXB0Lg0KDQpBbiBBUyBjYW4gcHVibGlzaCBtZXRhZGF0YSByZWxl
dmFudCB0byB0aGUgSldUIGFjY2VzcyB0b2tlbnMgaXQgaXNzdWVzDQoNCmFuZCBhIFJTIGNhbiBk
byB0aGUgc2FtZS4NCg0KDQoNCkluIHRoaXMgd2F5LCB0aGUgY2xpZW50IGNvdWxkIGNvbnN1bHQg
Ym90aCBwdWJsaXNoZWQgbGlzdHMgYW5kIGNob29zZQ0KDQp3aGljaCBjb21tb24gZm9ybWF0LCBp
ZiBhbnksIHdvdWxkIGJlIGFwcHJvcHJpYXRlLg0KDQpUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVu
dCBzaG91bGQgYmUgYWJsZSBpbiBpdHMgQVQgcmVxdWVzdCB0byBzcGVjaWZ5DQoNCnRoZSBmb3Jt
YXQgb2YgdGhlIEFULCB0aHVzIGF2b2lkaW5nIGFueSBkaXJlY3Qgc29tZQ0KDQpvdXQgb2YgYmFu
ZCBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTLg0KDQoNCg0KWW91IGNvbnRp
bnVlIHNheWluZzoNCg0KDQoNCiAgICAiIC9ub3IgaXQgc2VlbXMgdmVyeSBsaWtlbHkgdGhhdCBh
biBBUyB3b3VsZCBpc3N1ZSB0b2tlbnMgZm9yDQoNCiAgICByZXNvdXJjZXMgaXQgZG9lc27igJl0
IGtub3cvIi4NCg0KDQoNClRoaXMgaXMgd2hlcmUgd2UgaGF2ZSBhIG1ham9yIGRpZmZlcmVuY2Ug
aW4gb3VyIHBvaW50cyBvZiB2aWV3cy4gVGhlDQoNCm51bWJlciBvZiBBUyBpcyBsaWtlbHkgdG8g
YmUgc2V2ZXJhbCBvcmRlciBvZiBtYWduaXR1ZGVzIGhpZ2hlcg0KDQpjb21wYXJlZCB0byB0aGUg
bnVtYmVyIG9mIFJTLiBFdmVyeSB0aW1lIGEgUlMgaXMgYmVpbmcgZXN0YWJsaXNoZWQsIGl0DQoN
CnNob3VsZCBub3QgaGF2ZSB0byBtYWtlIGl0c2VsZiBrbm93biB0byBhbnkgQVMuDQoNCg0KDQpU
aGlzIGlzIHdoeSBJIHdyb3RlOg0KDQoNCg0KICAgIC8iYSBrZXkgcG9pbnQgaXMgdGhhdCBhbiBB
UyBhbmQgYSBSUyBETyBOT1QgbmVjZXNzYXJpbHkgbmVlZCB0byBrbm93DQoNCiAgICBlYWNoIG90
aGVyLiAqVGhlIFJTIG9ubHkgbmVlZHMgdG8gdHJ1c3QgdGhlIEFTKi8qLiovKGZ1bGwgc3RvcCki
Lw0KDQoNCg0KWW91IGFyZSBhc3N1bWluZyB0aGF0IGFuIEFTIGFuZCBhIFJTIG5lY2Vzc2FyaWx5
IG5lZWQgdG8ga25vdyBlYWNoIG90aGVyLg0KDQoNCg0KWW91IHdyb3RlOg0KDQoNCg0KICAgICIv
VGhlIHNjZW5hcmlvIGluIHdoaWNoIGEgdG9rZW4gaXNzdWVyIGlzbuKAmXQgYXdhcmUgb2Ygd2hl
cmUgdGhlDQoNCiAgICBjbGllbnQgd2lsbCBzcGVuZCB0aGUgY29ycmVzcG9uZGluZyB0b2tlbiBp
cyBpbXBvcnRhbnQsDQoNCiAgICBidXQgaXQgaXMgbW9yZSB0aGUgcHJvdmluY2Ugb2YgU1NJIHRo
YW4gbWFpbnN0cmVhbSBPQXV0aDIgdXNhZ2UgdG9kYXkiLi8NCg0KDQoNClRvZGF5LCBhcyBzb29u
IGFzIGFuIEFUIGlzIHRhcmdldGVkLCB0aGUgQVMgd2lsbCBiZSBhd2FyZSB3aGVyZSB0aGUNCg0K
Y2xpZW50IGlzIGxpa2VseSB0byBzcGVuZCB0aGUgQVQuIFRoZSByZWFsaXR5IGlzIHRoYXQgdGhl
IHNjZW5hcmlvDQoNCmluIHdoaWNoIGEgdG9rZW4gaXNzdWVyIHdpbGwgbm90IGJlIGF3YXJlIG9m
IHdoZXJlIHRoZSBjbGllbnQgd2lsbCBzcGVuZA0KDQp0aGUgY29ycmVzcG9uZGluZyB0b2tlbiBp
cyB0b2RheSBjb21wbGV0ZWx5IG91dCBvZiB0aGUgc2NvcGUNCg0Kb2YgT0F1dGgyIHVzYWdlcyAo
dW5mb3J0dW5hdGVseSwgaXQgaXMgbm90IGEgbWF0dGVyIG9mIG1haW5zdHJlYW0gb3Igbm90KS4N
Cg0KDQoNCkZvciB0aGF0IHJlYXNvbiwgaWYgdGhlIHNwZWMuIGNvbnRpbnVlcyB0byBwcmV2ZW50
IHRvIGltcGxlbWVudCAiUHJpdmFjeQ0KDQpieSBkZXNpZ24iIGFyY2hpdGVjdHVyZXMgYW5kIHdv
cnNlLCBtYW5kYXRlcyAiU3B5IGJ5IGRlc2lnbiINCg0KYXJjaGl0ZWN0dXJlcywgdGhpcyBzaG91
bGQgYmUgY2xlYXJseSBhZHZlcnRpc2VkIGluIHRoZSBQcml2YWN5DQoNCkNvbnNpZGVyYXRpb25z
IHNlY3Rpb24uDQoNCg0KDQpZb3UgcmVjb21tZW5kIHRvIHNwZWNpZnkgdGhlIHNwbGl0IEFUIHN0
cnVjdHVyZSBJIHN1Z2dlc3QgaW4gaXRzIG93bg0KDQpzcGVjIHJhdGhlciB0aGFuIGluIGFuIGlu
dGVyb3AgcHJvZmlsZSBmb3IgdGhlIGdlbmVyYWwgQVQgY2FzZS4NCg0KVGhlIGN1cnJlbnQgdGl0
bGUgb2YgdGhlIGRvY3VtZW50IGlzOiAiSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IN
Cg0KT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiLiBUaGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQN
Cg0KaXMgbXVjaCBtb3JlIHRoYW4gd2hhdCB0aGUgdGl0bGUgaW1wbGllcyBzaW5jZSB0aGUgaW50
cm9kdWN0aW9uIHN0YXRlcyA6DQoNCg0KDQogICAgIkJlc2lkZXMgZGVmaW5pbmcgYSBjb21tb24g
c2V0IG9mIG1hbmRhdG9yeSBhbmQgb3B0aW9uYWwgY2xhaW1zLCB0aGUNCg0KICAgIHByb2ZpbGUg
cHJvdmlkZXMgY2xlYXIgaW5kaWNhdGlvbnMgb24gaG93IGRldGVybWluZSB0aGUgY29udGVudCBv
Zg0KDQogICAgdGhlIGlzc3VlZCBKV1QgYWNjZXNzIHRva2VuLCBob3cgYW4gYXV0aG9yaXphdGlv
biBzZXJ2ZXIgY2FuIHB1Ymxpc2gNCg0KICAgIG1ldGFkYXRhIHJlbGV2YW50IHRvIHRoZSBKV1Qg
YWNjZXNzIHRva2VucyBpdCBpc3N1ZXMsIGFuZCBob3cNCg0KICAgIGEgcmVzb3VyY2Ugc2VydmVy
IHNob3VsZCB2YWxpZGF0ZSBpbmNvbWluZyBKV1QgYWNjZXNzIHRva2VucyIuDQoNCg0KDQpUaGUg
ZG9jdW1lbnQgc3BlY2lmaWVzIGEgcHJvdG9jb2wgd2l0aCBzZXZlcmUgbGltaXRhdGlvbnMgaW4g
dGhlDQoNCmF1dGhvcml6YXRpb24gcmVxdWVzdHMgcGFyYW1ldGVycyBhbmQgd2l0aCBzZXZlcmUg
bGltaXRhdGlvbnMgZm9yIHRoZQ0KDQp2YWxpZGF0aW9uIG9mIEFULg0KDQpJZiB0aGUgc3BlYy4g
c3RheXMgbGlrZSB0aGF0LCBpdCBzaG91bGQgcmF0aGVyIGJlIGNhbGxlZDoNCg0KDQoNCiAgKiAi
SlNPTiBXZWIgVG9rZW4gKEpXVCkgKkJhc2ljIFByb3RvY29sKiBmb3IgT0F1dGggMi4wIEFjY2Vz
cyBUb2tlbnMiIG9yDQoNCiAgKiAiSlNPTiBXZWIgVG9rZW4gKEpXVCkgKkJhc2ljIFByb3RvY29s
IGFuZCBQcm9maWxlKiBmb3IgT0F1dGggMi4wDQoNCiAgICBBY2Nlc3MgVG9rZW5zIi4NCg0KDQoN
Cg0KDQpJbiB0aGUgZnV0dXJlLCBhIHRydWUgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBU
b2tlbnMgY291bGQgdGhlbiBiZQ0KDQp3cml0dGVuLg0KDQoNCg0KVGhlIGNhc2Ugd2hlcmUgYSBj
bGllbnQgd291bGQgYmUgYWJsZSB0byBpbnNwZWN0IHRoZSBjb250ZW50IG9mIGENCg0KZ2VuZXJh
dGVkIEFULCBpbmRlZWQgY29tZXMgaW50byBjb250cmFkaWN0aW9uIHdpdGggdGhlIGNhc2Ugd2hl
cmUgdGhlIEFTDQoNCndvdWxkIGVuY3J5cHQNCg0KaXRzIGNvbnRlbnQgZm9yIHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQgYW5kIHlvdSBhZHZvY2F0ZSB0aGF0IGl0IGlzDQoNCmFub3RoZXIgcmVhc29u
ICJmb3Igd2hpY2ggdGhlIEFTIGluIHRoZSBnZW5lcmFsIGNhc2UgbmVlZHMgdG8ga25vdyB0aGUN
Cg0KaW50ZW5kZWQgcmVjaXBpZW50Ii4NCg0KSXQgaXMgbm90IHRoZSBnZW5lcmFsIGNhc2UsIGJ1
dCBhIHNwZWNpZmljIGNhc2UsIHdoaWNoIGlzIG1vcmUgZGlmZmljdWx0DQoNCnRvIGRlcGxveSB0
aGFuIHRoZSBzaW1wbGVzdCBjYXNlIHdoZXJlIFJTIG9ubHkgbmVlZCB0byBrbm93IHRoZSBBUyB0
aGF0DQoNCnRoZXkgdHJ1c3QuDQoNCkl0IGlzIGEgdHJhZGUgb2ZmIC9mb3IgdGhlIGNsaWVudC8g
dG8gYmUgYWJsZSB0byBpbnNwZWN0IGl0c2VsZiB0aGUgQVQNCg0Kb2YgdG8gbWFrZSBzdXJlIHRo
YXQgb25seSB0aGUgUlMgd2lsbCBiZSBhYmxlIHRvIGluc3BlY3QgdGhlIEFULg0KDQoNCg0KSSB3
cm90ZToNCg0KDQoNCiAgICAiVGhpcyBtZWFucyB0aGF0IGFuIGlkZW50aWZpZXIgb2YgdGhlIHBy
b2ZpbGUgb2YgdGhlIEFUIHNob3VsZCBiZQ0KDQogICAgYWJsZSB0byBiZSBpbmNsdWRlZCBpbnRv
IHRoZSBBVC4gVGhpcyBhbGxvd3MgZm9yIGZ1dHVyZSBleHRlbnNpb25zLiINCg0KDQoNCllvdSBy
ZXBsaWVkOg0KDQoNCg0KICAgICJDYW4geW91IGV4cGFuZCBvbiB0aGUgZXhhY3Qgc2NlbmFyaW8g
eW91IGFyZSB0aGlua2luZyBvZiB0aGF0IGNhbGxzDQoNCiAgICBmb3IgYSB2ZXJzaW9uPyINCg0K
DQoNCklkZW50aWZpZXIgZm9ybWF0cyBmb3IgQVQgc2hvdWxkIGJlIGFibGUgdG8gYmUgaW5jbHVk
ZWQgaW50byA6DQoNCg0KDQogICogdGhlIG1ldGFkYXRhIHB1Ymxpc2hlZCBieSB0aGUgQVMsDQoN
CiAgKiB0aGUgbWV0YWRhdGEgcHVibGlzaGVkIGJ5IHRoZSBSUywgYW5kDQoNCiAgKiB0aGUgQVQg
aXRzZWxmLg0KDQoNCg0KDQoNClRoZSBza2V0Y2ggb2YgdGhlIHNjZW5hcmlvIHdvdWxkIGJlIGFz
IGZvbGxvd3MuDQoNCg0KDQpUaGUgY2xpZW50IGNvbnN1bHRzIGJvdGggdGhlIG1ldGFkYXRhIHB1
Ymxpc2hlZCBieSB0aGUgQVMgYW5kIHRoZQ0KDQptZXRhZGF0YSBwdWJsaXNoZWQgYnkgdGhlIFJT
IGFuZCB0cmllcyB0byBmaW5kIG1hdGNoZXMgYmV0d2VlbiB0b2tlbg0KDQpmb3JtYXRzLg0KDQpJ
ZiB0aGVyZSBhcmUgc2V2ZXJhbCBtYXRjaGVzLCBpdCB3aWxsIGNob29zZSxpZiBwb3NzaWJsZSwg
YSBtYXRjaCB3aGVyZQ0KDQppdCBjYW4gYWNjZXNzIGFuZCB1bmRlcnN0YW5kIHRoZSBjb250ZW50
IG9mIHRoZSBBVC4gSXQgd2lsbCB0aGVuIGluZm9ybQ0KDQp0aGUgQVMNCg0Kb2YgaXRzIGNob2lj
ZSBieSBhZGRpbmcgdGhlIGlkZW50aWZpZXIgb2YgdGhlIHByb2ZpbGUgb2YgdGhlIEFUIGluIHRo
ZQ0KDQpBVCByZXF1ZXN0LiBUaGUgQVMgd2lsbCBhbHNvIGluY2x1ZGUgdGhlIGlkZW50aWZpZXIg
b2YgdGhlIHByb2ZpbGUgb2YNCg0KdGhlIEFUIGluIHRoZSBBVA0KDQpzbyB0aGF0IHRoZSBSUywg
d2hlbiBpdCByZWNlaXZlcyB0aGUgQVQsIGNhbiB1bmFtYmlndW91c2x5IGRlY29kZSB0aGUgQVQu
DQoNCg0KDQpGaW5hbGx5LCBJIHdpbGwgY29weSB0aGUgZW5kIG9mIHlvdXIgZW1haWwuDQoNCg0K
DQogICAgID4gQWxsb3dpbmcgYSBjbGllbnQgdG8gb25seSBzcGVjaWZ5IGEgc2NvcGUgYW5kIGEg
cmVzb3VyY2UgaXMgdmVyeQ0KDQogICAgcmVzdHJpY3RpdmUuDQoNCiAgICBTcGVjaWZ5aW5nIHNj
b3BlIG9yIHVzaW5nIHJlc291cmNlIGluZGljYXRvcnMgYXJlIGFsbCB0aGUgbWVjaGFuaXNtcw0K
DQogICAgSSBhbSBhd2FyZSBvZiB0aGF0IE9BdXRoMiBvZmZlcnMgZm9yIHNwZWNpZnlpbmcgd2hh
dCBhbiBhY2Nlc3MgdG9rZW4NCg0KICAgIHNob3VsZCBiZSBmb3IgLSBhdCBsZWFzdCBhdCB0aGUg
dGltZSBpbiB3aGljaCB0aGUgc3BlYyB3YXMgaW5jZXB0ZWQuDQoNCiAgICAoLi4uKSAuDQoNCg0K
DQogICAgV2hhdCBvdGhlciBpbnRlcm9wZXJhYmxlIG1lY2hhbmlzbXMgd291bGQgeW91IG9mZmVy
IGluIGFkZGl0aW9uIHRvDQoNCiAgICB0aGUgb25lcyBsaXN0ZWQgaGVyZT8NCg0KDQoNClRoZSBj
bGllbnQgc2hvdWxkIGJlIGFibGUgdG8gc3BlY2lmeSBpbiBpdHMgQVQgcmVxdWVzdCBhZGRpdGlv
bmFsDQoNCmF0dHJpYnV0ZXMgd2hvc2Ugc2VtYW50aWMgaXMgd2VsbCBkZXNjcmliZWQgYnkgdGhl
IGF0dHJpYnV0ZXMgZGVzY3JpcHRpb24NCg0KZm91bmQgaW4gc2VjdGlvbiA1LjEgb2YgW09wZW5J
RC5Db3JlXSBvciB0aGUgYXR0cmlidXRlcyBkZXNjcmlwdGlvbg0KDQpmb3VuZCBpbiBbUkZDNzY2
Ml0gb3Igb3RoZXIgaWRlbnRpdHkgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucy4NCg0KDQoNCipBbm90
aGVyIG5ldyBhbmQgbGFzdCBjb21tZW50KjogaXQgaXMgcXVpdGUgb2RkIHRoYXQgdGhlcmUgaXMg
bm8gZm9ybWFsDQoNCmRlc2NyaXB0aW9uIG9mIGFuIEFUIHByb2ZpbGUgYW55d2hlcmUgaW4gdGhl
IGN1cnJlbnQgZG9jdW1lbnQuDQoNCkEgc3ludGF4IGRlc2NyaXB0aW9uIHdvdWxkIGdyZWF0bHkg
ZW5oYW5jZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNCg0KRGVuaXMNCg0KDQoNCkhpIERlbmlzLA0K
DQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrIQ0KDQoNCg0KSW5saW5lDQoNCg0KDQov
PiBQcml2YWN5IGhhcyBub3QgcmVhbGx5IGJlZW4gYSBjb25jZXJuIGluIHRoZSBXRyBzaW5jZSBv
cmlnaW5hbGx5DQoNCnRoZSBBVCBhbmQgdGhlIFJTIHdlcmUgY28tbG9jYXRlZC4vDQoNCg0KDQpD
b2xvY2F0aW9uIG9mIEFTIGFuZCBSUyB3YXMgYSBmcmVxdWVudCBvY2N1cnJlbmNlLCBidXQgYnkg
bm8gbWVhbg0KDQptYW5kYXRvcnnigKYgQUZBSUsgb25lIG9mIHRoZSBkcml2ZXJzIGZvciB0aGUg
Y2hhbmdlcyBiZXR3ZWVuIE9BdXRoMSBhbmQNCg0KT0F1dGgyIHdhcyBwcm92aWRpbmcgdGhlIGFi
aWxpdHkgb2Ygc3VwcG9ydGluZyB0b3BvbG9naWVzIHdoZXJlIEFTIGFuZA0KDQpSUyBhcmUgZGlz
dGluY3QgcmlnaHQgb3V0IG9mIHRoZSBib3guDQoNCg0KDQpUaGUgc2NlbmFyaW8gd2hlcmUgQVMg
YW5kIFJTIGFyZSBkaXN0aW5jdCB3YXMgYWx3YXlzIHBvc3NpYmxlIGluDQoNCk91dGgyLCBhbmQg
YW5kIG5vdCBieSBhY2NpZGVudC4gVGhlIEpXVCBBVCBqdXN0IGhhcHBlbnMgdG8gYmUNCg0KcGFy
dGljdWxhcmx5IGhhbmR5IGluIGVtcG93ZXJpbmcgdGhlIFJTIHRvIHZhbGlkYXRlIGluY29taW5n
IHRva2Vucw0KDQp3aXRob3V0IGhhdmluZyB0byBwaG9uZSBob21lIHRvIHRoZSBBUyBldmVyeSB0
aW1lLCBoZW5jZSBpdCBnaXZlcyB0aGUNCg0Kb3Bwb3J0dW5pdHkgdG8gZGlzY3VzcyBpbXBsaWNh
dGlvbnMgb2YgdGhhdCBzY2VuYXJpbyBtb3JlIGluIGRlcHRoLA0KDQpidXQgZG9lc27igJl0IHJl
YWxseSBpbnRyb2R1Y2UgYW55dGhpbmcgdGhhdCB3YXNu4oCZdCBwb3NzaWJsZSBiZWZvcmUuDQoN
CkV2ZW4gdGhlIHBvc3NpYmlsaXR5IG9mIGEgdG9rZW4gZm9ybWF0IHBhc3NpbmcgaW5mbyBieSB2
YWx1ZSBpc27igJl0DQoNCmZvcmJpZGRlbiwgZGVmYXVsdCBPQXV0aDIgQVRzIGFyZSBub3QgbWFu
ZGF0b3JpbHkgb3BhcXVlLSB0aGV5IGp1c3QNCg0KaGFwcGVuIG5vdCB0byBoYXZlIGEgd2VsbCBk
ZWZpbmVkIGZvcm1hdC4NCg0KDQoNCiovPkluIHN1Y2ggY2FzZXMvKi8sIGl0IGlzIGltcG9ydGFu
dCB0byBiZSBhYmxlIHRvIG1ha2Ugc3VyZSB0aGF0IGFuDQoNCmF1dGhvcml6YXRpb24gc2VydmVy
IHdpbGwgTk9UIGJlIGFibGUgdG8ga25vdyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbnMNCg0KdG9r
ZW5zIHRoYXQgaXQgaXNzdWVzIHdpbGwgYmUgdXNlZC4gVXNpbmcgYW5vdGhlciB3b3JkaW5nLCBh
biBBUyBTSEFMTA0KDQpOT1QgYmUgYWJsZSB0byBrbm93IHdoZXJlIGFuIEFUIHJlcXVlc3RlZCBi
eSBhIGdpdmVuIGNsaWVudCB3aWxsIGJlIHVzZWQ6DQoNCipBdXRob3JpemF0aW9uIHNlcnZlcnMg
U0hBTEwgbm90IGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gYWN0IGFzICJCaWcNCg0KQnJvdGhlciIq
IGFuZCB0aHVzIFNIQUxMIG5vdCBiZSBhYmxlIHRvIGtub3cgd2hpY2ggcmVzb3VyY2VzIGFyZSBn
b2luZw0KDQp0byBiZSBhY2Nlc3NlZCBieSBjbGllbnRzLi8NCg0KDQoNClRoZSBzY2VuYXJpbyBp
biB3aGljaCBhIHRva2VuIGlzc3VlciBpc27igJl0IGF3YXJlIG9mIHdoZXJlIHRoZSBjbGllbnQN
Cg0Kd2lsbCBzcGVuZCB0aGUgY29ycmVzcG9uZGluZyB0b2tlbiBpcyBpbXBvcnRhbnQsIGJ1dCBp
dCBpcyBtb3JlIHRoZQ0KDQpwcm92aW5jZSBvZiBTU0kgdGhhbiBtYWluc3RyZWFtIE9BdXRoMiB1
c2FnZSB0b2RheS4NCg0KTWFpbnN0cmVhbSBPQXV0aDIgaW4gY3VycmVudCB1c2UsIHJlZ2FyZGxl
c3Mgb2YgdGhlIEFUIGZvcm1hdCwNCg0KdHlwaWNhbGx5IGRvIGtub3cgZm9yIHdob20gdGhlIHRv
a2VuIGlzIGJlaW5nIGlzc3VlZDogYSBncmVhdCBkZWFsIG9mDQoNCmxvZ2ljIGlzIHByZWRpY2F0
ZWQgb24gdGhhdCBrbm93bGVkZ2UuIERpZCB0aGUgdXNlciBjb25zZW50IGZvciB0aGlzDQoNCmNs
aWVudCB0byBhY2Nlc3MgdGhpcyBwYXJ0aWN1bGFyIHJlc291cmNlPyBEb2VzIGFjY2VzcyB0byB0
aGlzDQoNCnJlc291cmNlIHdhcnJhbnQgcHJlc2VudGluZyBhIHN0cm9uZ2VyIGF1dGhlbnRpY2F0
aW9uIHByb21wdD8gQXJlDQoNCnRoZXJlIG90aGVyIGF1dGhvcml6YXRpb24gY29uc2lkZXJhdGlv
bnMgdGhhdCBpbmZsdWVuY2VzIHdoZXRoZXIgdGhlDQoNCnJlcXVlc3RlZCB0b2tlbiBzaG91bGQg
YmUgaXNzdWVkPyBUaG9zZSBhcmUgY29uc2lkZXJhdGlvbnMgYW4gQVMgbmVlZA0KDQp0byBiZSBh
YmxlIHRvIHBlcmZvcm0gaW4gdGhlIGdlbmVyYWwgY2FzZSwgcmVnYXJkbGVzcyBvZiB0aGUgQVQN
Cg0KZm9ybWF0LiBUaGF0IGRvZXNu4oCZdCBtZWFuIHRoZXkgTVVTVCBiZSBkb25lIGluIGV2ZXJ5
IGNhc2UsIGJ1dCBtYWtpbmcNCg0KdGhlbSBpbXBvc3NpYmxlIHdvdWxkIGRlbnkgYSBsb3Qgb2Yg
dmVyeSBpbXBvcnRhbnQgc2NlbmFyaW9zIGZvciB3aGljaA0KDQpKV1QgQVRzIChhbmQgQVRzIGlu
IGdlbmVyYWwpIGFyZSB1c2VkIGZvciB0b2RheS4NCg0KDQoNClRoZSBzcGxpdCBzdHJ1Y3R1cmUg
eW91IHN1Z2dlc3QgaXMgaW50ZXJlc3RpbmcsIGJ1dCBJIHdvdWxkIHJlY29tbWVuZA0KDQppcyBl
bnNocmluZWQgaW4gaXRzIG93biBzcGVjIChtYXliZSBpbiB0aGUgU1NJIG9yYml0KSByYXRoZXIg
dGhhbiBpbg0KDQphbiBpbnRlcm9wIHByb2ZpbGUgZm9yIHRoZSBnZW5lcmFsIEFUIGNhc2UuDQoN
Cg0KDQovPk9uIHRoZSBjb250cmFyeSwgYSBjbGllbnQgU0hBTEwgYmUgYWJsZSB0byBpbnNwZWN0
IHRoZSBjb250ZW50IG9mDQoNCnRoZSBhY2Nlc3MgdG9rZW4gdG8gbWFrZSBzdXJlIHRoYXQgdGhl
IEFTIGhhcyBub3QgaW5jbHVkZWQgaW4gdGhlIEFUDQoNCnNvbWUgcHJpdmF0ZSBpbmZvcm1hdGlv
bg0KDQp0aGF0IHNob3VsZCBub3QgYmUgcHJlc2VudCwgYmVmb3JlIGZvcndhcmRpbmcgdGhlIEFU
IHRvIHRoZSBSUy4gSXQgaXMNCg0KcG9zc2libGUgZm9yIGFuIEFTIHRvIGNoYW5nZSB0aGUgZm9y
bWF0IG9mIHRoZSBBVCwgYnV0IHRoZSBSUyB3aWxsIG5vdA0KDQpuZWNlc3NhcmlseSBiZSBpbiBz
eW5jaA0KDQp3aXRoIHRoZSBSUy4vLy8NCg0KDQoNCkkgY2FuIHNlZSB0aGUgdmFsdWUgaW4gZG9p
bmcgd2hhdCB3ZSBjYW4gdG8gcHJldmVudCBhYnVzZXMsIGJ1dCBJIGZpbmQNCg0KdGhpcyByZXF1
aXJlbWVudCBwcm9ibGVtYXRpYy4gVGhlIGFjY2VzcyB0b2tlbiBpcyBhbiBhcnRpZmFjdCBtZWFu
dCB0bw0KDQplbmFibGUgdGhlIGNsaWVudCB0byBhY2Nlc3MgYSByZXNvdXJjZS4gSXRzIGZvcm1h
dCByZW1haW5zIGEgcHJpdmF0ZQ0KDQptYXR0ZXIgYmV0d2VlbiB0aGUgUlMgYW5kIHRoZSBBUywg
d2hpY2ggcmV0YWlucyB0aGUgZnJlZWRvbSB0byBjaGFuZ2UNCg0KaXQgYXMgdGhleSBzZWUgZml0
IHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgY2xpZW50IGNvZGUgdGhhdCB0YWtlcyBhDQoNCmRlcGVu
ZGVuY3kgb24gY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBBVCB0aGF0IG1pZ2h0IHZlcnkgd2VsbCBi
ZQ0KDQp0cmFuc2llbnQuIEFzIGZhciB0aGUgY2xpZW50IGlzIGNvbmNlcm5lZCwgdGhlIFJTIGFu
ZCB0aGUgQVMgbWlnaHQNCg0Kc3dpdGNoIHRoZWlyIGFncmVlbWVudCBmcm9tIEpXVCBBVCB0byBv
cGFxdWUgdG9rZW5zIHRvIGJlIHZhbGlkYXRlZA0KDQp2aWEgaW50cm9zcGVjdGlvbiBhdCBhbnkg
dGltZSwgd2hpY2ggd291bGQgYnJlYWsgYW55IGNsaWVudCBzaWRlIGxvZ2ljDQoNCmluc3BlY3Rp
bmcgdGhlIEFUIGFuZCBleHBlY3RpbmcgaXQgdG8gYmUgYSBKV1QuIFRoZSBjbGllbnQgaGFzIG5v
DQoNCmNvbnRyb2wgd2hhdHNvZXZlciBvbiB0aGUgY29udGVudCB0aGF0IGlzIHRyYW5zbWl0dGVk
IHZpYSBvcGFxdWUNCg0KdG9rZW4sIGhlbmNlIHByaXZhY3ktd2lzZSB0aGUgZmFjdCB0aGF0IHRo
ZSBjb250ZW50IG9mIHRoZSBKV1QgaXMNCg0KdmlzaWJsZSBpcyBtb3JlIG9mIGEgY29uY2VybiBh
Ym91dCBzdWNoIGNvbnRlbnQgYmVpbmcgYWNjZXNzaWJsZSBvbg0KDQp0aGUgY2xpZW50LiBPbmUg
YWRkaXRpb25hbCBwb2ludDogZXZlbiBpZiBjbGllbnRzIHdvdWxkIGJlIGFibGUgdG8NCg0Kc2Fm
ZWx5IHBlZWsgaW5zaWRlIGFuIEFUIHdpdGhvdXQgcmlza2luZyBicmVha2luZyB0aGVpciBjb2Rl
LCB0aGVyZeKAmXMNCg0Kbm8gZ3VhcmFudGVlIHRoYXQgdGhlIGNsaWVudCB3b3VsZCB1bmRlcnN0
YW5kIHRoZSBzZW1hbnRpYyBvZiB0aGUNCg0KY2xhaW1zIGluIHRoZSBBVCwgYXMgdGhvc2UgYXJl
IG1lYW50IGZvciBjb25zdW1wdGlvbiBieSB0aGUgUlMgd2hpY2gNCg0KY2FuIGFzc2lnbiBhbnkg
c2VtYW50aWMgdG8gdGhlbTsgbm9yIHRoZSBjbGllbnQgY2FuIHJlbGlhYmx5IHRydXN0IHRoZQ0K
DQpjb250ZW50IG9mIHRoZSBjbGFpbXMsIGdpdmVuIHRoYXQgdGhlIEFTIGNvdWxkIGFuZCBzb21l
dGltZXMgd2lsbA0KDQplbmNyeXB0IHRoZWlyIGNvbnRlbnQgZm9yIHRoZSBpbnRlbmRlZCByZWNp
cGllbnQgKGFub3RoZXIgcmVhc29uIGZvcg0KDQp3aGljaCB0aGUgQVMgaW4gdGhlIGdlbmVyYWwg
Y2FzZSBuZWVkcyB0byBrbm93IHRoZSBpbnRlbmRlZCByZWNpcGllbnQpLg0KDQoNCg0KLz4uIEl0
IGlzIHBvc3NpYmxlIGZvciBhbiBBUyB0byBjaGFuZ2UgdGhlIGZvcm1hdCBvZiB0aGUgQVQsIGJ1
dCB0aGUNCg0KUlMgd2lsbCBub3QgbmVjZXNzYXJpbHkgYmUgaW4gc3luY2ggd2l0aCB0aGUgUlMu
IC8NCg0KDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMgc2VudGVuY2UuIElzIHRoZSBsYXN0
IFJTIG1lYW50IHRvIGJlIEFTPw0KDQoNCg0KQXNzdW1pbmcgdGhhdOKAmXMgdGhlIGNhc2U6IEl0
IGRvZXNu4oCZdCBsb29rIHZlcnkgbGlrZWx5IHRoYXQgYW4gUlMgd291bGQNCg0Kc2ltcGx5IGFj
Y2VwdCB0b2tlbnMgZnJvbSBhbiBBUyB3aXRob3V0IHNvbWUgb3V0IG9mIGJhbmQgbmVnb3RpYXRp
b24sDQoNCm5vciBpdCBzZWVtcyB2ZXJ5IGxpa2VseSB0aGF0IGFuIEFTIHdvdWxkIGlzc3VlIHRv
a2VucyBmb3IgcmVzb3VyY2VzDQoNCml0IGRvZXNu4oCZdCBrbm93LSBzZWUgYWJvdmUuIFN1Y2gg
c2NlbmFyaW9zIG1pZ2h0IGV4aXN0LCBidXQgdGhleSBkb27igJl0DQoNCnNlZW0gdG8gbW9kZWwg
Y29tbW9uIGJ1c2luZXNzIHNvbHV0aW9ucyBvciB0aGUgdHlwaWNhbCBkZXBsb3ltZW50LA0KDQp3
aGVyZSBhbiBBUEkgd2lsbCBiZSBwcm90ZWN0ZWQgYnkgbWlkZGxld2FyZS9nYXRld2F5IHdpdGgg
cHJlY2lzZQ0KDQphc3N1bXB0aW9ucyBvbiBob3cgdG8gdmFsaWRhdGUgaW5jb21pbmcgdG9rZW5z
LiBUaGVyZSBtaWdodCBiZSBjaGFuZ2VzDQoNCnRoYXQgYXJlIGluY29uc2VxdWVudGlhbCAob3Jk
ZXIgb2YgY2xhaW1zLCBhZGRpdGlvbmFsIGNsYWltcykgYnV0DQoNCmFueXRoaW5nIG1vcmUgc3Vi
c3RhbnRpdmUgd291bGQgbGlrZWx5IHNpbXBseSBicmVhayB0aGUgc29sdXRpb24uDQoNCg0KDQov
PiBUaGlzIG1lYW5zIHRoYXQgYW4gaWRlbnRpZmllciBvZiB0aGUgcHJvZmlsZSBvZiB0aGUgQVQg
c2hvdWxkIGJlDQoNCmFibGUgdG8gYmUgaW5jbHVkZWQgaW50byB0aGUgQVQuIFRoaXMgYWxsb3dz
IGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4vLy8NCg0KDQoNCkNhbiB5b3UgZXhwYW5kIG9uIHRoZSBl
eGFjdCBzY2VuYXJpbyB5b3UgYXJlIHRoaW5raW5nIG9mIHRoYXQgY2FsbHMNCg0KZm9yIGEgdmVy
c2lvbj8gSWYgaXTigJlzIGEgbWF0dGVyIG9mIGV4dGVuc2lvbnMsIHRob3NlIHNob3VsZCBhbHdh
eXMgYmUNCg0KcG9zc2libGUg4oCTIGl04oCZcyBtb3JlIGJyZWFraW5nIGNoYW5nZXMgdGhhdCBy
ZXF1aXJlIHZlcnNpb25pbmcsIGJ1dCBJDQoNCmRvbuKAmXQgcmVjYWxsIHByZWNlZGVudHMgaW4g
c2ltaWxhciBzcGVjcy4NCg0KDQoNCklmIHRoaXMgaXMgYWltZWQgYXQgbWl0aWdhdGluZyB0aGUg
4oCcQVMgY2hhbmdlcyBmb3JtYXQgd2l0aG91dCB0ZWxsaW5nDQoNClJT4oCdLCBJIGRvbuKAmXQg
dGhpbmsgdGhhdCB3b3VsZCB3b3JrIOKAkyBiZXNpZGVzIG9mIGJlaW5nIHVubmVjZXNzYXJ5IHBl
cg0KDQp0aGUgYWJvdmUgY29uc2lkZXJhdGlvbnMsIHRoaXMgd291bGRu4oCZdCBwcm90ZWN0IHRo
ZSBSUyBmcm9tIGNoYW5nZXMNCg0Kd2VsbCB3aXRoaW4gdGhlIGN1cnJlbnQgc3BlYyAod2hpY2gg
YWxsb3dzIGFkZGluZyBhcmJpdHJhcnkgY2xhaW1zIGFzDQoNCmxvbmcgYXMgaXTigJlzIGRvbmUg
YWNjb3JkaW5nIHRvIEpXVCBydWxlcyksIGZyb20gY2hhbmdlcyB3aXRoaW4gdGhlDQoNCmNsYWlt
IGNvbnRlbnQgKGVnIHByaXZhdGUgc3RyaW5nIGZvcm1hdHMpIGFuZCBmcm9tIGNvbXBsZXRlIGRl
cGFydHVyZXMNCg0KZnJvbSB0aGUgdXNlIG9mIEpXVCBmb3IgQVRzLg0KDQoNCg0KLz4vL0FsbG93
aW5nIGEgY2xpZW50IHRvIG9ubHkgc3BlY2lmeSBhIHNjb3BlIGFuZCBhIHJlc291cmNlIGlzIHZl
cnkNCg0KcmVzdHJpY3RpdmUuLw0KDQoNCg0KU3BlY2lmeWluZyBzY29wZSBvciB1c2luZyByZXNv
dXJjZSBpbmRpY2F0b3JzIGFyZSBhbGwgdGhlIG1lY2hhbmlzbXMgSQ0KDQphbSBhd2FyZSBvZiB0
aGF0IE9BdXRoMiBvZmZlcnMgZm9yIHNwZWNpZnlpbmcgd2hhdCBhbiBhY2Nlc3MgdG9rZW4NCg0K
c2hvdWxkIGJlIGZvci0gYXQgbGVhc3QgYXQgdGhlIHRpbWUgaW4gd2hpY2ggdGhlIHNwZWMgd2Fz
IGluY2VwdGVkLiBJbg0KDQpmYWN0LCByZXNvdXJjZSBpbmRpY2F0b3JzIHdhcyBub3QgZXZlbiBS
RkMgYW5kIGluIG1hcmtldCB2ZW5kb3JzIHVzZWQNCg0KcHJvcHJpZXRhcnkgZnVuY3Rpb25hbCBl
cXVpdmFsZW50cy4gV2hhdCBvdGhlciBpbnRlcm9wZXJhYmxlDQoNCm1lY2hhbmlzbXMgd291bGQg
eW91IG9mZmVyIGluIGFkZGl0aW9uIHRvIHRoZSBvbmVzIGxpc3RlZCBoZXJlPw0KDQoNCg0KKkZy
b206ICpPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEZW5pcw0KDQo8ZGVuaXMuaWV0ZkBmcmVlLmZyPjxtYWls
dG86ZGVuaXMuaWV0ZkBmcmVlLmZyPg0KDQoqRGF0ZTogKlRodXJzZGF5LCBBcHJpbCA5LCAyMDIw
IGF0IDA5OjI2DQoNCipUbzogKm9hdXRoIDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGll
dGYub3JnPg0KDQoqU3ViamVjdDogKlJlOiBbT0FVVEgtV0ddIFdHTEMgb24gIkpTT04gV2ViIFRv
a2VuIChKV1QpIFByb2ZpbGUgZm9yDQoNCk9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQoNCg0K
SSBoYXZlIHRocmVlIGNvbmNlcm5zLCB0d28gb2YgdGhlbSBiZWluZyByZWxhdGVkIHRvIHByaXZh
Y3kuDQoNCg0KDQoxKSBQcml2YWN5IGhhcyBub3QgcmVhbGx5IGJlZW4gYSBjb25jZXJuIGluIHRo
ZSBXRyBzaW5jZSBvcmlnaW5hbGx5DQoNCnRoZSBBVCBhbmQgdGhlIFJTIHdlcmUgY28tbG9jYXRl
ZC4gSG93ZXZlciwgdGhpcyBkcmFmdCBub3cgcmVjb2duaXplcw0KDQp0aGF0IHRoZXJlIG1heSBl
eGlzdCBjYXNlcyB3aGVyZSAidGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZA0KDQpyZXNvdXJj
ZSBzZXJ2ZXIgYXJlIG5vdCBjby1sb2NhdGVkLCBhcmUgbm90IHJhbiBieSB0aGUgc2FtZSBlbnRp
dHksDQoNCm9yIGFyZSBvdGhlcndpc2Ugc2VwYXJhdGVkIGJ5IHNvbWUgYm91bmRhcnkiLg0KDQoN
Cg0KKkluIHN1Y2ggY2FzZXMqLCBpdCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBtYWtlIHN1
cmUgdGhhdCBhbg0KDQphdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIE5PVCBiZSBhYmxlIHRvIGtu
b3cgd2hlcmUgdGhlIGF1dGhvcml6YXRpb25zDQoNCnRva2VucyB0aGF0IGl0IGlzc3VlcyB3aWxs
IGJlIHVzZWQuIFVzaW5nIGFub3RoZXIgd29yZGluZywgYW4gQVMgU0hBTEwNCg0KTk9UIGJlIGFi
bGUgdG8ga25vdyB3aGVyZSBhbiBBVCByZXF1ZXN0ZWQgYnkgYSBnaXZlbiBjbGllbnQgd2lsbCBi
ZSB1c2VkOg0KDQoqQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIFNIQUxMIG5vdCBoYXZlIHRoZSBjYXBh
YmlsaXR5IHRvIGFjdCBhcyAiQmlnDQoNCkJyb3RoZXIiKiBhbmQgdGh1cyBTSEFMTCBub3QgYmUg
YWJsZSB0byBrbm93IHdoaWNoIHJlc291cmNlcyBhcmUgZ29pbmcNCg0KdG8gYmUgYWNjZXNzZWQg
YnkgY2xpZW50cy4NCg0KDQoNClRoaXMgbWVhbnMgdGhhdCwgaW4gc3VjaCBjYXNlcywgYW4gYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgU0hBTEwgbm90IGJlDQoNCmFibGUgdG8ga25vdyBmb3Igd2hpY2gg
cmVzb3VyY2Ugc2VydmVyIGFuIEFUIGhhcyBiZWVuIHRhcmdldGVkLg0KDQoNCg0KSXQgaXMgYSBm
YWN0IHRoYXQgbW9zdCBzb2x1dGlvbnMgY3VycmVudGx5IGRlcGxveWVkIHN1cHBvcnQgYSBidWls
dC1pbg0KDQoqIlNweSBieSBkZXNpZ24iKiBhcmNoaXRlY3R1cmUgaW5zdGVhZCBvZiBhICoiUHJp
dmFjeSBieSBkZXNpZ24iKg0KDQphcmNoaXRlY3R1cmUuDQoNCg0KDQpIb3dldmVyLCBmb3Igc2Vj
dXJpdHkgcmVhc29ucyBhbiBBVCBzdGlsbCBuZWVkcyB0byBiZSB0YXJnZXRlZC4NCg0KDQoNClRo
ZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBpcyB0aGUgZm9sbG93aW5nOg0KDQoNCg0KICAqIGZvciBz
ZWN1cml0eSByZWFzb25zLCB0aGUgQVQgbXVzdCBiZSB0YXJnZXRlZC4NCg0KICAqIGZvciBwcml2
YWN5IHJlYXNvbnMsIHRoZSBBUyBtdXN0IGJlIGtlcHQgaWdub3JhbnQgb2YgdGhlIG5hbWUgb2YN
Cg0KICAgIHRoZSB0YXJnZXQuDQoNCg0KDQpPbmUgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtIGlz
IHRvIGNvbnNpZGVyIHRoYXQgdGhlIEFUIGlzIGNvbXBvc2VkIG9mDQoNCmEgc2VxdWVuY2Ugb2Yg
dHdvIHN0cnVjdHVyZXM6IGEgc2lnbmVkIHN0cnVjdHVyZSBhbmQgYW4gdW5zaWduZWQNCg0Kc3Ry
dWN0dXJlLg0KDQoNCg0KVGhlIHNpZ25lZCBzdHJ1Y3R1cmUgY29udGFpbnMgYSAic2FsdGVkIGF1
ZCBjbGFpbSIuDQoNClRoZSB1bnNpZ25lZCBzdHJ1Y3R1cmUgY29udGFpbnMgYSAiYXVkIHNhbHQg
Y2xhaW0iLg0KDQoNCg0KSW4gcHJhY3RpY2UsIHRoZSAic2FsdGVkIGF1ZCBjbGFpbSIgd2lsbCBi
ZSBjb21wb3NlZCBvZiBib3RoIGEgb25lIHdheQ0KDQpoYXNoIGZ1bmN0aW9uIGFsZ29yaXRobSBp
ZGVudGlmaWVyIGFuZCBhIGhhc2ggdmFsdWUuDQoNCg0KDQpCZWZvcmUgcmVxdWVzdGluZyBhbiBB
VCB0byBhbiBBUywgdGhlIGNsaWVudCBjaG9vc2VzIGEgcmVzb3VyY2Ugc2VydmVyDQoNCmFuZCBz
ZWxlY3QgYSByZXNvdXJjZSBpbmRpY2F0b3IgdmFsdWUgY29ycmVzcG9uZGluZyB0byB0aGUgaWRl
bnRpZmllcg0KDQp0aGUgcmVzb3VyY2Ugc2VydmVyLg0KDQpJdCB0aGVuIGNob29zZXMgYSByYW5k
b20gdmFsdWUgd2hpY2ggaXQgdXNlcyBhcyBhICJhdWQgc2FsdCBjbGFpbSIgYW5kDQoNCnRoZW4g
Y29tcHV0ZXMgYSBoYXNoIHZhbHVlIGJ5IHVzaW5nIGEgb25lLXdheSBoYXNoIGZ1bmN0aW9uIHdo
aWNoDQoNCmNvbWJpbmVzDQoNCm9uZSBvZiB0aGUgcmVzb3VyY2UgaW5kaWNhdG9ycyBvZiB0aGUg
UlMgd2l0aCB0aGUgImF1ZCBzYWx0IGNsYWltIi4NCg0KQm90aCB0aGUgb25lIHdheSBoYXNoIGZ1
bmN0aW9uIGFsZ29yaXRobSBpZGVudGlmaWVyIGFuZCB0aGUgY29tcHV0ZWQNCg0KaGFzaCB2YWx1
ZQ0KDQphcmUgdGhlbiBpbmNsdWRlZCBpbnRvIHRoZSAic2FsdGVkIGF1ZCBjbGFpbSIuDQoNCg0K
DQpUaGUgQVQgcmVxdWVzdCB0aGVuIGNvbnRhaW5zIGEgInNhbHRlZCBhdWQgY2xhaW0iIGluc3Rl
YWQgb2YgYW4iYXVkDQoNCmNsYWltIi4gVGhlIEFUIGJsaW5kbHkgY29waWVzIHRoaXMgdmFsdWUg
aW50byB0aGUgQVQgd2hpY2ggaXMgdGhlbg0KDQppZGVudGlmaWVkIGFzDQoNCmEgInNhbHRlZCBh
dWQgY2xhaW0iIGluc3RlYWQgb2YgYW4gImF1ZCBjbGFpbSIuDQoNCg0KDQpXaGVuIHRoZSBBVCBp
cyByZWNlaXZlZCBieSB0aGUgY2xpZW50LCBpdCBhZGRzIHRvIHRoZSBBVCB0aGUgdW5zaWduZWQN
Cg0KcGFydCB0byB0aGUgQVQgd2hpY2ggY29udGFpbnMgdGhlICJhdWQgc2FsdCBjbGFpbSIgYW5k
IHNlbmRzIGJvdGggdGhlDQoNCnNpZ25lZA0KDQphbmQgdGhlIHVuc2lnbmVkIHBhcnQgb2YgdGhl
IEFUIHRvIHRoZSBSUy4NCg0KDQoNCldoZW4gdGhlIFJTIHJlY2VpdmVzIHRoZSBBVCwgdXNpbmcg
dGhlIG9uZSB3YXkgaGFzaCBmdW5jdGlvbiBhbGdvcml0aG0NCg0KaWRlbnRpZmllciBjb250YWlu
ZWQgaW4gdGhlICJzYWx0ZWQgYXVkIGNsYWltIiwgaXQgY29tYmluZXMgZWFjaCBvZg0KDQppdHMg
cmVzb3VyY2UgaW5kaWNhdG9ycw0KDQp3aXRoIHRoZSAiYXVkIHNhbHQgY2xhaW0iIGNvbnRhaW5l
ZCBpbiB0aGUgdW5zaWduZWQgcGFydCBvZiB0aGUgQVQgYW5kDQoNCnZlcmlmaWVzIHdoZXRoZXIg
aXQgbWF0Y2hlcyB3aXRoIHRoZSBoYXNoIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGUNCg0KInNhbHRl
ZCBhdWQgY2xhaW0iLg0KDQpJZiBub25lIG9mIHRoZXNlIHJlc291cmNlIGluZGljYXRvcnMgaXMg
cHJvdmlkaW5nIGEgbWF0Y2gsIHRoZW4gdGhlIFJTDQoNClNIQUxMIHJlamVjdGVkIHRoZSBBVC4N
Cg0KDQoNClRoZSBpbXBsaWNhdGlvbiBpcyB0byBhbGxvdyBhbiBBVCB0byBjb250YWluIGJvdGgg
YSBzaWduZWQgcGFydCBhbmQgYW4NCg0KdW5zaWduZWQgcGFydC4NCg0KDQoNCkluIGFkZGl0aW9u
LCB0aGUgImF1ZCBjbGFpbSIgc2hvdWxkIGJlIG11bHRpLXZhbHVlZCB3aGVyZSwgYXMgYQ0KDQpj
b25zZXF1ZW5jZSwgYm90aCB0aGUgInNhbHRlZCBhdWQgY2xhaW0iIHdpdGggdGhlICJhdWQgc2Fs
dCBjbGFpbSINCg0Kd291bGQgYWxzbyBiZSBtdWx0aS12YWx1ZWQuDQoNCg0KDQoNCg0KMikgV2l0
aGluIGNsYXVzZSA2LCAiUHJpdmFjeSBDb25zaWRlcmF0aW9ucyIsIHRoZSB0ZXh0IHN0YXRlczoN
Cg0KDQoNCiAgIEFzIEpXVCBhY2Nlc3MgdG9rZW5zIGNhcnJ5IGluZm9ybWF0aW9uIGJ5IHZhbHVl
LCBpdCBub3cgYmVjb21lcw0KDQogICBwb3NzaWJsZSBmb3IgcmVxdWVzdG9ycyBhbmQgcmVjZWl2
ZXJzIHRvIGRpcmVjdGx5IHBlZWsgaW5zaWRlIHRoZQ0KDQogICB0b2tlbiBjbGFpbXMgY29sbGVj
dGlvbi4gIFRoZSBjbGllbnQgTVVTVCBOT1QgaW5zcGVjdCB0aGUgY29udGVudCBvZg0KDQogICB0
aGUgYWNjZXNzIHRva2VuOiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJj
ZSBzZXJ2ZXINCg0KICAgbWlnaHQgZGVjaWRlIHRvIGNoYW5nZSB0b2tlbiBmb3JtYXQgYXQgYW55
IHRpbWUgKC4uLikuDQoNCg0KDQpPbiB0aGUgY29udHJhcnksIGEgY2xpZW50IFNIQUxMIGJlIGFi
bGUgdG8gaW5zcGVjdCB0aGUgY29udGVudCBvZiB0aGUNCg0KYWNjZXNzIHRva2VuIHRvIG1ha2Ug
c3VyZSB0aGF0IHRoZSBBUyBoYXMgbm90IGluY2x1ZGVkIGluIHRoZSBBVCBzb21lDQoNCnByaXZh
dGUgaW5mb3JtYXRpb24NCg0KdGhhdCBzaG91bGQgbm90IGJlIHByZXNlbnQsIGJlZm9yZSBmb3J3
YXJkaW5nIHRoZSBBVCB0byB0aGUgUlMuIEl0IGlzDQoNCnBvc3NpYmxlIGZvciBhbiBBUyB0byBj
aGFuZ2UgdGhlIGZvcm1hdCBvZiB0aGUgQVQsIGJ1dCB0aGUgUlMgd2lsbCBub3QNCg0KbmVjZXNz
YXJpbHkgYmUgaW4gc3luY2gNCg0Kd2l0aCB0aGUgUlMuDQoNCg0KDQpTaW5jZSB0aGVyZSBhcmUg
bm93IGNhc2VzIHdoZXJlICJ0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlDQoN
CnNlcnZlciBhcmUgbm90IGNvLWxvY2F0ZWQsIGFyZSBub3QgcmFuIGJ5IHRoZSBzYW1lIGVudGl0
eSwgb3IgYXJlDQoNCm90aGVyd2lzZSBzZXBhcmF0ZWQNCg0KYnkgc29tZSBib3VuZGFyeSIsIGEg
a2V5IHBvaW50IGlzIHRoYXQgYW4gQVMgYW5kIGEgUlMgRE8gTk9UDQoNCm5lY2Vzc2FyaWx5IG5l
ZWQgdG8ga25vdyBlYWNoIG90aGVyLiBUaGUgUlMgb25seSBuZWVkcyB0byB0cnVzdCB0aGUNCg0K
QVMuIChmdWxsIHN0b3ApDQoNCg0KDQpUaGlzIG1lYW5zIHRoYXQgYW4gaWRlbnRpZmllciBvZiB0
aGUgcHJvZmlsZSBvZiB0aGUgQVQgc2hvdWxkIGJlIGFibGUNCg0KdG8gYmUgaW5jbHVkZWQgaW50
byB0aGUgQVQuIFRoaXMgYWxsb3dzIGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4NCg0KDQoNCkluIGFu
eSBjYXNlLCB0aGUgIk1VU1QgTk9UIiBpbiB0aGUgcXVvdGVkIHNlbnRlbmNlIHNob3VsZCBiZSBy
ZW1vdmVkDQoNCm9yIGNoYW5nZWQgb3IgdGhlIHdob2xlIHNlbnRlbmNlIHNob3VsZCBiZSByZW1v
dmVkLi4NCg0KDQoNCg0KDQozKSBXaXRoaW4gY2xhdXNlIDIuMi4yIChzZWNvbmQgcGFyYWdyYXBo
KToNCg0KDQoNCiAgIFRoaXMgcHJvZmlsZSBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG1lY2hhbmlz
bSBmb3IgYSBjbGllbnQgdG8NCg0KICAgZGlyZWN0bHkgcmVxdWVzdCB0aGUgcHJlc2VuY2Ugb2Yg
c3BlY2lmaWMgY2xhaW1zIGluIEpXVCBhY2Nlc3MNCg0KICAgdG9rZW5zLCBhcyB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIgY2FuIGRldGVybWluZSB3aGF0IGFkZGl0aW9uYWwNCg0KICAgY2xhaW1z
IGFyZSByZXF1aXJlZCBieSBhIHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyIGJ5IHRha2luZyBp
bg0KDQogICBjb25zaWRlcmF0aW9uIHRoZSBjbGllbnRfaWQgb2YgdGhlIGNsaWVudCwgdGhlIHNj
b3BlIGFuZCB0aGUgcmVzb3VyY2UNCg0KICAgcGFyYW1ldGVycyBpbmNsdWRlZCBpbiB0aGUgcmVx
dWVzdC4NCg0KDQoNCkFsbG93aW5nIGEgY2xpZW50IHRvIG9ubHkgc3BlY2lmeSBhIHNjb3BlIGFu
ZCBhIHJlc291cmNlIGlzIHZlcnkNCg0KcmVzdHJpY3RpdmUuDQoNCg0KDQpXaGF0IHdvdWxkIGJl
IHRoZSB0aXRsZSBvZiBhbiBSRkMgdGhhdCB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvDQoNCnJl
cXVlc3QgdGhlIHByZXNlbmNlIG9mIHNwZWNpZmljIGNsYWltcyBpbiBKV1QgYWNjZXNzID8NCg0K
DQoNCklmIHN1Y2ggYSByZXN0cmljdGlvbiBpcyBrZXB0LCB3b3VsZCB0aGUgY3VycmVudCB0aXRs
ZSBvZiB0aGlzIFJGQw0KDQpzdGlsbCBiZSBpbmFwcHJvcHJpYXRlDQoNCiJKU09OIFdlYiBUb2tl
biAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyIgPw0KDQoNCg0KRGVu
aXMNCg0KDQoNCkRQIFNlY3VyaXR5IENvbnN1bHRpbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpP
QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=

--_000_ECADC22B22BE4656B925F2E84C86DADFamazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3C786CB7EC3A9849AB91022A87CDFBFE@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg
MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAy
IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUg
YXJlIHVzZSBjYXNlcyB3aGVyZSB0aGUgQVMgY2FuIGJlIGV4cGVjdGVkIHRvIGtub3cgKGFuZCBp
biBmYWN0IG5lZWRzIHRvIGtub3cpIHdoaWNoIFJTZXMgYSB0b2tlbiB3aWxsIGJlIHVzZWQgd2l0
aCwgYW5kIHVzZSBjYXNlcyB3aGVyZSB0aGVyZSBpcyB2YWx1ZSBpbiBvYnNjdXJpbmcgdGhpcyBm
YWN0LiBUaGlzIHNwZWMgc2hvdWxkIG5vdCBiZSBsaW1pdGVkIHRvIG9ubHkgb25lIG9yIHRoZSBv
dGhlci4NCiBUaGUgd29yayB5b3Ugc3VnZ2VzdCB0byBzdXBwb3J0IG9ic2N1cmluZyB0aGUgUlMg
aWRlbnRpdHkgaXMgbm90IHVuaXF1ZSB0byBhbnkgcGFydGljdWxhciBhY2Nlc3MgdG9rZW4gZm9y
bWF0LCBhbmQgaXMgdGhlcmVmb3JlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGlrZXdpc2UsIHRva2VuIGZvcm1hdCBuZWdvdGlhdGlvbiBp
cyBhbiBpbnRlcmVzdGluZyBjb25jZXB0LCBidXQgYnkgaXRzIG5hdHVyZSBpcyBub3QgYm91bmQg
dG8gYW55IHNwZWNpZmljIGZvcm1hdC4gSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHB1cnN1aW5n
IHRoYXQgd29yaywgSSBzdWdnZXN0IHN1Ym1pdHRpbmcgaXQgYXMgYSBzZXBhcmF0ZSBJLUQuIEEg
SldUIGFjY2VzcyB0b2tlbiBwcm9maWxlIHByb3ZpZGVzDQogc2lnbmlmaWNhbnQgdmFsdWUgd2l0
aG91dCB0aGlzIGFkZGl0aW9uLCBzbyBJIGRvbuKAmXQgc2VlIGFueSBiZW5lZml0IGluIHRyeWlu
ZyB0byBpbmNvcnBvcmF0ZSBpdCBpbnRvIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk5vdGUgdGhhdCBwZXJtaXR0aW5nIHRoZSBjbGllbnQgdG8gaW5zcGVjdCB0aGUgYWNjZXNz
IHRva2VuIGRvZXMgbm90IHByZXZlbnQgdGhlIEFTIGFuZCBSUyBmcm9tIGV4Y2hhbmdpbmcgaW5m
b3JtYXRpb24gYWJvdXQgdGhlIGNsaWVudCBvciByZXNvdXJjZSBvd25lciwgYXMgdGhpcyBjb3Vs
ZCBiZSBkb25lIHZpYSBwcm9wcmlldGFyeSBjbGFpbXMgd2l0aCBlbmNyeXB0ZWQgdmFsdWVzIG9y
IHZpYSBzZXBhcmF0ZQ0KIHNlcnZpY2UtdG8tc2VydmljZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0
aGUgUlMgYW5kIEFTLiBJdCBzaG91bGQgYWxzbyBiZSBub3RlZCB0aGF0IGluIG1hbnkgY2FzZXMg
KG5vdGFibHkgb25lcyB3aGVyZSB0aGUgQVMgYW5kIFJTIGFyZSBjbG9zZWx5IGFmZmlsaWF0ZWQp
IGVuY3J5cHRpbmcgdGhlIGFjY2VzcyB0b2tlbiBwcmVzZXJ2ZXMgdGhlIHJlc291cmNlIG93bmVy
4oCZcyBwcml2YWN5IGJ5IHByZXZlbnRpbmcgdGhlIGNsaWVudCBmcm9tIHNlZWluZw0KIGluZm9y
bWF0aW9uIHRoYXQgdGhlIHJlc291cmNlIG93bmVyIGhhcyBzaGFyZWQgd2l0aCB0aGUgQVMgYW5k
IFJTIGJ1dCBub3QgdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFzdGx5IEkg
YW0gYWdhaW5zdCBhZGRpbmcgYSBtZWNoYW5pc20gZm9yIHJlcXVlc3RpbmcgYXJiaXRyYXJ5IGNs
YWltcyB0byBiZSBpbmNsdWRlZCBpbiB0aGUgYWNjZXNzIHRva2VuLiBUaGUgcHVycG9zZSBvZiB0
aGUgYWNjZXNzIHRva2VuIGlzIHRvIHNlcnZlIGFzIGNyZWRlbnRpYWxzIHRoYXQgdGhlIGNsaWVu
dCBjYW4gdXNlIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBJZiB0aGUgY2xpZW50IHdh
bnRzDQogY2xhaW1zLCB0aGV5IHNob3VsZCByZXF1ZXN0IHRoZSBhcHByb3ByaWF0ZSBzY29wZXMg
YW5kIHJldHJpZXZlIHRoZW0gZnJvbSBhIHByb2ZpbGUgb3IgdXNlcmluZm8gZW5kcG9pbnQsIG9y
IHVzZSBPSURDLiBUaGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgdGhlIHJlc291cmNlIHNlcnZl
ciBzaG91bGQgYmUgdW5kZXJzdG9vZCBieSB0aGUgQVMgYmFzZWQgb24gdGhlIHJlc291cmNlIGlu
ZGljYXRvcnMgYW5kIHNjb3BlcyBpbiB0aGUgcmVxdWVzdC4NCiBJZiB0aGlzIGlzIG5vdCB0aGUg
Y2FzZSwgdGhlbiB0aGF0IHN1Z2dlc3RzIHRoZXJlIGlzIGEgdHJ1c3QgYm91bmRhcnkgYmV0d2Vl
biB0aGUgQVMgYW5kIFJTIGFuZCB0aGVyZWZvcmUgbmVlZHMgdG8gbWFrZSBpdHMgb3duIGF1dGhv
cml6YXRpb24gcmVxdWVzdC4gU2luY2UgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMgcmVwcmVzZW50
IGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgdG8gdGhlDQo8aT5jbGllbnQ8L2k+LCBpdCB3b3VsZCBi
ZSBpbmFwcHJvcHJpYXRlIHRvIGJ1bmRsZSB0aGUgcmVzb3VyY2Ugc2VydmVy4oCZcyBhdXRob3Jp
emF0aW9uIHJlcXVlc3QgaW50byB0aGUgY2xpZW504oCZcyBhdXRob3JpemF0aW9uIHJlcXVlc3Qu
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdCI+4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0i
aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2
M0MxIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5Lzwvc3Bhbj48L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr
Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi
bGFjayI+T0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBE
ZW5pcyAmbHQ7ZGVuaXMuaWV0ZkBmcmVlLmZyJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXks
IEFwcmlsIDEyLCAyMDIwIGF0IDg6NDggQU08YnI+DQo8Yj5UbzogPC9iPkJlbmphbWluIEthZHVr
ICZsdDtrYWR1a0BtaXQuZWR1Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Vml0dG9yaW8gQmVydG9jY2kg
Jmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDssIG9hdXRoICZsdDtvYXV0aEBpZXRm
Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtFWFRFUk5BTF0gW09BVVRILVdHXSBX
R0xDIG9uICZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBB
Y2Nlc3MgVG9rZW5zJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg
Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MjIiIHN0
eWxlPSJ3aWR0aDo0NjYuNXB0O21hcmdpbi1sZWZ0Oi41aW47Ym9yZGVyLWNvbGxhcHNlOmNvbGxh
cHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjI1cHQiPg0KPHRkIHdpZHRoPSI2
MjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NDY2LjVwdDtib3JkZXI6c29saWQgI0VEN0Qz
MSAxLjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAwaW4gNS40cHQ7aGVpZ2h0OjE1LjI1cHQiPg0KPHA+
PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6I0ZGRkY5OSI+Q0FVVElPTjwvc3Bhbj48L3N0
cm9uZz48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFja2dyb3VuZDojRkZGRjk5Ij46IFRoaXMg
ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90
IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzDQogeW91IGNhbiBjb25maXJt
IHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5IaSBCZW5qYW1pbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj5TaW5jZSB0aGVyZSBpcyB0b21vcnJvdyBhIHZpcnR1YWwgbWVldGluZyBhbmQg
YWRkaXRpb25hbGx5IEkgYW0gbG9ja2VkIGRvd24sIGJ5IGV4Y2VwdGlvbiwgSSByZXBseSB0b2Rh
eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XZSBib3Ro
IGFncmVlIHRoYXQgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNl
cnZlciBhcmUgbm90IGNvLWxvY2F0ZWQsIGFyZSBub3QgcnVuIGJ5IHRoZSBzYW1lIGVudGl0eSwN
Cjxicj4NCm9yIGFyZSBvdGhlcndpc2Ugc2VwYXJhdGVkIGJ5IHNvbWUgYm91bmRhcnkmcXVvdDsg
dGhpcyBkb2VzIGluZGVlZCBwcmVzZW50IHNvbWUgY29uc2VxdWVuY2VzIGZvciB0aGUgcHJpdmFj
eSBjb25zaWRlcmF0aW9ucw0KPGJyPg0Kb2YgdGhlIHByb3RvY29sIHRoYXQgd2lsbCBuZWVkIHRv
IGJlIGFkZHJlc3NlZCBpbiBzb21lIG1hbm5lci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5Ub2RheSBPQXV0aCAyLjAgaGFzIG5vdCBiZWVuIGNvbnN0cnVj
dGVkIHRha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhpcyBjYXNlLCBpLmUuIGl0IGhhcyBub3Qg
YmVlbiBkZXNpZ25lZCB0YWtpbmcgaW50byBjb25zaWRlcmF0aW9uDQo8YnI+DQomcXVvdDtQcml2
YWN5IGJ5IERlc2lnbiZxdW90Oy4gVGhlIGZhY3QgaXMgdGhhdCBPQXV0aCAyLjAgaGFzIG5vdGhp
bmcgc3BlY2lmaWMgdG8gdGFrZSBjYXJlIG9mIHByaXZhY3kgcHJpbmNpcGxlcy4NCjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZXJlIHdvdWxkIGJlIGEg
c2ltcGxlIHdheSB0byBzb2x2ZSBzb21lIG9mIG15IGNvbmNlcm5zOiB0byByZW1vdmUgaW4gdGhl
IEludHJvZHVjdGlvbiAoU2VjdGlvbiAxKSBsaW5lcyA3IHRvIDEwIDoNCjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBhcHByb2FjaCBpcyBw
YXJ0aWN1bGFybHkgY29tbW9uIGluPGJyPg0KJm5ic3A7Jm5ic3A7IHRvcG9sb2dpZXMgd2hlcmUg
dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgYXJlIG5vdDxicj4N
CiZuYnNwOyZuYnNwOyBjby1sb2NhdGVkLCBhcmUgbm90IHJhbiBieSB0aGUgc2FtZSBlbnRpdHks
IG9yIGFyZSBvdGhlcndpc2U8YnI+DQombmJzcDsmbmJzcDsgc2VwYXJhdGVkIGJ5IHNvbWUgYm91
bmRhcnkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5MZXQgdXMgbm93
IGFzc3VtZSB0aGF0IHByaXZhY3kgY29uY2VybnMgd291bGQgYmUgYWRkcmVzc2VkIGluIGVpdGhl
ciBPQXV0aCAyLjEuIG9yIE9BdXRoIDMuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj5UaGlzIHNwZWMuIGlzIHN1cHBvc2VkIHRvIGJlIHRhcmdldGVkIHRv
IE9BdXRoIDIuMCBidXQgdGhlIGhlYWRlciBhdCB0aGUgdG9wIG9mIHRoZSBwYWdlIG9taXRzIHRv
IG1lbnRpb24gaXQuIEN1cnJlbnRseSwgaXQgaXMgOg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkludGVybmV0
LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIEFjY2VzcyBU
b2tlbiBKV1QgUHJvZmlsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBNYXJjaCAyMDIwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPkl0IHNob3VsZCByYXRoZXIgYmU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkludGVy
bmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoDQo8Yj4y
LjA8L2I+IEFjY2VzcyBUb2tlbiBKV1QgUHJvZmlsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNYXJjaCAyMDIwPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZXJlIGlzIGhvd2V2ZXIgYSBwcm9ibGVt
IHRvIGJlIHNvbHZlZCBub3c6IHRvIGFsbG93IHRvIGVhc2lseSBkaXN0aW5ndWlzaCBiZXR3ZWVu
IE9BdXRoIDIuMCBKV1QgYW5kIGZ1dHVyZSBKV1QgdmVyc2lvbnMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SW4gYWRkaXRpb24sIHRoZXJlIHdpbGwgYmUg
dGhlIG5lZWQgdG8gYmUgYWJsZSB0byBjYXJyeSB1bnNpZ25lZCBwYXJhbWV0ZXJzIGFzc29jaWF0
ZWQgd2l0aCBhbiBPQXV0aCAyLjEuIG9yIE9BdXRoIDMuMCBKV1QuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gaGlzdG9yaWNhbCBleGFtcGxlIHdhcyB0
byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIHRoZSB2ZXJzaW9uIG9mIGEgWC41MDkgcHVibGljIGtl
eSBjZXJ0aWZpY2F0ZSB1c2luZyBhIHZlcnNpb24gcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPlNvbWV0aGluZyBzaW1pbGFyIHNob3VsZCBiZSBkb25lLiA8bzpwPg0KPC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNlY3Rpb24gNiAoUHJpdmFjeSBDb25zaWRl
cmF0aW9ucykgc2hvdWxkIGJlIG1vZGlmaWVkLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIE1VU1QgTk9UIChpbnNwZWN0IHRoZSBjb250ZW50IG9m
IHRoZSBhY2Nlc3MgdG9rZW4pIHNob3VsZCBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvbWUgdGV4dCwgbGlrZSB0aGUgZm9sbG93aW5n
IHRleHQsIHNob3VsZCBiZSBhZGRlZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkluIHRvcG9sb2dp
ZXMgd2hlcmUgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgYXJl
IG5vdCBjby1sb2NhdGVkLCBhcmUgbm90IHJhbiBieSB0aGUgc2FtZSBlbnRpdHksIG9yIGFyZSBv
dGhlcndpc2UNCjxicj4NCnNlcGFyYXRlZCBieSBzb21lIGJvdW5kYXJ5LCBzb21lIHByaXZhY3kg
Y29uY2VybnMgYXJpc2UuIEZvciBzZWN1cml0eSByZWFzb25zLCBzb21lIGNsaWVudHMgbWF5IHdh
bnQgdG8gdGFyZ2V0IHRoZWlyIGFjY2VzcyB0b2tlbnMNCjxicj4NCmJ1dCwgZm9yIHByaXZhY3kg
cmVhc29ucywgbWF5IGJlIHVud2lsbGluZyB0byBkaXNjbG9zZSB0byBhdXRob3JpemF0aW9uIHNl
cnZlcnMgYW4gaWRlbnRpZmljYXRpb24gb2YgdGhlIHJlc291cmNlIHNlcnZlcnMgdGhleSB3aWxs
IGFjY2VzcywNCjxicj4NCnNvIHRoYXQgYXV0aG9yaXNhdGlvbiBzZXJ2ZXJzIHdpbGwgYmUgdW5h
YmxlIHRvIGtub3cgd2hpY2ggcmVzb3VyY2VzIHNlcnZlcnMgYXJlIGJlaW5nIGFjY2Vzc2VkLiBU
aGlzIHByb2ZpbGUgZG9lcyBub3QgY29udGFpbiBwcm92aXNpb25zDQo8YnI+DQp0byBhZGRyZXNz
IHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij5Gb3IgZGF0YSBtaW5pbWl6YXRpb24sIG9wZW5uZXNzIGFuZCB0cmFuc3BhcmVuY3ksIHNvbWUg
Y2xpZW50cyBtYXkgd2FudCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgd2l0aCBhIGZpbmUgZ3JhbnVs
YXJpdHkgd2hpY2ggb2YgdGhlaXIgaWRlbnRpdHkgYXR0cmlidXRlczxicj4NCnNob3VsZCBiZSBp
bmNvcnBvcmF0ZWQgaW50byBhbiBhY2Nlc3MgdG9rZW4gYW5kIG1heSB3YW50IHZlcmlmeSB0aGF0
IG9ubHkgdGhlIHJlcXVlc3RlZCBpZGVudGl0eSBhdHRyaWJ1dGVzIGhhdmUgaW5kZWVkIGJlZW4g
aW5jb3Jwb3JhdGVkLiBUaGlzIHByb2ZpbGUNCjxicj4NCnN1cHBvcnRzIGEgc2NvcGUgcGFyYW1l
dGVyIHRoYXQgYWxsb3dzIHRvIHNwZWNpZnkgaW4gYWR2YW5jZSB3aGljaCBpZGVudGl0eSBhdHRy
aWJ1dGVzIHNob3VsZCBiZSBpbmNvcnBvcmF0ZWQsIGJ1dCB0aGUgc2VtYW50aWNzIG9mIHRoaXMg
cGFyYW1ldGVyDQo8YnI+DQppcyBzcGVjaWZpYyB0byBldmVyeSBhdXRob3Jpc2F0aW9uIHNlcnZl
ci4gUHJlc2VudGx5LCB0aGVyZSBpcyBub3Qgc3RhbmRhcmRpemVkIHdheSB0byBkZWZpbmUsIHdp
dGggYSBmaW5lIGdyYW51bGFyaXR5LCB3aGljaCBpZGVudGl0eSBhdHRyaWJ1dGVzIHdpbGwgYmUN
Cjxicj4NCmluY29ycG9yYXRlZCBpbnRvIGFuIGFjY2VzcyB0b2tlbi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5NeSBsYXN0IG5ldyBjb21tZW50IHJlbWFpbnMgdmFsaWQ6IGl0
IGlzIHF1aXRlIG9kZCB0aGF0IHRoZXJlIGlzIG5vIGZvcm1hbCBkZXNjcmlwdGlvbiBvZiBhbiBB
VCBwcm9maWxlIGFueXdoZXJlIGluIHRoZSBjdXJyZW50IGRvY3VtZW50Lg0KPGJyPg0KQSBzeW50
YXggZGVzY3JpcHRpb24gd291bGQgZ3JlYXRseSBlbmhhbmNlIGludGVyb3BlcmFiaWxpdHkuJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPkRlbmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgRGVuaXMsPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGFtIGdvaW5nIHRvIHRvcC1wb3N0IGJl
Y2F1c2UgdGhlIHF1b3RpbmcgaW4gdGhpcyB0aHJlYWQgaGFzIGJlY29tZSBwcmV0dHk8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bWFuZ2xlZC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkZpcnN0IG9mZiwgdGhhbmsg
eW91IGZvciBjYWxsaW5nIG91dCB0aGUgdGV4dCBpbiB0aGUgZG9jdW1lbnQgYWJvdXQ8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+c2NlbmFyaW9zIHdoZXJl
ICZxdW90O3RoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGFyZSBu
b3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Y28tbG9j
YXRlZCwgYXJlIG5vdCBydW4gYnkgdGhlIHNhbWUgZW50aXR5LCBvciBhcmUgb3RoZXJ3aXNlIHNl
cGFyYXRlZCBieTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij5zb21lIGJvdW5kYXJ5JnF1b3Q7OyB0aGlzIGRvZXMgaW5kZWVkIHByZXNlbnQgc29tZSBjb25z
ZXF1ZW5jZXMgZm9yIHRoZSBwcml2YWN5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPmNvbnNpZGVyYXRpb25zIG9mIHRoZSBwcm90b2NvbCB0aGF0IHdpbGwg
bmVlZCB0byBiZSBhZGRyZXNzZWQgaW4gc29tZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5tYW5uZXIsIHRob3VnaCBub3QgbmVjZXNzYXJpbHkgdGhlIG9u
ZSB0aGF0IHlvdSBlbnZpc2lvbi4mbmJzcDsgSSB3aWxsIHRyeSB0bzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yZW1lbWJlciB0byBjaGVjayBmb3IgdGhp
cyBwb2ludCB3aGVuIHRoZSBkb2N1bWVudCBwcm9ncmVzc2VzIHRvIElFU0c8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RXZhbHVhdGlvbi48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPllvdSBvdXRsaW5lIHNvbWUgaW50
ZXJlc3RpbmcgcHJvdG9jb2wgcHJvcG9zYWxzLCBzdWNoIGFzIGxldHRpbmcgdGhlIGNsaWVudDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5jaG9vc2UgdGhl
IHRva2VuIHByb2ZpbGUgdHlwZSwgbWFuZGF0aW5nIChpbiBhdCBsZWFzdCBzb21lIGNhc2VzKTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj52aXNpYmlsaXR5
IGludG8gdGhlIHRva2VuIGNvbnRlbnRzIGZvciB0aGUgY2xpZW50LCBhbmQgbGV0dGluZyB0aGUg
Y2xpZW50PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFk
ZCBhZGRpdGlvbmFsIHRva2VuIHBhcmFtZXRlcnMgaW4gaXRzIHJlcXVlc3QsIGJ1dCBpdCBzZWVt
cyBwcmV0dHkgY2xlYXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+dG8gbWUgdGhhdCB3aGlsZSB0aGVzZSB3b3VsZCBtYWtlIGZvciBhbiBpbnRlcmVzdGlu
ZyBwcm90b2NvbCwgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5wcm90b2NvbCB3b3VsZCBmdW5kYW1lbnRhbGx5IG5vdCBiZSBPQXV0aCAyLjAuJm5i
c3A7IEFzIHN1Y2gsIGl0IGRvZXNuJ3Qgc2VlbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5hcHByb3ByaWF0ZSB0byBhdHRlbXB0IHRvIHJlcXVpcmUgdGhl
bSBhcyBwYXJ0IG9mIHRoaXMgc3BlY2lmaWMgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHdvdWxkIGFsc28gbm90ZSB0aGF0IGZyYW1pbmcg
dGhpbmdzIGFzIGEgY29udHJhc3QgYmV0d2VlbiAmcXVvdDtwcml2YWN5IGJ5PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmRlc2lnbiZxdW90OyBhbmQgJnF1
b3Q7c3B5IGJ5IGRlc2lnbiZxdW90OyBzZWVtcyBkZXNpZ25lZCB0byBldm9rZSBhbiBlbW90aW9u
YWwgcmVhY3Rpb24sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPmFuZCBhcyBzdWNoIGFyZSBhY3RpdmVseSBoYXJtZnVsIHRvIHJhdGlvbmFsIHRlY2huaWNh
bCBkZWJhdGUuJm5ic3A7IEkgaW1wbG9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj55b3UgdG8gZm9jdXMgb24gdGhlIGZhY3RzIG9mIHdoYXQgZGF0YSBm
bG93cyB3aGVyZSBhbmQgd2hpY2ggYXNwZWN0cyBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj5zdWNoIGZsb3dzIGFyZSBkZXNpcmFibGUgYW5kIHVuZGVz
aXJhYmxlIGluIHRoZSB2YXJpb3VzIHNpdHVhdGlvbnMgdW5kZXI8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Y29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkZpbmFsbHksIEknbGwgbm90ZSB0aGF0
IHRob3VnaCBJIGFtIG1vc3RseSBqdXN0IGFuIG9ic2VydmVyIGhlcmUgYW5kIG5vdCBhbjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5pbXBsZW1lbnRvciwg
aXQncyBteSBzZW5zZSB0aGF0IE9BdXRoIDIuMCBhcyBjdXJyZW50bHkgZGVwbG95ZWQgaW52b2x2
ZXMgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yZWxh
dGl2ZWx5IGxhcmdlIG51bWJlciBvZiBSU2VzIHNwZWFraW5nIHRvIGEgY29tcGFyYWJsZSBvciBz
bWFsbGVyIG51bWJlciBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5BU2VzLCBhbmQgdGhhdCBpdCBpcyBjb21tb24gZm9yIEFTIGltcGxlbWVudGF0aW9u
cyB0byBoYXZlIHNpZ25pZmljYW50PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPmFtb3VudHMgb2YgbG9naWMgZGVkaWNhdGVkIHRvIGtub3dpbmcgdGhlIGNh
cGFiaWxpdGllcyBvZiB0aGUgUlNlcyB0aGV5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPnNlcnZlLiZuYnNwOyBNYW55IG9mIHlvdXIgY29tbWVudHMgZG8g
bm90IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoaXMgd29ybGR2aWV3LDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hbmQgSSBpbnZpdGUgdGhlIG90aGVyIFdH
IHBhcnRpY2lwYW50cyB0byBjbGFyaWZ5IGlmIG15IHVuZGVyc3RhbmRpbmcgaXM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aW5jb3JyZWN0LjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmtzLDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmVuPG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBGcmksIEFwciAxMCwgMjAyMCBhdCAxMTow
NzozNUFNICYjNDM7MDIwMCwgRGVuaXMgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgVml0dG9yaW8sPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFuayB5b3UgZm9yIHlvdXIgZmFzdCByZXNwb25z
ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPllvdSB3cm90
ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu
YnNwOyZuYnNwOyAmcXVvdDsvSXQgZG9lc27igJl0IGxvb2sgdmVyeSBsaWtlbHkgdGhhdCBhbiBS
UyB3b3VsZCBzaW1wbHkgYWNjZXB0IHRva2VuczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgZnJvbSBhbiBBUyB3aXRob3V0
IHNvbWUgb3V0IG9mIGJhbmQgbmVnb3RpYXRpby9uLCAmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFuZCBhbHNvOjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Oy9BcyBm
YXIgdGhlIGNsaWVudCBpcyBjb25jZXJuZWQsIHRoZSBSUyBhbmQgdGhlIEFTIG1pZ2h0IHN3aXRj
aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm
bmJzcDsmbmJzcDsgdGhlaXIgYWdyZWVtZW50LyZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2l0aCBzdWNoIHNlbnRlbmNlcywgaXQgc2VlbXMgdGhh
dCB5b3UgbWFuZGF0ZSBhIGRpcmVjdCBuZWdvdGlhdGlvbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YmV0d2VlbiB0aGUgQVMgYW5kIHRoZSBSUyB3aGlj
aCwgYnkgaW1wbGljYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPm1lYW5zIHRoYXQgdGhlIEFTIGFuZCB0aGUgUlMgbXVzdCBrbm93IGVhY2ggb3Ro
ZXIsIHdoaWNoIGlzIGV4YWN0bHkgd2hhdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+SSB3YW50IHRvIGF2b2lkLiBTdWNoIHNvbWUgb3V0IG9mIGJhbmQg
bmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+Y2FuIHNpbXBseSBiZSBkb25lIGJ5IHB1Ymxpc2hpbmcgd2hpY2ggQVQgZm9ybWF0cyB0aGUg
QVMgaXMgYWJsZSB0byA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+Z2VuZXJhdGUgYW5kIHdoaWNoIEFUIGZvcm1hdHMgdGhlIFJTIGlzIGFibGUgdG8gYWNj
ZXB0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbiBB
UyBjYW4gcHVibGlzaCBtZXRhZGF0YSByZWxldmFudCB0byB0aGUgSldUIGFjY2VzcyB0b2tlbnMg
aXQgaXNzdWVzIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij5hbmQgYSBSUyBjYW4gZG8gdGhlIHNhbWUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj5JbiB0aGlzIHdheSwgdGhlIGNsaWVudCBjb3VsZCBjb25zdWx0IGJv
dGggcHVibGlzaGVkIGxpc3RzIGFuZCBjaG9vc2UgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPndoaWNoIGNvbW1vbiBmb3JtYXQsIGlmIGFueSwgd291bGQg
YmUgYXBwcm9wcmlhdGUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPlRoaXMgbWVhbnMgdGhhdCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIGluIGl0cyBB
VCByZXF1ZXN0IHRvIHNwZWNpZnkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPnRoZSBmb3JtYXQgb2YgdGhlIEFULCB0aHVzIGF2b2lkaW5nIGFueSBkaXJl
Y3Qgc29tZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5v
dXQgb2YgYmFuZCBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WW91IGNvbnRpbnVlIHNheWlu
Zzo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu
YnNwOyZuYnNwOyAmcXVvdDsgL25vciBpdCBzZWVtcyB2ZXJ5IGxpa2VseSB0aGF0IGFuIEFTIHdv
dWxkIGlzc3VlIHRva2VucyBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNlcyBpdCBkb2VzbuKAmXQga25v
dy8mcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5U
aGlzIGlzIHdoZXJlIHdlIGhhdmUgYSBtYWpvciBkaWZmZXJlbmNlIGluIG91ciBwb2ludHMgb2Yg
dmlld3MuIFRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+bnVtYmVyIG9mIEFTIGlzIGxpa2VseSB0byBiZSBzZXZlcmFsIG9yZGVyIG9mIG1hZ25pdHVk
ZXMgaGlnaGVyPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PmNvbXBhcmVkIHRvIHRoZSBudW1iZXIgb2YgUlMuIEV2ZXJ5IHRpbWUgYSBSUyBpcyBiZWluZyBl
c3RhYmxpc2hlZCwgaXQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPnNob3VsZCBub3QgaGF2ZSB0byBtYWtlIGl0c2VsZiBrbm93biB0byBhbnkgQVMuPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGlzIHdoeSBJ
IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC8mcXVvdDthIGtleSBwb2ludCBpcyB0aGF0IGFuIEFTIGFuZCBhIFJT
IERPIE5PVCBuZWNlc3NhcmlseSBuZWVkIHRvIGtub3c8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVhY2ggb3RoZXIuICpU
aGUgUlMgb25seSBuZWVkcyB0byB0cnVzdCB0aGUgQVMqLyouKi8oZnVsbCBzdG9wKSZxdW90Oy88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPllvdSBhcmUgYXNz
dW1pbmcgdGhhdCBhbiBBUyBhbmQgYSBSUyBuZWNlc3NhcmlseSBuZWVkIHRvIGtub3cgZWFjaCBv
dGhlci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPllvdSB3
cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw
OyZuYnNwOyZuYnNwOyAmcXVvdDsvVGhlIHNjZW5hcmlvIGluIHdoaWNoIGEgdG9rZW4gaXNzdWVy
IGlzbuKAmXQgYXdhcmUgb2Ygd2hlcmUgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBjbGllbnQgd2lsbCBzcGVuZCB0
aGUgY29ycmVzcG9uZGluZyB0b2tlbiBpcyBpbXBvcnRhbnQsPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBidXQgaXQgaXMg
bW9yZSB0aGUgcHJvdmluY2Ugb2YgU1NJIHRoYW4gbWFpbnN0cmVhbSBPQXV0aDIgdXNhZ2UgdG9k
YXkmcXVvdDsuLzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
VG9kYXksIGFzIHNvb24gYXMgYW4gQVQgaXMgdGFyZ2V0ZWQsIHRoZSBBUyB3aWxsIGJlIGF3YXJl
IHdoZXJlIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+Y2xpZW50IGlzIGxpa2VseSB0byBzcGVuZCB0aGUgQVQuIFRoZSByZWFsaXR5IGlzIHRoYXQg
dGhlIHNjZW5hcmlvPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPmluIHdoaWNoIGEgdG9rZW4gaXNzdWVyIHdpbGwgbm90IGJlIGF3YXJlIG9mIHdoZXJlIHRo
ZSBjbGllbnQgd2lsbCBzcGVuZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+dGhlIGNvcnJlc3BvbmRpbmcgdG9rZW4gaXMgdG9kYXkgY29tcGxldGVseSBv
dXQgb2YgdGhlIHNjb3BlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPm9mIE9BdXRoMiB1c2FnZXMgKHVuZm9ydHVuYXRlbHksIGl0IGlzIG5vdCBhIG1hdHRl
ciBvZiBtYWluc3RyZWFtIG9yIG5vdCkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5Gb3IgdGhhdCByZWFzb24sIGlmIHRoZSBzcGVjLiBjb250aW51ZXMgdG8g
cHJldmVudCB0byBpbXBsZW1lbnQgJnF1b3Q7UHJpdmFjeSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YnkgZGVzaWduJnF1b3Q7IGFyY2hpdGVjdHVyZXMg
YW5kIHdvcnNlLCBtYW5kYXRlcyAmcXVvdDtTcHkgYnkgZGVzaWduJnF1b3Q7PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFyY2hpdGVjdHVyZXMsIHRoaXMg
c2hvdWxkIGJlIGNsZWFybHkgYWR2ZXJ0aXNlZCBpbiB0aGUgUHJpdmFjeSA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q29uc2lkZXJhdGlvbnMgc2VjdGlv
bi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPllvdSByZWNv
bW1lbmQgdG8gc3BlY2lmeSB0aGUgc3BsaXQgQVQgc3RydWN0dXJlIEkgc3VnZ2VzdCBpbiBpdHMg
b3duIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5zcGVj
IHJhdGhlciB0aGFuIGluIGFuIGludGVyb3AgcHJvZmlsZSBmb3IgdGhlIGdlbmVyYWwgQVQgY2Fz
ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGN1
cnJlbnQgdGl0bGUgb2YgdGhlIGRvY3VtZW50IGlzOiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldU
KSBQcm9maWxlIGZvciA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+T0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDsuIFRoZSBjb250ZW50IG9mIHRoZSBk
b2N1bWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5p
cyBtdWNoIG1vcmUgdGhhbiB3aGF0IHRoZSB0aXRsZSBpbXBsaWVzIHNpbmNlIHRoZSBpbnRyb2R1
Y3Rpb24gc3RhdGVzIDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtCZXNpZGVzIGRlZmluaW5nIGEgY29tbW9uIHNl
dCBvZiBtYW5kYXRvcnkgYW5kIG9wdGlvbmFsIGNsYWltcywgdGhlPG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBwcm9maWxl
IHByb3ZpZGVzIGNsZWFyIGluZGljYXRpb25zIG9uIGhvdyBkZXRlcm1pbmUgdGhlIGNvbnRlbnQg
b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHRoZSBpc3N1ZWQgSldUIGFjY2VzcyB0b2tlbiwgaG93IGFuIGF1dGhvcml6
YXRpb24gc2VydmVyIGNhbiBwdWJsaXNoPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBtZXRhZGF0YSByZWxldmFudCB0byB0
aGUgSldUIGFjY2VzcyB0b2tlbnMgaXQgaXNzdWVzLCBhbmQgaG93PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBhIHJlc291
cmNlIHNlcnZlciBzaG91bGQgdmFsaWRhdGUgaW5jb21pbmcgSldUIGFjY2VzcyB0b2tlbnMmcXVv
dDsuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgZG9j
dW1lbnQgc3BlY2lmaWVzIGEgcHJvdG9jb2wgd2l0aCBzZXZlcmUgbGltaXRhdGlvbnMgaW4gdGhl
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hdXRob3Jp
emF0aW9uIHJlcXVlc3RzIHBhcmFtZXRlcnMgYW5kIHdpdGggc2V2ZXJlIGxpbWl0YXRpb25zIGZv
ciB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnZh
bGlkYXRpb24gb2YgQVQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPklmIHRoZSBzcGVjLiBzdGF5cyBsaWtlIHRoYXQsIGl0IHNob3VsZCByYXRoZXIgYmUg
Y2FsbGVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i
c3A7ICogJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgKkJhc2ljIFByb3RvY29sKiBmb3IgT0F1
dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDsgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICogJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkg
KkJhc2ljIFByb3RvY29sIGFuZCBQcm9maWxlKiBmb3IgT0F1dGggMi4wPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBBY2Nl
c3MgVG9rZW5zJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPkluIHRoZSBmdXR1cmUsIGEgdHJ1ZSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRv
a2VucyBjb3VsZCB0aGVuIGJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj53cml0dGVuLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+VGhlIGNhc2Ugd2hlcmUgYSBjbGllbnQgd291bGQgYmUgYWJsZSB0byBpbnNwZWN0
IHRoZSBjb250ZW50IG9mIGEgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPmdlbmVyYXRlZCBBVCwgaW5kZWVkIGNvbWVzIGludG8gY29udHJhZGljdGlvbiB3
aXRoIHRoZSBjYXNlIHdoZXJlIHRoZSBBUyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+d291bGQgZW5jcnlwdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj5pdHMgY29udGVudCBmb3IgdGhlIGludGVuZGVkIHJlY2lw
aWVudCBhbmQgeW91IGFkdm9jYXRlIHRoYXQgaXQgaXMgPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFub3RoZXIgcmVhc29uICZxdW90O2ZvciB3aGljaCB0
aGUgQVMgaW4gdGhlIGdlbmVyYWwgY2FzZSBuZWVkcyB0byBrbm93IHRoZSA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aW50ZW5kZWQgcmVjaXBpZW50JnF1
b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBp
cyBub3QgdGhlIGdlbmVyYWwgY2FzZSwgYnV0IGEgc3BlY2lmaWMgY2FzZSwgd2hpY2ggaXMgbW9y
ZSBkaWZmaWN1bHQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPnRvIGRlcGxveSB0aGFuIHRoZSBzaW1wbGVzdCBjYXNlIHdoZXJlIFJTIG9ubHkgbmVlZCB0
byBrbm93IHRoZSBBUyB0aGF0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj50aGV5IHRydXN0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5JdCBpcyBhIHRyYWRlIG9mZiAvZm9yIHRoZSBjbGllbnQvIHRvIGJlIGFi
bGUgdG8gaW5zcGVjdCBpdHNlbGYgdGhlIEFUIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5vZiB0byBtYWtlIHN1cmUgdGhhdCBvbmx5IHRoZSBSUyB3aWxs
IGJlIGFibGUgdG8gaW5zcGVjdCB0aGUgQVQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj5JIHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1RoaXMgbWVhbnMgdGhhdCBh
biBpZGVudGlmaWVyIG9mIHRoZSBwcm9maWxlIG9mIHRoZSBBVCBzaG91bGQgYmU8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGFibGUgdG8gYmUgaW5jbHVkZWQgaW50byB0aGUgQVQuIFRoaXMgYWxsb3dzIGZvciBmdXR1cmUg
ZXh0ZW5zaW9ucy4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPllvdSByZXBsaWVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0NhbiB5b3UgZXhwYW5kIG9uIHRoZSBl
eGFjdCBzY2VuYXJpbyB5b3UgYXJlIHRoaW5raW5nIG9mIHRoYXQgY2FsbHM8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZv
ciBhIHZlcnNpb24/JnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5JZGVudGlmaWVyIGZvcm1hdHMgZm9yIEFUIHNob3VsZCBiZSBhYmxlIHRvIGJlIGlu
Y2x1ZGVkIGludG8gOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+Jm5ic3A7ICogdGhlIG1ldGFkYXRhIHB1Ymxpc2hlZCBieSB0aGUgQVMsPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAqIHRoZSBtZXRhZGF0
YSBwdWJsaXNoZWQgYnkgdGhlIFJTLCBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICogdGhlIEFUIGl0c2VsZi48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgc2tldGNoIG9mIHRoZSBzY2VuYXJpbyB3
b3VsZCBiZSBhcyBmb2xsb3dzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+VGhlIGNsaWVudCBjb25zdWx0cyBib3RoIHRoZSBtZXRhZGF0YSBwdWJsaXNoZWQg
YnkgdGhlIEFTIGFuZCB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPm1ldGFkYXRhIHB1Ymxpc2hlZCBieSB0aGUgUlMgYW5kIHRyaWVzIHRvIGZpbmQg
bWF0Y2hlcyBiZXR3ZWVuIHRva2VuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5mb3JtYXRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5JZiB0aGVyZSBhcmUgc2V2ZXJhbCBtYXRjaGVzLCBpdCB3aWxsIGNob29z
ZSxpZiBwb3NzaWJsZSwgYSBtYXRjaCB3aGVyZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aXQgY2FuIGFjY2VzcyBhbmQgdW5kZXJzdGFuZCB0aGUgY29u
dGVudCBvZiB0aGUgQVQuIEl0IHdpbGwgdGhlbiBpbmZvcm0gPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoZSBBUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5vZiBpdHMgY2hvaWNlIGJ5IGFkZGluZyB0aGUgaWRl
bnRpZmllciBvZiB0aGUgcHJvZmlsZSBvZiB0aGUgQVQgaW4gdGhlIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BVCByZXF1ZXN0LiBUaGUgQVMgd2lsbCBh
bHNvIGluY2x1ZGUgdGhlIGlkZW50aWZpZXIgb2YgdGhlIHByb2ZpbGUgb2YgPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoZSBBVCBpbiB0aGUgQVQ8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+c28gdGhhdCB0aGUg
UlMsIHdoZW4gaXQgcmVjZWl2ZXMgdGhlIEFULCBjYW4gdW5hbWJpZ3VvdXNseSBkZWNvZGUgdGhl
IEFULjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RmluYWxs
eSwgSSB3aWxsIGNvcHkgdGhlIGVuZCBvZiB5b3VyIGVtYWlsLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
QWxsb3dpbmcgYSBjbGllbnQgdG8gb25seSBzcGVjaWZ5IGEgc2NvcGUgYW5kIGEgcmVzb3VyY2Ug
aXMgdmVyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m
bmJzcDsmbmJzcDsmbmJzcDsgcmVzdHJpY3RpdmUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBTcGVjaWZ5aW5nIHNjb3Bl
IG9yIHVzaW5nIHJlc291cmNlIGluZGljYXRvcnMgYXJlIGFsbCB0aGUgbWVjaGFuaXNtczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm
bmJzcDsgSSBhbSBhd2FyZSBvZiB0aGF0IE9BdXRoMiBvZmZlcnMgZm9yIHNwZWNpZnlpbmcgd2hh
dCBhbiBhY2Nlc3MgdG9rZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSBmb3IgLSBhdCBsZWFzdCBhdCB0
aGUgdGltZSBpbiB3aGljaCB0aGUgc3BlYyB3YXMgaW5jZXB0ZWQuPG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAoLi4uKSAu
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz
cDsmbmJzcDsgV2hhdCBvdGhlciBpbnRlcm9wZXJhYmxlIG1lY2hhbmlzbXMgd291bGQgeW91IG9m
ZmVyIGluIGFkZGl0aW9uIHRvPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgb25lcyBsaXN0ZWQgaGVyZT88bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBjbGllbnQgc2hvdWxk
IGJlIGFibGUgdG8gc3BlY2lmeSBpbiBpdHMgQVQgcmVxdWVzdCBhZGRpdGlvbmFsIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hdHRyaWJ1dGVzIHdob3Nl
IHNlbWFudGljIGlzIHdlbGwgZGVzY3JpYmVkIGJ5IHRoZSBhdHRyaWJ1dGVzIGRlc2NyaXB0aW9u
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmZvdW5kIGlu
IHNlY3Rpb24gNS4xIG9mIFtPcGVuSUQuQ29yZV0gb3IgdGhlIGF0dHJpYnV0ZXMgZGVzY3JpcHRp
b24gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmZvdW5k
IGluIFtSRkM3NjYyXSBvciBvdGhlciBpZGVudGl0eSByZWxhdGVkIHNwZWNpZmljYXRpb25zLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KkFub3RoZXIgbmV3
IGFuZCBsYXN0IGNvbW1lbnQqOiBpdCBpcyBxdWl0ZSBvZGQgdGhhdCB0aGVyZSBpcyBubyBmb3Jt
YWwgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmRlc2Ny
aXB0aW9uIG9mIGFuIEFUIHByb2ZpbGUgYW55d2hlcmUgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQu
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkEgc3ludGF4
IGRlc2NyaXB0aW9uIHdvdWxkIGdyZWF0bHkgZW5oYW5jZSBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RGVuaXM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgRGVuaXMsPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFuayB5b3UgZm9yIHlvdXIg
ZmVlZGJhY2shPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J
bmxpbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi8mZ3Q7
IFByaXZhY3kgaGFzIG5vdCByZWFsbHkgYmVlbiBhIGNvbmNlcm4gaW4gdGhlIFdHIHNpbmNlIG9y
aWdpbmFsbHkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PnRoZSBBVCBhbmQgdGhlIFJTIHdlcmUgY28tbG9jYXRlZC4vPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db2xvY2F0aW9uIG9mIEFTIGFuZCBSUyB3YXMgYSBm
cmVxdWVudCBvY2N1cnJlbmNlLCBidXQgYnkgbm8gbWVhbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bWFuZGF0b3J54oCmIEFGQUlLIG9uZSBvZiB0aGUg
ZHJpdmVycyBmb3IgdGhlIGNoYW5nZXMgYmV0d2VlbiBPQXV0aDEgYW5kIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PQXV0aDIgd2FzIHByb3ZpZGluZyB0
aGUgYWJpbGl0eSBvZiBzdXBwb3J0aW5nIHRvcG9sb2dpZXMgd2hlcmUgQVMgYW5kIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SUyBhcmUgZGlzdGluY3Qg
cmlnaHQgb3V0IG9mIHRoZSBib3guPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj5UaGUgc2NlbmFyaW8gd2hlcmUgQVMgYW5kIFJTIGFyZSBkaXN0aW5jdCB3YXMg
YWx3YXlzIHBvc3NpYmxlIGluIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj5PdXRoMiwgYW5kIGFuZCBub3QgYnkgYWNjaWRlbnQuIFRoZSBKV1QgQVQganVz
dCBoYXBwZW5zIHRvIGJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5wYXJ0aWN1bGFybHkgaGFuZHkgaW4gZW1wb3dlcmluZyB0aGUgUlMgdG8gdmFsaWRh
dGUgaW5jb21pbmcgdG9rZW5zIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj53aXRob3V0IGhhdmluZyB0byBwaG9uZSBob21lIHRvIHRoZSBBUyBldmVyeSB0
aW1lLCBoZW5jZSBpdCBnaXZlcyB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPm9wcG9ydHVuaXR5IHRvIGRpc2N1c3MgaW1wbGljYXRpb25zIG9mIHRo
YXQgc2NlbmFyaW8gbW9yZSBpbiBkZXB0aCwgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPmJ1dCBkb2VzbuKAmXQgcmVhbGx5IGludHJvZHVjZSBhbnl0aGlu
ZyB0aGF0IHdhc27igJl0IHBvc3NpYmxlIGJlZm9yZS4gPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkV2ZW4gdGhlIHBvc3NpYmlsaXR5IG9mIGEgdG9rZW4g
Zm9ybWF0IHBhc3NpbmcgaW5mbyBieSB2YWx1ZSBpc27igJl0IDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5mb3JiaWRkZW4sIGRlZmF1bHQgT0F1dGgyIEFU
cyBhcmUgbm90IG1hbmRhdG9yaWx5IG9wYXF1ZS0gdGhleSBqdXN0IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5oYXBwZW4gbm90IHRvIGhhdmUgYSB3ZWxs
IGRlZmluZWQgZm9ybWF0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+Ki8mZ3Q7SW4gc3VjaCBjYXNlcy8qLywgaXQgaXMgaW1wb3J0YW50IHRvIGJlIGFibGUg
dG8gbWFrZSBzdXJlIHRoYXQgYW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPmF1dGhvcml6YXRpb24gc2VydmVyIHdpbGwgTk9UIGJlIGFibGUgdG8ga25v
dyB3aGVyZSB0aGUgYXV0aG9yaXphdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+dG9rZW5zIHRoYXQgaXQgaXNzdWVzIHdpbGwgYmUgdXNlZC4gVXNp
bmcgYW5vdGhlciB3b3JkaW5nLCBhbiBBUyBTSEFMTCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Tk9UIGJlIGFibGUgdG8ga25vdyB3aGVyZSBhbiBBVCBy
ZXF1ZXN0ZWQgYnkgYSBnaXZlbiBjbGllbnQgd2lsbCBiZSB1c2VkOjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIFNI
QUxMIG5vdCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIGFjdCBhcyAmcXVvdDtCaWcgPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJyb3RoZXImcXVvdDsqIGFu
ZCB0aHVzIFNIQUxMIG5vdCBiZSBhYmxlIHRvIGtub3cgd2hpY2ggcmVzb3VyY2VzIGFyZSBnb2lu
ZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50byBiZSBh
Y2Nlc3NlZCBieSBjbGllbnRzLi88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPlRoZSBzY2VuYXJpbyBpbiB3aGljaCBhIHRva2VuIGlzc3VlciBpc27igJl0IGF3
YXJlIG9mIHdoZXJlIHRoZSBjbGllbnQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPndpbGwgc3BlbmQgdGhlIGNvcnJlc3BvbmRpbmcgdG9rZW4gaXMgaW1w
b3J0YW50LCBidXQgaXQgaXMgbW9yZSB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPnByb3ZpbmNlIG9mIFNTSSB0aGFuIG1haW5zdHJlYW0gT0F1dGgy
IHVzYWdlIHRvZGF5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj5NYWluc3RyZWFtIE9BdXRoMiBpbiBjdXJyZW50IHVzZSwgcmVnYXJkbGVzcyBvZiB0aGUg
QVQgZm9ybWF0LCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+dHlwaWNhbGx5IGRvIGtub3cgZm9yIHdob20gdGhlIHRva2VuIGlzIGJlaW5nIGlzc3VlZDog
YSBncmVhdCBkZWFsIG9mIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5sb2dpYyBpcyBwcmVkaWNhdGVkIG9uIHRoYXQga25vd2xlZGdlLiBEaWQgdGhlIHVz
ZXIgY29uc2VudCBmb3IgdGhpcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+Y2xpZW50IHRvIGFjY2VzcyB0aGlzIHBhcnRpY3VsYXIgcmVzb3VyY2U/IERv
ZXMgYWNjZXNzIHRvIHRoaXMgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPnJlc291cmNlIHdhcnJhbnQgcHJlc2VudGluZyBhIHN0cm9uZ2VyIGF1dGhlbnRp
Y2F0aW9uIHByb21wdD8gQXJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj50aGVyZSBvdGhlciBhdXRob3JpemF0aW9uIGNvbnNpZGVyYXRpb25zIHRoYXQg
aW5mbHVlbmNlcyB3aGV0aGVyIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+cmVxdWVzdGVkIHRva2VuIHNob3VsZCBiZSBpc3N1ZWQ/IFRob3NlIGFy
ZSBjb25zaWRlcmF0aW9ucyBhbiBBUyBuZWVkIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj50byBiZSBhYmxlIHRvIHBlcmZvcm0gaW4gdGhlIGdlbmVyYWwg
Y2FzZSwgcmVnYXJkbGVzcyBvZiB0aGUgQVQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPmZvcm1hdC4gVGhhdCBkb2VzbuKAmXQgbWVhbiB0aGV5IE1VU1Qg
YmUgZG9uZSBpbiBldmVyeSBjYXNlLCBidXQgbWFraW5nIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50aGVtIGltcG9zc2libGUgd291bGQgZGVueSBhIGxv
dCBvZiB2ZXJ5IGltcG9ydGFudCBzY2VuYXJpb3MgZm9yIHdoaWNoIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5KV1QgQVRzIChhbmQgQVRzIGluIGdlbmVy
YWwpIGFyZSB1c2VkIGZvciB0b2RheS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPlRoZSBzcGxpdCBzdHJ1Y3R1cmUgeW91IHN1Z2dlc3QgaXMgaW50ZXJlc3Rp
bmcsIGJ1dCBJIHdvdWxkIHJlY29tbWVuZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+aXMgZW5zaHJpbmVkIGluIGl0cyBvd24gc3BlYyAobWF5YmUgaW4g
dGhlIFNTSSBvcmJpdCkgcmF0aGVyIHRoYW4gaW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFuIGludGVyb3AgcHJvZmlsZSBmb3IgdGhlIGdlbmVyYWwg
QVQgY2FzZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi8m
Z3Q7T24gdGhlIGNvbnRyYXJ5LCBhIGNsaWVudCBTSEFMTCBiZSBhYmxlIHRvIGluc3BlY3QgdGhl
IGNvbnRlbnQgb2YgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPnRoZSBhY2Nlc3MgdG9rZW4gdG8gbWFrZSBzdXJlIHRoYXQgdGhlIEFTIGhhcyBub3QgaW5j
bHVkZWQgaW4gdGhlIEFUIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5zb21lIHByaXZhdGUgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhhdCBzaG91bGQgbm90IGJlIHByZXNlbnQsIGJlZm9y
ZSBmb3J3YXJkaW5nIHRoZSBBVCB0byB0aGUgUlMuIEl0IGlzIDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5wb3NzaWJsZSBmb3IgYW4gQVMgdG8gY2hhbmdl
IHRoZSBmb3JtYXQgb2YgdGhlIEFULCBidXQgdGhlIFJTIHdpbGwgbm90IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5uZWNlc3NhcmlseSBiZSBpbiBzeW5j
aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj53aXRoIHRo
ZSBSUy4vLy88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkg
Y2FuIHNlZSB0aGUgdmFsdWUgaW4gZG9pbmcgd2hhdCB3ZSBjYW4gdG8gcHJldmVudCBhYnVzZXMs
IGJ1dCBJIGZpbmQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPnRoaXMgcmVxdWlyZW1lbnQgcHJvYmxlbWF0aWMuIFRoZSBhY2Nlc3MgdG9rZW4gaXMgYW4g
YXJ0aWZhY3QgbWVhbnQgdG8gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPmVuYWJsZSB0aGUgY2xpZW50IHRvIGFjY2VzcyBhIHJlc291cmNlLiBJdHMgZm9y
bWF0IHJlbWFpbnMgYSBwcml2YXRlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5tYXR0ZXIgYmV0d2VlbiB0aGUgUlMgYW5kIHRoZSBBUywgd2hpY2ggcmV0
YWlucyB0aGUgZnJlZWRvbSB0byBjaGFuZ2UgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPml0IGFzIHRoZXkgc2VlIGZpdCB3aXRob3V0IHdvcnJ5aW5nIGFi
b3V0IGNsaWVudCBjb2RlIHRoYXQgdGFrZXMgYSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ZGVwZW5kZW5jeSBvbiBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl
IEFUIHRoYXQgbWlnaHQgdmVyeSB3ZWxsIGJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj50cmFuc2llbnQuIEFzIGZhciB0aGUgY2xpZW50IGlzIGNvbmNl
cm5lZCwgdGhlIFJTIGFuZCB0aGUgQVMgbWlnaHQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnN3aXRjaCB0aGVpciBhZ3JlZW1lbnQgZnJvbSBKV1QgQVQg
dG8gb3BhcXVlIHRva2VucyB0byBiZSB2YWxpZGF0ZWQgPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnZpYSBpbnRyb3NwZWN0aW9uIGF0IGFueSB0aW1lLCB3
aGljaCB3b3VsZCBicmVhayBhbnkgY2xpZW50IHNpZGUgbG9naWMgPG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmluc3BlY3RpbmcgdGhlIEFUIGFuZCBleHBl
Y3RpbmcgaXQgdG8gYmUgYSBKV1QuIFRoZSBjbGllbnQgaGFzIG5vIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5jb250cm9sIHdoYXRzb2V2ZXIgb24gdGhl
IGNvbnRlbnQgdGhhdCBpcyB0cmFuc21pdHRlZCB2aWEgb3BhcXVlIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50b2tlbiwgaGVuY2UgcHJpdmFjeS13aXNl
IHRoZSBmYWN0IHRoYXQgdGhlIGNvbnRlbnQgb2YgdGhlIEpXVCBpcyA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dmlzaWJsZSBpcyBtb3JlIG9mIGEgY29u
Y2VybiBhYm91dCBzdWNoIGNvbnRlbnQgYmVpbmcgYWNjZXNzaWJsZSBvbiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhlIGNsaWVudC4gT25lIGFkZGl0
aW9uYWwgcG9pbnQ6IGV2ZW4gaWYgY2xpZW50cyB3b3VsZCBiZSBhYmxlIHRvIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5zYWZlbHkgcGVlayBpbnNpZGUg
YW4gQVQgd2l0aG91dCByaXNraW5nIGJyZWFraW5nIHRoZWlyIGNvZGUsIHRoZXJl4oCZcyA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bm8gZ3VhcmFudGVl
IHRoYXQgdGhlIGNsaWVudCB3b3VsZCB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpYyBvZiB0aGUgPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmNsYWltcyBpbiB0
aGUgQVQsIGFzIHRob3NlIGFyZSBtZWFudCBmb3IgY29uc3VtcHRpb24gYnkgdGhlIFJTIHdoaWNo
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5jYW4gYXNz
aWduIGFueSBzZW1hbnRpYyB0byB0aGVtOyBub3IgdGhlIGNsaWVudCBjYW4gcmVsaWFibHkgdHJ1
c3QgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5j
b250ZW50IG9mIHRoZSBjbGFpbXMsIGdpdmVuIHRoYXQgdGhlIEFTIGNvdWxkIGFuZCBzb21ldGlt
ZXMgd2lsbCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
ZW5jcnlwdCB0aGVpciBjb250ZW50IGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChhbm90aGVy
IHJlYXNvbiBmb3IgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPndoaWNoIHRoZSBBUyBpbiB0aGUgZ2VuZXJhbCBjYXNlIG5lZWRzIHRvIGtub3cgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudCkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj4vJmd0Oy4gSXQgaXMgcG9zc2libGUgZm9yIGFuIEFTIHRvIGNoYW5nZSB0aGUgZm9y
bWF0IG9mIHRoZSBBVCwgYnV0IHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+UlMgd2lsbCBub3QgbmVjZXNzYXJpbHkgYmUgaW4gc3luY2ggd2l0aCB0
aGUgUlMuIC88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkg
ZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMgc2VudGVuY2UuIElzIHRoZSBsYXN0IFJTIG1lYW50IHRv
IGJlIEFTPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXNz
dW1pbmcgdGhhdOKAmXMgdGhlIGNhc2U6IEl0IGRvZXNu4oCZdCBsb29rIHZlcnkgbGlrZWx5IHRo
YXQgYW4gUlMgd291bGQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPnNpbXBseSBhY2NlcHQgdG9rZW5zIGZyb20gYW4gQVMgd2l0aG91dCBzb21lIG91dCBv
ZiBiYW5kIG5lZ290aWF0aW9uLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+bm9yIGl0IHNlZW1zIHZlcnkgbGlrZWx5IHRoYXQgYW4gQVMgd291bGQgaXNz
dWUgdG9rZW5zIGZvciByZXNvdXJjZXMgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPml0IGRvZXNu4oCZdCBrbm93LSBzZWUgYWJvdmUuIFN1Y2ggc2NlbmFy
aW9zIG1pZ2h0IGV4aXN0LCBidXQgdGhleSBkb27igJl0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5zZWVtIHRvIG1vZGVsIGNvbW1vbiBidXNpbmVzcyBz
b2x1dGlvbnMgb3IgdGhlIHR5cGljYWwgZGVwbG95bWVudCwgPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPndoZXJlIGFuIEFQSSB3aWxsIGJlIHByb3RlY3Rl
ZCBieSBtaWRkbGV3YXJlL2dhdGV3YXkgd2l0aCBwcmVjaXNlIDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hc3N1bXB0aW9ucyBvbiBob3cgdG8gdmFsaWRh
dGUgaW5jb21pbmcgdG9rZW5zLiBUaGVyZSBtaWdodCBiZSBjaGFuZ2VzIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50aGF0IGFyZSBpbmNvbnNlcXVlbnRp
YWwgKG9yZGVyIG9mIGNsYWltcywgYWRkaXRpb25hbCBjbGFpbXMpIGJ1dCA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YW55dGhpbmcgbW9yZSBzdWJzdGFu
dGl2ZSB3b3VsZCBsaWtlbHkgc2ltcGx5IGJyZWFrIHRoZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi8mZ3Q7IFRoaXMgbWVhbnMgdGhhdCBh
biBpZGVudGlmaWVyIG9mIHRoZSBwcm9maWxlIG9mIHRoZSBBVCBzaG91bGQgYmUgPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFibGUgdG8gYmUgaW5jbHVk
ZWQgaW50byB0aGUgQVQuIFRoaXMgYWxsb3dzIGZvciBmdXR1cmUgZXh0ZW5zaW9ucy4vLy88bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNhbiB5b3UgZXhwYW5k
IG9uIHRoZSBleGFjdCBzY2VuYXJpbyB5b3UgYXJlIHRoaW5raW5nIG9mIHRoYXQgY2FsbHMgPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmZvciBhIHZlcnNp
b24/IElmIGl04oCZcyBhIG1hdHRlciBvZiBleHRlbnNpb25zLCB0aG9zZSBzaG91bGQgYWx3YXlz
IGJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5wb3Nz
aWJsZSDigJMgaXTigJlzIG1vcmUgYnJlYWtpbmcgY2hhbmdlcyB0aGF0IHJlcXVpcmUgdmVyc2lv
bmluZywgYnV0IEkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPmRvbuKAmXQgcmVjYWxsIHByZWNlZGVudHMgaW4gc2ltaWxhciBzcGVjcy48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHRoaXMgaXMgYWltZWQgYXQg
bWl0aWdhdGluZyB0aGUg4oCcQVMgY2hhbmdlcyBmb3JtYXQgd2l0aG91dCB0ZWxsaW5nIDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SU+KAnSwgSSBkb27i
gJl0IHRoaW5rIHRoYXQgd291bGQgd29yayDigJMgYmVzaWRlcyBvZiBiZWluZyB1bm5lY2Vzc2Fy
eSBwZXIgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRo
ZSBhYm92ZSBjb25zaWRlcmF0aW9ucywgdGhpcyB3b3VsZG7igJl0IHByb3RlY3QgdGhlIFJTIGZy
b20gY2hhbmdlcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+d2VsbCB3aXRoaW4gdGhlIGN1cnJlbnQgc3BlYyAod2hpY2ggYWxsb3dzIGFkZGluZyBhcmJp
dHJhcnkgY2xhaW1zIGFzIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5sb25nIGFzIGl04oCZcyBkb25lIGFjY29yZGluZyB0byBKV1QgcnVsZXMpLCBmcm9t
IGNoYW5nZXMgd2l0aGluIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+Y2xhaW0gY29udGVudCAoZWcgcHJpdmF0ZSBzdHJpbmcgZm9ybWF0cykgYW5k
IGZyb20gY29tcGxldGUgZGVwYXJ0dXJlcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+ZnJvbSB0aGUgdXNlIG9mIEpXVCBmb3IgQVRzLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LyZndDsvL0FsbG93aW5nIGEgY2xp
ZW50IHRvIG9ubHkgc3BlY2lmeSBhIHNjb3BlIGFuZCBhIHJlc291cmNlIGlzIHZlcnkgPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnJlc3RyaWN0aXZlLi88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNwZWNpZnlpbmcg
c2NvcGUgb3IgdXNpbmcgcmVzb3VyY2UgaW5kaWNhdG9ycyBhcmUgYWxsIHRoZSBtZWNoYW5pc21z
IEkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFtIGF3
YXJlIG9mIHRoYXQgT0F1dGgyIG9mZmVycyBmb3Igc3BlY2lmeWluZyB3aGF0IGFuIGFjY2VzcyB0
b2tlbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+c2hv
dWxkIGJlIGZvci0gYXQgbGVhc3QgYXQgdGhlIHRpbWUgaW4gd2hpY2ggdGhlIHNwZWMgd2FzIGlu
Y2VwdGVkLiBJbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+ZmFjdCwgcmVzb3VyY2UgaW5kaWNhdG9ycyB3YXMgbm90IGV2ZW4gUkZDIGFuZCBpbiBtYXJr
ZXQgdmVuZG9ycyB1c2VkIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5wcm9wcmlldGFyeSBmdW5jdGlvbmFsIGVxdWl2YWxlbnRzLiBXaGF0IG90aGVyIGlu
dGVyb3BlcmFibGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPm1lY2hhbmlzbXMgd291bGQgeW91IG9mZmVyIGluIGFkZGl0aW9uIHRvIHRoZSBvbmVzIGxp
c3RlZCBoZXJlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
KkZyb206ICpPQXV0aCA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+Jmx0
O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9hPiBvbiBiZWhhbGYgb2YgRGVuaXMgPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0
bzpkZW5pcy5pZXRmQGZyZWUuZnIiPiZsdDtkZW5pcy5pZXRmQGZyZWUuZnImZ3Q7PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qRGF0ZTogKlRodXJz
ZGF5LCBBcHJpbCA5LCAyMDIwIGF0IDA5OjI2PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPipUbzogKm9hdXRoIDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KlN1YmplY3Q6ICpSZTogW09BVVRILVdHXSBXR0xDIG9u
ICZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PQXV0aCAyLjAgQWNjZXNzIFRva2VucyZx
dW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBoYXZl
IHRocmVlIGNvbmNlcm5zLCB0d28gb2YgdGhlbSBiZWluZyByZWxhdGVkIHRvIHByaXZhY3kuPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4xKSBQcml2YWN5IGhh
cyBub3QgcmVhbGx5IGJlZW4gYSBjb25jZXJuIGluIHRoZSBXRyBzaW5jZSBvcmlnaW5hbGx5IDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50aGUgQVQgYW5k
IHRoZSBSUyB3ZXJlIGNvLWxvY2F0ZWQuIEhvd2V2ZXIsIHRoaXMgZHJhZnQgbm93IHJlY29nbml6
ZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhhdCB0
aGVyZSBtYXkgZXhpc3QgY2FzZXMgd2hlcmUgJnF1b3Q7dGhlIGF1dGhvcml6YXRpb24gc2VydmVy
IGFuZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cmVz
b3VyY2Ugc2VydmVyIGFyZSBub3QgY28tbG9jYXRlZCwgYXJlIG5vdCByYW4gYnkgdGhlIHNhbWUg
ZW50aXR5LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5v
ciBhcmUgb3RoZXJ3aXNlIHNlcGFyYXRlZCBieSBzb21lIGJvdW5kYXJ5JnF1b3Q7LjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KkluIHN1Y2ggY2FzZXMqLCBp
dCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBtYWtlIHN1cmUgdGhhdCBhbiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YXV0aG9yaXphdGlvbiBzZXJ2
ZXIgd2lsbCBOT1QgYmUgYWJsZSB0byBrbm93IHdoZXJlIHRoZSBhdXRob3JpemF0aW9uczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj50b2tlbnMgdGhhdCBp
dCBpc3N1ZXMgd2lsbCBiZSB1c2VkLiBVc2luZyBhbm90aGVyIHdvcmRpbmcsIGFuIEFTIFNIQUxM
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5OT1QgYmUg
YWJsZSB0byBrbm93IHdoZXJlIGFuIEFUIHJlcXVlc3RlZCBieSBhIGdpdmVuIGNsaWVudCB3aWxs
IGJlIHVzZWQ6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PipBdXRob3JpemF0aW9uIHNlcnZlcnMgU0hBTEwgbm90IGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8g
YWN0IGFzICZxdW90O0JpZyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+QnJvdGhlciZxdW90OyogYW5kIHRodXMgU0hBTEwgbm90IGJlIGFibGUgdG8ga25v
dyB3aGljaCByZXNvdXJjZXMgYXJlIGdvaW5nPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPnRvIGJlIGFjY2Vzc2VkIGJ5IGNsaWVudHMuPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIG1lYW5zIHRoYXQsIGluIHN1
Y2ggY2FzZXMsIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIFNIQUxMIG5vdCBiZSA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YWJsZSB0byBrbm93IGZvciB3
aGljaCByZXNvdXJjZSBzZXJ2ZXIgYW4gQVQgaGFzIGJlZW4gdGFyZ2V0ZWQuPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JdCBpcyBhIGZhY3QgdGhhdCBtb3N0
IHNvbHV0aW9ucyBjdXJyZW50bHkgZGVwbG95ZWQgc3VwcG9ydCBhIGJ1aWx0LWluIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qJnF1b3Q7U3B5IGJ5IGRl
c2lnbiZxdW90OyogYXJjaGl0ZWN0dXJlIGluc3RlYWQgb2YgYSAqJnF1b3Q7UHJpdmFjeSBieSBk
ZXNpZ24mcXVvdDsqIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj5hcmNoaXRlY3R1cmUuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5Ib3dldmVyLCBmb3Igc2VjdXJpdHkgcmVhc29ucyBhbiBBVCBzdGlsbCBuZWVkcyB0
byBiZSB0YXJnZXRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPlRoZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCBpcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICogZm9yIHNlY3VyaXR5
IHJlYXNvbnMsIHRoZSBBVCBtdXN0IGJlIHRhcmdldGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgKiBmb3IgcHJpdmFjeSByZWFzb25zLCB0
aGUgQVMgbXVzdCBiZSBrZXB0IGlnbm9yYW50IG9mIHRoZSBuYW1lIG9mPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg
dGFyZ2V0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T25l
IHdheSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBpcyB0byBjb25zaWRlciB0aGF0IHRoZSBBVCBpcyBj
b21wb3NlZCBvZiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+YSBzZXF1ZW5jZSBvZiB0d28gc3RydWN0dXJlczogYSBzaWduZWQgc3RydWN0dXJlIGFuZCBh
biB1bnNpZ25lZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+c3RydWN0dXJlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+VGhlIHNpZ25lZCBzdHJ1Y3R1cmUgY29udGFpbnMgYSAmcXVvdDtzYWx0ZWQgYXVkIGNsYWlt
JnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5U
aGUgdW5zaWduZWQgc3RydWN0dXJlIGNvbnRhaW5zIGEgJnF1b3Q7YXVkIHNhbHQgY2xhaW0mcXVv
dDsuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbiBwcmFj
dGljZSwgdGhlICZxdW90O3NhbHRlZCBhdWQgY2xhaW0mcXVvdDsgd2lsbCBiZSBjb21wb3NlZCBv
ZiBib3RoIGEgb25lIHdheSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+aGFzaCBmdW5jdGlvbiBhbGdvcml0aG0gaWRlbnRpZmllciBhbmQgYSBoYXNoIHZh
bHVlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmVmb3Jl
IHJlcXVlc3RpbmcgYW4gQVQgdG8gYW4gQVMsIHRoZSBjbGllbnQgY2hvb3NlcyBhIHJlc291cmNl
IHNlcnZlciA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
YW5kIHNlbGVjdCBhIHJlc291cmNlIGluZGljYXRvciB2YWx1ZSBjb3JyZXNwb25kaW5nIHRvIHRo
ZSBpZGVudGlmaWVyIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj50aGUgcmVzb3VyY2Ugc2VydmVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj5JdCB0aGVuIGNob29zZXMgYSByYW5kb20gdmFsdWUgd2hpY2ggaXQg
dXNlcyBhcyBhICZxdW90O2F1ZCBzYWx0IGNsYWltJnF1b3Q7IGFuZCA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhlbiBjb21wdXRlcyBhIGhhc2ggdmFs
dWUgYnkgdXNpbmcgYSBvbmUtd2F5IGhhc2ggZnVuY3Rpb24gd2hpY2ggPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmNvbWJpbmVzPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPm9uZSBvZiB0aGUgcmVzb3VyY2UgaW5k
aWNhdG9ycyBvZiB0aGUgUlMgd2l0aCB0aGUgJnF1b3Q7YXVkIHNhbHQgY2xhaW0mcXVvdDsuIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Cb3RoIHRoZSBv
bmUgd2F5IGhhc2ggZnVuY3Rpb24gYWxnb3JpdGhtIGlkZW50aWZpZXIgYW5kIHRoZSBjb21wdXRl
ZCZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
aGFzaCB2YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij5hcmUgdGhlbiBpbmNsdWRlZCBpbnRvIHRoZSAmcXVvdDtzYWx0ZWQgYXVkIGNsYWltJnF1b3Q7
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIEFUIHJl
cXVlc3QgdGhlbiBjb250YWlucyBhICZxdW90O3NhbHRlZCBhdWQgY2xhaW0mcXVvdDsgaW5zdGVh
ZCBvZiBhbiZxdW90O2F1ZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+Y2xhaW0mcXVvdDsuIFRoZSBBVCBibGluZGx5IGNvcGllcyB0aGlzIHZhbHVlIGlu
dG8gdGhlIEFUIHdoaWNoIGlzIHRoZW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPmlkZW50aWZpZWQgYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YSAmcXVvdDtzYWx0ZWQgYXVkIGNsYWltJnF1b3Q7IGluc3Rl
YWQgb2YgYW4gJnF1b3Q7YXVkIGNsYWltJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hlbiB0aGUgQVQgaXMgcmVjZWl2ZWQgYnkgdGhlIGNsaWVu
dCwgaXQgYWRkcyB0byB0aGUgQVQgdGhlIHVuc2lnbmVkIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5wYXJ0IHRvIHRoZSBBVCB3aGljaCBjb250YWlucyB0
aGUgJnF1b3Q7YXVkIHNhbHQgY2xhaW0mcXVvdDsgYW5kIHNlbmRzIGJvdGggdGhlIDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5zaWduZWQ8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YW5kIHRoZSB1bnNpZ25lZCBw
YXJ0IG9mIHRoZSBBVCB0byB0aGUgUlMuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5XaGVuIHRoZSBSUyByZWNlaXZlcyB0aGUgQVQsIHVzaW5nIHRoZSBvbmUg
d2F5IGhhc2ggZnVuY3Rpb24gYWxnb3JpdGhtIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj5pZGVudGlmaWVyIGNvbnRhaW5lZCBpbiB0aGUgJnF1b3Q7c2Fs
dGVkIGF1ZCBjbGFpbSZxdW90OywgaXQgY29tYmluZXMgZWFjaCBvZiA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aXRzIHJlc291cmNlIGluZGljYXRvcnM8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+d2l0aCB0aGUg
JnF1b3Q7YXVkIHNhbHQgY2xhaW0mcXVvdDsgY29udGFpbmVkIGluIHRoZSB1bnNpZ25lZCBwYXJ0
IG9mIHRoZSBBVCBhbmQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPnZlcmlmaWVzIHdoZXRoZXIgaXQgbWF0Y2hlcyB3aXRoIHRoZSBoYXNoIHZhbHVlIGNv
bnRhaW5lZCBpbiB0aGUgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPiZxdW90O3NhbHRlZCBhdWQgY2xhaW0mcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklmIG5vbmUgb2YgdGhlc2UgcmVzb3VyY2UgaW5k
aWNhdG9ycyBpcyBwcm92aWRpbmcgYSBtYXRjaCwgdGhlbiB0aGUgUlMgPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNIQUxMIHJlamVjdGVkIHRoZSBBVC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBpbXBsaWNh
dGlvbiBpcyB0byBhbGxvdyBhbiBBVCB0byBjb250YWluIGJvdGggYSBzaWduZWQgcGFydCBhbmQg
YW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnVuc2ln
bmVkIHBhcnQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J
biBhZGRpdGlvbiwgdGhlICZxdW90O2F1ZCBjbGFpbSZxdW90OyBzaG91bGQgYmUgbXVsdGktdmFs
dWVkIHdoZXJlLCBhcyBhIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj5jb25zZXF1ZW5jZSwgYm90aCB0aGUgJnF1b3Q7c2FsdGVkIGF1ZCBjbGFpbSZxdW90
OyB3aXRoIHRoZSAmcXVvdDthdWQgc2FsdCBjbGFpbSZxdW90OyA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+d291bGQgYWxzbyBiZSBtdWx0aS12YWx1ZWQu
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MikgV2l0aGluIGNs
YXVzZSA2LCAmcXVvdDtQcml2YWN5IENvbnNpZGVyYXRpb25zJnF1b3Q7LCB0aGUgdGV4dCBzdGF0
ZXM6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm
bmJzcDsgQXMgSldUIGFjY2VzcyB0b2tlbnMgY2FycnkgaW5mb3JtYXRpb24gYnkgdmFsdWUsIGl0
IG5vdyBiZWNvbWVzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPiZuYnNwOyZuYnNwOyBwb3NzaWJsZSBmb3IgcmVxdWVzdG9ycyBhbmQgcmVjZWl2ZXJzIHRv
IGRpcmVjdGx5IHBlZWsgaW5zaWRlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgdG9rZW4gY2xhaW1zIGNvbGxlY3Rpb24uJm5i
c3A7IFRoZSBjbGllbnQgTVVTVCBOT1QgaW5zcGVjdCB0aGUgY29udGVudCBvZjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgdGhlIGFj
Y2VzcyB0b2tlbjogdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUgcmVzb3VyY2Ugc2Vy
dmVyPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw
OyZuYnNwOyBtaWdodCBkZWNpZGUgdG8gY2hhbmdlIHRva2VuIGZvcm1hdCBhdCBhbnkgdGltZSAo
Li4uKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIHRo
ZSBjb250cmFyeSwgYSBjbGllbnQgU0hBTEwgYmUgYWJsZSB0byBpbnNwZWN0IHRoZSBjb250ZW50
IG9mIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
YWNjZXNzIHRva2VuIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBBUyBoYXMgbm90IGluY2x1ZGVkIGlu
IHRoZSBBVCBzb21lIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj5wcml2YXRlIGluZm9ybWF0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPnRoYXQgc2hvdWxkIG5vdCBiZSBwcmVzZW50LCBiZWZvcmUgZm9yd2Fy
ZGluZyB0aGUgQVQgdG8gdGhlIFJTLiBJdCBpcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cG9zc2libGUgZm9yIGFuIEFTIHRvIGNoYW5nZSB0aGUgZm9y
bWF0IG9mIHRoZSBBVCwgYnV0IHRoZSBSUyB3aWxsIG5vdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bmVjZXNzYXJpbHkgYmUgaW4gc3luY2g8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+d2l0aCB0aGUgUlMuPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TaW5jZSB0aGVyZSBh
cmUgbm93IGNhc2VzIHdoZXJlICZxdW90O3RoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVz
b3VyY2UgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnNl
cnZlciBhcmUgbm90IGNvLWxvY2F0ZWQsIGFyZSBub3QgcmFuIGJ5IHRoZSBzYW1lIGVudGl0eSwg
b3IgYXJlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5v
dGhlcndpc2Ugc2VwYXJhdGVkPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPmJ5IHNvbWUgYm91bmRhcnkmcXVvdDssIGEga2V5IHBvaW50IGlzIHRoYXQgYW4g
QVMgYW5kIGEgUlMgRE8gTk9UIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj5uZWNlc3NhcmlseSBuZWVkIHRvIGtub3cgZWFjaCBvdGhlci4gVGhlIFJTIG9u
bHkgbmVlZHMgdG8gdHJ1c3QgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj5BUy4gKGZ1bGwgc3RvcCk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMgbWVhbnMgdGhhdCBhbiBpZGVudGlmaWVyIG9mIHRoZSBw
cm9maWxlIG9mIHRoZSBBVCBzaG91bGQgYmUgYWJsZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dG8gYmUgaW5jbHVkZWQgaW50byB0aGUgQVQuIFRoaXMg
YWxsb3dzIGZvciBmdXR1cmUgZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPkluIGFueSBjYXNlLCB0aGUgJnF1b3Q7TVVTVCBOT1QmcXVvdDsg
aW4gdGhlIHF1b3RlZCBzZW50ZW5jZSBzaG91bGQgYmUgcmVtb3ZlZCA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+b3IgY2hhbmdlZCBvciB0aGUgd2hvbGUg
c2VudGVuY2Ugc2hvdWxkIGJlIHJlbW92ZWQuLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjMpIFdpdGhpbiBjbGF1c2UgMi4yLjIgKHNlY29uZCBwYXJhZ3JhcGgp
OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i
c3A7IFRoaXMgcHJvZmlsZSBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG1lY2hhbmlzbSBmb3IgYSBj
bGllbnQgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
Jm5ic3A7Jm5ic3A7IGRpcmVjdGx5IHJlcXVlc3QgdGhlIHByZXNlbmNlIG9mIHNwZWNpZmljIGNs
YWltcyBpbiBKV1QgYWNjZXNzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyB0b2tlbnMsIGFzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl
ciBjYW4gZGV0ZXJtaW5lIHdoYXQgYWRkaXRpb25hbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgY2xhaW1zIGFyZSByZXF1aXJlZCBi
eSBhIHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyIGJ5IHRha2luZyBpbjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgY29uc2lkZXJh
dGlvbiB0aGUgY2xpZW50X2lkIG9mIHRoZSBjbGllbnQsIHRoZSBzY29wZSBhbmQgdGhlIHJlc291
cmNlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw
OyZuYnNwOyBwYXJhbWV0ZXJzIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWxsb3dpbmcgYSBjbGllbnQgdG8gb25s
eSBzcGVjaWZ5IGEgc2NvcGUgYW5kIGEgcmVzb3VyY2UgaXMgdmVyeSA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cmVzdHJpY3RpdmUuPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XaGF0IHdvdWxkIGJlIHRoZSB0aXRs
ZSBvZiBhbiBSRkMgdGhhdCB3b3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yZXF1ZXN0IHRoZSBwcmVzZW5jZSBv
ZiBzcGVjaWZpYyBjbGFpbXMgaW4gSldUIGFjY2VzcyA/PG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JZiBzdWNoIGEgcmVzdHJpY3Rpb24gaXMga2VwdCwgd291
bGQgdGhlIGN1cnJlbnQgdGl0bGUgb2YgdGhpcyBSRkMgPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnN0aWxsIGJlIGluYXBwcm9wcmlhdGU8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+JnF1b3Q7SlNPTiBXZWIgVG9r
ZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDsgPzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RGVuaXM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRQIFNlY3VyaXR5IENvbnN1bHRp
bmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_ECADC22B22BE4656B925F2E84C86DADFamazoncom_--


From nobody Mon Apr 13 13:14:10 2020
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 B47D03A1D71 for ; Mon, 13 Apr 2020 13:14:08 -0700 (PDT)
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 WNSbV2WRMnw7 for ; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
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 9E0733A1D6F for ; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id w20so10784921iob.2 for ; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lpu37cRON/21RPGWIWYg3TV1QhqPL3HCtSzDvy8d93g=; b=ltdw9S3NjfG4jxOpVk7oeh6LhqIBalsxwEpLDgR0plICzY6dytzc6gjIQChnN85nBI eynzUYKJFp5CFADXxQHi4rfSM7GnreWcmY2C5Bu8iEMuP0vJiuDZHAvuTOgNfP91d99A Sh85LVTA0MNSkGVF/HpoQQEX8k6zV1HhUrlWPO2gwhJlJ0ZQf8UFHr0/eGe4Nk/ilP1U zRwPVknI4XFRt7HqS0G9yHaLA/3F/k4nOgQsHd48vveX5UtMGQoMC9KaFTaSnFK/MEo+ Cr1uAwESxR8sE2jy6EAHy17v7tqL314stK5XXSj459Xk8FcnAx9rN9V5H7K8ApDj0D2d F2Cg==
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=lpu37cRON/21RPGWIWYg3TV1QhqPL3HCtSzDvy8d93g=; b=Zi0lN30tCYY4Lz2RnA5ZlQ3ID9kpo/cvpNirZZXGU0mxQ9c0K01qb62wNxSUxetbbI DaqUh5GRtc4SAQApStWK1IdZjqwJ9Ue4vhgKPpG6DuEw1uat7BpNpsNyApb4f0lFEILT AFK/mQZBCGzGEvTa1CvNSBZFh7lGDbHKDVY3uCL1lPGfr4j7KTTcN0WjnnXfosJEiU38 2m8wpZsA+6LB7/twsx42AkPGKGRIUoKUJhDbnPEdRlft5rcpisNx2t0vDKr7dt3TCbde 4076ZbqMGdgPMR75f0c6rxnCOyupQvkJr6CnnVCsM1kAF9YygdRaSb2AiLtF6pfXx2oG drJA==
X-Gm-Message-State: AGi0PuZEMKbrpI5jNE0skps5SWaf48jTTswacs+yamldE8rtokoRVqD/ YfaT6Xyz6rS+wI4cPR90BcMdQ9PdiNCkRBwOuFf6Aw==
X-Google-Smtp-Source: APiQypK3YqYOgnadESK3BGjx/dOqA64NDUt4eavLMypqmbDFBWNQNgD2QPujl/ISGiVuYzHvdunU1gh5B+kJe0/SaHA=
X-Received: by 2002:a6b:4109:: with SMTP id n9mr17770848ioa.141.1586808845442;  Mon, 13 Apr 2020 13:14:05 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>  
In-Reply-To: 
From: Vittorio Bertocci 
Date: Mon, 13 Apr 2020 13:13:54 -0700
Message-ID: 
To: Aaron Parecki 
Cc: Dick Hardt , oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008f365c05a331b92c"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 20:14:09 -0000

--0000000000008f365c05a331b92c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It=E2=80=99s certainly possible to conceive ATs without subs, but I think t=
he
profile would be way less useful for SDK developers.
On the objections:
The sub doesn=E2=80=99t have to be a user, if you look at the earlier discu=
ssions
the case in which the token has been issued for an application via client
creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able to collide
and track users, given that the sub can be a PPID that is different for
every resource even if the authenticated subject was the same.

The sub is mandatory here because it was present in nearly every token
among the ones observed, and although one should not overindex on those
scenarios, I took that as strong indication that it is a frequently used
field and guaranteeing its presence facilitates embedding in SDKs lots of
downstream features, such as correlating with locally stored attributes,
which would otherwise left as exercise to the reader. Per the points above,
there are no obvious downsides in requiring the presence of the sub and
significant upsides. Again, the AS is in full control of the sub content
hence none of the privacy concerns mentioned here are mandated by the sheer
presence of the sub claim. If you feel the privacy section should be
stronger in warning an AS against the possibility of collusion if global
ide rockers are used, I am happy to reword accordingly

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki  wrote:

> This is a good point, I often use the hotel key analogy as well. The room
> door is the RS, the key is the access token, the door does not need to kn=
ow
> who the user is in order to know if it=E2=80=99s okay to unlock given a p=
articular
> key.
>
> If sub is required, then this profile is limited in use to cases where
> user identifiers are part of the system, and there will be situations in
> which it=E2=80=99s not appropriate to use this profile for access tokens.=
 If that=E2=80=99s
> okay, this should be clarified in the overview section to describe when
> this profile should be used.
>
> Aaron
>
>
>
> On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt  wrote:
>
>> Why does the "sub" need to be required?
>>
>> An access token is to prove authorization. The RS may not need "sub" to
>> constrain fulfilling the client request.
>>
>> For example, it the access token has the same properties as a movie
>> ticket, the RS does not need to have any identifier for who purchased th=
e
>> movie ticket.
>>
>> The privacy implication is the RS can correlate across API calls to know
>> it is the same subject.
>>
>>
>>
>>
>> On Mon, Apr 13, 2020 at 8:16 AM Denis > > wrote:
>>
>>> Hello,
>>>
>>> More on privacy about "JWT Profile for Access Tokens".
>>>
>>> The current document REQUIRES the claim names *sub* and *client_id*.
>>>
>>>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>>>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>>>
>>> *1) **sub  REQUIRED*
>>>
>>> RFC 7519 states:
>>>
>>> 4.1.2.  "sub" (Subject) Claim
>>>    The "sub" (subject) claim identifies the principal that is the
>>>    subject of the JWT.  The claims in a JWT are normally statements
>>>    about the subject.  The subject value MUST either be scoped to
>>>    *be locally unique in the context of the issuer or be globally
>>> unique*.
>>>    The processing of this claim is generally application specific.  The
>>>    "sub" value is a case-sensitive string containing a StringOrURI
>>>    value.  *Use of this claim is OPTIONAL.*
>>>
>>> If *sub *is *REQUIRED *for this profile, then this allows all resource
>>> servers to link accesses made by the same client on different servers.
>>>
>>> *2) client_id  REQUIRED*
>>>
>>> RFC 8693 states:
>>>
>>> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
>>> The client_id claim carries the client identi=EF=AC=81er of the OAuth 2=
.0 [RFC
>>> 6749] client that requested the token.
>>>
>>> RFC 6749 states:
>>>
>>> 2.2.  Client Identifier
>>>    The authorization server issues the registered client a client
>>>    identifier -- a unique string representing the registration
>>>    information provided by the client.  The client identifier is not a
>>>    secret; it is exposed to the resource owner and MUST NOT be used
>>>    alone for client authentication.  *The client identifier is unique
>>> to*
>>> *   the authorization server.*
>>>
>>> If *client_id* is REQUIRED for this profile, this also allows all
>>> resource servers to link accesses made by the same client on different
>>> servers.
>>>
>>> *Both claim names should be OPTIONAL *to allow to support the privacy
>>> principle of unlinkability.
>>>
>>> Would both names remain *REQUIRED*, the Privacy considerations section
>>> should mention that such a linkage by different resource servers
>>> will always be possible when using this profile.
>>>
>>> Denis
>>>
>>> I have uploaded the second presentation for today's session, the JWT
>>> Profile for Access Tokens.
>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oaut=
h
>>>
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> --
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000008f365c05a331b92c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It=E2=80=99s certainly possible to conceive ATs with=
out subs, but I think the profile would be way less useful for SDK develope=
rs.
On the objections:
The su=
b doesn=E2=80=99t have to be a user, if you look at the earlier discussions=
 the case in which the token has been issued for an application via client =
creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able to col=
lide and track users, given that the sub can be a PPID that is different fo=
r every resource even if the authenticated subject was the same.

The sub is mandatory here because =
it was present in nearly every token among the ones observed, and although =
one should not overindex on those scenarios, I took that as strong indicati=
on that it is a frequently used field and guaranteeing its presence facilit=
ates embedding in SDKs lots of downstream features, such as correlating wit=
h locally stored attributes, which would otherwise left as exercise to the =
reader. Per the points above, there are no obvious downsides in requiring t=
he presence of the sub and significant upsides. Again, the AS is in full co=
ntrol of the sub content hence none of the privacy concerns mentioned here =
are mandated by the sheer presence of the sub claim. If you feel the privac=
y section should be stronger in warning an AS against the possibility of co=
llusion if global ide rockers are used, I am happy to reword accordingly=C2=
=A0

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <aaron@parecki.com> wrote:
This is a good point, I often use th=
e hotel key analogy as well. The room door is the RS, the key is the access=
 token, the door does not need to know who the user is in order to know if =
it=E2=80=99s okay to unlock given a particular key.

If sub is required, then this profile is =
limited in use to cases where user identifiers are part of the system, and =
there will be situations in which it=E2=80=99s not appropriate to use this =
profile for access tokens. If that=E2=80=99s okay, this should be clarified=
 in the overview section to describe when this profile should be used.

Aaron



=

On Mon, Apr 13, 2020 at 10:08 AM Dick=
 Hardt <dick.h=
ardt@gmail.com> wrote:
Why does the "sub" need to be required?

An access token is to prove authorization. The RS may not need "=
sub" to constrain fulfilling=C2=A0the client request.=C2=A0
=

For example, it the=C2=A0access token has the same propertie=
s as a movie ticket, the RS does not need to have any identifier for who pu=
rchased the movie ticket.=C2=A0

The privacy implic=
ation is the RS can correlate across API calls to know it is the same subje=
ct.=C2=A0




On Mon, Apr 13,=
 2020 at 8:16 AM Denis <denis..ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=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


-- 
----
Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000008f365c05a331b92c--


From nobody Mon Apr 13 13:40:33 2020
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 C3B923A1DD4 for ; Mon, 13 Apr 2020 13:40:31 -0700 (PDT)
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 U4MOMuL646H8 for ; Mon, 13 Apr 2020 13:40:29 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 E6AA53A1DD2 for ; Mon, 13 Apr 2020 13:40:28 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id z12so9844503ilb.10 for ; Mon, 13 Apr 2020 13:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lg3Yh6hHAzBea7gWxiO2UbT9yGR/WkqUdMzsXuk8CWA=; b=rKLn8xCpg+WcfLTIP+MvbojUM9yQNB01KeuwygjbYTSSj/URsDXxn9sDYy+CNBE30y YFkApagXPNTxrZTETUzB0zxP4PLw0V+oyIVr2NBCvpzEccYZOitsLxb1Fo41baVsIe0/ TZgYQi7MeveBh/9cLEj4ZZ7QxtqYZ222CGzekK4NyzKFWNAf91l0thjCKgDaYqop5153 7yyc01STpEciwmEROrcaHKb1ZcviFxWfUtYOd57d5V4V7AXTmEifOvc/QFCawWT/Yj0p zYGlBOowckHjyXu+qSuYmJ2rE9r/6sIbaOX/aGMKHmxOH/Ge9sgg4XBdoU60/s8zKXsv v5lg==
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=Lg3Yh6hHAzBea7gWxiO2UbT9yGR/WkqUdMzsXuk8CWA=; b=ekYTkZVkSA3VDJN3gnEyzlrnAv5eUvCavhTKhKrGYkU1r7W8xm3j12sPuNptTfVBXp /3iooaY9FVh5m5GcM2opRTVYan1cIqstI+qOq9YSZAHW9RPrN9hGUH6EcmYbS9xpp8jD Q7DVIEUSiKfUeaKb6/qUzoWClVcgyyTz+/6LCxuOvIMDE8rfb+eGjsycpRegVHtNBhZ2 I/NUXOt4atECvSAJColAxSl61btLUQxNokhGumVMMK2LWkGKjK1NTUc9Lh7+CzfxVR7l chVxahdQis8M4cXYm/HNUF5Qac25PYInMpbJIBWVw+RcLhnwjgfhtRin1qhz6TZhmuA1 PVrg==
X-Gm-Message-State: AGi0PuabZuNEWJg0dk1yD2as/AEuuCh5wAI7ionxxxmBtaOsAI6v5Ylu q0uNcmO4w41lxDGfWVbcC+6mL7dPxWbF2c003pWenw==
X-Google-Smtp-Source: APiQypLE99UzM/nC1XS+SGwCtn0WUBOxsCnXd1GjOruj8BBCIj8D50yZl9/x3/LNzSjXc2rIcjvzy+df4vOlAawRnCo=
X-Received: by 2002:a92:901:: with SMTP id y1mr10119448ilg.260.1586810427995;  Mon, 13 Apr 2020 13:40:27 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>   
In-Reply-To: 
From: Vittorio Bertocci 
Date: Mon, 13 Apr 2020 13:40:17 -0700
Message-ID: 
To: Aaron Parecki 
Cc: Dick Hardt , oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e30e5e05a3321707"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Mon, 13 Apr 2020 20:40:32 -0000

--000000000000e30e5e05a3321707
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=E2=80=9CIde rockers=E2=80=9D is iPhone autocorrect jargon for =E2=80=9Cide=
ntifiers=E2=80=9D, of course :P

On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci  wrote:

> It=E2=80=99s certainly possible to conceive ATs without subs, but I think=
 the
> profile would be way less useful for SDK developers.
> On the objections:
> The sub doesn=E2=80=99t have to be a user, if you look at the earlier dis=
cussions
> the case in which the token has been issued for an application via client
> creds (hence non user) has been debated at length.
> Knowing the subject does not necessarily lead to API being able to collid=
e
> and track users, given that the sub can be a PPID that is different for
> every resource even if the authenticated subject was the same.
>
> The sub is mandatory here because it was present in nearly every token
> among the ones observed, and although one should not overindex on those
> scenarios, I took that as strong indication that it is a frequently used
> field and guaranteeing its presence facilitates embedding in SDKs lots of
> downstream features, such as correlating with locally stored attributes,
> which would otherwise left as exercise to the reader. Per the points abov=
e,
> there are no obvious downsides in requiring the presence of the sub and
> significant upsides. Again, the AS is in full control of the sub content
> hence none of the privacy concerns mentioned here are mandated by the she=
er
> presence of the sub claim. If you feel the privacy section should be
> stronger in warning an AS against the possibility of collusion if global
> ide rockers are used, I am happy to reword accordingly
>
> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki  wrote:
>
>> This is a good point, I often use the hotel key analogy as well. The roo=
m
>> door is the RS, the key is the access token, the door does not need to k=
now
>> who the user is in order to know if it=E2=80=99s okay to unlock given a =
particular
>> key.
>>
>> If sub is required, then this profile is limited in use to cases where
>> user identifiers are part of the system, and there will be situations in
>> which it=E2=80=99s not appropriate to use this profile for access tokens=
. If that=E2=80=99s
>> okay, this should be clarified in the overview section to describe when
>> this profile should be used.
>>
>> Aaron
>>
>>
>>
>> On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt  wrote=
:
>>
>>> Why does the "sub" need to be required?
>>>
>>> An access token is to prove authorization. The RS may not need "sub" to
>>> constrain fulfilling the client request.
>>>
>>> For example, it the access token has the same properties as a movie
>>> ticket, the RS does not need to have any identifier for who purchased t=
he
>>> movie ticket.
>>>
>>> The privacy implication is the RS can correlate across API calls to kno=
w
>>> it is the same subject.
>>>
>>>
>>>
>>>
>>> On Mon, Apr 13, 2020 at 8:16 AM Denis >> > wrote:
>>>
>>>> Hello,
>>>>
>>>> More on privacy about "JWT Profile for Access Tokens".
>>>>
>>>> The current document REQUIRES the claim names *sub* and *client_id*.
>>>>
>>>>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>>>>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>>>>
>>>> *1) **sub  REQUIRED*
>>>>
>>>> RFC 7519 states:
>>>>
>>>> 4.1.2.  "sub" (Subject) Claim
>>>>    The "sub" (subject) claim identifies the principal that is the
>>>>    subject of the JWT.  The claims in a JWT are normally statements
>>>>    about the subject.  The subject value MUST either be scoped to
>>>>    *be locally unique in the context of the issuer or be globally
>>>> unique*.
>>>>    The processing of this claim is generally application specific.  Th=
e
>>>>    "sub" value is a case-sensitive string containing a StringOrURI
>>>>    value.  *Use of this claim is OPTIONAL.*
>>>>
>>>> If *sub *is *REQUIRED *for this profile, then this allows all resource
>>>> servers to link accesses made by the same client on different servers.
>>>>
>>>> *2) client_id  REQUIRED*
>>>>
>>>> RFC 8693 states:
>>>>
>>>> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
>>>> The client_id claim carries the client identi=EF=AC=81er of the OAuth =
2.0 [RFC
>>>> 6749] client that requested the token.
>>>>
>>>> RFC 6749 states:
>>>>
>>>> 2.2.  Client Identifier
>>>>    The authorization server issues the registered client a client
>>>>    identifier -- a unique string representing the registration
>>>>    information provided by the client.  The client identifier is not a
>>>>    secret; it is exposed to the resource owner and MUST NOT be used
>>>>    alone for client authentication.  *The client identifier is unique
>>>> to*
>>>> *   the authorization server.*
>>>>
>>>> If *client_id* is REQUIRED for this profile, this also allows all
>>>> resource servers to link accesses made by the same client on different
>>>> servers.
>>>>
>>>> *Both claim names should be OPTIONAL *to allow to support the privacy
>>>> principle of unlinkability.
>>>>
>>>> Would both names remain *REQUIRED*, the Privacy considerations section
>>>> should mention that such a linkage by different resource servers
>>>> will always be possible when using this profile.
>>>>
>>>> Denis
>>>>
>>>> I have uploaded the second presentation for today's session, the JWT
>>>> Profile for Access Tokens.
>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oau=
th
>>>>
>>>>
>>>> Regards,
>>>>  Rifaat
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> --
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--000000000000e30e5e05a3321707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=E2=80=9CIde rockers=E2=80=9D is iPhone autocorrect =
jargon for =E2=80=9Cidentifiers=E2=80=9D, of course :P

=

On Mon, Ap=
r 13, 2020 at 13:13 Vittorio Bertocci <Vittorio@auth0.com> wrote:
It=E2=80=99s certainly possible to conceive ATs =
without subs, but I think the profile would be way less useful for SDK deve=
lopers.
On the objections:
Th=
e sub doesn=E2=80=99t have to be a user, if you look at the earlier discuss=
ions the case in which the token has been issued for an application via cli=
ent creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able t=
o collide and track users, given that the sub can be a PPID that is differe=
nt for every resource even if the authenticated subject was the same.
=


The sub is mandatory here bec=
ause it was present in nearly every token among the ones observed, and alth=
ough one should not overindex on those scenarios, I took that as strong ind=
ication that it is a frequently used field and guaranteeing its presence fa=
cilitates embedding in SDKs lots of downstream features, such as correlatin=
g with locally stored attributes, which would otherwise left as exercise to=
 the reader. Per the points above, there are no obvious downsides in requir=
ing the presence of the sub and significant upsides. Again, the AS is in fu=
ll control of the sub content hence none of the privacy concerns mentioned =
here are mandated by the sheer presence of the sub claim. If you feel the p=
rivacy section should be stronger in warning an AS against the possibility =
of collusion if global ide rockers are used, I am happy to reword according=
ly=C2=A0

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <aaron@parecki.com> wrote:
This is a goo=
d point, I often use the hotel key analogy as well. The room door is the RS=
, the key is the access token, the door does not need to know who the user =
is in order to know if it=E2=80=99s okay to unlock given a particular key.<=
/div>

If sub is required=
, then this profile is limited in use to cases where user identifiers are p=
art of the system, and there will be situations in which it=E2=80=99s not a=
ppropriate to use this profile for access tokens. If that=E2=80=99s okay, t=
his should be clarified in the overview section to describe when this profi=
le should be used.

Aaron=




On Mon, Apr 13=
, 2020 at 10:08 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Why does the "sub" need to be =
required?

An access token is to prove authorization. The=
 RS may not need "sub" to constrain fulfilling=C2=A0the client re=
quest.=C2=A0

For example, it the=C2=A0access token=
 has the same properties as a movie ticket, the RS does not need to have an=
y identifier for who purchased the movie ticket.=C2=A0

=

The privacy implication is the RS can correlate across API calls to kn=
ow it is the same subject.=C2=A0



On Mon, Apr 13, 2020 at 8:16 AM Denis <denis..ietf@free.fr> wrote:
=


 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=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


-- 
----
Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--000000000000e30e5e05a3321707--


From nobody Mon Apr 13 18:05:19 2020
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 58DC13A226A for ; Mon, 13 Apr 2020 18:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LMx9tCinu6W6 for ; Mon, 13 Apr 2020 18:05:15 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 BFBD73A2268 for ; Mon, 13 Apr 2020 18:05:14 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id l11so8027449lfc.5 for ; Mon, 13 Apr 2020 18:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YJWcF0PISBlOLvN7ctF1U5alTc3PO1S5o5zawVJAsT0=; b=TPISeYBQUDcRNmZgkO3etNzi/3b2YSTi/CUvrA2jriF5saCxnM5fqZRrL/4BQCqnx4 aqv5kqjVkmd60aqubq5Qz7tPnylsJE0ByeI6zY4cN2ER0wcUpEyJFL1/ZfIpg2K1j29B cbmaRRgWTfOzQ6yt7GkEz5c2pgc1T0BeBEehzWsK6rY542X2XYQaCVx4HD/yuZQdmy4q nHrUTHmYMUWwqqncIwyY1SecZ54U6jYopKvHSvGHsIU7k96BKGDc9ApfNKh+W/7zbTpG DBM6CuqvnIO2hetv0su0nZ3yq93H1lFDVWtYwJjWRW4iLHmdf37hQrUDlGrgCrOpaU9Q Kl6w==
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=YJWcF0PISBlOLvN7ctF1U5alTc3PO1S5o5zawVJAsT0=; b=C6w7/Pe6GYYK3D5WcBmdUQpNTs+XTbGSzsnKjnCI2eLcZ0kjVef0K4UT24JxoERovf SuZZFMn+tcXpsGtvm2H3OOQ9o1jfLIGiD1okEuhiAPEknONPtj9k8e/B6/MoZF0deUbF /aPjJnzkLDeevwJN8tv+qqTd2Jxx2J1vT+LM+zvsI9uhCPM5jFaaBuMt8Hry8NSR/WXW Jr3bEMllTUOO7vLwGFCEC2FT2T+Qtdx1KiasmJhXKjxP4Qs1Zq2O6WZOWR7N6kRXxoUl beYuMnX/ADfkNWPjAGCOroKXfNhyL7NYYYodUI0BdwGnFlJ55jSHsdzrI1GcZAUUFMCT JlqA==
X-Gm-Message-State: AGi0Pub3GamxLY4vY4wWPcxNtD79Cdz2CX2UygKeWdxA0lrphYNiDneK hBaSR37xcuBbp0cu5QbN2rblM+tUxNRJe6etZfcDKyS6ZaA=
X-Google-Smtp-Source: APiQypJIZCmVVsBgUrxPiRIzY/4cZxc0u0ML+YkTCdO/Fy9YgtD8EbzCnpcZlLzBmUWEIKYY6Pp9qmzOm5H0PPlX8sk=
X-Received: by 2002:a19:9109:: with SMTP id t9mr12025703lfd.10.1586826312861;  Mon, 13 Apr 2020 18:05:12 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>    
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 13 Apr 2020 18:04:46 -0700
Message-ID: 
To: Vittorio Bertocci 
Cc: Aaron Parecki , oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b2ceff05a335ca17"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 01:05:17 -0000

--000000000000b2ceff05a335ca17
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

An SDK is going to support "sub" wether it is required or optional.



On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci 
wrote:

> =E2=80=9CIde rockers=E2=80=9D is iPhone autocorrect jargon for =E2=80=9Ci=
dentifiers=E2=80=9D, of course :P
>
> On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci 
> wrote:
>
>> It=E2=80=99s certainly possible to conceive ATs without subs, but I thin=
k the
>> profile would be way less useful for SDK developers.
>> On the objections:
>> The sub doesn=E2=80=99t have to be a user, if you look at the earlier di=
scussions
>> the case in which the token has been issued for an application via clien=
t
>> creds (hence non user) has been debated at length.
>> Knowing the subject does not necessarily lead to API being able to
>> collide and track users, given that the sub can be a PPID that is differ=
ent
>> for every resource even if the authenticated subject was the same.
>>
>
The privacy correlation I described is not solved by a per resource
directed identifier as the resource is learning that the same user is doing
different transactions -- or per my example, the resource is learning all
the movies the user is seeing.


>
>> The sub is mandatory here because it was present in nearly every token
>> among the ones observed,
>>
>
But NOT every token. So there were use cases where it was not required.


> and although one should not overindex on those scenarios, I took that as
>> strong indication that it is a frequently used field and guaranteeing it=
s
>> presence facilitates embedding in SDKs lots of downstream features, such=
 as
>> correlating with locally stored attributes, which would otherwise left a=
s
>> exercise to the reader.
>>
>
NOT correlating all the different actions by the user may be the desired
privacy goal by a deployment.


> Per the points above, there are no obvious downsides in requiring the
>> presence of the sub and significant upsides. Again, the AS is in full
>> control of the sub content hence none of the privacy concerns mentioned
>> here are mandated by the sheer presence of the sub claim. If you feel th=
e
>> privacy section should be stronger in warning an AS against the possibil=
ity
>> of collusion if global ide rockers are used, I am happy to reword
>> accordingly
>>
>
Per Aaron's comment, if this profile is NOT intended to support use cases
where the RS should not be able to correlate a user between resource
accesses, then it is fine for "sub" to be required. If so, then the
document should strongly point that out.


>
>> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki  wrote:
>>
>>> This is a good point, I often use the hotel key analogy as well. The
>>> room door is the RS, the key is the access token, the door does not nee=
d to
>>> know who the user is in order to know if it=E2=80=99s okay to unlock gi=
ven a
>>> particular key.
>>>
>>> If sub is required, then this profile is limited in use to cases where
>>> user identifiers are part of the system, and there will be situations i=
n
>>> which it=E2=80=99s not appropriate to use this profile for access token=
s. If that=E2=80=99s
>>> okay, this should be clarified in the overview section to describe when
>>> this profile should be used.
>>>
>>> Aaron
>>>
>>>
>>>
>>> On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt 
>>> wrote:
>>>
>>>> Why does the "sub" need to be required?
>>>>
>>>> An access token is to prove authorization. The RS may not need "sub" t=
o
>>>> constrain fulfilling the client request.
>>>>
>>>> For example, it the access token has the same properties as a movie
>>>> ticket, the RS does not need to have any identifier for who purchased =
the
>>>> movie ticket.
>>>>
>>>> The privacy implication is the RS can correlate across API calls to
>>>> know it is the same subject.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 13, 2020 at 8:16 AM Denis >>> > wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> More on privacy about "JWT Profile for Access Tokens".
>>>>>
>>>>> The current document REQUIRES the claim names *sub* and *client_id*.
>>>>>
>>>>>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>>>>>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>>>>>
>>>>> *1) **sub  REQUIRED*
>>>>>
>>>>> RFC 7519 states:
>>>>>
>>>>> 4.1.2.  "sub" (Subject) Claim
>>>>>    The "sub" (subject) claim identifies the principal that is the
>>>>>    subject of the JWT.  The claims in a JWT are normally statements
>>>>>    about the subject.  The subject value MUST either be scoped to
>>>>>    *be locally unique in the context of the issuer or be globally
>>>>> unique*.
>>>>>    The processing of this claim is generally application specific.  T=
he
>>>>>    "sub" value is a case-sensitive string containing a StringOrURI
>>>>>    value.  *Use of this claim is OPTIONAL.*
>>>>>
>>>>> If *sub *is *REQUIRED *for this profile, then this allows all
>>>>> resource servers to link accesses made by the same client on differen=
t
>>>>> servers.
>>>>>
>>>>> *2) client_id  REQUIRED*
>>>>>
>>>>> RFC 8693 states:
>>>>>
>>>>> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
>>>>> The client_id claim carries the client identi=EF=AC=81er of the OAuth=
 2.0 [RFC
>>>>> 6749] client that requested the token.
>>>>>
>>>>> RFC 6749 states:
>>>>>
>>>>> 2.2.  Client Identifier
>>>>>    The authorization server issues the registered client a client
>>>>>    identifier -- a unique string representing the registration
>>>>>    information provided by the client.  The client identifier is not =
a
>>>>>    secret; it is exposed to the resource owner and MUST NOT be used
>>>>>    alone for client authentication.  *The client identifier is unique
>>>>> to*
>>>>> *   the authorization server.*
>>>>>
>>>>> If *client_id* is REQUIRED for this profile, this also allows all
>>>>> resource servers to link accesses made by the same client on differen=
t
>>>>> servers.
>>>>>
>>>>> *Both claim names should be OPTIONAL *to allow to support the privacy
>>>>> principle of unlinkability.
>>>>>
>>>>> Would both names remain *REQUIRED*, the Privacy considerations
>>>>> section should mention that such a linkage by different resource serv=
ers
>>>>> will always be possible when using this profile.
>>>>>
>>>>> Denis
>>>>>
>>>>> I have uploaded the second presentation for today's session, the JWT
>>>>> Profile for Access Tokens.
>>>>>
>>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oa=
uth
>>>>>
>>>>>
>>>>> Regards,
>>>>>  Rifaat
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> --
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com
>>> @aaronpk 
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>

--000000000000b2ceff05a335ca17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





An SDK is going to support "sub" wether it is required o=
r optional.=C2=A0



On Mon, Apr 13, 2020=
 at 1:40 PM Vittorio Bertocci <Vit=
torio@auth0.com> wrote:
=E2=80=9CIde rockers=E2=80=9D is iPho=
ne autocorrect jargon for =E2=80=9Cidentifiers=E2=80=9D, of course :P
=


On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci <Vittorio@auth0.com> wrote:
=

It=E2=80=99s certainly possible to conceive ATs without subs, but I thi=
nk the profile would be way less useful for SDK developers.
On the objections:
The sub doesn=E2=80=99t=
 have to be a user, if you look at the earlier discussions the case in whic=
h the token has been issued for an application via client creds (hence non =
user) has been debated at length.
Knowing the =
subject does not necessarily lead to API being able to collide and track us=
ers, given that the sub can be a PPID that is different for every resource =
even if the authenticated subject was the same.

The privacy correlation I described is =
not solved by a per resource directed identifier as the resource is learnin=
g that the same user is doing different transactions -- or per my example, =
the resource=C2=A0is learning=C2=A0all the movies the user is seeing.
=

=C2=A0
<=
div dir=3D"auto">
The sub is mandatory here because it was present in nearl=
y every token among the ones observed,

But NOT every token. So there were use ca=
ses where it was not required.
=C2=A0
and although one shoul=
d not overindex on those scenarios, I took that as strong indication that i=
t is a frequently used field and guaranteeing its presence facilitates embe=
dding in SDKs lots of downstream features, such as correlating with locally=
 stored attributes, which would otherwise left as exercise to the reader. <=
/div>

NOT correlat=
ing all the different actions by the user may be the desired privacy goal b=
y a deployment.
=C2=A0
Per the points above, there are no ob=
vious downsides in requiring the presence of the sub and significant upside=
s. Again, the AS is in full control of the sub content hence none of the pr=
ivacy concerns mentioned here are mandated by the sheer presence of the sub=
 claim. If you feel the privacy section should be stronger in warning an AS=
 against the possibility of collusion if global ide rockers are used, I am =
happy to reword accordingly=C2=A0

Per Aaron's comment, if this=C2=A0profile=C2=A0is=
 NOT intended to support use cases where the RS should not be able to corre=
late a user between resource accesses, then it is fine for "sub" =
to be required. If so, then the document should strongly point that out.=C2=
=A0
=C2=A0

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <aaron@parecki.com> wrote:
=
This is a good point, I often use the hotel key analogy as well. The room d=
oor is the RS, the key is the access token, the door does not need to know =
who the user is in order to know if it=E2=80=99s okay to unlock given a par=
ticular key.

If su=
b is required, then this profile is limited in use to cases where user iden=
tifiers are part of the system, and there will be situations in which it=E2=
=80=99s not appropriate to use this profile for access tokens. If that=E2=
=80=99s okay, this should be clarified in the overview section to describe =
when this profile should be used.

Aaron



On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Why do=
es the "sub" need to be required?

An access to=
ken is to prove authorization. The RS may not need "sub" to const=
rain fulfilling=C2=A0the client request.=C2=A0

For=
 example, it the=C2=A0access token has the same properties as a movie ticke=
t, the RS does not need to have any identifier for who purchased the movie =
ticket.=C2=A0

The privacy implication is the RS ca=
n correlate across API calls to know it is the same subject.=C2=A0




On Mon, Apr 13, 2020 at 8:16 AM D=
enis <denis..iet=
f@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=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


-- 
----
Aaron =
Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth








--000000000000b2ceff05a335ca17--


From nobody Tue Apr 14 00:00:05 2020
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 5272C3A0E37 for ; Tue, 14 Apr 2020 00:00:02 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 aLUx2A1ty3Eu for ; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 8632D3A0E1C for ; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id u5so3966597ilb.5 for ; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nRJJjgmL/HP4uludemOh06Q/ZlIKVC4lm8N/1LcVen8=; b=M5AHorjv4+QY125VSVuGJ0LJ5NYqa+UUKlNIROQsQN1f0kXkNl4c/q+5pbZ0d2om5V QLHZJUX+/QefEXKybBeAA8KW16COzjWUiUSMc12wWDfcjtuKXdbsZRPegROTv4NJYlFz bXew2LnUmSbEg52yJDzBiKtdUeAu7pNaJ+ozMlhH5jJ+8P+y/X37KrET9VjHsnfYkBQO NB4KGsNs3wfnZmWspc5qNwa5b3LowbSn6mekhu1Ui8QN+SUiVO/Vw6AdGWfrFWnM8NqN SyoOva4f1nBkwALbct+0/iuaDYiIg04inj45UM98SAqDYO4QyndLeVbI/n3rjCB8Ut7h 9PaQ==
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=nRJJjgmL/HP4uludemOh06Q/ZlIKVC4lm8N/1LcVen8=; b=DCmn+/pzXKcsElcnSB0Y0E+jkipnWM0muzBmIOQSE+NiE33uldBB4ZHxVApe/3F0z7 HOSSqjasA9zqL32jR8VgQXW3MzakFg0LHChVo+BVAdi8LDbNINS6oCgTuJqABdTj6sPS uyqlD5sLPkBLUGPqmmlwENCa7suZnWsxGtE/JP90ECk/DfTClR9VIfOrEY3F6iIJ9l8A c+RH9KX7RBNBTHTW1Zr7MxnFHg6047Q/gapWqhVTdz/Etm8oyWKIQeAs1thTL53Ryn8L 90plK2mhl6bJ6SBVaJwIzIPz/PUB217gR3Ye9mKq0IJwecvWh9TZZ7rfhpbIy2Bs6Tfe Vn4w==
X-Gm-Message-State: AGi0Pua8BuUBZlehNVvjCqKRujPFyXhb4mLrxO4NKe20Jf24o66CXxOx N8lpbDq67OAdSeERbCIgEGXqB2E0wI23HGCE5QmgHS4w
X-Google-Smtp-Source: APiQypIRX1ryyNpb31APTf9CVNCUUbtwnfeVL93lZgjcUCgFIYbQ3392HGhdUt6uNGRRLdroDd6ujyKuvOO3HpHplkE=
X-Received: by 2002:a92:5d5b:: with SMTP id r88mr18565437ilb.206.1586847596417;  Mon, 13 Apr 2020 23:59:56 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>     
In-Reply-To: 
From: Vittorio Bertocci 
Date: Mon, 13 Apr 2020 23:40:27 -0700
Message-ID: 
To: Dick Hardt 
Cc: Aaron Parecki , oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004c2a5505a33abf04"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 07:00:03 -0000

--0000000000004c2a5505a33abf04
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking about
just parsing the sub value if it=E2=80=99s present or not surfacing it in a=
n object
model if it=E2=80=99s not- i think about reliably offering the higher level=
 jobs to
be done that are made possible by the sub presence (such as the correlation
with the calling subject and local information, exactly as in your example
all the movies a user watched thru that particular API).

> the resource is learning that the same user is doing different
transactions
Thanks for the clarification, I didn=E2=80=99t realize that you were not ju=
st
considering correlation across resources, but across calls to the same API.
And you are right that in that case, an API would be able to correlate the
user across subsequent API calls.
Per the above, I think that the ability of performing that correlation
inter-API is a goal on most systems. More below.

> But NOT every token. So there were use cases where it was not required.
Not that it proves anything conclusively given that I only sampled 7
system, but sub was actually used by all of them- with one of them omitting
it only in a particular circumstance, for tokens issued via client
credentials grant, and leveraging its absence as a way of deducing the
nature of the token (user or app identity). During earlier drafts we
debated at length the issue of providing mechanics to perform that
distinction and the outcome was that there was no interest in providing it;
and in the same debate it was established that sub applies to the
authenticated entity, hence it can describe the app principal as well.
Again, the fact that the main analyzed systems don=E2=80=99t make a strong =
case for
the absence of sub doesn=E2=80=99t imply that no such case exist; but I bel=
ieve it
is a strong indicator of sub usefulness in real world scenarios. In fact,
together with iss and aud, sub is the only claim appearing in every
provider JWT AT examined (Tho both sub and aud have each one exception due
to special circumstances).

I am fine with explicitly calling out that the presence of a mandatory sub
makes it possible for an API to correlate subsequent calls on the same
entity. I am ready to bet it won=E2=80=99t be a surprise for people using
proprietary JWT ATs, also thanks to the widespread practice of using
slightly modified ID token validation SDKs (when ID token themselves aren=
=E2=80=99t
directly used in lieu of ATs for API calls, as done by the likes of
Kubernetes and other mainstream products, which hopefully will eventually
consider this profile instead).

As a last resort, nothing forces the AS to stop at varying sub values only
per resource; it could go farther and supply a different sub value at every
token issuance for the same authenticating principal if it so chooses, and
still adhere to the letter of this profile while preventing cross operation
correlation. That would adhere to the letter of this interop spec if not
the the spirit, given that layout would be respected and one can creatively
define principals in its own system. If Apple can assign anti correlation
emails, nothing prevents an AS doing the same with sub at different
granularity.
That would break the job to be done that sub is meant to enable, but would
prevent correlation in practice AND it would allow for us to include a
piece of info that proved to be useful for a large portion of known cases.
But to reiterate, even if this workaround would not be possible, I would
still be OK with admitting cross operation correlation within the same
resource as by design.


On Mon, Apr 13, 2020 at 18:05 Dick Hardt  wrote:

>
>
>
> An SDK is going to support "sub" wether it is required or optional.
>
>
>
> On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci 
> wrote:
>
>> =E2=80=9CIde rockers=E2=80=9D is iPhone autocorrect jargon for =E2=80=9C=
identifiers=E2=80=9D, of course :P
>>
>> On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci 
>> wrote:
>>
>>> It=E2=80=99s certainly possible to conceive ATs without subs, but I thi=
nk the
>>> profile would be way less useful for SDK developers.
>>> On the objections:
>>> The sub doesn=E2=80=99t have to be a user, if you look at the earlier
>>> discussions the case in which the token has been issued for an applicat=
ion
>>> via client creds (hence non user) has been debated at length.
>>> Knowing the subject does not necessarily lead to API being able to
>>> collide and track users, given that the sub can be a PPID that is diffe=
rent
>>> for every resource even if the authenticated subject was the same.
>>>
>>
> The privacy correlation I described is not solved by a per resource
> directed identifier as the resource is learning that the same user is doi=
ng
> different transactions -- or per my example, the resource is learning all
> the movies the user is seeing.
>
>
>>
>>> The sub is mandatory here because it was present in nearly every token
>>> among the ones observed,
>>>
>>
> But NOT every token. So there were use cases where it was not required.
>
>
>> and although one should not overindex on those scenarios, I took that as
>>> strong indication that it is a frequently used field and guaranteeing i=
ts
>>> presence facilitates embedding in SDKs lots of downstream features, suc=
h as
>>> correlating with locally stored attributes, which would otherwise left =
as
>>> exercise to the reader.
>>>
>>
> NOT correlating all the different actions by the user may be the desired
> privacy goal by a deployment.
>
>
>> Per the points above, there are no obvious downsides in requiring the
>>> presence of the sub and significant upsides. Again, the AS is in full
>>> control of the sub content hence none of the privacy concerns mentioned
>>> here are mandated by the sheer presence of the sub claim. If you feel t=
he
>>> privacy section should be stronger in warning an AS against the possibi=
lity
>>> of collusion if global ide rockers are used, I am happy to reword
>>> accordingly
>>>
>>
> Per Aaron's comment, if this profile is NOT intended to support use cases
> where the RS should not be able to correlate a user between resource
> accesses, then it is fine for "sub" to be required. If so, then the
> document should strongly point that out.
>
>
>>
>>> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki  wrote:
>>>
>>>> This is a good point, I often use the hotel key analogy as well. The
>>>> room door is the RS, the key is the access token, the door does not ne=
ed to
>>>> know who the user is in order to know if it=E2=80=99s okay to unlock g=
iven a
>>>> particular key.
>>>>
>>>> If sub is required, then this profile is limited in use to cases where
>>>> user identifiers are part of the system, and there will be situations =
in
>>>> which it=E2=80=99s not appropriate to use this profile for access toke=
ns. If that=E2=80=99s
>>>> okay, this should be clarified in the overview section to describe whe=
n
>>>> this profile should be used.
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>> On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt 
>>>> wrote:
>>>>
>>>>> Why does the "sub" need to be required?
>>>>>
>>>>> An access token is to prove authorization. The RS may not need "sub"
>>>>> to constrain fulfilling the client request.
>>>>>
>>>>> For example, it the access token has the same properties as a movie
>>>>> ticket, the RS does not need to have any identifier for who purchased=
 the
>>>>> movie ticket.
>>>>>
>>>>> The privacy implication is the RS can correlate across API calls to
>>>>> know it is the same subject.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 13, 2020 at 8:16 AM Denis >>>> > wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> More on privacy about "JWT Profile for Access Tokens".
>>>>>>
>>>>>> The current document REQUIRES the claim names *sub* and *client_id*.
>>>>>>
>>>>>>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>>>>>>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>>>>>>
>>>>>> *1) **sub  REQUIRED*
>>>>>>
>>>>>> RFC 7519 states:
>>>>>>
>>>>>> 4.1.2.  "sub" (Subject) Claim
>>>>>>    The "sub" (subject) claim identifies the principal that is the
>>>>>>    subject of the JWT.  The claims in a JWT are normally statements
>>>>>>    about the subject.  The subject value MUST either be scoped to
>>>>>>    *be locally unique in the context of the issuer or be globally
>>>>>> unique*.
>>>>>>    The processing of this claim is generally application specific.
>>>>>> The
>>>>>>    "sub" value is a case-sensitive string containing a StringOrURI
>>>>>>    value.  *Use of this claim is OPTIONAL.*
>>>>>>
>>>>>> If *sub *is *REQUIRED *for this profile, then this allows all
>>>>>> resource servers to link accesses made by the same client on differe=
nt
>>>>>> servers.
>>>>>>
>>>>>> *2) client_id  REQUIRED*
>>>>>>
>>>>>> RFC 8693 states:
>>>>>>
>>>>>> 4.3. "client_id" (Client Identi=EF=AC=81er) Claim
>>>>>> The client_id claim carries the client identi=EF=AC=81er of the OAut=
h 2.0
>>>>>> [RFC 6749] client that requested the token.
>>>>>>
>>>>>> RFC 6749 states:
>>>>>>
>>>>>> 2.2.  Client Identifier
>>>>>>    The authorization server issues the registered client a client
>>>>>>    identifier -- a unique string representing the registration
>>>>>>    information provided by the client.  The client identifier is not=
 a
>>>>>>    secret; it is exposed to the resource owner and MUST NOT be used
>>>>>>    alone for client authentication.  *The client identifier is
>>>>>> unique to*
>>>>>> *   the authorization server.*
>>>>>>
>>>>>> If *client_id* is REQUIRED for this profile, this also allows all
>>>>>> resource servers to link accesses made by the same client on differe=
nt
>>>>>> servers.
>>>>>>
>>>>>> *Both claim names should be OPTIONAL *to allow to support the
>>>>>> privacy principle of unlinkability.
>>>>>>
>>>>>> Would both names remain *REQUIRED*, the Privacy considerations
>>>>>> section should mention that such a linkage by different resource ser=
vers
>>>>>> will always be possible when using this profile.
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>> I have uploaded the second presentation for today's session, the JWT
>>>>>> Profile for Access Tokens.
>>>>>>
>>>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/o=
auth
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>  Rifaat
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> --
>>>> ----
>>>> Aaron Parecki
>>>> aaronparecki.com
>>>> @aaronpk 
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>

--0000000000004c2a5505a33abf04
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> An SDK is going to support "sub" weth=
er it is required or optional.=C2=A0
When I think ab=
out support for sub in this case, I am not thinking about just parsing the =
sub value if it=E2=80=99s present or not surfacing it in an object model if=
 it=E2=80=99s not- i think about reliably offering the higher level jobs to=
 be done that are made possible by the sub presence (such as the correlatio=
n with the calling subject and local information, exactly as in your exampl=
e all the movies a user watched thru that particular API).

> the resource is learning that=
 the same user is doing different transactions
Thank=
s for the clarification, I didn=E2=80=99t realize that you were not just co=
nsidering correlation across resources, but across calls to the same API. A=
nd you are right that in that case, an API would be able to correlate the u=
ser across subsequent API calls.
Per the above, I th=
ink that the ability of performing that correlation inter-API is a goal on =
most systems. More below.

> But NOT every token. So there were use cases where it was not requir=
ed.
Not that it proves anything conclusively given t=
hat I only sampled 7 system, but sub was actually used by all of them- with=
 one of them omitting it only in a particular circumstance, for tokens issu=
ed via client credentials grant, and leveraging its absence as a way of ded=
ucing the nature of the token (user or app identity). During earlier drafts=
 we debated at length the issue of providing mechanics to perform that dist=
inction and the outcome was that there was no interest in providing it; and=
 in the same debate it was established that sub applies to the authenticate=
d entity, hence it can describe the app principal as well.
Again, the fact that the main analyzed systems don=E2=80=99t make a =
strong case for the absence of sub doesn=E2=80=99t imply that no such case =
exist; but I believe it is a strong indicator of sub usefulness in real wor=
ld scenarios. In fact, together with iss and aud, sub is the only claim app=
earing in every provider JWT AT examined (Tho both sub and aud have each on=
e exception due to special circumstances).

I am fine with explicitly calling out that the presence =
of a mandatory sub makes it possible for an API to correlate subsequent cal=
ls on the same entity. I am ready to bet it won=E2=80=99t be a surprise for=
 people using proprietary JWT ATs, also thanks to the widespread practice o=
f using slightly modified ID token validation SDKs (when ID token themselve=
s aren=E2=80=99t directly used in lieu of ATs for API calls, as done by the=
 likes of Kubernetes and other mainstream products, which hopefully will ev=
entually consider this profile instead).

<=
div dir=3D"auto">As a last resort, nothing forces the AS to stop at varying=
 sub values only per resource; it could go farther and supply a different s=
ub value at every token issuance for the same authenticating principal if i=
t so chooses, and still adhere to the letter of this profile while preventi=
ng cross operation correlation. That would adhere to the letter of this int=
erop spec if not the the spirit, given that layout would be respected and o=
ne can creatively define principals in its own system. If Apple can assign =
anti correlation emails, nothing prevents an AS doing the same with sub at =
different granularity.
That would break the job to b=
e done that sub is meant to enable, but would prevent correlation in practi=
ce AND it would allow for us to include a piece of info that proved to be u=
seful for a large portion of known cases. But to reiterate, even if this wo=
rkaround would not be possible, I would still be OK with admitting cross op=
eration correlation within the same resource as by design.


On Mon, Apr 13, 2020 at 18:05 Dick Hardt <dick.hardt@gmail.com> wrote:



An SDK is going to support "sub&qu=
ot; wether it is required or optional.=C2=A0


<=
/div>

On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci <Vittorio@auth0.com> wrote:
=E2=80=9CIde rockers=E2=80=9D is iPhone autocorrect jargon for =E2=80=
=9Cidentifiers=E2=80=9D, of course :P

On Mon, Apr 13, 2020 at 13:=
13 Vittorio Bertocci <Vittorio@auth0.com> wrote:
It=E2=80=99s certainly possi=
ble to conceive ATs without subs, but I think the profile would be way less=
 useful for SDK developers.
On the objections:
=

The sub doesn=E2=80=99t have to be a user, if you look at=
 the earlier discussions the case in which the token has been issued for an=
 application via client creds (hence non user) has been debated at length.<=
/div>
Knowing the subject does not necessarily lead =
to API being able to collide and track users, given that the sub can be a P=
PID that is different for every resource even if the authenticated subject =
was the same.

The privacy correlation I described is not solved by a per resource direc=
ted identifier as the resource is learning that the same user is doing diff=
erent transactions -- or per my example, the resource=C2=A0is learning=C2=
=A0all the movies the user is seeing.
=C2=A0

The sub is man=
datory here because it was present in nearly every token among the ones obs=
erved,

But NOT every token. So there were use cases where it was not required.
=C2=A0
and although one should not overindex on those scenari=
os, I took that as strong indication that it is a frequently used field and=
 guaranteeing its presence facilitates embedding in SDKs lots of downstream=
 features, such as correlating with locally stored attributes, which would =
otherwise left as exercise to the reader. 

NOT correlating all the different actions by=
 the user may be the desired privacy goal by a deployment.
=C2=A0=

Per the points above, there are no obvious downsides in requiring the=
 presence of the sub and significant upsides. Again, the AS is in full cont=
rol of the sub content hence none of the privacy concerns mentioned here ar=
e mandated by the sheer presence of the sub claim. If you feel the privacy =
section should be stronger in warning an AS against the possibility of coll=
usion if global ide rockers are used, I am happy to reword accordingly=C2=
=A0

Per Aaro=
n's comment, if this=C2=A0profile=C2=A0is NOT intended to support use c=
ases where the RS should not be able to correlate a user between resource a=
ccesses, then it is fine for "sub" to be required. If so, then th=
e document should strongly point that out.=C2=A0
=C2=A0

On Mon, Apr 13, 2020 at 10:16 Aaron Parec=
ki <aaron@parecki=
.com> wrote:
This is a good point, I often use the hotel key =
analogy as well. The room door is the RS, the key is the access token, the =
door does not need to know who the user is in order to know if it=E2=80=99s=
 okay to unlock given a particular key.

If sub is required, then this profile is limited in u=
se to cases where user identifiers are part of the system, and there will b=
e situations in which it=E2=80=99s not appropriate to use this profile for =
access tokens. If that=E2=80=99s okay, this should be clarified in the over=
view section to describe when this profile should be used.

Aaron

<=
div dir=3D"auto">

On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c=
om> wrote:
Why does the "sub" need to be required?
An access token is to prove authorization. The RS may not need=
 "sub" to constrain fulfilling=C2=A0the client request.=C2=A0

For example, it the=C2=A0access token has the same pr=
operties as a movie ticket, the RS does not need to have any identifier for=
 who purchased the movie ticket.=C2=A0

The privacy=
 implication is the RS can correlate across API calls to know it is the sam=
e subject.=C2=A0



On Mon, =
Apr 13, 2020 at 8:16 AM Denis <denis..ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello,

    


    

    
More on privacy about "JWT Profile for
      Access Tokens".

    


    

    
The current document REQUIRES the claim
      names sub and client_id.

    
    
      
  • sub=C2=A0 REQUIRED - as defined in section 4.1.2 of [RFC7519]. 
      
  • client_id=C2=A0 REQUIRED - as defined in section 4.3 of [RFC8693]=

    • 
    

    
1) sub=C2=A0 REQUIRED 

    


    

    
RFC 7519 states:

    

      
4.1.2.=C2=A0 "sub" (Subject) Claim

        =C2=A0=C2=A0 The "sub" (subject) claim identifies the pri=
ncipal that is
        the

        =C2=A0=C2=A0 subject of the JWT.=C2=A0 The claims in a JWT are norm=
ally
        statements

        =C2=A0=C2=A0 about the subject.=C2=A0 The subject value MUST either=
 be scoped
        to 

        =C2=A0=C2=A0 be locally unique in the context of the issuer or b=
e
          globally unique.

        =C2=A0=C2=A0 The processing of this claim is generally application
        specific.=C2=A0 The

        =C2=A0=C2=A0 "sub" value is a case-sensitive string conta=
ining a
        StringOrURI

        =C2=A0=C2=A0 value.=C2=A0 Use of this claim is OPTIONAL.
    

    
If sub is REQUIRED for
      this profile, then this allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
2) client_id=C2=A0 REQUIRED

    


    

    
RFC 8693 states: 

    

    

      
4.3. "client_id" (Client Identi=EF=AC=81er)
        Claim 

        The client_id claim carries the client identi=EF=AC=81er of the OAu=
th
        2.0 [RFC 6749] client that requested the token.

      

    

    
RFC 6749 states:

    

      
2.2.=C2=A0 Client Identifier

        =C2=A0=C2=A0 The authorization server issues the registered client =
a
        client

        =C2=A0=C2=A0 identifier -- a unique string representing the registr=
ation

        =C2=A0=C2=A0 information provided by the client.=C2=A0 The client i=
dentifier is
        not a

        =C2=A0=C2=A0 secret; it is exposed to the resource owner and MUST N=
OT be
        used

        =C2=A0=C2=A0 alone for client authentication.=C2=A0 The client i=
dentifier
          is unique to

        =C2=A0=C2=A0 the authorization server.

    

    
If client_id is REQUIRED for
      this profile, this also allows all resource servers to link
      accesses made by the same client on different servers.

    


    

    
Both claim names should be OPTIONAL
      to allow to support the privacy principle of unlinkability.

    


    

    
Would both names remain REQUIRED,
      the Privacy considerations section should mention that such a
      linkage by different resource servers 

      will always be possible when using this profile.

    

    


    

    
Denis

    


    

    

     =20
      
I have uploaded the second presentation for today=
9;s
        session, the=C2=A0JWT Profile for Access Tokens.
        
        


        

        
Regards,

        
=C2=A0Rifaat

        
=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


-- 
----
Aaron =
Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth








--0000000000004c2a5505a33abf04--


From nobody Tue Apr 14 01:13:39 2020
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 B7CCF3A0404 for ; Tue, 14 Apr 2020 01:13:34 -0700 (PDT)
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, 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 urqAZbj3WLjp for ; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 CCE223A0407 for ; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id h205so6733353ybg.6 for ; Tue, 14 Apr 2020 01:13:32 -0700 (PDT)
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=qQ5+rI+ZANN6xZphofSDogQrBURkhrKU/L2TiD/9//M=; b=AHUWvrwTK1qxtjlBPlsOp7YP81heKYrZok0cIWCdDbE/U/3EgqRabRwpKs4LOVs4R0 75NLZja9eFJV5NOMSsSbr/T1/D4wjOQtTAeSKDereyzctdXWW8umYPKZGeNgXJGicmiN Gu4offqP3LMrGs6jwkZAMzqy6XjnetAxDbedqdZd0bDqj/tJn3lcX9xe3/J9oPjhLEwZ 1sP+AkkUyVRJ5KmYXZOk0NauVN1s2f/v40+6ioVYBjr5DX+CmnYfMd7BIVCL7N2ZrT3A h8xLVfBpr/l62RQlS+Wb4cHl0YmEbbpe9vtWDdg9ocMSLzFQc/e48XxAk1hl4ELlQCfL OQIw==
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=qQ5+rI+ZANN6xZphofSDogQrBURkhrKU/L2TiD/9//M=; b=qrEOh4KBiinYtPFTEoEzAPnbp3T/6SRCi235hlp+XgyjxewbrDjQ8xsdYzXDQaf0Wp 8Ua9DjW8Y1Sty9BJvIY2C01rY5DuAy6+2r1nrTT2uAQ0DNDBEFO/YKDjYRhs7gmjz4AF JWxOzB04QdNKeIz1Hzvav3/0IcCNoU2+/2n5BD7p3SDbfYVIi/FMC5NPzTomX1mHHnHZ b+vCK+k5GXNXOiz1kviTeJyJesdNG/chDbqZmfwqGfefQuYThM7wfCxWOOKUlfHjJIAo P8tViHzi3R0aLLg45r0UtW/K/cagFFAeKDnVunEuJdZ3m+qSyuxoZF6TZ/iX/8FkHV3o igdQ==
X-Gm-Message-State: AGi0Puboo3UfJ5owa+IsUKAMrks2ih3Uo1UmqQ5e0nxYLatmcDn4t7Au IR3b4Y0gDi6E9TCL5BSR9c6ykAMaBZb8ciBi1PwF2v838w==
X-Google-Smtp-Source: APiQypI3K+nZhUkOwOkDRJI3x5K6vrDls753W2O3TXNKjGf3vGjP+YIRVzX6gATihul06ijZY2kcmhrQJ6nOvpo9cWw=
X-Received: by 2002:a25:5f0c:: with SMTP id t12mr31392832ybb.254.1586852011693;  Tue, 14 Apr 2020 01:13:31 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan 
Date: Tue, 14 Apr 2020 10:12:54 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000077db2e05a33bc627"
Archived-At: 
Subject: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 14 Apr 2020 08:13:35 -0000

--00000000000077db2e05a33bc627
Content-Type: text/plain; charset="UTF-8"

I've wondered about the decision to use a new scheme before
 but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.

If at all, it is going to take time for RS implementations to recognize the
new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to do
   since it's both the issuer and recipient of a refresh token? Should this be
   somehow baked in the draft?
   - Do you think client registration metadata could be used to signal such
   intent?
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?
   - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
   we disqualify such cases or allow for sending two proofs, one for the AS to
   bind refresh tokens to, one for the RS to bind access tokens to?


Best,
*Filip Skokan*

--00000000000077db2e05a33bc627
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I've wondered about the decision to use a new sch=
eme=C2=A0before=C2=A0but this time i'd like to challenge=
 the immediate usability of the future spec for one specific case - sender =
constraining public client Refresh Tokens.

If at all, it is going to=
 take time for RS implementations to recognize the new `DPoP` authorization=
 scheme, let alone process it properly. In the meantime, i'd still like=
 to have the option to bind issued public client refresh tokens using DPoP =
without affecting the access tokens. In doing so i get an immediate win in =
sender constraining the refresh tokens but not introducing a breaking chang=
e for the RS.

  • Do you see this as something an AS implementat=
ion is just free to do since it's both the issuer and recipient of a re=
fresh token? Should this be somehow baked in the draft?
  • Do you thin=
k client registration metadata could be used to signal such intent?
    • Do you think the protocol should have signals in the messages themselves t=
o say what the client wants to apply DPoP to?
  • What if AS and RS don=
't have a shared support DPoP JWS Algorithm? Do we disqualify such case=
s or allow for sending two proofs, one for the AS to bind refresh tokens to=
, one for the RS to bind access tokens to?

Best,
Filip Skokan


--00000000000077db2e05a33bc627--


From nobody Tue Apr 14 07:23:14 2020
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 09D8D3A07E9 for ; Tue, 14 Apr 2020 07:23:12 -0700 (PDT)
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.398, 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 4r1bdl5o-ge6 for ; Tue, 14 Apr 2020 07:23:09 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CACB3A07E1 for ; Tue, 14 Apr 2020 07:23:08 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d22 with ME id SeP52200C4FMSmm03eP54S; Tue, 14 Apr 2020 16:23:06 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 14 Apr 2020 16:23:06 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>      
From: Denis 
Message-ID: <60478f63-257c-a05a-1587-505b9190205e@free.fr>
Date: Tue, 14 Apr 2020 16:23:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------015B1C8D56CC65AA69D38683"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 14:23:12 -0000

This is a multi-part message in MIME format.
--------------015B1C8D56CC65AA69D38683
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Vittorio, some comments in line:

 > An SDK is going to support "sub" wether it is required or optional.
> When I think about support for sub in this case, I am not thinking 
> about just parsing the sub value if it’s present or not surfacing it 
> in an object model if it’s not- i think about reliably offering the 
> higher level jobs to be done that are made possible by the sub 
> presence (such as the correlation with the calling subject and local 
> information, exactly as in your example all the movies a user watched 
> thru that particular API).
>
> > the resource is learning that the same user is doing different 
> transactions
> Thanks for the clarification, I didn’t realize that you were not just 
> considering correlation across resources, but across calls to the same 
> API. And you are right that in that case, an API would be able to 
> correlate the user across subsequent API calls.
> Per the above, I think that the ability of performing that correlation 
> inter-API is a goal on most systems. More below.
>
> > But NOT every token. So there were use cases where it was not required.
> Not that it proves anything conclusively given that I only sampled 7 
> system, but sub was actually used by all of them- with one of them 
> omitting it only in a particular circumstance, for tokens issued via 
> client credentials grant, and leveraging its absence as a way of 
> deducing the nature of the token (user or app identity). During 
> earlier drafts we debated at length the issue of providing mechanics 
> to perform that distinction and the outcome was that there was no 
> interest in providing it; and in the same debate it was established 
> that sub applies to the authenticated entity, hence it can describe 
> the app principal as well.
> Again, the fact that the main analyzed systems don’t make a strong 
> case for the absence of sub doesn’t imply that no such case exist; but 
> I believe it is a strong indicator of sub usefulness in real world 
> scenarios. In fact, together with iss and aud, sub is the only claim 
> appearing in every provider JWT AT examined (Tho both sub and aud have 
> each one exception due to special circumstances).
>
> I am fine with explicitly calling out that the presence of a mandatory 
> sub makes it possible for an API to correlate subsequent calls on the 
> same entity.

I agree with you that the ability of performing correlation inter-API is 
a goal on most systems. However, this correlation *alone *CANNOT be 
achieved
using the sub claim using the definition of sub as defined in RFC 7519 
(4.1.2):

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

Using the sub claim for inter-API correlation purposes would necessarily 
allow correlation across different resources.

In the "Privacy considerations" section, whether sub is REQUIRED or 
OPTIONAL, the reader should be warned that the presence of the "sub" 
(subject) claim
in a JWT makes it possible for different resources to correlate 
different calls, as well as for the same resource to correlate between 
inter-API calls.

> I am ready to bet it won’t be a surprise for people using proprietary 
> JWT ATs, also thanks to the widespread practice of using slightly 
> modified ID token validation SDKs
> (when ID token themselves aren’t directly used in lieu of ATs for API 
> calls, as done by the likes of Kubernetes and other mainstream 
> products, which hopefully will
> eventually consider this profile instead).
>
> As a last resort, nothing forces the AS to stop at varying sub values 
> only per resource; it could go farther and supply a different sub 
> value at every token issuance
> for the same authenticating principal if it so chooses, and still 
> adhere to the letter of this profile while preventing cross operation 
> correlation.

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

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

> That would adhere to the letter of this interop spec if not the the 
> spirit, given that layout would be respected and one can creatively 
> define principals in its own system.
> If Apple can assign anti correlation emails, nothing prevents an AS 
> doing the same with sub at different granularity.
> That would break the job to be done that sub is meant to enable, but 
> would prevent correlation in practice AND it would allow for us to 
> include a piece of info
> that proved to be useful for a large portion of known cases. But to 
> reiterate, even if this workaround would not be possible,
> I would still be OK with admitting cross operation correlation within 
> the same resource as by design.

...  and I hope you are also OK for admitting cross correlation of 
subjects between different resources. The question whether this was also 
done "by design" (or not) is left open.

Similar considerations apply for the client_id (client identifier) since 
RFC 6749 (2.2) states:

       The client identifier [i.e. a unique string representing the 
registration information provided by the client] is *unique to the 
authorization server*.

Denis

>
>
> On Mon, Apr 13, 2020 at 18:05 Dick Hardt  > wrote:
>
>
>
>
>     An SDK is going to support "sub" wether it is required or optional.
>
>
>
>     On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci
>     > wrote:
>
>         “Ide rockers” is iPhone autocorrect jargon for “identifiers”,
>         of course :P
>
>         On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci
>         > wrote:
>
>             It’s certainly possible to conceive ATs without subs, but
>             I think the profile would be way less useful for SDK
>             developers.
>             On the objections:
>             The sub doesn’t have to be a user, if you look at the
>             earlier discussions the case in which the token has been
>             issued for an application via client creds (hence non
>             user) has been debated at length.
>             Knowing the subject does not necessarily lead to API being
>             able to collide and track users, given that the sub can be
>             a PPID that is different for every resource even if the
>             authenticated subject was the same.
>
>
>     The privacy correlation I described is not solved by a per
>     resource directed identifier as the resource is learning that the
>     same user is doing different transactions -- or per my example,
>     the resource is learning all the movies the user is seeing.
>
>
>             The sub is mandatory here because it was present in nearly
>             every token among the ones observed,
>
>
>     But NOT every token. So there were use cases where it was not
>     required.
>
>             and although one should not overindex on those scenarios,
>             I took that as strong indication that it is a frequently
>             used field and guaranteeing its presence facilitates
>             embedding in SDKs lots of downstream features, such as
>             correlating with locally stored attributes, which would
>             otherwise left as exercise to the reader.
>
>
>     NOT correlating all the different actions by the user may be the
>     desired privacy goal by a deployment.
>
>             Per the points above, there are no obvious downsides in
>             requiring the presence of the sub and significant upsides.
>             Again, the AS is in full control of the sub content hence
>             none of the privacy concerns mentioned here are mandated
>             by the sheer presence of the sub claim. If you feel the
>             privacy section should be stronger in warning an AS
>             against the possibility of collusion if global ide rockers
>             are used, I am happy to reword accordingly
>
>
>     Per Aaron's comment, if this profile is NOT intended to support
>     use cases where the RS should not be able to correlate a user
>     between resource accesses, then it is fine for "sub" to be
>     required. If so, then the document should strongly point that out.
>
>
>             On Mon, Apr 13, 2020 at 10:16 Aaron Parecki
>             > wrote:
>
>                 This is a good point, I often use the hotel key
>                 analogy as well. The room door is the RS, the key is
>                 the access token, the door does not need to know who
>                 the user is in order to know if it’s okay to unlock
>                 given a particular key.
>
>                 If sub is required, then this profile is limited in
>                 use to cases where user identifiers are part of the
>                 system, and there will be situations in which it’s not
>                 appropriate to use this profile for access tokens. If
>                 that’s okay, this should be clarified in the overview
>                 section to describe when this profile should be used.
>
>                 Aaron
>
>
>
>                 On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt
>                 >
>                 wrote:
>
>                     Why does the "sub" need to be required?
>
>                     An access token is to prove authorization. The RS
>                     may not need "sub" to constrain fulfilling the
>                     client request.
>
>                     For example, it the access token has the same
>                     properties as a movie ticket, the RS does not need
>                     to have any identifier for who purchased the movie
>                     ticket.
>
>                     The privacy implication is the RS can correlate
>                     across API calls to know it is the same subject.
>
>
>
>
>                     On Mon, Apr 13, 2020 at 8:16 AM Denis
>                     >
>                     wrote:
>
>                         Hello,
>
>                         More on privacy about "JWT Profile for Access
>                         Tokens".
>
>                         The current document REQUIRES the claim names
>                         *sub* and *client_id*.
>
>                           * sub  REQUIRED - as defined in section
>                             4.1.2 of [RFC7519].
>                           * client_id  REQUIRED - as defined in
>                             section 4.3 of [RFC8693]
>
>                         *1) **sub REQUIRED*
>
>                         RFC 7519 states:
>
>                             4.1.2.  "sub" (Subject) Claim
>                                The "sub" (subject) claim identifies
>                             the principal that is the
>                                subject of the JWT. The claims in a JWT
>                             are normally statements
>                                about the subject.  The subject value
>                             MUST either be scoped to**
>                             *be locally unique in the context of the
>                             issuer or be globally unique*.
>                                The processing of this claim is
>                             generally application specific.  The
>                                "sub" value is a case-sensitive string
>                             containing a StringOrURI
>                                value. *Use of this claim is OPTIONAL.*
>
>                         If *sub *is *REQUIRED *for this profile, then
>                         this allows all resource servers to link
>                         accesses made by the same client on different
>                         servers.
>
>                         *2) client_id  REQUIRED*
>
>                         RFC 8693 states:
>
>                             4.3. "client_id" (Client Identifier) Claim
>                             The client_id claim carries the client
>                             identifier of the OAuth 2.0 [RFC 6749]
>                             client that requested the token.
>
>                         RFC 6749 states:
>
>                             2.2.  Client Identifier
>                                The authorization server issues the
>                             registered client a client
>                                identifier -- a unique string
>                             representing the registration
>                                information provided by the client. 
>                             The client identifier is not a
>                                secret; it is exposed to the resource
>                             owner and MUST NOT be used
>                                alone for client authentication. *The
>                             client identifier is unique to**
>                             **   the authorization server.*
>
>                         If *client_id* is REQUIRED for this profile,
>                         this also allows all resource servers to link
>                         accesses made by the same client on different
>                         servers.
>
>                         *Both claim names should be OPTIONAL *to allow
>                         to support the privacy principle of unlinkability.
>
>                         Would both names remain *REQUIRED*, the
>                         Privacy considerations section should mention
>                         that such a linkage by different resource servers
>                         will always be possible when using this profile.
>
>                         Denis
>
>>                         I have uploaded the second presentation for
>>                         today's session, the JWT Profile for Access
>>                         Tokens.
>>                         https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>>
>>
>>                         Regards,
>>                          Rifaat
>>
>
>                         _______________________________________________
>                         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
>
>                 -- 
>                 ----
>                 Aaron Parecki
>                 aaronparecki.com 
>                 @aaronpk 
>
>                 _______________________________________________
>                 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



--------------015B1C8D56CC65AA69D38683
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Vittorio, some comments in line:

    

    

    > An SDK is going to support "sub" wether it is required or
    optional. 
    

      

        
When I think about support for sub in this case,
          I am not thinking about just parsing the sub value if it’s
          present or not surfacing it in an object model if it’s not- i
          think about reliably offering the higher level jobs to be done
          that are made possible by the sub presence (such as the
          correlation with the calling subject and local information,
          exactly as in your example all the movies a user watched thru
          that particular API).

      

      


      

      
> the resource is learning that the same user
        is doing different transactions

      
Thanks for the clarification, I didn’t realize
        that you were not just considering correlation across resources,
        but across calls to the same API. And you are right that in that
        case, an API would be able to correlate the user across
        subsequent API calls.

      
Per the above, I think that the ability of
        performing that correlation inter-API is a goal on most systems.
        More below.

      


      

      
> But NOT every token. So there were use cases
        where it was not required.

      
Not that it proves anything conclusively given
        that I only sampled 7 system, but sub was actually used by all
        of them- with one of them omitting it only in a particular
        circumstance, for tokens issued via client credentials grant,
        and leveraging its absence as a way of deducing the nature of
        the token (user or app identity). During earlier drafts we
        debated at length the issue of providing mechanics to perform
        that distinction and the outcome was that there was no interest
        in providing it; and in the same debate it was established that
        sub applies to the authenticated entity, hence it can describe
        the app principal as well.

      
Again, the fact that the main analyzed systems
        don’t make a strong case for the absence of sub doesn’t imply
        that no such case exist; but I believe it is a strong indicator
        of sub usefulness in real world scenarios. In fact, together
        with iss and aud, sub is the only claim appearing in every
        provider JWT AT examined (Tho both sub and aud have each one
        exception due to special circumstances).

      


      

      
I am fine with explicitly calling out that the
        presence of a mandatory sub makes it possible for an API to
        correlate subsequent calls on the same entity. 

    

    
I agree with you that the ability of performing correlation
      inter-API is a goal on most systems. However, this correlation alone
      CANNOT be achieved 

      using the sub claim using the definition of sub as defined in RFC
      7519 (4.1.2):

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

    

    
Using the sub claim for inter-API correlation purposes would
      necessarily allow correlation across different resources.

    
In the "Privacy considerations" section, whether sub is REQUIRED
      or OPTIONAL, the reader should be warned that the presence of the
      "sub" (subject) claim 

      in a JWT makes it possible for different resources to correlate
      different calls, as well as for the same resource to correlate
      between inter-API calls. 

    

      
I am ready to bet it won’t be a surprise for
        people using proprietary JWT ATs, also thanks to the widespread
        practice of using slightly modified ID token validation SDKs 

        (when ID token themselves aren’t directly used in lieu of ATs
        for API calls, as done by the likes of Kubernetes and other
        mainstream products, which hopefully will 

        eventually consider this profile instead).

      


      

      
As a last resort, nothing forces the AS to stop at
        varying sub values only per resource; it could go farther and
        supply a different sub value at every token issuance 

        for the same authenticating principal if it so chooses, and
        still adhere to the letter of this profile while preventing
        cross operation correlation. 

    

    
Unfortunately, this is not possible since RFC 7519 (4.1.2)
      states:
    

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

    

      
That would adhere to the letter of this interop
        spec if not the the spirit, given that layout would be respected
        and one can creatively define principals in its own system. 

        If Apple can assign anti correlation emails, nothing prevents an
        AS doing the same with sub at different granularity.

      
That would break the job to be done that sub is
        meant to enable, but would prevent correlation in practice AND
        it would allow for us to include a piece of info 

        that proved to be useful for a large portion of known cases. But
        to reiterate, even if this workaround would not be possible, 

        I would still be OK with admitting cross operation correlation
        within the same resource as by design.

    

    
...  and I hope you are also OK for admitting cross correlation
      of subjects between different resources. The question whether this
      was also done "by design" (or not) is left open.

    
Similar considerations apply for the client_id (client
      identifier) since RFC 6749 (2.2) states:

    
      The client identifier [i.e. a unique string representing
      the registration information provided by the client] is unique
        to the authorization server.

    

    
Denis

    

      


      

      


        

          
On Mon, Apr 13, 2020 at
            18:05 Dick Hardt <dick.hardt@gmail.com> wrote:

          

          

            

              

                


                

                


                

                


                

                
An SDK is going to support "sub" wether it is
                  required or optional. 

                


                

                


                

              

              

              

                
On Mon, Apr 13, 2020
                  at 1:40 PM Vittorio Bertocci <Vittorio@auth0.com>
                  wrote:

                

                

                  

                    
“Ide rockers” is iPhone autocorrect
                      jargon for “identifiers”, of course :P

                  

                  


                    

                      
On Mon, Apr 13,
                        2020 at 13:13 Vittorio Bertocci <Vittorio@auth0.com>
                        wrote:

                      

                      

                        

                          
It’s certainly possible to
                            conceive ATs without subs, but I think the
                            profile would be way less useful for SDK
                            developers.

                          
On the objections:

                          
The sub doesn’t have to be a
                            user, if you look at the earlier discussions
                            the case in which the token has been issued
                            for an application via client creds (hence
                            non user) has been debated at length.

                        

                        
Knowing the subject does not
                          necessarily lead to API being able to collide
                          and track users, given that the sub can be a
                          PPID that is different for every resource even
                          if the authenticated subject was the same.

                      

                    

                  

                

                


                

                
The privacy correlation I described is not solved
                  by a per resource directed identifier as the resource
                  is learning that the same user is doing different
                  transactions -- or per my example, the resource is
                  learning all the movies the user is seeing.

                
 

                

                  

                    

                      

                        


                        

                        
The
                            sub is mandatory here because it was present
                            in nearly every token among the ones
                            observed,

                      

                    

                  

                

                


                

                
But NOT every token. So there were use cases where
                  it was not required.

                
 

                

                  

                    

                      

                        
and although one should not
                          overindex on those scenarios, I took that as
                          strong indication that it is a frequently used
                          field and guaranteeing its presence
                          facilitates embedding in SDKs lots of
                          downstream features, such as correlating with
                          locally stored attributes, which would
                          otherwise left as exercise to the reader. 

                      

                    

                  

                

                


                

                
NOT correlating all the different actions by the
                  user may be the desired privacy goal by a deployment.

                
 

                

                  

                    

                      

                        
Per the points above, there are
                          no obvious downsides in requiring the presence
                          of the sub and significant upsides. Again, the
                          AS is in full control of the sub content hence
                          none of the privacy concerns mentioned here
                          are mandated by the sheer presence of the sub
                          claim. If you feel the privacy section should
                          be stronger in warning an AS against the
                          possibility of collusion if global ide rockers
                          are used, I am happy to reword accordingly 

                      

                    

                  

                

                


                

                
Per Aaron's comment, if this profile is NOT
                  intended to support use cases where the RS should not
                  be able to correlate a user between resource accesses,
                  then it is fine for "sub" to be required. If so, then
                  the document should strongly point that out. 

              

            

            

              

                
 

                

                  

                    

                      

                        


                          

                            
On Mon,
                              Apr 13, 2020 at 10:16 Aaron Parecki <aaron@parecki..com>
                              wrote:

                            

                            

                              

                                
This is a good point, I
                                  often use the hotel key analogy as
                                  well. The room door is the RS, the key
                                  is the access token, the door does not
                                  need to know who the user is in order
                                  to know if it’s okay to unlock given a
                                  particular key.

                              

                              


                              

                              
If sub is required, then
                                this profile is limited in use to cases
                                where user identifiers are part of the
                                system, and there will be situations in
                                which it’s not appropriate to use this
                                profile for access tokens. If that’s
                                okay, this should be clarified in the
                                overview section to describe when this
                                profile should be used.

                              


                              

                              
Aaron

                              


                              

                              


                              

                              


                                

                                  
On
                                    Mon, Apr 13, 2020 at 10:08 AM Dick
                                    Hardt <dick.hardt@gmail.com>
                                    wrote:

                                  

                                  

                                    
Why does the "sub"
                                      need to be required?
                                      


                                      

                                      
An access token is to prove
                                        authorization. The RS may not
                                        need "sub" to constrain
                                        fulfilling the client request. 

                                      


                                      

                                      
For example, it the access
                                        token has the same properties as
                                        a movie ticket, the RS does not
                                        need to have any identifier for
                                        who purchased the movie ticket. 

                                      


                                      

                                      
The privacy implication is
                                        the RS can correlate across API
                                        calls to know it is the same
                                        subject. 

                                      


                                      

                                      


                                      

                                      


                                      

                                    

                                    

                                    

                                      
On
                                        Mon, Apr 13, 2020 at 8:16 AM
                                        Denis <denis..ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Hello,

                                          


                                          

                                          
More on privacy about
                                            "JWT Profile for Access
                                            Tokens".

                                          


                                          

                                          
The current document
                                            REQUIRES the claim names sub
                                            and client_id.

                                          
    
                                            
  • sub  REQUIRED - as
                                              defined in section 4.1.2
                                              of [RFC7519]. 
    • 
                                            
  • client_id  REQUIRED - as
                                              defined in section 4.3 of
                                              [RFC8693]
    • 
                                          

                                          
1) sub 
                                              REQUIRED 

                                          


                                          

                                          
RFC 7519 states:

                                          

                                            
4.1.2.  "sub" (Subject)
                                              Claim

                                                 The "sub" (subject)
                                              claim identifies the
                                              principal that is the

                                                 subject of the JWT. 
                                              The claims in a JWT are
                                              normally statements

                                                 about the subject.  The
                                              subject value MUST either
                                              be scoped to 

                                                 be locally unique
                                                in the context of the
                                                issuer or be globally
                                                unique.

                                                 The processing of this
                                              claim is generally
                                              application specific.  The

                                                 "sub" value is a
                                              case-sensitive string
                                              containing a StringOrURI

                                                 value.  Use of this
                                                claim is OPTIONAL.

                                          

                                          
If sub is REQUIRED
                                            for this profile, then
                                            this allows all resource
                                            servers to link accesses
                                            made by the same client on
                                            different servers.

                                          


                                          

                                          
2) client_id  REQUIRED

                                          


                                          

                                          
RFC 8693 states: 

                                          

                                          

                                            
4.3. "client_id"
                                              (Client Identifier) Claim 

                                              The client_id claim
                                              carries the client
                                              identifier of the OAuth 2.0
                                              [RFC 6749] client that
                                              requested the token.

                                            

                                          

                                          
RFC 6749 states:

                                          

                                            
2.2.  Client Identifier

                                                 The authorization
                                              server issues the
                                              registered client a client

                                                 identifier -- a unique
                                              string representing the
                                              registration

                                                 information provided by
                                              the client.  The client
                                              identifier is not a

                                                 secret; it is exposed
                                              to the resource owner and
                                              MUST NOT be used

                                                 alone for client
                                              authentication.  The
                                                client identifier is
                                                unique to

                                                 the
                                                authorization server.

                                          

                                          
If client_id is
                                            REQUIRED for this profile,
                                            this also allows all
                                            resource servers to link
                                            accesses made by the same
                                            client on different servers.

                                          


                                          

                                          
Both claim names
                                              should be OPTIONAL to
                                            allow to support the privacy
                                            principle of unlinkability.

                                          


                                          

                                          
Would both names remain REQUIRED,
                                            the Privacy considerations
                                            section should mention that
                                            such a linkage by different
                                            resource servers 

                                            will always be possible when
                                            using this profile.

                                          

                                          


                                          

                                          
Denis

                                          


                                          

                                          

                                            
I have
                                              uploaded the second
                                              presentation for today's
                                              session, the JWT Profile
                                              for Access Tokens.
                                              
                                              


                                              

                                              
Regards,

                                              
 Rifaat

                                              
 

                                              

                                            

                                          

                                          

                                        

_______________________________________________

                                        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

                                  

                                

                              

                              -- 

                              

                                
----

                                
Aaron Parecki

                                
                                
                                


                                

                              

_______________________________________________

                              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


    

    


    

  


--------------015B1C8D56CC65AA69D38683--


From nobody Tue Apr 14 07:38:19 2020
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 192BD3A083B for ; Tue, 14 Apr 2020 07:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level: 
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, 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 UE-hIVuWwtTx for ; Tue, 14 Apr 2020 07:38:14 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34393A0837 for ; Tue, 14 Apr 2020 07:38:13 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d22 with ME id SeeB2200h4FMSmm03eeBRT; Tue, 14 Apr 2020 16:38:12 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 14 Apr 2020 16:38:12 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>   
From: Denis 
Message-ID: 
Date: Tue, 14 Apr 2020 16:38:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F3FA4650B46446CCED4B46F6"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 14:38:17 -0000

This is a multi-part message in MIME format.
--------------F3FA4650B46446CCED4B46F6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Vittorio, one comment in line.
> It’s certainly possible to conceive ATs without subs, but I think the 
> profile would be way less useful for SDK developers.
> On the objections:
> The sub doesn’t have to be a user, if you look at the earlier 
> discussions the case in which the token has been issued for an 
> application via client creds (hence non user) has been debated at length.
> Knowing the subject does not necessarily lead to API being able to 
> collide and track users, given that the sub can be a PPID that is 
> different for every resource even if the authenticated subject was the 
> same.
>
> The sub is mandatory here because it was present in nearly every token 
> among the ones observed, and although one should not overindex on 
> those scenarios, I took that as strong indication that it is a 
> frequently used field and guaranteeing its presence facilitates 
> embedding in SDKs lots of downstream features, such as correlating 
> with locally stored attributes, which would otherwise left as exercise 
> to the reader. Per the points above, there are no obvious downsides in 
> requiring the presence of the sub and significant upsides. Again, the 
> AS is in full control of the sub content hence none of the privacy 
> concerns mentioned here are mandated by the sheer presence of the sub 
> claim.

> If you feel the privacy section should be stronger in warning an AS 
> against the possibility of collusion if global ide rockers 
> [identifiers] are used, I am happy to reword accordingly.

Text needs to added into the Privacy consideration section stating more 
than that.

Since RFC 7519 (4.1.2) states:

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

the presence of the sub claim in a JWT allows (1) different resource 
servers to perform correlations of actions performed by the same subject
on these different resource servers and (2) a single resource server to 
perform inter-API correlations of actions performed by the same subject.
Since a single claim parameter is being used, it is not possible to have 
only one of the two previous cases.

Denis

>
> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki  > wrote:
>
>     This is a good point, I often use the hotel key analogy as well.
>     The room door is the RS, the key is the access token, the door
>     does not need to know who the user is in order to know if it’s
>     okay to unlock given a particular key.
>
>     If sub is required, then this profile is limited in use to cases
>     where user identifiers are part of the system, and there will be
>     situations in which it’s not appropriate to use this profile for
>     access tokens. If that’s okay, this should be clarified in the
>     overview section to describe when this profile should be used.
>
>     Aaron
>
>
>
>     On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt      > wrote:
>
>         Why does the "sub" need to be required?
>
>         An access token is to prove authorization. The RS may not need
>         "sub" to constrain fulfilling the client request.
>
>         For example, it the access token has the same properties as a
>         movie ticket, the RS does not need to have any identifier for
>         who purchased the movie ticket.
>
>         The privacy implication is the RS can correlate across API
>         calls to know it is the same subject.
>
>
>
>
>         On Mon, Apr 13, 2020 at 8:16 AM Denis          > wrote:
>
>             Hello,
>
>             More on privacy about "JWT Profile for Access Tokens".
>
>             The current document REQUIRES the claim names *sub* and
>             *client_id*.
>
>               * sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>               * client_id  REQUIRED - as defined in section 4.3 of
>                 [RFC8693]
>
>             *1) **sub  REQUIRED*
>
>             RFC 7519 states:
>
>                 4.1.2.  "sub" (Subject) Claim
>                    The "sub" (subject) claim identifies the principal
>                 that is the
>                    subject of the JWT.  The claims in a JWT are
>                 normally statements
>                    about the subject.  The subject value MUST either
>                 be scoped to**
>                 *be locally unique in the context of the issuer or be
>                 globally unique*.
>                    The processing of this claim is generally
>                 application specific.  The
>                    "sub" value is a case-sensitive string containing a
>                 StringOrURI
>                    value. *Use of this claim is OPTIONAL.*
>
>             If *sub *is *REQUIRED *for this profile, then this allows
>             all resource servers to link accesses made by the same
>             client on different servers.
>
>             *2) client_id  REQUIRED*
>
>             RFC 8693 states:
>
>                 4.3. "client_id" (Client Identifier) Claim
>                 The client_id claim carries the client identifier of
>                 the OAuth 2.0 [RFC 6749] client that requested the token.
>
>             RFC 6749 states:
>
>                 2.2.  Client Identifier
>                    The authorization server issues the registered
>                 client a client
>                    identifier -- a unique string representing the
>                 registration
>                    information provided by the client.  The client
>                 identifier is not a
>                    secret; it is exposed to the resource owner and
>                 MUST NOT be used
>                    alone for client authentication. *The client
>                 identifier is unique to**
>                 **   the authorization server.*
>
>             If *client_id* is REQUIRED for this profile, this also
>             allows all resource servers to link accesses made by the
>             same client on different servers.
>
>             *Both claim names should be OPTIONAL *to allow to support
>             the privacy principle of unlinkability.
>
>             Would both names remain *REQUIRED*, the Privacy
>             considerations section should mention that such a linkage
>             by different resource servers
>             will always be possible when using this profile.
>
>             Denis
>
>>             I have uploaded the second presentation for today's
>>             session, the JWT Profile for Access Tokens.
>>             https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>>
>>
>>             Regards,
>>              Rifaat
>>
>
>             _______________________________________________
>             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
>
>     -- 
>     ----
>     Aaron Parecki
>     aaronparecki.com 
>     @aaronpk 
>
>     _______________________________________________
>     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



--------------F3FA4650B46446CCED4B46F6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Vittorio, one comment in line.

    

      
      

        
It’s certainly possible to conceive ATs without
          subs, but I think the profile would be way less useful for SDK
          developers.

        
On the objections:

        
The sub doesn’t have to be a user, if you look
          at the earlier discussions the case in which the token has
          been issued for an application via client creds (hence non
          user) has been debated at length.

      

      
Knowing the subject does not necessarily lead to
        API being able to collide and track users, given that the sub
        can be a PPID that is different for every resource even if the
        authenticated subject was the same.

      


      

      
The sub is mandatory here because it was present
        in nearly every token among the ones observed, and although one
        should not overindex on those scenarios, I took that as strong
        indication that it is a frequently used field and guaranteeing
        its presence facilitates embedding in SDKs lots of downstream
        features, such as correlating with locally stored attributes,
        which would otherwise left as exercise to the reader. Per the
        points above, there are no obvious downsides in requiring the
        presence of the sub and significant upsides. Again, the AS is in
        full control of the sub content hence none of the privacy
        concerns mentioned here are mandated by the sheer presence of
        the sub claim. 

    

    

    

      
If you feel the privacy section should be stronger
        in warning an AS against the possibility of collusion if global
        ide rockers [identifiers] are used, I am happy to reword
        accordingly.

    

    
Text needs to added into the Privacy consideration section
      stating more than that.

    
Since RFC 7519 (4.1.2) states:

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

      

      the presence of the sub claim in a JWT allows (1) different
      resource servers to perform correlations of actions performed by
      the same subject 

      on these different resource servers and (2) a single resource
      server to perform inter-API correlations of actions performed by
      the same subject.

      Since a single claim parameter is being used, it is not possible
      to have only one of the two previous cases.

    

    
 Denis

    

    

      


        

          
On Mon, Apr 13, 2020 at
            10:16 Aaron Parecki <aaron@parecki.com> wrote:

          

          

            

              
This is a good point, I often use the
                hotel key analogy as well. The room door is the RS, the
                key is the access token, the door does not need to know
                who the user is in order to know if it’s okay to unlock
                given a particular key.

            

            


            

            
If sub is required, then this profile is
              limited in use to cases where user identifiers are part of
              the system, and there will be situations in which it’s not
              appropriate to use this profile for access tokens. If
              that’s okay, this should be clarified in the overview
              section to describe when this profile should be used.

            


            

            
Aaron

            


            

            


            

            


              

                
On Mon, Apr 13, 2020
                  at 10:08 AM Dick Hardt <dick.hardt@gmail.com>
                  wrote:

                

                

                  
Why does the "sub" need to be required?
                    


                    

                    
An access token is to prove authorization. The
                      RS may not need "sub" to constrain fulfilling the
                      client request. 

                    


                    

                    
For example, it the access token has the same
                      properties as a movie ticket, the RS does not need
                      to have any identifier for who purchased the movie
                      ticket. 

                    


                    

                    
The privacy implication is the RS can correlate
                      across API calls to know it is the same subject. 

                    


                    

                    


                    

                    


                    

                  

                  

                  

                    
On Mon, Apr 13,
                      2020 at 8:16 AM Denis <denis..ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hello,

                        


                        

                        
More on privacy about "JWT Profile for
                          Access Tokens".

                        


                        

                        
The current document REQUIRES the claim
                          names sub and client_id.

                        
    
                          
  • sub  REQUIRED - as defined in section
                            4.1.2 of [RFC7519]. 
    • 
                          
  • client_id  REQUIRED - as defined in
                            section 4.3 of [RFC8693]
    • 
                        

                        
1) sub  REQUIRED 

                        


                        

                        
RFC 7519 states:

                        

                          
4.1.2.  "sub" (Subject) Claim

                               The "sub" (subject) claim identifies the
                            principal that is the

                               subject of the JWT.  The claims in a JWT
                            are normally statements

                               about the subject.  The subject value
                            MUST either be scoped to 

                               be locally unique in the context of
                              the issuer or be globally unique.

                               The processing of this claim is generally
                            application specific.  The

                               "sub" value is a case-sensitive string
                            containing a StringOrURI

                               value.  Use of this claim is
                              OPTIONAL.

                        

                        
If sub is REQUIRED for
                          this profile, then this allows all resource
                          servers to link accesses made by the same
                          client on different servers.

                        


                        

                        
2) client_id  REQUIRED

                        


                        

                        
RFC 8693 states: 

                        

                        

                          
4.3. "client_id" (Client Identifier) Claim
                            

                            The client_id claim carries the client
                            identifier of the OAuth 2.0 [RFC 6749] client
                            that requested the token.

                          

                        

                        
RFC 6749 states:

                        

                          
2.2.  Client Identifier

                               The authorization server issues the
                            registered client a client

                               identifier -- a unique string
                            representing the registration

                               information provided by the client.  The
                            client identifier is not a

                               secret; it is exposed to the resource
                            owner and MUST NOT be used

                               alone for client authentication.  The
                              client identifier is unique to

                               the authorization server.

                        

                        
If client_id is REQUIRED for this
                          profile, this also allows all resource servers
                          to link accesses made by the same client on
                          different servers.

                        


                        

                        
Both claim names should be OPTIONAL to
                          allow to support the privacy principle of
                          unlinkability.

                        


                        

                        
Would both names remain REQUIRED,
                          the Privacy considerations section should
                          mention that such a linkage by different
                          resource servers 

                          will always be possible when using this
                          profile.

                        

                        


                        

                        
Denis

                        


                        

                        

                          
I have uploaded the second
                            presentation for today's session, the JWT
                            Profile for Access Tokens.
                            
                            


                            

                            
Regards,

                            
 Rifaat

                            
 

                            

                          

                        

                        

                      

                      _______________________________________________

                      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

                

              

            

            -- 

            

              
----

              
Aaron Parecki

              
              
              


              

            

            _______________________________________________

            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


    

    


    

  


--------------F3FA4650B46446CCED4B46F6--


From nobody Tue Apr 14 08:06:11 2020
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 28D423A08AE for ; Tue, 14 Apr 2020 08:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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=aol.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 NKYOnRJai9U5 for ; Tue, 14 Apr 2020 08:06:06 -0700 (PDT)
Received: from sonic310-51.consmr.mail.ne1.yahoo.com (sonic310-51.consmr.mail.ne1.yahoo.com [66.163.186.232]) (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 21DC33A0895 for ; Tue, 14 Apr 2020 08:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1586876765; bh=sxNybFAn29a5Nf7KloawQK/SgNl39danpJ5EMqJ0TEY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ik4czuzhKXXd2l2nY2tNtgdjNM1UEYgwnOQJ+Wlog1N9yZgtZ0ESwtIBbqxuIaifx2kXxXlxIbWpb26zyj4eClpdClkaFK5uBlFoVeVZ0ogvyAIdJ/CrQzRKN1lpT/btxXBIyC0Wao6+telIoiTpUJb31Gyf+NUxbonSUfWcdRuEmZP7a+ow3BUl7aJ0x6Kt0Ps6P2FQ3+RCZvcdeL74Fc//i8hA6LEkF5AefmKYrRq2QGWA4tRL0zU/qaeRD2Pb5hsRcfWccoBRvQYrQe72PNV2jDZo2nm7JKyStSNMI1TW4uJDfrQeCnx2YmMeHMvc6ulxbBK6VfMDliYuzKm6gA==
X-YMail-OSG: l0hBi7UVM1mxQ0ruzjDGm3Pfu2FuPdGYhPaDT9dG7swv5FVDMQiZ_G4XESs_84P F2nRO5sXghqhCPjwsnBVQJ4.b9iAkBk976hi7lKydhuMlSvw9YbxbNzpE47aCYRcR5unuY.pkfGT oA4ldqXNpZ6OodJQlW8UR2i7q71.z5nQrkG3skwK4T2elhcAd3XSK43YImhRdrLnKmvef_QcTJnZ 71G4TZ9fHP_Y_n5AxiMFUKFZNJe7jx7XEyD3nHfgozXa9G6RbuWXxCkaLlfVaHNIdPCGLojl25Ce A4Ki69lFF3jZjXwkY0M3nGMXAR1ZO42dR8PM_IzhMdpQBj9HiVvSzamE1bUODOxmen4wuiLauzoy B1tsW7kzNFQGVmvrSoZBveY4HgOYUg.2pLwoG3MWpMeLH9yQq65.Ju5Nd4_In9aFaX3iLyzu5_iL u5mIT6XxkSZFPTEkGuXyZh5H7qvoMiBUUhQJwKQzWEJRuRQpfKUO2RTdgu6O09S9xJ9eNTtIGJkL 0jk4Z6OHLfavHvFj8IrBGJ978ZySG34ZImP8GvpxvEB8gjvgWBYKTS_ep3hwiamF6FEJ5jOdwNPi tFVUj1b_gdblwYYmArpwhIgZs8QMw5zxAOL7IxbxrBp24y6O1QapBCJGgPIua4xZFG196dSooecV rzQz_S236f47d2X.2G49femWYLpqCOB80wikR8l30BG8QHAby8uatA8mGY6q6_HUM45ovRlxOSKb vsQPyaISIYGErNOX8qYuS6FAfLq4hw6bOLKygDaZgZMfKloydXn96uWQPj6aJBY1FEq_ICBWuIzK ZcVpJFru0o5WrWzBd4YCKH.UniGQ8gd9n2AXZdbZvXXKV_2jNjmDdolSYVB6HQ1Ht_oL.gwjhn5M gqEmSI8TqwScCBeukyTByfGifNTXsX6k2jYDmf4nILYv5QFQbYgXzx2rA.uOGF3dctmcI.l5POhp 5kVmYAXuFBMXNJS0SaW.WvPDCOiht96zI6BEdddgoKi51V3gX7ahW_PFYg3I7fu19dbqK8n7jVfa zYGIRgSd3bVTIbsrSmHtLFFloPIjjRtab0ojvN9GZ.4N.nWx3q1J2GviQAO2eplGncDJWTFettJt EfrfQ0EY9aDuCl.uV0goHKRwqJUPu21vV.SuGIwtZrlJMqc6ydwkj.eBknQu7NS5KLuTRFlfrKBX BfwfOHzuELSJ6i4ww2UMadzjs49VxCtkP31QmRTUi._hnRJxCcM3YDpzgxmdoVPRJxW34ZGh9dQn vls7O2CFjtjL_Spjyj88orB1xCHWrvMwSu2XThx6syNTMqLyxqHx2QzcpL22dZRjk99uu0wKoLTk vVT8GBqsJHey3K7XT0BJhZa6u8DplfCkcy0i4AYK1iw5BBXUgTnbTikfx_zRpCxjmNK7xKZsMZMX qj8HqGF3dhNHfdyHsTl73JREj1CMtAKeX2uth00RILmwZMr55dcRzn1TXMT69zbma3Kg-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 14 Apr 2020 15:06:05 +0000
Received: by smtp409.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ef0f770d42afa3ad08f6a0b23ecd63e2;  Tue, 14 Apr 2020 15:04:04 +0000 (UTC)
To: Denis , oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <871581ba-ab3e-da6f-90f2-083803defbea@aol.com>
Date: Tue, 14 Apr 2020 11:03:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <60478f63-257c-a05a-1587-505b9190205e@free.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 15:06:07 -0000

On 4/14/20 10:23 AM, Denis wrote:
> Unfortunately, this is not possible since RFC 7519 (4.1.2) states:
>
>         The subject value MUST either be scoped to be *locally unique 
> in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the 
solution Vittorio suggested. While for any token issued the 'sub' claim 
must be unique (local to the issuer or globally); that doesn't mean it 
can't be different with every issued token. This would require the 
client to request a new token before every API invocation but it would 
suffice to protect against the suggested privacy correlation issues.

Note that inter-API correlation prevention is VERY difficult and really 
requires a unique token for every API call as the token itself can be a 
correlation handle (e.g. hash the token and it becomes the correlation 
identifier if the token is being reused for multiple API calls).

Thanks,
George


From nobody Tue Apr 14 08:23:15 2020
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 E7DFC3A0901 for ; Tue, 14 Apr 2020 08:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 745rNSaNvTnw for ; Tue, 14 Apr 2020 08:23:11 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C173A08FF for ; Tue, 14 Apr 2020 08:23:10 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d22 with ME id SfP72200b4FMSmm03fP8Vq; Tue, 14 Apr 2020 17:23:09 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 14 Apr 2020 17:23:09 +0200
X-ME-IP: 86.238.65.197
To: George Fletcher , oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com>
From: Denis 
Message-ID: <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr>
Date: Tue, 14 Apr 2020 17:23:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <871581ba-ab3e-da6f-90f2-083803defbea@aol.com>
Content-Type: multipart/alternative; boundary="------------E0C604B01AC1B9F3E7F1C8F1"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 15:23:13 -0000

This is a multi-part message in MIME format.
--------------E0C604B01AC1B9F3E7F1C8F1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

George,

I disagree with you:

    The 'sub' claim must be unique (local to the issuer or globally)
    with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).

Denis

>
>
> On 4/14/20 10:23 AM, Denis wrote:
>> Unfortunately, this is not possible since RFC 7519 (4.1.2) states:
>>
>>         The subject value MUST either be scoped to be *locally unique 
>> in the context of the issuer or be globally unique*.
> Regarding this phrase from RFC 7519, I don't agree that it prevents 
> the solution Vittorio suggested. While for any token issued the 'sub' 
> claim must be unique (local to the issuer or globally); that doesn't 
> mean it can't be different with every issued token. This would require 
> the client to request a new token before every API invocation but it 
> would suffice to protect against the suggested privacy correlation 
> issues.
>
> Note that inter-API correlation prevention is VERY difficult and 
> really requires a unique token for every API call as the token itself 
> can be a correlation handle (e.g. hash the token and it becomes the 
> correlation identifier if the token is being reused for multiple API 
> calls).
>
> Thanks,
> George
>


--------------E0C604B01AC1B9F3E7F1C8F1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
George,

    


    

    
I disagree with you:

    

      
The 'sub' claim must be unique (local
        to the issuer or globally) with every issued token.

    

    
 In addition, inter-API correlation
      prevention does not necessarily require a unique token for every
      API call, 

      since in many cases a session can be opened and one JWT can be
      used during the whole session (during successive calls).

    


    

    
Denis

    

    

      

      

      On 4/14/20 10:23 AM, Denis wrote:
      

      
Unfortunately, this is not possible since
        RFC 7519 (4.1.2) states:
        

        

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

      

      Regarding this phrase from RFC 7519, I don't agree that it
      prevents the solution Vittorio suggested. While for any token
      issued the 'sub' claim must be unique (local to the issuer or
      globally); that doesn't mean it can't be different with every
      issued token. This would require the client to request a new token
      before every API invocation but it would suffice to protect
      against the suggested privacy correlation issues.
      

      

      Note that inter-API correlation prevention is VERY difficult and
      really requires a unique token for every API call as the token
      itself can be a correlation handle (e.g. hash the token and it
      becomes the correlation identifier if the token is being reused
      for multiple API calls).
      

      

      Thanks,
      

      George
      

      

    

    


    

  


--------------E0C604B01AC1B9F3E7F1C8F1--


From nobody Tue Apr 14 08:35:03 2020
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 2D8963A09AF for ; Tue, 14 Apr 2020 08:35:02 -0700 (PDT)
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, 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=aol.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 Bc_-27yqaS3a for ; Tue, 14 Apr 2020 08:35:01 -0700 (PDT)
Received: from sonic306-48.consmr.mail.ne1.yahoo.com (sonic306-48.consmr.mail.ne1.yahoo.com [66.163.189.110]) (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 E9F9E3A09AB for ; Tue, 14 Apr 2020 08:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1586878500; bh=VsB/AuEOCpxZGaGfC3FQ4ufsPiAg2UHGWriypjsNyPQ=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=lNqApaod/e87nCsOx1hapDAeggATAmozy2ixO00gjchGcJoIc31uS4tPOskaDcMIEqWNMnrJpW6YNUAuSXdqoHlVvE7J6hq03mFq5Y5ZT+rtd8n01qFqo3lPogOFv9AF4hQouVwuWjqXMM4rLbrYX3eKPtdwpYA8XWX/WQhkSTOXtgJnj+cmQwJiKAKQ92BWevU8MAItXo/+77hPBw/SxuaUb2YQq+yHgh2yWfKz2aMk2tc60Oyy+glKJceP8Ev0AqdoRNAJOsj75PlAQN+jSkIh7KDSyffm39QaakTaw8XdvVUZ7Vfe5+eYVTCHR8k8/Qpe/lkcQCx12JGZeSY87Q==
X-YMail-OSG: lsuUq6IVM1mxbyzMXeke05J6YDaxIjAFP5rUxRNNwfXRSC7ki0b0iBKP9rskxe8 pMyhPdCJ.S2SSdhQtyVjjNJm8yPcnMHcR_naq44KHJcV9oSNF6HfJwHDi2s8X5J28zZ71.C38m.j zziEsPgigj6Yq9W1bXJFio8WQejtnmh_C6K1sKE6eaqp.ige2HrEcmsG7vxhiYiIx_kaZQmn.AEi X355b5x1KjzgLaF1bNFz98aj9Kp45N9L07.qC6UT.N65eaA_UwWekcFp3gsTBXCHow8aHvBNOQev aQ8CekV.vowVlBoGXoEbC1IYr_69Mcgp8EJWlsYt5ZJLtVHsXIugdJa00ZCpKCgT_.KJcSjxoBIc UmrnAtVvUrpUcWZolSN.eT23x_p4tbIe05EmoPgZwbF4RCUZAgjWQXhiHMcAAoELw5NEk0Ev01He FUuyKhYZMffe3xa.GEdcgwZb0C7JehyB_cWeXDez2cdfN50Eicj4o5wxyboezT_h4jEMVG65M9Ns kewuHMcYWMV1Eh6GU6PWAFDdB1y8z43yeZ3S91k.xtguSbS7QgvUQkvlcyB54vdkmtAJMYDj3SOi lZiTIkhVuNRlK9rd0JZcFPBXJjaQp5JwFI_pz5bOgQx68hkCHJDrgtqvFhdFf0iUHTvYPKA4X05R jcO3Z0gS1y7raEpB_znaVqm8ml6OmmXPXxGM20zKMas4E.z0yHLqj6oYGsvMSCsIHUcfD6pyMz8N U1Kioe1ci0VOhqLk0I.x0V_GNUdHQrM78buFj8O.AlDMbTruLZTZdBp6MyoZbr0hDTU013.VJONH WwEwCok0NBurPrzgTH4C5HdNMb.rR8hNLN5P6KFJRVBwplGOq8PTHDOhNoQARK5fcnlzaViM2C1J weN1sMPpm3pHYS4SN94tV4..Qu3WqgeeVI3uRbwlclLoDheP.oLFN0wCrcpXqy6DbVpAXLrfLgu6 t_leJ0euAEh42yQtVNUwma7IRojo4Ct_I5mOSm56oi6aZV2uIX1_fHuyhojO4BYXToGg7LO7FJmm SgbbaPoRiHIdE5fI7pdoYe_XUHv_0IfDmjutaOuPOGbT76HJD_IpcZxtulbdwT.XSYIKF_8BblBf RPV4S67lSxIPZbDnplbHuAqXnwYcsLUQGHhFb_Z0p6v6LU1oMeD340VDSjpAOYApJ6wGWnOIV9Sz X_BBWmhTuS.I7H6mcpDifKTLFovywizv6ZwLSXXa38JLkoWlfveBxv_7okRBhIfrAwQlg6DbRQRp O.A5nGpHLeqP21M7rAH0xjPBDGBZs7WBE6BN7XzgvZIUHtOV_EaDVQhWUo0wYj9uXuKYSlEhA_8o funO5A1ur3TRCrbYy4xLPfUk2nkC3nVPDrYB3VrSPa8Fps098jm5dxiGlRKIpsEcJEGD9ZjZp6kj vrfwoVnSY0rS_hNNjbDvcrE60MK_mkbI.ZBNrCdjfX1gBzUW0RpiuY5QiFDs3.tKURjS9E7i0dTJ 4_9LoEVNMw_sIdOoC6NXkdC_FE98-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 14 Apr 2020 15:35:00 +0000
Received: by smtp422.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b7d1e069ae2a850e53e7517c9b5406a2;  Tue, 14 Apr 2020 15:32:58 +0000 (UTC)
To: Denis , oauth@ietf.org
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com> <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>
Date: Tue, 14 Apr 2020 11:32:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr>
Content-Type: multipart/alternative; boundary="------------453B4A82809C4733BBC4E04E"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 15:35:02 -0000

This is a multi-part message in MIME format.
--------------453B4A82809C4733BBC4E04E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Denis,

If the same token is used (within a session) for multiple API calls then 
all those API calls can be correlated together even if the token does 
not have a 'sub' claim because the token itself is the correlating 
identifier (same is true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after 
re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' 
value as "urn:anonymous:" and create a new value 
with every token that is issued. This is similar to how Shibboleth 
supports attribute based access control with SAML assertions. Given it 
appears we disagree in our interpretations of the spec, I'm fine 
agreeing to disagree :)

Thanks,
George

On 4/14/20 11:23 AM, Denis wrote:
> George,
>
> I disagree with you:
>
>    The 'sub' claim must be unique (local to the issuer or globally)
>    with every issued token.
>
> In addition, inter-API correlation prevention does not necessarily 
> require a unique token for every API call,
> since in many cases a session can be opened and one JWT can be used 
> during the whole session (during successive calls).
>
> Denis
>
>>
>>
>> On 4/14/20 10:23 AM, Denis wrote:
>>> Unfortunately, this is not possible since RFC 7519 (4.1.2) states:
>>>
>>>         The subject value MUST either be scoped to be *locally 
>>> unique in the context of the issuer or be globally unique*.
>> Regarding this phrase from RFC 7519, I don't agree that it prevents 
>> the solution Vittorio suggested. While for any token issued the 'sub' 
>> claim must be unique (local to the issuer or globally); that doesn't 
>> mean it can't be different with every issued token. This would 
>> require the client to request a new token before every API invocation 
>> but it would suffice to protect against the suggested privacy 
>> correlation issues.
>>
>> Note that inter-API correlation prevention is VERY difficult and 
>> really requires a unique token for every API call as the token itself 
>> can be a correlation handle (e.g. hash the token and it becomes the 
>> correlation identifier if the token is being reused for multiple API 
>> calls).
>>
>> Thanks,
>> George
>>


--------------453B4A82809C4733BBC4E04E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Denis,

      

      If the same token is used (within a session) for multiple API
      calls then all those API calls can be correlated together even if
      the token does not have a 'sub' claim because the token itself is
      the correlating identifier (same is true for the session
      identifier).

      

      In regards to the AS issuing a token with a 'sub' claim, after
      re-reading the spec (rfc 7519) I believe the AS could issue the
      'sub' value as "urn:anonymous:<large random number>" and
      create a new value with every token that is issued. This is
      similar to how Shibboleth supports attribute based access control
      with SAML assertions. Given it appears we disagree in our
      interpretations of the spec, I'm fine agreeing to disagree :)

      

      Thanks,

      George

    

    
On 4/14/20 11:23 AM, Denis wrote:

    

    
George,
      

      

      I disagree with you:
      

      

         The 'sub' claim must be unique (local to the issuer or
      globally)
      

         with every issued token.
      

      

      In addition, inter-API correlation prevention does not necessarily
      require a unique token for every API call,
      

      since in many cases a session can be opened and one JWT can be
      used during the whole session (during successive calls).
      

      

      Denis
      

      

      

        

        

        On 4/14/20 10:23 AM, Denis wrote:
        

        
Unfortunately, this is not possible
          since RFC 7519 (4.1.2) states:
          

          

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

        

        Regarding this phrase from RFC 7519, I don't agree that it
        prevents the solution Vittorio suggested. While for any token
        issued the 'sub' claim must be unique (local to the issuer or
        globally); that doesn't mean it can't be different with every
        issued token. This would require the client to request a new
        token before every API invocation but it would suffice to
        protect against the suggested privacy correlation issues.
        

        

        Note that inter-API correlation prevention is VERY difficult and
        really requires a unique token for every API call as the token
        itself can be a correlation handle (e.g. hash the token and it
        becomes the correlation identifier if the token is being reused
        for multiple API calls).
        

        

        Thanks,
        

        George
        

        

      

    

    

  


--------------453B4A82809C4733BBC4E04E--


From nobody Tue Apr 14 11:07:52 2020
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 B44AF3A08C1 for ; Tue, 14 Apr 2020 11:07:50 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 JpCDy_pbQACX for ; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 D7A0B3A08BB for ; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id w11so234178pga.12 for ; Tue, 14 Apr 2020 11:07:48 -0700 (PDT)
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 :mime-version; bh=3EcUr8ownSZObdFSDDTEXdrn3kiavKVZsVTii8lnnh4=; b=kl6QGYyJn9f2b0+E11agRxObac6Wqzs2T1zsizU+4QV0lsA7e1nWPgL58c+LL+5cwH oPL/p5bMeVWdcn6gksw4P6A2PhdVBpiw4EQkzoC+0Mh77/lFrtAnV26D0fhbRKv8Cn3w QiIJGtAJ7x4LTMILlO83WFyb30nCMrkWDfEdSuIRM8eHN/Ag1zbeNoOs9e1zEG/GrslL 3tLCSiIt+1zos9Nu+Bq6kvf0K6yDp5gKmt9zc+aqjvvFWPPJAqYq4fmPCcYi30273Y5p v9pbS65Vf3YtCLh/9puQesLAdx92a4YoTaVt+HpqTrLziFgBBNYclPf1tvcXNCY9rxku fW9g==
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 :mime-version; bh=3EcUr8ownSZObdFSDDTEXdrn3kiavKVZsVTii8lnnh4=; b=bEIZ3NMLuZncl3uTyKpk1RcUltFyW8QRqgHXobn2dAXB5t3/+knfCB0iok56eix8AA OgLBARNBj1vgYsIlyRZKCDWSxL4N5GOURppTCk+VEspMPXSXL6bFB886pPl5NU442odK B24QG/r1AQhkbUcOG5ZP9kz+xk+tuRK1o9VXnOf2U/fZdP2ATdZsmTUFEGSnIgxfsib2 dSVCoMPlG82f7L8z9GQ5y6gfz7d+QpMmwKxhEdik6KIwwkt+AW1U29E7G3/BESS+D1V/ WysmxckBpZeWYN3Bx3hknTw6lwwXjH6hbtEq4aBsmvNJpuf2T7S244XGEP8Uk+xBXENN WEkQ==
X-Gm-Message-State: AGi0PuZNGnf5Nq9af2X8axj86v++ItmxKZ2xdoebpGvPMI6+8EyELR74 lebpfwPy4NMlz+JMTJeZtfZQOw==
X-Google-Smtp-Source: APiQypLv8jINRCHT3kkXrbBKJPrehMfTLspp70Lv7nEaa32QJXBEzAKXZY+fMkGf5NIrxPdso8J8/A==
X-Received: by 2002:a62:3144:: with SMTP id x65mr15374868pfx.66.1586887667754;  Tue, 14 Apr 2020 11:07:47 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id r189sm10683159pgr.31.2020.04.14.11.07.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2020 11:07:42 -0700 (PDT)
From: Vittorio Bertocci 
To: George Fletcher , Denis , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
Thread-Index: ATM1ODU3+R1ahTgRmb+LKJAgdDe1pmdHaXc2QVdDQkMxNzY4MXdRYSthQWJFeFFnNFpiYWcrYi1Id1k2QlNRWkQzPWU5OGEzYTBmZGFkZTgxY2M0MTdhn/2gfK8=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 14 Apr 2020 18:07:41 +0000
Message-ID: 
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com> <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr> <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>
In-Reply-To: <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>
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_MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Tue, 14 Apr 2020 18:07:51 -0000

--_000_MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks George, you described exactly what I was thinking.
I agree with your conclusions throughout the thread. Now that we have JTI m=
andatory, preventing tracking intra-API could be achieved only by issuing a=
 new token for every transaction regardless of the presence of a sub, and a=
 sub whose values change at every issuance would achieve the same.
One subtlety that perhaps is worth spelling out is that =93unique=94 in thi=
s context shouldn=92t be interpreted as =93singleton=94. An identifier is u=
nique if it cannot be used to indicate any entity other than the intended o=
ne, but that doesn=92t prevent the same entity from having multiple unique =
identifiers as long as they all satisfy that uniqueness criterion. And agai=
n, I maintain that preventing intra-API tracking is a non-goal in most scen=
arios.

That said, this was a great discussion. I am going to add explicit language=
 in the privacy considerations warning readers about the possibility of cor=
relation, and hinting at some of the measures described here as possible mi=
tigations.
Thanks everyone!
V.

From: OAuth  on behalf of George Fletcher 
Date: Tuesday, April 14, 2020 at 08:35
To: Denis , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeti=
ng: 2020-04-13

Hi Denis,

If the same token is used (within a session) for multiple API calls then al=
l those API calls can be correlated together even if the token does not hav=
e a 'sub' claim because the token itself is the correlating identifier (sam=
e is true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after re-reading t=
he spec (rfc 7519) I believe the AS could issue the 'sub' value as "urn:ano=
nymous:" and create a new value with every token that =
is issued. This is similar to how Shibboleth supports attribute based acces=
s control with SAML assertions. Given it appears we disagree in our interpr=
etations of the spec, I'm fine agreeing to disagree :)

Thanks,
George
On 4/14/20 11:23 AM, Denis wrote:
George,

I disagree with you:

   The 'sub' claim must be unique (local to the issuer or globally)
   with every issued token.

In addition, inter-API correlation prevention does not necessarily require =
a unique token for every API call,
since in many cases a session can be opened and one JWT can be used during =
the whole session (during successive calls).

Denis




On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

        The subject value MUST either be scoped to be *locally unique in th=
e context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the sol=
ution Vittorio suggested. While for any token issued the 'sub' claim must b=
e unique (local to the issuer or globally); that doesn't mean it can't be d=
ifferent with every issued token. This would require the client to request =
a new token before every API invocation but it would suffice to protect aga=
inst the suggested privacy correlation issues.

Note that inter-API correlation prevention is VERY difficult and really req=
uires a unique token for every API call as the token itself can be a correl=
ation handle (e.g. hash the token and it becomes the correlation identifier=
 if the token is being reused for multiple API calls).

Thanks,
George



--_000_MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thanks George, you described exactly what I was thin=
king.


I agree with your conclusions throughout the thread.=
 Now that we have JTI mandatory, preventing tracking intra-API could be ach=
ieved only by issuing a new token for every transaction regardless of the p=
resence of a sub, and a sub whose
 values change at every issuance would achieve the same. 


One subtlety that perhaps is worth spelling out is t=
hat =93unique=94 in this context shouldn=92t be interpreted as =93singleton=
=94. An identifier is unique if it cannot be used to indicate any entity ot=
her than the intended one, but that doesn=92t
 prevent the same entity from having multiple unique identifiers as long as=
 they all satisfy that uniqueness criterion. And again, I maintain that pre=
venting intra-API tracking is a non-goal in most scenarios.



 


That said, this was a great discussion. I am going t=
o add explicit language in the privacy considerations warning readers about=
 the possibility of correlation, and hinting at some of the measures descri=
bed here as possible mitigations.



Thanks everyone!


V.


 




From=
: OAuth <oauth-b=
ounces@ietf.org> on behalf of George Fletcher <gffletch=3D40aol.com@d=
marc.ietf.org>

Date: Tuesday, April 14, 2020 at 08:35

To: Denis <denis.ietf@free.fr>, "oauth@ietf.org" <=
;oauth@ietf.org>

Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtua=
l Meeting: 2020-04-13






 




Hi Denis,



If the same token is used (within a session) for multiple API calls then al=
l those API calls can be correlated together even if the token does not hav=
e a 'sub' claim because the token itself is the correlating identifier (sam=
e is true for the session identifier).



In regards to the AS issuing a token with a 'sub' claim, after re-reading t=
he spec (rfc 7519) I believe the AS could issue the 'sub' value as "ur=
n:anonymous:<large random number>" and create a new value with e=
very token that is issued. This is similar to how
 Shibboleth supports attribute based access control with SAML assertions. G=
iven it appears we disagree in our interpretations of the spec, I'm fine ag=
reeing to disagree :)



Thanks,

George




On 4/14/20 11:23 AM, Denis wrote:






George, 



I disagree with you: 



   The 'sub' claim must be unique (local to the issuer or globall=
y) 

   with every issued token. 



In addition, inter-API correlation prevention does not necessarily require =
a unique token for every API call,


since in many cases a session can be opened and one JWT can be used during =
the whole session (during successive calls).




Denis 














On 4/14/20 10:23 AM, Denis wrote: 








Unfortunately, this is not possible since RFC 7519 (=
4.1.2) states:




        The subject value MUST either be=
 scoped to be *locally unique in the context of the issuer or be globally u=
nique*.





Regarding this phrase=
 from RFC 7519, I don't agree that it prevents the solution Vittorio sugges=
ted. While for any token issued the 'sub' claim must be unique (local to th=
e issuer or globally); that doesn't
 mean it can't be different with every issued token. This would require the=
 client to request a new token before every API invocation but it would suf=
fice to protect against the suggested privacy correlation issues.




Note that inter-API correlation prevention is VERY difficult and really req=
uires a unique token for every API call as the token itself can be a correl=
ation handle (e.g. hash the token and it becomes the correlation identifier=
 if the token is being reused for
 multiple API calls). 



Thanks, 

George 

















--_000_MWHPR19MB1501AB7EB499AECDC1D8001CAEDA0MWHPR19MB1501namp_--


From nobody Tue Apr 14 13:09:27 2020
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 630E03A0E58 for ; Tue, 14 Apr 2020 13:09:25 -0700 (PDT)
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=pingidentity.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 XozAUIJtJTvp for ; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 67F163A0E57 for ; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id f8so760824lfe.12 for ; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=UINN27jivH9itUltYAuBCuuevMjliSAF9ng4o5mUw3Y=; b=U6Hoa5llF3NX0bET8elGPoHRmD0eBr6Sauc/Y9NZXcK585o55k9ygpH8KPDA2xfaEl tX9dg0bmas/HUwKSW1cA0mtC5n0txk24tYH/A3gAsCFrg3HF8MqEWRsCqP7NkhI6oryR HacHBd0RpnYSKpSPLbOoUr+jFP0LnBjuJ31HQGhg9YiJQfq4a0EFw8dn3rTZAIgXuiTq CoRMhKYoLeOfI1Uv+8cB7zZfmuBHc8nP6W+RHc60cemHo1CE6F0zjq7O4fwhCqxqPbm7 s1Zan0jY9qkoZ3cNQy3zcOeXC94abVokm9vkC59oULgSCWedUEQvfeznFaD3Usfoi5wX CUHw==
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=UINN27jivH9itUltYAuBCuuevMjliSAF9ng4o5mUw3Y=; b=bwd4qdXIovqusigI4l2AktfFePumwtb5edaKiwTptbgBEfiXAmcyRrYRzVDfNhxyA+ nvMDfaF8I8XibBTfHLft6xO02jxmRfOZyCo1cJBYrjggrvax1m+F0QGNo71+c5HKNpYo nWx+a7/GF1ahK62KeG2QHXFLTEutVQu89JgnGk6x6zVGMKVOwKymxBuWHcQDoqKzpMpl dMNEzRuqb1jsTfz9gXFOUg/9vag0Af1hozYoq+fR2JAEwg5vqWFhIYo1L1E0xYVo4ARt 2naP7B6qflG3CUPtsZB+iqNz199uUn7U4fSxgUadhwQ6Oq9BV2Xa1JRXlzQVdhZX5ucp pJAQ==
X-Gm-Message-State: AGi0PuaB7TOXzvac2fYRVQAkMc7kiFzjgy4IpVG/MLNDcXj1QSZWyG/g QwSqQEvsQmKrfAMk30Zn59v4BZz3D7qZeOykLC9NCfK4FSRCAuauZw+LXxJ6goPsftC+uH53rc4 Nte+3FPfsLEcxa+g2
X-Google-Smtp-Source: APiQypKAT/PaASEwrk95WTMUiPom9mhm/+KzvoGeokJo+v9Z1VyEIqO9bkC9NqLR9ju7SR8orKvkCRHLp5xEOYJ/ZTk=
X-Received: by 2002:a19:40ca:: with SMTP id n193mr859178lfa.196.1586894960760;  Tue, 14 Apr 2020 13:09:20 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell 
Date: Tue, 14 Apr 2020 14:08:54 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000006ed44805a345c60e"
Archived-At: 
Subject: [OAUTH-WG] PAR and client metadata
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, 14 Apr 2020 20:09:25 -0000

--0000000000006ed44805a345c60e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Using PAR can facilitate improved security by giving clients a (relatively)
simple means for sending a confidential, integrity protected, and (for
confidential clients anyway) authenticated authorization request.

It seems like some of that improved security could be undermined by a
malicious actor somehow getting a user to navigate to a URL of a regular
old parameterized authorization request. One variation of the Mix-Up Attack
does this
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4=
.1
for example and email, social media, online forums, etc., are other ways a
user might be tricked into following a maliciously crafted link.

Following from that it seems logical that an authorization server might
want to restrict some clients from sending a regular parameterized
authorization request and instead require use of the PAR endpoint to
initiate an authorization request. Something like this could, of course, be
implemented as custom policy or configuration in any AS. But I'm thinking
it might be common enough to warrant adding a client metadata parameter to
the PAR draft specifically for it. The metadata (and registered extensions)
defined by Dynamic Client Registration [RFC7591] has come to imply a
general data model and expected associated behaviors for clients that is
useful for authorization server implementations, even when the Dynamic
Client Registration Protocol isn't directly in play. This particular
situation seems like a good potential candidate for a new such client
metadata parameter that would indicate that the given client can only use a
request_uri value obtained from the PAR endpoint to initiate an
authorization request. And that a regular old fashioned authorization
request from the given client would result in an error.

Do the folks of this fine WG think something like this would be a
worthwhile addition to the PAR draft?

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000006ed44805a345c60e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Using PAR can facilitate improved security by giving =
clients a (relatively) simple means for sending a confidential, integrity p=
rotected, and (for confidential clients anyway) authenticated authorization=
 request.

It seems like some of that improved secu=
rity could be undermined by a malicious actor somehow getting a user to nav=
igate to a URL of a regular old parameterized authorization request. One va=
riation of the Mix-Up Attack does this htt=
ps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1<=
/a> for example and email, social media, online forums, etc., are other way=
s a user might be tricked into following a maliciously crafted link.=C2=A0<=
/div>

Following from that it seems logical that an autho=
rization server might want to restrict some clients from sending a regular =
parameterized authorization request and instead require use of the PAR endp=
oint to initiate an authorization request. Something like this could, of co=
urse, be implemented as custom policy or configuration in any AS. But I'=
;m thinking it might be common enough to warrant adding a client metadata p=
arameter to the PAR draft specifically for it. The metadata (and registered=
 extensions) defined by  Dynamic Client Registration [RFC7591] has come to =
imply a general data model and expected associated behaviors for clients th=
at is useful for authorization server implementations, even when the Dynami=
c Client Registration Protocol isn't directly in play. This particular =
situation seems like a good potential candidate for a new such client metad=
ata parameter that would indicate that the given client can only use a requ=
est_uri value obtained from the PAR endpoint to initiate an authorization r=
equest. And that a regular old fashioned authorization request from the giv=
en client would result in an error. 

Do the fo=
lks of this fine WG think something like this would be a worthwhile additio=
n to the PAR draft?



<=
div>




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000006ed44805a345c60e--


From nobody Tue Apr 14 13:22:01 2020
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 11FC63A0EAC for ; Tue, 14 Apr 2020 13:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 UDoS3LARrJZw for ; Tue, 14 Apr 2020 13:21:58 -0700 (PDT)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) (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 0C0FD3A0EAA for ; Tue, 14 Apr 2020 13:21:57 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id OS4Bj1f86C3bYOS4CjgpZs; Tue, 14 Apr 2020 13:21:57 -0700
X-CMAE-Analysis: v=2.3 cv=NZSYKFL4 c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=hhYmk6OB3ath9ieCrv0A:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=8FXbpEt50JgLI2hA1oMA:9 a=v77YmzfvTsoNDJpf:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: 
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Tue, 14 Apr 2020 23:21:55 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050001070602020207040708"
X-CMAE-Envelope: MS4wfPPvObCwkK5fG3rC+YjfQNEGIKSvCUB4JVYB9ADC6F4zBU5nw9xcSROx3Vm/Nek8adbUF9yNhy+fkwLGq6f3ONdcTwuP2T5XMTGukj81+FIldXwiIWoo 93pNDjIZfD/xJZVR09+gUhOzerZB29cfxlNlYGWmWqCEqUq3f5SUBRdd
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 14 Apr 2020 20:22:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms050001070602020207040708
Content-Type: multipart/alternative;
 boundary="------------9953E1CBDBBE8FB9517FCB8F"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------9953E1CBDBBE8FB9517FCB8F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm all for that.

I suppose you have already thought of a suitable name? :)

Vladimir

On 14/04/2020 23:08, Brian Campbell wrote:
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity
> protected, and (for confidential clients anyway) authenticated
> authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a
> regular old parameterized authorization request. One variation of the
> Mix-Up Attack does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section=
-4.4.1
> for example and email, social media, online forums, etc., are other
> ways a user might be tricked into following a maliciously crafted link.=
=C2=A0
>
> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular
> parameterized authorization request and instead require use of the PAR
> endpoint to initiate an authorization request. Something like this
> could, of course, be implemented as custom policy or configuration in
> any AS. But I'm thinking it might be common enough to warrant adding a
> client metadata parameter to the PAR draft specifically for it. The
> metadata (and registered extensions) defined by Dynamic Client
> Registration [RFC7591] has come to imply a general data model and
> expected associated behaviors for clients that is useful for
> authorization server implementations, even when the Dynamic Client
> Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only
> use a request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited..=C2=A0 If you have received this communication in error, pl=
ease
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------9953E1CBDBBE8FB9517FCB8F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I'm all for that.

    
I suppose you have already thought of a suitable name? :)

    
Vladimir

    

    
On 14/04/2020 23:08, Brian Campbell
      wrote:

    

    

      
      

        
Using PAR can facilitate improved security by giving
          clients a (relatively) simple means for sending a
          confidential, integrity protected, and (for confidential
          clients anyway) authenticated authorization request.

        


        

        
        


        

        
Following from that it seems logical that an authorization
          server might want to restrict some clients from sending a
          regular parameterized authorization request and instead
          require use of the PAR endpoint to initiate an authorization
          request. Something like this could, of course, be implemented
          as custom policy or configuration in any AS. But I'm thinking
          it might be common enough to warrant adding a client metadata
          parameter to the PAR draft specifically for it. The metadata
          (and registered extensions) defined by Dynamic Client
          Registration [RFC7591] has come to imply a general data model
          and expected associated behaviors for clients that is useful
          for authorization server implementations, even when the
          Dynamic Client Registration Protocol isn't directly in play.
          This particular situation seems like a good potential
          candidate for a new such client metadata parameter that would
          indicate that the given client can only use a request_uri
          value obtained from the PAR endpoint to initiate an
          authorization request. And that a regular old fashioned
          authorization request from the given client would result in an
          error. 

        

        


        

        
Do the folks of this fine WG think something like this
          would be a worthwhile addition to the PAR draft?

        

        


        

        


        

        


        

        


        

      

      

      C=
ONFIDENTIALITY
            NOTICE: This email may contain confidential and privileged
            material for the sole use of the intended recipient(s). Any
            review, use, distribution or disclosure by others is
            strictly prohibited..=C2=A0 If you have received this
            communication in error, please notify the sender immediately
            by e-mail and delete the message and any file attachments
            from your computer. Thank you.
      

      

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


    

    

  


--------------9953E1CBDBBE8FB9517FCB8F--

--------------ms050001070602020207040708
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MTQyMDIxNTVaMC8G
CSqGSIb3DQEJBDEiBCDyByoruZSePDtOkscG+qwT9cAvZeD2bD4T1A53twTv/zBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBALOrF1Lfjq9HTPcTCSiLsNf3z85J/nC9lMtzT9LAeJeyM8Yl
MyZfVK//AMCS/FFJueqKIyLfsRXlfaCfXo1nwIevLucCyPjZs6FhmeRzelY8oJ6Rbr08aBL7
AU795h/KRqe8kmnvUo0K7e6WUgkXCD/vPFjBD/rxInkSobXixa0IWNj6JsGmQwAWjcLz6pAq
3He/vDVaJUSl3xKhhmoq3ucr4FLqdUadPlLEqXSdNYpfZZC/Q/mD/jqvIs0WXU0Eef2HPrSB
YAhKc5dzatpfCgW20hOKihzm0HIPiZd49VDiK794dqtmiCmr3jp5C0fiNv04OFHlkzHxPQPt
6nGJ3xcAAAAAAAA=
--------------ms050001070602020207040708--


From nobody Tue Apr 14 14:39:11 2020
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 60F8F3A1078 for ; Tue, 14 Apr 2020 14:39:09 -0700 (PDT)
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=pingidentity.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 G1DofTp6A9Sn for ; Tue, 14 Apr 2020 14:39:07 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 434913A107F for ; Tue, 14 Apr 2020 14:39:06 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id j14so964982lfg.9 for ; Tue, 14 Apr 2020 14:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vV/9B3xropFYwpZuzBwp8Owro/qkwgbT//Gc8RMqPBU=; b=BP/IEbb2m2jb3FIyepGTtQxpWGTFHuP0zR86SF0YKfcwo5PyXKVBaNJOqaAScgRfps tnBiwZeHLl9akswElZgf6NZJ7nXTogHvRVRqz1+9RVOE6JVSJCSawYMnfzHqTJdZf/0/ MOYWDiVkz9O2UjkVuHwgN0XzSc8gQSI8yC+mmcgcu9Q6rsYQUFLa71HNNUF0Poov8yYZ hs0JQurOHT9CxJJzKw4I2xZxIRJF/hN6hJB/3AEgLyDjZucbYQJ9J39Wl/kB9y4qmpcA mEOTwlQoMfKGjZPYGSv44OesYUuLCtY7XoZkxH3hKqTpQhb2fRDtY+f5XE3vMyXzBpRB KW5g==
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=vV/9B3xropFYwpZuzBwp8Owro/qkwgbT//Gc8RMqPBU=; b=oHJZ612+ZloJ3xkqtrR8FWFlDrC6qY72H3pHe53qDjxwyH2sL9H2KR+0wS/9HD5fKS itphJDRygO/HJDN7MiGAve9fGIkln+eZuJrRXQx/LWh0Exax3fItv1PGgKaVM8grfMHe Fq+vY9Ga433+hwLBnIrA+JIWWodj2b3Fk9ExZJeijMABKPKvBugSb/q1jd9G6EEwL3Gb n8ignLtt8RWyZxGs2uvyL/g3h3I+W5LFXXPap3n4npNDICeM46OPeJTxGdHtDsIOynOa xlSiw2b4Xp2z+SiQWnj/jWBhHNd57sy+K6FlrY0dW396aEJXIo8Zh0fpU8F4b25uhtYp GxAw==
X-Gm-Message-State: AGi0PuayOAKAcOichRTTR8OfNtxojKP55yT9zDuhLSbMduKGUeBUwx0X JGf0Afubq61foFKs6Qjd3W7OhgJ6p2hMADl/uFz34gR8rmGvhZSUrshL8V/lzLYBNoNhBAa6fL7 W5+tdpZiH1j5VoA==
X-Google-Smtp-Source: APiQypJAwX2N+tjDTLIcbfNxSc7GTPzTehsye81tS3Vdej06V+NRfCbwde9EbqIv0IgAIIj77dqisPwDYwFzoGKCC/k=
X-Received: by 2002:a05:6512:308c:: with SMTP id z12mr1031509lfd.195.1586900345049;  Tue, 14 Apr 2020 14:39:05 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 14 Apr 2020 15:38:38 -0600
Message-ID: 
To: Filip Skokan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000005c6a3605a347076d"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 14 Apr 2020 21:39:09 -0000

--0000000000005c6a3605a347076d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:

> I've wondered about the decision to use a new scheme before
>  but
> this time i'd like to challenge the immediate usability of the future spe=
c
> for one specific case - sender constraining public client Refresh Tokens.
>

I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?


>
> If at all, it is going to take time for RS implementations to recognize
> the new `DPoP` authorization scheme, let alone process it properly. In th=
e
> meantime, i'd still like to have the option to bind issued public client
> refresh tokens using DPoP without affecting the access tokens. In doing s=
o
> i get an immediate win in sender constraining the refresh tokens but not
> introducing a breaking change for the RS.
>
>
>    - Do you see this as something an AS implementation is just free to do
>    since it's both the issuer and recipient of a refresh token?
>
> That's my first thought, yes.


>
>    - Should this be somehow baked in the draft?
>
> I'm not sure. Do you think it needs to be? I'm not sure what it would say
though.

In such a case the AS could bind the RT to the given dpop proof and either
not bind the AT while returning token_type=3DBearer or bind the AT while
returning token_type value DPoP. In the latter case the AT would almost
certainly still work as a bearer token at the RS and the client that knew
the RS's needs could send it as such with an `Authorization: Bearer `.
Or if it didn't know the RS's needs, it could start with `Authorization:
DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
point it could send `Authorization: Bearer `.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.



>
>    - Do you think client registration metadata could be used to signal
>    such intent?
>
> I think it certainly could. But it seems maybe too specific to warrant
metadata.


>
>    - Do you think the protocol should have signals in the messages
>    themselves to say what the client wants to apply DPoP to?
>
> My initial thought here is no. Take the case of a client working with an
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.


>
>    - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
>    we disqualify such cases or allow for sending two proofs, one for the =
AS to
>    bind refresh tokens to, one for the RS to bind access tokens to?
>
> The AS is the one that does the binding (which includes checking the
proof) so I don't see how sending two proofs would really work or help the
situation?

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000005c6a3605a347076d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Filip, 

My attempts a=
t responses to your questions/comments are inline:

On Tue, Apr 14, 2020=
 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:



  • Do you=
 think client registration metadata could be used to signal such intent?
I think it certainly could. But it see=
ms maybe too specific to warrant metadata. 
=C2=A0
  • =
Do you think the protocol should have signals in the messages themselves to=
 say what the client wants to apply DPoP to?
My initial thought here is no. Take the case of a client working w=
ith an AS that supports DPoP and one RS that does and one RS that doesn'=
;t. I can't really even think what signaling might look like there or h=
ow it could be made to be generally useful.
=C2=A0
  • =
What if AS and RS don't have a shared support DPoP JWS Algorithm? Do we=
 disqualify such cases or allow for sending two proofs, one for the AS to b=
ind refresh tokens to, one for the RS to bind access tokens to?
The AS is the one that does the binding (which =
includes checking the proof) so I don't see how sending two proofs woul=
d really work or help the situation? 
=C2=A0




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000005c6a3605a347076d--


From nobody Tue Apr 14 14:43:56 2020
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 60E183A1095 for ; Tue, 14 Apr 2020 14:43:55 -0700 (PDT)
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=pingidentity.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 vSOtyBN0v9bQ for ; Tue, 14 Apr 2020 14:43:53 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 158E23A1092 for ; Tue, 14 Apr 2020 14:43:52 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r7so1410580ljg.13 for ; Tue, 14 Apr 2020 14:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1l5GC9vl/iBtAY2Sb9J6AruEzv+pfd9vhv/PfJtS8QU=; b=P/RUyBZ90UZRaWLlP6wuc8JDajFUc4uG4TTNSpzGH2fAPUsRTqw78liSD1KRKJmzSs VDN+DqAE+uLFZ2VjpYAzFUIVExX0mIpuD7500V2V4JW7o5avSI3g8MeijLRep22azRBI X3+/8ZbCEcA9sbNMcy3nRY70zfCV8+K+g6bEiXyGjfyYwXOrdfgc2BQWND00FMCMw3Nr 8tbXj5ZjZ3z6Qd+rnX/LO1Ls8Gmmqr/CIoYPl2QPCl+Yi5W4NddqmFyjd5jWRtov3Lf9 hdGmzsoHT1hHNtIKG3/LOlkAZTnu3HMaZvGjoLtcdzIvpDuAKc9QH72aOe8qshj/Q0SD A4+Q==
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=1l5GC9vl/iBtAY2Sb9J6AruEzv+pfd9vhv/PfJtS8QU=; b=DBnWptmJM7He3b9ukh35wr9EefQQ0IlWaF1QD151RnRmNri708uPduTMDug1nw8Vq8 u+g0TcdlJ1x9BaTp2tfQer6/8xmPKlod41P9u/gt3UYB32cLTlMhUV88sOjvrrGwcHxY g7y29rI8FJAtZGFhcPzMP3PtuT1r0Zweg3D5uzNb99u3KBQTL4oMsdAHdMHpQPHn8TQl YBnSWZ7Ao0iS0KfWaDyPP6S1edwNbfPG61HLfBu7c6dcxkPruqUk4BU5rkzKNZpnv0R3 mpjHyayzDRu84EkEth2vnZIB2AsTr421D8CSlj9gRH3uCMCpG//miOUN+XDke9eBZ+xm h7Pw==
X-Gm-Message-State: AGi0Pubfpp95wfaiW0dfhqRlqQiWNl77toMUzQALDI2fu2onSSK4C0F/ 2APE5TUbdnxUwuXRmDIQhm89mBc/HuzUvszJk7BhsNhd3zMwz//LJPr9t+5WeMoaR3qFxvSMQeP 17fpv0Zd6XBkEmTUSmB0=
X-Google-Smtp-Source: APiQypJzcEgfChrwYQPpOTCitmIdahHokUdlg0maMCJoTbvfVU1VINy+ZxTwU9JM+d4TWuEz+1zf4IXKAMHLG58zTXA=
X-Received: by 2002:a2e:2a85:: with SMTP id q127mr1243064ljq.273.1586900631133;  Tue, 14 Apr 2020 14:43:51 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 14 Apr 2020 15:43:24 -0600
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000069b91805a3471816"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 14 Apr 2020 21:43:55 -0000

--00000000000069b91805a3471816
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I was hoping to get to a rough consensus in support of the idea before
coming up with a name that everyone will hate :)

In the meantime, however, name suggestions are of course welcome.


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov 
wrote:

> I'm all for that.
>
> I suppose you have already thought of a suitable name? :)
>
> Vladimir
> On 14/04/2020 23:08, Brian Campbell wrote:
>
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected=
,
> and (for confidential clients anyway) authenticated authorization request=
.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Atta=
ck
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.4.1
> for example and email, social media, online forums, etc., are other ways =
a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, =
be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter t=
o
> the PAR draft specifically for it. The metadata (and registered extension=
s)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use=
 a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000069b91805a3471816
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I was hoping to get to a rough consensus in support o=
f the idea before coming up with a name that everyone will hate :) 

In the meantime, however, name suggestions are of cou=
rse welcome. 


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvin=
ov <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  

    
I'm all for that.

    
I suppose you have already thought of a suitable name? :)

    
Vladimir

    

    
On 14/04/2020 23:08, Brian Campbell
      wrote:

    

    

     =20
      

        
Using PAR can facilitate improved security by giving
          clients a (relatively) simple means for sending a
          confidential, integrity protected, and (for confidential
          clients anyway) authenticated authorization request.

        


        

        
        


        

        
Following from that it seems logical that an authorization
          server might want to restrict some clients from sending a
          regular parameterized authorization request and instead
          require use of the PAR endpoint to initiate an authorization
          request. Something like this could, of course, be implemented
          as custom policy or configuration in any AS. But I'm thinking
          it might be common enough to warrant adding a client metadata
          parameter to the PAR draft specifically for it. The metadata
          (and registered extensions) defined by Dynamic Client
          Registration [RFC7591] has come to imply a general data model
          and expected associated behaviors for clients that is useful
          for authorization server implementations, even when the
          Dynamic Client Registration Protocol isn't directly in play.
          This particular situation seems like a good potential
          candidate for a new such client metadata parameter that would
          indicate that the given client can only use a request_uri
          value obtained from the PAR endpoint to initiate an
          authorization request. And that a regular old fashioned
          authorization request from the given client would result in an
          error. 

        

        


        

        
Do the folks of this fine WG think something like this
          would be a worthwhile addition to the PAR draft?

        

        


        

        


        

        


        

        


        

      

      

      CONFIDENTIALITY
            NOTICE: This email may contain confidential and privileged
            material for the sole use of the intended recipient(s). Any
            review, use, distribution or disclosure by others is
            strictly prohibited..=C2=A0 If you have received this
            communication in error, please notify the sender immediately
            by e-mail and delete the message and any file attachments
            from your computer. Thank you.
      

      

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


    

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000069b91805a3471816--


From nobody Wed Apr 15 00:16:44 2020
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 C8CFB3A1050; Wed, 15 Apr 2020 00:16:39 -0700 (PDT)
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: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158693499975.13234.13839201717736831166@ietfa.amsl.com>
Date: Wed, 15 Apr 2020 00:16:39 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-06.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, 15 Apr 2020 07:16:40 -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-06.txt
	Pages           : 19
	Date            : 2020-04-15

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-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-06


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 Wed Apr 15 00:25:47 2020
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 DF5883A1077 for ; Wed, 15 Apr 2020 00:25:45 -0700 (PDT)
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 FKCtbHblKrP3 for ; Wed, 15 Apr 2020 00:25:44 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 3B1353A1075 for ; Wed, 15 Apr 2020 00:25:44 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id h11so925668plr.11 for ; Wed, 15 Apr 2020 00:25:44 -0700 (PDT)
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:accept-language:content-language:mime-version; bh=JGYMjKL1xyxjrXkuW9nSW/HtKFkvJhiqO23pMPCX1TE=; b=lBKSHCbhF6SfDPb5HaXaLYSREdjfWRjZjrdLBB0QmXrzmly+5EBMNpHP9JC9uqE1Rd 9Mdg2QLpwBtjRpHFBlwgHUDLzmnoZLdrsFY4zvi3aq13sqZVMqWglZ/jMMaEjpU7r+rf GzrxjxstalHPjNdGNxKrsdEVqyjMkWVXRo39gZsO1X4nwPXMeui6OCcBHDt20JqQ0P9Z isfIe5KLUw5OQNa7l2N3Q3xOgWCmGLYmS7Rrdq3eeJSScmaE9ALQPWbdPnC7bKVeE3Nc ZBW6uyd89KxdUGQSlHYHfnQMGhFP43KJ+eA/sN60q4eEkhfs76p3NIBgHe7TMRZj4Pby ChYQ==
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:accept-language:content-language:mime-version; bh=JGYMjKL1xyxjrXkuW9nSW/HtKFkvJhiqO23pMPCX1TE=; b=BG1xGhzPfLHGIHgp3k8Ujs8JxYeyA5dxHeQaqWKHZXhKTGVV0WsBwcvMzUhGoz8nk6 G9YYAdqfwJh+Bfz1F8QtOu2EnhrAj0plnX1q4C3tXPbBmiaWEhYBpMxJTUm1ILSuuFJn CaW87TX3BHkkZfYH5qKaVTExkuJ8uF9iwSWoyTeSz+WNxEThfPGh+7wz2YRdcR+a7ZEx fylm5hUcC0I5jZ6wRz+23EgZtlCAlwvQ4F3woKcwTXQEbf2xm0USFczgzNTkObopGWSu Subig+0LNIcYT6s4SCbQFD8C4HmNp2uUPlf6jFpMH02UI37sJHeYTh50CcwHLhySuLDH M7yA==
X-Gm-Message-State: AGi0PuYvvCtp26onuy1XGl3M7bqaym3sqoEI47i7Yc+L4PkQ1RhXDodL ucYQrTV6XFET8I8hAZqFwHwuPksIsB2DwZLatKpujGarwyC7iJtl3ncjFpYlYKcPjO74QLjfmnN x1PMexWK+/FxqtoQ4eqYbdd4cMM5EXYaHJ83F515cHEQDrlCtDQJLJ35/LC3jQ2y8eA==
X-Google-Smtp-Source: APiQypJk9t0LKtxWXTjIZPEJbbkNAMVgjb7AGGNRTxabjH8ZREJryDB8sVt4a4lKEBOz+pFIJKqYOw==
X-Received: by 2002:a17:90a:324f:: with SMTP id k73mr4786438pjb.195.1586935543015;  Wed, 15 Apr 2020 00:25:43 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id 203sm13136589pfz.217.2020.04.15.00.25.42 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 00:25:42 -0700 (PDT)
From: Vittorio Bertocci 
To: "oauth@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-oauth-access-token-jwt-06.txt
Thread-Index: ATc1NDMwsbLYfWauTuWBQ3go8g+ryA==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 15 Apr 2020 07:25:41 +0000
Message-ID: 
References: <158693500043.13234.5281466444356484617@ietfa.amsl.com>
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_MWHPR19MB1501E14E85781281CA327CC8AEDB0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-access-token-jwt-06.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: Wed, 15 Apr 2020 07:25:46 -0000

--_000_MWHPR19MB1501E14E85781281CA327CC8AEDB0MWHPR19MB1501namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIGNvbnN0cnVjdGl2ZSBkaXNjdXNzaW9u
cyBsZWFkaW5nIHRvLCBkdXJpbmcgYW5kIGZvbGxvd2luZyB0aGUgVmlydHVhbCBpbnRlcmltIG1l
ZXRpbmcgb24gTW9uZGF5Lg0KDQpJIHVwbG9hZGVkIGEgbmV3IGRyYWZ0IHJlZmxlY3RpbmcgdGhl
IGNoYW5nZXMgd2UgZGlzY3Vzc2VkLSBoZXJl4oCZcyBhIHN1bW1hcnk6DQoNCg0KDQpDaGFuZ2Vz
IGRpc2N1c3NlZCBkdXJpbmcgIHRoZSBpbnRlcmltIG1lZXRpbmc6DQoNCiAgIG8gIEluIFNlY3Rp
b24gMi4yLjM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNj
ZXNzLXRva2VuLWp3dC0wNiNzZWN0aW9uLTIuMi4zPiBhbmQgU2VjdGlvbiAzPGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDYjc2Vj
dGlvbi0zPiBlbGltaW5hdGVkIGxhbmd1YWdlIHByb2hpYml0aW5nIEpXVCBBVCByZXF1ZXN0cyBm
ZWF0dXJpbmcgbXVsdGlwbGUgcmVzb3VyY2VzLCBzdWJzdGl0dXRpbmcgaXQgd2l0aCB0aGUNCg0K
ICAgICAgcHJvaGliaXRpb24gZm9yIHRoZSBBUyB0byBlbWl0IEpXVCBBVHMgZXhwcmVzc2luZyBh
bWJpZ3VvdXMgYXV0aG9yaXphdGlvbiBncmFudHMuICBJbiBTZWN0aW9uIDU8aHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNiNzZWN0
aW9uLTU+LCBhZGRlZCBsYW5ndWFnZSB3YXJuaW5nIGFnYWluc3Qgc2NvcGUgY29uZnVzaW9uIGFu
ZCBtZW50aW9uZWQgdGhlIGV4aXN0ZW5jZSBvZiBvdGhlciBhbWJpZ3VvdXMgYXV0aG9yaXphdGlv
biBncmFudC4NCg0KICAgbyAgSW4gU2VjdGlvbiAyLjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNiNzZWN0aW9uLTIuMj4gcHJv
bW90ZWQgY2xhaW1zIGlhdCBhbmQganRpIGZyb20gUkVDT01NRU5ERUQgdG8gUkVRVUlSRUQuDQoN
Cg0KDQpDaGFuZ2VzIGZyb20gdGhlIHN1YnNlcXVlbnQgZm9sbG93IHVwczoNCg0KwrcgICAgICAg
ICBJbiBTZWN0aW9uIDIuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v
YXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2I3NlY3Rpb24tMi4yPiBhbmQgU2VjdGlvbiA2PGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3Qt
MDYjc2VjdGlvbi02PiBhZGRlZCBhIGRpc2N1c3Npb24gYWJvdXQgaG93IGRpZmZlcmVudCBzdWIg
dmFsdWVzIGFmZmVjdCB0aGUgcHJpdmFjeSBwcm9wZXJ0aWVzIG9mIGEgc29sdXRpb24uDQoNCg0K
DQpUaGFua3MNCg0KVi4NCg0KDQoNCg0KDQoNCg0KDQoNCu+7v09uIDQvMTUvMjAsIDAwOjE2LCAi
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90
ZToNCg0KDQoNCg0KDQogICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtb2F1dGgt
YWNjZXNzLXRva2VuLWp3dC0wNi50eHQNCg0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt
aXR0ZWQgYnkgVml0dG9yaW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0byB0aGUNCg0KICAgIElFVEYg
cmVwb3NpdG9yeS4NCg0KDQoNCiAgICBOYW1lOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dA0KDQogICAgUmV2aXNpb246ICAgICAg
ICAgIDA2DQoNCiAgICBUaXRsZTogICAgICAgICAgICAgICAgICBKU09OIFdlYiBUb2tlbiAoSldU
KSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2Vucw0KDQogICAgRG9jdW1lbnQgZGF0
ZTogICAgICAgICAgIDIwMjAtMDQtMTQNCg0KICAgIEdyb3VwOiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG9hdXRoDQoNCiAgICBQYWdlczogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTkNCg0KICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2LnR4dA0KDQogICAg
U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8NCg0KICAgIEh0bWxpemVkOiAgICAgICBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2
DQoNCiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QNCg0KICAgIERpZmY6ICAgICAg
ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC1h
Y2Nlc3MtdG9rZW4tand0LTA2DQoNCg0KDQogICAgQWJzdHJhY3Q6DQoNCiAgICAgICBUaGlzIHNw
ZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb2ZpbGUgZm9yIGlzc3VpbmcgT0F1dGggMi4wIGFjY2Vz
cw0KDQogICAgICAgdG9rZW5zIGluIEpTT04gd2ViIHRva2VuIChKV1QpIGZvcm1hdC4gIEF1dGhv
cml6YXRpb24gc2VydmVycyBhbmQNCg0KICAgICAgIHJlc291cmNlIHNlcnZlcnMgZnJvbSBkaWZm
ZXJlbnQgdmVuZG9ycyBjYW4gbGV2ZXJhZ2UgdGhpcyBwcm9maWxlIHRvDQoNCiAgICAgICBpc3N1
ZSBhbmQgY29uc3VtZSBhY2Nlc3MgdG9rZW5zIGluIGludGVyb3BlcmFibGUgbWFubmVyLg0KDQoN
Cg0KDQoNCg0KDQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg
b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCg0KICAgIHVudGlsIHRoZSBo
dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu
DQoNCg0KDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQoNCg==

--_000_MWHPR19MB1501E14E85781281CA327CC8AEDB0MWHPR19MB1501namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp
bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxl
LW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy
ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw
YW4uZ3JleQ0KCXttc28tc3R5bGUtbmFtZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w
aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5
MjAyNTkwNDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz
OjEwOTE1OTM3MzIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg
Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K
dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVhciBhbGwsPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgYWdhaW4gZm9yIHRoZSBjb25z
dHJ1Y3RpdmUgZGlzY3Vzc2lvbnMgbGVhZGluZyB0bywgZHVyaW5nIGFuZCBmb2xsb3dpbmcgdGhl
IFZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIE1vbmRheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPkkgdXBsb2FkZWQgYSBuZXcgZHJhZnQgcmVmbGVjdGluZyB0aGUg
Y2hhbmdlcyB3ZSBkaXNjdXNzZWQtIGhlcmXigJlzIGEgc3VtbWFyeToNCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij5DaGFuZ2VzIGRpc2N1c3NlZCBkdXJpbmcgJm5ic3A7dGhlIGludGVy
aW0gbWVldGluZzo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2I3NlY3Rpb24tMi4yLjMi
PlNlY3Rpb24gMi4yLjM8L2E+IGFuZCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2I3NlY3Rpb24tMyI+U2VjdGlv
biAzPC9hPiBlbGltaW5hdGVkIGxhbmd1YWdlIHByb2hpYml0aW5nIEpXVCBBVCByZXF1ZXN0cyBm
ZWF0dXJpbmcgbXVsdGlwbGUgcmVzb3VyY2VzLCBzdWJzdGl0dXRpbmcgaXQgd2l0aCB0aGU8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvaGliaXRpb24gZm9yIHRoZSBBUyB0byBlbWl0
IEpXVCBBVHMgZXhwcmVzc2luZyBhbWJpZ3VvdXMgYXV0aG9yaXphdGlvbiBncmFudHMuJm5ic3A7
IEluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo
LWFjY2Vzcy10b2tlbi1qd3QtMDYjc2VjdGlvbi01Ij5TZWN0aW9uIDU8L2E+LCBhZGRlZCBsYW5n
dWFnZSB3YXJuaW5nIGFnYWluc3Qgc2NvcGUgY29uZnVzaW9uIGFuZCBtZW50aW9uZWQgdGhlIGV4
aXN0ZW5jZSBvZiBvdGhlciBhbWJpZ3VvdXMgYXV0aG9yaXphdGlvbiBncmFudC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsgbyZuYnNwOyBJbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2I3NlY3Rpb24tMi4yIj5TZWN0aW9uIDIuMjwv
YT4gcHJvbW90ZWQgY2xhaW1zIGlhdCBhbmQganRpIGZyb20gUkVDT01NRU5ERUQgdG8gUkVRVUlS
RUQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNoYW5nZXMgZnJvbSB0
aGUgc3Vic2VxdWVudCBmb2xsb3cgdXBzOjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi
PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2w7Y29s
b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv
bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k
aWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNiNzZWN0aW9u
LTIuMiI+U2VjdGlvbiAyLjI8L2E+IGFuZCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2I3NlY3Rpb24tNiI+U2Vj
dGlvbiA2PC9hPiBhZGRlZCBhIGRpc2N1c3Npb24gYWJvdXQgaG93IGRpZmZlcmVudCBzdWIgdmFs
dWVzIGFmZmVjdCB0aGUgcHJpdmFjeSBwcm9wZXJ0aWVzIG9mIGEgc29sdXRpb24uPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Vi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+77u/T24gNC8xNS8yMCwgMDA6MTYsICZxdW90O2ludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZyZxdW90OyAmbHQ7aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnJmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRv
a2VuLWp3dC0wNi50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZpdHRv
cmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgUmV2aXNpb246
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA2
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsgVGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpT
T04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg
RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgMjAyMC0wNC0xNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYXV0aDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzOiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAxOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNi50eHQ8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0dXM6
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3
dC88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyBIdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0w
NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRv
a2VuLWp3dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IERpZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm
dC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Fic3RyYWN0OjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvZmlsZSBmb3Ig
aXNzdWluZyBPQXV0aCAyLjAgYWNjZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rZW5zIGluIEpT
T04gd2ViIHRva2VuIChKV1QpIGZvcm1hdC4mbmJzcDsgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFu
ZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNlIHNlcnZlcnMgZnJvbSBkaWZmZXJlbnQgdmVu
ZG9ycyBjYW4gbGV2ZXJhZ2UgdGhpcyBwcm9maWxlIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXNz
dWUgYW5kIGNvbnN1bWUgYWNjZXNzIHRva2VucyBpbiBpbnRlcm9wZXJhYmxlIG1hbm5lci48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO1BsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl
cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv
biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhl
IElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MWHPR19MB1501E14E85781281CA327CC8AEDB0MWHPR19MB1501namp_--


From nobody Wed Apr 15 00:37:25 2020
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 46BAD3A10B3 for ; Wed, 15 Apr 2020 00:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 Dpimd-QT3BI2 for ; Wed, 15 Apr 2020 00:37:22 -0700 (PDT)
Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (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 EF29C3A10B2 for ; Wed, 15 Apr 2020 00:37:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.72,386,1580734800";  d="scan'208,217";a="202260090"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipodni.tcif.telstra.com.au with ESMTP; 15 Apr 2020 17:37:18 +1000
Received: from wsapp5585.srv.dir.telstra.com ([10.75.3.67]) by ipcbni.tcif.telstra.com.au with ESMTP; 15 Apr 2020 17:37:18 +1000
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 17:37:18 +1000
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 15 Apr 2020 17:37:18 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gZoMbAcFsm4Xx18TrD0TW2246EO1mkxzc/0UXEy5Ot1MGEke6OxfQWLSd0Pq01XJtoJpzzUwXoi0kwSiG27FXeb8YwgDpYbgrPhk9JcXwtuQkMsUXajKGKa74Q7oRmbS/+Hyz7goKKSXPokHXhmqGgGbMI5FWSkeV4ul6Yc876JG4D98hNCW7ik3a/Q3RXrgB517LxNeA1BYe/KZVMOHNgNkplDEXLNbUnNQVGz28fwoGsuFd/33QMg5uTKSKHYgklwSVzO3cWaAlXHcdC8f7ICulgMYTHS6fo9m/jCTyhG5Izmt7hEtlGCryw/ezwwSyP3ass/QCOm9T6jr3JTESQ==
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=jhxoNF7o1/6Cp1bAlf/6FGgNSLIgtLV6GoOXezGQ9yk=; b=BPprrT9/QklXQV/Eox1SjIF5lmiAkHAdQ0ikN7lgMYNWCDYvTFmqloJ19VEqGCyZTATct8H7ywAEQAnkLJXxNc9bq2Cyht83wv/caWJVbn3EhEjhycKwh7yrxn8LebFgiWN8LNB1w5NkqAGCilZu0qFRrpqhkDptOI45TwTv7Fpcn982usXktHazt5QdwKYv8lQLdin70ls/DLj1CMUEt8JP3ItKkdk16aKAP7Mw8J6eNApudi1IG3XtDpCvOkfjVnzadIgA6ZNPGgwDfDSN2h3cP5Euw5B/+1fmsWkkifODn7Qgyy20FxcJOVFnRR0sjcgei2PKIlj6QO8Bdj/Lsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jhxoNF7o1/6Cp1bAlf/6FGgNSLIgtLV6GoOXezGQ9yk=; b=vGVns0geSXykdsGgzx1Nf67q6ydTdeuE4I+uPxNJf9E8SykbxO2VUFHxsepTepdCBlHNJg05g4vLxLRUbLQokJgVP3a8L8VylXrHR3QS+5xx8bzgXP0VOCExHkpOLVIZ4Fy/x20CoTb00LcMk2o2onpxjj/xh0gG7ZjVeTu3ey4=
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com (10.175.216.7) by MEXPR01MB1144.ausprd01.prod.outlook.com (10.175.216.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.16; Wed, 15 Apr 2020 07:37:17 +0000
Received: from MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a]) by MEXPR01MB1702.ausprd01.prod.outlook.com ([fe80::4d7:1b54:6ee:bb6a%3]) with mapi id 15.20.2900.028; Wed, 15 Apr 2020 07:37:17 +0000
From: "Manger, James" 
To: Vittorio Bertocci , "George Fletcher" , Denis ,  "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
Thread-Index: AQHWDQVcWdAAu8TAS0ml2tCmjL0K/KhyX6QAgASBzACAAFExAIAAH2uAgAACN4CAADHOAIAAB1+AgABJ5QCAAF3KgIAAgT8AgAALawCAAAVegIAAArwAgAArP4CAAN9EIA==
Date: Wed, 15 Apr 2020 07:37:17 +0000
Message-ID: 
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com> <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr> <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com> 
In-Reply-To: 
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; 
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4e89fc14-3308-4c45-c00e-08d7e10fd2ec
x-ms-traffictypediagnostic: MEXPR01MB1144:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MEXPR01MB1702.ausprd01.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(10019020)(4636009)(346002)(376002)(396003)(136003)(366004)(39860400002)(86362001)(55016002)(2906002)(6506007)(110136005)(9686003)(5660300002)(7696005)(71200400001)(478600001)(8676002)(66476007)(66946007)(76116006)(316002)(26005)(8936002)(52536014)(66446008)(64756008)(66556008)(4744005)(81156014)(186003)(33656002); DIR:OUT; SFP:1102; 
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RTPmaqeTkTcSsHmHwGr+KtUuXTcIXlqARSEAF1WP5xNVLHFkHKRN6hHLfuQabsxefdmr+Q89SuSX73mcR8n5EWszCadtAqpWTN/1eTieQkEKUYngSNSIvxuYdEEDGIYHRMq8NTfz7kBBCvpkK6tWXg3ArK7qnxiDsMBoVJB/xm2M5pUfMbJBP1K04Pnx0sO8BMfZ/BkO6mkL9maLucKQILTb22K8x/2SiJ2ujiSXRgG9ZSYmOhzD4Dw6i2mcfPhXIH+8XX8+izSbuPUoaJAbx48TlTUVaXLsx1/GQsqXqgLMshwJXdcqU9g2eh4Ko48tx1nWtt6D5MqffilYsXUgH6gwbJTEQq/FoeoaPyxFMw345ouPZdZDK1VfxSxBJRE+B5OADqDXo4xCDBHUHKCWqNmDT9S9X3mkeWe5I5YLacKggqyucm3wK1B5aThZXOn1
x-ms-exchange-antispam-messagedata: zDgatB+4hBxxFsWdhkb5o4ArvDO580ANXUkOvFgXVgW7H6YwWLD4Uigwkl/ImOTs/iaPnRa2ILIQRgDfRm6/o7uQ75AOaCG9OY0I+eYtl+zdBaJY09+AbMtqtEyOcbisthjKWwECu97jSWxzIGNnbQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MEXPR01MB17027C2A7631B5623E1A1B6CE5DB0MEXPR01MB1702ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e89fc14-3308-4c45-c00e-08d7e10fd2ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 07:37:17.5094 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rQ2FbDSk2WBwkGPilU6LCejxJl3xMdRx0vVbaCt8nAl0ZzxKkhXcjICcs2skKaIhIQeO+tc+kXeITQwCyg/ZtomcYAoM4iqp3esB97gj9Pw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB1144
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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, 15 Apr 2020 07:37:24 -0000

--_000_MEXPR01MB17027C2A7631B5623E1A1B6CE5DB0MEXPR01MB1702ausp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> the AS could issue the 'sub' value as "urn:anonymous:" and create a new value with every token that is issued

But it those cases it would be better to omit "sub", instead of sending a p=
er-token value (we have "jti" as a per-token id). That at least avoids othe=
r parties misinterpreting these unusual "sub"s as long-term ids (and, for e=
xample, creating persistent user entries for each one).

--
James Manger


--_000_MEXPR01MB17027C2A7631B5623E1A1B6CE5DB0MEXPR01MB1702ausp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











> the AS could issue the 'sub' value as "urn:anonymous:<large ran=
dom number>" and create a new value with every token that is
 issued=



&nbs=
p;


But it th=
ose cases it would be better to
omit “sub”, instead of sending a per-token value (we hav=
e “jti” as a per-token id). That at least avoids other parties =
misinterpreting these unusual “sub”s as long-term ids (and, for=
 example, creating persistent user entries for each one).=



&nbs=
p;




--


James Manger






=
 








--_000_MEXPR01MB17027C2A7631B5623E1A1B6CE5DB0MEXPR01MB1702ausp_--


From nobody Wed Apr 15 01:39:14 2020
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 61B453A0598 for ; Wed, 15 Apr 2020 01:39:13 -0700 (PDT)
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 cvOlC70wc7Rd for ; Wed, 15 Apr 2020 01:39:09 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 2C4143A0597 for ; Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id z9so6391749pjd.2 for ; Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
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 :mime-version; bh=jSZMNTEUFd8xkqv35Ah/sCB79Zhpkm/tv+NIRgmwX+8=; b=dBGonPUGn7YuMLSwR7+urKwTHhNH6m7Ym2UjsVXLgzibuKYxIE6uwHaZgoTY/LMB3I R6ZrvDqTmi8f5TJGEGesSmkasJ0EH6vLDtenceBX4VOYr5IERD+2v3YMXCtPCYSfDzJJ R0Y6QyESvZJth1b4tLTrCwk+09I3U/7wzKyUux6bphPYTZ0081OUPxolD5c+DDYzV6Kj n8RAyVWh6AbKsUvqbmBfjU53ccKdLhwy2aHlYmv/uVkPLIeQ0v9IPRmjN8nLOKA691Z+ 0XFLBp7MrlVhk035W67sEJprHJbrDbUQAHA6+deFl2pQz+l/bt6Qht1L302z/oSVDz2Q cBLw==
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 :mime-version; bh=jSZMNTEUFd8xkqv35Ah/sCB79Zhpkm/tv+NIRgmwX+8=; b=AxOR4OxJIvGTAU5HpO1LM6KyBrnPKWXzLVAxgYSiNt+7TDjP0n8/MHleYCJy6y60+q CTmh0BaDJh0mKKcKwR0MwxWmTOrqxPiWE3ptUOzeOvBmnWQsVEKkE7MLhdt+vCZ0yaHI xwxqkot2OAUxwhhKzncMB40X+p9N0IIlCSfK/jlUg1bInBzgaGqTOxYXeESV2dxgbbGe DHiy9C9ktAny1dKg70flGSMziJUWoBoZUM/CLroJuPkGgK1nle0Jv/Jnsy4fn4L10Ip7 fwuBMg7hUqn6NpGscneXW73tfyu4nuvY8i6lnB8OLURQapYC2OvV0tF0oMK6w/nQOp4t AklQ==
X-Gm-Message-State: AGi0Pub/oTRKGSVA5icZQxPvCvJ2wzXsvYxur5wKypT+5SavaPq2vibj B2GujQcPcnz1v5p7l4G05KOcxA==
X-Google-Smtp-Source: APiQypIXVAAs2cdhSu6EexiaW+oyWuOd9u1oxoUxbNEUekv2u+2UZQwwvMQum0VlWftMKPf/dGXolw==
X-Received: by 2002:a17:902:bc8c:: with SMTP id bb12mr3707065plb.13.1586939948190;  Wed, 15 Apr 2020 01:39:08 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id w12sm6078865pfq.133.2020.04.15.01.39.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 01:39:07 -0700 (PDT)
From: Vittorio Bertocci 
To: "Manger, James" , George Fletcher , Denis , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
Thread-Index: AWM0MTdh96WvNEQ1hTaMCLRLrdsz1zAwQ0Ux5DwM14CAABFGyw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 15 Apr 2020 08:39:07 +0000
Message-ID: 
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>   <361d7891-01be-8e22-7765-613e727b2bc1@free.fr>       <60478f63-257c-a05a-1587-505b9190205e@free.fr> <871581ba-ab3e-da6f-90f2-083803defbea@aol.com> <32164a9c-c75c-14a4-d982-c55ee8ab0d1d@free.fr> <40ff7dfa-ddea-7798-0618-34454b5c7a4c@aol.com>  
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: multipart/alternative; boundary="_000_MWHPR19MB1501454E0BBCD5523A9BBBFDAEDB0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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, 15 Apr 2020 08:39:13 -0000

--_000_MWHPR19MB1501454E0BBCD5523A9BBBFDAEDB0MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks James!
If those scenarios would be an explicit target, then omitting the sub would=
 indeed eliminate any chance of misinterpreting. However those remain fairl=
y theoretical, and would already be pretty problematic in themselves given =
the need to get a new token per call in order to prevent jti based correlat=
ion- I don=92t think it=92s worth introducing in the spec the possibility t=
o omit the sub, and risk not having it when it=92s useful if it=92s omitted=
 by mistake in a mainstream scenario, to prevent a possible misinterpretati=
on in a less common scenario.
If you feel very strongly about this, we can complement the warning in the =
privacy considerations in draft-06 to highlight this scenario- but honestly=
 that seems overkill to me :)
Thanks
V.

From: "Manger, James" 
Date: Wednesday, April 15, 2020 at 00:37
To: Vittorio Bertocci , George Fletcher , Denis , "oauth@ietf.org" 
Subject: RE: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeti=
ng: 2020-04-13

> the AS could issue the 'sub' value as "urn:anonymous:" and create a new value with every token that is issued

But it those cases it would be better to omit =93sub=94, instead of sending=
 a per-token value (we have =93jti=94 as a per-token id). That at least avo=
ids other parties misinterpreting these unusual =93sub=94s as long-term ids=
 (and, for example, creating persistent user entries for each one).

--
James Manger


--_000_MWHPR19MB1501454E0BBCD5523A9BBBFDAEDB0MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thanks James!


If those scenarios would be an explicit target, then=
 omitting the sub would indeed eliminate any chance of misinterpreting. How=
ever those remain fairly theoretical, and would already be pretty problemat=
ic in themselves given the need to
 get a new token per call in order to prevent jti based correlation- I don=
=92t think it=92s worth introducing in the spec the possibility to omit the=
 sub, and risk not having it when it=92s useful if it=92s omitted by mistak=
e in a mainstream scenario, to prevent a
 possible misinterpretation in a less common scenario.


If you feel very strongly about this, we can complem=
ent the warning in the privacy considerations in draft-06 to highlight this=
 scenario- but honestly that seems overkill to me :)


Thanks


V.


 




From=
: "Manger, Jam=
es" <James.H.Manger@team.telstra.com>

Date: Wednesday, April 15, 2020 at 00:37

To: Vittorio Bertocci <vittorio.bertocci@auth0.com>, George Fl=
etcher <gffletch@aol.com>, Denis <denis.ietf@free.fr>, "oa=
uth@ietf.org" <oauth@ietf.org>

Subject: RE: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtua=
l Meeting: 2020-04-13






 






> the AS co=
uld issue the 'sub' value as "urn:anonymous:<large random number>=
;" and create a new value with every token that is issued<=
/o:p>


 


But it those cases it would be better to omit=
 =93sub=94, instead of sending a per-token value (we have =93jti=94 as a pe=
r-token id). That at least avoids other parties misinterpreting these unusu=
al =93sub=94s as long-term ids (and, for example,
 creating persistent user entries for each one).


 




--


James Manger






 










--_000_MWHPR19MB1501454E0BBCD5523A9BBBFDAEDB0MWHPR19MB1501namp_--


From nobody Wed Apr 15 11:59:18 2020
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 F14BC3A0542 for ; Wed, 15 Apr 2020 11:59:16 -0700 (PDT)
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 0iySGdi0IqNh for ; Wed, 15 Apr 2020 11:59:15 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 BA34B3A07AA for ; Wed, 15 Apr 2020 11:59:11 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id i75so4375717ild.13 for ; Wed, 15 Apr 2020 11:59:11 -0700 (PDT)
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=3QzGRi2p2LTZ9Bdbm0irt+PtCl3O0aCM08fFg310hIs=; b=r3jlEHrUHqp7gE5WaIJROY7Af/pkgqVYGIEBA7DTA3QJW7KcZJiN9CXvG71HAikWda 2rpu/rMGWCIeEyYx3fITEudtmq419g4afyfguymRlMwPo4SJRYCzmKiuleQ7LYemuoRH uXT/Ohkm+30XL6G9b+lR8IpaZXK+HY7t6BE9YOrdcbLRGiBHVxVZDrZmHDMnx8PuqE91 f11tS8PFhBlKZfIrGxwxL8Aa/paxnDw5h7feu7V6wjskVAClIcUuJmOll2mC48dQy1Ih Iak6xAaUkQtoIuIeGPGPYW/IwYxr5+qTUUW/MSMKa1hAFYQv6+MqPVJXUTOb1q3LdnNt y7lw==
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=3QzGRi2p2LTZ9Bdbm0irt+PtCl3O0aCM08fFg310hIs=; b=l61UK2eOpkMZjjeGh/PfyUT9FVyqdnITuWFh5UeQVaYK/b1EKqYrFWlwdeSFjxhzL7 YPGbkCQvC1Vq6UNz7JZwtDuaRLvny1+RdKxlzIlNTEDHkIg3MfU9LO5Mkp0VQSXTKp1D r2VS0opWzagg8X21Du01VwoFVzuYUU7MKM+/IDhsYsINEWhB5FSHZeM8EH0eRlOayCFm ca+BnRdOKt+FD430zI5XesVIY8hmt2lCKVuXWQYVCXC8ebqZ7mOk18hUwStQUnJ4jQrV io9g4Q92A+K8grDA/RNU0I2NePZ2li4ITA1kxRNA39ZXb1lw8GbAz7ex2LxRovqItY2Q sALQ==
X-Gm-Message-State: AGi0PubZO9iFSZso53Qd3NlgvNHQ7qEvlA9BqXGm3UsFpeT2Qj93NZDw Gx6Hkd5o10zf0XLbvna+Qvb/IEima57wGTz+BewneHIjZ5LqnA==
X-Google-Smtp-Source: APiQypIyR/6HmsmSNCEpA4+K3dEvVgjjFm3m6anNIkKb3Nxntw4qZdlS4LwwZrPOxWEZ9hrSL4D37g5KTDCuMD1QmSw=
X-Received: by 2002:a92:d90d:: with SMTP id s13mr7315927iln.255.1586977150612;  Wed, 15 Apr 2020 11:59:10 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Wed, 15 Apr 2020 14:59:00 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000054481f05a358e976"
Archived-At: 
Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 15 Apr 2020 18:59:17 -0000

--00000000000054481f05a358e976
Content-Type: text/plain; charset="UTF-8"

Hi all,



This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



Please send your comments to the OAuth mailing list by April 29, 2020.



Regards,

 Rifaat & Hannes

--00000000000054481f05a358e976
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://tools.ietf.org/html/=
draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0


--00000000000054481f05a358e976--


From nobody Wed Apr 15 12:44:24 2020
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 9D61F3A0897 for ; Wed, 15 Apr 2020 12:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.766
X-Spam-Level: 
X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 Ps0DmO_BDlQn for ; Wed, 15 Apr 2020 12:44:20 -0700 (PDT)
Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 7B1533A0895 for ; Wed, 15 Apr 2020 12:44:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1586979861; x=1618515861; h=from:to:cc:date:message-id:mime-version:subject; bh=iIVyPEAIkjm4iH5UyNJTTVwLROj8WOnfvSk2j+tp0tU=; b=i8eWld164clyfqu21rrz++UpZi992RlT3JlG3DSgYU6fM1AdG5o/m5sG eC4VX5a1aUVgIfFN46OpZIFDwaysV0DapOpWZlp6hqxwH2ENotYQtUFCf 0xag6oMdPyAPOO3D1pHAU1kZsRNMTDhonik4laUWTr0J7YcIiIu2gwecK M=;
IronPort-SDR: JxJBFZH9wn3DX3sc7T+/+HnKHvuyWNbuk07hHqWL2mqTeLNl9yWF+l/NPZTNoj/7JbqNyD62Ua JRk0K3OIR1mg==
X-IronPort-AV: E=Sophos; i="5.72,388,1580774400"; d="scan'208,217"; a="25641920"
Thread-Topic: [OAUTH-WG] PAR and client metadata
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 15 Apr 2020 19:43:49 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 6DC99A2043; Wed, 15 Apr 2020 19:43:46 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 19:43:45 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 19:43:45 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Wed, 15 Apr 2020 19:43:44 +0000
From: "Richard Backman, Annabelle" 
To: Brian Campbell 
CC: Vladimir Dzhuvinov , oauth 
Thread-Index: AQHWE14smwhXrB6IvU2ReCcw9fGtqw==
Date: Wed, 15 Apr 2020 19:43:44 +0000
Message-ID: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_760B73F1F31C4474887128EEBCF45D44amazoncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 15 Apr 2020 19:44:23 -0000

--_000_760B73F1F31C4474887128EEBCF45D44amazoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgSSB0aGluayB0aHJvdWdoIHRoaXMsIEnigJltIHN0cnVnZ2xpbmcgdG8gaWRlbnRpZnkgdGhl
IHRocmVhdHMgdGhpcyBhY3R1YWxseSBoZWxwcyBtaXRpZ2F0ZS4NCg0KQSBjbGllbnQgbWV0YWRh
dGEgcGFyYW1ldGVyIGltcGxpZXMgdGhhdCB0aGUgdmFsdWUgbWF5IGJlIGRpZmZlcmVudCBmb3Ig
ZGlmZmVyZW50IGNsaWVudHMsIGFuZCB0aGF0IGFueSBnaXZlbiBjbGllbnQgd29u4oCZdCBhbHJl
YWR5IGtub3cgdmlhIG90aGVyIG1lYW5zIHdoZXRoZXIgb3Igbm90IGl0IG5lZWRzIHRvIHVzZSBQ
QVIuIFRoYXQgbWVhbnMgd2XigJlyZSBvbmx5IHRhbGtpbmcgYWJvdXQgZHluYW1pYyBjbGllbnRz
IHNpbmNlIHN0YXRpY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnRzIGFscmVhZHkgaGF2ZSBzb21lIHBy
b3ByaWV0YXJ5IG91dC1vZi1iYW5kIHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20gKGUuZy4sIGEgZGV2
ZWxvcGVyIGNvbnNvbGUpLg0KDQpBIGNsaWVudCBtZXRhZGF0YSBwYXJhbWV0ZXIgYWxzbyBpbXBs
aWVzIHRoYXQgdGhlIEFTIGFsbG93cyBzb21lIGNsaWVudHMgdG8gbWFrZSBub24tUEFSIHJlcXVl
c3RzIChvdGhlcndpc2UgaXQgd291bGQgYmUgYW4gQVMgbWV0YWRhdGEgcGFyYW1ldGVyKS4gSWYg
dGhhdOKAmXMgdGhlIGNhc2UgdGhlbiBwcmVzdW1hYmx5IGEgbWFsaWNpb3VzIHBhcnR5IGNvdWxk
IHJlZ2lzdGVyIHRoZWlyIG93biBjbGllbnQgdGhhdCBkb2VzbuKAmXQgdXNlIFBBUi4NCg0KU28g
aXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgb25seSBzY2VuYXJpbyB0aGF0IHRoaXMgcGFyYW1ldGVy
IHdvdWxkIHByb3RlY3QgYWdhaW5zdCBpcyBhIG1hbGljaW91cyBwYXJ0eSBpbXBlcnNvbmF0aW5n
IGEgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnQgdGhhdCB1c2VzIFBBUi4gVGhhdCB3b3Vs
ZG7igJl0IGFwcGx5IHRvIE1peC1VcCwgc2luY2UgaW4gdGhhdCBhdHRhY2sgdGhlIGF0dGFja2Vy
IHVzZXMgaXRzIG93biBjbGllbnQuDQoNCklmIGEgY2xpZW50IGNhbiBkbyBQQVIsIHRoZW4gaXQg
Y2FuIGRvIGF1dGhvcml6YXRpb24gY29kZSBncmFudCBhbmQgUEtDRSwgc28gd2XigJlyZSBmdXJ0
aGVyIGxpbWl0ZWQgdG8gc2NlbmFyaW9zIHdoZXJlIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBuZWVk
IHRvIGJlIGFibGUgdG8gcmVkZWVtIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdGhlbXNlbHZlcy4g
V2hhdCB0aHJlYXRzIGZhbGwgaW50byB0aGlzIGNhdGVnb3J5Pw0KDQrigJQNCkFubmFiZWxsZSBC
YWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQoNCk9uIEFwciAxNCwgMjAyMCwgYXQgMjo0
NCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMu
aWV0Zi5vcmc+IHdyb3RlOg0KDQrvu78NCg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVk
IGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Ig
b3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtu
b3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQpJIHdhcyBob3BpbmcgdG8gZ2V0IHRvIGEgcm91
Z2ggY29uc2Vuc3VzIGluIHN1cHBvcnQgb2YgdGhlIGlkZWEgYmVmb3JlIGNvbWluZyB1cCB3aXRo
IGEgbmFtZSB0aGF0IGV2ZXJ5b25lIHdpbGwgaGF0ZSA6KQ0KDQpJbiB0aGUgbWVhbnRpbWUsIGhv
d2V2ZXIsIG5hbWUgc3VnZ2VzdGlvbnMgYXJlIG9mIGNvdXJzZSB3ZWxjb21lLg0KDQoNCk9uIFR1
ZSwgQXByIDE0LCAyMDIwIGF0IDI6MjIgUE0gVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBj
b25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+PiB3cm90ZToNCg0K
SSdtIGFsbCBmb3IgdGhhdC4NCg0KSSBzdXBwb3NlIHlvdSBoYXZlIGFscmVhZHkgdGhvdWdodCBv
ZiBhIHN1aXRhYmxlIG5hbWU/IDopDQoNClZsYWRpbWlyDQoNCk9uIDE0LzA0LzIwMjAgMjM6MDgs
IEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KVXNpbmcgUEFSIGNhbiBmYWNpbGl0YXRlIGltcHJvdmVk
IHNlY3VyaXR5IGJ5IGdpdmluZyBjbGllbnRzIGEgKHJlbGF0aXZlbHkpIHNpbXBsZSBtZWFucyBm
b3Igc2VuZGluZyBhIGNvbmZpZGVudGlhbCwgaW50ZWdyaXR5IHByb3RlY3RlZCwgYW5kIChmb3Ig
Y29uZmlkZW50aWFsIGNsaWVudHMgYW55d2F5KSBhdXRoZW50aWNhdGVkIGF1dGhvcml6YXRpb24g
cmVxdWVzdC4NCg0KSXQgc2VlbXMgbGlrZSBzb21lIG9mIHRoYXQgaW1wcm92ZWQgc2VjdXJpdHkg
Y291bGQgYmUgdW5kZXJtaW5lZCBieSBhIG1hbGljaW91cyBhY3RvciBzb21laG93IGdldHRpbmcg
YSB1c2VyIHRvIG5hdmlnYXRlIHRvIGEgVVJMIG9mIGEgcmVndWxhciBvbGQgcGFyYW1ldGVyaXpl
ZCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIE9uZSB2YXJpYXRpb24gb2YgdGhlIE1peC1VcCBBdHRh
Y2sgZG9lcyB0aGlzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo
LXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTQuNC4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xNSNzZWN0aW9uLTQuNC4uMT4g
Zm9yIGV4YW1wbGUgYW5kIGVtYWlsLCBzb2NpYWwgbWVkaWEsIG9ubGluZSBmb3J1bXMsIGV0Yy4s
IGFyZSBvdGhlciB3YXlzIGEgdXNlciBtaWdodCBiZSB0cmlja2VkIGludG8gZm9sbG93aW5nIGEg
bWFsaWNpb3VzbHkgY3JhZnRlZCBsaW5rLg0KDQpGb2xsb3dpbmcgZnJvbSB0aGF0IGl0IHNlZW1z
IGxvZ2ljYWwgdGhhdCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBtaWdodCB3YW50IHRvIHJlc3Ry
aWN0IHNvbWUgY2xpZW50cyBmcm9tIHNlbmRpbmcgYSByZWd1bGFyIHBhcmFtZXRlcml6ZWQgYXV0
aG9yaXphdGlvbiByZXF1ZXN0IGFuZCBpbnN0ZWFkIHJlcXVpcmUgdXNlIG9mIHRoZSBQQVIgZW5k
cG9pbnQgdG8gaW5pdGlhdGUgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBTb21ldGhpbmcgbGlr
ZSB0aGlzIGNvdWxkLCBvZiBjb3Vyc2UsIGJlIGltcGxlbWVudGVkIGFzIGN1c3RvbSBwb2xpY3kg
b3IgY29uZmlndXJhdGlvbiBpbiBhbnkgQVMuIEJ1dCBJJ20gdGhpbmtpbmcgaXQgbWlnaHQgYmUg
Y29tbW9uIGVub3VnaCB0byB3YXJyYW50IGFkZGluZyBhIGNsaWVudCBtZXRhZGF0YSBwYXJhbWV0
ZXIgdG8gdGhlIFBBUiBkcmFmdCBzcGVjaWZpY2FsbHkgZm9yIGl0LiBUaGUgbWV0YWRhdGEgKGFu
ZCByZWdpc3RlcmVkIGV4dGVuc2lvbnMpIGRlZmluZWQgYnkgRHluYW1pYyBDbGllbnQgUmVnaXN0
cmF0aW9uIFtSRkM3NTkxXSBoYXMgY29tZSB0byBpbXBseSBhIGdlbmVyYWwgZGF0YSBtb2RlbCBh
bmQgZXhwZWN0ZWQgYXNzb2NpYXRlZCBiZWhhdmlvcnMgZm9yIGNsaWVudHMgdGhhdCBpcyB1c2Vm
dWwgZm9yIGF1dGhvcml6YXRpb24gc2VydmVyIGltcGxlbWVudGF0aW9ucywgZXZlbiB3aGVuIHRo
ZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gUHJvdG9jb2wgaXNuJ3QgZGlyZWN0bHkgaW4g
cGxheS4gVGhpcyBwYXJ0aWN1bGFyIHNpdHVhdGlvbiBzZWVtcyBsaWtlIGEgZ29vZCBwb3RlbnRp
YWwgY2FuZGlkYXRlIGZvciBhIG5ldyBzdWNoIGNsaWVudCBtZXRhZGF0YSBwYXJhbWV0ZXIgdGhh
dCB3b3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBnaXZlbiBjbGllbnQgY2FuIG9ubHkgdXNlIGEgcmVx
dWVzdF91cmkgdmFsdWUgb2J0YWluZWQgZnJvbSB0aGUgUEFSIGVuZHBvaW50IHRvIGluaXRpYXRl
IGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gQW5kIHRoYXQgYSByZWd1bGFyIG9sZCBmYXNoaW9u
ZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZyb20gdGhlIGdpdmVuIGNsaWVudCB3b3VsZCByZXN1
bHQgaW4gYW4gZXJyb3IuDQoNCkRvIHRoZSBmb2xrcyBvZiB0aGlzIGZpbmUgV0cgdGhpbmsgc29t
ZXRoaW5nIGxpa2UgdGhpcyB3b3VsZCBiZSBhIHdvcnRod2hpbGUgYWRkaXRpb24gdG8gdGhlIFBB
UiBkcmFmdD8NCg0KDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h
eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv
bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlz
dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu
LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl
IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh
bmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkNPTkZJREVOVElBTElUWSBO
T1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk
IG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4g
QW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMg
c3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmlj
YXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl
LW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJv
bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_760B73F1F31C4474887128EEBCF45D44amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2IGRpcj0ibHRyIj5BcyBJIHRoaW5rIHRocm91Z2ggdGhpcywgSeKAmW0gc3RydWdnbGluZyB0
byBpZGVudGlmeSB0aGUgdGhyZWF0cyB0aGlzIGFjdHVhbGx5IGhlbHBzIG1pdGlnYXRlLjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5BIGNsaWVudCBt
ZXRhZGF0YSBwYXJhbWV0ZXIgaW1wbGllcyB0aGF0IHRoZSB2YWx1ZSBtYXkgYmUgZGlmZmVyZW50
IGZvciBkaWZmZXJlbnQgY2xpZW50cywgYW5kIHRoYXQgYW55IGdpdmVuIGNsaWVudCB3b27igJl0
IGFscmVhZHkga25vdyB2aWEgb3RoZXIgbWVhbnMgd2hldGhlciBvciBub3QgaXQgbmVlZHMgdG8g
dXNlIFBBUi4gVGhhdCBtZWFucyB3ZeKAmXJlIG9ubHkgdGFsa2luZyBhYm91dCBkeW5hbWljIGNs
aWVudHMgc2luY2UNCiBzdGF0aWNhbGx5IHJlZ2lzdGVyZWQgY2xpZW50cyBhbHJlYWR5IGhhdmUg
c29tZSBwcm9wcmlldGFyeSBvdXQtb2YtYmFuZCByZWdpc3RyYXRpb24gbWVjaGFuaXNtIChlLmcu
LCBhIGRldmVsb3BlciBjb25zb2xlKS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgY2xpZW50
IG1ldGFkYXRhIHBhcmFtZXRlciBhbHNvIGltcGxpZXMgdGhhdCB0aGUgQVMgYWxsb3dzIHNvbWUg
Y2xpZW50cyB0byBtYWtlIG5vbi1QQVIgcmVxdWVzdHMgKG90aGVyd2lzZSBpdCB3b3VsZCBiZSBh
biBBUyBtZXRhZGF0YSBwYXJhbWV0ZXIpLiBJZiB0aGF04oCZcyB0aGUgY2FzZSB0aGVuIHByZXN1
bWFibHkgYSBtYWxpY2lvdXMgcGFydHkgY291bGQgcmVnaXN0ZXIgdGhlaXIgb3duIGNsaWVudCB0
aGF0IGRvZXNu4oCZdCB1c2UgUEFSLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28g
aXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgb25seSBzY2VuYXJpbyB0aGF0IHRoaXMgcGFyYW1ldGVy
IHdvdWxkIHByb3RlY3QgYWdhaW5zdCBpcyBhIG1hbGljaW91cyBwYXJ0eSBpbXBlcnNvbmF0aW5n
IGEgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnQgdGhhdCB1c2VzIFBBUi4gVGhhdCB3b3Vs
ZG7igJl0IGFwcGx5IHRvIE1peC1VcCwgc2luY2UgaW4gdGhhdCBhdHRhY2sgdGhlIGF0dGFja2Vy
IHVzZXMgaXRzIG93biBjbGllbnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBh
IGNsaWVudCBjYW4gZG8gUEFSLCB0aGVuIGl0IGNhbiBkbyBhdXRob3JpemF0aW9uIGNvZGUgZ3Jh
bnQgYW5kIFBLQ0UsIHNvIHdl4oCZcmUgZnVydGhlciBsaW1pdGVkIHRvIHNjZW5hcmlvcyB3aGVy
ZSB0aGUgYXR0YWNrZXIgZG9lcyBub3QgbmVlZCB0byBiZSBhYmxlIHRvIHJlZGVlbSB0aGUgYXV0
aG9yaXphdGlvbiBjb2RlIHRoZW1zZWx2ZXMuIFdoYXQgdGhyZWF0cyBmYWxsIGludG8gdGhpcyBj
YXRlZ29yeT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj4N
CjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdi
YSgyNTUsIDI1NSwgMjU1LCAwKTsiPkFubmFiZWxsZSBCYWNrbWFuJm5ic3A7KHNoZS9oZXIpPC9z
cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUs
IDI1NSwgMjU1LCAwKTsiPkFXUyBJZGVudGl0eTwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBk
aXI9Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gQXByIDE0LCAyMDIwLCBh
dCAyOjQ0IFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsPTQwcGluZ2lkZW50aXR5LmNv
bUBkbWFyYy5pZXRmLm9yZyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjx0YWJsZSBjbGFzcz0iTXNvVGFibGVHcmlkIiBib3JkZXI9
IjEiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBz
ZTpjb2xsYXBzZTtib3JkZXI6bm9uZSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4y
NXB0Ij4NCjx0ZCB3aWR0aD0iNzExIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjg0Mi4zNXB0
O2JvcmRlcjpzb2xpZCAjRUQ3RDMxIDEuNXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDto
ZWlnaHQ6MTUuMjVwdCI+DQo8cD48c3Ryb25nPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGRkZG
OTkiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkY5
OSI+OiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRp
b24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgY2Fu
IGNvbmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4N
Cjxicj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+SSB3YXMgaG9waW5nIHRvIGdldCB0
byBhIHJvdWdoIGNvbnNlbnN1cyBpbiBzdXBwb3J0IG9mIHRoZSBpZGVhIGJlZm9yZSBjb21pbmcg
dXAgd2l0aCBhIG5hbWUgdGhhdCBldmVyeW9uZSB3aWxsIGhhdGUgOikNCjxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhlIG1lYW50aW1lLCBob3dldmVyLCBuYW1lIHN1
Z2dlc3Rpb25zIGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4gPGJyPg0KPC9kaXY+DQo8YnI+DQo8L2Rp
dj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz
PSJnbWFpbF9hdHRyIj5PbiBUdWUsIEFwciAxNCwgMjAyMCBhdCAyOjIyIFBNIFZsYWRpbWlyIER6
aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj52bGFk
aW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2Jv
cmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0K
PGRpdj4NCjxwPkknbSBhbGwgZm9yIHRoYXQuPC9wPg0KPHA+SSBzdXBwb3NlIHlvdSBoYXZlIGFs
cmVhZHkgdGhvdWdodCBvZiBhIHN1aXRhYmxlIG5hbWU/IDopPC9wPg0KPHA+VmxhZGltaXI8YnI+
DQo8L3A+DQo8ZGl2Pk9uIDE0LzA0LzIwMjAgMjM6MDgsIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxi
cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk
aXY+VXNpbmcgUEFSIGNhbiBmYWNpbGl0YXRlIGltcHJvdmVkIHNlY3VyaXR5IGJ5IGdpdmluZyBj
bGllbnRzIGEgKHJlbGF0aXZlbHkpIHNpbXBsZSBtZWFucyBmb3Igc2VuZGluZyBhIGNvbmZpZGVu
dGlhbCwgaW50ZWdyaXR5IHByb3RlY3RlZCwgYW5kIChmb3IgY29uZmlkZW50aWFsIGNsaWVudHMg
YW55d2F5KSBhdXRoZW50aWNhdGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdC48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2Pkl0IHNlZW1zIGxpa2Ugc29tZSBvZiB0aGF0IGltcHJvdmVkIHNl
Y3VyaXR5IGNvdWxkIGJlIHVuZGVybWluZWQgYnkgYSBtYWxpY2lvdXMgYWN0b3Igc29tZWhvdyBn
ZXR0aW5nIGEgdXNlciB0byBuYXZpZ2F0ZSB0byBhIFVSTCBvZiBhIHJlZ3VsYXIgb2xkIHBhcmFt
ZXRlcml6ZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBPbmUgdmFyaWF0aW9uIG9mIHRoZSBNaXgt
VXAgQXR0YWNrIGRvZXMgdGhpcw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTE1I3NlY3Rpb24tNC40Li4xIiB0YXJn
ZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0
aC1zZWN1cml0eS10b3BpY3MtMTUjc2VjdGlvbi00LjQuMTwvYT4gZm9yIGV4YW1wbGUgYW5kIGVt
YWlsLCBzb2NpYWwgbWVkaWEsIG9ubGluZSBmb3J1bXMsIGV0Yy4sIGFyZSBvdGhlciB3YXlzIGEg
dXNlciBtaWdodCBiZSB0cmlja2VkIGludG8gZm9sbG93aW5nIGEgbWFsaWNpb3VzbHkgY3JhZnRl
ZCBsaW5rLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rm9sbG93aW5nIGZy
b20gdGhhdCBpdCBzZWVtcyBsb2dpY2FsIHRoYXQgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWln
aHQgd2FudCB0byByZXN0cmljdCBzb21lIGNsaWVudHMgZnJvbSBzZW5kaW5nIGEgcmVndWxhciBw
YXJhbWV0ZXJpemVkIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhbmQgaW5zdGVhZCByZXF1aXJlIHVz
ZSBvZiB0aGUgUEFSIGVuZHBvaW50IHRvIGluaXRpYXRlIGFuIGF1dGhvcml6YXRpb24gcmVxdWVz
dC4gU29tZXRoaW5nDQogbGlrZSB0aGlzIGNvdWxkLCBvZiBjb3Vyc2UsIGJlIGltcGxlbWVudGVk
IGFzIGN1c3RvbSBwb2xpY3kgb3IgY29uZmlndXJhdGlvbiBpbiBhbnkgQVMuIEJ1dCBJJ20gdGhp
bmtpbmcgaXQgbWlnaHQgYmUgY29tbW9uIGVub3VnaCB0byB3YXJyYW50IGFkZGluZyBhIGNsaWVu
dCBtZXRhZGF0YSBwYXJhbWV0ZXIgdG8gdGhlIFBBUiBkcmFmdCBzcGVjaWZpY2FsbHkgZm9yIGl0
LiBUaGUgbWV0YWRhdGEgKGFuZCByZWdpc3RlcmVkIGV4dGVuc2lvbnMpDQogZGVmaW5lZCBieSBE
eW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gW1JGQzc1OTFdIGhhcyBjb21lIHRvIGltcGx5IGEg
Z2VuZXJhbCBkYXRhIG1vZGVsIGFuZCBleHBlY3RlZCBhc3NvY2lhdGVkIGJlaGF2aW9ycyBmb3Ig
Y2xpZW50cyB0aGF0IGlzIHVzZWZ1bCBmb3IgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW1wbGVtZW50
YXRpb25zLCBldmVuIHdoZW4gdGhlIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2Nv
bCBpc24ndCBkaXJlY3RseQ0KIGluIHBsYXkuIFRoaXMgcGFydGljdWxhciBzaXR1YXRpb24gc2Vl
bXMgbGlrZSBhIGdvb2QgcG90ZW50aWFsIGNhbmRpZGF0ZSBmb3IgYSBuZXcgc3VjaCBjbGllbnQg
bWV0YWRhdGEgcGFyYW1ldGVyIHRoYXQgd291bGQgaW5kaWNhdGUgdGhhdCB0aGUgZ2l2ZW4gY2xp
ZW50IGNhbiBvbmx5IHVzZSBhIHJlcXVlc3RfdXJpIHZhbHVlIG9idGFpbmVkIGZyb20gdGhlIFBB
UiBlbmRwb2ludCB0byBpbml0aWF0ZSBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQogQW5kIHRo
YXQgYSByZWd1bGFyIG9sZCBmYXNoaW9uZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZyb20gdGhl
IGdpdmVuIGNsaWVudCB3b3VsZCByZXN1bHQgaW4gYW4gZXJyb3IuDQo8YnI+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvIHRoZSBmb2xrcyBvZiB0aGlzIGZpbmUgV0cgdGhpbmsg
c29tZXRoaW5nIGxpa2UgdGhpcyB3b3VsZCBiZSBhIHdvcnRod2hpbGUgYWRkaXRpb24gdG8gdGhl
IFBBUiBkcmFmdD88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4N
CjxpPjxzcGFuPjxmb250IHNpemU9IjIiPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1h
aWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0
aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNl
LCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCiBjb21tdW5pY2F0aW9uIGlu
IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu
ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj
b21wdXRlci4gVGhhbmsgeW91LjwvZm9udD48L3NwYW4+PC9pPg0KPGJyPg0KPGZpZWxkc2V0Pjwv
ZmllbGRzZXQ+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiBy
ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0K
PGkgc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDt2
ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnJnYigyNTUsMjU1LDI1NSk7Zm9udC1m
YW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sc3lzdGVt
LXVpLCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxVYnVudHUsQ2FudGFy
ZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6cmdi
KDg1LDg1LDg1KSI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVyOjBw
eDtvdXRsaW5lOjBweDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTtiYWNrZ3JvdW5kOnRyYW5zcGFy
ZW50O2ZvbnQtZmFtaWx5OnByb3hpbWEtbm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lz
dGVtLEJsaW5rTWFjU3lzdGVtRm9udCwmcXVvdDtTZWdvZSBVSSZxdW90OyxSb2JvdG8sT3h5Z2Vu
LVNhbnMsVWJ1bnR1LENhbnRhcmVsbCwmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxBcmlhbCxz
YW5zLXNlcmlmO2ZvbnQtd2VpZ2h0OjYwMCI+PGZvbnQgc2l6ZT0iMiI+Q09ORklERU5USUFMSVRZ
DQogTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls
ZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo
cykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJz
IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz
IGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkNCiB0aGUgc2VuZGVyIGltbWVk
aWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRh
Y2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L2ZvbnQ+PC9zcGFuPjwvaT48
L2Rpdj4NCjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPC9zcGFuPjxicj4NCjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bh
bj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48YnI+DQo8c3Bhbj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_760B73F1F31C4474887128EEBCF45D44amazoncom_--


From nobody Thu Apr 16 00:10:14 2020
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 536893A1015 for ; Thu, 16 Apr 2020 00:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22T2gWmdQd6q for ; Thu, 16 Apr 2020 00:10:08 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 BE4E03A0F74 for ; Thu, 16 Apr 2020 00:10:07 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id s63so16109372qke.4 for ; Thu, 16 Apr 2020 00:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=IULBDrfj46/g8qt1WsvquebT0ycN7SA829C0NkBcUi8=; b=u/LnQI9Ox9hGuEkOnSehNu4Ws5vU7F3XzBMgA91UYthAEVFN1Z6HP8JrJuiHvMa9TS TzjQO9gXuEDvYf9maDboZ8oOHrYFEHUOrBdEI8kfXp05rB0DmfeNGYJNz8YTp0kf2I/n kIgIpWdBXENrjT4olvODaFEp6cQD9NTfkUZ9arwOIw/gMrcdBHP4GVncGOzTSIdcanGi CtpZtepzuYYDqe/qHcxMt/rJwnmyWuQNy+9BCVHUKZoIHYxFRo7pLAqYfLTH/aqrJA8f aHMe0QBYE0BvwT17xAqYf4YTDOYDVA0EeBCSqos/wVTrujvBHNPGJQWxHj4AuZyHNaRl XMdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=IULBDrfj46/g8qt1WsvquebT0ycN7SA829C0NkBcUi8=; b=NOjw9GlK4tDDsmrpyJyjL1Nbf2ZxcZSDkVqI86MxLft1xGEpD4/O2+w1pBFOTGBTyB ze7d+QxWpktH4iywZnwTj64DkoppcxkkUNTVwrvdUf66dYgDQUVkJ7QliH7c9VvcRih7 W4bYsTGdbvDTirtgB+EYNTNBQX65/nGhVwCZGcieB2GWhTQrEnwYIykDuePkygFaoJc2 +liXiK4arVbNqXiElyHJltxDl6QzoZohc3J8++wmsGPTlKxKyPF5JhwjTYfqcyi6j53e FQDA3bPCBl5LDCcCOSCvWIT2dLx4d4PaN9r3s3E1WodGU3N2r+lAHLwMhMHc1UU6/qAR 4tfA==
X-Gm-Message-State: AGi0PuZvhZ8XWMoZn9RGPyVc0iNLXZzhDEb/iaCJoRjRWXHG3zSNQIkY UZMfrOt1Sn2tGxkBMLOJUlCZfRgmxswvDaDcM4lw
X-Google-Smtp-Source: APiQypJTpmoSOucV6ATKq6ftmnuBwxVyq1dfT3EP2aTIeUB8SF9H+M+gy2tCc8eoPbSUYNNZHy+e89VeDKAPiKmFlcY=
X-Received: by 2002:a05:620a:2054:: with SMTP id d20mr16892050qka.496.1587021006246;  Thu, 16 Apr 2020 00:10:06 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Apr 2020 00:10:05 -0700
From: Dominick Baier 
In-Reply-To: 
References: 
MIME-Version: 1.0
Date: Thu, 16 Apr 2020 00:10:05 -0700
Message-ID: 
To: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="000000000000542c3e05a3631f1b"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 16 Apr 2020 07:10:12 -0000

--000000000000542c3e05a3631f1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.

*client_id vs sub*
I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of th=
e claim types
based on flow.
If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and
client.

Furthermore it says

"Authorization servers should prevent scenarios where clients can
   affect the value of the sub claim in ways that could confuse resource
   servers.=E2=80=9D

If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.

Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.

*audience claim*
I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don=E2=80=99t exist, you'=
d need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What=E2=80=99s =
the
value of that?

If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn=E2=80=99t make it required.

*iat vs nbf*
What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t m=
ost JWT
libraries (including e.g. the .NET one) looking for nbf by default?

*General*
This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn=E2=80=99=
t work
one way or the other for them.

I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see j=
ust some standard claims
and IF they are used, which semantics they have.

cheers
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
wrote:

Hi all,



This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



Please send your comments to the OAuth mailing list by April 29, 2020.



Regards,

 Rifaat & Hannes


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

--000000000000542c3e05a3631f1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Sinc=
e this is the last call, I thought I bring up some of thoughts / concerns. =
Some of them have been discussed before.

client_id vs sub
I am still not entirely happy with the =
=E2=80=9Cre-purposing=E2=80=9D of the claim types based on flow.
If the intention is, t=
hat sub expresses the entity against which the resource will do authorisati=
on (and that might be a client or a user) - I get it (and maybe it should b=
e stated like that) - but
this thinking reminds me of the old AD days where there was n=
o distinction between user and service accounts (something that has been fi=
xed IIRC in Windows Server 2012 R2).

All other OAuth specs make a very clear distinction betwe=
en users and client.

Furthermore it says

"Authorization servers should pre=
vent scenarios where clients can
=C2=A0 =C2=
=A0affect the value of the sub claim in ways that could confuse resource
=C2=A0 =C2=A0servers.=E2=80=9D

If we keep that dual se=
mantics of the sub claim - it must be clearly stated, that subject ID and c=
lient ID are now in the same collision domain. So when an AS / OP creates t=
hem, they need to be unique across user ids and client ids.

Maybe it should be also=
 explicitly mentioned that sub has a different semantic here as in OIDC - e=
ven though a majority of the software built today will use them together.

audien=
ce claim
I am not fully clear why aud is=
 required. OAuth itself does not have a notion of an audience (in the JWT s=
ense) - they have scopes (which is very similar). But in simple scenarios w=
here resources don=E2=80=99t exist, you'd need to make up an audience j=
ust to fulfil this requirement. And in many case this will be either static=
 or just repeat the scope values. What=E2=80=99s the value of that?

If the concept =
of resources are used, I absolutely agree that aud should be used too. But =
I wouldn=E2=80=99t make it required.

iat vs nbf
What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99=
t most JWT libraries (including e.g. the .NET one) looking for nbf by defau=
lt?

G=
eneral
This spec feels somehow in betwee=
n a profile and a BCP. On one hand you define some claims and their semanti=
cs (good) - on the other hand there is some prescriptive guidance and maybe=
 over-specification. My concern is, that in the end no-one will fully compl=
y with it, because it doesn=E2=80=99t work one way or the other for them.

I know we=
 just went though the discussion to make certain claims required as opposed=
 to optional - but maybe less is more.

<=
/div>
Tbh - the most valuable part of the doc to m=
e is the definition of the =E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=
=80=99d rather like to see just some standard claims and IF they are used, =
which semantics they have.

 cheers=C2=A0
 
=
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
 
On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:
 
Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://tools.ietf.org/html/=
draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--000000000000542c3e05a3631f1b--


From nobody Thu Apr 16 01:06:17 2020
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 447BA3A115B for ; Thu, 16 Apr 2020 01:06:15 -0700 (PDT)
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, 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 W7Oj6RA1EF02 for ; Thu, 16 Apr 2020 01:06:06 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 DBC633A1157 for ; Thu, 16 Apr 2020 01:06:05 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id e17so1572341ybq.0 for ; Thu, 16 Apr 2020 01:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3OYcN2kTb4cEy+jXmkiLyfYlyHvtONEQD8DCM1Gvl0g=; b=kBpY8ULD20QA+Tt0qsKDvc54M3K2THgQkdeA8Lm7W72C+6WGHAwF4Z03wIaPHKWvTH 3r0HbbXZR/hHdXlhnn3uJAI+RdaACGWQkzEX3lXRJ9cpAOqvKuiq/LkU5ECK9jsYiC8z x/isVXKKh1LBLXehIG7perXsgJKjD+vSCrZ19/H5NM2blJjLpheqS2FhTaeCS+Fa7HJF lBp+d5zl7YPREdVgGFyPdhVQGgibX4I3jtxkkhde2V/gfj1U3uR4awqCtxXjtXmxVMZJ qCHb8WRJlWt/GpglGVgzVhtLlX341ctvr5Fnv/ZsHDwf+9Bp40xnJ+kcTLVlToONrCIT cV0A==
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=3OYcN2kTb4cEy+jXmkiLyfYlyHvtONEQD8DCM1Gvl0g=; b=JpqHZFIYslFCRy9EBEEA6hZ+z61f8qa0HTqnWirm59gpMW3aVHtlL8/uqKL0UUssin nBMi7yLRZkim4vqrNVCnJKg/KOzi2ZF8rUuUuDWnzMr1DeaLUrGpDoFKg0BiZfFht/eV 1clNtVkAa0UCDhxLKaIcJp2joI+Use9yUSpBSEIoc8GhJH3bKEw2yUpRFr1K6go631E0 mEGoSWkuNC5Lez5aM54rSDODwaikgSue/aP8p/RMx8YCmlrqz55w7v6N9ZOSYbF1zBs4 fKklpe/RlJjNA8xVu5GKKybqhavUUQoUPwxsJI+kcxupdoBaZNXDyqTVgfJwbvOQfLBK 0w2w==
X-Gm-Message-State: AGi0PuZ39nh/pxDwi3nb9Fulsgzxli31n7Gub3NGoyyj8/e9lxT9TA3B ceaSrZVMDT53eVmgFFm+uC+RKjClpLUrHOpcSg==
X-Google-Smtp-Source: APiQypLp6fO77CFtZs44kN/q1YuoLaNcQY9Ki0q+h8mBW+ZJi0RI/9D0VylPTWRWo1tOKmDpvRHZaKBr699KBo90XII=
X-Received: by 2002:a25:aa69:: with SMTP id s96mr14648061ybi.85.1587024364892;  Thu, 16 Apr 2020 01:06:04 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Filip Skokan 
Date: Thu, 16 Apr 2020 10:05:28 +0200
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000084fcc905a363e757"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 16 Apr 2020 08:06:15 -0000

--00000000000084fcc905a363e757
Content-Type: text/plain; charset="UTF-8"

>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>

If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.


I agree.

 The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?


:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
wrote:

> Hi Filip,
>
> My attempts at responses to your questions/comments are inline:
>
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>
>> I've wondered about the decision to use a new scheme before
>>  but
>> this time i'd like to challenge the immediate usability of the future spec
>> for one specific case - sender constraining public client Refresh Tokens.
>>
>
> I'm still somewhat on the fence as to the pros and cons of using a new
> token type and authorization scheme. But the draft has gone with a new one.
> Would it have really helped this situation, if it'd stuck with "bearer"? Or
> would it just be less obvious?
>
>
>>
>> If at all, it is going to take time for RS implementations to recognize
>> the new `DPoP` authorization scheme, let alone process it properly. In the
>> meantime, i'd still like to have the option to bind issued public client
>> refresh tokens using DPoP without affecting the access tokens. In doing so
>> i get an immediate win in sender constraining the refresh tokens but not
>> introducing a breaking change for the RS.
>>
>>
>>    - Do you see this as something an AS implementation is just free to
>>    do since it's both the issuer and recipient of a refresh token?
>>
>> That's my first thought, yes.
>
>
>>
>>    - Should this be somehow baked in the draft?
>>
>> I'm not sure. Do you think it needs to be? I'm not sure what it would say
> though.
>
> In such a case the AS could bind the RT to the given dpop proof and either
> not bind the AT while returning token_type=Bearer or bind the AT while
> returning token_type value DPoP. In the latter case the AT would almost
> certainly still work as a bearer token at the RS and the client that knew
> the RS's needs could send it as such with an `Authorization: Bearer `.
> Or if it didn't know the RS's needs, it could start with `Authorization:
> DPoP ` which would get a 401 with `WWW-Authenticate: Bearer` at which
> point it could send `Authorization: Bearer `.
>
> As I wrote the preceding rambling paragraph I am starting to think that
> more should be said in the draft about working with RSs that don't support
> DPoP. Which isn't really what you were asking about. But maybe would cover
> some of the same ground.
>
>
>
>>
>>    - Do you think client registration metadata could be used to signal
>>    such intent?
>>
>> I think it certainly could. But it seems maybe too specific to warrant
> metadata.
>
>
>>
>>    - Do you think the protocol should have signals in the messages
>>    themselves to say what the client wants to apply DPoP to?
>>
>> My initial thought here is no. Take the case of a client working with an
> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
> really even think what signaling might look like there or how it could be
> made to be generally useful.
>
>
>>
>>    - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>    Do we disqualify such cases or allow for sending two proofs, one for the AS
>>    to bind refresh tokens to, one for the RS to bind access tokens to?
>>
>> The AS is the one that does the binding (which includes checking the
> proof) so I don't see how sending two proofs would really work or help the
> situation?
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

--00000000000084fcc905a363e757
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm still somewhat on the fence as to the pros =
and cons of using a new token type and authorization scheme. But the draft =
has gone with a new one. Would it have really helped this situation, if it&=
#39;d stuck with "bearer"? Or would it just be less obvious?

If we had stuck "bearer" than i=
 wouldn't have raised this topic, since existing RS would most likely i=
gnore the cnf claim and the resource server calls would continue to work, o=
bviously without taking advantage of the available sender check.
=

As I wrote=
 the preceding rambling paragraph I am starting to think that more should b=
e said in the draft about working with RSs that don't support DPoP. Whi=
ch isn't really what you were asking about. But maybe would cover some =
of the same ground.

I agree.

=

=C2=A0The AS is the=
 one that does the binding (which includes checking the proof) so I don'=
;t see how sending two proofs would really work or help the situation?

:facepalm: indeed, sorry.=C2=A0

S pozdravem,
Filip Skokan


On=
 Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampbell@pingidentity.com> wrote:
Hi Filip,=
 

My attempts at responses to your questions/c=
omments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com=
> wrote:
I've wondered about the decision to use a new scheme=
=C2=A0before=C2=A0but this time i'd li=
ke to challenge the immediate usability of the future spec for one specific=
 case - sender constraining public client Refresh Tokens.

I'm still somewhat on the fence as to th=
e pros and cons of using a new token type and authorization scheme. But the=
 draft has gone with a new one. Would it have really helped this situation,=
 if it'd stuck with "bearer"? Or would it just be less obviou=
s? 
=C2=A0

If at all, it is going to take time for RS i=
mplementations to recognize the new `DPoP` authorization scheme, let alone =
process it properly. In the meantime, i'd still like to have the option=
 to bind issued public client refresh tokens using DPoP without affecting t=
he access tokens. In doing so i get an immediate win in sender constraining=
 the refresh tokens but not introducing a breaking change for the RS.
  • Do you see this as something an AS implementation is just free to=
 do since it's both the issuer and recipient of a refresh token?
That's my first thought, yes. 
=C2=A0
  •  Should this be somehow baked in the draft?
I'm not sure. Do you think it needs to =
be? I'm not sure what it would say though. 

In such a case the AS could bind the RT to the given dpop proof and eithe=
r not bind the AT while returning token_type=3DBearer or bind the AT while =
returning token_type value DPoP. In the latter case the AT would almost cer=
tainly still work as a bearer token at the RS and the client that knew the =
RS's needs could send it as such with an `Authorization: Bearer <at&=
gt;`. Or if it didn't know the RS's needs, it could start with `Aut=
horization: DPoP <at>` which would get a 401 with `WWW-Authenticate: =
Bearer` at which point it could send `Authorization: Bearer <at>`. 

As I wrote the preceding rambling paragraph I a=
m starting to think that more should be said in the draft about working wit=
h RSs that don't support DPoP. Which isn't really what you were ask=
ing about. But maybe would cover some of the same ground. 
=
=C2=A0
=C2=A0
  • Do you think client registration meta=
data could be used to signal such intent?
I think it certainly could. But it seems maybe too specific to warran=
t metadata. 
=C2=A0
  • Do you think the protocol shoul=
d have signals in the messages themselves to say what the client wants to a=
pply DPoP to?
My initial thought her=
e is no. Take the case of a client working with an AS that supports DPoP an=
d one RS that does and one RS that doesn't. I can't really even thi=
nk what signaling might look like there or how it could be made to be gener=
ally useful.
=C2=A0
  • What if AS and RS don't hav=
e a shared support DPoP JWS Algorithm? Do we disqualify such cases or allow=
 for sending two proofs, one for the AS to bind refresh tokens to, one for =
the RS to bind access tokens to?
The=
 AS is the one that does the binding (which includes checking the proof) so=
 I don't see how sending two proofs would really work or help the situa=
tion? 
=C2=A0




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.


--00000000000084fcc905a363e757--


From nobody Thu Apr 16 01:15:57 2020
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 1A9F23A117D for ; Thu, 16 Apr 2020 01:15:56 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UxI7lhmRVF4C for ; Thu, 16 Apr 2020 01:15:54 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 1191B3A1179 for ; Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id i2so1579238ybk.2 for ; Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QnNmpYIKmfBjlWjprJ8s/phGnEkbu1sTNaHpodCuVpY=; b=cTK4m2H5QdGquq6P1AkgzPwI5KJOkwsKvewltw38ArdoTTdRNJ+lvYGZ+h6IgQra9Y n3/lTZyWKJR3VG8c/5JzW48PA6ayeRHFUMD9GbSAZnuYds+PNA+lUxDmhrZAQx2yvmAW E5OmKFkThYpeJpfcJBYDVwiiPlj35B8tc69vxte4gRial6q9kw34SHuGsHV6wMjInX3n vJJaI4TYGYMCIbWGvfnrnwN8XPzonYRXtKS591qoG9NYGUS8dK29LqMp4wcqtJgnYHAW PLkCtUCar1xHh/8s7XrB0E3d98F7A6aGHsQv7DrPwXCvv9pbnBLjMR+vqEt3z4mcX16g z7Pw==
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=QnNmpYIKmfBjlWjprJ8s/phGnEkbu1sTNaHpodCuVpY=; b=U092ZLCS/YXSowJaugFjb2pWvD2Vs1n9qpWnATZZH55pIJ1sb/0jNRpNdBeWGyX1Ad sx5QemRFdaPezNbTCXf5LRv8lh3joUCsJSYuUyK8v5kuejK59qjaZbQA4IsFJEk48V9K 3Gonbi//CKMl74oOU76TOmJKSZ1AkeCkNU4fccFyEJ0c3iDrfc5rCDJ3aZ1IaHoZlkAi n0ESXC88UdpY03HRyC77NtCDoDB+wuqANRdMWdtEpIqaSegkpHXlUnKvD35IwJBCrkzR /EUtmUInwdQV9yZo/jOimEAf+M1gH9akTFpUgYu0peGAajmiTFC3YzLCNhr3ElfY0mnX N/aQ==
X-Gm-Message-State: AGi0PuZ/WeXLKWvRadQZreWL13ZdF7ItboD4MvAELFEVej+WsQKGC5Hu 0INtuDVmvAtUPmhc1usSjp1yfRAXVfxinVFsEsS8W/I=
X-Google-Smtp-Source: APiQypJe3ffbGnSLrsb4eQiUTL2HzxdvSMNHSsddtqDCA307+77X4cBWun4q9rNKUnamTXO5+fLC/UkHwLYsexYvsxc=
X-Received: by 2002:a25:6607:: with SMTP id a7mr13753519ybc.351.1587024953078;  Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Filip Skokan 
Date: Thu, 16 Apr 2020 10:15:17 +0200
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000093f7ea05a3640a92"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 08:15:56 -0000

--00000000000093f7ea05a3640a92
Content-Type: text/plain; charset="UTF-8"

I would support defining a client level property. I would also support an
AS discovery property for an AS-wide policy that is signalled to all
clients (and maybe that one would be enough).

FWIW (and this touches my earlier responses about the dpop scheme) defining
metadata (both AS and Client) is beneficial not only for runtime (DCR,
discovery) but in general supports developers using these specs, when they
read about a possible behaviour in the document and there's a mentioned
metadata property, they know what to look for in readmes, API
documentation, UI etc. It saves time, theirs, and mine when i develop those
behaviour toggles - i don't have to start mixing configuration objects so
far composed entirely of IANA registered properties with proprietary ones,
i don't need to come up with property names (and we know what a PITA that
is) and it also saves time in the long run because it's less likely someone
will open an issue about it.

Best,
*Filip*


On Tue, 14 Apr 2020 at 22:09, Brian Campbell  wrote:

> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000093f7ea05a3640a92
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I would support defining a client level property. I w=
ould also support an AS discovery property for an AS-wide policy that is si=
gnalled to all clients (and maybe that one would be enough).

=

FWIW (and this touches my earlier responses about the dpop schem=
e) defining metadata (both AS and Client) is beneficial not only for runtim=
e (DCR, discovery) but in general supports developers using these specs, wh=
en they read about a possible behaviour in the document and there's a m=
entioned metadata property, they know what to look for in readmes, API docu=
mentation, UI etc. It saves time, theirs, and mine when i develop those beh=
aviour toggles - i don't have to start mixing configuration objects so =
far composed entirely of IANA registered properties with proprietary ones, =
i don't need to come up with property names (and we know what a PITA th=
at is) and it also saves time in the long run because it's less likely =
someone will open an issue about it.

Best,=

Filip


On Tue, 14 Apr 2020 at 22:09, Brian Campbel=
l <bcampbell=3D40pi=
ngidentity.com@dmarc.ietf.org> wrote:
Using PAR can facilitate=
 improved security by giving clients a (relatively) simple means for sendin=
g a confidential, integrity protected, and (for confidential clients anyway=
) authenticated authorization request.

It seems li=
ke some of that improved security could be undermined by a malicious actor =
somehow getting a user to navigate to a URL of a regular old parameterized =
authorization request. One variation of the Mix-Up Attack does this https://tools.ietf.org/html/draft-ietf-oauth-secu=
rity-topics-15#section-4.4.1 for example and email, social media, onlin=
e forums, etc., are other ways a user might be tricked into following a mal=
iciously crafted link.=C2=A0

Following from that i=
t seems logical that an authorization server might want to restrict some cl=
ients from sending a regular parameterized authorization request and instea=
d require use of the PAR endpoint to initiate an authorization request. Som=
ething like this could, of course, be implemented as custom policy or confi=
guration in any AS. But I'm thinking it might be common enough to warra=
nt adding a client metadata parameter to the PAR draft specifically for it.=
 The metadata (and registered extensions) defined by  Dynamic Client Regist=
ration [RFC7591] has come to imply a general data model and expected associ=
ated behaviors for clients that is useful for authorization server implemen=
tations, even when the Dynamic Client Registration Protocol isn't direc=
tly in play. This particular situation seems like a good potential candidat=
e for a new such client metadata parameter that would indicate that the giv=
en client can only use a request_uri value obtained from the PAR endpoint t=
o initiate an authorization request. And that a regular old fashioned autho=
rization request from the given client would result in an error. 
=


Do the folks of this fine WG think something like this =
would be a worthwhile addition to the PAR draft?








<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--00000000000093f7ea05a3640a92--


From nobody Thu Apr 16 08:11:18 2020
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 E4BF73A0B24 for ; Thu, 16 Apr 2020 08:11:16 -0700 (PDT)
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sJ1t2tDPdIqB for ; Thu, 16 Apr 2020 08:11:14 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 460EF3A0B17 for ; Thu, 16 Apr 2020 08:11:13 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id u13so5288783wrp.3 for ; Thu, 16 Apr 2020 08:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EUnSTXXnq06RIW0qc129+5aNQOuGntCpGrbLD0f0QR8=; b=lWmbhhtQzSCNFxM/8QT4Hwn9WUmoPVAZerTNYoVaGZzSD/ZM6QNHwHwBzzMadbEe0O ArWCPXGZQBEK/HlNbaFV8NBNC33qAUombakktXi3uKtNmn7/JQtjxPpH9JLe6fL/k/YJ 8vbPNv8gYvqZnJ1ewEdu7xDPMqmmWCPCQjOcoHVrCLt5l/pBI7ecJguLN1rrXLeTElPU VYxRampGstmwy+/gh5QA9iTHL1RzR6xKDI6Y1l9A5b2u5QoZYgB844LPQOfXuQ9nnHGb +dzttxsAjCJmD7FwuAVmIh+3T5XHdA0/oDLYRW3QK1VtQN4skuFrhX0ckN/V2Xcm3xGE g8zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EUnSTXXnq06RIW0qc129+5aNQOuGntCpGrbLD0f0QR8=; b=b5jf4i+HLC1cK01pDE3pPgrkoK76nL8nf+p+29U6WYmtTqbTsJOe1ew6/NDf3dQZSI h/LpLrNzKhFUIiyEZweKlS7JV1rJecnxxEurX3WCcC2thU08wK1pj/pbhR2BneXcW+z2 qSxuETsHbtl8eAeqKCw0U/c3vK6/RQqFT7jKSjSaEaMFduyH0r7UrYC/2USPioOFRBB1 rlnBwqBFv1G4lwgs1AxyYq9St9Dw+fkM22Hm+or63Xk0bsNUQwJI9nBAu2o/1CkV0e9z gFYaXGb8GzgZqiMUu1XTeuIGX5HHRThyp/hh8uzEh1FpW7ms8YETCs7Lfa0fzIpxT2F3 1fDg==
X-Gm-Message-State: AGi0PubpADlVAO/JnPaLFHstKgrR3Rymevft+dJ4EQSkThTyazztLM1F uNpLmmiVTjmH0YmyM2dIDABvkYcL/2s1a/mo2M9o+kVL
X-Google-Smtp-Source: APiQypIQWB1hQZeJsAdcP8NL78eRUCXegp9qAQfwCGcRJBf8EXKEeDjQYZV62J+o8Cg/3W3gROapYDpCDoSzMbc82Tg=
X-Received: by 2002:adf:b78b:: with SMTP id s11mr33825091wre.235.1587049871641;  Thu, 16 Apr 2020 08:11:11 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Sascha Preibisch 
Date: Thu, 16 Apr 2020 08:10:42 -0700
Message-ID: 
To: Filip Skokan 
Cc: Brian Campbell , oauth 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 15:11:17 -0000

I am also in favour of such metadata.

I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_uri only. This may be
a implementation detail of the AS, just wanted to mention it.

Regards,
Sascha

On Thu, 16 Apr 2020 at 01:16, Filip Skokan  wrote:
>
> I would support defining a client level property. I would also support an=
 AS discovery property for an AS-wide policy that is signalled to all clien=
ts (and maybe that one would be enough).
>
> FWIW (and this touches my earlier responses about the dpop scheme) defini=
ng metadata (both AS and Client) is beneficial not only for runtime (DCR, d=
iscovery) but in general supports developers using these specs, when they r=
ead about a possible behaviour in the document and there's a mentioned meta=
data property, they know what to look for in readmes, API documentation, UI=
 etc. It saves time, theirs, and mine when i develop those behaviour toggle=
s - i don't have to start mixing configuration objects so far composed enti=
rely of IANA registered properties with proprietary ones, i don't need to c=
ome up with property names (and we know what a PITA that is) and it also sa=
ves time in the long run because it's less likely someone will open an issu=
e about it.
>
> Best,
> Filip
>
>
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell  wrote:
>>
>> Using PAR can facilitate improved security by giving clients a (relative=
ly) simple means for sending a confidential, integrity protected, and (for =
confidential clients anyway) authenticated authorization request.
>>
>> It seems like some of that improved security could be undermined by a ma=
licious actor somehow getting a user to navigate to a URL of a regular old =
parameterized authorization request. One variation of the Mix-Up Attack doe=
s this https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#sect=
ion-4.4.1 for example and email, social media, online forums, etc., are oth=
er ways a user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might =
want to restrict some clients from sending a regular parameterized authoriz=
ation request and instead require use of the PAR endpoint to initiate an au=
thorization request. Something like this could, of course, be implemented a=
s custom policy or configuration in any AS. But I'm thinking it might be co=
mmon enough to warrant adding a client metadata parameter to the PAR draft =
specifically for it. The metadata (and registered extensions) defined by Dy=
namic Client Registration [RFC7591] has come to imply a general data model =
and expected associated behaviors for clients that is useful for authorizat=
ion server implementations, even when the Dynamic Client Registration Proto=
col isn't directly in play. This particular situation seems like a good pot=
ential candidate for a new such client metadata parameter that would indica=
te that the given client can only use a request_uri value obtained from the=
 PAR endpoint to initiate an authorization request. And that a regular old =
fashioned authorization request from the given client would result in an er=
ror.
>>
>> Do the folks of this fine WG think something like this would be a worthw=
hile addition to the PAR draft?
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg=
ed material for the sole use of the intended recipient(s). Any review, use,=
 distribution or disclosure by others is strictly prohibited...  If you hav=
e received this communication in error, please notify the sender immediatel=
y by e-mail and delete the message and any file attachments from your compu=
ter. Thank you._______________________________________________
>> 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


From nobody Thu Apr 16 08:39:59 2020
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 2F1AD3A0CB3 for ; Thu, 16 Apr 2020 08:39:57 -0700 (PDT)
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=pingidentity.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 6pOIkFCCZUXP for ; Thu, 16 Apr 2020 08:39:54 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 678C03A0CB2 for ; Thu, 16 Apr 2020 08:39:54 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id f8so5892904lfe.12 for ; Thu, 16 Apr 2020 08:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LdsPdkT9toHabqqnuNxge7xsa++fK4Dg6JgJW74X0zc=; b=KkagIaWuqwOksjlpBx2p6fqGVQ+cgW+6gBFlssS27jXLN70Sn1hy2Sp/qFiBMDkPhG ws3fZ+JgilANjyth0Zm2a7uWRmzh5W0+MwzpNeh8ONw7SPtF5KiI1gjq44pe+pDhsq+S a1Z5dPUuUe1U+FGP9kn4rncYPwhTfU4o0SNynQIaCYxvyszCYP6X/EYtPjrwhV8Rzvqv ll8slUsLFzGbWnc9a9S0wCZ9UvkDEOiDCCPqTNHjtFNw0lEy4nF3TYy4Q1g67K0IGFY5 21zg30a6TavEClvdYpsSSWqKf0QnFeDWZEbjANQz4tlOtBBhRBYg2oqLBSFa6guEovC1 2ZrQ==
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=LdsPdkT9toHabqqnuNxge7xsa++fK4Dg6JgJW74X0zc=; b=jKTezq+cUscBSoZHu+8nibs4EnnT9z5bryuj1g+VUyHdmSoqndp7caZ9IOrFKmAAit AyUnngUoxZUO3dlvoa0PTEC2EoAKEFGL72yg2KWm8nsFAZO7SlYj49xayMrbd9fpcBoK sKDjau4Tt/QTsG5iWVc4KHOvyWd4oAySRf3N171jLmkuIvIbkFvzbYgM8OhTNAUW/o0A clFcGnAajNJntUnyaI7jIIr5p10lkTfHEAdhQNytpT9gqlpQcmPZ6KUH45lNM4gt/rTg 9zO12upnbP4Qy2Bn4aEOrA8QzlAfXWCVQBlNNI2NywvTwoI6mBN3z6Vp9UG9TJpDOgwX Ujfw==
X-Gm-Message-State: AGi0PuZzKh6T7pJGI1E3haLohqzpWOXu4s6fyuJctW13fll4l6/gSTtp L8iilH43mdXmqN246+KvofSbo1cbt/NnqgkgmspZ7ypBhwEmnWaxXoLLn4W0a2V9nmaAJ0SaBUh BSp+ardLGHLgYVw==
X-Google-Smtp-Source: APiQypJ63aV/n1f4WkOuixxyQ/vt6Fa5T7z3l13aAdhpDsxXBde1ZQOjSksbft2VlB7klHu5lP36oC0Z3jW1qK37mns=
X-Received: by 2002:ac2:46e5:: with SMTP id q5mr6540980lfo.11.1587051592399; Thu, 16 Apr 2020 08:39:52 -0700 (PDT)
MIME-Version: 1.0
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>
In-Reply-To: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>
From: Brian Campbell 
Date: Thu, 16 Apr 2020 09:39:26 -0600
Message-ID: 
To: "Richard Backman, Annabelle" 
Cc: Vladimir Dzhuvinov , oauth 
Content-Type: multipart/alternative; boundary="00000000000067ec3305a36a3eb4"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 15:39:57 -0000

--00000000000067ec3305a36a3eb4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  wrote:

> As I think through this, I=E2=80=99m struggling to identify the threats t=
his
> actually helps mitigate.
>
> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won=E2=80=99t already know v=
ia other
> means whether or not it needs to use PAR. That means we=E2=80=99re only t=
alking
> about dynamic clients since statically registered clients already have so=
me
> proprietary out-of-band registration mechanism (e.g., a developer console=
).
>

As I tried to articulate in the original email and Filip also mentioned in
a different fork of this email thread, defining metadata can be beneficial
even when it's not used dynamically at runtime. So we're not only talking
about dynamic clients.



>
> A client metadata parameter also implies that the AS allows some clients
> to make non-PAR requests (otherwise it would be an AS metadata parameter)=
.
>

A per client setting seems necessary for existing ASs to roll out PAR
support over time or just generally in support of diverse client
capabilities and requirements.



> If that=E2=80=99s the case then presumably a malicious party could regist=
er their
> own client that doesn=E2=80=99t use PAR.
>
> So it seems to me that the only scenario that this parameter would protec=
t
> against is a malicious party impersonating a dynamically registered clien=
t
> that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in that attac=
k the
> attacker uses its own client.
>

This client metadata parameter is meant to be something that would prevent
a malicious actor from controlling the content of the authz request
parameters, which could be done by crafting the link and tricking a user
into following it. I mentioned mix-up as an example because the first
variant of it desribed at
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4=
.1
does something along those lines.



>
> If a client can do PAR, then it can do authorization code grant and PKCE,
> so we=E2=80=99re further limited to scenarios where the attacker does not=
 need to
> be able to redeem the authorization code themselves. What threats fall in=
to
> this category?
>
> =E2=80=94
> Annabelle Backman (she/her)
> AWS Identity
>
> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
> =EF=BB=BF
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and kno=
w
> the content is safe.
>
> I was hoping to get to a rough consensus in support of the idea before
> coming up with a name that everyone will hate :)
>
> In the meantime, however, name suggestions are of course welcome.
>
>
> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
>
>> I'm all for that.
>>
>> I suppose you have already thought of a suitable name? :)
>>
>> Vladimir
>> On 14/04/2020 23:08, Brian Campbell wrote:
>>
>> Using PAR can facilitate improved security by giving clients a
>> (relatively) simple means for sending a confidential, integrity protecte=
d,
>> and (for confidential clients anyway) authenticated authorization reques=
t.
>>
>> It seems like some of that improved security could be undermined by a
>> malicious actor somehow getting a user to navigate to a URL of a regular
>> old parameterized authorization request. One variation of the Mix-Up Att=
ack
>> does this
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
4.4.1
>> 
>> for example and email, social media, online forums, etc., are other ways=
 a
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might
>> want to restrict some clients from sending a regular parameterized
>> authorization request and instead require use of the PAR endpoint to
>> initiate an authorization request. Something like this could, of course,=
 be
>> implemented as custom policy or configuration in any AS. But I'm thinkin=
g
>> it might be common enough to warrant adding a client metadata parameter =
to
>> the PAR draft specifically for it. The metadata (and registered extensio=
ns)
>> defined by Dynamic Client Registration [RFC7591] has come to imply a
>> general data model and expected associated behaviors for clients that is
>> useful for authorization server implementations, even when the Dynamic
>> Client Registration Protocol isn't directly in play. This particular
>> situation seems like a good potential candidate for a new such client
>> metadata parameter that would indicate that the given client can only us=
e a
>> request_uri value obtained from the PAR endpoint to initiate an
>> authorization request. And that a regular old fashioned authorization
>> request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a
>> worthwhile addition to the PAR draft?
>>
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
..
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.*
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000067ec3305a36a3eb4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Apr 15, 2020 at 1:44 PM Richa=
rd Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> wrote:







As I think through this, I=E2=80=99m struggling to identif=
y the threats this actually helps mitigate.







A client metadata parameter implies that the value may be =
different for different clients, and that any given client won=E2=80=99t al=
ready know via other means whether or not it needs to use PAR. That means w=
e=E2=80=99re only talking about dynamic clients since
 statically registered clients already have some proprietary out-of-band re=
gistration mechanism (e.g., a developer console).


As I tried to articulate in th=
e original email and Filip also mentioned in a different fork of this email=
 thread, defining metadata can be beneficial even when it's not used dy=
namically at runtime. So we're not only talking about dynamic clients.<=
/div>

=C2=A0





A client metadata parameter also implies that the AS allows some clien=
ts to make non-PAR requests (otherwise it would be an AS metadata parameter=
).

A per client setting s=
eems necessary for existing ASs to roll out PAR support over time or just g=
enerally in support of diverse client capabilities and requirements. 

=C2=A0
 If that=E2=80=99s the c=
ase then presumably a malicious party could register their own client that =
doesn=E2=80=99t use PAR.







So it seems to me that the only scenario that this parameter would pro=
tect against is a malicious party impersonating a dynamically registered cl=
ient that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in that at=
tack the attacker uses its own client.
<=
br>
This client metadata parameter is meant to be something that =
would prevent a malicious actor from controlling the content of the authz r=
equest parameters, which could be done by crafting the link and tricking a =
user into following it. I mentioned mix-up as an example because the first =
variant of it desribed at https://tools.ietf.org/html/draft-=
ietf-oauth-security-topics-15#section-4.4.1 does something along those =
lines. 

=C2=A0







If a client can do PAR, then it can do authorization code grant and PK=
CE, so we=E2=80=99re further limited to scenarios where the attacker does n=
ot need to be able to redeem the authorization code themselves. What threat=
s fall into this category?







=E2=80=94






Annabelle Backman=
=C2=A0(she/her)


AWS Identity







On Apr 14, 2020, at 2:44 PM, Brian Campbell <b=
campbell=3D40pingidentity.com@dmarc.ietf.org> wrote:










=EF=BB=BF









=
CAUTION: This email originated from outside of the organization. Do no=
t click links or open attachments unless you can confirm the sender and kno=
w the content is safe.
















I was hoping to get to a rough consensus in support of the idea before=
 coming up with a name that everyone will hate :)










In the meantime, however, name suggestions are of course welcome. 












On Tue, Apr 14, 2020 at 2:22 PM Vladi=
mir Dzhuvinov <vladimir@connect2id.com> wrote:








I'm all for that.


I suppose you have already thought of a suitable name? :)


Vladimir




On 14/04/2020 23:08, Brian Campbell wrote:








Using PAR can facilitate improved security by giving clients a (relati=
vely) simple means for sending a confidential, integrity protected, and (fo=
r confidential clients anyway) authenticated authorization request.







It seems like some of that improved security could be undermined by a =
malicious actor somehow getting a user to navigate to a URL of a regular ol=
d parameterized authorization request. One variation of the Mix-Up Attack d=
oes this

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4=
.1 for example and email, social media, online forums, etc., are other =
ways a user might be tricked into following a maliciously crafted link.=C2=
=A0







Following from that it seems logical that an authorization server migh=
t want to restrict some clients from sending a regular parameterized author=
ization request and instead require use of the PAR endpoint to initiate an =
authorization request. Something
 like this could, of course, be implemented as custom policy or configurati=
on in any AS. But I'm thinking it might be common enough to warrant add=
ing a client metadata parameter to the PAR draft specifically for it. The m=
etadata (and registered extensions)
 defined by Dynamic Client Registration [RFC7591] has come to imply a gener=
al data model and expected associated behaviors for clients that is useful =
for authorization server implementations, even when the Dynamic Client Regi=
stration Protocol isn't directly
 in play. This particular situation seems like a good potential candidate f=
or a new such client metadata parameter that would indicate that the given =
client can only use a request_uri value obtained from the PAR endpoint to i=
nitiate an authorization request.
 And that a regular old fashioned authorization request from the given clie=
nt would result in an error.










Do the folks of this fine WG think something like this would be a wort=
hwhile addition to the PAR draft?



























CONFIDENTIALITY NOTICE: This email may contain co=
nfidential and privileged material for the sole use of the intended recipie=
nt(s). Any review, use, distribution or disclosure by others is strictly pr=
ohibited..=C2=A0 If you have received this
 communication in error, please notify the sender immediately by e-mail and=
 delete the message and any file attachments from your computer. Thank you.=






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








_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth







CONFIDENTIALITY
 NOTICE: This email may contain confidential and privileged material for th=
e sole use of the intended recipient(s). Any review, use, distribution or d=
isclosure by others is strictly prohibited..=C2=A0 If you have received thi=
s communication in error, please notify
 the sender immediately by e-mail and delete the message and any file attac=
hments from your computer. Thank you.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

















<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000067ec3305a36a3eb4--


From nobody Thu Apr 16 09:38:24 2020
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 0469B3A0E4B for ; Thu, 16 Apr 2020 09:38:22 -0700 (PDT)
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=pingidentity.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 6-ZX_FTlvNIt for ; Thu, 16 Apr 2020 09:38:19 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 A89DE3A0E4A for ; Thu, 16 Apr 2020 09:38:19 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id t11so6082575lfe.4 for ; Thu, 16 Apr 2020 09:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYA5jGC/BBuv+BgsdnDOyFUbDABX/dfGZbyVW1MGdvU=; b=crx2Q8E4OzRrmFWxQZZqVqUlEhCrLmACjfCQL+wAhlUB5DWXo+kRo5IOkHRiTQuCG9 r+3bT+WDi8E0RXWwCf47Y6XR4d2hO7fAnNdZcCEMBRhyQp3qUpUCuNm25skDhVJ95Ouh UQlBkNB3JZqcfzQ8yNHbinz4nzz4+DrFTgz+yQPYAWPfRUlw7F6WVie7ukmj3heI0s9Z qdyxgnYU+0P/3gd7qLCuJmoMZrc8ih0fD0DJZp52D1x+/aNaTYDLCnbsmsRcWKlz9VxQ BEhkAzb5l0Kc9dM1eyM7RKl+pihxHNExUT36BVv0OtaMMCTRCA+DhelVsqOgjN9esjun ENyQ==
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=DYA5jGC/BBuv+BgsdnDOyFUbDABX/dfGZbyVW1MGdvU=; b=H9WwAexMcu/osBIKpEizY1LdGEgX7iLPNLF113xeG1NgDIpAZLTY6s+F1WNP6ePfMj 3hKepsQQfXyhS79IoauggMH60RWn+1IYM9fz/FPUD51iYeGYOZp5z7WnUZN6tW2GwJaQ KyklAwYzliqz+D7u8R9w59U0hZh6WrdQF8uN07aSq9TxH1zx9Ryitjr24MZxj/x8+9Oi QEN2w3QRn0ZoCaN5I+WpRna5zAgYTUaMlcm0K7fETKLFR8Za3xrH29xKOSQw1LXLkauW veKy/1RlZtSnpAvHMibElb07qxTZ/owHhUI9WSAPkpzHEDPS4FmpwLew4Up2o64l+iTM bKUw==
X-Gm-Message-State: AGi0PuayxEDleRWGhx6UHJX2pPFSsg/52M84GunNbX50HTzNOKy2B/bI n5tSsXxAbG5PwQ7XCEll4MuFEKFpg/ncp2fsBBvQzsO6kaM7B7fIqDSh3RxoTwgGyhky3irQn+9 OkpYKVdp9euNtrw==
X-Google-Smtp-Source: APiQypLRvYCQJhwfoFmsmBIAasA3vKGM+4Kmvhthv+Mrh2pBaP7c+wKPZIGjC7QHzDxgBN/b9u2crRMj6UryrsGsQ0I=
X-Received: by 2002:a19:40ca:: with SMTP id n193mr6422955lfa.196.1587055097574;  Thu, 16 Apr 2020 09:38:17 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 16 Apr 2020 10:37:50 -0600
Message-ID: 
To: Filip Skokan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000549d0a05a36b0f9b"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 16 Apr 2020 16:38:22 -0000

--000000000000549d0a05a36b0f9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Filip for the replies. I'll add this to the growing list of todos
for a coming revision of the draft.

On Thu, Apr 16, 2020 at 2:06 AM Filip Skokan  wrote:

> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>> Would it have really helped this situation, if it'd stuck with "bearer"?=
 Or
>> would it just be less obvious?
>>
>
> If we had stuck "bearer" than i wouldn't have raised this topic, since
> existing RS would most likely ignore the cnf claim and the resource serve=
r
> calls would continue to work, obviously without taking advantage of the
> available sender check.
>
> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't suppo=
rt
>> DPoP. Which isn't really what you were asking about. But maybe would cov=
er
>> some of the same ground.
>
>
> I agree.
>
>  The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help t=
he
>> situation?
>
>
> :facepalm: indeed, sorry.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
> wrote:
>
>> Hi Filip,
>>
>> My attempts at responses to your questions/comments are inline:
>>
>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>
>>> I've wondered about the decision to use a new scheme before
>>>  but
>>> this time i'd like to challenge the immediate usability of the future s=
pec
>>> for one specific case - sender constraining public client Refresh Token=
s.
>>>
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>> Would it have really helped this situation, if it'd stuck with "bearer"?=
 Or
>> would it just be less obvious?
>>
>>
>>>
>>> If at all, it is going to take time for RS implementations to recognize
>>> the new `DPoP` authorization scheme, let alone process it properly. In =
the
>>> meantime, i'd still like to have the option to bind issued public clien=
t
>>> refresh tokens using DPoP without affecting the access tokens. In doing=
 so
>>> i get an immediate win in sender constraining the refresh tokens but no=
t
>>> introducing a breaking change for the RS.
>>>
>>>
>>>    - Do you see this as something an AS implementation is just free to
>>>    do since it's both the issuer and recipient of a refresh token?
>>>
>>> That's my first thought, yes.
>>
>>
>>>
>>>    - Should this be somehow baked in the draft?
>>>
>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>> say though.
>>
>> In such a case the AS could bind the RT to the given dpop proof and
>> either not bind the AT while returning token_type=3DBearer or bind the A=
T
>> while returning token_type value DPoP. In the latter case the AT would
>> almost certainly still work as a bearer token at the RS and the client t=
hat
>> knew the RS's needs could send it as such with an `Authorization: Bearer
>> `. Or if it didn't know the RS's needs, it could start with
>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>> Bearer` at which point it could send `Authorization: Bearer `.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't suppo=
rt
>> DPoP. Which isn't really what you were asking about. But maybe would cov=
er
>> some of the same ground.
>>
>>
>>
>>>
>>>    - Do you think client registration metadata could be used to signal
>>>    such intent?
>>>
>>> I think it certainly could. But it seems maybe too specific to warrant
>> metadata.
>>
>>
>>>
>>>    - Do you think the protocol should have signals in the messages
>>>    themselves to say what the client wants to apply DPoP to?
>>>
>>> My initial thought here is no. Take the case of a client working with a=
n
>> AS that supports DPoP and one RS that does and one RS that doesn't. I ca=
n't
>> really even think what signaling might look like there or how it could b=
e
>> made to be generally useful.
>>
>>
>>>
>>>    - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>    Do we disqualify such cases or allow for sending two proofs, one for=
 the AS
>>>    to bind refresh tokens to, one for the RS to bind access tokens to?
>>>
>>> The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help t=
he
>> situation?
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
.
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000549d0a05a36b0f9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Filip for the replies. I'll add this to the gro=
wing list of todos for a coming revision of the draft. 

On Thu, Apr 16, =
2020 at 2:06 AM Filip Skokan <panv=
a.ip@gmail.com> wrote:
I'm still somewhat on the fence a=
s to the pros and cons of using a new token type and authorization scheme. =
But the draft has gone with a new one. Would it have really helped this sit=
uation, if it'd stuck with "bearer"? Or would it just be less=
 obvious?

If we had stuck "beare=
r" than i wouldn't have raised this topic, since existing RS would=
 most likely ignore the cnf claim and the resource server calls would conti=
nue to work, obviously without taking advantage of the available sender che=
ck.

As I wrote the preceding rambling paragraph I am starting to think that=
 more should be said in the draft about working with RSs that don't sup=
port DPoP. Which isn't really what you were asking about. But maybe wou=
ld cover some of the same ground.

I agree.<=
/div>

=C2=
=A0The AS is the one that does the binding (which includes checking the pro=
of) so I don't see how sending two proofs would really work or help the=
 situation?

:facepalm: indeed, sorry.=C2=A0=


S pozdravem,
Fili=
p Skokan


On Tue, 14 Apr 2020 at 23:39, Brian Campbell =
<bcampbe=
ll@pingidentity.com> wrote:
Hi Filip, 

My attempts at responses to your questions/comments are inline:

On=
 Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'v=
e wondered about the decision to use a new scheme=C2=A0before=C2=A0but this time i'd like to challenge the immedi=
ate usability of the future spec for one specific case - sender constrainin=
g public client Refresh Tokens.

=

I'm still somewhat on the fence as to the pros and cons of using a=
 new token type and authorization scheme. But the draft has gone with a new=
 one. Would it have really helped this situation, if it'd stuck with &q=
uot;bearer"? Or would it just be less obvious? 
=C2=A0

If at all, it is going to take time for RS implementations to recogniz=
e the new `DPoP` authorization scheme, let alone process it properly. In th=
e meantime, i'd still like to have the option to bind issued public cli=
ent refresh tokens using DPoP without affecting the access tokens. In doing=
 so i get an immediate win in sender constraining the refresh tokens but no=
t introducing a breaking change for the RS.

  • Do you see this =
as something an AS implementation is just free to do since it's both th=
e issuer and recipient of a refresh token?
That's my first thought, yes. 
=C2=A0
  •  S=
hould this be somehow baked in the draft?
I'm not sure. Do you think it needs to be? I'm not sure what =
it would say though. 

In such a case the AS co=
uld bind the RT to the given dpop proof and either not bind the AT while re=
turning token_type=3DBearer or bind the AT while returning token_type value=
 DPoP. In the latter case the AT would almost certainly still work as a bea=
rer token at the RS and the client that knew the RS's needs could send =
it as such with an `Authorization: Bearer <at>`. Or if it didn't =
know the RS's needs, it could start with `Authorization: DPoP <at>=
;` which would get a 401 with `WWW-Authenticate: Bearer` at which point it =
could send `Authorization: Bearer <at>`. 

As I wrote the preceding rambling paragraph I am starting to think that m=
ore should be said in the draft about working with RSs that don't suppo=
rt DPoP. Which isn't really what you were asking about. But maybe would=
 cover some of the same ground. 
=C2=A0
=C2=A0<=
/div>
  • Do you think client registration metadata could be used to signal=
 such intent?
I think it certainly c=
ould. But it seems maybe too specific to warrant metadata. 
=
=C2=A0
  • Do you think the protocol should have signals in the messa=
ges themselves to say what the client wants to apply DPoP to?
My initial thought here is no. Take the case of a=
 client working with an AS that supports DPoP and one RS that does and one =
RS that doesn't. I can't really even think what signaling might loo=
k like there or how it could be made to be generally useful.
=
=C2=A0
  • What if AS and RS don't have a shared support DPoP JWS=
 Algorithm? Do we disqualify such cases or allow for sending two proofs, on=
e for the AS to bind refresh tokens to, one for the RS to bind access token=
s to?
The AS is the one that does th=
e binding (which includes checking the proof) so I don't see how sendin=
g two proofs would really work or help the situation? 
=C2=A0=





CONFIDENTIALITY NOTICE: This email m=
ay contain confidential and privileged material for the sole use of the int=
ended recipient(s). Any review, use, distribution or disclosure by others i=
s strictly prohibited.=C2=A0 If you have received this communication in err=
or, please notify the sender immediately by e-mail and delete the message a=
nd any file attachments from your computer. Thank you.






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000549d0a05a36b0f9b--


From nobody Thu Apr 16 12:09:01 2020
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 1C9483A0DA7 for ; Thu, 16 Apr 2020 12:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQOB-3sea1Gz for ; Thu, 16 Apr 2020 12:08:58 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4F9643A0D9F for ; Thu, 16 Apr 2020 12:08:58 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id n10so22235937iom.3 for ; Thu, 16 Apr 2020 12:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/1l/Mp0R59Le6EBfxIJMJmpiRA9qMbVfXqcIcDOUgA=; b=GYq1hpBLGD43tuNHLyV97Uy7h0r5gUGLG9lNhRavIQIhPbQtJZAh3BxXwQB1droApe 6afK/V/aGpIr11/4HxMYRRbLovZXV2QytdjRRN2W4MAy5zQXi8KNIiEKFoKU5NG5YHjR yskLBVqrCSVVeJDfRmJxwldmpgF1GUdXBdIDxC2d5KvXgbNM5RDVhpyg6sJFk0pzQV4T e9rwj3I7NxtYMxVeWSe1FM7n3R+5k8yttOuIZ6lASPIczgZkT6fEAXKGOS4Ns9Twf1p0 xScHHhTI8ICmMmgns6gMKlq5Ifnc3XBTSFMqToWgcgykeoBVoCR/wktWpYB5kPxJW4z3 LWyQ==
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=G/1l/Mp0R59Le6EBfxIJMJmpiRA9qMbVfXqcIcDOUgA=; b=qs5VnrzNcY6hzM+xPTEyHbz4hQHmqUOrt8vxfxF7Q8gqgXRnZsHDuvd+a1vtGMA+CE egLk6oqJOu1dlyZGufeCylzIUKXv7P/ejgNUbp9VbwlCBC04Kts3+JGOJvj6BKMmm8D/ C4n7Oien3Rz9XNewsJzrXutaL+bc48GAvNoWSq6EY1ZDnFdfbEnk/zliAmlpejIgbnEC SsX11EYBpDVhK64WvngUcsarkBUmCVa/sS1kl2cFiJMD5mKXzzz2qq1B2GrxQqgMnS+F 1EUBkcVufjNpdxqmJomoeCbT/vvyfuedfKKs7sxVOdE6jnIoN9BPrGdgYp6Jnx0ZBSLx 7KDw==
X-Gm-Message-State: AGi0PuZzsd1fp4KdmgGRABPUaIqw3k4rP9U471d7g8nB1sfqQpySYAV8 6O6Sp10AvWxkvueZw/ivWBpUe9amxOE=
X-Google-Smtp-Source: APiQypI/Q7O7uxkYNjURz6Z5h9zJi7aux8FzrBgRSspHmVRDDF83KGoPTxBQBE/fwX7K8YHDfNZA0w==
X-Received: by 2002:a05:6638:22a:: with SMTP id f10mr32621935jaq.59.1587064136624;  Thu, 16 Apr 2020 12:08:56 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id h13sm6569320iom.39.2020.04.16.12.08.55 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 12:08:55 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id n10so22235807iom.3 for ; Thu, 16 Apr 2020 12:08:55 -0700 (PDT)
X-Received: by 2002:a02:6a1a:: with SMTP id l26mr16489287jac.122.1587064134802;  Thu, 16 Apr 2020 12:08:54 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Thu, 16 Apr 2020 12:08:43 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000fda6c305a36d2920"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 16 Apr 2020 19:09:00 -0000

--000000000000fda6c305a36d2920
Content-Type: text/plain; charset="UTF-8"

Section 2.1 says:

> Although JWT access tokens can use any signing algorithm, use of
> asymmetric algorithms is RECOMMENDED

Can this be strengthened to disallow the `none` algorithm? Something like
adding "... and MUST NOT use the "none" algorithm".

Given that the JWT BCP doesn't disallow the "none" algorithm, technically
someone could follow both this JWT Access Token spec and the JWT BCP spec
and end up with an implementation that allows an AS to accept JWTs with the
"none" algorithm.

----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef 
wrote:

> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000fda6c305a36d2920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Section 2.1 says:

> Altho=
ugh JWT access tokens can use any signing algorithm, use of
> asymm=
etric algorithms is RECOMMENDED

Can this be strengthened=
 to disallow the `none` algorithm? Something like adding "... and MUST=
 NOT use the "none" algorithm".

Giv=
en that the JWT BCP doesn't disallow the "none" algorithm, te=
chnically someone could follow both this JWT Access Token spec and the JWT =
BCP spec and end up with an implementation that allows an AS to accept JWTs=
 with the "none" algorithm.

----
Aaron Parecki



On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<=
/div>
Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://to=
ols.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000fda6c305a36d2920--


From nobody Thu Apr 16 13:12:18 2020
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 33AC43A0853 for ; Thu, 16 Apr 2020 13:12:16 -0700 (PDT)
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=pingidentity.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 QccGtqaBmGSp for ; Thu, 16 Apr 2020 13:12:14 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 349883A0852 for ; Thu, 16 Apr 2020 13:12:14 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id j3so8785648ljg.8 for ; Thu, 16 Apr 2020 13:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7loZrpwwF7vZR/BUenwIMUqJXYNBWaepGvKXFb5zJeo=; b=fETX84BZl+qVyl2XV0MAqCikCYnStnuC1KH3Jz99ykoj3fJ21iNKVtbpqL72LyQzlp dsJaIYDxhS0WozzUiE5GuhN3v5ATJ2k9ADO/XL7x1NHweDHzeeyt2DvhiWy2gEVc/FVr b43ts87H5VkQDKfrmm7WS/DafbhSkVzq6Ut62oolR8mi442KLnvxxCNUiFTdjolXz4QN 0xWCdCbNOd3MO07MXTctG3OCM1AEMWB77OuP9gaWk6wWTF615w1J3ryHl/6fKjOkFgC0 fnF4Di8CRiQn501DBuP3YqeIdfk/DRmjswkQsR5xsu05ZzwSSMS3nVV6bzzYN9Uk24+X mWJg==
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=7loZrpwwF7vZR/BUenwIMUqJXYNBWaepGvKXFb5zJeo=; b=OE7Xxxmznv8+6n5RoECjz1sOM0SbTaFKdTljetDHr+Yar6jh9vdCAVG1msJJy7RuLO kfQCf8Ru41iYV0IBFlywlww1tigjC4H4HBWfXzD00zZq4JpQgWdnRuAOY2KWN4eauB/r KqasPfgruLTe5f4zNd4D6KjX1SidOvivL/hG6655WEAq8zajeHbUGsoxpGN+azLiudRx PPk8k+C6Bfy/kaM3y9S5vyD8ayRPHrKfVBugKHPHz9FYYfi8Der1cBMBJ6EY+VmfatEN Ic1d09lku1I5gS0nlcGzwB0ZA+aIDbgP9rfpZEsXDcyEYsbzFESfBnG0BR/+QadjrVJZ pqOA==
X-Gm-Message-State: AGi0PuYymBHJlA/k3S0guSDbIsYhkyO10vza028UhSgFXtBtFmK8sZgw 1ijnU0W0nyLLAgZ3kxEHTEQzpj5ojc4rxFtIdGGGnqi8tJlj6218nbnV4PpW35uE4u8FkZ4zWzV 9rvKUG7FxCAnXpw==
X-Google-Smtp-Source: APiQypJKQLByTP70wSvo/dG6YsqLI4HxbaxVWg2w7kXbuaBRmdelu01x6VbidUDcJpRThmQtGNatDDO3IqG5ohbfXac=
X-Received: by 2002:a2e:868b:: with SMTP id l11mr7598942lji.247.1587067932185;  Thu, 16 Apr 2020 13:12:12 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 16 Apr 2020 14:11:46 -0600
Message-ID: 
To: Aaron Parecki 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="000000000000554af305a36e0c79"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 16 Apr 2020 20:12:16 -0000

--000000000000554af305a36e0c79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

sec 4 does have "The resource server MUST reject any JWT in which the value
of "alg" is "none".'

On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki  wrote:

> Section 2.1 says:
>
> > Although JWT access tokens can use any signing algorithm, use of
> > asymmetric algorithms is RECOMMENDED
>
> Can this be strengthened to disallow the `none` algorithm? Something like
> adding "... and MUST NOT use the "none" algorithm".
>
> Given that the JWT BCP doesn't disallow the "none" algorithm, technically
> someone could follow both this JWT Access Token spec and the JWT BCP spec
> and end up with an implementation that allows an AS to accept JWTs with t=
he
> "none" algorithm.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
>
> On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef 
> wrote:
>
>> Hi all,
>>
>>
>>
>> This is a second working group last call for "JSON Web Token (JWT)
>> Profile for OAuth 2.0 Access Tokens".
>>
>>
>>
>> Here is the document:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>
>>
>>
>> Please send your comments to the OAuth mailing list by April 29, 2020.
>>
>>
>>
>> Regards,
>>
>>  Rifaat & Hannes
>>
>>
>> _______________________________________________
>> 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
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000554af305a36e0c79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


sec 4 does have "The resource server MUST reject any =
JWT in which the value of "alg" is "none".'
On Thu, =
Apr 16, 2020 at 1:09 PM Aaron Parecki <aaron@parecki.com> wrote:
Section 2.1 says:

=

> Although JWT access tokens can use any signing algorithm, u=
se of
> asymmetric algorithms is RECOMMENDED

Can=
 this be strengthened to disallow the `none` algorithm? Something like addi=
ng "... and MUST NOT use the "none" algorithm".

Given that the JWT BCP doesn't disallow the "non=
e" algorithm, technically someone could follow both this JWT Access To=
ken spec and the JWT BCP spec and end up with an implementation that allows=
 an AS to accept JWTs with the "none" algorithm.
<=
div dir=3D"ltr">

----
Aaron Parecki


On Wed, Apr 15, 2020 at 11:=
59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://to=
ols.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000554af305a36e0c79--


From nobody Thu Apr 16 13:14:09 2020
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 99FBB3A0FC7 for ; Thu, 16 Apr 2020 13:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v14cuLf-JlEP for ; Thu, 16 Apr 2020 13:14:05 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4F33A0F9B for ; Thu, 16 Apr 2020 13:14:05 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id 19so6585931ioz.10 for ; Thu, 16 Apr 2020 13:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4n2f8OWKgi9e06ssTmkN7EAN+bv2YTeSMxPsAMRdSSI=; b=ZfGD7gjWAjy3abnyJzEn7xkPMEh1q0X6sb7fFDtuzMX653OkvrI6pRPnyw4RDS6Y6i M2mxROzxllcYJrQAp0p7Oz9PDhm95ygY/wXP6y7Sb7T4er9aEm+27Yfe6XhmtPbd35pi +jxLEt3O6fG2/NE5NHDG3AlhGaXcNntVRyVgvV1rXRKICeWAi7m7i4g6IlFYO7g7vdvP QLSbguDL5coun40TtEj22OyaO6osB910YI3i0S/9+EbjdJrIisWhuQgFzXWOD2fD9FRR udg8baX9/lr6QYh6xi0rSvmCCuTeBVwLgLR6YeeNsYAnY9vsyN6MOBEFzvgZxknktfNe 4IHA==
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=4n2f8OWKgi9e06ssTmkN7EAN+bv2YTeSMxPsAMRdSSI=; b=JCoMnkV5l9k37glmj2JPB0j++bWndzBaoAbNaI+yq7M8OsR97qeBbYyODBQ4maygcR m7oqSpHb7URb+8jxiaF8YM9q3q8mcDdpkd8b7OSIwMRS7oENQ2DP/rXMMbETGbA1kine d+aIFmIXi4H8q1GKpVWPNk3+pp5x3oNx2Xjjzov4z2+PeVhK2Od4GRtPIy0ZQUqUaqEd /a2bhpT2JZbszkkVweE6eFnWfQeB9eykgHsMtfqoNtcGfnK2opYqBod/GTePkIknmXg3 Q9007FOc99qMzaRqiZyKKujx14+oiXuaYKGH7vQzy4UUZfcIZSGPqFS9aJXFLYhnkGRx W+6g==
X-Gm-Message-State: AGi0PuY5kYQrJjg4U2oVGzBOxgg0baWhRUkPGKBdhKX6M44m3xafxbEm RF8GVrnFoaj61vzVOP71MRiGm8BXx2U=
X-Google-Smtp-Source: APiQypK0MPUQe4eIWT605+n1lGKoYnSTBN6UIlez9MHr9wyz1/6OQHuROj8nTKunOF/eEBEwKaqkow==
X-Received: by 2002:a02:a68e:: with SMTP id j14mr67084jam.86.1587068043639; Thu, 16 Apr 2020 13:14:03 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com. [209.85.166.44]) by smtp.gmail.com with ESMTPSA id x15sm7376637ilg.29.2020.04.16.13.14.02 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 13:14:02 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id n10so22460787iom.3 for ; Thu, 16 Apr 2020 13:14:02 -0700 (PDT)
X-Received: by 2002:a6b:7f07:: with SMTP id l7mr12595900ioq.14.1587068042329;  Thu, 16 Apr 2020 13:14:02 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Aaron Parecki 
Date: Thu, 16 Apr 2020 13:13:51 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Brian Campbell 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="000000000000e5c55d05a36e12d7"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 16 Apr 2020 20:14:08 -0000

--000000000000e5c55d05a36e12d7
Content-Type: text/plain; charset="UTF-8"

My mistake! In that case, my request is editorial, to mention that in
section 2.1 where it first talks about signing algorithms.

----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell 
wrote:

> sec 4 does have "The resource server MUST reject any JWT in which the
> value of "alg" is "none".'
>
> On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki  wrote:
>
>> Section 2.1 says:
>>
>> > Although JWT access tokens can use any signing algorithm, use of
>> > asymmetric algorithms is RECOMMENDED
>>
>> Can this be strengthened to disallow the `none` algorithm? Something like
>> adding "... and MUST NOT use the "none" algorithm".
>>
>> Given that the JWT BCP doesn't disallow the "none" algorithm, technically
>> someone could follow both this JWT Access Token spec and the JWT BCP spec
>> and end up with an implementation that allows an AS to accept JWTs with the
>> "none" algorithm.
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>>
>>
>> On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <
>> rifaat.ietf@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> This is a second working group last call for "JSON Web Token (JWT)
>>> Profile for OAuth 2.0 Access Tokens".
>>>
>>>
>>>
>>> Here is the document:
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>>
>>>
>>>
>>> Please send your comments to the OAuth mailing list by April 29, 2020.
>>>
>>>
>>>
>>> Regards,
>>>
>>>  Rifaat & Hannes
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

--000000000000e5c55d05a36e12d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My mistake! In that case, my request is editorial, to ment=
ion that in section 2.1 where it first talks about signing algorithms.
=

----
Aaron Parecki
=

@aaronpk<=
/div>



On Thu, Apr 16, 2020 at 1:12 PM B=
rian Campbell <bcampbell@p=
ingidentity.com> wrote:
sec 4 does have "The resource server M=
UST reject any JWT in which the value of "alg" is "none"=
;.'

On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki <aaron@parecki.com> wrote:
Section 2.1 says:

> Although JWT access tokens=
 can use any signing algorithm, use of
> asymmetric algorithms is R=
ECOMMENDED

Can this be strengthened to disallow the `non=
e` algorithm? Something like adding "... and MUST NOT use the "no=
ne" algorithm".

Given that the JWT BCP d=
oesn't disallow the "none" algorithm, technically someone cou=
ld follow both this JWT Access Token spec and the JWT BCP spec and end up w=
ith an implementation that allows an AS to accept JWTs with the "none&=
quot; algorithm.

----
Aaron Parecki


=


On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>=
 wrote:
Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://to=
ols.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.


--000000000000e5c55d05a36e12d7--


From nobody Thu Apr 16 13:16:05 2020
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 F14933A086C for ; Thu, 16 Apr 2020 13:16:03 -0700 (PDT)
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=pingidentity.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 AuoIwG42ExUk for ; Thu, 16 Apr 2020 13:16:01 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 AA62F3A0FCD for ; Thu, 16 Apr 2020 13:16:00 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id v9so9206145ljk.12 for ; Thu, 16 Apr 2020 13:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aJUYg045nw/MA0tBonuU4JBCQX2WCc+eEzxIKKpXQ6k=; b=X/+ab6QTpVwN+CFrV1C24qdqbO9HIgzLQrVFUlIDU8/vbHvM4YqO/d6267VP7lzr58 TYEc/JtyLvxIq7pES5ti/rT6IYIppogjZwST7iWUi5/b5lO9e2Jw73/iD0ipRyXtw1r3 VP+BCwaICPkcw0Kv4ZBBIpdfukOtkoCEdDzvuER99Rg+kTiPo+G3bLrynacj+Zf6k6A9 TZIcU/K9r2bncMeIMGSMx3t+Ht1uKHCbpVGrLZpUsCDIfLtEjr1iEY3EwNKa3h/iNbWm bXL9zOp4pdaExJ5bVGBANL3zF5vzrLP922+Y26YgGItwGCphGp/oPdyC+DeYRQOaDrsn t6AA==
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=aJUYg045nw/MA0tBonuU4JBCQX2WCc+eEzxIKKpXQ6k=; b=sRG/Mon1DzxQL4EdEivQq2YcXEmkLDWJQsQ4iVqIGYYVVcpFDJ7SRAdifCjd31PzSz UX1bQ8gbGjkXecl9cCNp75F7W9IIIbs9LJPTTtsSGlLLyau0soURl5v58q6ac1lprJU7 GphHtZa84LOcLMIxU6C+tKrvyMEL4FpFbRvBdBianh0demOUiYIM4cxBFQ+dnip3eSiu /WecnWica4aEwffIHbF1sEyYMwtMojhx2xDpvsZ6NaLESdkA8Udl8Ux5seHFAQPpRWjH u5ljFDkrYIQwboadvFEs/lnqiB4jyaN6JA4W8yjKO4dLh0ESWeQgSwRtLE/EZu+W1wK/ BydA==
X-Gm-Message-State: AGi0PuYaJ7xujCjpOCiAWYGZ8xfk8qowGUeBdIP6nIPLo8bu05PO5ttQ w0fxli2BRbH/O3mJsdRgtIpqgqAgNEtZaBiALMeklgVZ7EFKSPd0bii+OfmoA7T9pLg6YEgHy3t 3dHApGK90CVdXbg==
X-Google-Smtp-Source: APiQypJ3ynie1m9UUTq/XI6szFsxNxbnfD8BGtvSkUbmvolscH7n7iQbGKE7ko+tQzNsn75hOD4Okzwd/Lw62blk1jM=
X-Received: by 2002:a2e:b0c6:: with SMTP id g6mr7489591ljl.96.1587068158736; Thu, 16 Apr 2020 13:15:58 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 16 Apr 2020 14:15:31 -0600
Message-ID: 
To: Aaron Parecki 
Cc: Rifaat Shekh-Yusef , oauth 
Content-Type: multipart/alternative; boundary="000000000000d611cb05a36e190a"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 16 Apr 2020 20:16:04 -0000

--000000000000d611cb05a36e190a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'll +1 that

On Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki  wrote:

> My mistake! In that case, my request is editorial, to mention that in
> section 2.1 where it first talks about signing algorithms.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
>
> On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell 
> wrote:
>
>> sec 4 does have "The resource server MUST reject any JWT in which the
>> value of "alg" is "none".'
>>
>> On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki  wrote:
>>
>>> Section 2.1 says:
>>>
>>> > Although JWT access tokens can use any signing algorithm, use of
>>> > asymmetric algorithms is RECOMMENDED
>>>
>>> Can this be strengthened to disallow the `none` algorithm? Something
>>> like adding "... and MUST NOT use the "none" algorithm".
>>>
>>> Given that the JWT BCP doesn't disallow the "none" algorithm,
>>> technically someone could follow both this JWT Access Token spec and th=
e
>>> JWT BCP spec and end up with an implementation that allows an AS to acc=
ept
>>> JWTs with the "none" algorithm.
>>>
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com
>>> @aaronpk 
>>>
>>>
>>>
>>> On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <
>>> rifaat.ietf@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> This is a second working group last call for "JSON Web Token (JWT)
>>>> Profile for OAuth 2.0 Access Tokens".
>>>>
>>>>
>>>>
>>>> Here is the document:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>>>
>>>>
>>>>
>>>> Please send your comments to the OAuth mailing list by April 29, 2020.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>  Rifaat & Hannes
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
.
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000d611cb05a36e190a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'll +1 that 

=

On Thu, Apr 16, 2020 at 2:14 PM Aaron=
 Parecki <aaron@parecki.com>=
 wrote:
My mistake! In that case, my request is editorial, to mention that=
 in section 2.1 where it first talks about signing algorithms.

----
Aaron Parecki
aaronparecki.com=




On Thu, Apr 16, 2020 at 1:1=
2 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
sec 4 does have &qu=
ot;The resource server MUST reject any JWT in which the value of "alg&=
quot; is "none".'

On Thu, Apr 16, 2020 at 1:09 PM Aaron Pareck=
i <aaron@parecki.=
com> wrote:
Section 2.1 says:

> Al=
though JWT access tokens can use any signing algorithm, use of
> as=
ymmetric algorithms is RECOMMENDED

Can this be strengthe=
ned to disallow the `none` algorithm? Something like adding "... and M=
UST NOT use the "none" algorithm".

=
Given that the JWT BCP doesn't disallow the "none" algorithm,=
 technically someone could follow both this JWT Access Token spec and the J=
WT BCP spec and end up with an implementation that allows an AS to accept J=
WTs with the "none" algorithm.

----
Aaron Parecki
<=
br>


On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shek=
h-Yusef <rifa=
at.ietf@gmail.com> wrote:
Hi all,



=C2=A0



This is a
second working group last call for "JSON Web Token (JWT) Profile for O=
Auth
2.0 Access Tokens".



=C2=A0



Here is the
document:



https://to=
ols.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send
your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=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






CONFIDENTIALITY NOTICE: This email m=
ay contain confidential and privileged material for the sole use of the int=
ended recipient(s). Any review, use, distribution or disclosure by others i=
s strictly prohibited.=C2=A0 If you have received this communication in err=
or, please notify the sender immediately by e-mail and delete the message a=
nd any file attachments from your computer. Thank you.






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000d611cb05a36e190a--


From nobody Thu Apr 16 13:50:53 2020
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 622D23A1091 for ; Thu, 16 Apr 2020 13:50:51 -0700 (PDT)
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=pingidentity.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 M4UdqJIgpNRI for ; Thu, 16 Apr 2020 13:50:49 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 17E2A3A108B for ; Thu, 16 Apr 2020 13:50:48 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id u6so7759634ljl.6 for ; Thu, 16 Apr 2020 13:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BVmn2cYpZe/vLi4WCB1rkp0StnqZ1A1Hy9RSuLdf9KE=; b=c9Szm3Trc/Uu51qliJ8YAmSXbL3GGIF7coC1f6mbOIEJ5Up4TD7dwVOhk8+xlmT8TU DeXhU/IUh7nTzl9BBhYkmvkNCYmPMmj9Q2A30xiknjdQnfNCPaC7VMyRgXOr5vepk2WO 8a/otjfbwaphwrJiiKXNYBeeQSmdjS46JkC7E0i+oD3GLLRP/lZf2SywhKDvljU3xkMH 9c9gLVLfS6jgIojV7CAN9yvqRc8gtcrj2xaDvdTAwTV5KS4MhtFN5tSd0HXJGKudMOCD b6DFi44tfZkfz1D4koIVk/L3Zt4QvxgCUmgL6LiboHGfmG9vCanUJwYjuU/odBirO1t1 H56A==
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=BVmn2cYpZe/vLi4WCB1rkp0StnqZ1A1Hy9RSuLdf9KE=; b=XrCGjYsJ26fJtrFoRqD+QN7AfmZc6ieIA7sDwqWCpSxCQI0In/rUxqw+mZAjZbe6HJ os0u81bgLWI8WOcEQIui+lOoKN1QCYB46g236sWgxFZ5Wj6cY6befzzQDeiEOg61AXH+ AuMpPklFdC55cj4mOy/Q9thUM1T44XDxk0raBtlvs9Hz6dsphuwGjEd5h4BEsGt1IZQK TWGH3PSDhPF6/vcu+KJT5c5f+bSdqvT+2AF+QQYL4oECupWZWdJOp1czb7G1C2J3bAAQ dVy6nK1i8YtAd1/jd11RlcWNKLqZZwGrUhQulwqWdDwu77B7Oc+bxuhWJnSSCeHPS8ZZ RZzQ==
X-Gm-Message-State: AGi0PuaMb5wB0or/06SV92DqstXoT7qOeiaA/ZB6klMq9uZsrJOBmq3e 7RG05WhkhTdMgNhfVzt/bRgnVwND2bSO55+V7k6jOOA8l4vbMhL4tXyXrVjDO8JTc74M6lrLWiu VKQtapWYBS/LynA==
X-Google-Smtp-Source: APiQypIDCY5qqgMi2a5J6Bd80uKBGQxt0IZWBPnqFZrwqxs78mM4IBYSExlRPWjFmz3UKaFYECcVLMFPKE9TnRNOPGo=
X-Received: by 2002:a2e:b8c1:: with SMTP id s1mr22532ljp.0.1587070247195; Thu, 16 Apr 2020 13:50:47 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 16 Apr 2020 14:50:20 -0600
Message-ID: 
To: Filip Skokan 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000517eb505a36e96a7"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 20:50:52 -0000

--000000000000517eb505a36e96a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 16, 2020 at 2:15 AM Filip Skokan  wrote:

> I would support defining a client level property. I would also support an
> AS discovery property for an AS-wide policy that is signalled to all
> clients (and maybe that one would be enough).
>

I do think there needs to be something at the client level for it to be
useful. My thinking was that one AS-wide policy would be too broad to be of
much use. Many existing ASs will need to roll out PAR support over time or
more generally just support diverse clients with different capabilities and
requirements including PAR forever. The AS can advertise support for PAR by
including a "pushed_authorization_request_endpoint" parameter. Which is
roughly consistent with other AS metadata that's mostly about advertising
the set of supported capabilities. But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


> FWIW (and this touches my earlier responses about the dpop scheme)
> defining metadata (both AS and Client) is beneficial not only for runtime
> (DCR, discovery) but in general supports developers using these specs, wh=
en
> they read about a possible behaviour in the document and there's a
> mentioned metadata property, they know what to look for in readmes, API
> documentation, UI etc. It saves time, theirs, and mine when i develop tho=
se
> behaviour toggles - i don't have to start mixing configuration objects so
> far composed entirely of IANA registered properties with proprietary ones=
,
> i don't need to come up with property names (and we know what a PITA that
> is) and it also saves time in the long run because it's less likely someo=
ne
> will open an issue about it.
>

That is good and useful perspective, thanks for sharing that.


Best,
> *Filip*
>
>
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
>> Using PAR can facilitate improved security by giving clients a
>> (relatively) simple means for sending a confidential, integrity protecte=
d,
>> and (for confidential clients anyway) authenticated authorization reques=
t.
>>
>> It seems like some of that improved security could be undermined by a
>> malicious actor somehow getting a user to navigate to a URL of a regular
>> old parameterized authorization request. One variation of the Mix-Up Att=
ack
>> does this
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
4.4.1
>> for example and email, social media, online forums, etc., are other ways=
 a
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might
>> want to restrict some clients from sending a regular parameterized
>> authorization request and instead require use of the PAR endpoint to
>> initiate an authorization request. Something like this could, of course,=
 be
>> implemented as custom policy or configuration in any AS. But I'm thinkin=
g
>> it might be common enough to warrant adding a client metadata parameter =
to
>> the PAR draft specifically for it. The metadata (and registered extensio=
ns)
>> defined by Dynamic Client Registration [RFC7591] has come to imply a
>> general data model and expected associated behaviors for clients that is
>> useful for authorization server implementations, even when the Dynamic
>> Client Registration Protocol isn't directly in play. This particular
>> situation seems like a good potential candidate for a new such client
>> metadata parameter that would indicate that the given client can only us=
e a
>> request_uri value obtained from the PAR endpoint to initiate an
>> authorization request. And that a regular old fashioned authorization
>> request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a
>> worthwhile addition to the PAR draft?
>>
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any f=
ile
>> attachments from your computer. Thank you.*
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000517eb505a36e96a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Apr 16, 2020 at 2:15 AM Filip=
 Skokan <panva.i=
p@gmail.com> wrote:
I would support defining a client level pr=
operty. I would also support an AS discovery property for an AS-wide policy=
 that is signalled to all clients (and maybe that one would be enough).

I do think there needs to be somet=
hing at the client level for it to be useful. My thinking was that one AS-w=
ide policy would be too broad to be of much use. Many existing ASs will nee=
d to roll out PAR support over time or more generally just support diverse =
clients with different capabilities and requirements including PAR forever.=
 The AS can advertise support for PAR by including a  "pushed_authoriz=
ation_request_endpoint" parameter. Which is roughly consistent with ot=
her AS metadata that's mostly about advertising the set of supported ca=
pabilities. But do you think that an AS-wide policy signal (i.e. all_yall_c=
lients_gotta_do_par_every_darn_time : true) is needed or sufficiently usefu=
l? 
=C2=A0
FWIW (and this touches my earlier res=
ponses about the dpop scheme) defining metadata (both AS and Client) is ben=
eficial not only for runtime (DCR, discovery) but in general supports devel=
opers using these specs, when they read about a possible behaviour in the d=
ocument and there's a mentioned metadata property, they know what to lo=
ok for in readmes, API documentation, UI etc. It saves time, theirs, and mi=
ne when i develop those behaviour toggles - i don't have to start mixin=
g configuration objects so far composed entirely of IANA registered propert=
ies with proprietary ones, i don't need to come up with property names =
(and we know what a PITA that is) and it also saves time in the long run be=
cause it's less likely someone will open an issue about it.
=


That is good and useful perspective, thank=
s for sharing that.=C2=A0 
=C2=A0

Best,
Filip


On Tue, 14 Apr 2020 at 22:09,=
 Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote=
:
Using PAR can facilitate improved security by giving clients a (rel=
atively) simple means for sending a confidential, integrity protected, and =
(for confidential clients anyway) authenticated authorization request.

It seems like some of that improved security could be =
undermined by a malicious actor somehow getting a user to navigate to a URL=
 of a regular old parameterized authorization request. One variation of the=
 Mix-Up Attack does this https://tools.iet=
f.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1 for exampl=
e and email, social media, online forums, etc., are other ways a user might=
 be tricked into following a maliciously crafted link.=C2=A0

=

Following from that it seems logical that an authorization serve=
r might want to restrict some clients from sending a regular parameterized =
authorization request and instead require use of the PAR endpoint to initia=
te an authorization request. Something like this could, of course, be imple=
mented as custom policy or configuration in any AS. But I'm thinking it=
 might be common enough to warrant adding a client metadata parameter to th=
e PAR draft specifically for it. The metadata (and registered extensions) d=
efined by  Dynamic Client Registration [RFC7591] has come to imply a genera=
l data model and expected associated behaviors for clients that is useful f=
or authorization server implementations, even when the Dynamic Client Regis=
tration Protocol isn't directly in play. This particular situation seem=
s like a good potential candidate for a new such client metadata parameter =
that would indicate that the given client can only use a request_uri value =
obtained from the PAR endpoint to initiate an authorization request. And th=
at a regular old fashioned authorization request from the given client woul=
d result in an error. 

Do the folks of this fi=
ne WG think something like this would be a worthwhile addition to the PAR d=
raft?




=





CONFIDENTIALITY NOTICE: This email m=
ay contain confidential and privileged material for the sole use of the int=
ended recipient(s). Any review, use, distribution or disclosure by others i=
s strictly prohibited...=C2=A0 If you have received this communication in e=
rror, please notify the sender immediately by e-mail and delete the message=
 and any file attachments from your computer. Thank you._=
______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth








<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000517eb505a36e96a7--


From nobody Thu Apr 16 14:07:33 2020
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 85E3E3A10FE for ; Thu, 16 Apr 2020 14:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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=aol.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 XFJJk7wvcxlX for ; Thu, 16 Apr 2020 14:07:27 -0700 (PDT)
Received: from sonic306-49.consmr.mail.ne1.yahoo.com (sonic306-49.consmr.mail.ne1.yahoo.com [66.163.189.111]) (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 6BA0E3A10FC for ; Thu, 16 Apr 2020 14:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587071246; bh=l7PfHBMpJbyoN2i51cF3CnWT2jnjXb2lsfHt0RPPlBY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=UtCH+e1B5Iuq207TEs7HMEknrZs2jtZL4ybFzYqcV0TtXcAZzXfU8EreW9zRynitLhoP6uzXJL3/GKfNMT6P2dc/g7BR9MSYoN12zEEmjdFlNEYeh7bEzVSZdUx75tE8f5y3s0whWHBAPEhzuN5PwTh2DrlRGwXzOGGl+LTTSq4ItJ/v07EjKeWhOV96gEov/zcp+3mQtLtN+03xvwqG/XXQWTbkH3sn0FtkyppkBfWFTHm8dKxroLTBj8ElS4F/aI268D9tQTjPxsncA36inMym7+Mx4j9nbIZRqxTTcSOboooGrj4yx3uA3HdJ/FYnggxvUYhTZQmPx5PkmIOzcA==
X-YMail-OSG: DuHBXIsVM1mIaY.mLhrC5100YxqrF_lrsfkiDbSIqd.sVFV93Y.QkodCSBNKY7v gkYETmteo.Pm1w3fuBqvilcC.Bm9aiPuG9lvKtRsXa8pIhnr5hKdWbC3rW.pWNAvuQv6dUP4emIr nt43X78e8a1SeQfj8DMuuafzX9ywWz1OScYiOopcTp1GnBuESM06V10QIZlBMSvHap0q0vr76Ckk M.WvcueBtL6cHJYs2JR4zWrYL.ZfWIDE2iFF1fcAsZD7j.3R_Bb0EHLw21L4P5lvBW8BY0yu3nnW rbdhAYWcMKKVw5Kxu3bV9W8E_ujqnnuzuCGj093hUjH9TCaoB8qUZ25hrzPKsAOH_50aMgQrzBKC Hw15bjEcjUdGYwIaJ3I0IfbSP1zBpGY8l6YgX0oztvrRudS6Mx.WcJuKA6Ces0zidn84KRZAhvkT xlZl4K9Ddciyqfs0IEjK0NbyGpnkIgYDIoRtscxItU0j7f89aaVnuYmmDwHePG.qJC6dsJEF.JXU 97BzZR7l3HBQgKNurOVasUHrkXM26touJgThigM1AvHfu95L47WkTHsO1RPpgrzBgjDnd9WFZ0ly 5jI56Ryi_1go5RARr6Q0V2Jhd9.Uf2dnm5sOqS7LxCHMvtGd3h5juOKPNpEZS8bmfVPzlhrI2Dgt JICZdRMbFW1nIksuyaOxMI3994wPtCKEbj..CfZRZ4b6RVl.2lRUqYspIqDFVENzYbJmi7.zJMZO bMAqV1i8rY0PxPk.5OxO4nJTlnBpgJ.6ZcEZkLZY5AthhlbV9aogAXiUmqrb9NT.D3vpCecFrbnK lmeV5QBJrthZKhWPM262Dd.hNjV6QbPJ_g1HOHldqJYp7ZsiNs5rapQ9Dt8jAwk0cYD4uCiaHOUv 4GBoV5eGC57BKcbfUwa22vTSKFnqi0uozw.TzCQA2HWvfuGbYkI2SD1TrCgM66VXCSK2ea1CEtDB LHc2Hjb13kIb0fdvUQEjnn3.g6WVj4gXbM177KB8OGPwtErtuq3RPG6IJH0Ka2ENlnPNvXtTcmF8 vHJRcYn9PATMlgxxppmQI2xJk1NbfZWD_Ada7Knxyrjg_.cpRBmzSyiflsjhL543sKYGTkJ_xlsS adVpnBgaxw.BbtR_fTnDijKShwnU60atYX17X17NKWxA610r1eBooMICI0d.liyc8RTlbWjv6l4D gKe4Bg7olgI3Pnuqr3_M8oED1iITCRS3YP3tzqmVwMEenP4NQOMlFmr7iC.U4i9Z2rll42Rdn8UQ x4pE.f.NPGwsdflHN9QK1EgzZzus2HkzorA2MP35anQLK9k2ntmqKu9PI7FumBSjtYGfUXtVI55k YejM5w9jTm3DGG_l_wIynEyvk5DPArZ3c6uPT7q1vISvxzFq5z9KKScfO1XhcGtBy3VLyL4UNAvN Z24BxP54vkJ36GGy6DY8JrGiqTm70Os8grDGPnpVgu.MUco7VY1IkNvyx0NqUruRRUEkSi6o5gCE 4e1s-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Thu, 16 Apr 2020 21:07:26 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2fc2721a8d884ce232713d16b73c41b1;  Thu, 16 Apr 2020 21:05:24 +0000 (UTC)
To: Brian Campbell , Filip Skokan 
Cc: oauth 
References:   
From: George Fletcher 
Organization: AOL LLC
Message-ID: <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com>
Date: Thu, 16 Apr 2020 17:05:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 21:07:31 -0000

Maybe if we make it an array of authorization "flows" supported? A bit 
like the AS can describe whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" 
and "par" (redirect not being quite right:) which allows for expansion 
in the future. That way the AS could easily signal whether it supports 
both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:
> But do you think that an AS-wide policy
> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
> needed or sufficiently useful?


From nobody Thu Apr 16 14:07:47 2020
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 C54CE3A10FC for ; Thu, 16 Apr 2020 14:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 xGxHuIfTS458 for ; Thu, 16 Apr 2020 14:07:27 -0700 (PDT)
Received: from sonic306-49.consmr.mail.ne1.yahoo.com (sonic306-49.consmr.mail.ne1.yahoo.com [66.163.189.111]) (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 70E593A10FD for ; Thu, 16 Apr 2020 14:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587071246; bh=l7PfHBMpJbyoN2i51cF3CnWT2jnjXb2lsfHt0RPPlBY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=UtCH+e1B5Iuq207TEs7HMEknrZs2jtZL4ybFzYqcV0TtXcAZzXfU8EreW9zRynitLhoP6uzXJL3/GKfNMT6P2dc/g7BR9MSYoN12zEEmjdFlNEYeh7bEzVSZdUx75tE8f5y3s0whWHBAPEhzuN5PwTh2DrlRGwXzOGGl+LTTSq4ItJ/v07EjKeWhOV96gEov/zcp+3mQtLtN+03xvwqG/XXQWTbkH3sn0FtkyppkBfWFTHm8dKxroLTBj8ElS4F/aI268D9tQTjPxsncA36inMym7+Mx4j9nbIZRqxTTcSOboooGrj4yx3uA3HdJ/FYnggxvUYhTZQmPx5PkmIOzcA==
X-YMail-OSG: DuHBXIsVM1mIaY.mLhrC5100YxqrF_lrsfkiDbSIqd.sVFV93Y.QkodCSBNKY7v gkYETmteo.Pm1w3fuBqvilcC.Bm9aiPuG9lvKtRsXa8pIhnr5hKdWbC3rW.pWNAvuQv6dUP4emIr nt43X78e8a1SeQfj8DMuuafzX9ywWz1OScYiOopcTp1GnBuESM06V10QIZlBMSvHap0q0vr76Ckk M.WvcueBtL6cHJYs2JR4zWrYL.ZfWIDE2iFF1fcAsZD7j.3R_Bb0EHLw21L4P5lvBW8BY0yu3nnW rbdhAYWcMKKVw5Kxu3bV9W8E_ujqnnuzuCGj093hUjH9TCaoB8qUZ25hrzPKsAOH_50aMgQrzBKC Hw15bjEcjUdGYwIaJ3I0IfbSP1zBpGY8l6YgX0oztvrRudS6Mx.WcJuKA6Ces0zidn84KRZAhvkT xlZl4K9Ddciyqfs0IEjK0NbyGpnkIgYDIoRtscxItU0j7f89aaVnuYmmDwHePG.qJC6dsJEF.JXU 97BzZR7l3HBQgKNurOVasUHrkXM26touJgThigM1AvHfu95L47WkTHsO1RPpgrzBgjDnd9WFZ0ly 5jI56Ryi_1go5RARr6Q0V2Jhd9.Uf2dnm5sOqS7LxCHMvtGd3h5juOKPNpEZS8bmfVPzlhrI2Dgt JICZdRMbFW1nIksuyaOxMI3994wPtCKEbj..CfZRZ4b6RVl.2lRUqYspIqDFVENzYbJmi7.zJMZO bMAqV1i8rY0PxPk.5OxO4nJTlnBpgJ.6ZcEZkLZY5AthhlbV9aogAXiUmqrb9NT.D3vpCecFrbnK lmeV5QBJrthZKhWPM262Dd.hNjV6QbPJ_g1HOHldqJYp7ZsiNs5rapQ9Dt8jAwk0cYD4uCiaHOUv 4GBoV5eGC57BKcbfUwa22vTSKFnqi0uozw.TzCQA2HWvfuGbYkI2SD1TrCgM66VXCSK2ea1CEtDB LHc2Hjb13kIb0fdvUQEjnn3.g6WVj4gXbM177KB8OGPwtErtuq3RPG6IJH0Ka2ENlnPNvXtTcmF8 vHJRcYn9PATMlgxxppmQI2xJk1NbfZWD_Ada7Knxyrjg_.cpRBmzSyiflsjhL543sKYGTkJ_xlsS adVpnBgaxw.BbtR_fTnDijKShwnU60atYX17X17NKWxA610r1eBooMICI0d.liyc8RTlbWjv6l4D gKe4Bg7olgI3Pnuqr3_M8oED1iITCRS3YP3tzqmVwMEenP4NQOMlFmr7iC.U4i9Z2rll42Rdn8UQ x4pE.f.NPGwsdflHN9QK1EgzZzus2HkzorA2MP35anQLK9k2ntmqKu9PI7FumBSjtYGfUXtVI55k YejM5w9jTm3DGG_l_wIynEyvk5DPArZ3c6uPT7q1vISvxzFq5z9KKScfO1XhcGtBy3VLyL4UNAvN Z24BxP54vkJ36GGy6DY8JrGiqTm70Os8grDGPnpVgu.MUco7VY1IkNvyx0NqUruRRUEkSi6o5gCE 4e1s-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Thu, 16 Apr 2020 21:07:26 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2fc2721a8d884ce232713d16b73c41b1;  Thu, 16 Apr 2020 21:05:24 +0000 (UTC)
To: Brian Campbell , Filip Skokan 
Cc: oauth 
References:   
From: George Fletcher 
Organization: AOL LLC
Message-ID: <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com>
Date: Thu, 16 Apr 2020 17:05:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 16 Apr 2020 21:07:33 -0000

Maybe if we make it an array of authorization "flows" supported? A bit 
like the AS can describe whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" 
and "par" (redirect not being quite right:) which allows for expansion 
in the future. That way the AS could easily signal whether it supports 
both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:
> But do you think that an AS-wide policy
> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
> needed or sufficiently useful?


From nobody Fri Apr 17 00:22:53 2020
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 8AFC83A0F4C for ; Fri, 17 Apr 2020 00:22:48 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 yNX1RFKBB5Rj for ; Fri, 17 Apr 2020 00:22:43 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450: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 0204E3A0F61 for ; Fri, 17 Apr 2020 00:22:37 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id k11so1833719wrp.5 for ; Fri, 17 Apr 2020 00:22:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ym7w5RptcParAIhMSqmmmTkaWLNhaXhJftERJG0qeZ4=; b=JucI7nMY1UyXhBPtUPulveLD/Iym0xchtcKf+0BporZk2ZkbH/SNmZY30wfyUGoVHu wAUDtLx35l7bV+Eixhkge92cEhk/2MEVsJnR/xDC2IQayFLqP3b7xlsQy6CNptsuI1wp /msc98AXUt2mzpvPUP+c6SxsRztZQrW+xSvQuiuqoZFYq3lhxcyPsNamhNELcu4oaZcc ds03Fx8WYMWf00m0uEpZBJKS3MTovbUYnDeKmG6XFEFkjrgXjNpMRU+wgTkjs28IET0y Ut8/BEj95zY1ZuXTUsQYjz0nx2h30huer4g1SoiegF+ZnGJ1wJvzb7sj8wsZFEzUEdHp NFAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ym7w5RptcParAIhMSqmmmTkaWLNhaXhJftERJG0qeZ4=; b=Wn8vDzgL3TRUPW9YQkLbhpelk8tsfnM8WuoMF4Gwbkxq/bxQ0uDQiGy9FswEd/YxAy SqvGcFW5fcd8jeMkjE3KFZiyk5Y5lIT5FA15arsoXOUSwCw4AHGhm+Qdw6ekvQdVdnbm A4vrmbi64WSf04y6LYSQvY4G57WAxLa6DT72TpjUPrXyPuq+kRydkt74flcYdn/TLWpY +5oEYQ+d73xUd6ikop2LsGqXbwRAd3bg4kJojkdCIQea+F965cnAN9owVt8t6To63dF3 2VYjpM6zuixVHZGoSH7AgnvBnggDLWqmyUFX320csYr2zdnRRjG5c1VNPjFfeMH5OiZC Y0gw==
X-Gm-Message-State: AGi0PuaKfBH7/Nap6CvcvukD3JJxPztn5fTgq6QktUwsJ/UVxliwFsIR mVpmY7oTQTApuhYVnPEKg/s0Gg==
X-Google-Smtp-Source: APiQypL/TY9n/1lmZlhdAsC7nqWPvIYuC9l+V0TTcPR2wI1RvhZHQQagwy3qxLbdCEkPPvSQdZClMQ==
X-Received: by 2002:a5d:420d:: with SMTP id n13mr2621084wrq.204.1587108154520;  Fri, 17 Apr 2020 00:22:34 -0700 (PDT)
Received: from [192.168.71.111] (p5B0D9376.dip0.t-ipconnect.de. [91.13.147.118]) by smtp.gmail.com with ESMTPSA id a1sm21585968wrn.80.2020.04.17.00.22.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 00:22:33 -0700 (PDT)
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_705DBA0F-2ECB-44B1-9EAA-C309612F0FC5"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 17 Apr 2020 09:22:32 +0200
In-Reply-To: <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com>
Cc: Filip Skokan , oauth , George Fletcher 
To: Brian Campbell 
References:    <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 17 Apr 2020 07:22:49 -0000

--Apple-Mail=_705DBA0F-2ECB-44B1-9EAA-C309612F0FC5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Is this really a PAR requirement? I=E2=80=99m asking since the client in =
the end is required to use an authorization request in the fron channel =
but with a PAR request_uri. So one could see this as a constrained on =
the authorisation request itself. Another question is whether this =
request_uri must be PAR based or whether it could be any other =
request_uri.

> On 16. Apr 2020, at 23:05, George Fletcher =
 wrote:
>=20
> Maybe if we make it an array of authorization "flows" supported? A bit =
like the AS can describe whether it supports "pairwise", "public" or =
both?
>=20
> Not sure what to name it though:) Possible values could be "redirect" =
and "par" (redirect not being quite right:) which allows for expansion =
in the future. That way the AS could easily signal whether it supports =
both or just one. It does mean the discovery doc is redundant in =
specifying that the AS supports PAR but that's probably ok.
>=20
> On 4/16/20 4:50 PM, Brian Campbell wrote:
>> But do you think that an AS-wide policy
>> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
>> needed or sufficiently useful?
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_705DBA0F-2ECB-44B1-9EAA-C309612F0FC5
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w
ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG
EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE
CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G
A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN
Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F
jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb
IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy
zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr
BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw
MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R
BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr
BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp
cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7
2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe
GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/
L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE
tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q
CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3
/crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3
DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT
LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD
QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE
CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT
LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u
IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J
Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ
XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4
uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h
iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3
sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6
yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw
MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH
AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF
BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v
bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw
Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z
aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka
MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f
Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4
VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc
hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za
Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI
5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG
CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ
8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww
E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB
fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG
A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh
BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC
AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDE3MDcyMjMy
WjAvBgkqhkiG9w0BCQQxIgQgthlG3PQ6k0+w+BRArF+Sk4rwJMW4exMXhNotVsSm4NowgbMGCSsG
AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM
EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww
KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7
IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn
YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w
MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC
EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAOQi1uw4/RHP8oG5eFLcbhmh20EZ8
M8mcx1+fQ29U1ZUUvIHBmdv2xBnoFw0vl5XN+zcqUM0A8Up+BpANyAgY4FoYCbeiOJ+AbOfKGSat
kParFNzt5JSzTGWtgAdB23nb6iW469nD4IE2ysZteWvvR2zbGUawTo1JUPFPf8bahgreipDpPQ9a
bIsVHqeYvikh48Om0LQzvQCTy83vRFBkaZnSum9nLNWUSdjaiUgHCU/l4gKi88269Y3t/uN7r5Jn
AW0POdEA6cZEP30pi8hSlawnf+/fqyoUGwYOoEVfLv8vqH7qfqFzn/6HAEB3XMG1NMoun4LSxBVl
3N1gpHe6cgAAAAAAAA==
--Apple-Mail=_705DBA0F-2ECB-44B1-9EAA-C309612F0FC5--


From nobody Fri Apr 17 07:36:06 2020
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 1B6EF3A0B1B for ; Fri, 17 Apr 2020 07:36:05 -0700 (PDT)
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=aol.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 PSwpXETfMq1W for ; Fri, 17 Apr 2020 07:36:03 -0700 (PDT)
Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (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 EFE5E3A0B95 for ; Fri, 17 Apr 2020 07:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587134140; bh=ak1/tbuKc4/KNevR3lpNosmSbN6jMFep89dE3PWXtoo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=s721HSHnAeT1XQPklkNUN88rCUUPJu30as/P9+jtgIeI0WaihmgN8hZiHFNsKK/eLZehMqHFnDMAA5Wyc+oCPn/SmGP135KoRZAAoDum88P/rcu7siqBnHHzU/dKGGulmJlg6k20WAhszzM+2+zO6WHraG/SyrW7734pUiEP4dPNzKd4mUQXmpY+VON278t7guq3Z7TqHRPwWo/VQEyak/ZRFyuiorNv9gIF9oKTiGATLe/OBxVfIPdbSI5H9L165lfrlow8yJKgfKagncWgsi1Ag54FdvdZ5rYvazLLy7HacmPlsvN0IDnVvjAudl1ZUyrJhpZ1WdEa8EEfxebsRg==
X-YMail-OSG: MFaR6vMVM1l_um_Wc.fVBgB80bHMttS9krcWgskhS7jJbK0V56wAwjDwVEe7kIt 9GT9NUsFBiKzj01wjzAd8fJSTwdIat3b5LONgZg6N2UAOIQjZdwzOP.Six1vwl5XAlaGA8D2os1i 56u6rp8tp2f73Eq8S0sWmNcadfZKP8r29S_3j5g4dffh7oX8UOc1MIQdjF3nRCMSx4xDLECy6Zum obJbfw96XxwsFy8tT_FsFRj.xi2mwdkLmFD5.A1FU6YZE2rjkeFm0d_oSOBD_k2aLJtoG_JekxLE LEdlKVSm3vffYS4W.x9PuiOcUPuh_t8puYNa1atYcabuU6Ap3NmoNJpK4T6eRsnjalskRrdzQ6e7 JPMgrR_BEuVv5XDy7Alx8imTugZXdp3McG3adCJndGy9kGlL6S67wMMJrERMKQQaH82HwO0FWFLS 7q0qLbcqOwpxezv7uG1V5B863Fx_GFtvV350TJyj9KUH7WWxHpZ9exe09wxdutVwbVZ5s4EhR_f0 surG7t9uSemV9VqkhduFS7EhlbE9XDePHCAr20ucL_LXqMqlCCZCr5J4vc2tbCl1Tu7R7afq0AFb o4nUs3bjxEi5YafQq2DetRNSDye64qHze07dN6.NSQLNRK0GcUZEcVYyk8vK3LcC.OyhhvTHbwvi o2jjvjb_Nn33X6P1J390LWkx8mGpSExnSFWJvZBanbIFVGSemnT663f9XmmxtE6BdDWvfynQPMyb 76iiL07vmC4_6R8M1I2fiRM.cBVSAriuK.t.YWknSkfMmp96acTvWK2o5IoUwEAugVtFFv9UTNra 83viSSaWI1pzB8.BpxsP0Ti3y4qcGYFmsQ4X_TmLcNREtXDbqJJsdHNkGvIsrdqN9VIevre1YEFX yq8XocsHbkQQcX41kqaiY3Ccif2qbtQKG5UmDqkduK4.434avZ8IsXyBlSpIP7jzFwt5dIeAbtdI GnJ0BV1KR4KhZFn5X8KdflWSj2kTlbIVK9HfMVKAixFGbmE3_dslacYDl3Ed2ih7FN_PGzGbL_fv R_dQvxDy8EqK2e0N9nNRDjuEHzlgmYDDXCLf5JFdBynY7MBujzCXUvQPr9VpJNimMbRnO5snaioA rHXarunIYcmbEWoxt2UZH6Yx.TySFv.WCcAd7LptVENyFXSZFXoyjfzxj2gBItlyB9P.czpGEfXg H5h92aM5z8xU_0dAMKxGrpoCDPOjal9beW_2UXN36_d_fX7RxhloBYr7ltk4A4SxqNo.eLpKag6F h8K2a5NSl3Wnc21qNXedTdps1gb_26HDzJeqQ6EU5mOwh1RNz5UNUWxCvfC6OQUfs2hEU9uhG2Tn WDNjtAcGZiiFg_5KMgvZEe8NAdJPYQtMI5LMHLGTCqeaViiM5nGeScgfAXyFXQ5tVjVT8Vtov3nr STW_D30hsKtvrRt653EXBnqfa5fgsbZ1DheaVN6OOGFFd6ESfexTkL8tY0yxSmJhiVg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Apr 2020 14:35:40 +0000
Received: by smtp417.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bccf1a3c0b5f17bca550db98017ec375;  Fri, 17 Apr 2020 14:33:38 +0000 (UTC)
To: Torsten Lodderstedt , Brian Campbell 
Cc: Filip Skokan , oauth 
References:    <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Fri, 17 Apr 2020 10:33:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------56CD8F876048A0A27CE04DD6"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 17 Apr 2020 14:36:05 -0000

This is a multi-part message in MIME format.
--------------56CD8F876048A0A27CE04DD6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I don't know about a PAR "requirement", but it feels like the PAR spec 
is the right place to put this. My understanding of what's being asked 
is... how does the AS advertise to it's clients that it will ONLY accept 
PAR based request_uris and other authn/authz request methods will fail.

On 4/17/20 3:22 AM, Torsten Lodderstedt wrote:
> Is this really a PAR requirement? I’m asking since the client in the end is required to use an authorization request in the fron channel but with a PAR request_uri. So one could see this as a constrained on the authorisation request itself. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri.
>
>> On 16. Apr 2020, at 23:05, George Fletcher  wrote:
>>
>> Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both?
>>
>> Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the future. That way the AS could easily signal whether it supports both or just one. It does mean the discovery doc is redundant in specifying that the AS supports PAR but that's probably ok.
>>
>> On 4/16/20 4:50 PM, Brian Campbell wrote:
>>> But do you think that an AS-wide policy
>>> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
>>> needed or sufficiently useful?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--------------56CD8F876048A0A27CE04DD6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I don't know about a PAR
      "requirement", but it feels like the PAR spec is the right place
      to put this. My understanding of what's being asked is... how does
      the AS advertise to it's clients that it will ONLY accept PAR
      based request_uris and other authn/authz request methods will
      fail.

    

    
On 4/17/20 3:22 AM, Torsten Lodderstedt
      wrote:

    

    

      
Is this really a PAR requirement? I’m asking since the client in the end is required to use an authorization request in the fron channel but with a PAR request_uri. So one could see this as a constrained on the authorisation request itself. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri.



      

        
On 16. Apr 2020, at 23:05, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the future. That way the AS could easily signal whether it supports both or just one. It does mean the discovery doc is redundant in specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:


        

          
But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


        

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


      

      

    

    

  


--------------56CD8F876048A0A27CE04DD6--


From nobody Fri Apr 17 07:36:13 2020
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 654FF3A0B68 for ; Fri, 17 Apr 2020 07:36:05 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 jnwnc2-UYL8q for ; Fri, 17 Apr 2020 07:36:03 -0700 (PDT)
Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (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 CB6263A0B84 for ; Fri, 17 Apr 2020 07:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587134140; bh=ak1/tbuKc4/KNevR3lpNosmSbN6jMFep89dE3PWXtoo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=s721HSHnAeT1XQPklkNUN88rCUUPJu30as/P9+jtgIeI0WaihmgN8hZiHFNsKK/eLZehMqHFnDMAA5Wyc+oCPn/SmGP135KoRZAAoDum88P/rcu7siqBnHHzU/dKGGulmJlg6k20WAhszzM+2+zO6WHraG/SyrW7734pUiEP4dPNzKd4mUQXmpY+VON278t7guq3Z7TqHRPwWo/VQEyak/ZRFyuiorNv9gIF9oKTiGATLe/OBxVfIPdbSI5H9L165lfrlow8yJKgfKagncWgsi1Ag54FdvdZ5rYvazLLy7HacmPlsvN0IDnVvjAudl1ZUyrJhpZ1WdEa8EEfxebsRg==
X-YMail-OSG: MFaR6vMVM1l_um_Wc.fVBgB80bHMttS9krcWgskhS7jJbK0V56wAwjDwVEe7kIt 9GT9NUsFBiKzj01wjzAd8fJSTwdIat3b5LONgZg6N2UAOIQjZdwzOP.Six1vwl5XAlaGA8D2os1i 56u6rp8tp2f73Eq8S0sWmNcadfZKP8r29S_3j5g4dffh7oX8UOc1MIQdjF3nRCMSx4xDLECy6Zum obJbfw96XxwsFy8tT_FsFRj.xi2mwdkLmFD5.A1FU6YZE2rjkeFm0d_oSOBD_k2aLJtoG_JekxLE LEdlKVSm3vffYS4W.x9PuiOcUPuh_t8puYNa1atYcabuU6Ap3NmoNJpK4T6eRsnjalskRrdzQ6e7 JPMgrR_BEuVv5XDy7Alx8imTugZXdp3McG3adCJndGy9kGlL6S67wMMJrERMKQQaH82HwO0FWFLS 7q0qLbcqOwpxezv7uG1V5B863Fx_GFtvV350TJyj9KUH7WWxHpZ9exe09wxdutVwbVZ5s4EhR_f0 surG7t9uSemV9VqkhduFS7EhlbE9XDePHCAr20ucL_LXqMqlCCZCr5J4vc2tbCl1Tu7R7afq0AFb o4nUs3bjxEi5YafQq2DetRNSDye64qHze07dN6.NSQLNRK0GcUZEcVYyk8vK3LcC.OyhhvTHbwvi o2jjvjb_Nn33X6P1J390LWkx8mGpSExnSFWJvZBanbIFVGSemnT663f9XmmxtE6BdDWvfynQPMyb 76iiL07vmC4_6R8M1I2fiRM.cBVSAriuK.t.YWknSkfMmp96acTvWK2o5IoUwEAugVtFFv9UTNra 83viSSaWI1pzB8.BpxsP0Ti3y4qcGYFmsQ4X_TmLcNREtXDbqJJsdHNkGvIsrdqN9VIevre1YEFX yq8XocsHbkQQcX41kqaiY3Ccif2qbtQKG5UmDqkduK4.434avZ8IsXyBlSpIP7jzFwt5dIeAbtdI GnJ0BV1KR4KhZFn5X8KdflWSj2kTlbIVK9HfMVKAixFGbmE3_dslacYDl3Ed2ih7FN_PGzGbL_fv R_dQvxDy8EqK2e0N9nNRDjuEHzlgmYDDXCLf5JFdBynY7MBujzCXUvQPr9VpJNimMbRnO5snaioA rHXarunIYcmbEWoxt2UZH6Yx.TySFv.WCcAd7LptVENyFXSZFXoyjfzxj2gBItlyB9P.czpGEfXg H5h92aM5z8xU_0dAMKxGrpoCDPOjal9beW_2UXN36_d_fX7RxhloBYr7ltk4A4SxqNo.eLpKag6F h8K2a5NSl3Wnc21qNXedTdps1gb_26HDzJeqQ6EU5mOwh1RNz5UNUWxCvfC6OQUfs2hEU9uhG2Tn WDNjtAcGZiiFg_5KMgvZEe8NAdJPYQtMI5LMHLGTCqeaViiM5nGeScgfAXyFXQ5tVjVT8Vtov3nr STW_D30hsKtvrRt653EXBnqfa5fgsbZ1DheaVN6OOGFFd6ESfexTkL8tY0yxSmJhiVg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Apr 2020 14:35:40 +0000
Received: by smtp417.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bccf1a3c0b5f17bca550db98017ec375;  Fri, 17 Apr 2020 14:33:38 +0000 (UTC)
To: Torsten Lodderstedt , Brian Campbell 
Cc: Filip Skokan , oauth 
References:    <91a9b333-9b43-5f85-6bb2-2bb008aec4e7@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Fri, 17 Apr 2020 10:33:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------56CD8F876048A0A27CE04DD6"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 17 Apr 2020 14:36:05 -0000

This is a multi-part message in MIME format.
--------------56CD8F876048A0A27CE04DD6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I don't know about a PAR "requirement", but it feels like the PAR spec 
is the right place to put this. My understanding of what's being asked 
is... how does the AS advertise to it's clients that it will ONLY accept 
PAR based request_uris and other authn/authz request methods will fail.

On 4/17/20 3:22 AM, Torsten Lodderstedt wrote:
> Is this really a PAR requirement? I’m asking since the client in the end is required to use an authorization request in the fron channel but with a PAR request_uri. So one could see this as a constrained on the authorisation request itself. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri.
>
>> On 16. Apr 2020, at 23:05, George Fletcher  wrote:
>>
>> Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both?
>>
>> Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the future. That way the AS could easily signal whether it supports both or just one. It does mean the discovery doc is redundant in specifying that the AS supports PAR but that's probably ok.
>>
>> On 4/16/20 4:50 PM, Brian Campbell wrote:
>>> But do you think that an AS-wide policy
>>> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
>>> needed or sufficiently useful?
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--------------56CD8F876048A0A27CE04DD6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I don't know about a PAR
      "requirement", but it feels like the PAR spec is the right place
      to put this. My understanding of what's being asked is... how does
      the AS advertise to it's clients that it will ONLY accept PAR
      based request_uris and other authn/authz request methods will
      fail.

    

    
On 4/17/20 3:22 AM, Torsten Lodderstedt
      wrote:

    

    

      
Is this really a PAR requirement? I’m asking since the client in the end is required to use an authorization request in the fron channel but with a PAR request_uri. So one could see this as a constrained on the authorisation request itself. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri.



      

        
On 16. Apr 2020, at 23:05, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the future. That way the AS could easily signal whether it supports both or just one. It does mean the discovery doc is redundant in specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:


        

          
But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


        

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


      

      

    

    

  


--------------56CD8F876048A0A27CE04DD6--


From nobody Fri Apr 17 08:17:13 2020
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 D8D193A0FEA for ; Fri, 17 Apr 2020 08:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 EGqb5AKQRbyj for ; Fri, 17 Apr 2020 08:16:52 -0700 (PDT)
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 452EE3A0DE8 for ; Fri, 17 Apr 2020 08:16:28 -0700 (PDT)
Received: from [192.168.1.13] (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 03HFGQOe016709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Apr 2020 11:16:27 -0400
From: Justin Richer 
Message-Id: <1E6724FE-9EBE-4A1F-BE24-099771FACEFD@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C8C0B946-2022-45A9-BEF7-7EFC111C6EE1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 17 Apr 2020 11:16:26 -0400
In-Reply-To: 
Cc: Brian Campbell , oauth 
To: Filip Skokan 
References:   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 15:17:12 -0000

--Apple-Mail=_C8C0B946-2022-45A9-BEF7-7EFC111C6EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The idea of =E2=80=9CContinuing to work without taking advantage of =
sender constraints=E2=80=9D is, I would argue, a security hole. Systems =
are allowed to fail security checks but still offer functionality. This =
is exactly the pattern behind allowing an unsigned JWT because you =
checked the =E2=80=9Calg" header and it was =E2=80=9Cnone=E2=80=9D and =
so you=E2=80=99re OK with that. Yes, you shouldn=E2=80=99t do that, but =
maybe we could=E2=80=99ve also made this more explicit within JOSE. By =
using the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a =
clear syntactic change that says to the RS =E2=80=9Ceither you know to =
look for this or you don=E2=80=99t know what it is=E2=80=9D.=20

It=E2=80=99s one of the problems I have with how the OAuth MTLS spec was =
written. By re-using the =E2=80=9CBearer=E2=80=9D scheme there, I =
believe we=E2=80=99ve made a mistake that allows things to fall through =
in an insecure fashion. The same argument against it =E2=80=94 ease of =
porting existing deployments =E2=80=94 was raised there as well, and it =
won in the end. I hope we can do better this time.

 =E2=80=94 Justin

> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>=20
> I'm still somewhat on the fence as to the pros and cons of using a new =
token type and authorization scheme. But the draft has gone with a new =
one. Would it have really helped this situation, if it'd stuck with =
"bearer"? Or would it just be less obvious?
>=20
> If we had stuck "bearer" than i wouldn't have raised this topic, since =
existing RS would most likely ignore the cnf claim and the resource =
server calls would continue to work, obviously without taking advantage =
of the available sender check.
>=20
> As I wrote the preceding rambling paragraph I am starting to think =
that more should be said in the draft about working with RSs that don't =
support DPoP. Which isn't really what you were asking about. But maybe =
would cover some of the same ground.
>=20
> I agree.
>=20
>  The AS is the one that does the binding (which includes checking the =
proof) so I don't see how sending two proofs would really work or help =
the situation?
>=20
> :facepalm: indeed, sorry.=20
>=20
> S pozdravem,
> Filip Skokan
>=20
>=20
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell =
> wrote:
> Hi Filip,=20
>=20
> My attempts at responses to your questions/comments are inline:
>=20
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan > wrote:
> I've wondered about the decision to use a new scheme before =
 but this time i'd like to challenge the immediate usability of the =
future spec for one specific case - sender constraining public client =
Refresh Tokens.
>=20
> I'm still somewhat on the fence as to the pros and cons of using a new =
token type and authorization scheme. But the draft has gone with a new =
one. Would it have really helped this situation, if it'd stuck with =
"bearer"? Or would it just be less obvious?=20
> =20
>=20
> If at all, it is going to take time for RS implementations to =
recognize the new `DPoP` authorization scheme, let alone process it =
properly. In the meantime, i'd still like to have the option to bind =
issued public client refresh tokens using DPoP without affecting the =
access tokens. In doing so i get an immediate win in sender constraining =
the refresh tokens but not introducing a breaking change for the RS.
>=20
> Do you see this as something an AS implementation is just free to do =
since it's both the issuer and recipient of a refresh token?
> That's my first thought, yes.=20
> =20
> Should this be somehow baked in the draft?
> I'm not sure. Do you think it needs to be? I'm not sure what it would =
say though.=20
>=20
> In such a case the AS could bind the RT to the given dpop proof and =
either not bind the AT while returning token_type=3DBearer or bind the =
AT while returning token_type value DPoP. In the latter case the AT =
would almost certainly still work as a bearer token at the RS and the =
client that knew the RS's needs could send it as such with an =
`Authorization: Bearer `. Or if it didn't know the RS's needs, it =
could start with `Authorization: DPoP ` which would get a 401 with =
`WWW-Authenticate: Bearer` at which point it could send `Authorization: =
Bearer `.=20
>=20
> As I wrote the preceding rambling paragraph I am starting to think =
that more should be said in the draft about working with RSs that don't =
support DPoP. Which isn't really what you were asking about. But maybe =
would cover some of the same ground.=20
> =20
> =20
> Do you think client registration metadata could be used to signal such =
intent?
> I think it certainly could. But it seems maybe too specific to warrant =
metadata.=20
> =20
> Do you think the protocol should have signals in the messages =
themselves to say what the client wants to apply DPoP to?
> My initial thought here is no. Take the case of a client working with =
an AS that supports DPoP and one RS that does and one RS that doesn't. I =
can't really even think what signaling might look like there or how it =
could be made to be generally useful.
> =20
> What if AS and RS don't have a shared support DPoP JWS Algorithm? Do =
we disqualify such cases or allow for sending two proofs, one for the AS =
to bind refresh tokens to, one for the RS to bind access tokens to?
> The AS is the one that does the binding (which includes checking the =
proof) so I don't see how sending two proofs would really work or help =
the situation?=20
> =20
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_C8C0B946-2022-45A9-BEF7-7EFC111C6EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
idea of =E2=80=9CContinuing to work without taking advantage of sender =
constraints=E2=80=9D is, I would argue, a security hole. Systems are =
allowed to fail security checks but still offer functionality. This is =
exactly the pattern behind allowing an unsigned JWT because you checked =
the =E2=80=9Calg" header and it was =E2=80=9Cnone=E2=80=9D and so =
you=E2=80=99re OK with that. Yes, you shouldn=E2=80=99t do that, but =
maybe we could=E2=80=99ve also made this more explicit within JOSE. By =
using the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a =
clear syntactic change that says to the RS =E2=80=9Ceither you know to =
look for this or you don=E2=80=99t know what it is=E2=80=9D. 

It=E2=80=99s one of the =
problems I have with how the OAuth MTLS spec was written. By re-using =
the =E2=80=9CBearer=E2=80=9D scheme there, I believe we=E2=80=99ve made =
a mistake that allows things to fall through in an insecure fashion. The =
same argument against it =E2=80=94 ease of porting existing deployments =
=E2=80=94 was raised there as well, and it won in the end. I hope we can =
do better this time.

 =E2=80=94 Justin

On Apr =
16, 2020, at 4:05 AM, Filip Skokan <panva.ip@gmail.com> =
wrote:

I'm still =
somewhat on the fence as to the pros and cons of using a new token type =
and authorization scheme. But the draft has gone with a new one. Would =
it have really helped this situation, if it'd stuck with "bearer"? Or =
would it just be less obvious?

If we had stuck "bearer" than i =
wouldn't have raised this topic, since existing RS would most likely =
ignore the cnf claim and the resource server calls would continue to =
work, obviously without taking advantage of the available sender =
check.

As I =
wrote the preceding rambling paragraph I am starting to think that more =
should be said in the draft about working with RSs that don't support =
DPoP. Which isn't really what you were asking about. But maybe would =
cover some of the same ground.

I agree.

 The AS is the one that does the =
binding (which includes checking the proof) so I don't see how sending =
two proofs would really work or help the situation?

:facepalm: indeed, =
sorry. 

S=
 pozdravem,
Filip Skokan


On Tue, 14 Apr 2020 at 23:39, Brian =
Campbell <bcampbell@pingidentity.com> wrote:
Hi Filip, 

My attempts at responses to your =
questions/comments are inline:

On Tue, Apr =
14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:
I've wondered about the decision to use a new scheme before but this time i'd =
like to challenge the immediate usability of the future spec for one =
specific case - sender constraining public client Refresh Tokens.

I'm still somewhat on the fence as to =
the pros and cons of using a new token type and authorization scheme. =
But the draft has gone with a new one. Would it have really helped this =
situation, if it'd stuck with "bearer"? Or would it just be less =
obvious? 
 

If at all, it is going to take time for RS =
implementations to recognize the new `DPoP` authorization scheme, let =
alone process it properly. In the meantime, i'd still like to have the =
option to bind issued public client refresh tokens using DPoP without =
affecting the access tokens. In doing so i get an immediate win in =
sender constraining the refresh tokens but not introducing a breaking =
change for the RS.

  • Do you see this as something an AS implementation is just =
free to do since it's both the issuer and recipient of a refresh =
token?
That's my first =
thought, yes. 
 
  •  Should this be somehow baked =
in the draft?
I'm not =
sure. Do you think it needs to be? I'm not sure what it would say =
though. 

In such a case the AS could bind the RT to the given dpop =
proof and either not bind the AT while returning token_type=3DBearer or =
bind the AT while returning token_type value DPoP. In the latter case =
the AT would almost certainly still work as a bearer token at the RS and =
the client that knew the RS's needs could send it as such with an =
`Authorization: Bearer <at>`. Or if it didn't know the RS's needs, =
it could start with `Authorization: DPoP <at>` which would get a =
401 with `WWW-Authenticate: Bearer` at which point it could send =
`Authorization: Bearer <at>`. 

As I wrote the preceding =
rambling paragraph I am starting to think that more should be said in =
the draft about working with RSs that don't support DPoP. Which isn't =
really what you were asking about. But maybe would cover some of the =
same ground. 
 
 
  • Do you think client =
registration metadata could be used to signal such =
intent?
I think it =
certainly could. But it seems maybe too specific to warrant metadata. =

 
  • Do you think the protocol =
should have signals in the messages themselves to say what the client =
wants to apply DPoP to?
My initial thought here is no. Take the case of a client =
working with an AS that supports DPoP and one RS that does and one RS =
that doesn't. I can't really even think what signaling might look like =
there or how it could be made to be generally useful.
 
  • What if AS and RS don't have a =
shared support DPoP JWS Algorithm? Do we disqualify such cases or allow =
for sending two proofs, one for the AS to bind refresh tokens to, one =
for the RS to bind access tokens =
to?
The AS is the one =
that does the binding (which includes checking the proof) so I don't see =
how sending two proofs would really work or help the situation? 
 




CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged material for the sole use of the intended recipient(s). =
Any review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, =
please notify the sender immediately by e-mail and delete the message =
and any file attachments from your computer. Thank =
you.

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

=

--Apple-Mail=_C8C0B946-2022-45A9-BEF7-7EFC111C6EE1--


From nobody Fri Apr 17 08:26:09 2020
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 0D7AC3A0DB1 for ; Fri, 17 Apr 2020 08:26:08 -0700 (PDT)
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 2hIBVnq3wtF6 for ; Fri, 17 Apr 2020 08:26:05 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 145FB3A0A7E for ; Fri, 17 Apr 2020 08:25:56 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id b17so1054484ybq.13 for ; Fri, 17 Apr 2020 08:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RQttaasDrWqDwFeUA7kfXj5oZq8jjxG/auoAce6883o=; b=gczalB/dOnFAIpgKAtcSVCe7eaj3FI7j/dv/CfZEVx83fxNxEaje8LjVVVPeKsKMtZ NEyJqgEG3TjE789fEOiLaGIJIkytZU6uDDDXifQhkvOxzfLj4eoaJKdqZYDQB007gfif zmg7uATz8+7CsDlkBn9myshMZEeXLaU88oQ7Is/gC4XyU+/TMhcCLJlREquqS2K8N3Zk xgt9r9niZHbdLVokbKnoGh6CVEEP9jGotjQUkHtfI45pm+4heCf5ni7euwAr5Vstx9YR KYDoS0WZOZVbWzg5bk5AWmX6UIpYn8Z8h0VyEVM7Q+ERnx+XxiV92Xk6sRWKkI0nJMew Ps/A==
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=RQttaasDrWqDwFeUA7kfXj5oZq8jjxG/auoAce6883o=; b=nL1eAjVUYSZ59sYf9+lKpjb9tlF4Hk8OTmcNxjGNrJPfEElcwb1H+X2p3r/r+t+tzS KqRLONNdqto8hlT3g6xIebeV09SOYf8P5h6ecxP/NvcYUaR7fBq/ABCjDv2dCR+2bXw+ svnJXUa0Tn08h8xYalf7Lznj9eKlZ64xFfDTtndIx3eSqtbESUA/rZTmfmq5Luois1PK 9OPfLn1ms5n/Smn6j0bHWiz4t5vtze8OJMaOUS/G5vQgExo2PgToGLm6dsrZZI2SExWG jBXzCnXgmWL5Ybqh7LVLc1r7BcAicatEMO6/cL4/Qe3zG7Jcj6NkBskUwcMRFE4RJr8/ aXkg==
X-Gm-Message-State: AGi0PuY1lNKKL17oxYaWKLsBa1E6BVWx9UJ2SZVs8DKtC8quyzQr1WrF BbMYebAdpbjmBx6SLJLuzQ0ok7g//mF17vIaAw==
X-Google-Smtp-Source: APiQypK6etlvrp6pRrhdCj5bOlQVcKfXkvJQMqkUgHRI5RG5gCAg1uBfffFUcWyvXRasWFFsbQXlGLXCcuoA24vBz8o=
X-Received: by 2002:a25:9b06:: with SMTP id y6mr6413575ybn.127.1587137155068;  Fri, 17 Apr 2020 08:25:55 -0700 (PDT)
MIME-Version: 1.0
References:    <1E6724FE-9EBE-4A1F-BE24-099771FACEFD@mit.edu>
In-Reply-To: <1E6724FE-9EBE-4A1F-BE24-099771FACEFD@mit.edu>
From: Filip Skokan 
Date: Fri, 17 Apr 2020 17:25:16 +0200
Message-ID: 
To: Justin Richer 
Cc: Brian Campbell , oauth 
Content-Type: multipart/alternative; boundary="0000000000005678c705a37e2a19"
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 15:26:08 -0000

--0000000000005678c705a37e2a19
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:

> The idea of =E2=80=9CContinuing to work without taking advantage of sende=
r
> constraints=E2=80=9D is, I would argue, a security hole. Systems are allo=
wed to
> fail security checks but still offer functionality. This is exactly the
> pattern behind allowing an unsigned JWT because you checked the =E2=80=9C=
alg"
> header and it was =E2=80=9Cnone=E2=80=9D and so you=E2=80=99re OK with th=
at. Yes, you shouldn=E2=80=99t do
> that, but maybe we could=E2=80=99ve also made this more explicit within J=
OSE. By
> using the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a clea=
r syntactic change that
> says to the RS =E2=80=9Ceither you know to look for this or you don=E2=80=
=99t know what it
> is=E2=80=9D.
>
> It=E2=80=99s one of the problems I have with how the OAuth MTLS spec was =
written.
> By re-using the =E2=80=9CBearer=E2=80=9D scheme there, I believe we=E2=80=
=99ve made a mistake that
> allows things to fall through in an insecure fashion. The same argument
> against it =E2=80=94 ease of porting existing deployments =E2=80=94 was r=
aised there as
> well, and it won in the end. I hope we can do better this time.
>
>  =E2=80=94 Justin
>
> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>
> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>> Would it have really helped this situation, if it'd stuck with "bearer"?=
 Or
>> would it just be less obvious?
>>
>
> If we had stuck "bearer" than i wouldn't have raised this topic, since
> existing RS would most likely ignore the cnf claim and the resource serve=
r
> calls would continue to work, obviously without taking advantage of the
> available sender check.
>
> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't suppo=
rt
>> DPoP. Which isn't really what you were asking about. But maybe would cov=
er
>> some of the same ground.
>
>
> I agree.
>
>  The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help t=
he
>> situation?
>
>
> :facepalm: indeed, sorry.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
> wrote:
>
>> Hi Filip,
>>
>> My attempts at responses to your questions/comments are inline:
>>
>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>
>>> I've wondered about the decision to use a new scheme before
>>>  but
>>> this time i'd like to challenge the immediate usability of the future s=
pec
>>> for one specific case - sender constraining public client Refresh Token=
s.
>>>
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>> Would it have really helped this situation, if it'd stuck with "bearer"?=
 Or
>> would it just be less obvious?
>>
>>
>>>
>>> If at all, it is going to take time for RS implementations to recognize
>>> the new `DPoP` authorization scheme, let alone process it properly. In =
the
>>> meantime, i'd still like to have the option to bind issued public clien=
t
>>> refresh tokens using DPoP without affecting the access tokens. In doing=
 so
>>> i get an immediate win in sender constraining the refresh tokens but no=
t
>>> introducing a breaking change for the RS.
>>>
>>>
>>>    - Do you see this as something an AS implementation is just free to
>>>    do since it's both the issuer and recipient of a refresh token?
>>>
>>> That's my first thought, yes.
>>
>>
>>>
>>>    - Should this be somehow baked in the draft?
>>>
>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>> say though.
>>
>> In such a case the AS could bind the RT to the given dpop proof and
>> either not bind the AT while returning token_type=3DBearer or bind the A=
T
>> while returning token_type value DPoP. In the latter case the AT would
>> almost certainly still work as a bearer token at the RS and the client t=
hat
>> knew the RS's needs could send it as such with an `Authorization: Bearer
>> `. Or if it didn't know the RS's needs, it could start with
>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>> Bearer` at which point it could send `Authorization: Bearer `.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>> more should be said in the draft about working with RSs that don't suppo=
rt
>> DPoP. Which isn't really what you were asking about. But maybe would cov=
er
>> some of the same ground.
>>
>>
>>
>>>
>>>    - Do you think client registration metadata could be used to signal
>>>    such intent?
>>>
>>> I think it certainly could. But it seems maybe too specific to warrant
>> metadata.
>>
>>
>>>
>>>    - Do you think the protocol should have signals in the messages
>>>    themselves to say what the client wants to apply DPoP to?
>>>
>>> My initial thought here is no. Take the case of a client working with a=
n
>> AS that supports DPoP and one RS that does and one RS that doesn't. I ca=
n't
>> really even think what signaling might look like there or how it could b=
e
>> made to be generally useful.
>>
>>
>>>
>>>    - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>    Do we disqualify such cases or allow for sending two proofs, one for=
 the AS
>>>    to bind refresh tokens to, one for the RS to bind access tokens to?
>>>
>>> The AS is the one that does the binding (which includes checking the
>> proof) so I don't see how sending two proofs would really work or help t=
he
>> situation?
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
..
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--0000000000005678c705a37e2a19
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I completely agree Justin, as mentioned - i wondered=C2=A0=
a year ago, I don't anymore. But i'd like it to be clear that sendi=
ng a DPoP proof does not necessarily mean the AS MUST issue a DPoP access t=
oken. Depending on the AS/RS relationship and configuration a regular Beare=
r may be still be issued and only the public client's refresh token=C2=
=A0would be constrained.

Best,
Filip


On Fri, 17 Apr 2020 at 17:16, Justin Richer =
<jricher@mit.edu> wrote:
The idea of =E2=80=9CContinuing to work without taking=
 advantage of sender constraints=E2=80=9D is, I would argue, a security hol=
e. Systems are allowed to fail security checks but still offer functionalit=
y. This is exactly the pattern behind allowing an unsigned JWT because you =
checked the =E2=80=9Calg" header and it was =E2=80=9Cnone=E2=80=9D and=
 so you=E2=80=99re OK with that. Yes, you shouldn=E2=80=99t do that, but ma=
ybe we could=E2=80=99ve also made this more explicit within JOSE. By using =
the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a clear syntac=
tic change that says to the RS =E2=80=9Ceither you know to look for this or=
 you don=E2=80=99t know what it is=E2=80=9D.=C2=A0

It=E2=
=80=99s one of the problems I have with how the OAuth MTLS spec was written=
. By re-using the =E2=80=9CBearer=E2=80=9D scheme there, I believe we=E2=80=
=99ve made a mistake that allows things to fall through in an insecure fash=
ion. The same argument against it =E2=80=94 ease of porting existing deploy=
ments =E2=80=94 was raised there as well, and it won in the end. I hope we =
can do better this time.

=C2=A0=E2=80=94 Justin

On Apr 16, 2020, at 4:05 AM, Filip=
 Skokan <panva.i=
p@gmail.com> wrote:

I'm still somewhat on the fence a=
s to the pros and cons of using a new token type and authorization scheme. =
But the draft has gone with a new one. Would it have really helped this sit=
uation, if it'd stuck with "bearer"? Or would it just be less=
 obvious?

If we had stuck "beare=
r" than i wouldn't have raised this topic, since existing RS would=
 most likely ignore the cnf claim and the resource server calls would conti=
nue to work, obviously without taking advantage of the available sender che=
ck.

As I wrote the preceding rambling paragraph I am starting to think that=
 more should be said in the draft about working with RSs that don't sup=
port DPoP. Which isn't really what you were asking about. But maybe wou=
ld cover some of the same ground.

I agree.<=
/div>

=C2=
=A0The AS is the one that does the binding (which includes checking the pro=
of) so I don't see how sending two proofs would really work or help the=
 situation?

:facepalm: indeed, sorry.=C2=A0=


S pozdravem,
Fili=
p Skokan


On Tue, 14 Apr 2020 at 23:39, Brian Campbell =
<bcampbe=
ll@pingidentity.com> wrote:
Hi Filip, 

My attempts at responses to your questions/comments are inline:

On=
 Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:
I'v=
e wondered about the decision to use a new scheme=C2=A0before=C2=A0but this time i'd like to challenge the immedi=
ate usability of the future spec for one specific case - sender constrainin=
g public client Refresh Tokens.

=

I'm still somewhat on the fence as to the pros and cons of using a=
 new token type and authorization scheme. But the draft has gone with a new=
 one. Would it have really helped this situation, if it'd stuck with &q=
uot;bearer"? Or would it just be less obvious? 
=C2=A0

If at all, it is going to take time for RS implementations to recogniz=
e the new `DPoP` authorization scheme, let alone process it properly. In th=
e meantime, i'd still like to have the option to bind issued public cli=
ent refresh tokens using DPoP without affecting the access tokens. In doing=
 so i get an immediate win in sender constraining the refresh tokens but no=
t introducing a breaking change for the RS.

  • Do you see this =
as something an AS implementation is just free to do since it's both th=
e issuer and recipient of a refresh token?
That's my first thought, yes. 
=C2=A0
  •  S=
hould this be somehow baked in the draft?
I'm not sure. Do you think it needs to be? I'm not sure what =
it would say though. 

In such a case the AS co=
uld bind the RT to the given dpop proof and either not bind the AT while re=
turning token_type=3DBearer or bind the AT while returning token_type value=
 DPoP. In the latter case the AT would almost certainly still work as a bea=
rer token at the RS and the client that knew the RS's needs could send =
it as such with an `Authorization: Bearer <at>`. Or if it didn't =
know the RS's needs, it could start with `Authorization: DPoP <at>=
;` which would get a 401 with `WWW-Authenticate: Bearer` at which point it =
could send `Authorization: Bearer <at>`. 

As I wrote the preceding rambling paragraph I am starting to think that m=
ore should be said in the draft about working with RSs that don't suppo=
rt DPoP. Which isn't really what you were asking about. But maybe would=
 cover some of the same ground. 
=C2=A0
=C2=A0<=
/div>
  • Do you think client registration metadata could be used to signal=
 such intent?
I think it certainly c=
ould. But it seems maybe too specific to warrant metadata. 
=
=C2=A0
  • Do you think the protocol should have signals in the messa=
ges themselves to say what the client wants to apply DPoP to?
My initial thought here is no. Take the case of a=
 client working with an AS that supports DPoP and one RS that does and one =
RS that doesn't. I can't really even think what signaling might loo=
k like there or how it could be made to be generally useful.
=
=C2=A0
  • What if AS and RS don't have a shared support DPoP JWS=
 Algorithm? Do we disqualify such cases or allow for sending two proofs, on=
e for the AS to bind refresh tokens to, one for the RS to bind access token=
s to?
The AS is the one that does th=
e binding (which includes checking the proof) so I don't see how sendin=
g two proofs would really work or help the situation? 
=C2=A0=





<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth


--0000000000005678c705a37e2a19--


From nobody Fri Apr 17 08:37:44 2020
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 CDAB73A0E77 for ; Fri, 17 Apr 2020 08:37:43 -0700 (PDT)
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=aol.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 2GfGdyd3FN_y for ; Fri, 17 Apr 2020 08:37:41 -0700 (PDT)
Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (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 5D4793A0E75 for ; Fri, 17 Apr 2020 08:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587137860; bh=Yw5eNIV3M0nXEtGYaQVtHGYecWZeKdhwWHb/ay7IfmA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=uPWZInlHyuL8Wbm+K2y+wvIaBdOfyeXXl2dgoJMlDug2tKAIM5skadxhz+3uE06XJiwgVcg/ehT71b7Agk0+nzXwBjsKvLHox++Xi88YjaGZh8XeTSyieLBZyUOjxV7DDkfEiiOBHjZccWoDn91H2xpQ/1HJ2MwLLky3eboNMIa9+xqtj1RkO2/PTov5QLjiv9Qr82osbsVDrCfjuafwI68fBldRUS/mT+9I2wYyndnfpPTz+s/NIbokMKJIhioKyaafFFKsz8cIO2JQq7PS0WzPvaUpoBH7VM4FD2V9pt11pa1Tuoz1LRn93ij6MtRZB5xJvW17XuDqInx5vKsXZw==
X-YMail-OSG: zh_FAJAVM1nFZqYB1YtY70Y4PW8eONqktqteHegzL19oclsYxwiFiYmnSKVMG64 0HjJyVTZQAJXVeox5PXGXOFRCOcesfDf_Z9HHcipm164CJVqlHrKsl2NljNzGaADw83SMelWtiXl Ecbo6W5gwcK5EyCYvtn0_9GxgJICJup.MjV_u5BRrsqLZpu0keNTzKQQx3cYE6CTlqywa1bJL9fc cDgj4vMf1ZHKfX_5gAH6W.ohPfqF85jdGotRrvM.IVxPKhqxS3N5l3Bp8oMmD_mXpUYrXv1A9VfW aWaFQl_3CYu9T6mhVFoXujaba_Qs0K7y9dd5p6.Gl_vkSi7j7X9bbRzH7TbZGNXnuQqNJkyOtFoZ E_0iDiRhoVuSDyNdhws.0m0h5hW6C2EMky5fUjZEP1BvCuxK2jdbyxtnyntCZE.I1ZBbgPd.bwSP KGSwbJjbJXHXQHEroprjuj1EqPoAOzaTS7XP5p87zpTbYcexBX4wiYIygNHb0RK2TXYbE4RePOIx aI_394FIzqdeR3fs3aKSPrISdoGYPX.TaXCcvq4_goOi7hMPEfp4CYgSTh7LaKUd49_qrthsB9qz L2fw76hhk7oAIsA7ZQsG5MfO69P217ITsBj02Auhev2JUBT1QlxofFnl1hfTkrR2.hd2.6.2EDOw TYzOvhWnD08FlY0yJ6Zs5.0U8026L4mOW7.oW.RrNorUlHSfChpVm7WEHfduUjtFXThLZ2O8IQ86 AaS_MyNWvp3EEBKsbrT2exyv5rT_ILBsllj0LMtRujw3O6aKPeBCyOB8Gnmu.1WCWNNp3Dce0y7M as5XQm25G.bW6Phn3.y1XZyWTjgP0.RwVb.G3YtZ43sz6scvoDH76GiIF6DkJklbxXLGyWFMIsSR _XH2mRxsZiWl7Ue8yCzLiUB6mwfQ50CT_74GE7nR9GNWHFDUsZ9ov.ZH4gFaqgkJqx.WxPZPMhVJ Z5STLgeNHTCbiTtsolsYQi9.BY8SSQNOgIv.skUxMXXULQAbk9YyIVEgiUdKpKWePPxn75DmJOJF ZuM9TDBme2ietCm8qYAilR7tSD4EWNg3Fkd0hgElzMkTaly13peWTq7Kxammw2f6t1SBBMi0t3n. 3qRkUlMKwQiR2K2wZC5oMjnRAt2uY5wL3AwcOn0y.jf079JevgM9kjzioNZxWrOsJxByqFb1Yf3C 9lzjPnRRSw0zf8NndZlIlVkDE.BiOKjkt0wY01gtfd_iD_FmAXx__WpFnrnfdH_EFVCTZeqnH7Qd munedAoBRIPIl8K8TfiP0flptG4Jwmo5Jzt7aSHHZGeByb9.GdurbjnQ3EOXeP9kX4sDHy4D7dBW vyf81mQl_DflUH3W2Q3RnyTORaju0DbH1JlD3_6LC.SjZoJxNgTO60qGGxgG54si18Pcn9Uiu6zz k5U8t4XKUDzOXlF.UM5upR2jYHTMOpbNA2FZ7pPjzEY_1.TswQTGnszDCL.cknHJKgISNSY1uO8N 4.V8w2ccGX06oXmqhJ1C53L_yg7uDHCBVxhZag8nE3wa2
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Apr 2020 15:37:40 +0000
Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e71b54af3802725e12f272aff28f38cd;  Fri, 17 Apr 2020 15:35:38 +0000 (UTC)
To: Filip Skokan , Justin Richer 
Cc: oauth 
References:    <1E6724FE-9EBE-4A1F-BE24-099771FACEFD@mit.edu> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <1d6fb3d7-cd3d-9e46-972c-4c30633a6657@aol.com>
Date: Fri, 17 Apr 2020 11:35:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6443A878E968421F18845B5D"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 15:37:44 -0000

This is a multi-part message in MIME format.
--------------6443A878E968421F18845B5D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

This brings up interesting rollout questions. Protecting just the 
refresh_token is easy and a useful security measure (especially if 
access tokens are short lived). However, once you start issuing DPoP 
bound access tokens to a client, it means ALL the endpoints that client 
invokes MUST understand DPoP and know what to do with the header. 
Depending on how many endpoints that is, spread across N teams (or even 
companies) this can be problematic.

As much as I agree with Justin in regards to the security issues, it may 
not be possible to force all RPs to update at the same time. This is of 
course potentially solvable if the client uses unique access tokens per 
API endpoint AND the AS knows which endpoints support DPoP and which 
don't. The problem here is that this creates a tight-coupling between RP 
and AS (at least for the rollout period).

On 4/17/20 11:25 AM, Filip Skokan wrote:
> I completely agree Justin, as mentioned - i wondered a year ago, I don't
> anymore. But i'd like it to be clear that sending a DPoP proof does not
> necessarily mean the AS MUST issue a DPoP access token. Depending on the
> AS/RS relationship and configuration a regular Bearer may be still be
> issued and only the public client's refresh token would be constrained.
>
> Best,
> *Filip*
>
>
> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>
>> The idea of “Continuing to work without taking advantage of sender
>> constraints” is, I would argue, a security hole. Systems are allowed to
>> fail security checks but still offer functionality. This is exactly the
>> pattern behind allowing an unsigned JWT because you checked the “alg"
>> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
>> that, but maybe we could’ve also made this more explicit within JOSE. By
>> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
>> says to the RS “either you know to look for this or you don’t know what it
>> is”.
>>
>> It’s one of the problems I have with how the OAuth MTLS spec was written.
>> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
>> allows things to fall through in an insecure fashion. The same argument
>> against it — ease of porting existing deployments — was raised there as
>> well, and it won in the end. I hope we can do better this time.
>>
>>   — Justin
>>
>> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>>> token type and authorization scheme. But the draft has gone with a new one.
>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>> would it just be less obvious?
>>>
>> If we had stuck "bearer" than i wouldn't have raised this topic, since
>> existing RS would most likely ignore the cnf claim and the resource server
>> calls would continue to work, obviously without taking advantage of the
>> available sender check.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>>> more should be said in the draft about working with RSs that don't support
>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>> some of the same ground.
>>
>> I agree.
>>
>>   The AS is the one that does the binding (which includes checking the
>>> proof) so I don't see how sending two proofs would really work or help the
>>> situation?
>>
>> :facepalm: indeed, sorry.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
>> wrote:
>>
>>> Hi Filip,
>>>
>>> My attempts at responses to your questions/comments are inline:
>>>
>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>>
>>>> I've wondered about the decision to use a new scheme before
>>>>  but
>>>> this time i'd like to challenge the immediate usability of the future spec
>>>> for one specific case - sender constraining public client Refresh Tokens.
>>>>
>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>> token type and authorization scheme. But the draft has gone with a new one.
>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>> would it just be less obvious?
>>>
>>>
>>>> If at all, it is going to take time for RS implementations to recognize
>>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>>> meantime, i'd still like to have the option to bind issued public client
>>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>>> i get an immediate win in sender constraining the refresh tokens but not
>>>> introducing a breaking change for the RS.
>>>>
>>>>
>>>>     - Do you see this as something an AS implementation is just free to
>>>>     do since it's both the issuer and recipient of a refresh token?
>>>>
>>>> That's my first thought, yes.
>>>
>>>>     - Should this be somehow baked in the draft?
>>>>
>>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>>> say though.
>>>
>>> In such a case the AS could bind the RT to the given dpop proof and
>>> either not bind the AT while returning token_type=Bearer or bind the AT
>>> while returning token_type value DPoP. In the latter case the AT would
>>> almost certainly still work as a bearer token at the RS and the client that
>>> knew the RS's needs could send it as such with an `Authorization: Bearer
>>> `. Or if it didn't know the RS's needs, it could start with
>>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>>> Bearer` at which point it could send `Authorization: Bearer `.
>>>
>>> As I wrote the preceding rambling paragraph I am starting to think that
>>> more should be said in the draft about working with RSs that don't support
>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>> some of the same ground.
>>>
>>>
>>>
>>>>     - Do you think client registration metadata could be used to signal
>>>>     such intent?
>>>>
>>>> I think it certainly could. But it seems maybe too specific to warrant
>>> metadata.
>>>
>>>
>>>>     - Do you think the protocol should have signals in the messages
>>>>     themselves to say what the client wants to apply DPoP to?
>>>>
>>>> My initial thought here is no. Take the case of a client working with an
>>> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
>>> really even think what signaling might look like there or how it could be
>>> made to be generally useful.
>>>
>>>
>>>>     - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>>     Do we disqualify such cases or allow for sending two proofs, one for the AS
>>>>     to bind refresh tokens to, one for the RS to bind access tokens to?
>>>>
>>>> The AS is the one that does the binding (which includes checking the
>>> proof) so I don't see how sending two proofs would really work or help the
>>> situation?
>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited...
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>> _______________________________________________
>> 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


--------------6443A878E968421F18845B5D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    This brings up interesting rollout questions. Protecting just the
    refresh_token is easy and a useful security measure (especially if
    access tokens are short lived). However, once you start issuing DPoP
    bound access tokens to a client, it means ALL the endpoints that
    client invokes MUST understand DPoP and know what to do with the
    header. Depending on how many endpoints that is, spread across N
    teams (or even companies) this can be problematic. 

    

    As much as I agree with Justin in regards to the security issues, it
    may not be possible to force all RPs to update at the same time.
    This is of course potentially solvable if the client uses unique
    access tokens per API endpoint AND the AS knows which endpoints
    support DPoP and which don't. The problem here is that this creates
    a tight-coupling between RP and AS (at least for the rollout
    period).

    

    
On 4/17/20 11:25 AM, Filip Skokan
      wrote:

    

    

      
I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer <jricher@mit.edu> wrote:



      

        
The idea of “Continuing to work without taking advantage of sender
constraints” is, I would argue, a security hole. Systems are allowed to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the “alg"
header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
that, but maybe we could’ve also made this more explicit within JOSE. By
using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
says to the RS “either you know to look for this or you don’t know what it
is”.

It’s one of the problems I have with how the OAuth MTLS spec was written.
By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it — ease of porting existing deployments — was raised there as
well, and it won in the end. I hope we can do better this time.

 — Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva.ip@gmail.com> wrote:

I'm still somewhat on the fence as to the pros and cons of using a new


        

          
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



        

        
If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that


        

          
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


        

        

I agree.

 The AS is the one that does the binding (which includes checking the


        

          
proof) so I don't see how sending two proofs would really work or help the
situation?


        

        

:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampbell@pingidentity.com>
wrote:



        

          
Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:



          

            
I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.



          

          
I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?




          

            
If at all, it is going to take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to
   do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.


          

          



          

            
   - Should this be somehow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would


          

          
say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=Bearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost certainly still work as a bearer token at the RS and the client that
knew the RS's needs could send it as such with an `Authorization: Bearer
<at>`. Or if it didn't know the RS's needs, it could start with
`Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticate:
Bearer` at which point it could send `Authorization: Bearer <at>`.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.





          

            
   - Do you think client registration metadata could be used to signal
   such intent?

I think it certainly could. But it seems maybe too specific to warrant


          

          
metadata.




          

            
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?

My initial thought here is no. Take the case of a client working with an


          

          
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.




          

            
   - What if AS and RS don't have a shared support DPoP JWS Algorithm?
   Do we disqualify such cases or allow for sending two proofs, one for the AS
   to bind refresh tokens to, one for the RS to bind access tokens to?

The AS is the one that does the binding (which includes checking the


          

          
proof) so I don't see how sending two proofs would really work or help the
situation?


*CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly prohibited...
If you have received this communication in error, please notify the sender
immediately by e-mail and delete the message and any file attachments from
your computer. Thank you.*


        

        
_______________________________________________
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


    

    

  


--------------6443A878E968421F18845B5D--


From nobody Fri Apr 17 08:37:55 2020
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 8AC103A0E77 for ; Fri, 17 Apr 2020 08:37:44 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 0Ts-OI5rTePU for ; Fri, 17 Apr 2020 08:37:41 -0700 (PDT)
Received: from sonic302-48.consmr.mail.ne1.yahoo.com (sonic302-48.consmr.mail.ne1.yahoo.com [66.163.186.174]) (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 679B73A0E78 for ; Fri, 17 Apr 2020 08:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587137860; bh=Yw5eNIV3M0nXEtGYaQVtHGYecWZeKdhwWHb/ay7IfmA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=uPWZInlHyuL8Wbm+K2y+wvIaBdOfyeXXl2dgoJMlDug2tKAIM5skadxhz+3uE06XJiwgVcg/ehT71b7Agk0+nzXwBjsKvLHox++Xi88YjaGZh8XeTSyieLBZyUOjxV7DDkfEiiOBHjZccWoDn91H2xpQ/1HJ2MwLLky3eboNMIa9+xqtj1RkO2/PTov5QLjiv9Qr82osbsVDrCfjuafwI68fBldRUS/mT+9I2wYyndnfpPTz+s/NIbokMKJIhioKyaafFFKsz8cIO2JQq7PS0WzPvaUpoBH7VM4FD2V9pt11pa1Tuoz1LRn93ij6MtRZB5xJvW17XuDqInx5vKsXZw==
X-YMail-OSG: zh_FAJAVM1nFZqYB1YtY70Y4PW8eONqktqteHegzL19oclsYxwiFiYmnSKVMG64 0HjJyVTZQAJXVeox5PXGXOFRCOcesfDf_Z9HHcipm164CJVqlHrKsl2NljNzGaADw83SMelWtiXl Ecbo6W5gwcK5EyCYvtn0_9GxgJICJup.MjV_u5BRrsqLZpu0keNTzKQQx3cYE6CTlqywa1bJL9fc cDgj4vMf1ZHKfX_5gAH6W.ohPfqF85jdGotRrvM.IVxPKhqxS3N5l3Bp8oMmD_mXpUYrXv1A9VfW aWaFQl_3CYu9T6mhVFoXujaba_Qs0K7y9dd5p6.Gl_vkSi7j7X9bbRzH7TbZGNXnuQqNJkyOtFoZ E_0iDiRhoVuSDyNdhws.0m0h5hW6C2EMky5fUjZEP1BvCuxK2jdbyxtnyntCZE.I1ZBbgPd.bwSP KGSwbJjbJXHXQHEroprjuj1EqPoAOzaTS7XP5p87zpTbYcexBX4wiYIygNHb0RK2TXYbE4RePOIx aI_394FIzqdeR3fs3aKSPrISdoGYPX.TaXCcvq4_goOi7hMPEfp4CYgSTh7LaKUd49_qrthsB9qz L2fw76hhk7oAIsA7ZQsG5MfO69P217ITsBj02Auhev2JUBT1QlxofFnl1hfTkrR2.hd2.6.2EDOw TYzOvhWnD08FlY0yJ6Zs5.0U8026L4mOW7.oW.RrNorUlHSfChpVm7WEHfduUjtFXThLZ2O8IQ86 AaS_MyNWvp3EEBKsbrT2exyv5rT_ILBsllj0LMtRujw3O6aKPeBCyOB8Gnmu.1WCWNNp3Dce0y7M as5XQm25G.bW6Phn3.y1XZyWTjgP0.RwVb.G3YtZ43sz6scvoDH76GiIF6DkJklbxXLGyWFMIsSR _XH2mRxsZiWl7Ue8yCzLiUB6mwfQ50CT_74GE7nR9GNWHFDUsZ9ov.ZH4gFaqgkJqx.WxPZPMhVJ Z5STLgeNHTCbiTtsolsYQi9.BY8SSQNOgIv.skUxMXXULQAbk9YyIVEgiUdKpKWePPxn75DmJOJF ZuM9TDBme2ietCm8qYAilR7tSD4EWNg3Fkd0hgElzMkTaly13peWTq7Kxammw2f6t1SBBMi0t3n. 3qRkUlMKwQiR2K2wZC5oMjnRAt2uY5wL3AwcOn0y.jf079JevgM9kjzioNZxWrOsJxByqFb1Yf3C 9lzjPnRRSw0zf8NndZlIlVkDE.BiOKjkt0wY01gtfd_iD_FmAXx__WpFnrnfdH_EFVCTZeqnH7Qd munedAoBRIPIl8K8TfiP0flptG4Jwmo5Jzt7aSHHZGeByb9.GdurbjnQ3EOXeP9kX4sDHy4D7dBW vyf81mQl_DflUH3W2Q3RnyTORaju0DbH1JlD3_6LC.SjZoJxNgTO60qGGxgG54si18Pcn9Uiu6zz k5U8t4XKUDzOXlF.UM5upR2jYHTMOpbNA2FZ7pPjzEY_1.TswQTGnszDCL.cknHJKgISNSY1uO8N 4.V8w2ccGX06oXmqhJ1C53L_yg7uDHCBVxhZag8nE3wa2
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Apr 2020 15:37:40 +0000
Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e71b54af3802725e12f272aff28f38cd;  Fri, 17 Apr 2020 15:35:38 +0000 (UTC)
To: Filip Skokan , Justin Richer 
Cc: oauth 
References:    <1E6724FE-9EBE-4A1F-BE24-099771FACEFD@mit.edu> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <1d6fb3d7-cd3d-9e46-972c-4c30633a6657@aol.com>
Date: Fri, 17 Apr 2020 11:35:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6443A878E968421F18845B5D"
Content-Language: en-US
X-Mailer: WebService/1.1.15651 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 15:37:45 -0000

This is a multi-part message in MIME format.
--------------6443A878E968421F18845B5D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

This brings up interesting rollout questions. Protecting just the 
refresh_token is easy and a useful security measure (especially if 
access tokens are short lived). However, once you start issuing DPoP 
bound access tokens to a client, it means ALL the endpoints that client 
invokes MUST understand DPoP and know what to do with the header. 
Depending on how many endpoints that is, spread across N teams (or even 
companies) this can be problematic.

As much as I agree with Justin in regards to the security issues, it may 
not be possible to force all RPs to update at the same time. This is of 
course potentially solvable if the client uses unique access tokens per 
API endpoint AND the AS knows which endpoints support DPoP and which 
don't. The problem here is that this creates a tight-coupling between RP 
and AS (at least for the rollout period).

On 4/17/20 11:25 AM, Filip Skokan wrote:
> I completely agree Justin, as mentioned - i wondered a year ago, I don't
> anymore. But i'd like it to be clear that sending a DPoP proof does not
> necessarily mean the AS MUST issue a DPoP access token. Depending on the
> AS/RS relationship and configuration a regular Bearer may be still be
> issued and only the public client's refresh token would be constrained.
>
> Best,
> *Filip*
>
>
> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>
>> The idea of “Continuing to work without taking advantage of sender
>> constraints” is, I would argue, a security hole. Systems are allowed to
>> fail security checks but still offer functionality. This is exactly the
>> pattern behind allowing an unsigned JWT because you checked the “alg"
>> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
>> that, but maybe we could’ve also made this more explicit within JOSE. By
>> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
>> says to the RS “either you know to look for this or you don’t know what it
>> is”.
>>
>> It’s one of the problems I have with how the OAuth MTLS spec was written.
>> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
>> allows things to fall through in an insecure fashion. The same argument
>> against it — ease of porting existing deployments — was raised there as
>> well, and it won in the end. I hope we can do better this time.
>>
>>   — Justin
>>
>> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>>
>> I'm still somewhat on the fence as to the pros and cons of using a new
>>> token type and authorization scheme. But the draft has gone with a new one.
>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>> would it just be less obvious?
>>>
>> If we had stuck "bearer" than i wouldn't have raised this topic, since
>> existing RS would most likely ignore the cnf claim and the resource server
>> calls would continue to work, obviously without taking advantage of the
>> available sender check.
>>
>> As I wrote the preceding rambling paragraph I am starting to think that
>>> more should be said in the draft about working with RSs that don't support
>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>> some of the same ground.
>>
>> I agree.
>>
>>   The AS is the one that does the binding (which includes checking the
>>> proof) so I don't see how sending two proofs would really work or help the
>>> situation?
>>
>> :facepalm: indeed, sorry.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
>> wrote:
>>
>>> Hi Filip,
>>>
>>> My attempts at responses to your questions/comments are inline:
>>>
>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>>
>>>> I've wondered about the decision to use a new scheme before
>>>>  but
>>>> this time i'd like to challenge the immediate usability of the future spec
>>>> for one specific case - sender constraining public client Refresh Tokens.
>>>>
>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>> token type and authorization scheme. But the draft has gone with a new one.
>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>> would it just be less obvious?
>>>
>>>
>>>> If at all, it is going to take time for RS implementations to recognize
>>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>>> meantime, i'd still like to have the option to bind issued public client
>>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>>> i get an immediate win in sender constraining the refresh tokens but not
>>>> introducing a breaking change for the RS.
>>>>
>>>>
>>>>     - Do you see this as something an AS implementation is just free to
>>>>     do since it's both the issuer and recipient of a refresh token?
>>>>
>>>> That's my first thought, yes.
>>>
>>>>     - Should this be somehow baked in the draft?
>>>>
>>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>>> say though.
>>>
>>> In such a case the AS could bind the RT to the given dpop proof and
>>> either not bind the AT while returning token_type=Bearer or bind the AT
>>> while returning token_type value DPoP. In the latter case the AT would
>>> almost certainly still work as a bearer token at the RS and the client that
>>> knew the RS's needs could send it as such with an `Authorization: Bearer
>>> `. Or if it didn't know the RS's needs, it could start with
>>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>>> Bearer` at which point it could send `Authorization: Bearer `.
>>>
>>> As I wrote the preceding rambling paragraph I am starting to think that
>>> more should be said in the draft about working with RSs that don't support
>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>> some of the same ground.
>>>
>>>
>>>
>>>>     - Do you think client registration metadata could be used to signal
>>>>     such intent?
>>>>
>>>> I think it certainly could. But it seems maybe too specific to warrant
>>> metadata.
>>>
>>>
>>>>     - Do you think the protocol should have signals in the messages
>>>>     themselves to say what the client wants to apply DPoP to?
>>>>
>>>> My initial thought here is no. Take the case of a client working with an
>>> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
>>> really even think what signaling might look like there or how it could be
>>> made to be generally useful.
>>>
>>>
>>>>     - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>>     Do we disqualify such cases or allow for sending two proofs, one for the AS
>>>>     to bind refresh tokens to, one for the RS to bind access tokens to?
>>>>
>>>> The AS is the one that does the binding (which includes checking the
>>> proof) so I don't see how sending two proofs would really work or help the
>>> situation?
>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited...
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>> _______________________________________________
>> 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


--------------6443A878E968421F18845B5D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    This brings up interesting rollout questions. Protecting just the
    refresh_token is easy and a useful security measure (especially if
    access tokens are short lived). However, once you start issuing DPoP
    bound access tokens to a client, it means ALL the endpoints that
    client invokes MUST understand DPoP and know what to do with the
    header. Depending on how many endpoints that is, spread across N
    teams (or even companies) this can be problematic. 

    

    As much as I agree with Justin in regards to the security issues, it
    may not be possible to force all RPs to update at the same time.
    This is of course potentially solvable if the client uses unique
    access tokens per API endpoint AND the AS knows which endpoints
    support DPoP and which don't. The problem here is that this creates
    a tight-coupling between RP and AS (at least for the rollout
    period).

    

    
On 4/17/20 11:25 AM, Filip Skokan
      wrote:

    

    

      
I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer <jricher@mit.edu> wrote:



      

        
The idea of “Continuing to work without taking advantage of sender
constraints” is, I would argue, a security hole. Systems are allowed to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the “alg"
header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
that, but maybe we could’ve also made this more explicit within JOSE. By
using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
says to the RS “either you know to look for this or you don’t know what it
is”.

It’s one of the problems I have with how the OAuth MTLS spec was written.
By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it — ease of porting existing deployments — was raised there as
well, and it won in the end. I hope we can do better this time.

 — Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva.ip@gmail.com> wrote:

I'm still somewhat on the fence as to the pros and cons of using a new


        

          
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



        

        
If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that


        

          
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


        

        

I agree.

 The AS is the one that does the binding (which includes checking the


        

          
proof) so I don't see how sending two proofs would really work or help the
situation?


        

        

:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampbell@pingidentity.com>
wrote:



        

          
Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:



          

            
I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.



          

          
I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?




          

            
If at all, it is going to take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to
   do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.


          

          



          

            
   - Should this be somehow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would


          

          
say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=Bearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost certainly still work as a bearer token at the RS and the client that
knew the RS's needs could send it as such with an `Authorization: Bearer
<at>`. Or if it didn't know the RS's needs, it could start with
`Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticate:
Bearer` at which point it could send `Authorization: Bearer <at>`.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.





          

            
   - Do you think client registration metadata could be used to signal
   such intent?

I think it certainly could. But it seems maybe too specific to warrant


          

          
metadata.




          

            
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?

My initial thought here is no. Take the case of a client working with an


          

          
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.




          

            
   - What if AS and RS don't have a shared support DPoP JWS Algorithm?
   Do we disqualify such cases or allow for sending two proofs, one for the AS
   to bind refresh tokens to, one for the RS to bind access tokens to?

The AS is the one that does the binding (which includes checking the


          

          
proof) so I don't see how sending two proofs would really work or help the
situation?


*CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly prohibited...
If you have received this communication in error, please notify the sender
immediately by e-mail and delete the message and any file attachments from
your computer. Thank you.*


        

        
_______________________________________________
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


    

    

  


--------------6443A878E968421F18845B5D--


From nobody Fri Apr 17 09:26:01 2020
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 A8D883A0CB9 for ; Fri, 17 Apr 2020 09:26:00 -0700 (PDT)
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 prl8B23Pky4D for ; Fri, 17 Apr 2020 09:25:59 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 DEC4A3A11A3 for ; Fri, 17 Apr 2020 09:25:58 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id o127so2947844iof.0 for ; Fri, 17 Apr 2020 09:25:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=yZ26VDoHWgswEauP5HHlJoe4vUYL/CST0CoYw/vHU4k=; b=P9LJvsvfIAu2TgvgVrP8oSHcbg0+zzaHYRq2miQavPWm7XoFcEjfT7xXLX5V2q/Zuw RHs1YJssGvlSieyu5gC8YjWUNOesxCFVBSuB5cFVsuOUfUQQe+HZdcvIb0VREtWjABTw wQAlKsimKY0IAv2lEKNiCkpoWQ9dXKIsNolAYkOI5MYXesJTR2x4MjnvZp/FgcMFqsLO BvJ+eaI61OnWTkATugtAXhzxEtXi6LTfEXfC6Q5sGHHUuIIJzuyO3fQhHABotXiJLm61 AV2/OF/nN/gxuAOdfsdyHYziPLKLrf3uhJPCacufkC29YEPfjVIXGCZM01mEsP+ZLtdn hL/g==
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=yZ26VDoHWgswEauP5HHlJoe4vUYL/CST0CoYw/vHU4k=; b=MSZJNi4LRz8sFhPbNrsgQMB/7uEeXHUkSgpddkeRrbM+LHoFWgRMXsn3eiG4G4MSQ8 rOcu4U5ruxDdlWpDL5h+trW8L8A1reSK3kDHJXU4iEfg/g9CGM78nzXyN/3Y9cWhSLPo 278lviKraoFYSp+4IKnba1Sorp21p00Bbyzel82GLWVwH8hv2F+j5Whn/RG4EvpJ6gZ2 Xm7YWZ8cV2m+ld03O3gWRy+QTrhuIvulGGAe4OIjiACA9HDSBYXmT8FwhQl8iYSm6S/k Rweunf5DJ+Uv4jtN5bLDslbydZxgy3SeZiPCLZzBLvWrhYg+Tnkg2YeGmWO/lwiA8d5s 5frg==
X-Gm-Message-State: AGi0PuZS+zEoHdYijrOAGMzw8AFuf39av8/ultvZhVdq04zlgiGCX/ni NqXOduXoUtSUZgchvSN+2hK10eQNj0nX4vJM6suXMMVg+XY=
X-Google-Smtp-Source: APiQypJ0Wl4aP1JHl5LIEV0EiajTyY7sq81JTHoOZmSpMN7Izc+BE624/ey4xwGrw8N5H8q98RrDy8Fco8t/IayTKCE=
X-Received: by 2002:a5e:9504:: with SMTP id r4mr3791665ioj.2.1587140757715; Fri, 17 Apr 2020 09:25:57 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com>
In-Reply-To: <158628195716.9275.10690808358259357603@ietfa.amsl.com>
From: Rifaat Shekh-Yusef 
Date: Fri, 17 Apr 2020 12:25:46 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000012800505a37f0130"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-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: Fri, 17 Apr 2020 16:26:01 -0000

--00000000000012800505a37f0130
Content-Type: text/plain; charset="UTF-8"

All,

You can find this meeting minutes at the following link:
https://datatracker.ietf.org/doc/minutes-interim-2020-oauth-04-202004131200/


Thanks to *Jared Jennings *for taking these notes.

Regards,
 Rifaat & Hannes



On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary 
wrote:

> The Web Authorization Protocol (oauth) Working Group will hold
> a virtual interim meeting on 2020-04-13 from 12:00 to 13:00
> America/Toronto (16:00 to 17:00 UTC).
>
> Agenda:
> 1. Nested JWT
> https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt
>
> 2. JWT Profile for Access Tokens
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
> Information about remote participation:
> https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000012800505a37f0130
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find this meeti=
ng minutes at the following link:
=


Thanks to Jared Jennings for taking these notes.=


Regards,


--00000000000012800505a37f0130--


From nobody Fri Apr 17 11:40:01 2020
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 C980E3A15FC for ; Fri, 17 Apr 2020 11:39:52 -0700 (PDT)
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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=lodderstedt.net
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 eas8w4MkeOQ1 for ; Fri, 17 Apr 2020 11:39:49 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 9FD403A1607 for ; Fri, 17 Apr 2020 11:39:42 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id x4so3916093wmj.1 for ; Fri, 17 Apr 2020 11:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=m10Nn8+fq5WQqON/UNkiQuwXIqE3Py8bQdA4ujc9lgY=; b=XEyNQf8WqvkQ1IlLOzK27B1ololf3id6koQFeySMyhPtx0yUEseu9TnB/Y9IM47oJG JOebDslIig2oPK6IOvCt7x8s+wjW8qHmNBTFdhJ79xRTrdyH9MQSnSJV9zkuR4qoRegD o8QTAsfiwFyS/ARVMM+54qWqA1pqJFQTsRRPuBcyQqK/xbmg6StagBg2DgyPRVaVWBb5 lvZJb3u+TlQzgvTQfVqIPuUv0Wc0IZSepMN0Upc1tyLaNgB2RualWY4eayuE3fHfgDND QvQ6SNBXpIvXUBtMwUv6hO8fwJg1BeGYfzaZtdfEXxT4WpZjq4/f0K8ZrtM+TKqQc+t4 I8+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=m10Nn8+fq5WQqON/UNkiQuwXIqE3Py8bQdA4ujc9lgY=; b=PqHWZlVi9OUnA+xA8sUr74DAl7aU+l8T3jpBpfKZBDo+/I5zei31od/MwY3nSHPLSE Uc+EgosdYLsek8MHVut9WojC+SaDY2nsbcZ3OTnGif0eXWeI0ejMWcMHMdSJPSdSaI04 KhCWxUSuYprLyNBRrNHlwJKVx6iptznB4sBRTvGRPSed601ry5wQSAQO1E+lVTiIVq1W XzQ/6XvP1ATYtqoiqLuQvpYutyh3q6KElFM/5AM0K0qLLmDEYjUprILUCsiEb3U89Js4 OcIghMFbHPVgkqYUkcHQbY0FlxAzw0Zob5fbaCYKMlU8+3P4I5zc/UAgBWJdo+6SpFJG MnFg==
X-Gm-Message-State: AGi0Pua+324iNl/KWaA1qVzaFdJHQoHKG+G+Z7abTTYM3jno/jf36uni PLh0e9CjiGVyeAQ0fRzwS/cvjw==
X-Google-Smtp-Source: APiQypJoVltm0hyZMFcsauC766YmDM9g9V3p3Ib1Be+Ewxj+j5rluq+TLEHP7kL1gbrQpEgLEnycpg==
X-Received: by 2002:a05:600c:2210:: with SMTP id z16mr4877997wml.151.1587148780867;  Fri, 17 Apr 2020 11:39:40 -0700 (PDT)
Received: from [192.168.71.106] (p5B0D9376.dip0.t-ipconnect.de. [91.13.147.118]) by smtp.gmail.com with ESMTPSA id n4sm8160151wrr.68.2020.04.17.11.39.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 11:39:39 -0700 (PDT)
Content-Type: multipart/signed; boundary=Apple-Mail-333E8CAE-F58A-4A62-9ECD-C00464EB4B6C; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt 
Mime-Version: 1.0 (1.0)
Date: Fri, 17 Apr 2020 20:39:38 +0200
Message-Id: <033DBD9F-9C5B-465B-ABD6-27A8525ADDA9@lodderstedt.net>
References: <1d6fb3d7-cd3d-9e46-972c-4c30633a6657@aol.com>
Cc: Filip Skokan , Justin Richer , oauth 
In-Reply-To: <1d6fb3d7-cd3d-9e46-972c-4c30633a6657@aol.com>
To: George Fletcher 
X-Mailer: iPad Mail (17D50)
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 18:39:59 -0000

--Apple-Mail-333E8CAE-F58A-4A62-9ECD-C00464EB4B6C
Content-Type: multipart/alternative;
	boundary=Apple-Mail-76874CB8-E31C-4D9F-84FA-BAAFC4666901
Content-Transfer-Encoding: 7bit


--Apple-Mail-76874CB8-E31C-4D9F-84FA-BAAFC4666901
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think the same is already true for mTLS. Solving it in an interoperable wa=
y would require some metadata about RS and their requirements re mTLS/DPoP. S=
hall we revitalize the idea of RS metadata?

> Am 17.04.2020 um 17:37 schrieb George Fletcher :
>=20
> =EF=BB=BF This brings up interesting rollout questions. Protecting just th=
e refresh_token is easy and a useful security measure (especially if access t=
okens are short lived). However, once you start issuing DPoP bound access to=
kens to a client, it means ALL the endpoints that client invokes MUST unders=
tand DPoP and know what to do with the header. Depending on how many endpoin=
ts that is, spread across N teams (or even companies) this can be problemati=
c.=20
>=20
> As much as I agree with Justin in regards to the security issues, it may n=
ot be possible to force all RPs to update at the same time. This is of cours=
e potentially solvable if the client uses unique access tokens per API endpo=
int AND the AS knows which endpoints support DPoP and which don't. The probl=
em here is that this creates a tight-coupling between RP and AS (at least fo=
r the rollout period).
>=20
> On 4/17/20 11:25 AM, Filip Skokan wrote:
>> I completely agree Justin, as mentioned - i wondered a year ago, I don't
>> anymore. But i'd like it to be clear that sending a DPoP proof does not
>> necessarily mean the AS MUST issue a DPoP access token. Depending on the
>> AS/RS relationship and configuration a regular Bearer may be still be
>> issued and only the public client's refresh token would be constrained.
>>=20
>> Best,
>> *Filip*
>>=20
>>=20
>> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>>=20
>>> The idea of =E2=80=9CContinuing to work without taking advantage of send=
er
>>> constraints=E2=80=9D is, I would argue, a security hole. Systems are all=
owed to
>>> fail security checks but still offer functionality. This is exactly the
>>> pattern behind allowing an unsigned JWT because you checked the =E2=80=9C=
alg"
>>> header and it was =E2=80=9Cnone=E2=80=9D and so you=E2=80=99re OK with t=
hat. Yes, you shouldn=E2=80=99t do
>>> that, but maybe we could=E2=80=99ve also made this more explicit within J=
OSE. By
>>> using the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a cle=
ar syntactic change that
>>> says to the RS =E2=80=9Ceither you know to look for this or you don=E2=80=
=99t know what it
>>> is=E2=80=9D.
>>>=20
>>> It=E2=80=99s one of the problems I have with how the OAuth MTLS spec was=
 written.
>>> By re-using the =E2=80=9CBearer=E2=80=9D scheme there, I believe we=E2=80=
=99ve made a mistake that
>>> allows things to fall through in an insecure fashion. The same argument
>>> against it =E2=80=94 ease of porting existing deployments =E2=80=94 was r=
aised there as
>>> well, and it won in the end. I hope we can do better this time.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>>>=20
>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>>>> Would it have really helped this situation, if it'd stuck with "bearer"=
? Or
>>>> would it just be less obvious?
>>>>=20
>>> If we had stuck "bearer" than i wouldn't have raised this topic, since
>>> existing RS would most likely ignore the cnf claim and the resource serv=
er
>>> calls would continue to work, obviously without taking advantage of the
>>> available sender check.
>>>=20
>>> As I wrote the preceding rambling paragraph I am starting to think that
>>>> more should be said in the draft about working with RSs that don't supp=
ort
>>>> DPoP. Which isn't really what you were asking about. But maybe would co=
ver
>>>> some of the same ground.
>>>=20
>>> I agree.
>>>=20
>>>  The AS is the one that does the binding (which includes checking the
>>>> proof) so I don't see how sending two proofs would really work or help t=
he
>>>> situation?
>>>=20
>>> :facepalm: indeed, sorry.
>>>=20
>>> S pozdravem,
>>> *Filip Skokan*
>>>=20
>>>=20
>>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
>>> wrote:
>>>=20
>>>> Hi Filip,
>>>>=20
>>>> My attempts at responses to your questions/comments are inline:
>>>>=20
>>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote=
:
>>>>=20
>>>>> I've wondered about the decision to use a new scheme before
>>>>>  but
>>>>> this time i'd like to challenge the immediate usability of the future s=
pec
>>>>> for one specific case - sender constraining public client Refresh Toke=
ns.
>>>>>=20
>>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>>> token type and authorization scheme. But the draft has gone with a new o=
ne.
>>>> Would it have really helped this situation, if it'd stuck with "bearer"=
? Or
>>>> would it just be less obvious?
>>>>=20
>>>>=20
>>>>> If at all, it is going to take time for RS implementations to recogniz=
e
>>>>> the new `DPoP` authorization scheme, let alone process it properly. In=
 the
>>>>> meantime, i'd still like to have the option to bind issued public clie=
nt
>>>>> refresh tokens using DPoP without affecting the access tokens. In doin=
g so
>>>>> i get an immediate win in sender constraining the refresh tokens but n=
ot
>>>>> introducing a breaking change for the RS.
>>>>>=20
>>>>>=20
>>>>>    - Do you see this as something an AS implementation is just free to=

>>>>>    do since it's both the issuer and recipient of a refresh token?
>>>>>=20
>>>>> That's my first thought, yes.
>>>>=20
>>>>>    - Should this be somehow baked in the draft?
>>>>>=20
>>>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>>>> say though.
>>>>=20
>>>> In such a case the AS could bind the RT to the given dpop proof and
>>>> either not bind the AT while returning token_type=3DBearer or bind the A=
T
>>>> while returning token_type value DPoP. In the latter case the AT would
>>>> almost certainly still work as a bearer token at the RS and the client t=
hat
>>>> knew the RS's needs could send it as such with an `Authorization: Beare=
r
>>>> `. Or if it didn't know the RS's needs, it could start with
>>>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate=
:
>>>> Bearer` at which point it could send `Authorization: Bearer `.
>>>>=20
>>>> As I wrote the preceding rambling paragraph I am starting to think that=

>>>> more should be said in the draft about working with RSs that don't supp=
ort
>>>> DPoP. Which isn't really what you were asking about. But maybe would co=
ver
>>>> some of the same ground.
>>>>=20
>>>>=20
>>>>=20
>>>>>    - Do you think client registration metadata could be used to signal=

>>>>>    such intent?
>>>>>=20
>>>>> I think it certainly could. But it seems maybe too specific to warrant=

>>>> metadata.
>>>>=20
>>>>=20
>>>>>    - Do you think the protocol should have signals in the messages
>>>>>    themselves to say what the client wants to apply DPoP to?
>>>>>=20
>>>>> My initial thought here is no. Take the case of a client working with a=
n
>>>> AS that supports DPoP and one RS that does and one RS that doesn't. I c=
an't
>>>> really even think what signaling might look like there or how it could b=
e
>>>> made to be generally useful.
>>>>=20
>>>>=20
>>>>>    - What if AS and RS don't have a shared support DPoP JWS Algorithm?=

>>>>>    Do we disqualify such cases or allow for sending two proofs, one fo=
r the AS
>>>>>    to bind refresh tokens to, one for the RS to bind access tokens to?=

>>>>>=20
>>>>> The AS is the one that does the binding (which includes checking the
>>>> proof) so I don't see how sending two proofs would really work or help t=
he
>>>> situation?
>>>>=20
>>>>=20
>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly prohibite=
d...
>>>> If you have received this communication in error, please notify the sen=
der
>>>> immediately by e-mail and delete the message and any file attachments f=
rom
>>>> your computer. Thank you.*
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-76874CB8-E31C-4D9F-84FA-BAAFC4666901
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I think the same is alread=
y true for mTLS. Solving it in an interoperable way would require some metad=
ata about RS and their requirements re mTLS/DPoP. Shall we revitalize the id=
ea of RS metadata?

Am 17=
.04.2020 um 17:37 schrieb George Fletcher <gffletch=3D40aol.com@dmarc.iet=
f.org>:

=EF=BB=BF
 =20
    
 =20
 =20
    This brings up interesting rollout questions. Protecting just the
    refresh_token is easy and a useful security measure (especially if
    access tokens are short lived). However, once you start issuing DPoP
    bound access tokens to a client, it means ALL the endpoints that
    client invokes MUST understand DPoP and know what to do with the
    header. Depending on how many endpoints that is, spread across N
    teams (or even companies) this can be problematic. 

    

    As much as I agree with Justin in regards to the security issues, it
    may not be possible to force all RPs to update at the same time.
    This is of course potentially solvable if the client uses unique
    access tokens per API endpoint AND the AS knows which endpoints
    support DPoP and which don't. The problem here is that this creates
    a tight-coupling between RP and AS (at least for the rollout
    period).

    

    
On 4/17/20 11:25 AM, Filip Skokan
      wrote:

    

    

      
I completely agree Justin, as m=
entioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer <jricher@mit.edu> wrote:



      

        
The idea of =E2=80=9CContinui=
ng to work without taking advantage of sender
constraints=E2=80=9D is, I would argue, a security hole. Systems are allowed=
 to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the =E2=80=9Calg=
"
header and it was =E2=80=9Cnone=E2=80=9D and so you=E2=80=99re OK with that.=
 Yes, you shouldn=E2=80=99t do
that, but maybe we could=E2=80=99ve also made this more explicit within JOSE=
. By
using the =E2=80=98DPoP=E2=80=99 auth scheme, we=E2=80=99re making a clear s=
yntactic change that
says to the RS =E2=80=9Ceither you know to look for this or you don=E2=80=99=
t know what it
is=E2=80=9D.

It=E2=80=99s one of the problems I have with how the OAuth MTLS spec was wri=
tten.
By re-using the =E2=80=9CBearer=E2=80=9D scheme there, I believe we=E2=80=99=
ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it =E2=80=94 ease of porting existing deployments =E2=80=94 was rais=
ed there as
well, and it won in the end. I hope we can do better this time.

 =E2=80=94 Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva.ip@gmail.com> wrote:

I'm still somewhat on the fence as to the pros and cons of using a new


        

          
token type and authorizatio=
n scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



        

        
If we had stuck "bearer" than=
 i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that


        

          
more should be said in the d=
raft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


        

        
I agree.

 The AS is the one that does the binding (which includes checking the


        

          
proof) so I don't see how s=
ending two proofs would really work or help the
situation?


        

        
:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampbell@pingidentity.co=
m>
wrote:



        

          
Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:=




          

            
I've wondered about the d=
ecision to use a new scheme before
<https://github.com/danielfett/=
draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.



          

          
I'm still somewhat on the f=
ence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?




          

            
If at all, it is going to=
 take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to
   do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.


          

          

          

            
   - Should this be someh=
ow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would


          

          
say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=3DBearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost certainly still work as a bearer token at the RS and the client that
knew the RS's needs could send it as such with an `Authorization: Bearer
<at>`. Or if it didn't know the RS's needs, it could start with
`Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticat=
e:
Bearer` at which point it could send `Authorization: Bearer <at>`.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.





          

            
   - Do you think client r=
egistration metadata could be used to signal
   such intent?

I think it certainly could. But it seems maybe too specific to warrant


          

          
metadata.




          

            
   - Do you think the pro=
tocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?

My initial thought here is no. Take the case of a client working with an


          

          
AS that supports DPoP and o=
ne RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.




          

            
   - What if AS and RS do=
n't have a shared support DPoP JWS Algorithm?
   Do we disqualify such cases or allow for sending two proofs, one for the A=
S
   to bind refresh tokens to, one for the RS to bind access tokens to?

The AS is the one that does the binding (which includes checking the


          

          
proof) so I don't see how s=
ending two proofs would really work or help the
situation?


*CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly prohibited...
If you have received this communication in error, please notify the sender
immediately by e-mail and delete the message and any file attachments from
your computer. Thank you.*


        

        
_____________________________=
__________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth





      

      

      

      

      
_______________________________=
________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

 =20

_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth
=

--Apple-Mail-76874CB8-E31C-4D9F-84FA-BAAFC4666901--

--Apple-Mail-333E8CAE-F58A-4A62-9ECD-C00464EB4B6C
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw
ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG
EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE
CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G
A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN
Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F
jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb
IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy
zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr
BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw
MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R
BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr
BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp
cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7
2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe
GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/
L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE
tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q
CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3
/crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM
B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w
LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD
QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDE3MTgzOTM4WjAvBgkqhkiG9w0BCQQxIgQg
Eod3l43F6RZ7euQN+Etb5SzqQo2Xlxfi5HDtnWYtft4wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL
MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x
IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs
aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ
AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250
ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE
AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw
DQYJKoZIhvcNAQEBBQAEggEARZs8YvLFs/0EseB+0mXqApcMFqjT0Sej0SplT8UkbaNvV40rKHol
jZsxZh+Uu3YQWHjExpbZX6k97HmZF35YLfT16bKMqAigFjN4By7Jwg1i0p7i0bAI8x1Ic2N+dDE3
pom2kUUXxs83tJ3uUhLJh8niJHggd/ElwyMPUGt0miHDfXebEYrL2dAi81hde49tXSKL48WHtt20
NHb47beOowtzXq49ZHU8VLHco1XEG3uVRXad2KUSBI9z4BehlgIgQlGev3v9TBQH9WSz79qckawk
dkNdkuGR2uosyup7IRHyveonAwLIR9vexRzz5TQx9nUZ5wbQDlDyMSN5o03SOwAAAAAAAA==

--Apple-Mail-333E8CAE-F58A-4A62-9ECD-C00464EB4B6C--


From nobody Fri Apr 17 12:04:15 2020
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 B71B83A065A for ; Fri, 17 Apr 2020 12:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujC57qMO8i7N for ; Fri, 17 Apr 2020 12:04:10 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 04FE53A08A7 for ; Fri, 17 Apr 2020 12:03:15 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id b62so3585330qkf.6 for ; Fri, 17 Apr 2020 12:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=pIsukEIhaC4TagQBIEp/ZR1chK11+2B2OR4GYb/9E7E=; b=crIvdulBeOHRahy+Zor3wGz1N3/iLgU/Tn9y8quUlUpRGYqKOGRJ9WCbGQ8DMwTzcL UuoyAP8pxh7Ic7NaJmhsMWSr/98r7Vf4q7tCAN7baf1f4xgR3ZdQItWqpkOsEajDnK4J vhrioRhO7whswLFVCp5MgFzmC4+aW4OO7idAyVkCz1dVWiwyXA2kTFH8pNuA7qq9bO74 QqgZCobK/0/sFUkvnE1xL/00KQaf8aOOQYbwTdB95b/nTUnB+0DFmpyVp15OXUw1KdS+ ddpDL/udCeKyFr/QGWKzIJcfBq6lDPF+J/AIdf8J6S3XKALM8NZx1xrHVMMEIfmqsEp4 ktJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=pIsukEIhaC4TagQBIEp/ZR1chK11+2B2OR4GYb/9E7E=; b=YFxrE7pnwJdULkbDjNr4zrcsN98GAQg2iEFMElYPlWCDm3W5OqyKsQJYEqLYEyHj9R 5KhPO0LTE2IpwO4gFpxda1q/fiuOG0hJNuOvH/MeY/j726vyGXlLpdV14S3zqnX6EsZ+ YPtMtamRZDXdgXWgbo2w+AREHwgBaWGbeegDysVVf5PvL9/M/nEi6IwtYMpCJFDYNRZz NBmluZrtEmJFIEVbX9L/rkO0HUv04A63vytRwgs+IfWwn8TSz1Tw8sUulxJW9x+eDUd6 FMOSvhdr4wnExQnziCs4993hMOPFKNJQrOjDO6ZgCqJCJzTHRQnKJb4L2oNb5AaqsWWC uAYQ==
X-Gm-Message-State: AGi0PuYT9f9xcNy6wX+B0g2Ewcy9B5TG38k/Dfc5a0pOuvvPQJzv+0TK p1XnAXQUKUIGkBk0Whckfx/hEwvKPkF11D9y
X-Google-Smtp-Source: APiQypIoZGX8R2aUQLU3Il/ZTq4kJKHxWImjGglwRibtzA0mutXSDbt087aJ662SW+Mz9xEObZ62ag==
X-Received: by 2002:a37:e10c:: with SMTP id c12mr4686167qkm.483.1587150193139;  Fri, 17 Apr 2020 12:03:13 -0700 (PDT)
Received: from [192.168.8.104] ([190.107.226.32]) by smtp.gmail.com with ESMTPSA id k58sm1194811qtf.40.2020.04.17.12.03.10 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 12:03:12 -0700 (PDT)
To: oauth@ietf.org
References: <1d6fb3d7-cd3d-9e46-972c-4c30633a6657@aol.com> <033DBD9F-9C5B-465B-ABD6-27A8525ADDA9@lodderstedt.net>
From: John Bradley 
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <840bc070-3a35-5df5-4164-1fb332e44b7c@ve7jtb.com>
Date: Fri, 17 Apr 2020 15:03:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <033DBD9F-9C5B-465B-ABD6-27A8525ADDA9@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------345E10107B63E6704B5BE915"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
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, 17 Apr 2020 19:04:14 -0000

This is a multi-part message in MIME format.
--------------345E10107B63E6704B5BE915
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

I agree that without a tight binding between the RS and AS we need to
revisit RS meta-data.

It is a can of worms however.


On 4/17/2020 2:39 PM, Torsten Lodderstedt wrote:
> I think the same is already true for mTLS. Solving it in an
> interoperable way would require some metadata about RS and their
> requirements re mTLS/DPoP. Shall we revitalize the idea of RS metadata?
>
>> Am 17..04.2020 um 17:37 schrieb George Fletcher
>> :
>>
>>  This brings up interesting rollout questions. Protecting just the
>> refresh_token is easy and a useful security measure (especially if
>> access tokens are short lived). However, once you start issuing DPoP
>> bound access tokens to a client, it means ALL the endpoints that
>> client invokes MUST understand DPoP and know what to do with the
>> header. Depending on how many endpoints that is, spread across N
>> teams (or even companies) this can be problematic.
>>
>> As much as I agree with Justin in regards to the security issues, it
>> may not be possible to force all RPs to update at the same time. This
>> is of course potentially solvable if the client uses unique access
>> tokens per API endpoint AND the AS knows which endpoints support DPoP
>> and which don't. The problem here is that this creates a
>> tight-coupling between RP and AS (at least for the rollout period).
>>
>> On 4/17/20 11:25 AM, Filip Skokan wrote:
>>> I completely agree Justin, as mentioned - i wondered a year ago, I don't
>>> anymore. But i'd like it to be clear that sending a DPoP proof does not
>>> necessarily mean the AS MUST issue a DPoP access token. Depending on the
>>> AS/RS relationship and configuration a regular Bearer may be still be
>>> issued and only the public client's refresh token would be constrained.
>>>
>>> Best,
>>> *Filip*
>>>
>>>
>>> On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:
>>>
>>>> The idea of “Continuing to work without taking advantage of sender
>>>> constraints” is, I would argue, a security hole. Systems are allowed to
>>>> fail security checks but still offer functionality. This is exactly the
>>>> pattern behind allowing an unsigned JWT because you checked the “alg"
>>>> header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
>>>> that, but maybe we could’ve also made this more explicit within JOSE.. By
>>>> using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
>>>> says to the RS “either you know to look for this or you don’t know what it
>>>> is”.
>>>>
>>>> It’s one of the problems I have with how the OAuth MTLS spec was written.
>>>> By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
>>>> allows things to fall through in an insecure fashion. The same argument
>>>> against it — ease of porting existing deployments — was raised there as
>>>> well, and it won in the end. I hope we can do better this time.
>>>>
>>>>  — Justin
>>>>
>>>> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
>>>>
>>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>>>> token type and authorization scheme. But the draft has gone with a new one.
>>>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>>>> would it just be less obvious?
>>>>>
>>>> If we had stuck "bearer" than i wouldn't have raised this topic, since
>>>> existing RS would most likely ignore the cnf claim and the resource server
>>>> calls would continue to work, obviously without taking advantage of the
>>>> available sender check.
>>>>
>>>> As I wrote the preceding rambling paragraph I am starting to think that
>>>>> more should be said in the draft about working with RSs that don't support
>>>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>>>> some of the same ground.
>>>> I agree.
>>>>
>>>>  The AS is the one that does the binding (which includes checking the
>>>>> proof) so I don't see how sending two proofs would really work or help the
>>>>> situation?
>>>> :facepalm: indeed, sorry.
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>> On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
>>>> wrote:
>>>>
>>>>> Hi Filip,
>>>>>
>>>>> My attempts at responses to your questions/comments are inline:
>>>>>
>>>>> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:
>>>>>
>>>>>> I've wondered about the decision to use a new scheme before
>>>>>>  but
>>>>>> this time i'd like to challenge the immediate usability of the future spec
>>>>>> for one specific case - sender constraining public client Refresh Tokens.
>>>>>>
>>>>> I'm still somewhat on the fence as to the pros and cons of using a new
>>>>> token type and authorization scheme. But the draft has gone with a new one.
>>>>> Would it have really helped this situation, if it'd stuck with "bearer"? Or
>>>>> would it just be less obvious?
>>>>>
>>>>>
>>>>>> If at all, it is going to take time for RS implementations to recognize
>>>>>> the new `DPoP` authorization scheme, let alone process it properly. In the
>>>>>> meantime, i'd still like to have the option to bind issued public client
>>>>>> refresh tokens using DPoP without affecting the access tokens. In doing so
>>>>>> i get an immediate win in sender constraining the refresh tokens but not
>>>>>> introducing a breaking change for the RS.
>>>>>>
>>>>>>
>>>>>>    - Do you see this as something an AS implementation is just free to
>>>>>>    do since it's both the issuer and recipient of a refresh token?
>>>>>>
>>>>>> That's my first thought, yes.
>>>>>>    - Should this be somehow baked in the draft?
>>>>>>
>>>>>> I'm not sure. Do you think it needs to be? I'm not sure what it would
>>>>> say though.
>>>>>
>>>>> In such a case the AS could bind the RT to the given dpop proof and
>>>>> either not bind the AT while returning token_type=Bearer or bind the AT
>>>>> while returning token_type value DPoP. In the latter case the AT would
>>>>> almost certainly still work as a bearer token at the RS and the client that
>>>>> knew the RS's needs could send it as such with an `Authorization: Bearer
>>>>> `. Or if it didn't know the RS's needs, it could start with
>>>>> `Authorization: DPoP ` which would get a 401 with `WWW-Authenticate:
>>>>> Bearer` at which point it could send `Authorization: Bearer `.
>>>>>
>>>>> As I wrote the preceding rambling paragraph I am starting to think that
>>>>> more should be said in the draft about working with RSs that don't support
>>>>> DPoP. Which isn't really what you were asking about. But maybe would cover
>>>>> some of the same ground.
>>>>>
>>>>>
>>>>>
>>>>>>    - Do you think client registration metadata could be used to signal
>>>>>>    such intent?
>>>>>>
>>>>>> I think it certainly could. But it seems maybe too specific to warrant
>>>>> metadata.
>>>>>
>>>>>
>>>>>>    - Do you think the protocol should have signals in the messages
>>>>>>    themselves to say what the client wants to apply DPoP to?
>>>>>>
>>>>>> My initial thought here is no. Take the case of a client working with an
>>>>> AS that supports DPoP and one RS that does and one RS that doesn't. I can't
>>>>> really even think what signaling might look like there or how it could be
>>>>> made to be generally useful.
>>>>>
>>>>>
>>>>>>    - What if AS and RS don't have a shared support DPoP JWS Algorithm?
>>>>>>    Do we disqualify such cases or allow for sending two proofs, one for the AS
>>>>>>    to bind refresh tokens to, one for the RS to bind access tokens to?
>>>>>>
>>>>>> The AS is the one that does the binding (which includes checking the
>>>>> proof) so I don't see how sending two proofs would really work or help the
>>>>> situation?
>>>>>
>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>> review, use, distribution or disclosure by others is strictly prohibited...
>>>>> If you have received this communication in error, please notify the sender
>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>> your computer. Thank you.*
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------345E10107B63E6704B5BE915
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I agree that without a tight binding between the RS and AS we
      need to revisit RS meta-data.

    
It is a can of worms however.

    


    

    
On 4/17/2020 2:39 PM, Torsten
      Lodderstedt wrote:

    

    

      
      
I think the same is already true for mTLS. Solving
        it in an interoperable way would require some metadata about RS
        and their requirements re mTLS/DPoP. Shall we revitalize the
        idea of RS metadata?

      


        
Am 17..04.2020 um 17:37 schrieb George
          Fletcher <gffletch=40aol.com@dmarc.ietf.org>:

          

        

      

      

        

          
          This brings up interesting rollout questions. Protecting just
          the refresh_token is easy and a useful security measure
          (especially if access tokens are short lived). However, once
          you start issuing DPoP bound access tokens to a client, it
          means ALL the endpoints that client invokes MUST understand
          DPoP and know what to do with the header. Depending on how
          many endpoints that is, spread across N teams (or even
          companies) this can be problematic. 

          

          As much as I agree with Justin in regards to the security
          issues, it may not be possible to force all RPs to update at
          the same time. This is of course potentially solvable if the
          client uses unique access tokens per API endpoint AND the AS
          knows which endpoints support DPoP and which don't. The
          problem here is that this creates a tight-coupling between RP
          and AS (at least for the rollout period).

          

          
On 4/17/20 11:25 AM, Filip Skokan
            wrote:

          

          

            
I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer <jricher@mit.edu> wrote:



            

              
The idea of “Continuing to work without taking advantage of sender
constraints” is, I would argue, a security hole. Systems are allowed to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the “alg"
header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
that, but maybe we could’ve also made this more explicit within JOSE.. By
using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
says to the RS “either you know to look for this or you don’t know what it
is”.

It’s one of the problems I have with how the OAuth MTLS spec was written.
By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it — ease of porting existing deployments — was raised there as
well, and it won in the end. I hope we can do better this time.

 — Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan <panva.ip@gmail.com> wrote:

I'm still somewhat on the fence as to the pros and cons of using a new


              

                
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



              

              
If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that


              

                
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


              

              
I agree.

 The AS is the one that does the binding (which includes checking the


              

                
proof) so I don't see how sending two proofs would really work or help the
situation?


              

              
:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell <bcampbell@pingidentity.com>
wrote:



              

                
Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <panva.ip@gmail.com> wrote:



                

                  
I've wondered about the decision to use a new scheme before
<https://github.com/danielfett/draft-dpop/issues/41#issuecomment-490096716> but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.



                

                
I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?




                

                  
If at all, it is going to take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


   - Do you see this as something an AS implementation is just free to
   do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.


                

                

                  
   - Should this be somehow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would


                

                
say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=Bearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost certainly still work as a bearer token at the RS and the client that
knew the RS's needs could send it as such with an `Authorization: Bearer
<at>`. Or if it didn't know the RS's needs, it could start with
`Authorization: DPoP <at>` which would get a 401 with `WWW-Authenticate:
Bearer` at which point it could send `Authorization: Bearer <at>`.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.





                

                  
   - Do you think client registration metadata could be used to signal
   such intent?

I think it certainly could. But it seems maybe too specific to warrant


                

                
metadata.




                

                  
   - Do you think the protocol should have signals in the messages
   themselves to say what the client wants to apply DPoP to?

My initial thought here is no. Take the case of a client working with an


                

                
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.




                

                  
   - What if AS and RS don't have a shared support DPoP JWS Algorithm?
   Do we disqualify such cases or allow for sending two proofs, one for the AS
   to bind refresh tokens to, one for the RS to bind access tokens to?

The AS is the one that does the binding (which includes checking the


                

                
proof) so I don't see how sending two proofs would really work or help the
situation?


*CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly prohibited...
If you have received this communication in error, please notify the sender
immediately by e-mail and delete the message and any file attachments from
your computer. Thank you.*


              

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





            

            

            

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


          

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        

      

      

      

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


    

  


--------------345E10107B63E6704B5BE915--


From nobody Sun Apr 19 01:09:25 2020
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 C8C993A074B for ; Sun, 19 Apr 2020 01:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.211
X-Spam-Level: *
X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MISSING_HEADERS=1.207, 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 OXV6NC6guWYD for ; Sun, 19 Apr 2020 01:09:22 -0700 (PDT)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (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 EC0A93A0747 for ; Sun, 19 Apr 2020 01:09:21 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q50xjBTawnYyoQ50yjg0Y6; Sun, 19 Apr 2020 01:09:21 -0700
X-CMAE-Analysis: v=2.3 cv=d86LNirE c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=4kG_aAeuAw_d-pNtDboA:9 a=hVy5dM5bJJFa2tYy:21 a=QymQuDMcWa3YDhTZ:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=DVh3MC2FUoLFXO0QobUA:9 a=OBK4qm-CHOFXXD4I:21 a=F02Jg16fTNAJCQ-b:21 a=HKBuKgiWF3ZbqhlZ:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
Cc: oauth 
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com> 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
Date: Sun, 19 Apr 2020 11:09:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060206000806060900080801"
X-CMAE-Envelope: MS4wfNtkJvTZCkVkqBgGPvzQdFSWwohwHSsztUFLup0W400G3f6VHa6k4hiq07VQRGP1/L6r/wyf/0QxIalPo/tUfyPOvtD6JdriPxrSn2gOCpHPFMauOEZS Jl3mTIcLVtQBuJQx8V0iNYZT65TxTu6mG1i+QFOySXQU1v0T7Dg9rOvD
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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: Sun, 19 Apr 2020 08:09:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms060206000806060900080801
Content-Type: multipart/alternative;
 boundary="------------DF9457C9D0A7C0EF0D8D20E0"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------DF9457C9D0A7C0EF0D8D20E0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

In a off-list conversation Torsten floated the idea of letting
confidential PAR-only clients register without a redirect_uris and
having this "PAR only" parameter will enable that.

A "PAR only" parameter will also prevent client developers from
accidentally making plain authz requests (for clients that rely on PAR
for the extra security).

Vladimir

On 16/04/2020 18:39, Brian Campbell wrote:
>
>
> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle
>  > wrote:
>
>     As I think through this, I=E2=80=99m struggling to identify the thr=
eats
>     this actually helps mitigate.
>
>     A client metadata parameter implies that the value may be
>     different for different clients, and that any given client won=E2=80=
=99t
>     already know via other means whether or not it needs to use PAR.
>     That means we=E2=80=99re only talking about dynamic clients since
>     statically registered clients already have some proprietary
>     out-of-band registration mechanism (e.g., a developer console).
>
>
> As I tried to articulate in the original email and Filip also
> mentioned in a different fork of this email thread, defining metadata
> can be beneficial even when it's not used dynamically at runtime. So
> we're not only talking about dynamic clients.
>
> =C2=A0
>
>
>     A client metadata parameter also implies that the AS allows some
>     clients to make non-PAR requests (otherwise it would be an AS
>     metadata parameter).
>
>
> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
>
> =C2=A0
>
>     If that=E2=80=99s the case then presumably a malicious party could
>     register their own client that doesn=E2=80=99t use PAR.
>
>     So it seems to me that the only scenario that this parameter would
>     protect against is a malicious party impersonating a dynamically
>     registered client that uses PAR. That wouldn=E2=80=99t apply to Mix=
-Up,
>     since in that attack the attacker uses its own client.
>
>
> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz
> request parameters, which could be done by crafting the link and
> tricking a user into following it. I mentioned mix-up as an example
> because the first variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section=
-4.4.1
> does something along those lines.
>
> =C2=A0
>
>
>     If a client can do PAR, then it can do authorization code grant
>     and PKCE, so we=E2=80=99re further limited to scenarios where the a=
ttacker
>     does not need to be able to redeem the authorization code
>     themselves. What threats fall into this category?
>
>     =E2=80=94
>     Annabelle Backman=C2=A0(she/her)
>     AWS Identity
>
>>     On Apr 14, 2020, at 2:44 PM, Brian Campbell
>>     >     > wrote:
>>
>>     =EF=BB=BF
>>
>>     *CAUTION*: This email originated from outside of the
>>     organization. Do not click links or open attachments unless you
>>     can confirm the sender and know the content is safe.
>>
>>
>>     I was hoping to get to a rough consensus in support of the idea
>>     before coming up with a name that everyone will hate :)
>>
>>     In the meantime, however, name suggestions are of course welcome.
>>
>>
>>     On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov
>>     > wrote:
>>
>>         I'm all for that.
>>
>>         I suppose you have already thought of a suitable name? :)
>>
>>         Vladimir
>>
>>         On 14/04/2020 23:08, Brian Campbell wrote:
>>>         Using PAR can facilitate improved security by giving clients
>>>         a (relatively) simple means for sending a confidential,
>>>         integrity protected, and (for confidential clients anyway)
>>>         authenticated authorization request.
>>>
>>>         It seems like some of that improved security could be
>>>         undermined by a malicious actor somehow getting a user to
>>>         navigate to a URL of a regular old parameterized
>>>         authorization request. One variation of the Mix-Up Attack
>>>         does this
>>>         https://tools.ietf.org/html/draft-ietf-oauth-security-topics-=
15#section-4.4.1
>>>         
>>>         for example and email, social media, online forums, etc.,
>>>         are other ways a user might be tricked into following a
>>>         maliciously crafted link.=C2=A0
>>>
>>>         Following from that it seems logical that an authorization
>>>         server might want to restrict some clients from sending a
>>>         regular parameterized authorization request and instead
>>>         require use of the PAR endpoint to initiate an authorization
>>>         request. Something like this could, of course, be
>>>         implemented as custom policy or configuration in any AS. But
>>>         I'm thinking it might be common enough to warrant adding a
>>>         client metadata parameter to the PAR draft specifically for
>>>         it. The metadata (and registered extensions) defined by
>>>         Dynamic Client Registration [RFC7591] has come to imply a
>>>         general data model and expected associated behaviors for
>>>         clients that is useful for authorization server
>>>         implementations, even when the Dynamic Client Registration
>>>         Protocol isn't directly in play. This particular situation
>>>         seems like a good potential candidate for a new such client
>>>         metadata parameter that would indicate that the given client
>>>         can only use a request_uri value obtained from the PAR
>>>         endpoint to initiate an authorization request. And that a
>>>         regular old fashioned authorization request from the given
>>>         client would result in an error.
>>>
>>>         Do the folks of this fine WG think something like this would
>>>         be a worthwhile addition to the PAR draft?
>>>
>>>
>>>
>>>
>>>
>>>         /CONFIDENTIALITY NOTICE: This email may contain confidential
>>>         and privileged material for the sole use of the intended
>>>         recipient(s). Any review, use, distribution or disclosure by
>>>         others is strictly prohibited..=C2=A0 If you have received th=
is
>>>         communication in error, please notify the sender immediately
>>>         by e-mail and delete the message and any file attachments
>>>         from your computer. Thank you./
>>>
>>>         _______________________________________________
>>>         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
>>
>>
>>     /CONFIDENTIALITY NOTICE: This email may contain confidential and
>>     privileged material for the sole use of the intended
>>     recipient(s). Any review, use, distribution or disclosure by
>>     others is strictly prohibited..=C2=A0 If you have received this
>>     communication in error, please notify the sender immediately by
>>     e-mail and delete the message and any file attachments from your
>>     computer. Thank you./
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>


--------------DF9457C9D0A7C0EF0D8D20E0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
In a off-list conversation Torsten floated the idea of letting
      confidential PAR-only clients register without a redirect_uris and
      having this "PAR only" parameter will enable that.

    

    
A "PAR only" parameter will also prevent client developers from
      accidentally making plain authz requests (for clients that rely on
      PAR for the extra security).

    

    
Vladimir

    

    
On 16/04/2020 18:39, Brian Campbell
      wrote:

    

    

      
      

        


        

        

        

          
On Wed, Apr 15, 2020 at 1=
:44
            PM Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org>=
;
            wrote:

          

          

            

              
As I think through this, I=E2=80=99m strug=
gling to
                identify the threats this actually helps mitigate.

              


              

              
A client metadata parameter implies that
                the value may be different for different clients, and
                that any given client won=E2=80=99t already know via othe=
r means
                whether or not it needs to use PAR. That means we=E2=80=99=
re
                only talking about dynamic clients since statically
                registered clients already have some proprietary
                out-of-band registration mechanism (e.g., a developer
                console).
              

            

          

          


          

          
As I tried to articulate in the original email and Filip
            also mentioned in a different fork of this email thread,
            defining metadata can be beneficial even when it's not used
            dynamically at runtime. So we're not only talking about
            dynamic clients.

          


          

          
=C2=A0

          

            

              

                


                

                
A client metadata parameter also implies that the
                  AS allows some clients to make non-PAR requests
                  (otherwise it would be an AS metadata parameter).
=

              

            

          

          


          

          
A per client setting seems necessary for existing ASs to
            roll out PAR support over time or just generally in support
            of diverse client capabilities and requirements. 

          

          


          

          
=C2=A0

          

            

              

                
 If that=E2=80=99s the case then presumably a malici=
ous
                  party could register their own client that doesn=E2=80=99=
t use
                  PAR.

                


                

                
So it seems to me that the only scenario that this
                  parameter would protect against is a malicious party
                  impersonating a dynamically registered client that
                  uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since =
in that
                  attack the attacker uses its own client.

              

            

          

          


          

          
This client metadata parameter is meant to be something
            that would prevent a malicious actor from controlling the
            content of the authz request parameters, which could be done
            by crafting the link and tricking a user into following it.
            I mentioned mix-up as an example because the first variant
            of it desribed at https://tools.ietf.org/html/draft-=
ietf-oauth-security-topics-15#section-4.4.1
            does something along those lines. 

          

          


          

          
=C2=A0

          

            

              

                


                

                
If a client can do PAR, then it can do
                  authorization code grant and PKCE, so we=E2=80=99re fur=
ther
                  limited to scenarios where the attacker does not need
                  to be able to redeem the authorization code
                  themselves. What threats fall into this category?
=

                


                

                
=E2=80=94

                

                  

                    
An=
nabelle
                        Backman=C2=A0(she/her)

                    
AW=
S
                        Identity

                  

                  


                    
On Apr 14, 2020, at 2:44 PM=
,
                      Brian Campbell <bcampbell=3D40ping=
identity.com@dmarc.ietf.org>
                      wrote:

                      

                    

                  

                  

                    
=EF=BB=BF
                      

                        

                          
                            

                              
                                
CAUTION: This
                                    email originated from outside of the
                                    organization. Do not click links or
                                    open attachments unless you can
                                    confirm the sender and know the
                                    content is safe.

                              		
                            

                          
                        

                      

                      

                      

                        

                          
I was hoping to get to a rough consensus
                            in support of the idea before coming up with
                            a name that everyone will hate :)
                            

                          

                          


                          

                          
In the meantime, however, name
                            suggestions are of course welcome. 

                          

                          

                        

                        

                        

                          
On Tue, A=
pr
                            14, 2020 at 2:22 PM Vladimir Dzhuvinov <=
vladimir@connect2id.com>
                            wrote:

                          

                          

                            

                              
I'm all for that.

                              
I suppose you have already thought of a
                                suitable name? :)

                              
Vladimir

                              

                              
On 14/04/2020 23:08, Brian Campbell
                                wrote:

                              

                              

                                

                                  
Using PAR can facilitate improved
                                    security by giving clients a
                                    (relatively) simple means for
                                    sending a confidential, integrity
                                    protected, and (for confidential
                                    clients anyway) authenticated
                                    authorization request.

                                  


                                  

                                  
It seems like some of that
                                    improved security could be
                                    undermined by a malicious actor
                                    somehow getting a user to navigate
                                    to a URL of a regular old
                                    parameterized authorization request.
                                    One variation of the Mix-Up Attack
                                    does this
                                    
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
=2E4.1
                                    for example and email, social media,
                                    online forums, etc., are other ways
                                    a user might be tricked into
                                    following a maliciously crafted
                                    link.=C2=A0

                                  


                                  

                                  
Following from that it seems
                                    logical that an authorization server
                                    might want to restrict some clients
                                    from sending a regular parameterized
                                    authorization request and instead
                                    require use of the PAR endpoint to
                                    initiate an authorization request.
                                    Something like this could, of
                                    course, be implemented as custom
                                    policy or configuration in any AS.
                                    But I'm thinking it might be common
                                    enough to warrant adding a client
                                    metadata parameter to the PAR draft
                                    specifically for it. The metadata
                                    (and registered extensions) defined
                                    by Dynamic Client Registration
                                    [RFC7591] has come to imply a
                                    general data model and expected
                                    associated behaviors for clients
                                    that is useful for authorization
                                    server implementations, even when
                                    the Dynamic Client Registration
                                    Protocol isn't directly in play.
                                    This particular situation seems like
                                    a good potential candidate for a new
                                    such client metadata parameter that
                                    would indicate that the given client
                                    can only use a request_uri value
                                    obtained from the PAR endpoint to
                                    initiate an authorization request.
                                    And that a regular old fashioned
                                    authorization request from the given
                                    client would result in an error.
                                    

                                  

                                  


                                  

                                  
Do the folks of this fine WG
                                    think something like this would be a
                                    worthwhile addition to the PAR
                                    draft?

                                  

                                  


                                  

                                  


                                  

                                  


                                  

                                  


                                  

                                

                                

                                CONFIDENTIALITY=

                                      NOTICE: This email may contain
                                      confidential and privileged
                                      material for the sole use of the
                                      intended recipient(s). Any review,
                                      use, distribution or disclosure by
                                      others is strictly prohibited..=C2=A0=

                                      If you have received this
                                      communication in error, please
                                      notify the sender immediately by
                                      e-mail and delete the message and
                                      any file attachments from your
                                      computer. Thank you.<=
/i>
                                

                                

                                
____________________________________=
___________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=



                              

                              

                            

_______________________________________________

                            OAuth mailing list

                            =
OAuth@ietf.org

                            https://www.ietf.o=
rg/mailman/listinfo/oauth

                          

                        

                        

                        =
CONFIDENTIALITY NOTICE: This
                              email may contain confidential and
                              privileged material for the sole use of
                              the intended recipient(s). Any review,
                              use, distribution or disclosure by others
                              is strictly prohibited..=C2=A0 If you have
                              received this communication in error,
                              please notify the sender immediately by
                              e-mail and delete the message and any file
                              attachments from your computer. Thank you.<=
/font>

                      _____________________________________________=
__

                      OAuth mailing list

                      OAut=
h@ietf.org

                      http=
s://www.ietf.org/mailman/listinfo/oauth

                    

                  

                

              

            

          

        

      

    

    

  


--------------DF9457C9D0A7C0EF0D8D20E0--

--------------ms060206000806060900080801
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MTkwODA5MThaMC8G
CSqGSIb3DQEJBDEiBCDmO1Ph5tcyTbr1OC5OOtbm9ztxKap/K8VsBNamrpLoVTBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAIhBX08wXqktb/g+l76dLkvL+vhlns7vSXNL3jvPrYmVMkcB
OQIWJRp/4F9BmblTxejurH26S5kROVv9+7VFLpf996NejdW4m+1JHcuD6+5iD+rbyyIjuUUQ
UsR5uJfQFW+qXPjMjRvG340AM4jXLNbb2zQYbWnoV+KzNoY7bkNworrHENOvUfXtEYGfbzzx
W5vHwEYRgok8CwapOWjXNqU6cW7FjIPmY/9aOGL03tTLH3F3POLHXkghQPDk1E4OK1KuYfOM
BglqtwzYlbo1oK5WMQIo9KbGWbtmq1rJGuq+tNnujSd/+a09BIIo3h2KNz9WJgeIbQl0PCBF
XH6OqTsAAAAAAAA=
--------------ms060206000806060900080801--


From nobody Sun Apr 19 01:50:36 2020
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 D883F3A0872 for ; Sun, 19 Apr 2020 01:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.006
X-Spam-Level: 
X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 haXwRXcuEE-B for ; Sun, 19 Apr 2020 01:50:32 -0700 (PDT)
Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) (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 9E5993A0871 for ; Sun, 19 Apr 2020 01:50:32 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Q5eojAy1FmDM7Q5epjjRYy; Sun, 19 Apr 2020 01:50:32 -0700
X-CMAE-Analysis: v=2.3 cv=At2QI91P c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=hlTvbsXRcvCjb8sc_2wA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=UbviTu1ZqzJtqA0RhU8A:9 a=t2uNApSflnAsOYvg:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References:  
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: 
Date: Sun, 19 Apr 2020 11:50:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020004030307010100040706"
X-CMAE-Envelope: MS4wfGu1tKUlYy7r/uLSxINmlRzEUAIPYaMc/r9jHe+hPpwuRhObf+Eiv4lmjwfSUM3t9+Jmpvkb5iKOdgVcHHdSWwxapr8V8oVSCXsMpZaifNQViiKDMLLv gUebOGDA+hrT3KmrWzB0Sk6B1I5t3gbxfXcOd2eKq916VTvHJsgwaR9I
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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: Sun, 19 Apr 2020 08:50:34 -0000

This is a cryptographically signed message in MIME format.

--------------ms020004030307010100040706
Content-Type: multipart/alternative;
 boundary="------------205CE31E35C06B8ECECA8AAB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------205CE31E35C06B8ECECA8AAB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 16/04/2020 10:10, Dominick Baier wrote:
> *iat vs nbf*
> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99=
t most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JW=
T.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir


--------------205CE31E35C06B8ECECA8AAB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 16/04/2020 10:10, Dominick Baier
      wrote:

    

    

      
iat vs nbf

      
What=E2=80=99s the rationale for using ia=
t instead
        of nbf. Aren=E2=80=99t most JWT libraries (including e.g. the .NE=
T one)
        looking for nbf by default?

    

    
Developers often tend to intuitively pick up "iat" over "nbf"
      because it sounds more meaningful (my private observation). So
      given the empirical approach of Vittorio to the spec, I suspect
      that's how "iat" got here.

    
If we bother to carefully look at the JWT spec we'll see that
      "iat" is meant to be "informational" whereas it's "nbf" that is
      intended to serve (together with "exp") in determining the actual
      validity window of the JWT.

    
https://tools.ietf.org/html/rfc7519#section-4=
=2E1.5

    
My suggestion is to require either "iat" or "nbf". That shouldn't
      break anything, and deployments that rely on one or the other to
      determine the validity window of the access token can continue
      using their preferred claim for that.

    
Vladimir

    

  


--------------205CE31E35C06B8ECECA8AAB--

--------------ms020004030307010100040706
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MTkwODUwMzBaMC8G
CSqGSIb3DQEJBDEiBCAZZroj2+du283XQLEk1mGQllHZagqlGxLoGv9ZtnVwuzBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAKnw2CqDHAJR+dyPexILbWNLjs/kunGy1dkjMf8oEnmCHoYY
osX6roQi8bcwWjiMuchE00xhF1eQugMDitr/W4ExgD85EGgtvR5M0WSuFexwQflHid0cOBkd
alx9cut3RoZ0CgNBTQ3K7CULq22pWWXye1mpXmiMET+xKe7R09zw9uxl91E4OeSSx8auy1/7
87KLde0htiASu8/8MMEw6ZVPdsXFFuxrT4eTANF21HTKia7jCFmtx2hOxdTN2uWRYDI1XkYX
a+dK1veXP0R4s12cFLSPo0WLHdqWXJMPbtWxoutMwliJtFMeVPruECGann/PK8IqbQqsN5EQ
jwccHtkAAAAAAAA=
--------------ms020004030307010100040706--


From nobody Sun Apr 19 05:30:52 2020
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 55BD33A079D; Sun, 19 Apr 2020 05:30:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158729945010.28219.7700355069497038849@ietfa.amsl.com>
Date: Sun, 19 Apr 2020 05:30:50 -0700
Archived-At: 
Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-20 CHANGED
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: Sun, 19 Apr 2020 12:30:51 -0000

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-04-20 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).

Agenda:
1. Pushed Authorization Requests
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/

2. Rich Authorization Requests
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/



Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=ma2406d0d665d68cf51297c0544e429bf


From nobody Sun Apr 19 05:34:46 2020
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 BECBE3A07AB for ; Sun, 19 Apr 2020 05:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 6gjdU7MwHiVq for ; Sun, 19 Apr 2020 05:34:44 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 47C803A07AA for ; Sun, 19 Apr 2020 05:34:44 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id f3so7729707ioj.1 for ; Sun, 19 Apr 2020 05:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=So1xqwniw0Zev+UkmAoCgfuUl7QKg1hx3SQvBgNGIdM=; b=ADCP2i73BJuvdr1TuhwlNnBB5zZwYnQcd+/IWlbY5UNFjs+iNc1OQ64Y7Z2kqFEV3Z 6vugLTuLh/u3MRGVvYYcBkeK+mjK+/WIfJik9LmxNlpKD3UUMUKzcU9mlX0KLRdSahqL LaR9hEypuDOStdIvXeS5dNUCrE2ScwpIVvYIlq/3fJ8zF+puRPHTTM3iSaS2Zp+oIGel jZFiHqZdLN/W/quDuAWaE9stDwbHcAyCmJF06m1Hl53RjTxyC+U10N/M0V9i6notjALO 8QZMILLoB2N3Pl+bkHRnlOKDiRFml/6kw+ctzmuCPgUw3ZS+gyyypTjeWp0YsvkutP4N Ndew==
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=So1xqwniw0Zev+UkmAoCgfuUl7QKg1hx3SQvBgNGIdM=; b=Kea2RcG9kDMQdj2AJMM6KJEx2sL2Addh6XAHdJs5puoe91J/iGqGVJTZPcmQJZzOEA gBpA883buAIChFxQcTG9YXSnyqXtm892wLGR4DR89zS7s4V0vrZ2yF1X8F/accNRTods lAHYaM01KRGWZaK0NrvBX+6JpAES/ccftqW2FbA2jdCqQDOjN8d+uy70NF9Qd1jaMJr0 UPppnn7hoU6XRyvMp3bLUF8uPBsqWmDqKAiKIynpatQjzBvD1zmqV1dW80Ju29le92OI B2w1IK6Tpu/qXJD6jglL3bKwZoSHyrWEZrKOAIpwy0pKh+iDFX6vqxV7YnzMmqp9QRgJ z/sg==
X-Gm-Message-State: AGi0Puab0aDgoGzawArONWB3MaAo1kZs0vhD4bHeWv/JPTfRmy7jk1ws eZ6L4t0XS0jN8w09EhaJ/yWcnVR/i6ptQkJ16gDSg73U
X-Google-Smtp-Source: APiQypKIe3wxfjpDnYv+SMafCjx10pkDvkcxDG90Xqh4Oyn5+BipIymW6bg4rQ2mcCtWVm36Rq5v0awsDfGjcbvLCU0=
X-Received: by 2002:a02:aa93:: with SMTP id u19mr11436473jai.70.1587299683378;  Sun, 19 Apr 2020 05:34:43 -0700 (PDT)
MIME-Version: 1.0
References: <158729945010.28219.7700355069497038849@ietfa.amsl.com>
In-Reply-To: <158729945010.28219.7700355069497038849@ietfa.amsl.com>
From: Rifaat Shekh-Yusef 
Date: Sun, 19 Apr 2020 08:34:32 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000c7a78b05a3a401f5"
Archived-At: 
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-20 CHANGED
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: Sun, 19 Apr 2020 12:34:46 -0000

--000000000000c7a78b05a3a401f5
Content-Type: text/plain; charset="UTF-8"

All,

We had an issue with the time allocated for this meeting on the Webex tool,
so we fixed that.
As with previous two interim meetings, this one will too be at the same
time, *12:00pm EST*.

Regards,
 Rifaat & Hannes


On Sun, Apr 19, 2020 at 8:31 AM IESG Secretary 
wrote:

> MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.
>
> The Web Authorization Protocol (oauth) Working Group will hold
> a virtual interim meeting on 2020-04-20 from 12:00 to 13:00
> America/Toronto (16:00 to 17:00 UTC).
>
> Agenda:
> 1. Pushed Authorization Requests
> https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
>
> 2. Rich Authorization Requests
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
>
>
>
> Information about remote participation:
> https://ietf.webex.com/ietf/j.php?MTID=ma2406d0d665d68cf51297c0544e429bf
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000c7a78b05a3a401f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

We had an issue with the time allo=
cated for this meeting on the Webex tool, so we fixed that.
As wi=
th previous two interim=C2=A0meetings, this one will too be at the same tim=
e, 12:00pm EST.

Regards,
=C2=
=A0Rifaat & Hannes


On Sun, Apr 19, 2020 at 8:31 AM =
IESG Secretary <iesg-secretar=
y@ietf.org> wrote:
MEETING DETAILS HAVE CHANGED.=C2=A0 SEE LATEST DETAILS BELOW.


The Web Authorization Protocol (oauth) Working Group will hold

a virtual interim meeting on 2020-04-20 from 12:00 to 13:00 America/Toronto=
 (16:00 to 17:00 UTC).



Agenda:

1. Pushed Authorization Requests

https://datatracker.ietf.org/doc/draft-ietf-oa=
uth-par/



2. Rich Authorization Requests

https://datatracker.ietf.org/doc/draft-ietf-oa=
uth-rar/







Information about remote participation:

https://ietf.webex.com/iet=
f/j.php?MTID=3Dma2406d0d665d68cf51297c0544e429bf



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000c7a78b05a3a401f5--


From nobody Sun Apr 19 05:37:12 2020
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 8C8C23A07BF for ; Sun, 19 Apr 2020 05:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 33h0BI9EdTCX for ; Sun, 19 Apr 2020 05:37:09 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 05DC83A07BE for ; Sun, 19 Apr 2020 05:37:08 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id b18so6914043ilf.2 for ; Sun, 19 Apr 2020 05:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=mDBdsO+2F5Nl9A5sgDTwlYTUwGfTgiqYyuz/JhrbVHQ=; b=WQrFxCRhee4DYl5DQTZEnJIsTwXrDDKPgC11VtM2MfjA/X/e2JnKiPduoFujbU6dQo PTBU/DUJ2CdLpNZh7nOIqe9Hn30VdlVBfIrLhX7rdqUhdls9X2DiqHhnQ7svbwd6L1G1 P6BZp2weTn8hHZPVE8vm8+J80uxVcUEbxgRBfyIqHnEiWHKB7xM/NzUiY4JUK0J99bD0 +a6b5r/2RjmS3pOgIAPcZYP06yWWO6hJILXfg1a3FkZpKF+LYCP3N+Ceqo2z0j/WnZ6M W6IhbE/XxiwJP85R0Go3Ywz6sSBWHtKayNE57f71oY3ucWJ6zOHr0AUk3R4F0vnmYcfl IWKA==
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=mDBdsO+2F5Nl9A5sgDTwlYTUwGfTgiqYyuz/JhrbVHQ=; b=A5WV4qP2lT82UYHI7ICWk9xejJcWO7ECL5sP5HPiD9yr3tCd2HfEk5MEOqzGCNLxeF kfkJ5ArSuaHcvJyal/ilVj2gPg8EzwNoEFeOcYvvr1efEC6ufzzYLxQCC2bpTbYTN5s0 gaSfGZWvkn0PRmTMrkPidFganoTs6m+9JPFJh0TZvc7TdTy8MfPCgO9S3t/eOkIMWXbH qpWc6adJMQ32+8O/cOLxaG3lhFiDNu4ig48TcaHfsBGXhtM2kQbVMeJeEepIwQnxurFO KoqHUFX2wn7Oqc7nXjchydjdv36ASOmcR+9+S92sQBiip4bBV/IMkQcNGXoHKcoPRv5y 4fyg==
X-Gm-Message-State: AGi0PuYqW31WcNsYeX6c6H7OC/swag8mVlob29AehJtLiKbsxx9y1lfI G42acm8bPooRMhOzVQLT5Ol0yGMO+GAogyRqm7e4Foo4
X-Google-Smtp-Source: APiQypKuoCkNIpH7b4kkub5sMCEji7Bzy5brbUxiAoeTH6FGlRE9tntDzJVciK3pkfgwMIbV1rgQRyiLa84QwN7C2Xw=
X-Received: by 2002:a92:d3c5:: with SMTP id c5mr11704225ilh.73.1587299827890;  Sun, 19 Apr 2020 05:37:07 -0700 (PDT)
MIME-Version: 1.0
References: <73725170.21051581587299148230.JavaMail.nobody@rva2rmd101.webex.com>
In-Reply-To: <73725170.21051581587299148230.JavaMail.nobody@rva2rmd101.webex.com>
From: Rifaat Shekh-Yusef 
Date: Sun, 19 Apr 2020 08:36:57 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/mixed; boundary="00000000000064eb6205a3a40af5"
Archived-At: 
Subject: [OAUTH-WG] Fwd: Webex meeting changed: OAuth WG Virtual Interim Meeting - April 20th
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: Sun, 19 Apr 2020 12:37:10 -0000

--00000000000064eb6205a3a40af5
Content-Type: multipart/alternative; boundary="00000000000064eb5f05a3a40af3"

--00000000000064eb5f05a3a40af3
Content-Type: text/plain; charset="UTF-8"

---------- Forwarded message ---------
From: Web Authorization Protocol Working Group 
Date: Sun, Apr 19, 2020 at 8:25 AM
Subject: Webex meeting changed: OAuth WG Virtual Interim Meeting - April
20th
To: 




You changed the Webex meeting information.


When it's time, start your Webex meeting here.

Meeting number (access code): 610 005 584
Meeting password: PVe2mESQb23
Host key: 166805

Monday, April 20, 2020
12:00 pm  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr

Start meeting


*Join by phone*
Tap to call in from a mobile device (attendees only)
1-650-479-3208 <%2B1-650-479-3208,,*01*610005584%23%23*01*> Call-in toll
number (US/Canada)
1-877-668-4493 <1-877-668-4493,,*01*610005584%23%23*01*> Call-in toll free
number (US/Canada)
Global call-in numbers

  |  Toll-free calling restrictions


*Join from a video system or application*
Dial 610005584@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

*Join using Microsoft Lync or Microsoft Skype for Business*
Dial 610005584.ietf@lync.webex.com

Need help? Go to http://help.webex.com

--00000000000064eb5f05a3a40af3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




---------- Forwarded message ---------
From: Web Authorization Protocol Working Gro=
up <m=
essenger@webex.com>
Date: Sun, Apr 19, 2020 at 8:25 AM
=
Subject: Webex meeting changed: OAuth WG Virtual Interim Meeting - April 20=
th
To:  <oauth-chairs@ietf.o=
rg>









	
=C2=A0

	

		
		=09




        

            
				

                    You changed the Webex meeting information.
                

            		
        

        

			=C2=A0
		

        

            
				

                    When it's time, start your Webex meeting here.
                

            		
        

        

			=C2=A0
		




						

							

								
									Meeting number (access code): 610 005 584
								
							

						

						

							

								Meeting password: PVe2mESQb23
							

						

						

							

								Host key: 166805
							

						



						

							

								=C2=A0
							

							

								Monday, April 20, 2020
								
							

							

								
									12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) Eastern Time (US &=
; Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
								
							

						


 

   =20

			
=C2=A0

			
Start meeting

			
=
=C2=A0



	Tap to call in from a mobile device (attendees only)
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0=
|=C2=A0=C2=A0Toll-free calling restrictions
=C2=A0

	
Join from a video system or appli=
cation
Dial 610005584@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting nu=
mber.
=C2=A0

    
Join using Microsoft Lync or Microsoft Skype for Business
Dial 610005584.ietf@lync.webex.com


			

                
=C2=A0

				

					Need help? Go to http://help.webe=
x.com
					
				

                
=C2=A0

			

				
	






--00000000000064eb5f05a3a40af3--

--00000000000064eb6205a3a40af5
Content-Type: application/ics; name="invite.ics"
Content-Disposition: attachment; filename="invite.ics"
Content-Transfer-Encoding: base64
Content-ID: <1719270e652475802341>
X-Attachment-Id: 1719270e652475802341

QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r
IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ
TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u
ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l
d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w
NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS
TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP
RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5
NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO
RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDE5
VDEyMjU0OFoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n
IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFOk1BSUxUTzpvYXV0aC1jaGFp
cnNAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ2lzY28gV2ViZXgiOk1BSUxUTzptZXNzZW5nZXJA
d2ViZXguY29tDQpEVFNUQVJUO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDQyMFQxMjAwMDAN
CkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDQyMFQxMzAwMDANCkxPQ0FUSU9OOmh0
dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1hMjQwNmQwZDY2NWQ2OGNmNTEy
OTdjMDU0NGU0MjliZg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4NzI5OTE0OA0KVUlEOjUx
MDk5ZGRjLTAyNDctNGZmNi04ZGRlLWM2YzAzMDJiZmNkZg0KREVTQ1JJUFRJT046XG5cbkpPSU4g
V0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWEy
NDA2ZDBkNjY1ZDY4Y2Y1MTI5N2MwNTQ0ZTQyOWJmXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNv
ZGUpOiA2MTAgMDA1IDU4NFxuXG5Ib3N0IGtleTogMTY2ODA1XG5cbk1lZXRpbmcgcGFzc3dvcmQ6
IFBWZTJtRVNRYjIzXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWlu
IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVz
IG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2
MTAwMDU1ODQlMjMlMjMqMDEqXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1i
ZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9z
dHMgbm90IHN1cHBvcnRlZCk6IHRlbDoxLTg3Ny02NjgtNDQ5MywsKjAxKjYxMDAwNTU4NCUyMyUy
MyowMSpcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p
ZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tMjgzYjAyOTYzNWE3ZTA5NzE3ZTgzZTBjMWVlMzll
ZjZcblxuVG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zXG5odHRwczovL3d3dy53ZWJleC5j
b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5KT0lOIEZST00gQSBWSURFTyBT
WVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjYxMDAwNTU4NEBpZXRmLndlYmV4LmNvbVxu
WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt
YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv
ciBCdXNpbmVzc1xuRGlhbCBzaXA6NjEwMDA1NTg0LmlldGZAbHluYy53ZWJleC5jb21cblxuXG5c
bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p
ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg
dGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv
biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp
c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRp
bmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0
aGUgbWVldGluZy5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0i
dGV4dC9jc3MiPlxuKiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtc
bglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3Jk
ZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtc
bglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQt
d3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRp
dGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgt
d2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5c
bn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUg
e1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBh
dXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIg
e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50
XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0
cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZG
IiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIg
YWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48
L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBt
YXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVy
OiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUw
cHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWdu
PSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8
L3RhYmxlPi0tPlxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJ
PEZPTlQgU0laRT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGlt
ZSwgam9pbiB0aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8
L3RyPlxuCQkJCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo
dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9O
VCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChh
Y2Nlc3MgY29kZSk6IDYxMCAwMDUgNTg0PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J
CQk8L3RhYmxlPlxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQg
U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Ib3N0IGtleTogMTY2ODA1PC9G
T05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48
dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBh
c3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZB
Q0U9ImFyaWFsIj5QVmUybUVTUWIyMzwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAg
ICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0
eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHls
ZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxw
YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFp
bXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5
NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJ
CQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2
cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYTI0
MDZkMGQ2NjVkNjhjZjUxMjk3YzA1NDRlNDI5YmYiIHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250
LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5c
bgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFi
bGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+
Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB
TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo
b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjEwMDA1NTg0
JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsg
Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPjEt
NjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9O
VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi
PjxiPjxhIGhyZWY9J3RlbDoxLTg3Ny02NjgtNDQ5MywsKjAxKjYxMDAwNTU4NCUyMyUyMyowMSon
IHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5
OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTg3Ny02NjgtNDQ5
MzwvYT48L2I+IENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5i
c3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxhIGhy
ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTI4
M2IwMjk2MzVhN2UwOTcxN2U4M2UwYzFlZTM5ZWY2IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v
bmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4gbnVtYmVyczwv
YT4mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29t
L3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v
bmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJp
Y3Rpb25zPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9
ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48
L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIz
IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBv
ciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB
Q0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjEwMDA1NTg0QGlldGYud2ViZXgu
Y29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjYxMDAwNTU4
NEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xP
Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBh
bmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZu
YnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48
dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTog
MTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1c2lu
ZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwvdGQ+
PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZv
bnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkRp
YWwgPGEgaHJlZj0iIHNpcDo2MTAwMDU1ODQuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0i
dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjEwMDA1NTg0LmlldGZAbHluYy53
ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6
IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBz
dHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJ
PHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlh
bDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8g
PGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4
dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+
XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRk
PiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+
XG4NClNVTU1BUlk6T0F1dGggV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcgLSBBcHJpbCAyMHRo
DQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg==
--00000000000064eb6205a3a40af5
Content-Type: application/ics; name="Webex_Meeting.ics"
Content-Disposition: attachment; filename="Webex_Meeting.ics"
Content-Transfer-Encoding: base64
Content-ID: <1719270e652c1ce7aee2>
X-Attachment-Id: 1719270e652c1ce7aee2

QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r
IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ
TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u
ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l
d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w
NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS
TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP
RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5
NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO
RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwNDE5
VDEyMjU0OFoNCkFUVEVOREVFO0NOPSJXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n
IEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZBTFNFOk1BSUxUTzpvYXV0aC1jaGFp
cnNAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iQ2lzY28gV2ViZXgiOk1BSUxUTzptZXNzZW5nZXJA
d2ViZXguY29tDQpEVFNUQVJUO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDQyMFQxMjAwMDAN
CkRURU5EO1RaSUQ9QW1lcmljYS9OZXdfWW9yazoyMDIwMDQyMFQxMzAwMDANCkxPQ0FUSU9OOmh0
dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1hMjQwNmQwZDY2NWQ2OGNmNTEy
OTdjMDU0NGU0MjliZg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU4NzI5OTE0OA0KVUlEOjUx
MDk5ZGRjLTAyNDctNGZmNi04ZGRlLWM2YzAzMDJiZmNkZg0KREVTQ1JJUFRJT046XG5cbkpPSU4g
V0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWEy
NDA2ZDBkNjY1ZDY4Y2Y1MTI5N2MwNTQ0ZTQyOWJmXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNv
ZGUpOiA2MTAgMDA1IDU4NFxuXG5Ib3N0IGtleTogMTY2ODA1XG5cbk1lZXRpbmcgcGFzc3dvcmQ6
IFBWZTJtRVNRYjIzXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWlu
IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVz
IG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2
MTAwMDU1ODQlMjMlMjMqMDEqXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1i
ZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9z
dHMgbm90IHN1cHBvcnRlZCk6IHRlbDoxLTg3Ny02NjgtNDQ5MywsKjAxKjYxMDAwNTU4NCUyMyUy
MyowMSpcblxuR2xvYmFsIGNhbGwtaW4gbnVtYmVyc1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p
ZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tMjgzYjAyOTYzNWE3ZTA5NzE3ZTgzZTBjMWVlMzll
ZjZcblxuVG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zXG5odHRwczovL3d3dy53ZWJleC5j
b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5KT0lOIEZST00gQSBWSURFTyBT
WVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjYxMDAwNTU4NEBpZXRmLndlYmV4LmNvbVxu
WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVt
YmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZv
ciBCdXNpbmVzc1xuRGlhbCBzaXA6NjEwMDA1NTg0LmlldGZAbHluYy53ZWJleC5jb21cblxuXG5c
bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p
ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg
dGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv
biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp
c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRp
bmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0
aGUgbWVldGluZy5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0i
dGV4dC9jc3MiPlxuKiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtc
bglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3Jk
ZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtc
bglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQt
d3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRp
dGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgt
d2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5c
bn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUg
e1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBh
dXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIg
e1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50
XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0
cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZG
IiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIg
YWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48
L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBt
YXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVy
OiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUw
cHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWdu
PSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8
L3RhYmxlPi0tPlxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJ
PEZPTlQgU0laRT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGlt
ZSwgam9pbiB0aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8
L3RyPlxuCQkJCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo
dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9O
VCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChh
Y2Nlc3MgY29kZSk6IDYxMCAwMDUgNTg0PC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J
CQk8L3RhYmxlPlxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQg
U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Ib3N0IGtleTogMTY2ODA1PC9G
T05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJPHRhYmxlPjx0cj48
dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBh
c3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZB
Q0U9ImFyaWFsIj5QVmUybUVTUWIyMzwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cblxuICAgICAg
ICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0
eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHls
ZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4JCQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxw
YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFp
bXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5
NDI7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJ
CQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2
cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYTI0
MDZkMGQ2NjVkNjhjZjUxMjk3YzA1NDRlNDI5YmYiIHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250
LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5c
bgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4JCQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFi
bGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBBcmlhbDsiPjwvRk9OVD5cbjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+
Jm5ic3A7PEJSPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklB
TCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBo
b25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjEwMDA1NTg0
JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsg
Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPjEt
NjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9O
VD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi
PjxiPjxhIGhyZWY9J3RlbDoxLTg3Ny02NjgtNDQ5MywsKjAxKjYxMDAwNTU4NCUyMyUyMyowMSon
IHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5
OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTg3Ny02NjgtNDQ5
MzwvYT48L2I+IENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5i
c3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxhIGhy
ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9bTI4
M2IwMjk2MzVhN2UwOTcxN2U4M2UwYzFlZTM5ZWY2IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v
bmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4gbnVtYmVyczwv
YT4mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29t
L3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v
bmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJp
Y3Rpb25zPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9
ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48
L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIz
IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBv
ciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB
Q0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6NjEwMDA1NTg0QGlldGYud2ViZXgu
Y29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPjYxMDAwNTU4
NEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xP
Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBh
bmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZu
YnNwOyA8QlI+XG5cbjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48
dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTog
MTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1c2lu
ZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwvdGQ+
PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZv
bnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkRp
YWwgPGEgaHJlZj0iIHNpcDo2MTAwMDU1ODQuaWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0i
dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+NjEwMDA1NTg0LmlldGZAbHluYy53
ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6
IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBz
dHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJ
PHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlh
bDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8g
PGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4
dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+
XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRk
PiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+
XG4NClNVTU1BUlk6T0F1dGggV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmcgLSBBcHJpbCAyMHRo
DQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg==
--00000000000064eb6205a3a40af5--


From nobody Sun Apr 19 09:38:04 2020
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 9B7E93A0C4C for ; Sun, 19 Apr 2020 09:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 8KEUtpaLhccb for ; Sun, 19 Apr 2020 09:38:01 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 E6E7E3A0C44 for ; Sun, 19 Apr 2020 09:38:00 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id e9so570761iok.9 for ; Sun, 19 Apr 2020 09:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=BWZ9eo4DX3olcXOmDAkW6hgJbNGeuBplimAddPlIzoQ=; b=DIyb5XZ5616HTTIrhgC63wWtEgZE0RSog4b8fl7KwoBc5eF749fvU7Ow9S5LDwNvqZ T7bus0K5uS4IX10BV9S6bxC4dlDL9xxqpdfp5R0T1kWomeCq1uqTvj2Qp24ED7hwHO4f 721UVaGJTLhQliE1dRYSkiVmhKDZpSDv/NZGTeii8ZwkTHa/xY7Vw4DQlMAvml62yv2e VYeLFifZBO+GJXM/9BnTF/tLTa3loWHE0aYTpmWacCLIPoSS1DuXT4E6/PqrFaR0jCH+ 2UzCjigEuzc4bGFRXilNdHGVdEHpc5Kt1n0qVoCnjHDM5YSQxUpx9SGYIhRd+l6a7e0R K6vQ==
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=BWZ9eo4DX3olcXOmDAkW6hgJbNGeuBplimAddPlIzoQ=; b=ZIApUbpgz+1UdLMfykV6sDtkQZeSYCDYQH5HzxGGaDUrfz+BFxJdoJznn9WGPjKkDq mEBk8Pf10jFHV2Vvb8+lCIj48RBNNlQkIi0WYsxBHNIAMIYqO5lbYR9webWy/f38ubAL a727ushR7T1ntgNiuqx7Ryw+JD6u0raH+fncPt7vIR0a9HUykoPMIfJIF6Asa3CBtVeG MqmNp51mNajcbhra9jKzROc6nHSVeMu0FiUHMLLk4wjeg6m0UFwqFcoohKfM1k5YT/oo jKmv50CZu4TOiBTfdRwb4VYm0fw5lRgNTjCIStbhqKM+ZmIlYKsjfzEMz0NcupGNFW/1 fgOA==
X-Gm-Message-State: AGi0PubIOUyUp3giFx9KtMkj1Mh18WES7LwXWYQsZ8toMAVCkCFGeHNm fnx5Gw31f6KiBs2CmBcg0bOz0gCKGi99U6dVCNyQS9bIKeU=
X-Google-Smtp-Source: APiQypKSAgRAJAk/E0mCMnURUzkZV/DV8jHCa61KIFsVBxnnQR5HPyviarKlZm51uw0mrWdOgDUW6MNQQgV668/p+4k=
X-Received: by 2002:a02:cb8a:: with SMTP id u10mr12129606jap.73.1587314279951;  Sun, 19 Apr 2020 09:37:59 -0700 (PDT)
MIME-Version: 1.0
References: <73725170.21051581587299148230.JavaMail.nobody@rva2rmd101.webex.com> 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Sun, 19 Apr 2020 12:37:49 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000cdb17405a3a767c5"
Archived-At: 
Subject: Re: [OAUTH-WG] Webex meeting changed: OAuth WG Virtual Interim Meeting - April 20th
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: Sun, 19 Apr 2020 16:38:03 -0000

--000000000000cdb17405a3a767c5
Content-Type: text/plain; charset="UTF-8"

All,

You can find this meeting material at the following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-05/session/oauth

Regards,
 Rifaat & Hannes


On Sun, Apr 19, 2020 at 8:36 AM Rifaat Shekh-Yusef 
wrote:

>
>
> ---------- Forwarded message ---------
> From: Web Authorization Protocol Working Group 
> Date: Sun, Apr 19, 2020 at 8:25 AM
> Subject: Webex meeting changed: OAuth WG Virtual Interim Meeting - April
> 20th
> To: 
>
>
>
>
> You changed the Webex meeting information.
>
>
> When it's time, start your Webex meeting here.
>
> Meeting number (access code): 610 005 584
> Meeting password: PVe2mESQb23
> Host key: 166805
>
> Monday, April 20, 2020
> 12:00 pm  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr
>
> Start meeting
> 
>
> *Join by phone*
> Tap to call in from a mobile device (attendees only)
> 1-650-479-3208 <%2B1-650-479-3208,,*01*610005584%23%23*01*> Call-in toll
> number (US/Canada)
> 1-877-668-4493 <1-877-668-4493,,*01*610005584%23%23*01*> Call-in toll
> free number (US/Canada)
> Global call-in numbers
> 
>   |  Toll-free calling restrictions
> 
>
> *Join from a video system or application*
> Dial 610005584@ietf.webex.com
> You can also dial 173.243.2.68 and enter your meeting number.
>
> *Join using Microsoft Lync or Microsoft Skype for Business*
> Dial 610005584.ietf@lync.webex.com
>
> Need help? Go to http://help.webex.com
>
>

--000000000000cdb17405a3a767c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find this meeting material=
 at the following link:

Regards,
=C2=A0Rifaat & Hannes
=C2=A0

On=
 Sun, Apr 19, 2020 at 8:36 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:


---------- Forwarded=
 message ---------
From: Web Authorization Protocol Working Group <<=
a href=3D"mailto:messenger@webex.com" target=3D"_blank">messenger@webex.com=
>
Date: Sun, Apr 19, 2020 at 8:25 AM
Subject: Webex mee=
ting changed: OAuth WG Virtual Interim Meeting - April 20th
To:  <oauth-chairs@ietf.o=
rg>









	
=C2=A0

	

		
		=09




        

            
				

                    You changed the Webex meeting information.
                

            		
        

        

			=C2=A0
		

        

            
				

                    When it's time, start your Webex meeting here.
                

            		
        

        

			=C2=A0
		




						

							

								
									Meeting number (access code): 610 005 584
								
							

						

						

							

								Meeting password: PVe2mESQb23
							

						

						

							

								Host key: 166805
							

						



						

							

								=C2=A0
							

							

								Monday, April 20, 2020
								
							

							

								
									12:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) Eastern Time (US &=
; Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
								
							

						


 

   =20

			
=C2=A0

			
Start meeting

			
=
=C2=A0



	=

Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-32=
08=C2=A0Call-in toll number (US/Can=
ada)
1-877-668-4493=C2=A0Call-in t=
oll free number (US/Canada)
Global call-in numbers=C2=A0=C2=A0|=C2=A0=C2=A0Toll-fre=
e calling restrictions
=C2=A0

	=

Join from a video system or ap=
plication
Dial 610005584@ietf.webex.com
You can also dial 173.243.2.68 and e=
nter your meeting number.
=C2=A0

    
=
=

Join using Microsoft Lync or Microsoft Skype for Business
Dial 610005584.ietf@lync.webex.com


			

                
=C2=A0

				

					Need help? Go to http:/=
/help.webex.com
					
				

                
=C2=A0

			

				
	








--000000000000cdb17405a3a767c5--


From nobody Sun Apr 19 11:30:27 2020
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 DED073A0F1C; Sun, 19 Apr 2020 11:30:22 -0700 (PDT)
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: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158732102285.31467.551848692555230905@ietfa.amsl.com>
Date: Sun, 19 Apr 2020 11:30:22 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.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: Sun, 19 Apr 2020 18:30: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           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-21.txt
	Pages           : 31
	Date            : 2020-04-19

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21


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 Sun Apr 19 21:59:38 2020
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 C87223A0F93 for ; Sun, 19 Apr 2020 21:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, UNPARSEABLE_RELAY=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=alkaline-solutions.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 susdGsoJWWUc for ; Sun, 19 Apr 2020 21:59:35 -0700 (PDT)
Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464CC3A0F91 for ; Sun, 19 Apr 2020 21:59:35 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 7F0DA3856D5; Mon, 20 Apr 2020 04:59:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1587358773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xMwDunGbKN5Gc7Y9830OnyQmN5nT0j9yXt4nAnwuYe8=; b=UKgTtZnT218N3bRH8SGtCVAWcT9SclAxsQMvULv4scyY/Z2eIGxJDoQppo51a6YqrDwHMN hpQyjgrrWDz9PiKwHfm0DfrhYetDTXd6iL9CkcKjAdPSrjhdi3WLqqwTn/kFqFR13ruaey 6MpKbHZjU6wNJFB1cfbbUsbDBFv/T0g=
From: David Waite 
Message-Id: <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A999A5BC-6FCC-4243-9D9B-275A592E050A"
Mime-Version: 1.0
Date: Sun, 19 Apr 2020 22:59:31 -0600
In-Reply-To: 
Cc: oauth@ietf.org
To: Vladimir Dzhuvinov 
References:   
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1587358774; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xMwDunGbKN5Gc7Y9830OnyQmN5nT0j9yXt4nAnwuYe8=; b=Qg2QxE2K5UJrD+DxPc5oPaDgqykfWeXh1gIbdU/6+J5sVvEwyx2BqAnBb31YEZHjQPTXVD cq8lawqJePqgrXSC2I49OL4mhp+MRjGu/9o0fZMTvdYIic7se9BUXXnvid8PnYBPDx3NTu RuyKzcrlWgyJsFiANspxlfG0tKlG4eI=
ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1587358774; a=rsa-sha256; cv=none; b=cus0FxJsPMsW1Q29IfPlnqK5PcEyzHcp5z5IHgng/V7ttIOM65m/7B1sU38d/4f21kmr8f Eb3U5mKlfItMnHssJvQw7Qqt7ijwuiKHHht2kfdql2ExiU0bS/RR7INKJx40Q1CUHCFRRU +iy1lY1znrEtTOLkP17PrMZS3ZbXyF8=
ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 04:59:37 -0000

--Apple-Mail=_A999A5BC-6FCC-4243-9D9B-275A592E050A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

There are a number of ambiguities and statements around using JWTs in =
various contexts:

1. Some implementations interpret =E2=80=9Ciat" to also have the meaning =
of =E2=80=9Cnbf=E2=80=9D in the absence of =E2=80=9Cnbf=E2=80=9D, =
although this is AFAIK not prescribed by any spec
2. The DPoP draft=E2=80=99s client-generated tokens have the resource =
servers use their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, =
since the tokens are meant for immediate one time use by a party that =
may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS =
may reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past =
or =E2=80=9Cexp=E2=80=9D too far in the future, but not that =E2=80=9Cnbf=E2=
=80=9D was too far in the past or that the interval between nbf and exp =
was too large.

The JWT spec also allows implementers to provide some leeway for clock =
skew. Presumably this meant validators and not JWT creators, although =
there is history of messages setting similar values to account for clock =
skew (e.g. SAML IDPs setting notBefore to one minute before issuance and =
notOnOrAfter 5 minutes after issuance).=20

-DW

> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov =
 wrote:
>=20
> On 16/04/2020 10:10, Dominick Baier wrote:
>> iat vs nbf
>> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99=
t most JWT libraries (including e.g. the .NET one) looking for nbf by =
default?
> Developers often tend to intuitively pick up "iat" over "nbf" because =
it sounds more meaningful (my private observation). So given the =
empirical approach of Vittorio to the spec, I suspect that's how "iat" =
got here.
>=20
> If we bother to carefully look at the JWT spec we'll see that "iat" is =
meant to be "informational" whereas it's "nbf" that is intended to serve =
(together with "exp") in determining the actual validity window of the =
JWT.
>=20
> https://tools.ietf.org/html/rfc7519#section-4.1.5 =

> My suggestion is to require either "iat" or "nbf". That shouldn't =
break anything, and deployments that rely on one or the other to =
determine the validity window of the access token can continue using =
their preferred claim for that.
>=20
> Vladimir
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A999A5BC-6FCC-4243-9D9B-275A592E050A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

There=
 are a number of ambiguities and statements around using JWTs in various =
contexts:

1. Some =
implementations interpret =E2=80=9Ciat" to also have the meaning of =
=E2=80=9Cnbf=E2=80=9D in the absence of =E2=80=9Cnbf=E2=80=9D, although =
this is AFAIK not prescribed by any spec
2. The =
DPoP draft=E2=80=99s client-generated tokens have the resource servers =
use their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, since the =
tokens are meant for immediate one time use by a party that may not have =
clock synchronization.
3. There are recommendations =
in the JWT profile for OAuth that the AS may reject tokens based on an =
=E2=80=9Ciat=E2=80=9D too far in the past or =E2=80=9Cexp=E2=80=9D too =
far in the future, but not that =E2=80=9Cnbf=E2=80=9D was too far in the =
past or that the interval between nbf and exp was too large.

The JWT spec also allows =
implementers to provide some leeway for clock skew. Presumably this =
meant validators and not JWT creators, although there is history of =
messages setting similar values to account for clock skew (e.g. SAML =
IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 =
minutes after issuance). 

-DW

On Apr =
19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  

    
On 16/04/2020 10:10, Dominick Baier
      wrote:

    

    

      
iat vs =
nbf

      
What=E2=80=99s the rationale =
for using iat instead
        of nbf. Aren=E2=80=99t most JWT libraries (including e.g. the =
.NET one)
        looking for nbf by default?

    
Developers often tend to intuitively pick =
up "iat" over "nbf"
      because it sounds more meaningful (my private observation). So
      given the empirical approach of Vittorio to the spec, I suspect
      that's how "iat" got here.
If we bother to =
carefully look at the JWT spec we'll see that
      "iat" is meant to be "informational" whereas it's "nbf" that is
      intended to serve (together with "exp") in determining the actual
      validity window of the JWT.
https://tools.i=
etf.org/html/rfc7519#section-4.1.5
My suggestion is =
to require either "iat" or "nbf". That shouldn't
      break anything, and deployments that rely on one or the other to
      determine the validity window of the access token can continue
      using their preferred claim for that.
Vladimir

    

  


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

=

--Apple-Mail=_A999A5BC-6FCC-4243-9D9B-275A592E050A--


From nobody Sun Apr 19 23:12:21 2020
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 CF2E03A10E8 for ; Sun, 19 Apr 2020 23:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level: 
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 kotv6B00KukU for ; Sun, 19 Apr 2020 23:12:18 -0700 (PDT)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (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 26CFC3A10E5 for ; Sun, 19 Apr 2020 23:12:18 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id QPfDjbgT2b7cvQPfEjuqOQ; Sun, 19 Apr 2020 23:12:16 -0700
X-CMAE-Analysis: v=2.3 cv=O4lHQy1W c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=MXzmhXZ1gubhqf1ePBcA:9 a=QEXdDO2ut3YA:10 a=jGqiy6jZAAAA:8 a=c-ntgTk_fXaBXHuSi90A:9 a=ZqLJkzxFk54mY-CO:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=jHrLhlbFqA1ZHZAWynec:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <158732102285.31467.551848692555230905@ietfa.amsl.com>
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: 
Date: Mon, 20 Apr 2020 09:12:14 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <158732102285.31467.551848692555230905@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030808050702040103010200"
X-CMAE-Envelope: MS4wfCwjAnT8ms7ri5Ii4mUuKOMHCMBfSjsYH5hsTMUIXyh+BKLOUUyrMaBL2kKp9vz+OoaTNsPNEzC0pHglNCfDSoRDhe1hJPo+nG5+eqtLoKEaF+Ta42AM d0iycu8KbOPQX5alD1LQCTZcWC+4KYWqc8Cg+UE6V6RbqUwqTwaGZhTi
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.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: Mon, 20 Apr 2020 06:12:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms030808050702040103010200
Content-Type: multipart/alternative;
 boundary="------------3060463387EDBC6AEA8FB753"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------3060463387EDBC6AEA8FB753
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Nat, John, thanks for updating the JAR spec. I just reviewed it, in
particular the authz request and the security considerations sections.
Choosing to make client_id (as top-level parameter) mandatory for all
cases, even for those when it can be readily extracted from the JWT,
makes the job of implementers even easier.


I have just one comment about the last paragraph in section 5, assuming
backward compatibility means with RFC6749 requests. Here is my proposed
wording:

The client MAY send the parameters included in the request object=20
duplicated in the query parameters. For instance, this can be done=20
to ensure the minimal required query parameters for an OAuth 2.0=20
[RFC6749] authorization request are also present. An authorization=20
server supporting this specification MUST however only use the=20
parameters included in the request object.


Vladimir


On 19/04/2020 21:30, 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           : The OAuth 2.0 Authorization Framework: JWT Se=
cured Authorization Request (JAR)
>         Authors         : Nat Sakimura
>                           John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-21.txt
> 	Pages           : 31
> 	Date            : 2020-04-19
>
> Abstract:
>    The authorization request in OAuth 2.0 described in RFC 6749 utilize=
s
>    query parameter serialization, which means that Authorization Reques=
t
>    parameters are encoded in the URI of the request and sent through
>    user agents such as web browsers.  While it is easy to implement, it=

>    means that (a) the communication through the user agents are not
>    integrity protected and thus the parameters can be tainted, and (b)
>    the source of the communication is not authenticated.  Because of
>    these weaknesses, several attacks to the protocol have now been put
>    forward.
>
>    This document introduces the ability to send request parameters in a=

>    JSON Web Token (JWT) instead, which allows the request to be signed
>    with JSON Web Signature (JWS) and encrypted with JSON Web Encryption=

>    (JWE) so that the integrity, source authentication and
>    confidentiality property of the Authorization Request is attained.
>    The request can be sent by value or by reference.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-21
>
>
> 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/
>


--------------3060463387EDBC6AEA8FB753
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Nat, John, thanks for updating the JAR spec. I just reviewed it,
      in particular the authz request and the security considerations
      sections. Choosing to make client_id (as top-level parameter)
      mandatory for all cases, even for those when it can be readily
      extracted from the JWT, makes the job of implementers even easier.<=
/p>
    


    

    
I have just one comment about the last paragraph in section 5,
      assuming backward compatibility means with RFC6749 requests. Here
      is my proposed wording:

    
The client MAY send the parameters included in=
 the request object=20
duplicated in the query parameters. For instance, this can be done=20
to ensure the minimal required query parameters for an OAuth 2.0=20
[RFC6749] authorization request are also present. An authorization=20
server supporting this specification MUST however only use the=20
parameters included in the request object.

    


    

    
Vladimir

    

    


    

    
On 19/04/2020 21:30,
      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           : The OAuth 2.0 Authorization Framework: JWT Secu=
red Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-21.txt
	Pages           : 31
	Date            : 2020-04-19

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-=
oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jw=
sreq-21
https://datatracker.ietf.org/doc/html=
/draft-ietf-oauth-jwsreq-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-oauth-jwsreq-21


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/



    

    

  


--------------3060463387EDBC6AEA8FB753--

--------------ms030808050702040103010200
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MjAwNjEyMTRaMC8G
CSqGSIb3DQEJBDEiBCCFQCGDp/mMNToVsZhSYuNNqqhnMRwev8APBNdKBwHDzDBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAEiOkh0CgVA5Qb7xD9BSphZSUNAlOOijLc1JA21hr7AZCtvM
dG0JbmK03cZOGpZ7rf4K82Z8rKNg1SP4d/l7qWnx50YGGrS9RpejZ3twk/o36SVfvclXoZVO
T5xyFkL59VZUnLcWbPjxNKpJICkDmIOejVVIBmftIY2hAM9K9QWljTdSU8yDcNLfWRSU7Gw/
NR5oRvpobJWSxW+CD6ymAqFB+dpzhEkHzs/J+peVFhEMGPpQ+2ZcGL7I2ueR6Xlpqn8nOdIs
q4vOaIxwBUIvBseP9+zdlaZjf4JxrQ9qtJqDc1v/wkfVJe0sKrXEtf3NBRZR9Eka2Ywll7jg
See0AtwAAAAAAAA=
--------------ms030808050702040103010200--


From nobody Sun Apr 19 23:52:28 2020
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 713663A1281 for ; Sun, 19 Apr 2020 23:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level: 
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBhjhKKY9phT for ; Sun, 19 Apr 2020 23:52:10 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 C769A3A1282 for ; Sun, 19 Apr 2020 23:50:39 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id w24so7598435qts.11 for ; Sun, 19 Apr 2020 23:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=WP+sEblzVrP/Ar5G1r3kd70m2iHGuEDJyGGj+MZ7gHI=; b=0S/G/A29RVjT78l5F2lQPN3NSBQeaICuweESSOeQvV9ToPyhggY6XOPF3gKCAc3l9r Iu29q+NupVRQQ1UptBRanJg5kRKHlOpC8GOD9OscHDNZ6exVEKq6W3AUfrPMOFfpDkKT Wq1JRp1axZ3NN/c2RP8Osl4I+m5spzm7DxqrXHSVXXUoIo/AxJ8kymMBU3lhCNO7zdJO 303ExivqmLH/EMMwzy/xYlYoLIl309FCxXJvyvNTVwEB+iqMX+gvqwjOm5X5q/s/SDmO c5Xzpd49j3WNveYnrOou7lrjZaX+h71UzFJr4bD/CX/hHpNFcrWCWt9B1lnfKaP3MhBr lKrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=WP+sEblzVrP/Ar5G1r3kd70m2iHGuEDJyGGj+MZ7gHI=; b=ofrcwEoEw1ugE+scKIcmGtVCvlvgYL/vfD2HdEyCw+BsDTzsaCF6Fcpri+sEHGkK3L L2EZ7xS7g4EbfKKJyCkknF/3+x7C9Aj+zzZrfbMk9Es7fGAAPZvM9DkKX7Dcw2Udbo8Z 1LhtL5DJieSF+mgF5/k8ZOg3Pqc8QuXYI98ZScpAF4j+Uok9eV8MDePemM7KVMTFhoVh b7rSk4uD36tS4x5KqQD/e2CZH/ZT5Q7W5z4pemkczFYpPoY6l4iiLAM96MI9l8ZlVhCe YAp4A+jZhtyuug2h8dK7jZNT3hmRdnPkFz4JU452MmVdx6KcsqWmStU6eqbFByMTVGqF Vxlg==
X-Gm-Message-State: AGi0Pua5AGTzDzu2qt1xnYnIolEjGlNBpgGGyIUKVG78glgSemtEwOWi KbAuU72o33o8/FZArOTtdedYEopKF3Wy/VOr2CaTJ1s=
X-Google-Smtp-Source: APiQypJU33V4jpXINOC4FlqXF7i62meU1crUNjs54Zo0zTtFmef5KdPfxPeDCEp4b/KE2NkuH0uDbK/BwvXFIH7IJWw=
X-Received: by 2002:ac8:17c7:: with SMTP id r7mr14267421qtk.356.1587365427896;  Sun, 19 Apr 2020 23:50:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 02:50:27 -0400
From: Dominick Baier 
In-Reply-To: <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
References:    <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
MIME-Version: 1.0
Date: Mon, 20 Apr 2020 02:50:27 -0400
Message-ID: 
To: David Waite ,  Vladimir Dzhuvinov 
Cc: oauth@ietf.org, Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="00000000000075750705a3b350c5"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 06:52:26 -0000

--00000000000075750705a3b350c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what=E2=80=99s the difference between the two
practically speaking - and shouldn=E2=80=99t be the more common (aka suppor=
ted by
most libraries) be used?

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=3D40alkaline-solutions.com@dmarc.ietf.org) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret =E2=80=9Ciat" to also have the meaning of=
 =E2=80=9Cnbf=E2=80=9D
in the absence of =E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescri=
bed by any spec
2. The DPoP draft=E2=80=99s client-generated tokens have the resource serve=
rs use
their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, since the tokens=
 are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past or =E2=
=80=9Cexp=E2=80=9D too far in the
future, but not that =E2=80=9Cnbf=E2=80=9D was too far in the past or that =
the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov 
wrote:

On 16/04/2020 10:10, Dominick Baier wrote:

*iat vs nbf*
What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t m=
ost JWT
libraries (including e.g. the ..NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir
_______________________________________________
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

--00000000000075750705a3b350c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Just=
 a quick data point -=C2=A0

The Microsoft .NET JWT implementation checks for exp and nbf. Not =
iat.

I guess my rea=
l question is - what=E2=80=99s the difference between the two practically s=
peaking - and shouldn=E2=80=99t be the more common (aka supported by most l=
ibraries) be used?
 

 
=E2=
=80=94=E2=80=94=E2=80=94
Dominick Baier
 
On 20. April 2020 at 06:59:47, David Waite (david=3D40alkaline-solutions.c=
om@dmarc.ietf.org) wrote:
 
There are a number of ambiguities=
 and statements around using JWTs in various contexts:

1. Some implementations interpret =E2=80=9C=
iat" to also have the meaning of =E2=80=9Cnbf=E2=80=9D in the absence =
of =E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescribed by any spec=

2. The DPoP draft=E2=80=99s client-generated tokens h=
ave the resource servers use their own nbf/exp heuristics around =E2=80=9Ci=
at=E2=80=9D, since the tokens are meant for immediate one time use by a par=
ty that may not have clock synchronization.
3. There a=
re recommendations in the JWT profile for OAuth that the AS may reject toke=
ns based on an =E2=80=9Ciat=E2=80=9D too far in the past or =E2=80=9Cexp=E2=
=80=9D too far in the future, but not that =E2=80=9Cnbf=E2=80=9D was too fa=
r in the past or that the interval between nbf and exp was too large.
=


The JWT spec also allo=
ws implementers to provide some leeway for clock skew. Presumably this mean=
t validators and not JWT creators, although there is history of messages se=
tting similar values to account for clock skew (e.g. SAML IDPs setting notB=
efore to one minute before issuance and notOnOrAfter 5 minutes after issuan=
ce).=C2=A0

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wr=
ote:


  =20
    =20
  =20
  

    
On 16/04/2020 10:10, Dominick Baier
      wrote:

    

    

      
iat vs nbf
      
What=E2=80=99s the rationale for=
 using iat instead
        of nbf. Aren=E2=80=99t most JWT libraries (including e.g. the ..NET=
 one)
        looking for nbf by default?

    
Developers often tend to intuitively pick up=
 "iat" over "nbf"
      because it sounds more meaningful (my private observation). So
      given the empirical approach of Vittorio to the spec, I suspect
      that's how "iat" got here.
If we bothe=
r to carefully look at the JWT spec we'll see that
      "iat" is meant to be "informational" whereas it&#=
39;s "nbf" that is
      intended to serve (together with "exp") in determining the =
actual
      validity window of the JWT.
https=
://tools.ietf.org/html/rfc7519#section-4.1.5
My sugges=
tion is to require either "iat" or "nbf". That shouldn&=
#39;t
      break anything, and deployments that rely on one or the other to
      determine the validity window of the access token can continue
      using their preferred claim for that.
Vladimir

    

  


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

______________________________________=
_________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--00000000000075750705a3b350c5--


From nobody Mon Apr 20 00:06:14 2020
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 F139C3A12D7 for ; Mon, 20 Apr 2020 00:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.178
X-Spam-Level: 
X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=WWKNxwiM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SVR3zncf
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 8fZqhbgD7xZD for ; Mon, 20 Apr 2020 00:05:59 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E57D3A12DB for ; Mon, 20 Apr 2020 00:05:59 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2E38E5A2; Mon, 20 Apr 2020 03:05:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 20 Apr 2020 03:05:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=Ca7ZBxXA3UeWq8MQMgTJJELitYV+RNliuopMF0opXBE=; b=WWKNxwiMyCfs ZVeiEE5ZJOVSkMPgGYfpKnhSc+tALasPInQVHCE0bNtLKckpOJoMd0+1I+VRZTd9 pRGoWfcJHh6Pl5rYtl5U95FuovIa98+phrs5/qYuOD6S2QEX3FSPC+ajtuLWUHi9 8cQHf0D/rZbCDY+pOdAglhGmA3jlYF6AzNR5Nd7PazFugTJ3oxZSOGYtx2/JSkUy pSeauWnY2m+8m/D2dQ4TL9URFfyQ1Q/Gv1cqEEQYWt5iC+Yj1na1LdI/zU4NJLYn be07s7CVx6jg0xcv2KlgQfQc/jiqAZwx79LUClJCtvfPa7Oh90uOEVc5TsitM9WY M7DMViSEKA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ca7ZBx XA3UeWq8MQMgTJJELitYV+RNliuopMF0opXBE=; b=SVR3zncfAkbfsxtllDEVPT 68JepZ1EvsyBEPKjPs8JH6INYEmbo9+1DdFg6Vw5236NlOHUi5N+8Qfb7aycmVwE 7EJTM5IxcUeTHGa9b3Q3wmBHIwDUMZdhSaqF6Xy2Z1GI3KsXMSVvEJxqBsCom9FF /BpzcO5C7m4Nq5rUa91ZzMY2xM7drYquBSH9iOp1ARUwciQQ7Cs7bqC+KXuzmm/6 cKnGLBZ6DB6+4zu3vrhrWdpwegMczFxdR2EinNj93imGf4QRxQjIo59KiMxOJqQz sTbPBnSkArByTmBiwa8achfYxSynY8kOxr0ePqNW+c2IuJN8evKHmOqwFyiH9LUA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhi phhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggssh gvtghurhhithihrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeel gedrvddvhedrhedrudeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhi thihrdgtohhm
X-ME-Proxy:    
Received: from philippes-imac.localdomain (94-225-5-162.access.telenet.be [94.225.5.162]) by mail.messagingengine.com (Postfix) with ESMTPA id B69833065BF7; Mon, 20 Apr 2020 03:05:49 -0400 (EDT)
From: Philippe De Ryck 
Message-Id: <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BE79931-791A-470C-86ED-99F72534470D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Mon, 20 Apr 2020 09:05:48 +0200
In-Reply-To: 
Cc: David Waite , Vladimir Dzhuvinov , Vittorio Bertocci , oauth@ietf.org
To: Dominick Baier 
References:    <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com> 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 07:06:13 -0000

--Apple-Mail=_6BE79931-791A-470C-86ED-99F72534470D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In theory, you can issue a token that only becomes valid in the future. =
That would have a different iat and nbf timestamp. I have not seen this =
in practice though.=20

Given that RFC 7519 lists =E2=80=9Ciat=E2=80=9D as informative, I would =
not change that behavior in a specific use case if there is no =
significant need to do so.

Philippe

> On 20 Apr 2020, at 08:50, Dominick Baier  =
wrote:
>=20
> Just a quick data point -=20
>=20
> The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.
>=20
> I guess my real question is - what=E2=80=99s the difference between =
the two practically speaking - and shouldn=E2=80=99t be the more common =
(aka supported by most libraries) be used?
>=20
> =E2=80=94=E2=80=94=E2=80=94
> Dominick Baier
>=20
> On 20. April 2020 at 06:59:47, David Waite =
(david=3D40alkaline-solutions.com@dmarc.ietf.org =
) wrote:
>=20
>> There are a number of ambiguities and statements around using JWTs in =
various contexts:
>>=20
>> 1. Some implementations interpret =E2=80=9Ciat" to also have the =
meaning of =E2=80=9Cnbf=E2=80=9D in the absence of =E2=80=9Cnbf=E2=80=9D, =
although this is AFAIK not prescribed by any spec
>> 2. The DPoP draft=E2=80=99s client-generated tokens have the resource =
servers use their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, =
since the tokens are meant for immediate one time use by a party that =
may not have clock synchronization.
>> 3. There are recommendations in the JWT profile for OAuth that the AS =
may reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past =
or =E2=80=9Cexp=E2=80=9D too far in the future, but not that =E2=80=9Cnbf=E2=
=80=9D was too far in the past or that the interval between nbf and exp =
was too large.
>>=20
>> The JWT spec also allows implementers to provide some leeway for =
clock skew. Presumably this meant validators and not JWT creators, =
although there is history of messages setting similar values to account =
for clock skew (e.g. SAML IDPs setting notBefore to one minute before =
issuance and notOnOrAfter 5 minutes after issuance).=20
>>=20
>> -DW
>>=20
>>> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov =
> wrote:
>>>=20
>>> On 16/04/2020 10:10, Dominick Baier wrote:
>>>> iat vs nbf
>>>> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=
=99t most JWT libraries (including e.g. the ..NET one) looking for nbf =
by default?
>>> Developers often tend to intuitively pick up "iat" over "nbf" =
because it sounds more meaningful (my private observation). So given the =
empirical approach of Vittorio to the spec, I suspect that's how "iat" =
got here.
>>>=20
>>> If we bother to carefully look at the JWT spec we'll see that "iat" =
is meant to be "informational" whereas it's "nbf" that is intended to =
serve (together with "exp") in determining the actual validity window of =
the JWT.
>>>=20
>>> https://tools.ietf.org/html/rfc7519#section-4.1.5 =

>>> My suggestion is to require either "iat" or "nbf". That shouldn't =
break anything, and deployments that rely on one or the other to =
determine the validity window of the access token can continue using =
their preferred claim for that.
>>>=20
>>> Vladimir
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf..org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_6BE79931-791A-470C-86ED-99F72534470D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In =
theory, you can issue a token that only becomes valid in the future. =
That would have a different iat and nbf timestamp. I have not seen this =
in practice though. 

Given that RFC 7519 lists =E2=80=9Ciat=E2=80=9D as =
informative, I would not change that behavior in a specific use case if =
there is no significant need to do so.

Philippe

On 20 =
Apr 2020, at 08:50, Dominick Baier <dbaier@leastprivilege.com> wrote:

Just a quick data point - 

The Microsoft .NET JWT implementation =
checks for exp and nbf. Not iat.

I guess my real question is - what=E2=80=99s the =
difference between the two practically speaking - and shouldn=E2=80=99t =
be the more common (aka supported by most libraries) be used?

=E2=80=94=E2=80=94=E2=80=94
Dominick =
Baier

On 20. April 2020 at 06:59:47, David Waite (david=3D40alkaline-solutions.com@dmarc.ietf.org) =
wrote:
There are a number of ambiguities and =
statements around using JWTs in various contexts:

1. Some implementations interpret =
=E2=80=9Ciat" to also have the meaning of =E2=80=9Cnbf=E2=80=9D in the =
absence of =E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescribed =
by any spec
2. The DPoP draft=E2=80=99s =
client-generated tokens have the resource servers use their own nbf/exp =
heuristics around =E2=80=9Ciat=E2=80=9D, since the tokens are meant for =
immediate one time use by a party that may not have clock =
synchronization.
3. There are recommendations in =
the JWT profile for OAuth that the AS may reject tokens based on an =
=E2=80=9Ciat=E2=80=9D too far in the past or =E2=80=9Cexp=E2=80=9D too =
far in the future, but not that =E2=80=9Cnbf=E2=80=9D was too far in the =
past or that the interval between nbf and exp was too large.

The JWT spec also allows =
implementers to provide some leeway for clock skew. Presumably this =
meant validators and not JWT creators, although there is history of =
messages setting similar values to account for clock skew (e.g. SAML =
IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 =
minutes after issuance). 

-DW

On Apr =
19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

On 16/04/2020 10:10, Dominick Baier wrote:
iat=
 vs nbf
What=E2=80=99s =
the rationale for using iat instead of nbf. Aren=E2=80=99t most JWT =
libraries (including e.g. the ..NET one) looking for nbf by =
default?
Developers often tend to =
intuitively pick up "iat" over "nbf" because it sounds more meaningful =
(my private observation). So given the empirical approach of Vittorio to =
the spec, I suspect that's how "iat" got here.
If we =
bother to carefully look at the JWT spec we'll see that "iat" is meant =
to be "informational" whereas it's "nbf" that is intended to serve =
(together with "exp") in determining the actual validity window of the =
JWT.
https://tools.i=
etf.org/html/rfc7519#section-4.1.5
My suggestion is =
to require either "iat" or "nbf". That shouldn't break anything, and =
deployments that rely on one or the other to determine the validity =
window of the access token can continue using their preferred claim for =
that.
Vladimir
_______________________________________________
OAuth mailing list
OAuth@ietf..org
https://www.ietf.org/mailman/listinfo/oauth

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

=

--Apple-Mail=_6BE79931-791A-470C-86ED-99F72534470D--


From nobody Mon Apr 20 00:43:20 2020
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 1331B3A1375 for ; Mon, 20 Apr 2020 00:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level: 
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Z8sOM0TXgh for ; Mon, 20 Apr 2020 00:43:17 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 07F913A1373 for ; Mon, 20 Apr 2020 00:43:16 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id g74so9537615qke.13 for ; Mon, 20 Apr 2020 00:43:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lkFncC2ejP5EBjl7iBudwspHQQVTqvvWC5ARDznQQAc=; b=c0VA1PkQJ4c/i72MMH3GxuVJ3vzQQfkHavzlqMjioxXkFeHFQxfwomi17MZI7OE3BD wbMDOADZCY2FR4jDwbuYd7CDlum9ndwCWgn1CJwDTz+YzyijaIVNykoXbAYbivL1F0hp BYHFVYqgtoQtYgoqUTgJ2unXotiM8oDKIAl1y9k0GVtnWgY4sd+A7iw4EWpVTQkMSyuR ENtkTC85Ywnw83nsXqhIAgQ3348qKInRIEhJR9/L8xybjLpDLLsjPU77/Cl4W84uoDMI 8rtLmDMi3AnQoPnFjkWyStkqwTyOHQzuo6U0LaAkmKsaKGNiYUd0Rk942s3U357eFzFH v0gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lkFncC2ejP5EBjl7iBudwspHQQVTqvvWC5ARDznQQAc=; b=ue2goD62IHycvZbOx2CaaoibDs6gbokfegsJ+VtvgmLV2W+umvtQDsJ1FCfbinFIJP hPdA6HQqGTw1j6xdHuH7JOKHfx2Z6b8WQ1DUJMm1HWEX0OpWm89XS+IeSvRKuTam7Twv yPRYdjuWxIQrRoWfX9ifgaYudZxnWKb92pOyr4D69XNgHo9cm70Mg0XsqZwtvc8xrhUM TGhdUmLbBwfW0Hk60G/2SvnlClmG0YHP7gcLlhe2X40evbbyirm0JTGqggyHAfRpTruU Z1W2dZ1eA6XmSJf2HQ/ZcVP1ogFhHM1ehapUw0Em/Tmw1aR0YGVT1xqgSBKF+5DdFObP NHtA==
X-Gm-Message-State: AGi0PuYVDf0rDBIJVaAjDBi8GvbeaahPvFHLk3fhmfyf0w6s88E/JrYv OubpxBASDveFQeMtQUqaoOQSCL7CWHLRFhzbL4Z0zbU=
X-Google-Smtp-Source: APiQypKwEw57yC3+NPa3g+M4XpVwUa8oV9voEZG0yUiKqOIPiCYjWM7ImLcR90KvQ9DkzOZQHEd8oXYa4rvn/DakVE0=
X-Received: by 2002:a05:620a:158a:: with SMTP id d10mr14870201qkk.259.1587368595586;  Mon, 20 Apr 2020 00:43:15 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 03:43:14 -0400
From: Dominick Baier 
In-Reply-To: <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.com>
References:    <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>  <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.com>
MIME-Version: 1.0
Date: Mon, 20 Apr 2020 03:43:14 -0400
Message-ID: 
To: Philippe De Ryck 
Cc: Vittorio Bertocci ,  Vladimir Dzhuvinov ,  David Waite , oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000044919605a3b40dd5"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 07:43:19 -0000

--00000000000044919605a3b40dd5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hence my question

What should be the recommended semantics - =E2=80=9Cinformative=E2=80=9D - =
=E2=80=9Cor don=E2=80=99t accept
before a certain time stamp=E2=80=9D ?

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 20. April 2020 at 09:05:53, Philippe De Ryck (
philippe@pragmaticwebsecurity.com) wrote:

In theory, you can issue a token that only becomes valid in the future.
That would have a different iat and nbf timestamp. I have not seen this in
practice though.

Given that RFC 7519 lists =E2=80=9Ciat=E2=80=9D as informative, I would not=
 change that
behavior in a specific use case if there is no significant need to do so.

Philippe

On 20 Apr 2020, at 08:50, Dominick Baier  wrote:

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what=E2=80=99s the difference between the two
practically speaking - and shouldn=E2=80=99t be the more common (aka suppor=
ted by
most libraries) be used?

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=3D40alkaline-solutions.com@dmarc.ietf.org) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret =E2=80=9Ciat" to also have the meaning of=
 =E2=80=9Cnbf=E2=80=9D
in the absence of =E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescri=
bed by any spec
2. The DPoP draft=E2=80=99s client-generated tokens have the resource serve=
rs use
their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, since the tokens=
 are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past or =E2=
=80=9Cexp=E2=80=9D too far in the
future, but not that =E2=80=9Cnbf=E2=80=9D was too far in the past or that =
the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov 
wrote:

On 16/04/2020 10:10, Dominick Baier wrote:

*iat vs nbf*
What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t m=
ost JWT
libraries (including e.g. the ..NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

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


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

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

--00000000000044919605a3b40dd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Henc=
e my question

What =
should be the recommended semantics - =E2=80=9Cinformative=E2=80=9D - =E2=
=80=9Cor don=E2=80=99t accept before a certain time stamp=E2=80=9D ?
 =

 
=E2=80=94=E2=80=94=E2=80=94
Dominic=
k Baier
 
On 20. April 2020 at 09:05:=
53, Philippe De Ryck (=
philippe@pragmaticwebsecurity.com) wrote:
 
In theory, you ca=
n issue a token that only becomes valid in the future. That would have a di=
fferent iat and nbf timestamp. I have not seen this in practice though.=C2=
=A0

Given that RFC 7519=
 lists =E2=80=9Ciat=E2=80=9D as informative, I would not change that behavi=
or in a specific use case if there is no significant need to do so.

Philippe

On 20 Apr 2020, at 08:50, Dominick Baier <dbaier@leastprivilege.com> wrote:
Just a quick data point -=C2=A0

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat=
.

I guess my real question is - what=E2=80=99s t=
he difference between the two practically speaking - and shouldn=E2=80=99t =
be the more common (aka supported by most libraries) be used?

=E2=80=94=E2=80=94=E2=80=94
Dom=
inick Baier

On 20. April 2020 at 06:59:47, David Waite (=
david=3D40alkaline-solutions.com@dmarc.ietf.org) wrote:
=

There are a number of=
 ambiguities and statements around using JWTs in various contexts:

1. Some implementations interpr=
et =E2=80=9Ciat" to also have the meaning of =E2=80=9Cnbf=E2=80=9D in =
the absence of =E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescribed=
 by any spec
2. The DPoP draft=E2=80=99s client-genera=
ted tokens have the resource servers use their own nbf/exp heuristics aroun=
d =E2=80=9Ciat=E2=80=9D, since the tokens are meant for immediate one time =
use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may=
 reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past or =E2=
=80=9Cexp=E2=80=9D too far in the future, but not that =E2=80=9Cnbf=E2=80=
=9D was too far in the past or that the interval between nbf and exp was to=
o large.

The JWT =
spec also allows implementers to provide some leeway for clock skew. Presum=
ably this meant validators and not JWT creators, although there is history =
of messages setting similar values to account for clock skew (e.g. SAML IDP=
s setting notBefore to one minute before issuance and notOnOrAfter 5 minute=
s after issuance).=C2=A0

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir =
Dzhuvinov <vladimi=
r@connect2id.com> wrote:

On 16/04/2=
020 10:10, Dominick Baier wrote:
iat=
 vs nbf
What=E2=80=99s the ra=
tionale for using iat instead of nbf. Aren=E2=80=99t most JWT libraries (in=
cluding e.g. the ..NET one) looking for nbf by default?
<=
p class=3D"">Developers often tend to intuitively pick up "iat" o=
ver "nbf" because it sounds more meaningful (my private observati=
on). So given the empirical approach of Vittorio to the spec, I suspect tha=
t's how "iat" got here.
If we bother to care=
fully look at the JWT spec we'll see that "iat" is meant to b=
e "informational" whereas it's "nbf" that is intend=
ed to serve (together with "exp") in determining the actual valid=
ity window of the JWT.
https://tools.ie=
tf.org/html/rfc7519#section-4.1.5
My suggestion is to =
require either "iat" or "nbf". That shouldn't break=
 anything, and deployments that rely on one or the other to determine the v=
alidity window of the access token can continue using their preferred claim=
 for that.
Vladimir
______________=
_________________________________
OAuth mailing list
OAuth@ietf..org
https://www.ietf.org/mailman/listinfo/oauth

________________________________________=
_______=C2=A0
OA=
uth mailing list=C2=A0
OAuth@ietf.org=C2=A0
https://www.ietf.org/m=
ailman/listinfo/oauth=C2=A0
___________________________=
____________________
OAuth maili=
ng list
OAuth@ietf.org
https=
://www.ietf.org/mailman/listinfo/oauth



--00000000000044919605a3b40dd5--


From nobody Mon Apr 20 00:48:55 2020
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 85EA13A1399 for ; Mon, 20 Apr 2020 00:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 HN_MUfUBoFA5 for ; Mon, 20 Apr 2020 00:48:51 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 A3E3A3A1398 for ; Mon, 20 Apr 2020 00:48:51 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id t9so2088514pjw.0 for ; Mon, 20 Apr 2020 00:48:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=aIyYoMSPhIRmtExXO6USvkT6JmZnr/ZGYlPaIOb0bDg=; b=e2dHPNcQoLSM3JzMAPj9sTMSmDZWuv9SnbqkRWItCfgQ8CpgPbAc/Y3N5FlUK9SQvX gUFtYf5iF1NgSBEiM0fNjQvtTl8kBiPMjw0Bnp9xsQtR+WkC53UXPZtcSQqt/Dh9nt/+ 4tbdsqZO872EC1731KqCgFYQXfkSRExJRyuZvtKSUyeGCpnT8kz6ESnMTjwHyOsPkI8f 3iE/hbVY2xDSvBjWXr+7DT8K42LcOlwaGtFo8t1Hwt0TPV5b1rQCPr2Kyw8RKz3puA4W xiVMg/hESk0l+oF2k2SdeEUnHZqQqL+BmEGtwd5KgT/mEzNkJHZKs393pi8jKk6DcxX/ daYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=aIyYoMSPhIRmtExXO6USvkT6JmZnr/ZGYlPaIOb0bDg=; b=sGJxPf3eFhzX9KQ02gIKE5G6RSfiz7wH16OTjq5h+Ru+wHWulnkoZHcMXtKCVomOIa 1XR5MbDT10yYjToTtr7904PzvHhF2eHCQacrrmzO18kaIcTD9SYnZrmjOCElsHzHdVBj d6ivDFqM9WJzxKd+hNbuWYCjR5eWcRdw1xKVDO+i0+1/12CPcn1n13EWE3wbDRuiYoEC TRDxHJCBqNDvQr9ZpQFSexD/tIVIb5rWd5y6T4RRx7gjKezeFeiBBF8phyvm03AXyfzS CGrbylBL2+Et1Ew7EHLctmGAp5u6kOFkc5Z61UpBNIm+4oO7V8/YHs14h60REhTxpGHJ 4AWw==
X-Gm-Message-State: AGi0PuYOlBFqoiyIufKPkiPSN1nHh2UR+8BuYekOhBni811KIhJ1VCjB coo8twiIRXErcCH7uf6tdKfNLw==
X-Google-Smtp-Source: APiQypKHMgbj8JvRdnZ7b5Xu+cyNusOU3l4J21a5OUhALF+YD1RDktxaxsjQEayvm+1uImxyUm/dEg==
X-Received: by 2002:a17:90a:c983:: with SMTP id w3mr20802042pjt.102.1587368930516;  Mon, 20 Apr 2020 00:48:50 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id r63sm335243pfr.42.2020.04.20.00.48.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 00:48:50 -0700 (PDT)
From: 
To: "'Dominick Baier'" , "'Rifaat Shekh-Yusef'" , "'oauth'" 
References:  
In-Reply-To: 
Date: Mon, 20 Apr 2020 00:48:49 -0700
Message-ID: <085301d616e8$21029750$6307c5f0$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0854_01D616AD.74A768D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMKsWrR7q68zM9CsrN/StHwRJR9eAIthgGopgbpRgA=
Content-Language: en-us
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 07:48:54 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0854_01D616AD.74A768D0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Dominick for your comments!

Inline

=20

> All other OAuth specs make a very clear distinction between users and =
client.

There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In =
previous discussions on this topic it has been brought up that the JWT =
spec defines sub as identifying the principal that is the subject of the =
JWT, and that=E2=80=99s not necessarily limited to users.=20

However I get the potential confusion, and I am happy to add clarifying =
language if you have specific passages in the space you are particularly =
worried about: however I feel the matter is addressed upfront by the =
language in Section 2.2. in the sub entry, =E2=80=9CIn case of access =
tokens obtained through grants where no resource owner is involved, such =
as the client credentials grant, the value of sub SHOULD correspond to =
an identifier the authorization server uses to indicate the client =
application.=E2=80=9C and Section 5 has an entire paragraph discussing =
things to watch out in assigning sub values in the app identity case. =
Feel free to suggest additional language if you want to clarify further. =


=20

> sub has a different semantic here as in OIDC

The  spec refers to RFC7519 in the sub definition in 2.2, rather than =
OIDC, to preempt that concern and keep the original sub semantic =
available.

=20

> I am not fully clear why aud is required.

Aud is there mostly because of three reasons:

*	Many existing specs postulate its existence in the token. No one =
declares it as a proper MUST (apart from the BCP, but that=E2=80=99s =
partial) however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the =
mechanism to prevent token redirect (and adds scope restriction as also =
important, however here we make it optional to acocut for =
non-delegations scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as =
one of the assumptions that must hold to prevent bearer tokens misuse=20
-BCP225 makes aud mandatory for AS which can issue JWTs for more than =
one app
*	Apart from Ping, for which some of its examples are without aud (but =
also without identifying scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from =
vendors all featured an aud. I know one shoulnd=E2=80=99t overindex on =
those examples, but together with the above it seemed to point to =
something universally useful. One possible reason is that use of a =
format for the AT is correlated with topologies where AS and RS are =
separated by some boundary (network, logical, business, code factoring, =
etc) hence identifying the resource seems like a natural need. Again, =
not an iron clad law, but an indication.
*	A lot of people repurpose existing libraries for the JWT AT case, and =
some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t =
mean that we should condone any bad practices, but in tis particular =
case it suggests that lots of developers already expect/can handle an =
audience in the JWT used to call their API

None of those are a slam dunk argument for mandatory, but I find them =
compelling enough to simplify validation and just require an aud to be =
there, as opposed to introduce complications that make it conditional to =
the presence of scopes or other disambiguation. One reason I feel pretty =
good about that is that adding a default audience isn=E2=80=99t very =
hard if any of the above assumptions end up not being true for a =
particular case

=20

> What=E2=80=99s the rationale for using iat instead of nbf.=20

That=E2=80=99s just straight from OIDC ID_tokens, and the considerations =
about repurposing existing logic. I see there=E2=80=99s a thread on this =
specifically, let me answer further on that branch.

=20

> This spec feels somehow in between a profile and a BCP

You are right that this spec attempts to go beyond just declaring a =
layout, and I agree this means that this profile will not apply to =
absolutely everyone. The reason I tried that route (at the cost of =
working way harder in the last year for reaching consensus than if we =
would have just listed the possible content), is that I often observe =
implementers make questionable choices because of the large leeway =
specifications allow. My hope was that the scope of this profile was =
small enough to make that extra level of guidance achievable, whereas =
trying to do the same with a larger spec would have been prohibitively =
expensive.=20

I believe things worked out well so far: we had lots of constructive =
discussions, and I ended up relaxing A LOT of the constraints I was =
originally envisioning. Nonetheless, my hope is that we identified the =
right set of guidelines that will help people actually interoperate out =
of the box for the most basic/common scenarios, as opposed to complying =
with the letter of the spec but still having a lot to figure out out of =
band.=20

=20

From: OAuth  On Behalf Of Dominick Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: Rifaat Shekh-Yusef ; oauth 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for =
OAuth 2.0 Access Tokens"

=20

Since this is the last call, I thought I bring up some of thoughts / =
concerns. Some of them have been discussed before.

=20

client_id vs sub

I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of =
the claim types based on flow.

If the intention is, that sub expresses the entity against which the =
resource will do authorisation (and that might be a client or a user) - =
I get it (and maybe it should be stated like that) - but

this thinking reminds me of the old AD days where there was no =
distinction between user and service accounts (something that has been =
fixed IIRC in Windows Server 2012 R2).

=20

All other OAuth specs make a very clear distinction between users and =
client.

=20

Furthermore it says

=20

"Authorization servers should prevent scenarios where clients can

   affect the value of the sub claim in ways that could confuse resource

   servers.=E2=80=9D

=20

If we keep that dual semantics of the sub claim - it must be clearly =
stated, that subject ID and client ID are now in the same collision =
domain. So when an AS / OP creates them, they need to be unique across =
user ids and client ids.

=20

Maybe it should be also explicitly mentioned that sub has a different =
semantic here as in OIDC - even though a majority of the software built =
today will use them together.

=20

audience claim

I am not fully clear why aud is required. OAuth itself does not have a =
notion of an audience (in the JWT sense) - they have scopes (which is =
very similar). But in simple scenarios where resources don=E2=80=99t =
exist, you'd need to make up an audience just to fulfil this =
requirement. And in many case this will be either static or just repeat =
the scope values. What=E2=80=99s the value of that?

=20

If the concept of resources are used, I absolutely agree that aud should =
be used too. But I wouldn=E2=80=99t make it required.

=20

iat vs nbf

What=E2=80=99s the rationale for using iat instead of nbf. =
Aren=E2=80=99t most JWT libraries (including e.g. the .NET one) looking =
for nbf by default?

=20

General

This spec feels somehow in between a profile and a BCP. On one hand you =
define some claims and their semantics (good) - on the other hand there =
is some prescriptive guidance and maybe over-specification. My concern =
is, that in the end no-one will fully comply with it, because it =
doesn=E2=80=99t work one way or the other for them.

=20

I know we just went though the discussion to make certain claims =
required as opposed to optional - but maybe less is more.

=20

Tbh - the most valuable part of the doc to me is the definition of the =
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to =
see just some standard claims and IF they are used, which semantics they =
have.

=20

cheers=20

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=20

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com =
 ) wrote:

Hi all,

=20

This is a second working group last call for "JSON Web Token (JWT) =
Profile for OAuth 2.0 Access Tokens".

=20

Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

=20

Please send your comments to the OAuth mailing list by April 29, 2020.

=20

Regards,

 Rifaat & Hannes

=20

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


------=_NextPart_000_0854_01D616AD.74A768D0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks =
Dominick for your comments!
Inline
 
> All other =
OAuth specs make a very clear distinction between users and =
client.
There=E2=80=99s a =
nuance worth highlighting here: sub !=3D user. In previous discussions =
on this topic it has been brought up that the JWT spec defines sub as =
identifying the principal that is the subject of the JWT, and =
that=E2=80=99s not necessarily limited to users. =

However I =
get the potential confusion, and I am happy to add clarifying language =
if you have specific passages in the space you are particularly worried =
about: however I feel the matter is addressed upfront by the language in =
Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained =
through grants where no resource owner is involved, such as the client =
credentials grant, the value of sub SHOULD correspond to an identifier =
the authorization server uses to indicate the client =
application.=E2=80=9C =
and Section 5 has an entire paragraph discussing things to watch out in =
assigning sub values in the app identity case. Feel free to suggest =
additional language if you want to clarify further. 
 
> sub =
has a different semantic here as in OIDC
The =C2=A0spec refers to RFC7519 in the sub definition =
in 2.2, rather than OIDC, to preempt that concern and keep the original =
sub semantic available.
 
> I am not =
fully clear why aud is required.
Aud is there mostly because of three =
reasons:
  • Many existing specs postulate its existence in the token. No one =
declares it as a proper MUST (apart from the BCP, but that=E2=80=99s =
partial) however I think its importance comes across..
    -Bearer token =
usage RFC6750 calls it out (in threat mitigation) as the mechanism to =
prevent token redirect (and adds scope restriction as also important, =
however here we make it optional to acocut for non-delegations =
scenario).
    -Resource indicators RFC8707 refers to the same section of =
RFC7519 as one of the assumptions that must hold to prevent bearer =
tokens misuse 
    -BCP225 makes aud mandatory for AS which can issue =
JWTs for more than one app
  • Apart from Ping, for =
which some of its examples are without aud (but also without identifying =
scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from =
vendors all featured an aud. I know one shoulnd=E2=80=99t overindex on =
those examples, but together with the above it seemed to point to =
something universally useful. One possible reason is that use of a =
format for the AT is correlated with topologies where AS and RS are =
separated by some boundary (network, logical, business, code factoring, =
etc) hence identifying the resource seems like a natural need. Again, =
not an iron clad law, but an indication.
  • A lot of people repurpose existing libraries for the JWT AT case, =
and some people even sends id_tokens in lieu of ATs. That =
doesn=E2=80=99t mean that we should condone any bad practices, but in =
tis particular case it suggests that lots of developers already =
expect/can handle an audience in the JWT used to call their =
API
None of those are a slam =
dunk argument for mandatory, but I find them compelling enough to =
simplify validation and just require an aud to be there, as opposed to =
introduce complications that make it conditional to the presence of =
scopes or other disambiguation. One reason I feel pretty good about that =
is that adding a default audience isn=E2=80=99t very hard if any of the =
above assumptions end up not being true for a particular =
case
 =

> =
What=E2=80=99s the rationale for using iat instead of nbf. =

That=E2=80=99s just =
straight from OIDC ID_tokens, and the considerations about repurposing =
existing logic. I see there=E2=80=99s a thread on this specifically, let =
me answer further on that branch.
 =

> This =
spec feels somehow in between a profile and a =
BCP
You are right that =
this spec attempts to go beyond just declaring a layout, and I agree =
this means that this profile will not apply to absolutely everyone. The =
reason I tried that route (at the cost of working way harder in the last =
year for reaching consensus than if we would have just listed the =
possible content), is that I often observe implementers make =
questionable choices because of the large leeway specifications allow. =
My hope was that the scope of this profile was small enough to make that =
extra level of guidance achievable, whereas trying to do the same with a =
larger spec would have been prohibitively expensive. 
I believe things worked out well so far: we had lots =
of constructive discussions, and I ended up relaxing A LOT of the =
constraints I was originally envisioning. Nonetheless, my hope is that =
we identified the right set of guidelines that will help people actually =
interoperate out of the box for the most basic/common scenarios, as =
opposed to complying with the letter of the spec but still having a lot =
to figure out out of band. 
 
From: OAuth =
<oauth-bounces@ietf.org> On Behalf Of Dominick =
Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: =
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth =
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Second WGLC on =
"JSON Web Token (JWT) Profile for OAuth 2.0 Access =
Tokens"
 
Since this =
is the last call, I thought I bring up some of thoughts / concerns. Some =
of them have been discussed before.
 =

client_id =
vs sub=

I am still =
not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of the claim =
types based on flow.
If the =
intention is, that sub expresses the entity against which the resource =
will do authorisation (and that might be a client or a user) - I get it =
(and maybe it should be stated like that) - =
but
this =
thinking reminds me of the old AD days where there was no distinction =
between user and service accounts (something that has been fixed IIRC in =
Windows Server 2012 R2).
 =

All other =
OAuth specs make a very clear distinction between users and =
client.
 =

Furthermore=
 it says
 =

"Autho=
rization servers should prevent scenarios where clients =
can
  =
 affect the value of the sub claim in ways that could confuse =
resource
  =
 servers.=E2=80=9D
 =

If we keep =
that dual semantics of the sub claim - it must be clearly stated, that =
subject ID and client ID are now in the same collision domain. So when =
an AS / OP creates them, they need to be unique across user ids and =
client ids.
 =

Maybe it =
should be also explicitly mentioned that sub has a different semantic =
here as in OIDC - even though a majority of the software built today =
will use them together.
 =

audience =
claim=

I am not =
fully clear why aud is required. OAuth itself does not have a notion of =
an audience (in the JWT sense) - they have scopes (which is very =
similar). But in simple scenarios where resources don=E2=80=99t exist, =
you'd need to make up an audience just to fulfil this requirement. And =
in many case this will be either static or just repeat the scope values. =
What=E2=80=99s the value of that?
 =

If the =
concept of resources are used, I absolutely agree that aud should be =
used too. But I wouldn=E2=80=99t make it =
required.
 =

iat vs =
nbf=

What=E2=80=99=
s the rationale for using iat instead of nbf. Aren=E2=80=99t most JWT =
libraries (including e.g. the .NET one) looking for nbf by =
default?
 =

General=

This spec =
feels somehow in between a profile and a BCP. On one hand you define =
some claims and their semantics (good) - on the other hand there is some =
prescriptive guidance and maybe over-specification. My concern is, that =
in the end no-one will fully comply with it, because it doesn=E2=80=99t =
work one way or the other for them.
 =

I know we =
just went though the discussion to make certain claims required as =
opposed to optional - but maybe less is =
more.
 =

Tbh - the =
most valuable part of the doc to me is the definition of the =
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to =
see just some standard claims and IF they are used, which semantics they =
have.
 =

cheers =
;
=E2=80=94=E2=
=80=94=E2=80=94
Dominick =
Baier
 =

On 15. =
April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) =
wrote:
Hi all,
 
This is a second working =
group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 =
Access Tokens".
 
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
 
Please send your comments to the OAuth =
mailing list by April 29, 2020.
 
Regards,
 Rifaat & Hannes
 
___________=
____________________________________ 
OAuth mailing list 
OAuth@ietf.org 
https://www.ietf.org=
/mailman/listinfo/oauth =


------=_NextPart_000_0854_01D616AD.74A768D0--



From nobody Mon Apr 20 00:49:49 2020
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 7AB7B3A139F for ; Mon, 20 Apr 2020 00:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 PWXkGi6ai7AS for ; Mon, 20 Apr 2020 00:49:46 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 C22E23A139C for ; Mon, 20 Apr 2020 00:49:46 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id r4so4656632pgg.4 for ; Mon, 20 Apr 2020 00:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=cuj/64J/qr0ZAt3XYQfjLmkrjHRMJju5BhrXoXMv4P4=; b=bh0bELouV4fqnPn4meQhqzacgrW0P4Vd5zkwp8bKXvhViPrGbvKuXAjuJVKPzaWp1h ViZt2BisglXKs1MtTXg1yX/tgTQhGS7YNzBGN66cPzvFkQ9+AZs3bAEi+FqleVRrEWB4 ZhHWHfHeTfs30iww7Ls+quPdCSxhmBVollniY2ScTBm3gqj4KZUuUJ3enkiJ3nSLa32Y +gXicVlemdCqSXhv6Kc7CYuyeVlUNx2GJp0puJzRj+N/Sg0CacxbTV6l/zphZyfnW2tb 2rq4Kdu5UKtxkXcL4sJDqFKjUx9tk/XpTVRAa7ON19tcWaztFfqi+XBkRYHrNT+IHYo1 hOPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=cuj/64J/qr0ZAt3XYQfjLmkrjHRMJju5BhrXoXMv4P4=; b=bvfMV7zJ8WBZRE6uRuIUAPEKjCTIIPrCt8ovqz554eb1ZhX3dd3OjRW2OupdjkrQKK S7Av/pHZSFV0SlHu60COWnSANt6nlcJBtqnvf/luS5dRs0rdHzRd4YvgxCJGOmnDWLl3 niGwmZn+MGvDELRjqqT3fPgyeyFKAHHQSKS05QqsY8NQ9OWX29U55i16y2LJlxab114E ecfrgR4zMKbBgMr3SQJXOI2baUChnzvbOAMojil6PP0RiATpLFYF3yNHgEcfdXSKP7Oq oiYYhdQScRZX1bM7fYR8SVED5522KgZiIX+Ow+cniLdCXD721wbBkCO9hFryfdN6sg86 NW2g==
X-Gm-Message-State: AGi0PubVo8ufU5IgmB5ryup4i045fnbWMnSgHzeH99PahWSon81CeVfa 7JAYOyr/qmrgFa4F7kOuX831Krzyw/bRxA==
X-Google-Smtp-Source: APiQypJGnZEmhiTFIwLER2h/6YHqffJpXD89cg8zqNfWpp+sti5f6weJs2MwREnAP0TGuTTJ0sWi0A==
X-Received: by 2002:a63:d201:: with SMTP id a1mr15275902pgg.3.1587368985996; Mon, 20 Apr 2020 00:49:45 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id ml24sm228716pjb.48.2020.04.20.00.49.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 00:49:45 -0700 (PDT)
From: 
To: "'Brian Campbell'" , "'Aaron Parecki'" 
Cc: "'oauth'" 
References:     
In-Reply-To: 
Date: Mon, 20 Apr 2020 00:49:44 -0700
Message-ID: <086201d616e8$4216c2e0$c64448a0$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0863_01D616AD.95BB6D50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMKsWrR7q68zM9CsrN/StHwRJR9eAFUM/u7AmtkLzQBsagRbQLsZC+xpdVoPJA=
Content-Language: en-us
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 07:49:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0863_01D616AD.95BB6D50
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the catch! Will add a mention of that in section 2.1 as well.

=20

From: OAuth  On Behalf Of Brian Campbell
Sent: Thursday, April 16, 2020 1:16 PM
To: Aaron Parecki 
Cc: oauth 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for =
OAuth 2.0 Access Tokens"

=20

I'll +1 that=20

=20

On Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki  > wrote:

My mistake! In that case, my request is editorial, to mention that in =
section 2.1 where it first talks about signing algorithms.




----

Aaron Parecki

aaronparecki.com =20

@aaronpk =20

=20

=20

=20

On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell =
 > wrote:

sec 4 does have "The resource server MUST reject any JWT in which the =
value of "alg" is "none".'

=20

On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki  > wrote:

Section 2.1 says:

=20

> Although JWT access tokens can use any signing algorithm, use of

> asymmetric algorithms is RECOMMENDED

=20

Can this be strengthened to disallow the `none` algorithm? Something =
like adding "... and MUST NOT use the "none" algorithm".

=20

Given that the JWT BCP doesn't disallow the "none" algorithm, =
technically someone could follow both this JWT Access Token spec and the =
JWT BCP spec and end up with an implementation that allows an AS to =
accept JWTs with the "none" algorithm.

=20

----

Aaron Parecki

aaronparecki.com =20

@aaronpk =20

=20

=20

=20

On Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef =
 > wrote:

Hi all,

=20

This is a second working group last call for "JSON Web Token (JWT) =
Profile for OAuth 2.0 Access Tokens".

=20

Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

=20

Please send your comments to the OAuth mailing list by April 29, 2020.

=20

Regards,

 Rifaat & Hannes

=20

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

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


CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.


------=_NextPart_000_0863_01D616AD.95BB6D50
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for =
the catch! Will add a mention of that in section 2.1 as =
well.
 
From: OAuth =
<oauth-bounces@ietf.org> On Behalf Of Brian =
Campbell
Sent: Thursday, April 16, 2020 1:16 PM
To: =
Aaron Parecki <aaron@parecki.com>
Cc: oauth =
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Second WGLC on =
"JSON Web Token (JWT) Profile for OAuth 2.0 Access =
Tokens"
 
I'll +1 =
that 
 
On =
Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki <aaron@parecki.com> =
wrote:
My =
mistake! In that case, my request is editorial, to mention that in =
section 2.1 where it first talks about signing =
algorithms.

----
Aaron Parecki
 
 
 
On =
Thu, Apr 16, 2020 at 1:12 PM Brian Campbell <bcampbell@pingidentity.com> =
wrote:
sec =
4 does have "The resource server MUST reject any JWT in which the =
value of "alg" is "none".'
 
On =
Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki <aaron@parecki.com> =
wrote:
Section 2.1 says:
 
> Although JWT access tokens can use any signing =
algorithm, use of
> =
asymmetric algorithms is RECOMMENDED
 
Can this be strengthened to disallow the `none` =
algorithm? Something like adding "... and MUST NOT use the =
"none" algorithm".
 
Given that the JWT BCP doesn't disallow the =
"none" algorithm, technically someone could follow both this =
JWT Access Token spec and the JWT BCP spec and end up with an =
implementation that allows an AS to accept JWTs with the =
"none" algorithm.
 
----
Aaron Parecki
 
 
 
On =
Wed, Apr 15, 2020 at 11:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> =
wrote:
Hi all,
 
This is a second working group last call for =
"JSON Web Token (JWT) Profile for OAuth 2.0 Access =
Tokens".
 
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-tok=
en-jwt-06
 
Please send your comments to the OAuth =
mailing list by April 29, 2020.
 
Regards,
 Rifaat & Hannes
 
_______________________________________________
OAut=
h mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAut=
h mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain =
confidential and privileged material for the sole use of the intended =
recipient(s). Any review, use, distribution or disclosure by others is =
strictly prohibited.  If you have received this communication in =
error, please notify the sender immediately by e-mail and delete the =
message and any file attachments from your computer. Thank =
you.
<=
p class=3DMsoNormal>
CONFIDENTIALITY NOTICE: This email may contain =
confidential and privileged material for the sole use of the intended =
recipient(s). Any review, use, distribution or disclosure by others is =
strictly prohibited..  If you have received this communication in =
error, please notify the sender immediately by e-mail and delete the =
message and any file attachments from your computer. Thank =
you.

------=_NextPart_000_0863_01D616AD.95BB6D50--


From nobody Mon Apr 20 01:11:20 2020
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 E41AB3A08E1 for ; Mon, 20 Apr 2020 01:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 oMorxuqtieiH for ; Mon, 20 Apr 2020 01:11:11 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 6AC643A046D for ; Mon, 20 Apr 2020 01:11:00 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id y25so4583102pfn.5 for ; Mon, 20 Apr 2020 01:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=tcxHdrW5igwdjhgkuRBznLolNnPgZwqzLP57hDM2X4I=; b=LZdZZpBgJwW79E3EpP1Fwx7ybWMYDEzMI/fKK1z9Pv2fTYcTgNF2Hpz4Cd0pEspbbZ LElECFcDriayyX5DYRlLeZ2D4BV2AQ7rsC3bduabJlSyKn4V9Tp48JYvAaUpXWpPj9s5 vDEWqwXVSzH8RffQh5CcwMj1PJee/hDqzlymnLFwru7CiCmXum1xUJtK/n0xUEEu77zC sDXk33tq9HwGuaOTZFVMyytGswKBlnnUKcFr0/oU7PUU1sZgXIbFOkGrLHC2PNatFsTs m9nN1TJcAefgYoPnyxltLUnK48b9c8EqD5DA73gi3w1cvTf3rjo/3o6ryvPZKOX+KiaM FFGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=tcxHdrW5igwdjhgkuRBznLolNnPgZwqzLP57hDM2X4I=; b=D0sTKjVxGyGqrLPNBn0WieoDlQmtpgWIYe6WvuztpuIxZvYnWKfkUn6R+duDPMpCQY 5BerUQNFYQv50j+BX+H9qoJBbk6Q+LZ1ptgJ613Cr4ISWGCEbeW1X+HjM1Z1Wmf3jEam JIAUfwMXEMnbV5SnTWrAAnTolkC7L7O7lQyZL0eJGIznG08B7n/wRVWFr9xN23Q3xz8O YVRcjwHc1T8qUKNFRJS8uRNzutyLI5s59llOVrFk8LDYowgYdi5K1bJ59CEOjddtzN7+ S8BYhrj9oGt/0aoBgcrrtPInCTgEGlX0FIMs8hk914aP52uuE6VrYy5nDatKlxyCwSOf EDwg==
X-Gm-Message-State: AGi0PuYyVW0lJzrMHbQ1Ripl903xaO/HMO+2DqKyFq4N8nQIEwqHyW8y rqH7K1N+7ook2sw/7Vk68s4J15Qk6TAniA==
X-Google-Smtp-Source: APiQypLEgv0nKI+UDbINujG5XHii4QphG+fv4VVpLhglVOcVg/JpsYAl623uvG2+Vpc3/rXvXB5h2w==
X-Received: by 2002:a63:514a:: with SMTP id r10mr13304365pgl.246.1587370259444;  Mon, 20 Apr 2020 01:10:59 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id r128sm357267pfc.141.2020.04.20.01.10.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 01:10:59 -0700 (PDT)
From: 
To: "'David Waite'" , "'Vladimir Dzhuvinov'" , "'Dominick Baier'" 
Cc: 
References:    <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
In-Reply-To: <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
Date: Mon, 20 Apr 2020 01:10:58 -0700
Message-ID: <08b901d616eb$392e2760$ab8a7620$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08BA_01D616B0.8CD19950"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMKsWrR7q68zM9CsrN/StHwRJR9eAIthgGoAs78VUYCJVShOaXfRoXg
Content-Language: en-us
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 20 Apr 2020 08:11:19 -0000

This is a multipart message in MIME format.

------=_NextPart_000_08BA_01D616B0.8CD19950
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks guys for the commentary here.

I wasn=E2=80=99t too partial on the =E2=80=9Ctime claim=E2=80=9D type. I =
just went for =E2=80=9CIat=E2=80=9D very much in line with =
Vladimir=E2=80=99s guess, it was quite empirical:=20

*	it comes from OIDC, and for the usual consideration that existing =
logic used for processing ID_tokens will be partially repurposed to =
implement some of the validation steps
*	=E2=80=9Cnbf=E2=80=9D appeared as the =E2=80=9Ctime claim=E2=80=9D =
only in AzureAD and IS, while =E2=80=9Ciat=E2=80=9D appears in AWS, =
OKTA, Auth0 and again Azure AD, hence it seemed the common choice

The slightly more philosophical, but still empirical reason is that I =
haven=E2=80=99t observed scenarios in which the RS defers to the AS the =
decision about the starting time for the validity of the AT, the =
semantic of =E2=80=9Cnbf=E2=80=9D, whereas =E2=80=9Ciat=E2=80=9D simply =
states a fact about the token and it=E2=80=99s up to the RS to decide =
what to do with it, including applying nbf sematic. That=E2=80=99s a =
decision that can be easily enshrined as a default in an SDK without =
loss of expressive power.

=20

I am not married to =E2=80=9Ciat=E2=80=9D and if there=E2=80=99s strong =
momentum for =E2=80=9Cnbf=E2=80=9D I am open to change it, however we =
are in a second last call and we just discussed =E2=80=9Ciat=E2=80=9D in =
the interim meeting last week, hence I thought we had pretty strong =
consensus on =E2=80=9Ciat=E2=80=9D already. You folks tell me =
=F0=9F=98=8A

=20

From: OAuth  On Behalf Of David Waite
Sent: Sunday, April 19, 2020 10:00 PM
To: Vladimir Dzhuvinov 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for =
OAuth 2.0 Access Tokens"

=20

There are a number of ambiguities and statements around using JWTs in =
various contexts:

=20

1. Some implementations interpret =E2=80=9Ciat" to also have the meaning =
of =E2=80=9Cnbf=E2=80=9D in the absence of =E2=80=9Cnbf=E2=80=9D, =
although this is AFAIK not prescribed by any spec

2. The DPoP draft=E2=80=99s client-generated tokens have the resource =
servers use their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, =
since the tokens are meant for immediate one time use by a party that =
may not have clock synchronization.

3. There are recommendations in the JWT profile for OAuth that the AS =
may reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past =
or =E2=80=9Cexp=E2=80=9D too far in the future, but not that =
=E2=80=9Cnbf=E2=80=9D was too far in the past or that the interval =
between nbf and exp was too large.

=20

The JWT spec also allows implementers to provide some leeway for clock =
skew. Presumably this meant validators and not JWT creators, although =
there is history of messages setting similar values to account for clock =
skew (e.g. SAML IDPs setting notBefore to one minute before issuance and =
notOnOrAfter 5 minutes after issuance).=20

=20

-DW





On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov  > wrote:

=20

On 16/04/2020 10:10, Dominick Baier wrote:

iat vs nbf

What=E2=80=99s the rationale for using iat instead of nbf. =
Aren=E2=80=99t most JWT libraries (including e.g. the ..NET one) looking =
for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it =
sounds more meaningful (my private observation). So given the empirical =
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is =
meant to be "informational" whereas it's "nbf" that is intended to serve =
(together with "exp") in determining the actual validity window of the =
JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break =
anything, and deployments that rely on one or the other to determine the =
validity window of the access token can continue using their preferred =
claim for that.

Vladimir

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

=20


------=_NextPart_000_08BA_01D616B0.8CD19950
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks =
guys for the commentary here.
I =
wasn=E2=80=99t too partial on the =E2=80=9Ctime claim=E2=80=9D type. I =
just went for =E2=80=9CIat=E2=80=9D very much in line with =
Vladimir=E2=80=99s guess, it was quite empirical: 
  • it comes from OIDC, =
and for the usual consideration that existing logic used for processing =
ID_tokens will be partially repurposed to implement some of the =
validation steps
  • =E2=80=9Cnbf=E2=80=9D =
appeared as the =E2=80=9Ctime claim=E2=80=9D only in AzureAD and IS, =
while =E2=80=9Ciat=E2=80=9D appears in AWS, OKTA, Auth0 and again Azure =
AD, hence it seemed the common choice
The slightly more philosophical, but still empirical =
reason is that I haven=E2=80=99t observed scenarios in which the RS =
defers to the AS the decision about the starting time for the validity =
of the AT, the semantic of =E2=80=9Cnbf=E2=80=9D, whereas =
=E2=80=9Ciat=E2=80=9D simply states a fact about the token and =
it=E2=80=99s up to the RS to decide what to do with it, including =
applying nbf sematic. That=E2=80=99s a decision that can be easily =
enshrined as a default in an SDK without loss of expressive =
power.
 
I am not married to =E2=80=9Ciat=E2=80=9D and if =
there=E2=80=99s strong momentum for =E2=80=9Cnbf=E2=80=9D I am open to =
change it, however we are in a second last call and we just discussed =
=E2=80=9Ciat=E2=80=9D in the interim meeting last week, hence I thought =
we had pretty strong consensus on =E2=80=9Ciat=E2=80=9D already. You =
folks tell me 😊
 
From: OAuth =
<oauth-bounces@ietf.org> On Behalf Of David =
Waite
Sent: Sunday, April 19, 2020 10:00 PM
To: =
Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] Second WGLC on =
"JSON Web Token (JWT) Profile for OAuth 2.0 Access =
Tokens"
 
There are a =
number of ambiguities and statements around using JWTs in various =
contexts:
 
1. Some implementations interpret =E2=80=9Ciat" =
to also have the meaning of =E2=80=9Cnbf=E2=80=9D in the absence of =
=E2=80=9Cnbf=E2=80=9D, although this is AFAIK not prescribed by any =
spec
2. The DPoP =
draft=E2=80=99s client-generated tokens have the resource servers use =
their own nbf/exp heuristics around =E2=80=9Ciat=E2=80=9D, since the =
tokens are meant for immediate one time use by a party that may not have =
clock synchronization.
3. =
There are recommendations in the JWT profile for OAuth that the AS may =
reject tokens based on an =E2=80=9Ciat=E2=80=9D too far in the past or =
=E2=80=9Cexp=E2=80=9D too far in the future, but not that =
=E2=80=9Cnbf=E2=80=9D was too far in the past or that the interval =
between nbf and exp was too large.
 
The JWT spec also allows implementers to provide some =
leeway for clock skew. Presumably this meant validators and not JWT =
creators, although there is history of messages setting similar values =
to account for clock skew (e.g. SAML IDPs setting notBefore to one =
minute before issuance and notOnOrAfter 5 minutes after =
issuance). 
 
-DW


On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> =
wrote:
 
On 16/04/2020 10:10, Dominick Baier =
wrote:
iat vs nbf
What=E2=80=99s the rationale for using iat instead of =
nbf. Aren=E2=80=99t most JWT libraries (including e.g. the ..NET one) =
looking for nbf by default?
Developers =
often tend to intuitively pick up "iat" over "nbf" =
because it sounds more meaningful (my private observation). So given the =
empirical approach of Vittorio to the spec, I suspect that's how =
"iat" got here.
If we =
bother to carefully look at the JWT spec we'll see that "iat" =
is meant to be "informational" whereas it's "nbf" =
that is intended to serve (together with "exp") in determining =
the actual validity window of the JWT.
https://tools.=
ietf.org/html/rfc7519#section-4.1.5
My =
suggestion is to require either "iat" or "nbf". That =
shouldn't break anything, and deployments that rely on one or the other =
to determine the validity window of the access token can continue using =
their preferred claim for that.
Vladimir
_______________________________________________
OAut=
h mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 

------=_NextPart_000_08BA_01D616B0.8CD19950--


From nobody Mon Apr 20 10:59:51 2020
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 842CD3A0E0E for ; Mon, 20 Apr 2020 10:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.186
X-Spam-Level: 
X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[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, T_SPF_TEMPERROR=0.01, 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 KkXxGdfgJQ8d for ; Mon, 20 Apr 2020 10:59:29 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 9EC9B3A0C64 for ; Mon, 20 Apr 2020 10:56:39 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id z12so10734376ilb.10 for ; Mon, 20 Apr 2020 10:56:39 -0700 (PDT)
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=zz5a9uAvcPx6kZXQoTdfynkDZccFYJ6vVivxXctZAL0=; b=e7eo95pHFrnUE63Jg/mjJq6n+AeiNssYbun1g9Zt6Q2wxd2j33C5JtenU4xm6QifI7 H5ZTodeI1Qm7x86PVt2fR6mzDeQ/7voiodKGyVvF9aiUX7VFHHZqGjq7Syh31lmo/ODv Z1Qe8VEqvHicaMgyDNeWlIVw5HzEq+RlxKGlQWNZ1BPCaORb3028bnmRzpxiSL41O+46 4e/21/vj/IXHz8klOWHxZYNS93MMb+ohofYGlMKSH2Pd4RbRN+lHAF7Y1NA93GAG1ZZz c/l2B5i8FEEBVcaX3HUK8pH+B6YQMvvCHBR8wc1Xdd+DKbELxgbiFXL5WO+lhpAcL1Iv b/XA==
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=zz5a9uAvcPx6kZXQoTdfynkDZccFYJ6vVivxXctZAL0=; b=DABxxURYIHv5SqhuSYlSzzKW2TbbQs42RXERa8UrMFu7tHqd41yhPjOUGy+bE2t9zx yOkRo8C/VS0fO3C21gbAWvdr47vOxzJ6l0By8YydQksx6xbkNACbzF6kod9tpS29yNV2 qM7LJTa6r01in/jrzKhF5nmKkwh97/z8Nn3J88fzdCWSwXXtay3FavMFUyPE02fuEkMw nhSVcmwyB4vU5u/T8J8vIXdb9yLttqZQCL0MKdvHPaUsuoKMcY6h5hB/Lfx9pB5iU99i FBKgdIqN6gCMgZi/x4FSSZm5Q4hgvqlZoJI/vEWgcAJfJ5e1llZrLmSLyW1jffA3tPAU xnQw==
X-Gm-Message-State: AGi0PubS4sHRC+21up+9NcP93Sf+U9vdyd+SgQMnx822M2Y/NUdyTBnF uGzvvLVOfuQ5TjiBKhCSF72+fxdxVHL7OvIxASil20qk1KE=
X-Google-Smtp-Source: APiQypKscUIkS1pxac/ttjJWnUf/zquL3CaPMd/xca0kYkyZWHlqiYjkAmUcYVFttVNkl9T14UJRUFqLd0klGjHX35k=
X-Received: by 2002:a92:5e4d:: with SMTP id s74mr8960949ilb.278.1587405398419;  Mon, 20 Apr 2020 10:56:38 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 20 Apr 2020 13:56:28 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000e3356905a3bc9e97"
Archived-At: 
Subject: [OAUTH-WG] April 20th Interim Meeting Minutes
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, 20 Apr 2020 17:59:50 -0000

--000000000000e3356905a3bc9e97
Content-Type: text/plain; charset="UTF-8"

All,

You can find the minutes for this meeting on the following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-05/materials/minutes-interim-2020-oauth-05-202004201200


Thanks to *Jared Jennings *for taking these notes.

Regards,
 Rifaat & Hannes

--000000000000e3356905a3bc9e97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find the minute=
s for this=C2=A0meeting on the following link:

Thanks to Jared Jennings for taking the=
se notes.

Regards,
=C2=A0Rifaat & Ha=
nnes=C2=A0


--000000000000e3356905a3bc9e97--


From nobody Mon Apr 20 14:29:03 2020
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 5A5AC3A10BF for ; Mon, 20 Apr 2020 14:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level: 
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Zf7ADkq4JOzD for ; Mon, 20 Apr 2020 14:28:49 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650131.outbound.protection.outlook.com [40.107.65.131]) (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 B515E3A10BE for ; Mon, 20 Apr 2020 14:28:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gjmWR72JTCHWE5ue8eN2+PSIb8N8wOSlIByLvXrKzzw3TXyoeDJiGAi7K9MqX56p9eURbYElDRBKxph7M4AZC643rlnb/ZOdLTnPx9zUxmZtt+Sm7Jh37mFhRHXO7bujZ8ZfXBSpO+l6KjeP3JAnREBRuHJjL5nYodxfHHF3DLzZYpGMlVSGi2ugl9tf/+gikp/rfIXUa6y3bGFtjIze2suOXiahaN21jQ0zKtFwbIBZ+CjWJvd6Br1RckvFBm/MIx1wiIgVLhagtawiv19Y7FJ9FmLKv+6q/BZ9C++ub8gRj9LrILIqougVSl1jbx88rZ9HaO1pQ5j/YZ+DNMqjew==
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=FqUa3CdVfCVuhcOkzQSlbuB9oW/n1CftQrK+hOpTGB0=; b=l9R2jDQ8CHw3IFPTmonMzMb9I1kCd5HPhLg9NeISfRgGWEE2NaNbwozrIcWeIIh+QmR1FmhQgXVCQONRWRhfkGbDVQ5uWi//XDSRwyEu07M9lcmjlaogKf6J0hJ/bRr5vQvrneCFRfhaQgfkPEesRv0Gy+sbSQtOoplQMi+c9NmW3soE8MMzQhvI6b0rlj96Ucd5jGgL13tTZ8J0RHO3jXseilpYSfB8Xtpm9wV130N9+evAtr0szF5wtXMPAd7JYobd/QGSPsSNguQxntQv4wj8IocrsDsQEXvaR/KRlnVo+Pl9/T7R+/rMwzdVYXkRsRhMXuyiU0B7PAdIiA7trw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FqUa3CdVfCVuhcOkzQSlbuB9oW/n1CftQrK+hOpTGB0=; b=bAL8bFGOnRA920Y8NcswibcGhuBEeB+MXAOUGm8lRhsvLfVffG5llIT3+feBu3zspO59m0nsk99OagQ4kqAXvrPqSg/JdEW2OZeHXrsuZlfppAdCYr0QPXYShwYUVeJ8ZPC8ARQyciPQHsiUZshcfX94dwPgBxDak/7vcmgoiZY=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0761.namprd00.prod.outlook.com (2603:10b6:610:68::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2967.0; Mon, 20 Apr 2020 21:28:47 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276%6]) with mapi id 15.20.2971.000; Mon, 20 Apr 2020 21:28:47 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Caution about open redirectors using the state parameter
Thread-Index: AdYXSOJMqPEgvXlOQI+GZQm5PJwZ3A==
Date: Mon, 20 Apr 2020 21:28:47 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4e3ceca3-921a-43d5-ae73-0000718202cf; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-20T19:20:54Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5e8782ca-5f52-4b12-dbd0-08d7e571cfdb
x-ms-traffictypediagnostic: CH2PR00MB0761:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(52536014)(55016002)(33656002)(71200400001)(82960400001)(82950400001)(86362001)(9686003)(6916009)(8990500004)(2906002)(10290500003)(8936002)(4744005)(66946007)(8676002)(7696005)(66476007)(6506007)(64756008)(66556008)(5660300002)(66446008)(186003)(498600001)(81156014)(26005)(76116006); DIR:OUT; SFP:1102; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WiuYZ4zEjVKehTqG5vlL4dTrJJBDUiQm34sdFT7RJqBwHOHw7web52k0Hk1g2zBIyKTxiKY+3/FsW/WjJISvIK/YaQ+Buh1fdW2TtcdLmUefaKUnrIcOjX9iMEruGjXrhftvrBK6+ZZMDI3Jy7rxKqGBu37EqE4292Kx7kLLp1fSTr1WP1GK5m2t1qimqmb25ddZjtq5GghyOrs/Osc/I4ZsDgumIlNNuLUCB3W8SqbW4nIjtNjTceQi5QeBYXC88luT7xikB58vE6TA5gcbLdNS2eVtihMomBf8kqToSB9ooFT91SfeNlsl9jRfA1BIbDxD4HkZkDKwJxOcUcpsq27Tk3jQXpx877ywEa3h9k4/w+GQ9YHAPFkald2aw2TTol82M+xDYSzUiGENP0J6mC0PJuBvAxnbpx+gEn59R3I1/usCgQdoJOZN4UtGq283
x-ms-exchange-antispam-messagedata: wCe3x1Ib8J4D3PxcVDNzX2IBuWhENZEMiSVlTQ7rfAjxLYaCdABKIXfiCisVSheL7w9VP+mVM5yWJ3F26w/pJfqb/+i8FiUe2OFuS6vp3frE+zt0iFZyUs18PuxXjJ5WDasq1qU2B4+P2z84urVuH/3fho068kV4UeU/km0M50eyzQkb/8/N5EbXi/PPx8X+57A68pTVS15e7hnrwZtnMJ//3RfrKiAlEnGxgTykkgyCvXVyvPA2L2yORJNwIZfNjTNf4+EbImq8Yuh3gptHHAJ83od/9KXt2tUo89qSR2QU3pp2DPnmN/PggMF1ZfFFGiavQP8qvj+HgeVkZbh+nIljAghyz1ULOlsgRm3S3Hb/IzharyKGKLvqBLtCVgAWZSJMPDi2WdWtktAmovwJ4tYCSSA/IZ/R5Vxx1bVr6kphEWK8JT7K02UX1ADGsw2TKcv2BHJ0vzM4BFybBjVLpbpwCFxLuJUqP6t4gH/+FVF+kzb/QA0bMvXc42G8pOLhtY5PAixocg+jw6r+K1ZbkZOVnFLLYDe2p7HwMKEG9Ni7cAbsiaKJcILjvJveBW66dCdJY1L94sn61tOnF0bBC9nBkg2l7jnIwwknNTTAhm2KzycP92ZAOiw6RN67wOkKfzuSbluA4VRcYqgpRm9bM9zgOlBfKO0zc5y2l1fJ1jf1itgDCVRfdzbROE/y/JwJJXAD+VGO1DNrgKEpwdtuf/kjalxc50hPaZFoayMwIdFcMEkXU1em+ATDs27+spL6aItVtUNvX62H+9Sm6zWsDsEXmg6wXLrQe6uWuu6IC68=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678578C4FDBDCD7D5EA8AFBF5D40CH2PR00MB0678namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e8782ca-5f52-4b12-dbd0-08d7e571cfdb
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 21:28:47.6407 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qrmCFWnhZpbKm4gyiampc+eY5tV+yRfpNJj2FaYjvYnCfBskilXeE7VCGXBRyXGYBvYOQJZf1Avw93tYvDM4BA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0761
Archived-At: 
Subject: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 20 Apr 2020 21:29:02 -0000

--_000_CH2PR00MB0678578C4FDBDCD7D5EA8AFBF5D40CH2PR00MB0678namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've seen several circumstances where "clever" clients implement an open re=
director by encoding a URL to redirect to in the state parameter value.  At=
tackers can then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in draft-ietf-oa=
uth-security-topics?

                                                       Thanks,
                                                       -- Mike


--_000_CH2PR00MB0678578C4FDBDCD7D5EA8AFBF5D40CH2PR00MB0678namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I’ve seen several circumstances where “c=
lever” clients implement an open redirector by encoding a URL to redi=
rect to in the state parameter value.  Attackers can then utilize this=
 open redirector by choosing a state value.


 


Can we please add an explicit prohibition of this pr=
actice in draft-ietf-oauth-security-topics?


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        Thanks,


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        -- Mike


 






--_000_CH2PR00MB0678578C4FDBDCD7D5EA8AFBF5D40CH2PR00MB0678namp_--


From nobody Mon Apr 20 22:54:40 2020
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 05BFE3A0A51 for ; Mon, 20 Apr 2020 22:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level: 
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nsTECPSIDxs for ; Mon, 20 Apr 2020 22:54:30 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 C56443A0A64 for ; Mon, 20 Apr 2020 22:54:29 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id v18so5999448qvx.9 for ; Mon, 20 Apr 2020 22:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=rV/Cxv40bMifdetXGCdDqkgRSkpb4qzzRJ3Yg1rOiuU=; b=Jw7QBReY/wkti346INhxtnNfdxiPL/MMS+e6SXIxOwDlhx6ZOYJJIpmE8MxXdcPbwD Jky0rhfNiAxN6h04mLdUB4nslZFiVB83TpgOjSSetifzo7GjWvwhbHcnA5eUGKIh/01G VzxP2Oiv6UHpWHcRvw5vHj9J1PuBRvVF+vkJq8ceQYllQyfqc/s/DpUKrOEvUeixse1T TwGWSEkTYbHbLRFi13ezvY1kmG+bQEV3oXcSNxZN5xEKYwKxTl8Nf0MDZvl2fvq55Ejm vehckL0LGDWJNoTivDmMQ2baf9HUCqj+2rU+5xKtNC4xaaWlA5m3nE4ltK26leLl1bfG 0JGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=rV/Cxv40bMifdetXGCdDqkgRSkpb4qzzRJ3Yg1rOiuU=; b=RQkaCj+GTyXjYWID+Sa2XwrI1KQNamXem6puF1c4K6nIWFJE/ruc/baG/argxUIMzB f/MRembaZFYpmhh/CgnHdz/vOjaZs+5qem+cMJYw1MxUiqTK1y+Dl/7PxV5LLj21peVO CGu6EPkLt5Qoswd3ozscS9a272BUK7s0MrjBFnwFBSbq6LMgGnAvBJVowBrtI+xqXA0W KFNB6fCFe8XqlL6B5b6pdjR9/sEdOEa6QXjGVhgklGqsDz9PZIUvSIVWhvo86NK10EwL PBidSYL8t3gItXbEMx2VWtNFzM+pXr8dvK7YNOe7xRM/a3MsiQsUIAUodbmdUkwManhP Yqsw==
X-Gm-Message-State: AGi0PuZa7SGp2NGf9Il6Ruk+nKTyJzuSsrsgelzUdgDdlQ/3nVgeE8bg CoE6zkzbWMUvwAMPpKC6rP/5Y2aQNxy69PEluxWrUJ8=
X-Google-Smtp-Source: APiQypIaonlQay6t2iRr4MT15X4v7mND3Pz/+RSJrPo6TmU05EtFggpdxwSyBEQYCxiZJbwKNaFeS3EexrxAVY5KlKg=
X-Received: by 2002:ad4:4d06:: with SMTP id l6mr4996069qvl.34.1587448467936; Mon, 20 Apr 2020 22:54:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 21 Apr 2020 01:54:26 -0400
From: Dominick Baier 
In-Reply-To: <085301d616e8$21029750$6307c5f0$@auth0.com>
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>
MIME-Version: 1.0
Date: Tue, 21 Apr 2020 01:54:26 -0400
Message-ID: 
To: oauth , Rifaat Shekh-Yusef , vittorio.bertocci@auth0.com
Content-Type: multipart/alternative; boundary="00000000000007eb4405a3c6a66b"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 05:54:38 -0000

--00000000000007eb4405a3c6a66b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.


Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?

There=E2=80=99s some language that seems to imply that, e.g.:

as this would allow malicious
   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -

In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.


If this spec is about interop, I think this should be at least a
recommendation...


=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (
vittorio.bertocci@auth0.com) wrote:

Thanks Dominick for your comments!

Inline



*>** All other OAuth specs make a very clear distinction between users and
client.*

There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In previou=
s
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that=
=E2=80=99s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, =E2=80=9CIn case =
of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.=E2=80=9C and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.



*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.



*>** I am not fully clear why aud is required.*

Aud is there mostly because of three reasons:

   - Many existing specs postulate its existence in the token. No one
   declares it as a proper MUST (apart from the BCP, but that=E2=80=99s par=
tial)
   however I think its importance comes across..
   -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
   mechanism to prevent token redirect (and adds scope restriction as also
   important, however here we make it optional to acocut for non-delegation=
s
   scenario).
   -Resource indicators RFC8707 refers to the same section of RFC7519 as
   one of the assumptions that must hold to prevent bearer tokens misuse
   -BCP225 makes aud mandatory for AS which can issue JWTs for more than
   one app
   - Apart from Ping, for which some of its examples are without aud (but
   also without identifying scopes, given that the one I retrieved had only
   =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from ven=
dors all featured
   an aud. I know one shoulnd=E2=80=99t overindex on those examples, but to=
gether with
   the above it seemed to point to something universally useful. One possib=
le
   reason is that use of a format for the AT is correlated with topologies
   where AS and RS are separated by some boundary (network, logical, busine=
ss,
   code factoring, etc) hence identifying the resource seems like a natural
   need. Again, not an iron clad law, but an indication.
   - A lot of people repurpose existing libraries for the JWT AT case, and
   some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t me=
an that we
   should condone any bad practices, but in tis particular case it suggests
   that lots of developers already expect/can handle an audience in the JWT
   used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
the presence of scopes or other disambiguation. One reason I feel pretty
good about that is that adding a default audience isn=E2=80=99t very hard i=
f any of
the above assumptions end up not being true for a particular case



*> What=E2=80=99s the rationale for using iat instead of nbf. *

That=E2=80=99s just straight from OIDC ID_tokens, and the considerations ab=
out
repurposing existing logic. I see there=E2=80=99s a thread on this specific=
ally,
let me answer further on that branch.



*> This spec feels somehow in between a profile and a BCP*

You are right that this spec attempts to go beyond just declaring a layout,
and I agree this means that this profile will not apply to absolutely
everyone. The reason I tried that route (at the cost of working way harder
in the last year for reaching consensus than if we would have just listed
the possible content), is that I often observe implementers make
questionable choices because of the large leeway specifications allow. My
hope was that the scope of this profile was small enough to make that extra
level of guidance achievable, whereas trying to do the same with a larger
spec would have been prohibitively expensive.

I believe things worked out well so far: we had lots of constructive
discussions, and I ended up relaxing A LOT of the constraints I was
originally envisioning. Nonetheless, my hope is that we identified the
right set of guidelines that will help people actually interoperate out of
the box for the most basic/common scenarios, as opposed to complying with
the letter of the spec but still having a lot to figure out out of band.



*From:* OAuth  *On Behalf Of *Dominick Baier
*Sent:* Thursday, April 16, 2020 12:10 AM
*To:* Rifaat Shekh-Yusef ; oauth 
*Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"



Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.



*client_id vs sub*

I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of th=
e claim types
based on flow.

If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but

this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).



All other OAuth specs make a very clear distinction between users and
client.



Furthermore it says



"Authorization servers should prevent scenarios where clients can

   affect the value of the sub claim in ways that could confuse resource

   servers.=E2=80=9D



If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.



Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.



*audience claim*

I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don=E2=80=99t exist, you'=
d need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What=E2=80=99s =
the
value of that?



If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn=E2=80=99t make it required.



*iat vs nbf*

What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t m=
ost JWT
libraries (including e.g. the .NET one) looking for nbf by default?



*General*

This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn=E2=80=99=
t work
one way or the other for them.



I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.



Tbh - the most valuable part of the doc to me is the definition of the
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see j=
ust some standard claims
and IF they are used, which semantics they have.



cheers

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier



On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
wrote:

Hi all,



This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



Please send your comments to the OAuth mailing list by April 29, 2020.



Regards,

 Rifaat & Hannes



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

--00000000000007eb4405a3c6a66b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

In case of access tokens obtained through grants where no resource=
 owner is involved, such as the client credentials grant, the value of sub =
SHOULD correspond to an identifier the authorization server uses to indicat=
e the client application.
 

Maybe I am=
 missing something, but does it say anywhere what to explicitly do in the c=
ase of an access token where a resource owner is involved?


--00000000000007eb4405a3c6a66b--


From nobody Tue Apr 21 00:43:56 2020
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 E961F3A0765 for ; Tue, 21 Apr 2020 00:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 Sccfqal_jW8K for ; Tue, 21 Apr 2020 00:43:49 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 83DB13A0763 for ; Tue, 21 Apr 2020 00:43:49 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id k18so4954557pll.6 for ; Tue, 21 Apr 2020 00:43:49 -0700 (PDT)
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 :mime-version; bh=O29IRXJQuihTYViwJGN3E8iWJkT1Y44A/Rwu9keGOuw=; b=bB8jMlhzpaezcCWFvKSZe5I4X2YlJFua26Zi4N83x7bq0J6wWHE9LhG0Af4OThMNPY 6H0jcut0VtQ9VNUAmBih8N+mi/wHdzGvqJzF9WO9BV3oLhuWbrMj1S9tkBqi/Uv7R3tk /smHzm2sKQplPwHFhWR3XGAHEWn8X5qLJCJl2t55sS2w2O7Em/IqSHznyQoI5X3UuvXK Jeo37VOxBfdZJYGw3e5D+bRBGfzFSB0F4d2e6+EmL/1rIHZDvpnktZ2JlkK+Pd41XXzr 0JhOZdf2C9rbJHu4qgLevW02AASu0V3IX5wYRoRKEtl2Xza+CpAnPavSxW5xDuc8V6LQ uwKw==
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 :mime-version; bh=O29IRXJQuihTYViwJGN3E8iWJkT1Y44A/Rwu9keGOuw=; b=lvLtEGy8s9KmSLYZjch5u6IcO0UB14/iGVWlpaAaeo5sklYRMuGvkGtn0lWI4+uyQw ak1BNMhDnGd4DJPMalN5s3C1Hqw5560oNs9hBxrjE1G2WLoTnKo0GvYPTil3EoO3yoBc MNVbCjUR/audtbztRN2qBxQjRsBgQF+xT5WjYuk4JP5hEdA2H4FmudewM6t7yu4bR172 VHLzPlxgwA8GkI4+ELakrE87uxYw68P0zDruIuaXCRGKefZCVN6dUKP0qrOlfouJwPFh xRJ3W48giw5rwupvu5JtokecleFNGJw7PINylxF3qmXmEEEi5V3dgrsEYExd+B+Vxy9P KwwQ==
X-Gm-Message-State: AGi0PuYWp6rfzPek23ccC0I79diRY/w+dvrrdX4of5gNjWTPHkhyd4Ru ItrfrkyLmdyByie2O8oebTsmPpVe8dc=
X-Google-Smtp-Source: APiQypLqlW7u4+h7av1+2EoMFKz8++sDg2mnH1hTzgVg5UB5tDWcxb8kIA8L+3xurg5DQq2WBoAuUg==
X-Received: by 2002:a17:902:a50a:: with SMTP id s10mr19218749plq.164.1587455028774;  Tue, 21 Apr 2020 00:43:48 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id d14sm1668328pfr.35.2020.04.21.00.43.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 00:43:48 -0700 (PDT)
From: Vittorio Bertocci 
To: Dominick Baier , oauth , Rifaat Shekh-Yusef 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AUFRa29UzLyu7kLPs7J/StHwRJR9eGcyK001JDA3JGRnOGNUM6H3tCBr
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 21 Apr 2020 07:43:47 +0000
Message-ID: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com> 
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: multipart/alternative; boundary="_000_MWHPR19MB15017E10AD0880993F02B44CAED50MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 07:43:55 -0000

--_000_MWHPR19MB15017E10AD0880993F02B44CAED50MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This is a great point. In my head I just considered the OIDC semantic and t=
hought only of highlighting the app identity case, but you are absolutely r=
ight that not mentioning the user case at all is confusing. I added the lan=
guage you suggested at the beginning of the sub definition.
Thanks!

From: Dominick Baier 
Date: Monday, April 20, 2020 at 22:54
To: oauth , Rifaat Shekh-Yusef , "vi=
ttorio.bertocci@auth0.com" 
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"


In case of access tokens obtained through grants where no resource owner is=
 involved, such as the client credentials grant, the value of sub SHOULD co=
rrespond to an identifier the authorization server uses to indicate the cli=
ent application.

Maybe I am missing something, but does it say anywhere what to explicitly d=
o in the case of an access token where a resource owner is involved?

There=92s some language that seems to imply that, e.g.:


as this would allow malicious

   clients to select the sub of a high privilege resource owner
I would have expected to see something stronger like above just -


In case of access tokens obtained through grants where a resource owner is =
involved, such as the authorisation code grant, the value of sub SHOULD cor=
respond to the subject identifier of the resource owner.

If this spec is about interop, I think this should be at least a recommenda=
tion...


=97=97=97
Dominick Baier


On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:
Thanks Dominick for your comments!
Inline

> All other OAuth specs make a very clear distinction between users and cli=
ent.
There=92s a nuance worth highlighting here: sub !=3D user. In previous disc=
ussions on this topic it has been brought up that the JWT spec defines sub =
as identifying the principal that is the subject of the JWT, and that=92s n=
ot necessarily limited to users.

However I get the potential confusion, and I am happy to add clarifying lan=
guage if you have specific passages in the space you are particularly worri=
ed about: however I feel the matter is addressed upfront by the language in=
 Section 2.2. in the sub entry, =93In case of access tokens obtained throug=
h grants where no resource owner is involved, such as the client credential=
s grant, the value of sub SHOULD correspond to an identifier the authorizat=
ion server uses to indicate the client application.=93 and Section 5 has an=
 entire paragraph discussing things to watch out in assigning sub values in=
 the app identity case. Feel free to suggest additional language if you wan=
t to clarify further.

> sub has a different semantic here as in OIDC
The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,=
 to preempt that concern and keep the original sub semantic available.

> I am not fully clear why aud is required.
Aud is there mostly because of three reasons:

=B7         Many existing specs postulate its existence in the token. No on=
e declares it as a proper MUST (apart from the BCP, but that=92s partial) h=
owever I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp

=B7         Apart from Ping, for which some of its examples are without aud=
 (but also without identifying scopes, given that the one I retrieved had o=
nly =93openid=94), all of the sample JWT ATs I received from vendors all fe=
atured an aud. I know one shoulnd=92t overindex on those examples, but toge=
ther with the above it seemed to point to something universally useful. One=
 possible reason is that use of a format for the AT is correlated with topo=
logies where AS and RS are separated by some boundary (network, logical, bu=
siness, code factoring, etc) hence identifying the resource seems like a na=
tural need. Again, not an iron clad law, but an indication.

=B7         A lot of people repurpose existing libraries for the JWT AT cas=
e, and some people even sends id_tokens in lieu of ATs. That doesn=92t mean=
 that we should condone any bad practices, but in tis particular case it su=
ggests that lots of developers already expect/can handle an audience in the=
 JWT used to call their API
None of those are a slam dunk argument for mandatory, but I find them compe=
lling enough to simplify validation and just require an aud to be there, as=
 opposed to introduce complications that make it conditional to the presenc=
e of scopes or other disambiguation. One reason I feel pretty good about th=
at is that adding a default audience isn=92t very hard if any of the above =
assumptions end up not being true for a particular case

> What=92s the rationale for using iat instead of nbf.
That=92s just straight from OIDC ID_tokens, and the considerations about re=
purposing existing logic. I see there=92s a thread on this specifically, le=
t me answer further on that branch.

> This spec feels somehow in between a profile and a BCP
You are right that this spec attempts to go beyond just declaring a layout,=
 and I agree this means that this profile will not apply to absolutely ever=
yone. The reason I tried that route (at the cost of working way harder in t=
he last year for reaching consensus than if we would have just listed the p=
ossible content), is that I often observe implementers make questionable ch=
oices because of the large leeway specifications allow. My hope was that th=
e scope of this profile was small enough to make that extra level of guidan=
ce achievable, whereas trying to do the same with a larger spec would have =
been prohibitively expensive.
I believe things worked out well so far: we had lots of constructive discus=
sions, and I ended up relaxing A LOT of the constraints I was originally en=
visioning. Nonetheless, my hope is that we identified the right set of guid=
elines that will help people actually interoperate out of the box for the m=
ost basic/common scenarios, as opposed to complying with the letter of the =
spec but still having a lot to figure out out of band.

From: OAuth > On Beha=
lf Of Dominick Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: Rifaat Shekh-Yusef =
>; oauth >
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

Since this is the last call, I thought I bring up some of thoughts / concer=
ns. Some of them have been discussed before.

client_id vs sub
I am still not entirely happy with the =93re-purposing=94 of the claim type=
s based on flow.
If the intention is, that sub expresses the entity against which the resour=
ce will do authorisation (and that might be a client or a user) - I get it =
(and maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there was no distinction =
between user and service accounts (something that has been fixed IIRC in Wi=
ndows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and clien=
t.

Furthermore it says

"Authorization servers should prevent scenarios where clients can
   affect the value of the sub claim in ways that could confuse resource
   servers.=94

If we keep that dual semantics of the sub claim - it must be clearly stated=
, that subject ID and client ID are now in the same collision domain. So wh=
en an AS / OP creates them, they need to be unique across user ids and clie=
nt ids.

Maybe it should be also explicitly mentioned that sub has a different seman=
tic here as in OIDC - even though a majority of the software built today wi=
ll use them together.

audience claim
I am not fully clear why aud is required. OAuth itself does not have a noti=
on of an audience (in the JWT sense) - they have scopes (which is very simi=
lar). But in simple scenarios where resources don=92t exist, you'd need to =
make up an audience just to fulfil this requirement. And in many case this =
will be either static or just repeat the scope values. What=92s the value o=
f that?

If the concept of resources are used, I absolutely agree that aud should be=
 used too. But I wouldn=92t make it required.

iat vs nbf
What=92s the rationale for using iat instead of nbf. Aren=92t most JWT libr=
aries (including e.g. the .NET one) looking for nbf by default?

General
This spec feels somehow in between a profile and a BCP. On one hand you def=
ine some claims and their semantics (good) - on the other hand there is som=
e prescriptive guidance and maybe over-specification. My concern is, that i=
n the end no-one will fully comply with it, because it doesn=92t work one w=
ay or the other for them.

I know we just went though the discussion to make certain claims required a=
s opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the =93a=
t+jwt=94 typ. For the rest I=92d rather like to see just some standard clai=
ms and IF they are used, which semantics they have.

cheers
=97=97=97
Dominick Baier


On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:
Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile =
for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes

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

--_000_MWHPR19MB15017E10AD0880993F02B44CAED50MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the user case at all is con=
fusing. I added the language you suggested
 at the beginning of the sub definition.


Thanks!


 




From=
: Dominick Baier &l=
t;dbaier@leastprivilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oauth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf=
@gmail.com>, "vittorio.bertocci@auth0.com" <vittorio.bertoc=
ci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 






In case of access tokens obtained through grants where no re=
source owner is involved, such as the client credentials grant, the value o=
f sub SHOULD correspond to an identifier the authorization server uses to i=
ndicate the client application.






 






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






 






There=92s some language that seems to imply that, e.=
g.:






 






as this would all=
ow malicious


   clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just - 






 






In cas=
e of access tokens obtained through grants where a resource owner is involv=
ed, such as the authorisation code grant, the value of sub SHOULD correspon=
d to the subject identifier of the resource owner.






 






If this spec is about interop, I think this should b=
e at least a recommendation...






 




 




=97=97=97 




Dominick Baier






 


On 20. April 2020 at 09:48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


 


> All other OAuth specs make a very clear distinction between users and c=
lient.


There=92s a nuance worth highlighting here: sub !=3D user. In prev=
ious discussions on this topic it has been brought up that the JWT spec def=
ines sub as identifying the principal that
 is the subject of the JWT, and that=92s not necessarily limited to users. =



However I get the potential confusion, and I am happy to add clarifyi=
ng language if you have specific passages in the space you are particularly=
 worried about: however I feel the matter is addressed upfront by the langu=
age in Section 2.2. in the sub entry, =93In case of access tokens obtained through grants where no=
 resource owner is involved, such as the client credentials grant, the valu=
e of sub SHOULD correspond to an identifier the authorization server uses t=
o indicate the client application.=93 and Section 5 has=
 an entire paragraph discussing things to watch out in assigning sub values=
 in the app identity case. Feel free to suggest additional language if you =
want to clarify further. 


 


> sub=
 has a different semantic here as in OIDC


The  spec refers to RFC7519 in the sub definition in 2.2, rat=
her than OIDC, to preempt that concern and keep the original sub semantic a=
vailable.


 


> I am not fully clear why aud is required.


Aud is there mostly because of three reasons:



=B7        
Many existing specs postulate its existence =
in the token. No one declares it as a proper MUST (apart from the BCP, but =
that=92s partial) however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp



=B7        
Apart from Ping, for which some of its examp=
les are without aud (but also without identifying scopes, given that the on=
e I retrieved had only =93openid=94), all of the sample JWT ATs I received =
from vendors all featured an aud. I
 know one shoulnd=92t overindex on those examples, but together with the ab=
ove it seemed to point to something universally useful. One possible reason=
 is that use of a format for the AT is correlated with topologies where AS =
and RS are separated by some boundary
 (network, logical, business, code factoring, etc) hence identifying the re=
source seems like a natural need. Again, not an iron clad law, but an indic=
ation.



=B7        
A lot of people repurpose existing libraries=
 for the JWT AT case, and some people even sends id_tokens in lieu of ATs. =
That doesn=92t mean that we should condone any bad practices, but in tis pa=
rticular case it suggests that lots
 of developers already expect/can handle an audience in the JWT used to cal=
l their API


None of those are a slam dunk argument for mandatory, but I find t=
hem compelling enough to simplify validation and just require an aud to be =
there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
. One reason I feel pretty good about that is that adding a default audienc=
e isn=92t very hard if any of the above assumptions end up not being true f=
or a particular case


 


> Wha=
t=92s the rationale for using iat instead of nbf.



That=92s just straight from OIDC ID_tokens, and the considerations=
 about repurposing existing logic. I see there=92s a thread on this specifi=
cally, let me answer further on that branch.


 


> Thi=
s spec feels somehow in between a profile and a BCP

You are right that this spec attempts to go beyond just declaring =
a layout, and I agree this means that this profile will not apply to absolu=
tely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots of constructi=
ve discussions, and I ended up relaxing A LOT of the constraints I was orig=
inally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



 






From: OAuth <o=
auth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <=
rifaat.ietf@gmail.com>; oauth <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 




Since this =
is the last call, I thought I bring up some of thoughts / concerns. Some of=
 them have been discussed before.






 






client_i=
d vs sub






I am still =
not entirely happy with the =93re-purposing=94 of the claim types based on =
flow.






If the inte=
ntion is, that sub expresses the entity against which the resource will do =
authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinki=
ng reminds me of the old AD days where there was no distinction between use=
r and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






 






All other O=
Auth specs make a very clear distinction between users and client.






 






Furthermore=
 it says






 






"Autho=
rization servers should prevent scenarios where clients can






  &nbs=
p;affect the value of the sub claim in ways that could confuse resource






  &nbs=
p;servers.=94






 






If we keep =
that dual semantics of the sub claim - it must be clearly stated, that subj=
ect ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






 






Maybe it sh=
ould be also explicitly mentioned that sub has a different semantic here as=
 in OIDC - even though a majority of the
 software built today will use them together.






 






audience=
 claim






I am not fu=
lly clear why aud is required. OAuth itself does not have a notion of an au=
dience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=92t exist, you'd need to make up an audience just to fulfil this requirem=
ent. And in many case this will be either static or just repeat the scope v=
alues. What=92s the value of that?






 






If the conc=
ept of resources are used, I absolutely agree that aud should be used too. =
But I wouldn=92t make it required.






 






iat vs n=
bf






What=92s th=
e rationale for using iat instead of nbf. Aren=92t most JWT libraries (incl=
uding e.g. the .NET one) looking for nbf by
 default?






 






General<=
/span>






This spec f=
eels somehow in between a profile and a BCP. On one hand you define some cl=
aims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=92t work one way or the other for them.






 






I know we j=
ust went though the discussion to make certain claims required as opposed t=
o optional - but maybe less is more.






 






Tbh - the m=
ost valuable part of the doc to me is the definition of the =93at+jwt=
=94 typ. For the rest I=92d rather like to see just
 some standard claims and IF they are used, which semantics they have.






 




cheers =
;




=97=97=97




Dominick Ba=
ier






 


On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:










Hi all,



 



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



 



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06=




 



Please send your comments to the OAuth mailing list by April 29, 2020.=




 



Regards,



 Rifaat & Hannes



 




___________=
____________________________________


OAuth mailing list 

OAuth@ietf.org 

https://www.ietf.or=
g/mailman/listinfo/oauth





















--_000_MWHPR19MB15017E10AD0880993F02B44CAED50MWHPR19MB1501namp_--


From nobody Tue Apr 21 06:13:09 2020
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 CE3A73A0C04 for ; Tue, 21 Apr 2020 06:13:07 -0700 (PDT)
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=pingidentity.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-TdNPwITkJ3 for ; Tue, 21 Apr 2020 06:13:06 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 A6AD53A0C0B for ; Tue, 21 Apr 2020 06:13:05 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id a21so601498ljb.9 for ; Tue, 21 Apr 2020 06:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZ4wd9Riq8CzLZG+ci6FBmrIBrDnp0zJ4bAyTiWzQYs=; b=Kmq3UM1So6tIqNqhweBoxCzOXJgSwEPSEfmC6aZ9INxl2MD88oHu32oweVRhqqJAFD NaAew64ujoxxAf72Ll8qJaCfhq2WN9LkwvHfRWJEh78v+LbwAG4+yWNGgwPwWe6gnDWl znLBRHvWxm58I0MNiHByRYqJicixlJkWYW+4NWIunRweHV7ki4PU95D5qkhorXls9HAV fFrKJojDhWLaQnjL/tJ+0zTG8QZSxjJ//OV4uXD+Iq5iB2lwGZAFBg+Ow3U9tc/PvjNq UWvVBOw7at8LZU0w4CjDTX4+EWjPiVfelNjfhsyrXXI9ZbAL83npxCY9sYaTZJkztOam 0k6A==
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=JZ4wd9Riq8CzLZG+ci6FBmrIBrDnp0zJ4bAyTiWzQYs=; b=UtPUSvghU8gTTu60N7pp1zlEPFEdQ/1wRCWY0X2IwPxHv6xtJhWUZQz0vtxT6llkUP zmbEnv/aA8QP8SP2wE5XdRDcCnOtyV4BOiNscyUxUx7ctQkwfmKimWFc5RaXSB4mvFTX WbHxMaheHyow0nYzMYzCxE0SXtVlVhuTknUb5yEB0WrxpNaakAXQzUg/cZjR64UZ6z+W hJo9zL9aOCkjV5hhvIRa89p0MDoY6xb2YEy7R4KHsEbUsvwJN3696OKqCBVUKYRFhlKd opIGf+F8vFYlpK0750IhZzzbBwnqyL9tkbcC4fvy4Z+o7tDE4HfTZCGHtL4s11dMIN8C V5Cg==
X-Gm-Message-State: AGi0PuboDf3lcWO3IiDVmhWbzjrW+msnKQey9mdLI8mLs2ixtdiRsQZo k//9S6J5GnlOuk0i8F/v6P7Aim+VORZh3ohu5T39KOzQFEBFCSsnJ02fT33IMHSMICzcgqldLVi 24jPWCaCb/kS9pgO+z9U=
X-Google-Smtp-Source: APiQypIUH59p6lY0+oSyV9jH3hYqsLUvHhy2g+otlC2AHgiaQ7ZK0Wzn49ATBrUZAfddK6VUxN4oa2KgDYZAJK/OJhU=
X-Received: by 2002:a2e:3813:: with SMTP id f19mr12977100lja.216.1587474783812;  Tue, 21 Apr 2020 06:13:03 -0700 (PDT)
MIME-Version: 1.0
References: <158732102285.31467.551848692555230905@ietfa.amsl.com> 
In-Reply-To: 
From: Brian Campbell 
Date: Tue, 21 Apr 2020 07:12:37 -0600
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000947cdb05a3ccc63b"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.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: Tue, 21 Apr 2020 13:13:08 -0000

--000000000000947cdb05a3ccc63b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd agree that Vladimir's proposed wording is more meaningful/helpful.

On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvinov 
wrote:

> Nat, John, thanks for updating the JAR spec. I just reviewed it, in
> particular the authz request and the security considerations sections.
> Choosing to make client_id (as top-level parameter) mandatory for all
> cases, even for those when it can be readily extracted from the JWT, make=
s
> the job of implementers even easier.
>
>
> I have just one comment about the last paragraph in section 5, assuming
> backward compatibility means with RFC6749 requests. Here is my proposed
> wording:
>
> The client MAY send the parameters included in the request object
> duplicated in the query parameters. For instance, this can be done
> to ensure the minimal required query parameters for an OAuth 2.0
> [RFC6749] authorization request are also present. An authorization
> server supporting this specification MUST however only use the
> parameters included in the request object.
>
>
> Vladimir
>
>
> On 19/04/2020 21:30, 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           : The OAuth 2.0 Authorization Framework: JWT Secu=
red Authorization Request (JAR)
>         Authors         : Nat Sakimura
>                           John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-21.txt
> 	Pages           : 31
> 	Date            : 2020-04-19
>
> Abstract:
>    The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>    query parameter serialization, which means that Authorization Request
>    parameters are encoded in the URI of the request and sent through
>    user agents such as web browsers.  While it is easy to implement, it
>    means that (a) the communication through the user agents are not
>    integrity protected and thus the parameters can be tainted, and (b)
>    the source of the communication is not authenticated.  Because of
>    these weaknesses, several attacks to the protocol have now been put
>    forward.
>
>    This document introduces the ability to send request parameters in a
>    JSON Web Token (JWT) instead, which allows the request to be signed
>    with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>    (JWE) so that the integrity, source authentication and
>    confidentiality property of the Authorization Request is attained.
>    The request can be sent by value or by reference.
>
>
> The IETF datatracker status page for this draft is:https://datatracker.ie=
tf.org/doc/draft-ietf-oauth-jwsreq/
>
> There are also htmlized versions available at:https://tools.ietf.org/html=
/draft-ietf-oauth-jwsreq-21https://datatracker.ietf.org/doc/html/draft-ietf=
-oauth-jwsreq-21
>
> A diff from the previous version is available at:https://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-oauth-jwsreq-21
>
>
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000947cdb05a3ccc63b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'd agree that Vladimir's proposed wording is more=
 meaningful/helpful. 

On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvino=
v <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  

    
Nat, John, thanks for updating the JAR spec. I just reviewed it,
      in particular the authz request and the security considerations
      sections. Choosing to make client_id (as top-level parameter)
      mandatory for all cases, even for those when it can be readily
      extracted from the JWT, makes the job of implementers even easier.
    


    

    
I have just one comment about the last paragraph in section 5,
      assuming backward compatibility means with RFC6749 requests. Here
      is my proposed wording:

    
The client MAY send the parameters included in the request object=
=20
duplicated in the query parameters. For instance, this can be done=20
to ensure the minimal required query parameters for an OAuth 2.0=20
[RFC6749] authorization request are also present. An authorization=20
server supporting this specification MUST however only use the=20
parameters included in the request object.

    


    

    
Vladimir

    

    


    

    
    

      
A New Internet-Draft is available from the on-line Internet-Draf=
ts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : The OAuth 2.0 Authorization Framework: JWT Secure=
d Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-21.txt
	Pages           : 31
	Date            : 2020-04-19

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
   (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-=
jwsreq-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsr=
eq-21


Please note that it may take a couple of minutes from the time of submissio=
n
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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000947cdb05a3ccc63b--


From nobody Tue Apr 21 10:24:12 2020
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 C43553A0821 for ; Tue, 21 Apr 2020 10:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv2BTvTm39MY for ; Tue, 21 Apr 2020 10:24:03 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 6FAB53A0810 for ; Tue, 21 Apr 2020 10:23:59 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id w29so12260489qtv.3 for ; Tue, 21 Apr 2020 10:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=l6j/+LwdtEYH/OoljeTi9wjcIvDTY7eLkCBiMnSIYv4=; b=Eu9ocMiMJXD9JBJfluIYmUium1Gl7QDKhP1TNrJ7BhvqpUZuvWF/yBuF+aaq6Ydfyi oSLF3OKa3OTidypDIv8D/cTCggkiWz4NlhtCv32XEBfAHnZ8GcQADDfoKtmVTnLKEzCu 3mnFcPrdndSlJvvRSw40G87X0vT6mztsxB1U8GRFt4b60lBTSZHcj9EQYu+oh6ee483z Pk3vD22jllTag7ptj1KpiCQihe/524fkGug8R40egAX0FEHS8cXJpg3L19nSVJWR6+qi fvjUiTieticldaTDhr7f0cVifZt7Wk6mLUEUYiFAKYATahQjlXEraO9IjJjAmZrs50/P n0hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=l6j/+LwdtEYH/OoljeTi9wjcIvDTY7eLkCBiMnSIYv4=; b=ai6l+MtofRm1GUgMrtYt/nLkrMWJ4t3q7iI9i21KlNYGj6SD/nrQjyQ/9homiXMYKW 2UZInhLL6ptmscee5gaJ6xMond+dhOrCkJOdgqVKx3+qhEgLF7SEa07w6t2/er7q+fvk TX4c8+EneEdxgSUehnE0aq5EjM0tDQbaQclUvpfo8ky961hh3u6+mcLOwSqnBxEa4s+R dez8WrB6nV7pxjmkbUvAvG/0NYd0YDRQmt6Zkfhm7mV1V7TN7u7mmmo8xLzpA/RLrFil N7Zg9q3oLL9q6lBUbFNHXzDfFzMYdaIuQiMuMsXeVUbPn2eIDG25uMWdFRlpq2vXTWJl VB/Q==
X-Gm-Message-State: AGi0Pua8Zs5zwvxH04xjgSPMNf6IRJtZ/DREK7u+xzvgvKc2MrqQnJfp MSVCRk+GbRnss5DECmsiz2olvX1NpVbeH7bm3ATHaMM=
X-Google-Smtp-Source: APiQypJ13Lc6NehTcBS4Pim++A0oKg98uL3/HKrUd3VDVFHPjRjiZ6ceY7CU7m4tXq5cPePrIyuPxj/96CWMjT7leiM=
X-Received: by 2002:ac8:6c23:: with SMTP id k3mr22774961qtu.107.1587489836370;  Tue, 21 Apr 2020 10:23:56 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 21 Apr 2020 13:23:55 -0400
From: Dominick Baier 
In-Reply-To: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>  
MIME-Version: 1.0
Date: Tue, 21 Apr 2020 13:23:55 -0400
Message-ID: 
To: oauth , Rifaat Shekh-Yusef ,  Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="000000000000c81d0c05a3d047b8"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 17:24:11 -0000

--000000000000c81d0c05a3d047b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oh and while we are at it - could you also fix the typo in my name? Thanks
;)

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 21. April 2020 at 09:43:49, Vittorio Bertocci (
vittorio.bertocci@auth0.com) wrote:

This is a great point. In my head I just considered the OIDC semantic and
thought only of highlighting the app identity case, but you are absolutely
right that not mentioning the user case at all is confusing. I added the
language you suggested at the beginning of the sub definition.

Thanks!



*From: *Dominick Baier 
*Date: *Monday, April 20, 2020 at 22:54
*To: *oauth , Rifaat Shekh-Yusef , "
vittorio.bertocci@auth0.com" 
*Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"



In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.



Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?



There=E2=80=99s some language that seems to imply that, e.g.:



as this would allow malicious

   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -



In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.



If this spec is about interop, I think this should be at least a
recommendation...





=E2=80=94=E2=80=94=E2=80=94

Dominick Baier



On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (
vittorio.bertocci@auth0.com) wrote:

Thanks Dominick for your comments!

Inline



*>** All other OAuth specs make a very clear distinction between users and
client.*

There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In previou=
s
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that=
=E2=80=99s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, =E2=80=9CIn case =
of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.=E2=80=9C and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.



*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.



*>** I am not fully clear why aud is required.*

Aud is there mostly because of three reasons:

=C2=B7         Many existing specs postulate its existence in the token. No=
 one
declares it as a proper MUST (apart from the BCP, but that=E2=80=99s partia=
l)
however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the
mechanism to prevent token redirect (and adds scope restriction as also
important, however here we make it optional to acocut for non-delegations
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one
of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one
app

=C2=B7         Apart from Ping, for which some of its examples are without =
aud
(but also without identifying scopes, given that the one I retrieved had
only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from v=
endors all
featured an aud. I know one shoulnd=E2=80=99t overindex on those examples, =
but
together with the above it seemed to point to something universally useful.
One possible reason is that use of a format for the AT is correlated with
topologies where AS and RS are separated by some boundary (network,
logical, business, code factoring, etc) hence identifying the resource
seems like a natural need. Again, not an iron clad law, but an indication.

=C2=B7         A lot of people repurpose existing libraries for the JWT AT =
case,
and some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t m=
ean that
we should condone any bad practices, but in tis particular case it suggests
that lots of developers already expect/can handle an audience in the JWT
used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
the presence of scopes or other disambiguation. One reason I feel pretty
good about that is that adding a default audience isn=E2=80=99t very hard i=
f any of
the above assumptions end up not being true for a particular case



*> What=E2=80=99s the rationale for using iat instead of nbf. *

That=E2=80=99s just straight from OIDC ID_tokens, and the considerations ab=
out
repurposing existing logic. I see there=E2=80=99s a thread on this specific=
ally,
let me answer further on that branch.



*> This spec feels somehow in between a profile and a BCP*

You are right that this spec attempts to go beyond just declaring a layout,
and I agree this means that this profile will not apply to absolutely
everyone. The reason I tried that route (at the cost of working way harder
in the last year for reaching consensus than if we would have just listed
the possible content), is that I often observe implementers make
questionable choices because of the large leeway specifications allow. My
hope was that the scope of this profile was small enough to make that extra
level of guidance achievable, whereas trying to do the same with a larger
spec would have been prohibitively expensive.

I believe things worked out well so far: we had lots of constructive
discussions, and I ended up relaxing A LOT of the constraints I was
originally envisioning. Nonetheless, my hope is that we identified the
right set of guidelines that will help people actually interoperate out of
the box for the most basic/common scenarios, as opposed to complying with
the letter of the spec but still having a lot to figure out out of band.



*From:* OAuth  *On Behalf Of *Dominick Baier
*Sent:* Thursday, April 16, 2020 12:10 AM
*To:* Rifaat Shekh-Yusef ; oauth 
*Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"



Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.



*client_id vs sub*

I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of th=
e claim types
based on flow.

If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but

this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).



All other OAuth specs make a very clear distinction between users and
client.



Furthermore it says



"Authorization servers should prevent scenarios where clients can

   affect the value of the sub claim in ways that could confuse resource

   servers.=E2=80=9D



If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.



Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.



*audience claim*

I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don=E2=80=99t exist, you'=
d need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What=E2=80=99s =
the
value of that?



If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn=E2=80=99t make it required.



*iat vs nbf*

What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t m=
ost JWT
libraries (including e.g. the .NET one) looking for nbf by default?



*General*

This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn=E2=80=99=
t work
one way or the other for them.



I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.



Tbh - the most valuable part of the doc to me is the definition of the
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see j=
ust some standard claims
and IF they are used, which semantics they have.



cheers

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier



On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
wrote:

Hi all,



This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



Please send your comments to the OAuth mailing list by April 29, 2020.



Regards,

 Rifaat & Hannes



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

--000000000000c81d0c05a3d047b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Oh a=
nd while we are at it - could you also fix the typo in my name? Thanks ;) 
 
=E2=80=94=E2=80=94=E2=80=94
Do=
minick Baier
 
On 21. April 2020 at 0=
9:43:49, Vittorio Bertocci (=
vittorio.bertocci@auth0.com) wrote:
 










This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the user case at all is con=
fusing. I added the language you suggested
 at the beginning of the sub definition.


Thanks!


=C2=A0




From=
: Dominick Baier &l=
t;dbaier@leastprivilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oauth@ietf.org&g=
t;, Rifaat Shekh-Yusef <rifaat.=
ietf@gmail.com>, "vittorio.bertocci@auth0.com" <vittorio.bertocci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






In case of access tokens obtained through grants where no re=
source owner is involved, such as the client credentials grant, the value o=
f sub SHOULD correspond to an identifier the authorization server uses to i=
ndicate the client application.






=C2=A0






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






=C2=A0






There=E2=80=99s some language that seems to imply th=
at, e.g.:






=C2=A0






as this would all=
ow malicious


=C2=A0=C2=A0 clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just -=C2=A0






=C2=A0






In cas=
e of access tokens obtained through grants where a resource owner is involv=
ed, such as the authorisation code grant, the value of sub SHOULD correspon=
d to the subject identifier of the resource owner.






=C2=A0






If this spec is about interop, I think this should b=
e at least a recommendation...






=C2=A0




=C2=A0




=E2=80=94=E2=80=94=E2=80=94 




Dominick Baier






=C2=A0


On 20. April 2020 at 09:48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


=C2=A0


> All other OAuth specs make a very clear distinction between users and c=
lient.


There=E2=80=99s a nuance worth highlighting here: sub !=3D user. I=
n previous discussions on this topic it has been brought up that the JWT sp=
ec defines sub as identifying the principal that
 is the subject of the JWT, and that=E2=80=99s not necessarily limited to u=
sers. 


However I get the potential confusion, and I am happy to add clarifyi=
ng language if you have specific passages in the space you are particularly=
 worried about: however I feel the matter is addressed upfront by the langu=
age in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained through grants wh=
ere no resource owner is involved, such as the client credentials grant, th=
e value of sub SHOULD correspond to an identifier the authorization server =
uses to indicate the client application.=E2=80=9C and S=
ection 5 has an entire paragraph discussing things to watch out in assignin=
g sub values in the app identity case. Feel free to suggest additional lang=
uage if you want to clarify further. 


=C2=A0


> sub=
 has a different semantic here as in OIDC


The =C2=A0spec refers to RFC7519 in the sub definition in 2.2, rat=
her than OIDC, to preempt that concern and keep the original sub semantic a=
vailable.


=C2=A0


> I am not fully clear why aud is required.


Aud is there mostly because of three reasons:



=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Many existing specs postulate its existence in the tok=
en. No one declares it as a proper MUST (apart from the BCP, but that=E2=80=
=99s partial) however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp



=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Apart from Ping, for which some of its examples are wi=
thout aud (but also without identifying scopes, given that the one I retrie=
ved had only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I receive=
d from vendors all featured an aud. I
 know one shoulnd=E2=80=99t overindex on those examples, but together with =
the above it seemed to point to something universally useful. One possible =
reason is that use of a format for the AT is correlated with topologies whe=
re AS and RS are separated by some boundary
 (network, logical, business, code factoring, etc) hence identifying the re=
source seems like a natural need. Again, not an iron clad law, but an indic=
ation.



=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
A lot of people repurpose existing libraries for the J=
WT AT case, and some people even sends id_tokens in lieu of ATs. That doesn=
=E2=80=99t mean that we should condone any bad practices, but in tis partic=
ular case it suggests that lots
 of developers already expect/can handle an audience in the JWT used to cal=
l their API


None of those are a slam dunk argument for mandatory, but I find t=
hem compelling enough to simplify validation and just require an aud to be =
there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
. One reason I feel pretty good about that is that adding a default audienc=
e isn=E2=80=99t very hard if any of the above assumptions end up not being =
true for a particular case


=C2=A0


> Wha=
t=E2=80=99s the rationale for using iat instead of nbf.



That=E2=80=99s just straight from OIDC ID_tokens, and the consider=
ations about repurposing existing logic. I see there=E2=80=99s a thread on =
this specifically, let me answer further on that branch.


=C2=A0


> Thi=
s spec feels somehow in between a profile and a BCP


You are right that this spec attempts to go beyond just declaring =
a layout, and I agree this means that this profile will not apply to absolu=
tely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots of constructi=
ve discussions, and I ended up relaxing A LOT of the constraints I was orig=
inally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



=C2=A0






From: OAuth <o=
auth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <=
rifaat.ietf@gmail.com>; oauth <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0




Since this =
is the last call, I thought I bring up some of thoughts / concerns. Some of=
 them have been discussed before.






=C2=A0






client_i=
d vs sub






I am still =
not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of the claim typ=
es based on flow.






If the inte=
ntion is, that sub expresses the entity against which the resource will do =
authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinki=
ng reminds me of the old AD days where there was no distinction between use=
r and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






=C2=A0






All other O=
Auth specs make a very clear distinction between users and client.





=C2=A0






Furthermore=
 it says






=C2=A0






"Autho=
rization servers should prevent scenarios where clients can






=C2=A0 =C2=
=A0affect the value of the sub claim in ways that could confuse resource






=C2=A0 =C2=
=A0servers.=E2=80=9D






=C2=A0






If we keep =
that dual semantics of the sub claim - it must be clearly stated, that subj=
ect ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






=C2=A0






Maybe it sh=
ould be also explicitly mentioned that sub has a different semantic here as=
 in OIDC - even though a majority of the
 software built today will use them together.






=C2=A0






audience=
 claim






I am not fu=
lly clear why aud is required. OAuth itself does not have a notion of an au=
dience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=E2=80=99t exist, you'd need to make up an audience just to fulfil thi=
s requirement. And in many case this will be either static or just repeat t=
he scope values. What=E2=80=99s the value of that?






=C2=A0






If the conc=
ept of resources are used, I absolutely agree that aud should be used too. =
But I wouldn=E2=80=99t make it required.






=C2=A0






iat vs n=
bf






What=E2=80=
=99s the rationale for using iat instead of nbf. Aren=E2=80=99t most JWT li=
braries (including e.g. the .NET one) looking for nbf by
 default?






=C2=A0






General<=
/span>






This spec f=
eels somehow in between a profile and a BCP. On one hand you define some cl=
aims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=E2=80=99t work one way or the other for them.






=C2=A0






I know we j=
ust went though the discussion to make certain claims required as opposed t=
o optional - but maybe less is more.






=C2=A0






Tbh - the m=
ost valuable part of the doc to me is the definition of the =E2=80=9Cat+jwt=
=E2=80=9D typ. For the rest I=E2=80=99d rather like to see just
 some standard claims and IF they are used, which semantics they have.






=C2=A0




cheers=C2=
=A0




=E2=80=94=
=E2=80=94=E2=80=94




Dominick Ba=
ier






=C2=A0


On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:











Hi all,



=C2=A0



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



=C2=A0



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06



=C2=A0



Please send your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0




___________=
____________________________________


OAuth mailing list 

OAuth@ietf.org 

https://www.ietf.or=
g/mailman/listinfo/oauth























--000000000000c81d0c05a3d047b8--


From nobody Tue Apr 21 11:08:38 2020
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 05CAB3A0924 for ; Tue, 21 Apr 2020 11:08:37 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=microsoft.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 i1MmK8h5Q5fU for ; Tue, 21 Apr 2020 11:08:34 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640135.outbound.protection.outlook.com [40.107.64.135]) (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 06C153A08EC for ; Tue, 21 Apr 2020 11:07:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dj+puUEsW9PwEQNyETDRQZneu7DfXOWuW1827nr9wQhvN8eLDQOEPv4CBmPn8Ej4kED1mV8k45UYOlhmS+LizJthfSrs5UUAWf5iQFAyUtgFexhOGzwQZ3hzEh5BcQXAb2IuJr35rqPkRwpe60eBYigkmYTY9FeIe6KuRxyL9QLlsimcLLueMYq+sHmaJoPtyGcBokPTBgHhIP3uCImn5LXYlHPEK9SyPAF2Fk1HkKu8Hcgi4wp4vhmHDr4QlJhVDdyk/aaP5BrSAz8KJhTiQ6JNs4G+EiInnBilIBPYp0czRu3EJtMjPOPNTIQ9Jnad6xFzMHxIG1wVV1083oYZ8Q==
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=h68Kcm3ZiA7eVclDcH9A0/8UZYNpUKd1CeM3HfZFM+s=; b=HC+Pj8X/N1M9WrFCTBO53yT4Dz5+UTb1a/XgeKNVWBJ567vVIG8dr9x2gL0zDYD7Mgde6gywemLX1I95dQ5P/a8srGOxV/BOxHI6eDs179aqXv73fcKDuaJhKyQMeK98EMLxB4FJj4Q6c0sz/lCnsvoCcj7g8GwU4lCuuw4QJAFpx4DHAzb0OV1hFnOhcBd2Om5qcm4VhByKLPLiP1pSqUIfVRwRBUufa4yxthGzHfYObXgb+MkJxIyXHkbKZjg/PHVR13FDmAKT025Bgayzk6jim+M1gsqgeIlyx7U3qcGjdDsRIBD62YHri+TkVOPvnd9Li6qyOYodLgYb7x6b+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h68Kcm3ZiA7eVclDcH9A0/8UZYNpUKd1CeM3HfZFM+s=; b=Cjtp1kivG7SCguSTizyoaHhFZWtp0OrO2nP6FtCb62jU5MZnDw5ufz8RP/uYoxp9VMYsFyfsWsueQ5WATut8uE8z67FDM6CoSX+DYLLiLuh30W66FMeCx2T/BAR8n3UzNXlJ47CdwYE5TgQBoNOJGKzMBtp+N3jpjGczE6Nz44M=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0680.namprd00.prod.outlook.com (2603:10b6:610:7b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2971.0; Tue, 21 Apr 2020 18:07:37 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276%6]) with mapi id 15.20.2973.000; Tue, 21 Apr 2020 18:07:37 +0000
From: Mike Jones 
To: oauth , Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AdYYB6pDYW6Oyu7JT7+X3TjjJM1Xcg==
Date: Tue, 21 Apr 2020 18:07:37 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9f0c9e8c-d062-4091-9da2-0000c627d177; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-21T18:05:28Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 25d974f9-f862-4d5d-49f3-08d7e61edffe
x-ms-traffictypediagnostic: CH2PR00MB0680:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 038002787A
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lHg/eF168HwHCqdyZpqbc4wClq66bk/SCWw5g+/Y0TxCSAhoeQ7szK8wi8oDcYrtBgpQYw0LzZJ+RbLMG09oclvYfj2gUvgDGYBKjejvL52C1Li9D2Zmyijs6+HKKrhmERV/chZqsmBv5RZ4fqGAQJ5zgQ6fHEqfyqayEoVqwktR5UKE+7S2G0CrMPPF7gmO/N7BykaBvCtk6mNtZ5G+D+aPUB2UeoiJUf5AfFGRC5gj8MzzXFC41H5aS5sd7BPqmY+mU73CiogQCRdJi7yAgjDtl6B8Bzb9cLXqx+b2+locQ3vnTpZfHrfNjEy03JqE+gP5nNIGInDBJMkxvXbGUpEQOklvzZ3MZTCRT/kuumJYRd0liBf+DBtwkE2QVXanvEco+JsEVT2BhyxE31dhwT75VB3F9tjUHM4Siu5sc8oDATmP0PUnP5XVnEZwPyleJngqAsRRko7Ev5O0T/oMylj7XjHAreinUGqXJW8Qql1fV8z7/V5LCr8DZqJ8RtktlZJD+LtPRqIUbvnAV9hMEA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(346002)(396003)(136003)(376002)(366004)(186003)(66556008)(110136005)(316002)(52536014)(9686003)(4326008)(64756008)(66446008)(86362001)(2906002)(966005)(478600001)(66476007)(10290500003)(66946007)(76116006)(8676002)(71200400001)(53546011)(82950400001)(82960400001)(8936002)(33656002)(55016002)(6506007)(7696005)(5660300002)(26005)(8990500004); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: H5je4HCPS8u6xi5Pv8iBhv5W11t/PEsuzAV4m4YF2dOQtWp2F9MifhOjlYEsZwf9PNmvVhabHb0vyWyPNL17xLY0ikACbciWqmPdxbuwILvSmcFqU8F+yiuEv0SEHKraH9m/rsfZP3FvSwwkUh6rOjgf6b89Y6OcAOfW0o82CH3Ib1mPJAhu1bZ0IqKk9q7h4Uc8uppS8BUQBGze4GTHZ56+0df/6SIRZruqlpcQsqFdDkKWbuFdoo20gEIGXJ1ANAdLyxPoY3O4dkUJFrreZWIC3cBfVFFvetcNiPGJKlloDY4K4dncYadcu7S+IrQ8kvwFN72QZ3YfET7MhER449XdYrhtACptxJfV/T933MkLxcDZZpCSuvRK8Tu9bx+JCblPJvihshuMxCCK6/TowlLjsW6WUiO+0bkh32HNLBc4M/4u1+GGSjk15xOeUVKd5EaaLAy7ee6ex7CdJFLj50HH/TqSkImYpbMa+Sdsv0I9hzl3ScMf5x0GgbPEpLJsVtkqceLSa5ruJB3nU0i1CQKztAwAORZ5/LvRsMbroVlh8Pp2H3JfMMuW0G97lvFCIiBbBA8dsk9VmjiHRSTXX5tYt7wtcpNuddHmpojxd8NTBMX9wjc2Na+99X8sIBmA5byKO60/Jw96YiN2vV9l7BbapjK86FD7YSuGRw71C92RYJOEwGSb68t5MVVglPkJ6wx0b7WsGf4X9aRZSEK1m7Lqe/mLVyrt+oog/3yVCZsICAKPP8OaFcn10wQSGXmFjgJdtGAeYryxpkIgsM2xn6cIqphyXgyNsxHngAu2M18=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50CH2PR00MB0678namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25d974f9-f862-4d5d-49f3-08d7e61edffe
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 18:07:37.6451 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yb7PPSlWqJonuC90yTD1sDBUzn2dfCzeArgOSIn9abxr9GRcY7dDe3w4Nk9RNUf4DZCvXzkOl3X+voGrmq9kqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0680
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 18:08:37 -0000

--_000_CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50CH2PR00MB0678namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBmZWVkYmFjayBpcyBmcm9tIGEgTWljcm9zb2Z0IGVuZ2luZWVyIG9uIHRoZSBBenVyZSBB
Y3RpdmUgRGlyZWN0b3J5IGlkZW50aXR5IHRlYW06DQoNCg0KICAqICAgMQ0KICAgICAqICAgTWlz
c2luZyBzcGFjZSBhdCDigJxUb2tlbnMoSldUKeKAnQ0KICAqICAgMi4xDQogICAgICogICBVc2Ug
b2Yg4oCcTVVTVOKAnSBzYXlpbmcgb25lIGZvcm0gbXVzdCBiZSB1c2VkLCBmb2xsb3dlZCBieSDi
gJxTSE9VTETigJ0gc2F5aW5nIGEgZGlmZmVyZW50IGZvcm1hdCBzaG91bGQgYmUgdXNlZCBpcyBh
IGJpdCBjb25mdXNpbmcuIEkgZ2V0IHRoZSBwb2ludCwgYnV0IEkgaGFkIHRvIHJlYWQgaXQgc2V2
ZXJhbCB0aW1lcy4NCiAgICAgKiAgIE1pc3Npbmcgc3BhY2UgYXQg4oCcVGhlcmVmb3JlLHRoZeKA
nQ0KICAqICAgMi4yLjENCiAgICAgKiAgIFJlZmVyZW5jZXMgdGhlIGRlZmluaXRpb25zIG9mIOKA
nGFjcuKAnSwg4oCcYW1y4oCdIGFuZCDigJxhdXRoX3RpbWXigJ0gZnJvbSBPcGVuSUQgQ29ubmVj
dC4gSW4gT3BlbklEIENvbm5lY3QsIHRoZXNlIGV4cGxpY2l0bHkgcmVmZXIgdG8gdGhlIGVuZC11
c2Vy4oCZcyBhdXRoZW50aWNhdGlvbi4gRG9lcyB0aGlzIG1lYW4gdGhlc2UgY2xhaW1zIHNob3Vs
ZCBvbmx5IGJlIHVzZWQgd2hlbiB0aGUgc3ViamVjdCBpcyBhIHVzZXI/IElmIHNvLCB0aGVuIGl0
IG1pZ2h0IGJlIGdvb2QgdG8gY2xhcmlmeS4gSWYgbm90IChhbmQgdGhlc2UgYWxzbyBhcHBseSBm
b3IgY2xpZW50IGNyZWRlbnRpYWxzLCBmb3IgZXhhbXBsZSksIHRoZW4gYSByZWZlcmVuY2UgdG8g
T3BlbklEIENvbm5lY3QgbWF5IG5vdCBiZSBpZGVhbC4NCiAgKiAgIDIuMi4yDQogICAgICogICBV
c2Ugb2Yg4oCccmVzb3VyY2Ugb3duZXLigJ0gc3VnZ2VzdHMgdGhlIHJlc291cmNlIG93bmVyIGlz
IHRoZSBzdWJqZWN0IG9mIHRoZSB0b2tlbi4gVGhpcyBpcyBub3QgYWx3YXlzIHRydWUuIEluIGNs
aWVudCBjcmVkZW50aWFscyBpdOKAmXMgbm90LCBhbmQgZXZlbiBpbiBzY2VuYXJpb3Mgd2l0aCBh
IHVzZXIsIGlzIGl0IG5lY2Vzc2FyaWx5IHRoZSByZXNvdXJjZSBvd25lciB3aG8gaXMgYXV0aGVu
dGljYXRlZC9hdXRob3JpemVkPyAoT3IgY291bGQgaXQgYmUgYSBkaWZmZXJlbnQgdXNlciB3aG8g
aGFzIGJlZW4gc2VwYXJhdGUgYXV0aG9yaXplZCBmb3IgdGhlIHJlcXVlc3RlZCBhY2Nlc3MgYnkg
dGhlIHJlc291cmNlIG93bmVyPykNCiAgKiAgIDIuMi4zLjENCiAgICAgKiAgIExpbmsgdG8gc2Vj
dGlvbiA0LjEuMiBvZiBTQ0lNIENvcmUgaXMgYWN0dWFsbHkgbGlua2luZyB0byBzZWN0aW9uIDQu
MS4yIG9mIHRoaXMgZG9jLg0KICAgICAqICAgU3RhdGVzIOKAnGdyb3Vwc+KAnSwg4oCccm9sZXPi
gJ0gYW5kIOKAnGVudGl0bGVtZW50c+KAnSBpbiBTQ0lNIGRvbuKAmXQgaGF2ZSBhIHZvY2FidWxh
cnkgZGVmaW5lZCwgYnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsLCDigJxncm91cHPigJ0gZG9lcyBo
YXZlIGEgc3ludGF4IGRlZmluZWQgaW4gU0NJTS4NCiAgKiAgIDMNCiAgICAgKiAgIE1pc3Npbmcg
bmV3bGluZSBpbiB0aGUgZXhhbXBsZSwgYmVmb3JlIOKAnCZzdGF0ZeKAnQ0KICAqICAgNA0KICAg
ICAqICAgU3RhdGVzIHRoZSBjb25maWd1cmF0aW9uIG1ldGFkYXRhIGlzIHVzZWQgdG86IOKAnGFk
dmVydGlzZSB0byByZXNvdXJjZSBzZXJ2ZXJzIFthbmRdIHdoYXQgaXNzIGNsYWltIHZhbHVlIHRv
IGV4cGVjdCB2aWEgdGhlIGlzc3VlciBtZXRhZGF0YSB2YWx1ZeKAnS4gVGhpcyBzZWVtcyBjaXJj
dWxhciwgc2luY2UgdGhlIGNvbmZpZ3VyYXRpb24gbWV0YWRhdGEgaXMgaXRzZWxmIG9idGFpbmVk
IGJ5IGFwcGVuZGluZyBhIHN1ZmZpeCB0byBhIGtub3duIChhbmQgdHJ1c3RlZCkgaXNzdWVyIHZh
bHVlLCByaWdodD8NCiAgICAgKiAgIOKAnEFT4oCdIEkgdXNlZCB3aXRob3V0IGhhdmluZyBiZWVu
IGludHJvZHVjZWQgYXMgYWJicmV2aWF0aW9uIG9mIOKAnGF1dGhvcml6YXRpb24gc2VydmVy4oCd
Lg0KICAgICAqICAgU3RhdGVzIHRoYXQgYW55IEpXVCB0b2tlbiB3aXRoIOKAnHR5cOKAnSB2YWx1
ZSBvdGhlciB0aGFuIOKAnGF0K2p3dOKAnSBtdXN0IGJlIHJlamVjdGVkLg0KICAgICAgICAqICAg
VGhlIHZhbHVlIOKAnGFwcGxpY2F0aW9uL2F0K2p3dOKAnSBzaG91bGQgYWxzbyBiZSBhY2NlcHRl
ZC4NCiAgICAgICAgKiAgIEFzIHdyaXR0ZW4sIHRoaXMgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgdG8g
bWVhbiB0aGVyZSBpcyBubyBwb3NzaWJpbGl0eSBvZiBhIGZ1dHVyZSBKV1QgdG9rZW4gcHJvZmls
ZSB0byBiZSBzcGVjaWZpZWQgZm9yIHVzZSBhcyBhIEJlYXJlciB0b2tlbiAoZS5nLiBvbmUgd2l0
aCBtZWRpYSB0eXBlIOKAnGFwcGxpY2F0aW9uL2V4YW1wbGUrand04oCdKS4gSSBiZWxpZXZlIHRo
ZSBpbnRlbnQgaXMgdG8gc2F5IHRoYXQgaWYgdGhlIOKAnHR5cOKAnSB2YWx1ZSBpcyBub3Qg4oCc
YXQrand04oCdLCBpdCBzaG91bGQgcmVqZWN0ZWQgZm9yIHRoaXMgcHJvZmlsZS4gKEJ1dCBtYXli
ZSB0aGF04oCZcyBhbHJlYWR5IHVuZGVyc3Rvb2Q/KQ0KICAgICAqICAgVGhpcmQgYnVsbGV0IHN1
Z2dlc3RzIHRoZSBpc3N1ZXIgaWRlbnRpZmllciBpcyBvYnRhaW5lZCB0aHJvdWdoIGRpc2NvdmVy
eS4gRGlzY292ZXJ5IGRlZmluZXMgdGhlIGxvY2F0aW9uIG9mIHRoZSBtZXRhZGF0YSB0byBiZSBk
ZXJpdmVkIGZyb20gdGhlIGlzc3VlciBpZGVudGlmaWVyLiBUaGlzIGNpcmN1bGFyIHJlZmVyZW5j
ZSBpcyBjb25mdXNpbmcuDQogICAgICogICBVc2Ugb2Ygc2luZ3VsYXIgc3VnZ2VzdHMgdGhlcmUg
aXMgb25seSBvbmUgcG9zc2libGUg4oCcYXVk4oCdIHZhbHVlIHRoYXQgYSByZXNvdXJjZSBzZXJ2
ZXIgd291bGQgYWNjZXB0Lg0KICAgICAqICAgU3RhdGVzIHRoZSBzaWduaW5nIGtleSBtdXN0IGJl
IG9idGFpbmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBJcyB0aGlzIHJlcXVpcmVt
ZW50IG5lY2Vzc2FyeT8gKEUuZy4gSSBiZWxpZXZlIEF6dXJlIEFEIHN1cHBvcnRzIGEgcmVzb3Vy
Y2Ugc2VydmVyIG93bmVyIHByb3ZpZGluZyBhIGN1c3RvbSBzaWduaW5nIGtleSwgaW4gd2hpY2gg
Y2FzZSB0aGUgUlMgaXMgbm90IHJldHJpZXZpbmcgdGhlIHNpZ25pbmcga2V5IGZyb20gdGhlIEFT
LikNCiAgICAgKiAgIEkgZXhwZWN0ZWQgc29tZSByZWZlcmVuY2UgdG8gSldUIHZhbGlkYXRpb24g
c3RlcHMgZnJvbSBSRkMgNzUxOQ0KICAqICAgNQ0KICAgICAqICAg4oCcYXMgdGhpcyB3b3VsZCBh
bGxvdyBtYWxpY2lvdXMgY2xpZW50cyB0byBzZWxlY3QgdGhlIHN1YiBvZiBhIGhpZ2ggcHJpdmls
ZWdlIHJlc291cmNlIG93bmVy4oCdOiB0aGUgc3ViamVjdCBvZiB0aGUgYWNjZXNzIHRva2VuIGlz
IG5vdCBuZWNlc3NhcmlseSB0aGUgcmVzb3VyY2Ugb3duZXIgKGUuZy4gY2xpZW50IGNyZWRlbnRp
YWxzKS4NCiAgICAgKiAgIOKAnFRvIHByZXZlbnRpbmcgY3Jvc3MtSldUIGNvbmZ1c2lvbuKAnTog
bWlnaHQgYmUgZ29vZCB0byByZWZlcmVuY2Ugc2VjdGlvbiAyLjggb2YgUkZDIDg3MjUgdG8gY2xh
cmlmeSB3aGF0IOKAnGNyb3NzLUpXVCBjb25mdXNpb27igJ0gaXMNCiAgICAgKiAgIOKAnGVhY2gg
c2NvcGUgc3RyaW5nIGluY2x1ZGVkIGluIHRoZSByZXN1bHRpbmcgSldUIGFjY2VzcyB0b2tlbiwg
aWYgYW55LCBjYW4gYmUgdW5hbWJpZ3VvdXNseSBjb3JyZWxhdGVkIHRvIGEgc3BlY2lmaWMgcmVz
b3VyY2UgYW1vbmcgdGhlIG9uZXMgbGlzdGVkIGluIHRoZSBhdWQgY2xhaW3igJ0gc3BlY2lmaWVz
IGFuIHVuYW1iaWd1b3VzIG1hcHBpbmcsIGJ1dCBzZWN0aW9uIDIuMS4xIG9mIFJGQzg2OTM8aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg2OTMjc2VjdGlvbi0yLjEuMT4gc3VnZ2VzdHMg
YSBDYXRlc2lhbiBwcm9kdWN0IG9mIHJlc291cmNlcyBhbmQgc2NvcGVzIGlzIHBvc3NpYmxlLCBt
ZWFuaW5nIHRoYXQgb25lIHNjb3BlIHZhbHVlIGNvdWxkIChsZWdpdGltYXRlbHkpIG1hcCB0byBt
dWx0aXBsZSBhdWRpZW5jZSB2YWx1ZXMuIEl04oCZcyB1bmNsZWFyIGlmIHRoZSBpbnRlbnQgaGVy
ZSBpcyB0byBhdm9pZCB0aGUgYW1iaWd1aXR5IGZvciBzcGVjaWZ5aW5nIHRoYXQgaXQgbXVzdCBu
b3QgYmUgYW1iaWd1b3VzLCBvciBpZiB0aGVyZeKAmXMgYSBzbGlnaHQgY29uZmxpY3QgYmV0d2Vl
biB0aGUgc3BlY3MuDQogICAgICogICBFeHRyYSDigJhu4oCZIGF0IOKAnE9wZW5uSUQgQ29ubmVj
dOKAmQ0KICAqICAgNy4xLjENCiAgICAgKiAgIFR5cG8gYXQg4oCcSlRX4oCdDQogICAgICogICBN
aXNzaW5nIOKAmEHigJkgYXQg4oCcTi/igJ0NCiAgKiAgIDcuMg0KICAgICAqICAgTWlzc2luZyBz
cGFjZSBhdCDigJjigJ1yb2xlc+KAnSzigJ1ncm91cHPigJ3igJkNCiAgKiAgIFJlZmVyZW5jZToN
CiAgICAgKiAgIE5vIGxpbmsgdG8gT3BlbklELkNvcmUNCiAgKiAgIEFsbCBvdmVyOg0KICAgICAq
ICAgTWlzc2luZyBkb3VibGUgcXVvdGVzIGFyb3VuZCBjbGFpbSBhbmQgcGFyYW1ldGVyIG5hbWVz
IChlLmcuIDIuMiwgMi4yLjMpLCB3aGljaCBpcyBpbmNvbnNpc3RlbnQgd2l0aCBvdGhlciBPQXV0
aCAyLjAgc3BlY3MsIEkgdGhpbmsuDQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWZhYXQgU2hla2gtWXVzZWYNClNlbnQ6IFdlZG5lc2RheSwg
QXByaWwgMTUsIDIwMjAgMTE6NTkgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICJKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9m
aWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyINCg0KSGkgYWxsLA0KDQpUaGlzIGlzIGEg
c2Vjb25kIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciAiSlNPTiBXZWIgVG9rZW4gKEpXVCkg
UHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiLg0KDQpIZXJlIGlzIHRoZSBkb2N1
bWVudDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vz
cy10b2tlbi1qd3QtMDYNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgT0F1dGgg
bWFpbGluZyBsaXN0IGJ5IEFwcmlsIDI5LCAyMDIwLg0KDQpSZWdhcmRzLA0KIFJpZmFhdCAmIEhh
bm5lcw0KDQo=

--_000_CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50CH2PR00MB0678namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo
DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTUzMDc1NTA1NzsNCgltc28tbGlzdC10
eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk4ODUzMTg0MiAtMTEwNjA4OTE0
NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2
NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0
OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t
ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWJpZGktZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OlN5bWJvbDsNCgltc28tYmlkaS1mb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczsNCgltc28tYmlkaS1mb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy
Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj5UaGlzIGZlZWRiYWNrIGlzIGZyb20gYSBNaWNyb3NvZnQgZW5naW5lZXIgb24g
dGhlIEF6dXJlIEFjdGl2ZSBEaXJlY3RvcnkgaWRlbnRpdHkgdGVhbTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg
dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t
bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjE8bzpwPjwvbzpwPjwvbGk+PHVsIHN0
eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh
cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+
TWlzc2luZyBzcGFjZSBhdCDigJxUb2tlbnMoSldUKeKAnTxvOnA+PC9vOnA+PC9saT48L3VsPg0K
PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s
aXN0OmwwIGxldmVsMSBsZm8xIj4yLjE8bzpwPjwvbzpwPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4t
dG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+VXNlIG9mIOKAnE1V
U1TigJ0gc2F5aW5nIG9uZSBmb3JtIG11c3QgYmUgdXNlZCwgZm9sbG93ZWQgYnkg4oCcU0hPVUxE
4oCdIHNheWluZyBhIGRpZmZlcmVudCBmb3JtYXQgc2hvdWxkIGJlIHVzZWQgaXMgYSBiaXQgY29u
ZnVzaW5nLiBJIGdldCB0aGUgcG9pbnQsIGJ1dCBJIGhhZCB0byByZWFkIGl0IHNldmVyYWwgdGlt
ZXMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+TWlzc2luZyBzcGFjZSBhdCDi
gJxUaGVyZWZvcmUsdGhl4oCdPG86cD48L286cD48L2xpPjwvdWw+DQo8bGkgY2xhc3M9Ik1zb0xp
c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzEiPjIuMi4xPG86cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9
ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm
dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPlJlZmVyZW5jZXMgdGhlIGRlZmluaXRpb25z
IG9mIOKAnGFjcuKAnSwg4oCcYW1y4oCdIGFuZCDigJxhdXRoX3RpbWXigJ0gZnJvbSBPcGVuSUQg
Q29ubmVjdC4gSW4gT3BlbklEIENvbm5lY3QsIHRoZXNlIGV4cGxpY2l0bHkgcmVmZXIgdG8gdGhl
IGVuZC11c2Vy4oCZcyBhdXRoZW50aWNhdGlvbi4gRG9lcyB0aGlzIG1lYW4gdGhlc2UgY2xhaW1z
DQogc2hvdWxkIDxpPm9ubHk8L2k+IGJlIHVzZWQgd2hlbiB0aGUgc3ViamVjdCBpcyBhIHVzZXI/
IElmIHNvLCB0aGVuIGl0IG1pZ2h0IGJlIGdvb2QgdG8gY2xhcmlmeS4gSWYgbm90IChhbmQgdGhl
c2UgYWxzbyBhcHBseSBmb3IgY2xpZW50IGNyZWRlbnRpYWxzLCBmb3IgZXhhbXBsZSksIHRoZW4g
YSByZWZlcmVuY2UgdG8gT3BlbklEIENvbm5lY3QgbWF5IG5vdCBiZSBpZGVhbC48bzpwPjwvbzpw
PjwvbGk+PC91bD4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+Mi4yLjI8bzpwPjwvbzpwPjwvbGk+PHVs
IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlz
dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZv
MSI+VXNlIG9mIOKAnHJlc291cmNlIG93bmVy4oCdIHN1Z2dlc3RzIHRoZSByZXNvdXJjZSBvd25l
ciBpcyB0aGUgc3ViamVjdCBvZiB0aGUgdG9rZW4uIFRoaXMgaXMgbm90IGFsd2F5cyB0cnVlLiBJ
biBjbGllbnQgY3JlZGVudGlhbHMgaXTigJlzIG5vdCwgYW5kIGV2ZW4gaW4gc2NlbmFyaW9zIHdp
dGggYSB1c2VyLCBpcyBpdCBuZWNlc3NhcmlseQ0KIHRoZSByZXNvdXJjZSBvd25lciB3aG8gaXMg
YXV0aGVudGljYXRlZC9hdXRob3JpemVkPyAoT3IgY291bGQgaXQgYmUgYSBkaWZmZXJlbnQgdXNl
ciB3aG8gaGFzIGJlZW4gc2VwYXJhdGUgYXV0aG9yaXplZCBmb3IgdGhlIHJlcXVlc3RlZCBhY2Nl
c3MgYnkgdGhlIHJlc291cmNlIG93bmVyPykNCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGxpIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww
IGxldmVsMSBsZm8xIj4yLjIuMy4xPG86cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRv
cDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl
PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPkxpbmsgdG8gc2VjdGlv
biA0LjEuMiBvZiBTQ0lNIENvcmUgaXMgYWN0dWFsbHkgbGlua2luZyB0byBzZWN0aW9uIDQuMS4y
IG9mIHRoaXMgZG9jLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPlN0YXRlcyDi
gJxncm91cHPigJ0sIOKAnHJvbGVz4oCdIGFuZCDigJxlbnRpdGxlbWVudHPigJ0gaW4gU0NJTSBk
b27igJl0IGhhdmUgYSB2b2NhYnVsYXJ5IGRlZmluZWQsIGJ1dCBhcyBmYXIgYXMgSSBjYW4gdGVs
bCwg4oCcZ3JvdXBz4oCdDQo8aT5kb2VzPC9pPiBoYXZlIGEgc3ludGF4IGRlZmluZWQgaW4gU0NJ
TS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+MzxvOnA+PC9vOnA+
PC9saT48dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNz
PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl
dmVsMiBsZm8xIj5NaXNzaW5nIG5ld2xpbmUgaW4gdGhlIGV4YW1wbGUsIGJlZm9yZSDigJwmYW1w
O3N0YXRl4oCdPG86cD48L286cD48L2xpPjwvdWw+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh
cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjQ8bzpw
PjwvbzpwPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxs
aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz
dDpsMCBsZXZlbDIgbGZvMSI+U3RhdGVzIHRoZSBjb25maWd1cmF0aW9uIG1ldGFkYXRhIGlzIHVz
ZWQgdG86IOKAnGFkdmVydGlzZSB0byByZXNvdXJjZSBzZXJ2ZXJzIFthbmRdIHdoYXQgaXNzIGNs
YWltIHZhbHVlIHRvIGV4cGVjdCB2aWEgdGhlIGlzc3VlciBtZXRhZGF0YSB2YWx1ZeKAnS4gVGhp
cyBzZWVtcyBjaXJjdWxhciwgc2luY2UgdGhlIGNvbmZpZ3VyYXRpb24NCiBtZXRhZGF0YSBpcyBp
dHNlbGYgb2J0YWluZWQgYnkgYXBwZW5kaW5nIGEgc3VmZml4IHRvIGEga25vd24gKGFuZCB0cnVz
dGVkKSBpc3N1ZXIgdmFsdWUsIHJpZ2h0PzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xp
c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxm
bzEiPuKAnEFT4oCdIEkgdXNlZCB3aXRob3V0IGhhdmluZyBiZWVuIGludHJvZHVjZWQgYXMgYWJi
cmV2aWF0aW9uIG9mIOKAnGF1dGhvcml6YXRpb24gc2VydmVy4oCdLjxvOnA+PC9vOnA+PC9saT48
bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp
c3Q6bDAgbGV2ZWwyIGxmbzEiPlN0YXRlcyB0aGF0IGFueSBKV1QgdG9rZW4gd2l0aCDigJx0eXDi
gJ0gdmFsdWUgb3RoZXIgdGhhbiDigJxhdCYjNDM7and04oCdIG11c3QgYmUgcmVqZWN0ZWQuPG86
cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9InNxdWFyZSI+DQo8
bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp
c3Q6bDAgbGV2ZWwzIGxmbzEiPlRoZSB2YWx1ZSDigJxhcHBsaWNhdGlvbi9hdCYjNDM7and04oCd
IHNob3VsZCBhbHNvIGJlIGFjY2VwdGVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xp
c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxm
bzEiPkFzIHdyaXR0ZW4sIHRoaXMgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgdG8gbWVhbiB0aGVyZSBp
cyBubyBwb3NzaWJpbGl0eSBvZiBhIGZ1dHVyZSBKV1QgdG9rZW4gcHJvZmlsZSB0byBiZSBzcGVj
aWZpZWQgZm9yIHVzZSBhcyBhIEJlYXJlciB0b2tlbiAoZS5nLiBvbmUgd2l0aCBtZWRpYSB0eXBl
IOKAnGFwcGxpY2F0aW9uL2V4YW1wbGUmIzQzO2p3dOKAnSkuDQogSSBiZWxpZXZlIHRoZSBpbnRl
bnQgaXMgdG8gc2F5IHRoYXQgaWYgdGhlIOKAnHR5cOKAnSB2YWx1ZSBpcyBub3Qg4oCcYXQmIzQz
O2p3dOKAnSwgaXQgc2hvdWxkIHJlamVjdGVkDQo8aT5mb3IgdGhpcyBwcm9maWxlPC9pPi4gKEJ1
dCBtYXliZSB0aGF04oCZcyBhbHJlYWR5IHVuZGVyc3Rvb2Q/KTxvOnA+PC9vOnA+PC9saT48L3Vs
Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z
by1saXN0OmwwIGxldmVsMiBsZm8xIj5UaGlyZCBidWxsZXQgc3VnZ2VzdHMgdGhlIGlzc3VlciBp
ZGVudGlmaWVyIGlzIG9idGFpbmVkIHRocm91Z2ggZGlzY292ZXJ5LiBEaXNjb3ZlcnkgZGVmaW5l
cyB0aGUgbG9jYXRpb24gb2YgdGhlIG1ldGFkYXRhIHRvIGJlIGRlcml2ZWQgZnJvbSB0aGUgaXNz
dWVyIGlkZW50aWZpZXIuIFRoaXMgY2lyY3VsYXIgcmVmZXJlbmNlDQogaXMgY29uZnVzaW5nLjxv
OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t
bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPlVzZSBvZiBzaW5ndWxhciBzdWdnZXN0
cyB0aGVyZSBpcyBvbmx5IG9uZSBwb3NzaWJsZSDigJxhdWTigJ0gdmFsdWUgdGhhdCBhIHJlc291
cmNlIHNlcnZlciB3b3VsZCBhY2NlcHQuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBs
Zm8xIj5TdGF0ZXMgdGhlIHNpZ25pbmcga2V5DQo8aT5tdXN0PC9pPiBiZSBvYnRhaW5lZCBmcm9t
IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gSXMgdGhpcyByZXF1aXJlbWVudCBuZWNlc3Nhcnk/
IChFLmcuIEkgYmVsaWV2ZSBBenVyZSBBRCBzdXBwb3J0cyBhIHJlc291cmNlIHNlcnZlciBvd25l
ciBwcm92aWRpbmcgYSBjdXN0b20gc2lnbmluZyBrZXksIGluIHdoaWNoIGNhc2UgdGhlIFJTIGlz
IG5vdCByZXRyaWV2aW5nIHRoZSBzaWduaW5nIGtleSBmcm9tIHRoZSBBUy4pDQo8bzpwPjwvbzpw
PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu
O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj5JIGV4cGVjdGVkIHNvbWUgcmVmZXJlbmNlIHRvIEpX
VCB2YWxpZGF0aW9uIHN0ZXBzIGZyb20gUkZDIDc1MTk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxs
aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz
dDpsMCBsZXZlbDEgbGZvMSI+NTxvOnA+PC9vOnA+PC9saT48dWwgc3R5bGU9Im1hcmdpbi10b3A6
MGluIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj7igJxhcyB0aGlzIHdvdWxk
IGFsbG93IG1hbGljaW91cyBjbGllbnRzIHRvIHNlbGVjdCB0aGUgc3ViIG9mIGEgaGlnaCBwcml2
aWxlZ2UgcmVzb3VyY2Ugb3duZXLigJ06IHRoZSBzdWJqZWN0IG9mIHRoZSBhY2Nlc3MgdG9rZW4g
aXMgbm90IG5lY2Vzc2FyaWx5IHRoZSByZXNvdXJjZSBvd25lciAoZS5nLiBjbGllbnQgY3JlZGVu
dGlhbHMpLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl
PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPuKAnFRvIHByZXZlbnRp
bmcgY3Jvc3MtSldUIGNvbmZ1c2lvbuKAnTogbWlnaHQgYmUgZ29vZCB0byByZWZlcmVuY2Ugc2Vj
dGlvbiAyLjggb2YgUkZDIDg3MjUgdG8gY2xhcmlmeSB3aGF0IOKAnGNyb3NzLUpXVCBjb25mdXNp
b27igJ0gaXM8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj7igJxlYWNoIHNjb3Bl
IHN0cmluZyBpbmNsdWRlZCBpbiB0aGUgcmVzdWx0aW5nIEpXVCBhY2Nlc3MgdG9rZW4sIGlmIGFu
eSwgY2FuIGJlIHVuYW1iaWd1b3VzbHkgY29ycmVsYXRlZCB0byBhIHNwZWNpZmljIHJlc291cmNl
IGFtb25nIHRoZSBvbmVzIGxpc3RlZCBpbiB0aGUgYXVkIGNsYWlt4oCdIHNwZWNpZmllcyBhbiB1
bmFtYmlndW91cw0KIG1hcHBpbmcsIGJ1dCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjODY5MyNzZWN0aW9uLTIuMS4xIj5zZWN0aW9uIDIuMS4xIG9mIFJGQzg2OTM8L2E+
IHN1Z2dlc3RzIGEgQ2F0ZXNpYW4gcHJvZHVjdCBvZiByZXNvdXJjZXMgYW5kIHNjb3BlcyBpcyBw
b3NzaWJsZSwgbWVhbmluZyB0aGF0IG9uZSBzY29wZSB2YWx1ZSBjb3VsZCAobGVnaXRpbWF0ZWx5
KSBtYXAgdG8gbXVsdGlwbGUgYXVkaWVuY2UgdmFsdWVzLiBJdOKAmXMgdW5jbGVhcg0KIGlmIHRo
ZSBpbnRlbnQgaGVyZSBpcyB0byBhdm9pZCB0aGUgYW1iaWd1aXR5IGZvciBzcGVjaWZ5aW5nIHRo
YXQgaXQgbXVzdCBub3QgYmUgYW1iaWd1b3VzLCBvciBpZiB0aGVyZeKAmXMgYSBzbGlnaHQgY29u
ZmxpY3QgYmV0d2VlbiB0aGUgc3BlY3MuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlz
dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZv
MSI+RXh0cmEg4oCYbuKAmSBhdCDigJxPcGVubklEIENvbm5lY3TigJk8bzpwPjwvbzpwPjwvbGk+
PC91bD4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp
bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+Ny4xLjE8bzpwPjwvbzpwPjwvbGk+PHVsIHN0eWxl
PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+VHlw
byBhdCDigJxKVFfigJ08bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj5NaXNzaW5n
IOKAmEHigJkgYXQg4oCcTi/igJ08bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxsaSBjbGFzcz0iTXNv
TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSI+Ny4yPG86cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9
ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm
dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPk1pc3Npbmcgc3BhY2UgYXQg4oCY4oCdcm9s
ZXPigJ0s4oCdZ3JvdXBz4oCd4oCZPG86cD48L286cD48L2xpPjwvdWw+DQo8bGkgY2xhc3M9Ik1z
b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx
IGxmbzEiPlJlZmVyZW5jZTo8bzpwPjwvbzpwPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp
biIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+Tm8gbGluayB0byBPcGVuSUQu
Q29yZTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BbGwgb3Zlcjo8
bzpwPjwvbzpwPjwvbGk+PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4N
CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t
bGlzdDpsMCBsZXZlbDIgbGZvMSI+TWlzc2luZyBkb3VibGUgcXVvdGVzIGFyb3VuZCBjbGFpbSBh
bmQgcGFyYW1ldGVyIG5hbWVzIChlLmcuIDIuMiwgMi4yLjMpLCB3aGljaCBpcyBpbmNvbnNpc3Rl
bnQgd2l0aCBvdGhlciBPQXV0aCAyLjAgc3BlY3MsIEkgdGhpbmsuPG86cD48L286cD48L2xpPjwv
dWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv
Yj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8
L2I+DQpSaWZhYXQgU2hla2gtWXVzZWY8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJp
bCAxNSwgMjAyMCAxMTo1OSBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYu
b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICZx
dW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9r
ZW5zJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs
aW5lLWhlaWdodDoxMTUlIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+VGhpcyBpcyBhIHNlY29u
ZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkg
UHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDsuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1
JSI+SGVyZSBpcyB0aGUgZG9jdW1lbnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNiI+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNjwv
YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo
dDoxMTUlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJsaW5lLWhlaWdodDoxMTUlIj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBPQXV0
aCBtYWlsaW5nIGxpc3QgYnkgQXByaWwgMjksIDIwMjAuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo
dDoxMTUlIj4mbmJzcDtSaWZhYXQgJmFtcDsgSGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50CH2PR00MB0678namp_--


From nobody Tue Apr 21 12:19:10 2020
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 EFD103A0842 for ; Tue, 21 Apr 2020 12:19:07 -0700 (PDT)
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 NJb4wFIPd83c for ; Tue, 21 Apr 2020 12:19:04 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 0BBE83A083D for ; Tue, 21 Apr 2020 12:19:04 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id g2so5632028plo.3 for ; Tue, 21 Apr 2020 12:19:04 -0700 (PDT)
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 :mime-version; bh=XJY7EhBwgkqI2F6ECc5U3cCLeDG3lmEQz+dBrM4k+vQ=; b=MMxriX2an4GFNOwYuWnPvMiGzBR0Hbgtg20P+A1oyS17wuW6rmoHklTwaq0KyMW954 Mp7X6PkOmZ04g+ApfViyVHGrt/1Fb7BNUOgZ81IlzZYYNBSh2A5Liew0NRne2/zLQxPJ kYsnSh3zwbU5w3dzPbko3dzy6X0CsyaEeSMeyZJwGlmU4ZVSojsIs30riKGHZYISkkiy 72/6Q+DZmFs2UQkOCpRK+WlQanD+Sekdf+OW5dGWudBbAFN7XHXBO1BIO1fPCBxS7Qjn ILM0O6GEroO0H5kc6D2kBRgmST+WnEXxrIbq2Uhtr6yGVo1v30+iERVORlXEDMuFmjCw Wx4w==
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 :mime-version; bh=XJY7EhBwgkqI2F6ECc5U3cCLeDG3lmEQz+dBrM4k+vQ=; b=kvpYuR6YLRIRcZwcZnk20Va+VnFmZCVrm5ommbk35drUX4U70qp0YIm5u7SXuMYyGc EYq2sNTyJFaZG0FvBNQB0RYr6mlDOtJyg1MAO+UQhALqU0X2Bfa5vQmc5gmHOnyv8GtT jiqtGCCT+mGt22sdq9fBpOle52YoYJETA1V9OxB+OLGUJycAYJMflxnqr+Ath7cKQRDt 2fGEfE8Hh6dCVzxKaafzy9rznsRJGvzPN+gFdWxuJ8Sc5lT7ZMsQyVcizR63u8VMmvrQ D+UGYomvWxLp4iiir4D/hcXjQnRlKjbPCBaeDpQhm1f/rbxiLmZoJyqZoEh4eqHf9PIX AuGA==
X-Gm-Message-State: AGi0PuYtjd/YtExtyRhXiwH3YpYC14wrfOWS4zIOCwEB4Txf+WN0W2zG dcMLgz01pXc31XY2CAL/IlnaFR1Zmpg=
X-Google-Smtp-Source: APiQypKM7W8OmssAfLrxRLqIh48nIp2ioC3I2Joyvy1DKeNiaznkoJRwfiDqbE34VhBt5I2CCo9W7A==
X-Received: by 2002:a17:902:76c4:: with SMTP id j4mr14322812plt.177.1587496743055;  Tue, 21 Apr 2020 12:19:03 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id c15sm2915216pgk.66.2020.04.21.12.19.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 12:19:02 -0700 (PDT)
From: Vittorio Bertocci 
To: Dominick Baier , oauth , Rifaat Shekh-Yusef 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AWc4Y1QzOd30qeKpH104zsyxEMHG/jA0OTAx3D2a0oCAACAoow==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 21 Apr 2020 19:19:01 +0000
Message-ID: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>   
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: multipart/alternative; boundary="_000_MWHPR19MB150196432E117F2C47B077D1AED50MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 19:19:08 -0000

--_000_MWHPR19MB150196432E117F2C47B077D1AED50MWHPR19MB1501namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T3VjaCEgU29ycnkg8J+YiiBmaXhlZA0KDQpGcm9tOiBEb21pbmljayBCYWllciA8ZGJhaWVyQGxl
YXN0cHJpdmlsZWdlLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDIxLCAyMDIwIGF0IDEwOjIz
DQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPiwgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQu
aWV0ZkBnbWFpbC5jb20+LCBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lAYXV0
aDAuY29tPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gIkpTT04gV2Vi
IFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQpPaCBh
bmQgd2hpbGUgd2UgYXJlIGF0IGl0IC0gY291bGQgeW91IGFsc28gZml4IHRoZSB0eXBvIGluIG15
IG5hbWU/IFRoYW5rcyA7KQ0KDQrigJTigJTigJQNCkRvbWluaWNrIEJhaWVyDQoNCg0KT24gMjEu
IEFwcmlsIDIwMjAgYXQgMDk6NDM6NDksIFZpdHRvcmlvIEJlcnRvY2NpICh2aXR0b3Jpby5iZXJ0
b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4pIHdyb3Rl
Og0KVGhpcyBpcyBhIGdyZWF0IHBvaW50LiBJbiBteSBoZWFkIEkganVzdCBjb25zaWRlcmVkIHRo
ZSBPSURDIHNlbWFudGljIGFuZCB0aG91Z2h0IG9ubHkgb2YgaGlnaGxpZ2h0aW5nIHRoZSBhcHAg
aWRlbnRpdHkgY2FzZSwgYnV0IHlvdSBhcmUgYWJzb2x1dGVseSByaWdodCB0aGF0IG5vdCBtZW50
aW9uaW5nIHRoZSB1c2VyIGNhc2UgYXQgYWxsIGlzIGNvbmZ1c2luZy4gSSBhZGRlZCB0aGUgbGFu
Z3VhZ2UgeW91IHN1Z2dlc3RlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzdWIgZGVmaW5pdGlv
bi4NClRoYW5rcyENCg0KRnJvbTogRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVn
ZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+Pg0KRGF0ZTogTW9uZGF5LCBB
cHJpbCAyMCwgMjAyMCBhdCAyMjo1NA0KVG86IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86
b2F1dGhAaWV0Zi5vcmc+PiwgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5j
b208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+LCAidml0dG9yaW8uYmVydG9jY2lAYXV0
aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+IiA8dml0dG9yaW8uYmVy
dG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+Pg0KU3Vi
amVjdDogUkU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gIkpTT04gV2ViIFRva2VuIChKV1Qp
IFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQoNCkluIGNhc2Ugb2YgYWNj
ZXNzIHRva2VucyBvYnRhaW5lZCB0aHJvdWdoIGdyYW50cyB3aGVyZSBubyByZXNvdXJjZSBvd25l
ciBpcyBpbnZvbHZlZCwgc3VjaCBhcyB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50LCB0aGUg
dmFsdWUgb2Ygc3ViIFNIT1VMRCBjb3JyZXNwb25kIHRvIGFuIGlkZW50aWZpZXIgdGhlIGF1dGhv
cml6YXRpb24gc2VydmVyIHVzZXMgdG8gaW5kaWNhdGUgdGhlIGNsaWVudCBhcHBsaWNhdGlvbi4N
Cg0KTWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGRvZXMgaXQgc2F5IGFueXdoZXJl
IHdoYXQgdG8gZXhwbGljaXRseSBkbyBpbiB0aGUgY2FzZSBvZiBhbiBhY2Nlc3MgdG9rZW4gd2hl
cmUgYSByZXNvdXJjZSBvd25lciBpcyBpbnZvbHZlZD8NCg0KVGhlcmXigJlzIHNvbWUgbGFuZ3Vh
Z2UgdGhhdCBzZWVtcyB0byBpbXBseSB0aGF0LCBlLmcuOg0KDQoNCmFzIHRoaXMgd291bGQgYWxs
b3cgbWFsaWNpb3VzDQoNCiAgIGNsaWVudHMgdG8gc2VsZWN0IHRoZSBzdWIgb2YgYSBoaWdoIHBy
aXZpbGVnZSByZXNvdXJjZSBvd25lcg0KSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRvIHNlZSBzb21l
dGhpbmcgc3Ryb25nZXIgbGlrZSBhYm92ZSBqdXN0IC0NCg0KDQpJbiBjYXNlIG9mIGFjY2VzcyB0
b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hlcmUgYSByZXNvdXJjZSBvd25lciBpcyBp
bnZvbHZlZCwgc3VjaCBhcyB0aGUgYXV0aG9yaXNhdGlvbiBjb2RlIGdyYW50LCB0aGUgdmFsdWUg
b2Ygc3ViIFNIT1VMRCBjb3JyZXNwb25kIHRvIHRoZSBzdWJqZWN0IGlkZW50aWZpZXIgb2YgdGhl
IHJlc291cmNlIG93bmVyLg0KDQpJZiB0aGlzIHNwZWMgaXMgYWJvdXQgaW50ZXJvcCwgSSB0aGlu
ayB0aGlzIHNob3VsZCBiZSBhdCBsZWFzdCBhIHJlY29tbWVuZGF0aW9uLi4uDQoNCg0K4oCU4oCU
4oCUDQpEb21pbmljayBCYWllcg0KDQoNCk9uIDIwLiBBcHJpbCAyMDIwIGF0IDA5OjQ4OjUxLCB2
aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgw
LmNvbT4gKHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8uYmVydG9j
Y2lAYXV0aDAuY29tPikgd3JvdGU6DQpUaGFua3MgRG9taW5pY2sgZm9yIHlvdXIgY29tbWVudHMh
DQpJbmxpbmUNCg0KPiBBbGwgb3RoZXIgT0F1dGggc3BlY3MgbWFrZSBhIHZlcnkgY2xlYXIgZGlz
dGluY3Rpb24gYmV0d2VlbiB1c2VycyBhbmQgY2xpZW50Lg0KVGhlcmXigJlzIGEgbnVhbmNlIHdv
cnRoIGhpZ2hsaWdodGluZyBoZXJlOiBzdWIgIT0gdXNlci4gSW4gcHJldmlvdXMgZGlzY3Vzc2lv
bnMgb24gdGhpcyB0b3BpYyBpdCBoYXMgYmVlbiBicm91Z2h0IHVwIHRoYXQgdGhlIEpXVCBzcGVj
IGRlZmluZXMgc3ViIGFzIGlkZW50aWZ5aW5nIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0aGUgc3Vi
amVjdCBvZiB0aGUgSldULCBhbmQgdGhhdOKAmXMgbm90IG5lY2Vzc2FyaWx5IGxpbWl0ZWQgdG8g
dXNlcnMuDQoNCkhvd2V2ZXIgSSBnZXQgdGhlIHBvdGVudGlhbCBjb25mdXNpb24sIGFuZCBJIGFt
IGhhcHB5IHRvIGFkZCBjbGFyaWZ5aW5nIGxhbmd1YWdlIGlmIHlvdSBoYXZlIHNwZWNpZmljIHBh
c3NhZ2VzIGluIHRoZSBzcGFjZSB5b3UgYXJlIHBhcnRpY3VsYXJseSB3b3JyaWVkIGFib3V0OiBo
b3dldmVyIEkgZmVlbCB0aGUgbWF0dGVyIGlzIGFkZHJlc3NlZCB1cGZyb250IGJ5IHRoZSBsYW5n
dWFnZSBpbiBTZWN0aW9uIDIuMi4gaW4gdGhlIHN1YiBlbnRyeSwg4oCcSW4gY2FzZSBvZiBhY2Nl
c3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNlIG93bmVy
IGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHRoZSB2
YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLuKA
nCBhbmQgU2VjdGlvbiA1IGhhcyBhbiBlbnRpcmUgcGFyYWdyYXBoIGRpc2N1c3NpbmcgdGhpbmdz
IHRvIHdhdGNoIG91dCBpbiBhc3NpZ25pbmcgc3ViIHZhbHVlcyBpbiB0aGUgYXBwIGlkZW50aXR5
IGNhc2UuIEZlZWwgZnJlZSB0byBzdWdnZXN0IGFkZGl0aW9uYWwgbGFuZ3VhZ2UgaWYgeW91IHdh
bnQgdG8gY2xhcmlmeSBmdXJ0aGVyLg0KDQo+IHN1YiBoYXMgYSBkaWZmZXJlbnQgc2VtYW50aWMg
aGVyZSBhcyBpbiBPSURDDQpUaGUgIHNwZWMgcmVmZXJzIHRvIFJGQzc1MTkgaW4gdGhlIHN1YiBk
ZWZpbml0aW9uIGluIDIuMiwgcmF0aGVyIHRoYW4gT0lEQywgdG8gcHJlZW1wdCB0aGF0IGNvbmNl
cm4gYW5kIGtlZXAgdGhlIG9yaWdpbmFsIHN1YiBzZW1hbnRpYyBhdmFpbGFibGUuDQoNCj4gSSBh
bSBub3QgZnVsbHkgY2xlYXIgd2h5IGF1ZCBpcyByZXF1aXJlZC4NCkF1ZCBpcyB0aGVyZSBtb3N0
bHkgYmVjYXVzZSBvZiB0aHJlZSByZWFzb25zOg0KDQrigKIgICAgICAgICBNYW55IGV4aXN0aW5n
IHNwZWNzIHBvc3R1bGF0ZSBpdHMgZXhpc3RlbmNlIGluIHRoZSB0b2tlbi4gTm8gb25lIGRlY2xh
cmVzIGl0IGFzIGEgcHJvcGVyIE1VU1QgKGFwYXJ0IGZyb20gdGhlIEJDUCwgYnV0IHRoYXTigJlz
IHBhcnRpYWwpIGhvd2V2ZXIgSSB0aGluayBpdHMgaW1wb3J0YW5jZSBjb21lcyBhY3Jvc3MuLg0K
LUJlYXJlciB0b2tlbiB1c2FnZSBSRkM2NzUwIGNhbGxzIGl0IG91dCAoaW4gdGhyZWF0IG1pdGln
YXRpb24pIGFzIHRoZSBtZWNoYW5pc20gdG8gcHJldmVudCB0b2tlbiByZWRpcmVjdCAoYW5kIGFk
ZHMgc2NvcGUgcmVzdHJpY3Rpb24gYXMgYWxzbyBpbXBvcnRhbnQsIGhvd2V2ZXIgaGVyZSB3ZSBt
YWtlIGl0IG9wdGlvbmFsIHRvIGFjb2N1dCBmb3Igbm9uLWRlbGVnYXRpb25zIHNjZW5hcmlvKS4N
Ci1SZXNvdXJjZSBpbmRpY2F0b3JzIFJGQzg3MDcgcmVmZXJzIHRvIHRoZSBzYW1lIHNlY3Rpb24g
b2YgUkZDNzUxOSBhcyBvbmUgb2YgdGhlIGFzc3VtcHRpb25zIHRoYXQgbXVzdCBob2xkIHRvIHBy
ZXZlbnQgYmVhcmVyIHRva2VucyBtaXN1c2UNCi1CQ1AyMjUgbWFrZXMgYXVkIG1hbmRhdG9yeSBm
b3IgQVMgd2hpY2ggY2FuIGlzc3VlIEpXVHMgZm9yIG1vcmUgdGhhbiBvbmUgYXBwDQoNCuKAoiAg
ICAgICAgIEFwYXJ0IGZyb20gUGluZywgZm9yIHdoaWNoIHNvbWUgb2YgaXRzIGV4YW1wbGVzIGFy
ZSB3aXRob3V0IGF1ZCAoYnV0IGFsc28gd2l0aG91dCBpZGVudGlmeWluZyBzY29wZXMsIGdpdmVu
IHRoYXQgdGhlIG9uZSBJIHJldHJpZXZlZCBoYWQgb25seSDigJxvcGVuaWTigJ0pLCBhbGwgb2Yg
dGhlIHNhbXBsZSBKV1QgQVRzIEkgcmVjZWl2ZWQgZnJvbSB2ZW5kb3JzIGFsbCBmZWF0dXJlZCBh
biBhdWQuIEkga25vdyBvbmUgc2hvdWxuZOKAmXQgb3ZlcmluZGV4IG9uIHRob3NlIGV4YW1wbGVz
LCBidXQgdG9nZXRoZXIgd2l0aCB0aGUgYWJvdmUgaXQgc2VlbWVkIHRvIHBvaW50IHRvIHNvbWV0
aGluZyB1bml2ZXJzYWxseSB1c2VmdWwuIE9uZSBwb3NzaWJsZSByZWFzb24gaXMgdGhhdCB1c2Ug
b2YgYSBmb3JtYXQgZm9yIHRoZSBBVCBpcyBjb3JyZWxhdGVkIHdpdGggdG9wb2xvZ2llcyB3aGVy
ZSBBUyBhbmQgUlMgYXJlIHNlcGFyYXRlZCBieSBzb21lIGJvdW5kYXJ5IChuZXR3b3JrLCBsb2dp
Y2FsLCBidXNpbmVzcywgY29kZSBmYWN0b3JpbmcsIGV0YykgaGVuY2UgaWRlbnRpZnlpbmcgdGhl
IHJlc291cmNlIHNlZW1zIGxpa2UgYSBuYXR1cmFsIG5lZWQuIEFnYWluLCBub3QgYW4gaXJvbiBj
bGFkIGxhdywgYnV0IGFuIGluZGljYXRpb24uDQoNCuKAoiAgICAgICAgIEEgbG90IG9mIHBlb3Bs
ZSByZXB1cnBvc2UgZXhpc3RpbmcgbGlicmFyaWVzIGZvciB0aGUgSldUIEFUIGNhc2UsIGFuZCBz
b21lIHBlb3BsZSBldmVuIHNlbmRzIGlkX3Rva2VucyBpbiBsaWV1IG9mIEFUcy4gVGhhdCBkb2Vz
buKAmXQgbWVhbiB0aGF0IHdlIHNob3VsZCBjb25kb25lIGFueSBiYWQgcHJhY3RpY2VzLCBidXQg
aW4gdGlzIHBhcnRpY3VsYXIgY2FzZSBpdCBzdWdnZXN0cyB0aGF0IGxvdHMgb2YgZGV2ZWxvcGVy
cyBhbHJlYWR5IGV4cGVjdC9jYW4gaGFuZGxlIGFuIGF1ZGllbmNlIGluIHRoZSBKV1QgdXNlZCB0
byBjYWxsIHRoZWlyIEFQSQ0KTm9uZSBvZiB0aG9zZSBhcmUgYSBzbGFtIGR1bmsgYXJndW1lbnQg
Zm9yIG1hbmRhdG9yeSwgYnV0IEkgZmluZCB0aGVtIGNvbXBlbGxpbmcgZW5vdWdoIHRvIHNpbXBs
aWZ5IHZhbGlkYXRpb24gYW5kIGp1c3QgcmVxdWlyZSBhbiBhdWQgdG8gYmUgdGhlcmUsIGFzIG9w
cG9zZWQgdG8gaW50cm9kdWNlIGNvbXBsaWNhdGlvbnMgdGhhdCBtYWtlIGl0IGNvbmRpdGlvbmFs
IHRvIHRoZSBwcmVzZW5jZSBvZiBzY29wZXMgb3Igb3RoZXIgZGlzYW1iaWd1YXRpb24uIE9uZSBy
ZWFzb24gSSBmZWVsIHByZXR0eSBnb29kIGFib3V0IHRoYXQgaXMgdGhhdCBhZGRpbmcgYSBkZWZh
dWx0IGF1ZGllbmNlIGlzbuKAmXQgdmVyeSBoYXJkIGlmIGFueSBvZiB0aGUgYWJvdmUgYXNzdW1w
dGlvbnMgZW5kIHVwIG5vdCBiZWluZyB0cnVlIGZvciBhIHBhcnRpY3VsYXIgY2FzZQ0KDQo+IFdo
YXTigJlzIHRoZSByYXRpb25hbGUgZm9yIHVzaW5nIGlhdCBpbnN0ZWFkIG9mIG5iZi4NClRoYXTi
gJlzIGp1c3Qgc3RyYWlnaHQgZnJvbSBPSURDIElEX3Rva2VucywgYW5kIHRoZSBjb25zaWRlcmF0
aW9ucyBhYm91dCByZXB1cnBvc2luZyBleGlzdGluZyBsb2dpYy4gSSBzZWUgdGhlcmXigJlzIGEg
dGhyZWFkIG9uIHRoaXMgc3BlY2lmaWNhbGx5LCBsZXQgbWUgYW5zd2VyIGZ1cnRoZXIgb24gdGhh
dCBicmFuY2guDQoNCj4gVGhpcyBzcGVjIGZlZWxzIHNvbWVob3cgaW4gYmV0d2VlbiBhIHByb2Zp
bGUgYW5kIGEgQkNQDQpZb3UgYXJlIHJpZ2h0IHRoYXQgdGhpcyBzcGVjIGF0dGVtcHRzIHRvIGdv
IGJleW9uZCBqdXN0IGRlY2xhcmluZyBhIGxheW91dCwgYW5kIEkgYWdyZWUgdGhpcyBtZWFucyB0
aGF0IHRoaXMgcHJvZmlsZSB3aWxsIG5vdCBhcHBseSB0byBhYnNvbHV0ZWx5IGV2ZXJ5b25lLiBU
aGUgcmVhc29uIEkgdHJpZWQgdGhhdCByb3V0ZSAoYXQgdGhlIGNvc3Qgb2Ygd29ya2luZyB3YXkg
aGFyZGVyIGluIHRoZSBsYXN0IHllYXIgZm9yIHJlYWNoaW5nIGNvbnNlbnN1cyB0aGFuIGlmIHdl
IHdvdWxkIGhhdmUganVzdCBsaXN0ZWQgdGhlIHBvc3NpYmxlIGNvbnRlbnQpLCBpcyB0aGF0IEkg
b2Z0ZW4gb2JzZXJ2ZSBpbXBsZW1lbnRlcnMgbWFrZSBxdWVzdGlvbmFibGUgY2hvaWNlcyBiZWNh
dXNlIG9mIHRoZSBsYXJnZSBsZWV3YXkgc3BlY2lmaWNhdGlvbnMgYWxsb3cuIE15IGhvcGUgd2Fz
IHRoYXQgdGhlIHNjb3BlIG9mIHRoaXMgcHJvZmlsZSB3YXMgc21hbGwgZW5vdWdoIHRvIG1ha2Ug
dGhhdCBleHRyYSBsZXZlbCBvZiBndWlkYW5jZSBhY2hpZXZhYmxlLCB3aGVyZWFzIHRyeWluZyB0
byBkbyB0aGUgc2FtZSB3aXRoIGEgbGFyZ2VyIHNwZWMgd291bGQgaGF2ZSBiZWVuIHByb2hpYml0
aXZlbHkgZXhwZW5zaXZlLg0KSSBiZWxpZXZlIHRoaW5ncyB3b3JrZWQgb3V0IHdlbGwgc28gZmFy
OiB3ZSBoYWQgbG90cyBvZiBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbnMsIGFuZCBJIGVuZGVkIHVw
IHJlbGF4aW5nIEEgTE9UIG9mIHRoZSBjb25zdHJhaW50cyBJIHdhcyBvcmlnaW5hbGx5IGVudmlz
aW9uaW5nLiBOb25ldGhlbGVzcywgbXkgaG9wZSBpcyB0aGF0IHdlIGlkZW50aWZpZWQgdGhlIHJp
Z2h0IHNldCBvZiBndWlkZWxpbmVzIHRoYXQgd2lsbCBoZWxwIHBlb3BsZSBhY3R1YWxseSBpbnRl
cm9wZXJhdGUgb3V0IG9mIHRoZSBib3ggZm9yIHRoZSBtb3N0IGJhc2ljL2NvbW1vbiBzY2VuYXJp
b3MsIGFzIG9wcG9zZWQgdG8gY29tcGx5aW5nIHdpdGggdGhlIGxldHRlciBvZiB0aGUgc3BlYyBi
dXQgc3RpbGwgaGF2aW5nIGEgbG90IHRvIGZpZ3VyZSBvdXQgb3V0IG9mIGJhbmQuDQoNCkZyb206
IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPj4gT24gQmVoYWxmIE9mIERvbWluaWNrIEJhaWVyDQpTZW50OiBUaHVyc2RheSwgQXByaWwg
MTYsIDIwMjAgMTI6MTAgQU0NClRvOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdt
YWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj47IG9hdXRoIDxvYXV0aEBpZXRm
Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU2Vj
b25kIFdHTEMgb24gIkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBB
Y2Nlc3MgVG9rZW5zIg0KDQpTaW5jZSB0aGlzIGlzIHRoZSBsYXN0IGNhbGwsIEkgdGhvdWdodCBJ
IGJyaW5nIHVwIHNvbWUgb2YgdGhvdWdodHMgLyBjb25jZXJucy4gU29tZSBvZiB0aGVtIGhhdmUg
YmVlbiBkaXNjdXNzZWQgYmVmb3JlLg0KDQpjbGllbnRfaWQgdnMgc3ViDQpJIGFtIHN0aWxsIG5v
dCBlbnRpcmVseSBoYXBweSB3aXRoIHRoZSDigJxyZS1wdXJwb3NpbmfigJ0gb2YgdGhlIGNsYWlt
IHR5cGVzIGJhc2VkIG9uIGZsb3cuDQpJZiB0aGUgaW50ZW50aW9uIGlzLCB0aGF0IHN1YiBleHBy
ZXNzZXMgdGhlIGVudGl0eSBhZ2FpbnN0IHdoaWNoIHRoZSByZXNvdXJjZSB3aWxsIGRvIGF1dGhv
cmlzYXRpb24gKGFuZCB0aGF0IG1pZ2h0IGJlIGEgY2xpZW50IG9yIGEgdXNlcikgLSBJIGdldCBp
dCAoYW5kIG1heWJlIGl0IHNob3VsZCBiZSBzdGF0ZWQgbGlrZSB0aGF0KSAtIGJ1dA0KdGhpcyB0
aGlua2luZyByZW1pbmRzIG1lIG9mIHRoZSBvbGQgQUQgZGF5cyB3aGVyZSB0aGVyZSB3YXMgbm8g
ZGlzdGluY3Rpb24gYmV0d2VlbiB1c2VyIGFuZCBzZXJ2aWNlIGFjY291bnRzIChzb21ldGhpbmcg
dGhhdCBoYXMgYmVlbiBmaXhlZCBJSVJDIGluIFdpbmRvd3MgU2VydmVyIDIwMTIgUjIpLg0KDQpB
bGwgb3RoZXIgT0F1dGggc3BlY3MgbWFrZSBhIHZlcnkgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2Vl
biB1c2VycyBhbmQgY2xpZW50Lg0KDQpGdXJ0aGVybW9yZSBpdCBzYXlzDQoNCiJBdXRob3JpemF0
aW9uIHNlcnZlcnMgc2hvdWxkIHByZXZlbnQgc2NlbmFyaW9zIHdoZXJlIGNsaWVudHMgY2FuDQog
ICBhZmZlY3QgdGhlIHZhbHVlIG9mIHRoZSBzdWIgY2xhaW0gaW4gd2F5cyB0aGF0IGNvdWxkIGNv
bmZ1c2UgcmVzb3VyY2UNCiAgIHNlcnZlcnMu4oCdDQoNCklmIHdlIGtlZXAgdGhhdCBkdWFsIHNl
bWFudGljcyBvZiB0aGUgc3ViIGNsYWltIC0gaXQgbXVzdCBiZSBjbGVhcmx5IHN0YXRlZCwgdGhh
dCBzdWJqZWN0IElEIGFuZCBjbGllbnQgSUQgYXJlIG5vdyBpbiB0aGUgc2FtZSBjb2xsaXNpb24g
ZG9tYWluLiBTbyB3aGVuIGFuIEFTIC8gT1AgY3JlYXRlcyB0aGVtLCB0aGV5IG5lZWQgdG8gYmUg
dW5pcXVlIGFjcm9zcyB1c2VyIGlkcyBhbmQgY2xpZW50IGlkcy4NCg0KTWF5YmUgaXQgc2hvdWxk
IGJlIGFsc28gZXhwbGljaXRseSBtZW50aW9uZWQgdGhhdCBzdWIgaGFzIGEgZGlmZmVyZW50IHNl
bWFudGljIGhlcmUgYXMgaW4gT0lEQyAtIGV2ZW4gdGhvdWdoIGEgbWFqb3JpdHkgb2YgdGhlIHNv
ZnR3YXJlIGJ1aWx0IHRvZGF5IHdpbGwgdXNlIHRoZW0gdG9nZXRoZXIuDQoNCmF1ZGllbmNlIGNs
YWltDQpJIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlzIHJlcXVpcmVkLiBPQXV0aCBpdHNl
bGYgZG9lcyBub3QgaGF2ZSBhIG5vdGlvbiBvZiBhbiBhdWRpZW5jZSAoaW4gdGhlIEpXVCBzZW5z
ZSkgLSB0aGV5IGhhdmUgc2NvcGVzICh3aGljaCBpcyB2ZXJ5IHNpbWlsYXIpLiBCdXQgaW4gc2lt
cGxlIHNjZW5hcmlvcyB3aGVyZSByZXNvdXJjZXMgZG9u4oCZdCBleGlzdCwgeW91J2QgbmVlZCB0
byBtYWtlIHVwIGFuIGF1ZGllbmNlIGp1c3QgdG8gZnVsZmlsIHRoaXMgcmVxdWlyZW1lbnQuIEFu
ZCBpbiBtYW55IGNhc2UgdGhpcyB3aWxsIGJlIGVpdGhlciBzdGF0aWMgb3IganVzdCByZXBlYXQg
dGhlIHNjb3BlIHZhbHVlcy4gV2hhdOKAmXMgdGhlIHZhbHVlIG9mIHRoYXQ/DQoNCklmIHRoZSBj
b25jZXB0IG9mIHJlc291cmNlcyBhcmUgdXNlZCwgSSBhYnNvbHV0ZWx5IGFncmVlIHRoYXQgYXVk
IHNob3VsZCBiZSB1c2VkIHRvby4gQnV0IEkgd291bGRu4oCZdCBtYWtlIGl0IHJlcXVpcmVkLg0K
DQppYXQgdnMgbmJmDQpXaGF04oCZcyB0aGUgcmF0aW9uYWxlIGZvciB1c2luZyBpYXQgaW5zdGVh
ZCBvZiBuYmYuIEFyZW7igJl0IG1vc3QgSldUIGxpYnJhcmllcyAoaW5jbHVkaW5nIGUuZy4gdGhl
IC5ORVQgb25lKSBsb29raW5nIGZvciBuYmYgYnkgZGVmYXVsdD8NCg0KR2VuZXJhbA0KVGhpcyBz
cGVjIGZlZWxzIHNvbWVob3cgaW4gYmV0d2VlbiBhIHByb2ZpbGUgYW5kIGEgQkNQLiBPbiBvbmUg
aGFuZCB5b3UgZGVmaW5lIHNvbWUgY2xhaW1zIGFuZCB0aGVpciBzZW1hbnRpY3MgKGdvb2QpIC0g
b24gdGhlIG90aGVyIGhhbmQgdGhlcmUgaXMgc29tZSBwcmVzY3JpcHRpdmUgZ3VpZGFuY2UgYW5k
IG1heWJlIG92ZXItc3BlY2lmaWNhdGlvbi4gTXkgY29uY2VybiBpcywgdGhhdCBpbiB0aGUgZW5k
IG5vLW9uZSB3aWxsIGZ1bGx5IGNvbXBseSB3aXRoIGl0LCBiZWNhdXNlIGl0IGRvZXNu4oCZdCB3
b3JrIG9uZSB3YXkgb3IgdGhlIG90aGVyIGZvciB0aGVtLg0KDQpJIGtub3cgd2UganVzdCB3ZW50
IHRob3VnaCB0aGUgZGlzY3Vzc2lvbiB0byBtYWtlIGNlcnRhaW4gY2xhaW1zIHJlcXVpcmVkIGFz
IG9wcG9zZWQgdG8gb3B0aW9uYWwgLSBidXQgbWF5YmUgbGVzcyBpcyBtb3JlLg0KDQpUYmggLSB0
aGUgbW9zdCB2YWx1YWJsZSBwYXJ0IG9mIHRoZSBkb2MgdG8gbWUgaXMgdGhlIGRlZmluaXRpb24g
b2YgdGhlIOKAnGF0K2p3dOKAnSB0eXAuIEZvciB0aGUgcmVzdCBJ4oCZZCByYXRoZXIgbGlrZSB0
byBzZWUganVzdCBzb21lIHN0YW5kYXJkIGNsYWltcyBhbmQgSUYgdGhleSBhcmUgdXNlZCwgd2hp
Y2ggc2VtYW50aWNzIHRoZXkgaGF2ZS4NCg0KY2hlZXJzDQrigJTigJTigJQNCkRvbWluaWNrIEJh
aWVyDQoNCg0KT24gMTUuIEFwcmlsIDIwMjAgYXQgMjA6NTk6MzEsIFJpZmFhdCBTaGVraC1ZdXNl
ZiAocmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+KSB3
cm90ZToNCkhpIGFsbCwNCg0KVGhpcyBpcyBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs
bCBmb3IgIkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3Mg
VG9rZW5zIi4NCg0KSGVyZSBpcyB0aGUgZG9jdW1lbnQ6DQpodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2DQoNClBsZWFzZSBzZW5k
IHlvdXIgY29tbWVudHMgdG8gdGhlIE9BdXRoIG1haWxpbmcgbGlzdCBieSBBcHJpbCAyOSwgMjAy
MC4NCg0KUmVnYXJkcywNCiBSaWZhYXQgJiBIYW5uZXMNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0K

--_000_MWHPR19MB150196432E117F2C47B077D1AED50MWHPR19MB1501namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MiA2IDUgOSAyIDIgNSAy
IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp
c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz
NDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwg
bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5haXJtYWlsb24sIGxp
LmFpcm1haWxvbiwgZGl2LmFpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTphaXJtYWlsX29uOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpwLmFpcm1haWxvbjAsIGxpLmFpcm1h
aWxvbjAsIGRpdi5haXJtYWlsb24wDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxvbjsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uMDAsIGxpLmFpcm1h
aWxvbjAwLCBkaXYuYWlybWFpbG9uMDANCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbG9uMDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdWNo
ISBTb3JyeSA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkm
cXVvdDsiPiYjMTI4NTIyOzwvc3Bhbj4gZml4ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Y29sb3I6YmxhY2siPkRvbWluaWNrIEJhaWVyICZsdDtkYmFpZXJAbGVhc3Rwcml2aWxlZ2Uu
Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBBcHJpbCAyMSwgMjAyMCBhdCAxMDoy
Mzxicj4NCjxiPlRvOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0OywgUmlmYWF0IFNo
ZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBWaXR0b3JpbyBCZXJ0b2Nj
aSAmbHQ7dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv
Yj5SZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldU
KSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PaCBhbmQgd2hpbGUg
d2UgYXJlIGF0IGl0IC0gY291bGQgeW91IGFsc28gZml4IHRoZSB0eXBvIGluIG15IG5hbWU/IFRo
YW5rcyA7KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCU
4oCU4oCUIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWlu
aWNrIEJhaWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj5PbiAyMS4g
QXByaWwgMjAyMCBhdCAwOTo0Mzo0OSwgVml0dG9yaW8gQmVydG9jY2kgKDxhIGhyZWY9Im1haWx0
bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iPnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNv
bTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgYSBncmVhdCBwb2ludC4gSW4gbXkgaGVhZCBJIGp1
c3QgY29uc2lkZXJlZCB0aGUgT0lEQyBzZW1hbnRpYyBhbmQgdGhvdWdodCBvbmx5IG9mIGhpZ2hs
aWdodGluZyB0aGUgYXBwIGlkZW50aXR5IGNhc2UsIGJ1dCB5b3UgYXJlIGFic29sdXRlbHkgcmln
aHQgdGhhdCBub3QgbWVudGlvbmluZyB0aGUNCiB1c2VyIGNhc2UgYXQgYWxsIGlzIGNvbmZ1c2lu
Zy4gSSBhZGRlZCB0aGUgbGFuZ3VhZ2UgeW91IHN1Z2dlc3RlZCBhdCB0aGUgYmVnaW5uaW5nIG9m
IHRoZSBzdWIgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy
b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr
Ij5Eb21pbmljayBCYWllciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVn
ZS5jb20iPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv
Yj5Nb25kYXksIEFwcmlsIDIwLCAyMDIwIGF0IDIyOjU0PGJyPg0KPGI+VG86IDwvYj5vYXV0aCAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
LCBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFp
bC5jb20iPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls
dG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIj52aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5j
b208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAu
Y29tIj52aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6
IDwvYj5SRTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAo
SldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90Ozwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw
cmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPkluIGNhc2Ugb2YgYWNjZXNzIHRva2VucyBvYnRhaW5lZCB0aHJvdWdoIGdyYW50cyB3aGVy
ZSBubyByZXNvdXJjZSBvd25lciBpcyBpbnZvbHZlZCwgc3VjaCBhcyB0aGUgY2xpZW50IGNyZWRl
bnRpYWxzIGdyYW50LCB0aGUgdmFsdWUgb2Ygc3ViIFNIT1VMRCBjb3JyZXNwb25kIHRvIGFuIGlk
ZW50aWZpZXIgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzZXMgdG8gaW5kaWNhdGUgdGhlIGNs
aWVudCBhcHBsaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcs
IGJ1dCBkb2VzIGl0IHNheSBhbnl3aGVyZSB3aGF0IHRvIGV4cGxpY2l0bHkgZG8gaW4gdGhlIGNh
c2Ugb2YgYW4gYWNjZXNzIHRva2VuIHdoZXJlIGEgcmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQ/
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5UaGVyZeKAmXMgc29tZSBsYW5ndWFnZSB0aGF0IHNlZW1zIHRvIGltcGx5IHRoYXQsIGUuZy46
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC1icmVh
azpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci10b3AtbGVmdC1yYWRpdXM6
NHB4O2JvcmRlci10b3AtcmlnaHQtcmFkaXVzOjRweDtib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1
czo0cHg7Ym9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1czo0cHg7Zm9udC12YXJpYW50LWxpZ2F0dXJl
czpub3JtYWw7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90OyI+YXMgdGhpcyB3b3VsZCBhbGxvdyBtYWxpY2lv
dXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWst
YWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBN
b25vJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY2xpZW50cyB0byBzZWxlY3QgdGhlIHN1YiBvZiBhIGhp
Z2ggcHJpdmlsZWdlIHJlc291cmNlIG93bmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgaGF2ZSBleHBlY3RlZCB0
byBzZWUgc29tZXRoaW5nIHN0cm9uZ2VyIGxpa2UgYWJvdmUganVzdCAtJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv
cmQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBjYXNlIG9mIGFjY2VzcyB0b2tl
bnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hlcmUgYSByZXNvdXJjZSBvd25lciBpcyBpbnZv
bHZlZCwgc3VjaCBhcyB0aGUgYXV0aG9yaXNhdGlvbiBjb2RlIGdyYW50LCB0aGUgdmFsdWUgb2Yg
c3ViIFNIT1VMRCBjb3JyZXNwb25kIHRvIHRoZSBzdWJqZWN0IGlkZW50aWZpZXIgb2YgdGhlIHJl
c291cmNlIG93bmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhpcyBzcGVjIGlzIGFib3V0IGludGVyb3AsIEkg
dGhpbmsgdGhpcyBzaG91bGQgYmUgYXQgbGVhc3QgYSByZWNvbW1lbmRhdGlvbi4uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAlOKAlOKAlA0KPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb21pbmljayBCYWllcjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uMCI+T24gMjAuIEFwcmlsIDIw
MjAgYXQgMDk6NDg6NTEsIDxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5j
b20iPg0Kdml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9hPiAoPGEgaHJlZj0ibWFpbHRvOnZp
dHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSI+dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9h
Pikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+VGhhbmtzIERvbWluaWNrIGZvciB5b3VyIGNvbW1lbnRzITxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmU8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxpPiZndDs8L2k+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj4gQWxsIG90aGVyIE9BdXRoIHNwZWNzIG1ha2UgYSB2ZXJ5IGNs
ZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlcnMgYW5kIGNsaWVudC48L3NwYW4+PC9pPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZeKAmXMgYSBudWFuY2Ugd29y
dGggaGlnaGxpZ2h0aW5nIGhlcmU6IHN1YiAhPSB1c2VyLiBJbiBwcmV2aW91cyBkaXNjdXNzaW9u
cyBvbiB0aGlzIHRvcGljIGl0IGhhcyBiZWVuIGJyb3VnaHQgdXAgdGhhdCB0aGUgSldUIHNwZWMg
ZGVmaW5lcyBzdWIgYXMgaWRlbnRpZnlpbmcgdGhlIHByaW5jaXBhbCB0aGF0DQogaXMgdGhlIHN1
YmplY3Qgb2YgdGhlIEpXVCwgYW5kIHRoYXTigJlzIG5vdCBuZWNlc3NhcmlseSBsaW1pdGVkIHRv
IHVzZXJzLiA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ib3dldmVyIEkg
Z2V0IHRoZSBwb3RlbnRpYWwgY29uZnVzaW9uLCBhbmQgSSBhbSBoYXBweSB0byBhZGQgY2xhcmlm
eWluZyBsYW5ndWFnZSBpZiB5b3UgaGF2ZSBzcGVjaWZpYyBwYXNzYWdlcyBpbiB0aGUgc3BhY2Ug
eW91IGFyZSBwYXJ0aWN1bGFybHkgd29ycmllZCBhYm91dDogaG93ZXZlciBJIGZlZWwgdGhlIG1h
dHRlciBpcyBhZGRyZXNzZWQgdXBmcm9udCBieSB0aGUgbGFuZ3VhZ2UgaW4gU2VjdGlvbiAyLjIu
IGluIHRoZSBzdWIgZW50cnksIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtjb2xvcjpibGFjayI+SW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2gg
Z3JhbnRzIHdoZXJlIG5vIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBj
bGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHRoZSB2YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3Bv
bmQgdG8gYW4gaWRlbnRpZmllciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBpbmRp
Y2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6YmxhY2siPiBhbmQgU2VjdGlvbiA1IGhhcyBhbiBlbnRpcmUgcGFyYWdyYXBoIGRpc2N1c3Np
bmcgdGhpbmdzIHRvIHdhdGNoIG91dCBpbiBhc3NpZ25pbmcgc3ViIHZhbHVlcyBpbiB0aGUgYXBw
IGlkZW50aXR5IGNhc2UuIEZlZWwgZnJlZSB0byBzdWdnZXN0IGFkZGl0aW9uYWwgbGFuZ3VhZ2Ug
aWYgeW91IHdhbnQgdG8gY2xhcmlmeSBmdXJ0aGVyLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jmd0OyBzdWIgaGFzIGEgZGlmZmVyZW50IHNlbWFudGljIGhlcmUgYXMgaW4g
T0lEQzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo
ZSAmbmJzcDtzcGVjIHJlZmVycyB0byBSRkM3NTE5IGluIHRoZSBzdWIgZGVmaW5pdGlvbiBpbiAy
LjIsIHJhdGhlciB0aGFuIE9JREMsIHRvIHByZWVtcHQgdGhhdCBjb25jZXJuIGFuZCBrZWVwIHRo
ZSBvcmlnaW5hbCBzdWIgc2VtYW50aWMgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PGk+Jmd0OzwvaT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPiBJIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlzIHJlcXVpcmVk
Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF1ZCBp
cyB0aGVyZSBtb3N0bHkgYmVjYXVzZSBvZiB0aHJlZSByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPk1hbnkgZXhpc3Rpbmcgc3BlY3MgcG9zdHVsYXRlIGl0cyBleGlz
dGVuY2UgaW4gdGhlIHRva2VuLiBObyBvbmUgZGVjbGFyZXMgaXQgYXMgYSBwcm9wZXIgTVVTVCAo
YXBhcnQgZnJvbSB0aGUgQkNQLCBidXQgdGhhdOKAmXMgcGFydGlhbCkgaG93ZXZlciBJIHRoaW5r
IGl0cyBpbXBvcnRhbmNlIGNvbWVzIGFjcm9zcy4uPGJyPg0KLUJlYXJlciB0b2tlbiB1c2FnZSBS
RkM2NzUwIGNhbGxzIGl0IG91dCAoaW4gdGhyZWF0IG1pdGlnYXRpb24pIGFzIHRoZSBtZWNoYW5p
c20gdG8gcHJldmVudCB0b2tlbiByZWRpcmVjdCAoYW5kIGFkZHMgc2NvcGUgcmVzdHJpY3Rpb24g
YXMgYWxzbyBpbXBvcnRhbnQsIGhvd2V2ZXIgaGVyZSB3ZSBtYWtlIGl0IG9wdGlvbmFsIHRvIGFj
b2N1dCBmb3Igbm9uLWRlbGVnYXRpb25zIHNjZW5hcmlvKS48YnI+DQotUmVzb3VyY2UgaW5kaWNh
dG9ycyBSRkM4NzA3IHJlZmVycyB0byB0aGUgc2FtZSBzZWN0aW9uIG9mIFJGQzc1MTkgYXMgb25l
IG9mIHRoZSBhc3N1bXB0aW9ucyB0aGF0IG11c3QgaG9sZCB0byBwcmV2ZW50IGJlYXJlciB0b2tl
bnMgbWlzdXNlDQo8YnI+DQotQkNQMjI1IG1ha2VzIGF1ZCBtYW5kYXRvcnkgZm9yIEFTIHdoaWNo
IGNhbiBpc3N1ZSBKV1RzIGZvciBtb3JlIHRoYW4gb25lIGFwcDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOw0KPC9zcGFuPkFwYXJ0IGZyb20gUGluZywgZm9yIHdoaWNoIHNvbWUgb2YgaXRzIGV4
YW1wbGVzIGFyZSB3aXRob3V0IGF1ZCAoYnV0IGFsc28gd2l0aG91dCBpZGVudGlmeWluZyBzY29w
ZXMsIGdpdmVuIHRoYXQgdGhlIG9uZSBJIHJldHJpZXZlZCBoYWQgb25seSDigJxvcGVuaWTigJ0p
LCBhbGwgb2YgdGhlIHNhbXBsZSBKV1QgQVRzIEkgcmVjZWl2ZWQgZnJvbSB2ZW5kb3JzIGFsbCBm
ZWF0dXJlZCBhbiBhdWQuIEkga25vdyBvbmUgc2hvdWxuZOKAmXQgb3ZlcmluZGV4DQogb24gdGhv
c2UgZXhhbXBsZXMsIGJ1dCB0b2dldGhlciB3aXRoIHRoZSBhYm92ZSBpdCBzZWVtZWQgdG8gcG9p
bnQgdG8gc29tZXRoaW5nIHVuaXZlcnNhbGx5IHVzZWZ1bC4gT25lIHBvc3NpYmxlIHJlYXNvbiBp
cyB0aGF0IHVzZSBvZiBhIGZvcm1hdCBmb3IgdGhlIEFUIGlzIGNvcnJlbGF0ZWQgd2l0aCB0b3Bv
bG9naWVzIHdoZXJlIEFTIGFuZCBSUyBhcmUgc2VwYXJhdGVkIGJ5IHNvbWUgYm91bmRhcnkgKG5l
dHdvcmssIGxvZ2ljYWwsIGJ1c2luZXNzLA0KIGNvZGUgZmFjdG9yaW5nLCBldGMpIGhlbmNlIGlk
ZW50aWZ5aW5nIHRoZSByZXNvdXJjZSBzZWVtcyBsaWtlIGEgbmF0dXJhbCBuZWVkLiBBZ2Fpbiwg
bm90IGFuIGlyb24gY2xhZCBsYXcsIGJ1dCBhbiBpbmRpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPkEgbG90IG9mIHBlb3BsZSByZXB1cnBvc2UgZXhpc3RpbmcgbGli
cmFyaWVzIGZvciB0aGUgSldUIEFUIGNhc2UsIGFuZCBzb21lIHBlb3BsZSBldmVuIHNlbmRzIGlk
X3Rva2VucyBpbiBsaWV1IG9mIEFUcy4gVGhhdCBkb2VzbuKAmXQgbWVhbiB0aGF0IHdlIHNob3Vs
ZCBjb25kb25lIGFueSBiYWQgcHJhY3RpY2VzLCBidXQgaW4gdGlzIHBhcnRpY3VsYXIgY2FzZSBp
dCBzdWdnZXN0cyB0aGF0IGxvdHMgb2YgZGV2ZWxvcGVycyBhbHJlYWR5DQogZXhwZWN0L2NhbiBo
YW5kbGUgYW4gYXVkaWVuY2UgaW4gdGhlIEpXVCB1c2VkIHRvIGNhbGwgdGhlaXIgQVBJPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vbmUgb2YgdGhvc2UgYXJlIGEgc2xh
bSBkdW5rIGFyZ3VtZW50IGZvciBtYW5kYXRvcnksIGJ1dCBJIGZpbmQgdGhlbSBjb21wZWxsaW5n
IGVub3VnaCB0byBzaW1wbGlmeSB2YWxpZGF0aW9uIGFuZCBqdXN0IHJlcXVpcmUgYW4gYXVkIHRv
IGJlIHRoZXJlLCBhcyBvcHBvc2VkIHRvIGludHJvZHVjZSBjb21wbGljYXRpb25zDQogdGhhdCBt
YWtlIGl0IGNvbmRpdGlvbmFsIHRvIHRoZSBwcmVzZW5jZSBvZiBzY29wZXMgb3Igb3RoZXIgZGlz
YW1iaWd1YXRpb24uIE9uZSByZWFzb24gSSBmZWVsIHByZXR0eSBnb29kIGFib3V0IHRoYXQgaXMg
dGhhdCBhZGRpbmcgYSBkZWZhdWx0IGF1ZGllbmNlIGlzbuKAmXQgdmVyeSBoYXJkIGlmIGFueSBv
ZiB0aGUgYWJvdmUgYXNzdW1wdGlvbnMgZW5kIHVwIG5vdCBiZWluZyB0cnVlIGZvciBhIHBhcnRp
Y3VsYXIgY2FzZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mZ3Q7IFdoYXTigJlzIHRo
ZSByYXRpb25hbGUgZm9yIHVzaW5nIGlhdCBpbnN0ZWFkIG9mIG5iZi4NCjwvc3Bhbj48L2k+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXTigJlzIGp1c3Qgc3RyYWln
aHQgZnJvbSBPSURDIElEX3Rva2VucywgYW5kIHRoZSBjb25zaWRlcmF0aW9ucyBhYm91dCByZXB1
cnBvc2luZyBleGlzdGluZyBsb2dpYy4gSSBzZWUgdGhlcmXigJlzIGEgdGhyZWFkIG9uIHRoaXMg
c3BlY2lmaWNhbGx5LCBsZXQgbWUgYW5zd2VyIGZ1cnRoZXIgb24gdGhhdCBicmFuY2guPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZndDsgVGhpcyBzcGVjIGZlZWxzIHNvbWVob3cgaW4g
YmV0d2VlbiBhIHByb2ZpbGUgYW5kIGEgQkNQPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+WW91IGFyZSByaWdodCB0aGF0IHRoaXMgc3BlYyBhdHRlbXB0
cyB0byBnbyBiZXlvbmQganVzdCBkZWNsYXJpbmcgYSBsYXlvdXQsIGFuZCBJIGFncmVlIHRoaXMg
bWVhbnMgdGhhdCB0aGlzIHByb2ZpbGUgd2lsbCBub3QgYXBwbHkgdG8gYWJzb2x1dGVseSBldmVy
eW9uZS4gVGhlIHJlYXNvbiBJIHRyaWVkIHRoYXQNCiByb3V0ZSAoYXQgdGhlIGNvc3Qgb2Ygd29y
a2luZyB3YXkgaGFyZGVyIGluIHRoZSBsYXN0IHllYXIgZm9yIHJlYWNoaW5nIGNvbnNlbnN1cyB0
aGFuIGlmIHdlIHdvdWxkIGhhdmUganVzdCBsaXN0ZWQgdGhlIHBvc3NpYmxlIGNvbnRlbnQpLCBp
cyB0aGF0IEkgb2Z0ZW4gb2JzZXJ2ZSBpbXBsZW1lbnRlcnMgbWFrZSBxdWVzdGlvbmFibGUgY2hv
aWNlcyBiZWNhdXNlIG9mIHRoZSBsYXJnZSBsZWV3YXkgc3BlY2lmaWNhdGlvbnMgYWxsb3cuIE15
IGhvcGUNCiB3YXMgdGhhdCB0aGUgc2NvcGUgb2YgdGhpcyBwcm9maWxlIHdhcyBzbWFsbCBlbm91
Z2ggdG8gbWFrZSB0aGF0IGV4dHJhIGxldmVsIG9mIGd1aWRhbmNlIGFjaGlldmFibGUsIHdoZXJl
YXMgdHJ5aW5nIHRvIGRvIHRoZSBzYW1lIHdpdGggYSBsYXJnZXIgc3BlYyB3b3VsZCBoYXZlIGJl
ZW4gcHJvaGliaXRpdmVseSBleHBlbnNpdmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SSBiZWxpZXZlIHRoaW5ncyB3b3JrZWQgb3V0IHdlbGwgc28gZmFyOiB3ZSBo
YWQgbG90cyBvZiBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbnMsIGFuZCBJIGVuZGVkIHVwIHJlbGF4
aW5nIEEgTE9UIG9mIHRoZSBjb25zdHJhaW50cyBJIHdhcyBvcmlnaW5hbGx5IGVudmlzaW9uaW5n
LiBOb25ldGhlbGVzcywgbXkNCiBob3BlIGlzIHRoYXQgd2UgaWRlbnRpZmllZCB0aGUgcmlnaHQg
c2V0IG9mIGd1aWRlbGluZXMgdGhhdCB3aWxsIGhlbHAgcGVvcGxlIGFjdHVhbGx5IGludGVyb3Bl
cmF0ZSBvdXQgb2YgdGhlIGJveCBmb3IgdGhlIG1vc3QgYmFzaWMvY29tbW9uIHNjZW5hcmlvcywg
YXMgb3Bwb3NlZCB0byBjb21wbHlpbmcgd2l0aCB0aGUgbGV0dGVyIG9mIHRoZSBzcGVjIGJ1dCBz
dGlsbCBoYXZpbmcgYSBsb3QgdG8gZmlndXJlIG91dCBvdXQgb2YgYmFuZC4NCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy
b206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci
Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Eb21p
bmljayBCYWllcjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMjAgMTI6
MTAgQU08YnI+DQo8Yj5Ubzo8L2I+IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDs7
IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn
PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMg
b24gJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2Vz
cyBUb2tlbnMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj5TaW5jZSB0aGlzIGlzIHRoZSBsYXN0IGNhbGwsIEkgdGhvdWdodCBJIGJyaW5nIHVwIHNv
bWUgb2YgdGhvdWdodHMgLyBjb25jZXJucy4gU29tZSBvZiB0aGVtIGhhdmUgYmVlbiBkaXNjdXNz
ZWQgYmVmb3JlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+Y2xpZW50X2lkIHZzIHN1Yjwvc3Bhbj48L2I+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSBhbSBzdGlsbCBub3Qg
ZW50aXJlbHkgaGFwcHkgd2l0aCB0aGUg4oCccmUtcHVycG9zaW5n4oCdIG9mIHRoZSBjbGFpbSB0
eXBlcyBiYXNlZCBvbiBmbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj5JZiB0aGUgaW50ZW50aW9uIGlzLCB0aGF0IHN1YiBleHByZXNz
ZXMgdGhlIGVudGl0eSBhZ2FpbnN0IHdoaWNoIHRoZSByZXNvdXJjZSB3aWxsIGRvIGF1dGhvcmlz
YXRpb24gKGFuZCB0aGF0IG1pZ2h0IGJlIGEgY2xpZW50DQogb3IgYSB1c2VyKSAtIEkgZ2V0IGl0
IChhbmQgbWF5YmUgaXQgc2hvdWxkIGJlIHN0YXRlZCBsaWtlIHRoYXQpIC0gYnV0PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPnRoaXMgdGhp
bmtpbmcgcmVtaW5kcyBtZSBvZiB0aGUgb2xkIEFEIGRheXMgd2hlcmUgdGhlcmUgd2FzIG5vIGRp
c3RpbmN0aW9uIGJldHdlZW4gdXNlciBhbmQgc2VydmljZSBhY2NvdW50cyAoc29tZXRoaW5nIHRo
YXQNCiBoYXMgYmVlbiBmaXhlZCBJSVJDIGluIFdpbmRvd3MgU2VydmVyIDIwMTIgUjIpLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+QWxsIG90aGVyIE9BdXRoIHNwZWNzIG1ha2UgYSB2ZXJ5IGNsZWFyIGRpc3RpbmN0aW9uIGJl
dHdlZW4gdXNlcnMgYW5kIGNsaWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkZ1cnRoZXJtb3JlIGl0IHNheXM8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei
PiZxdW90O0F1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQgcHJldmVudCBzY2VuYXJpb3Mgd2hl
cmUgY2xpZW50cyBjYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+Jm5ic3A7ICZuYnNwO2FmZmVjdCB0aGUgdmFsdWUgb2YgdGhlIHN1YiBj
bGFpbSBpbiB3YXlzIHRoYXQgY291bGQgY29uZnVzZSByZXNvdXJjZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsgJm5ic3A7c2Vy
dmVycy7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPklmIHdlIGtlZXAgdGhhdCBkdWFsIHNlbWFudGljcyBvZiB0aGUgc3Vi
IGNsYWltIC0gaXQgbXVzdCBiZSBjbGVhcmx5IHN0YXRlZCwgdGhhdCBzdWJqZWN0IElEIGFuZCBj
bGllbnQgSUQgYXJlIG5vdyBpbiB0aGUgc2FtZQ0KIGNvbGxpc2lvbiBkb21haW4uIFNvIHdoZW4g
YW4gQVMgLyBPUCBjcmVhdGVzIHRoZW0sIHRoZXkgbmVlZCB0byBiZSB1bmlxdWUgYWNyb3NzIHVz
ZXIgaWRzIGFuZCBjbGllbnQgaWRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+TWF5YmUgaXQgc2hvdWxkIGJlIGFsc28gZXhw
bGljaXRseSBtZW50aW9uZWQgdGhhdCBzdWIgaGFzIGEgZGlmZmVyZW50IHNlbWFudGljIGhlcmUg
YXMgaW4gT0lEQyAtIGV2ZW4gdGhvdWdoIGEgbWFqb3JpdHkgb2YgdGhlDQogc29mdHdhcmUgYnVp
bHQgdG9kYXkgd2lsbCB1c2UgdGhlbSB0b2dldGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPmF1ZGllbmNlIGNsYWlt
PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj5JIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlzIHJlcXVpcmVkLiBPQXV0aCBpdHNl
bGYgZG9lcyBub3QgaGF2ZSBhIG5vdGlvbiBvZiBhbiBhdWRpZW5jZSAoaW4gdGhlIEpXVCBzZW5z
ZSkgLSB0aGV5IGhhdmUNCiBzY29wZXMgKHdoaWNoIGlzIHZlcnkgc2ltaWxhcikuIEJ1dCBpbiBz
aW1wbGUgc2NlbmFyaW9zIHdoZXJlIHJlc291cmNlcyBkb27igJl0IGV4aXN0LCB5b3UnZCBuZWVk
IHRvIG1ha2UgdXAgYW4gYXVkaWVuY2UganVzdCB0byBmdWxmaWwgdGhpcyByZXF1aXJlbWVudC4g
QW5kIGluIG1hbnkgY2FzZSB0aGlzIHdpbGwgYmUgZWl0aGVyIHN0YXRpYyBvciBqdXN0IHJlcGVh
dCB0aGUgc2NvcGUgdmFsdWVzLiBXaGF04oCZcyB0aGUgdmFsdWUgb2YgdGhhdD88L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklm
IHRoZSBjb25jZXB0IG9mIHJlc291cmNlcyBhcmUgdXNlZCwgSSBhYnNvbHV0ZWx5IGFncmVlIHRo
YXQgYXVkIHNob3VsZCBiZSB1c2VkIHRvby4gQnV0IEkgd291bGRu4oCZdCBtYWtlIGl0IHJlcXVp
cmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+aWF0IHZzIG5iZjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2hhdOKAmXMgdGhlIHJhdGlvbmFsZSBmb3Ig
dXNpbmcgaWF0IGluc3RlYWQgb2YgbmJmLiBBcmVu4oCZdCBtb3N0IEpXVCBsaWJyYXJpZXMgKGlu
Y2x1ZGluZyBlLmcuIHRoZSAuTkVUIG9uZSkgbG9va2luZyBmb3IgbmJmIGJ5DQogZGVmYXVsdD88
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPkdlbmVyYWw8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgc3BlYyBmZWVscyBzb21laG93IGluIGJldHdlZW4g
YSBwcm9maWxlIGFuZCBhIEJDUC4gT24gb25lIGhhbmQgeW91IGRlZmluZSBzb21lIGNsYWltcyBh
bmQgdGhlaXIgc2VtYW50aWNzIChnb29kKSAtIG9uIHRoZQ0KIG90aGVyIGhhbmQgdGhlcmUgaXMg
c29tZSBwcmVzY3JpcHRpdmUgZ3VpZGFuY2UgYW5kIG1heWJlIG92ZXItc3BlY2lmaWNhdGlvbi4g
TXkgY29uY2VybiBpcywgdGhhdCBpbiB0aGUgZW5kIG5vLW9uZSB3aWxsIGZ1bGx5IGNvbXBseSB3
aXRoIGl0LCBiZWNhdXNlIGl0IGRvZXNu4oCZdCB3b3JrIG9uZSB3YXkgb3IgdGhlIG90aGVyIGZv
ciB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVs
dmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+SSBrbm93IHdlIGp1c3Qgd2VudCB0aG91Z2ggdGhlIGRpc2N1c3Npb24g
dG8gbWFrZSBjZXJ0YWluIGNsYWltcyByZXF1aXJlZCBhcyBvcHBvc2VkIHRvIG9wdGlvbmFsIC0g
YnV0IG1heWJlIGxlc3MgaXMgbW9yZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRiaCAtIHRoZSBtb3N0IHZhbHVhYmxlIHBh
cnQgb2YgdGhlIGRvYyB0byBtZSBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg4oCcYXQmIzQzO2p3
dOKAnSB0eXAuIEZvciB0aGUgcmVzdCBJ4oCZZCByYXRoZXIgbGlrZSB0byBzZWUganVzdA0KIHNv
bWUgc3RhbmRhcmQgY2xhaW1zIGFuZCBJRiB0aGV5IGFyZSB1c2VkLCB3aGljaCBzZW1hbnRpY3Mg
dGhleSBoYXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj5jaGVlcnMmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPuKAlOKAlOKAlDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+RG9taW5pY2sgQmFpZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24wMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PbiAxNS4gQXByaWwgMjAyMCBhdCAyMDo1OTozMSwg
UmlmYWF0IFNoZWtoLVl1c2VmICg8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29t
Ij5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdo
dDoxMTUlIj4NCkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzts
aW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KVGhpcyBpcyBhIHNlY29uZCB3b3JraW5nIGdyb3Vw
IGxhc3QgY2FsbCBmb3IgJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1
dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50
OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUi
Pg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt
YWNjZXNzLXRva2VuLWp3dC0wNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll
dGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KUGxlYXNlIHNlbmQgeW91
ciBjb21tZW50cyB0byB0aGUgT0F1dGggbWFpbGluZyBsaXN0IGJ5IEFwcmlsIDI5LCAyMDIwLjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0K
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6
MTE1JSI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xp
bmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7UmlmYWF0ICZhbXA7IEhhbm5lczxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0IDxi
cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+IDxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MWHPR19MB150196432E117F2C47B077D1AED50MWHPR19MB1501namp_--


From nobody Tue Apr 21 12:28:10 2020
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 DD0B93A0872 for ; Tue, 21 Apr 2020 12:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.517
X-Spam-Level: 
X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, RCVD_IN_MSPIKE_H2=-0.82, 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=aol.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 f0h5KxJDxmNk for ; Tue, 21 Apr 2020 12:28:06 -0700 (PDT)
Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 1521A3A0867 for ; Tue, 21 Apr 2020 12:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1587497285; bh=59ZBpVoG2pzYvdBERJK0ONBZqh17HVPMdvBKf5qLi9I=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=RfaAPnGOqUGjbtq5qcK6qQQW1JN5LLN9D6jGdvXh98py4nS5uQfjz6cW/4nmqEaf7EuXgQ0BYmQiQBpEZ5N1kLMw6wewx0ylDT/40DB+g1BHbD7sooq2fe47M3D0dI0ogE8DlzBDkj/CXiUa0FbAtFm4IcQ4laVD8xejQ70z6PbodgYdo57Avy2ej71W7nCFKY6Mf5HRLcYm+eCAbGpuoCyRZstZAvr+gNCE/yjW0YhXfboUqGOrjAxhWSI7b12SaBmxDLb6O2ImwVw20mVqq3713xSONth7Li4mtXkqKJz0tYxtY7Oha31y9wTozF+jqE+SSa3b84vYL4Ni3qj+mw==
X-YMail-OSG: bj2x78YVM1nVnYpiD9PaW9MHO7DtXMR.oBCuOhY3DoyjJJz0PBSGEeQ7KJjlRHg DAcgRCeEXbI.fvkhaAWGarB7SlVOhalyvUG2gKaImPnE.ImP2wU4H37CwIY62Y4JVBTuj7ofwaLr JcZfbx2CSWRN66DQKOfVa3AFwahUnVCU6cV8o0W.thCYNWG9uzU0vOCdT7lsFi0PR2lX7p5Bdkue Pnmc3FM.xoUjlwkirBQTu4OZ8lTunHPRwyDfAYaUwnDmyxMxBqBwLYuZjqJpvtGW3jzRQiZEFaqL wjWp.kvfBbXINi5kfPTU7Ep5d9LLA8ZKF5X7wNsjCx._Lk9cX4jcDRa9prbYEZTfbnUOS1YCt3nn MaiHgV01Ea.K4D97qH_D9kxIYRblW0P1uqtnJpv1lGcIFQeOA5kjnSM8D89KmHAzb_CNbONx7FC. _LLPYZSVjpxXNestmWirdtVlB8RYRRxwNQeVEfBRGH8mRapCOwIYFLgh91VgFFh021tEt0XYaF98 WzCvOjK1GQccrgMIq_pPpl24ar4kr92.DKSjYV0SzKQK5kN_UrUpnthwM.2Sx7hNIYi1fzH05rQW lZfHvSdixdciPIt.TwIy5CNv4bwP0BF6oNeABJ3wovixZU8J7WBaammeXrUTtjHVcB31PhdTtfbW ATfqPMrHVtcu3LSpg1XxMzHPS5O4raBxbfJmWdLf4GEy18iOXLSJeWwyw2gyL9H1KPpRYHUH2WeO jIrPG5ZEUNPzrdypKo1cP.U2tOJrxakhR4WR7HT.Iiz_vVIqwlXXURQv.g8ioNXKukXlf4uY7QrL X7YqNqD5hXPDsDL0VA82.eHeduw0rr41F8jtuS8m_pPgOuC7v2fAr4.YZU7aSMwG0Qa0IlTsukNI nNlHnaFEz86tmlvJMU4CUHic4dAzTJJjzK036i.beD.nRSpdlmIP9YzAlY7yu_u7BcRjK4T0v91r YPZi.EYoYcjnS9rWwB21wdSa4et5zIYqHgFcLhzvti7So7RkYyaVZUGswNmI0.P81I8uBcaKbH2p G3SA1N8OvLtYYf1ftsGl6ATc2Ime3DRzB5EiL2FjnWPfwMstm7R8dABfuvoDUldPFrjVxr4RGkP1 JImXD9mizkGHddjrIdHivLzMKgqXAfNQ8GWj7cyJ4IL9STH45MF1R22y1IMEsgiI9LIsP.IAaVIh zJFlEzwIbEzu58BbGuaaIjSvgDoIikTze_24tIBZi.wkJlzN9OK6lKCS9iL0.UP1AmAqPzZAbQNw 3q.qWSdrFUfYT1TSLn8ok40fACps7etipCpe.rnaxYscx6ngJ32pj8TWMhrIUidXCVmVj.9AFXzb gi4cyLMiZmeoZA4yZoH4DsuhMwtVuWGKpsZ_EhzoK8WJcihSgX7pn0PTDjkcg
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Tue, 21 Apr 2020 19:28:05 +0000
Received: by smtp412.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 62c3b0f783352aaa260f669c7511034e;  Tue, 21 Apr 2020 19:28:01 +0000 (UTC)
To: Mike Jones , "oauth@ietf.org" 
References: 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com>
Date: Tue, 21 Apr 2020 15:27:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8B2959EDC9A44DCF98E37107"
Content-Language: en-US
X-Mailer: WebService/1.1.15739 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: 
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 21 Apr 2020 19:28:08 -0000

This is a multi-part message in MIME format.
--------------8B2959EDC9A44DCF98E37107
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

+1

However, we should be careful how we prohibit it... because if the state 
value is actually signed, having the URL there isn't a problem as the 
attacker can not manipulate the value without breaking the signature.

On 4/20/20 5:28 PM, Mike Jones wrote:
> I've seen several circumstances where "clever" clients implement an open redirector by encoding a URL to redirect to in the state parameter value.  Attackers can then utilize this open redirector by choosing a state value.
>
> Can we please add an explicit prohibition of this practice in draft-ietf-oauth-security-topics?
>
>                                                         Thanks,
>                                                         -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------8B2959EDC9A44DCF98E37107
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

      

      However, we should be careful how we prohibit it... because if the
      state value is actually signed, having the URL there isn't a
      problem as the attacker can not manipulate the value without
      breaking the signature.

    

    
On 4/20/20 5:28 PM, Mike Jones wrote:

    

    

      
I've seen several circumstances where "clever" clients implement an open redirector by encoding a URL to redirect to in the state parameter value.  Attackers can then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in draft-ietf-oauth-security-topics?

                                                       Thanks,
                                                       -- Mike




      

      

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


    

    

  


--------------8B2959EDC9A44DCF98E37107--


From nobody Tue Apr 21 14:35:26 2020
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 848DA3A0AD3 for ; Tue, 21 Apr 2020 14:35:25 -0700 (PDT)
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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 8d1O4d09gzJb for ; Tue, 21 Apr 2020 14:35:23 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 0F0EB3A0AC9 for ; Tue, 21 Apr 2020 14:35:22 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id u16so5186485wmc.5 for ; Tue, 21 Apr 2020 14:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cuhRNnxPkA04g8SgNTYSGVff8qUMCMvcTS085W0u8nU=; b=KDPKBFtnVJEC3HOGsK/QT107MGE0JMx0Dfj67frCOpGbr9ezOKUfThCZT0IXhIdQPP D55TMglv3WRA2blMte/zCXDfPHPIU/Jzp03L7IVevKY4yHsh+2nLfAOWEIfyMNVnLGWM rWVBB6kGDgavuXiBPHqSYlmjalht48tWWt6/s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cuhRNnxPkA04g8SgNTYSGVff8qUMCMvcTS085W0u8nU=; b=ewjRNX8QujCgNLEAmRr9qJBNhkEdjmdVxDNAnZ+30rhDtmN2TxltnQK2KcS/fGcguh vn42bB9DM2zFcsGVR6e2KMIn4+OrvhhKdykuhH/2Szrtlt4lu9uSCkuK/FgFjtZjkW4K SYZ24QtAM6Ru/TYKBJUT+2scqZQGthoQ5lsiPNj/VXKchsV4ZdpxsttH5T3WqOww0lYY I3bdh/SmfS1VUVvzaIC5wQZtXarcB6MWnfyAy3WigpP7XvWDCCBqIsD32Fjb0/26CYdU g25O6Xv8IF1h+0ppHiD7EsanIHytBOqZuAgymxtwImxrF7MINXFKBQ4x157DYfXsOtJf smfQ==
X-Gm-Message-State: AGi0PuZe+1rGBL8FOUWg0uPbCv3suaKNPc2Eq0QcNlp7mKmNV6LTp06Q e9UYipKOUM37uS+7WMxu2mB6zYPgYzfo3RdiCuIZ7wxrDx2m4UsAscJ6OjUoIojv8zw2RZqG7Yo mktPRh6CJK9UM6+kL0vUszEdoVf3m2zZ3UWHZAz9tm09Dl1EdOMYoxzFi/NhPJz8=
X-Google-Smtp-Source: APiQypKsWl5x4JPr1rTRlDDx22y+m7CTvOfnu0lwnVnR5uprI4kLTrupZHGPRSljaGH+9bQtaItjiQ==
X-Received: by 2002:a1c:5502:: with SMTP id j2mr7417095wmb.56.1587504921125; Tue, 21 Apr 2020 14:35:21 -0700 (PDT)
Received: from [10.0.0.3] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id a20sm5663953wra.26.2020.04.21.14.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Apr 2020 14:35:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-768CBC63-9179-402C-8B95-086B5C91546D
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Tue, 21 Apr 2020 22:35:18 +0100
Message-Id: <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com>
References: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com>
Cc: Mike Jones , "oauth@ietf.org" 
In-Reply-To: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com>
To: George Fletcher 
X-Mailer: iPhone Mail (17D50)
Archived-At: 
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 21 Apr 2020 21:35:26 -0000

--Apple-Mail-768CBC63-9179-402C-8B95-086B5C91546D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think the correct defence is to validate the URL (eg check against a white=
list) at the point you are going to redirect to it after the OAuth flow comp=
letes, rather than before you begin the OAuth flow.=20

But this feels like generic web app security advice rather than anything spe=
cific to OAuth - always validate URLs before performing a redirect.

Neil

> On 21 Apr 2020, at 20:28, George Fletcher  wrote:
>=20
> =EF=BB=BF +1
>=20
> However, we should be careful how we prohibit it... because if the state v=
alue is actually signed, having the URL there isn't a problem as the attacke=
r can not manipulate the value without breaking the signature.
>=20
>> On 4/20/20 5:28 PM, Mike Jones wrote:
>> I've seen several circumstances where "clever" clients implement an open r=
edirector by encoding a URL to redirect to in the state parameter value.  At=
tackers can then utilize this open redirector by choosing a state value.
>>=20
>> Can we please add an explicit prohibition of this practice in draft-ietf-=
oauth-security-topics?
>>=20
>>                                                        Thanks,
>>                                                        -- Mike
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-768CBC63-9179-402C-8B95-086B5C91546D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I think the correct defenc=
e is to validate the URL (eg check against a whitelist) at the point you are=
 going to redirect to it after the OAuth flow completes, rather than before y=
ou begin the OAuth flow. 


There=E2=80=99s some language that seems to imply that, e.g.:

as this would allow malicious
   clients to select the sub of a high privilege resource owner
=

I would have expected to see something stronger like above just -=C2=
=A0

In case of access tokens obtained through grants where a =
resource owner is involved, such as the authorisation code grant, the value of sub SHOULD c=
orrespond to the subject identifier of the resource owner.

If this spec is about interop, I think this sh=
ould be at least a recommendation...


 
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
 
On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wr=
ote:
 
Thanks Dominick for your comments!
Inline
=C2=A0
> All other OAuth specs make a very clear distinction=
 between users and client.
There=E2=80=
=99s a nuance worth highlighting here: sub !=3D user. In previous discussio=
ns on this topic it has been brought up that the JWT spec defines sub as id=
entifying the principal that is the subject of the JWT, and that=E2=80=99s =
not necessarily limited to users. 
However I get the potential con=
fusion, and I am happy to add clarifying language if you have specific pass=
ages in the space you are particularly worried about: however I feel the ma=
tter is addressed upfront by the language in Section 2.2. in the sub entry,=
 =E2=80=9CIn case of ac=
cess tokens obtained through grants where no resource owner is involved, su=
ch as the client credentials grant, the value of sub SHOULD correspond to a=
n identifier the authorization server uses to indicate the client applicati=
on.=E2=80=9C and Section 5 has an entire paragraph disc=
ussing things to watch out in assigning sub values in the app identity case=
. Feel free to suggest additional language if you want to clarify further. =

=C2=A0
> sub has a differ=
ent semantic here as in OIDC
The =C2=
=A0spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC, t=
o preempt that concern and keep the original sub semantic available.
=C2=A0
> I am=
 not fully clear why aud is required.
=
Aud is there mostly because of three reasons:
  • Many existing specs postulate its existence in the token. No one declares =
it as a proper MUST (apart from the BCP, but that=E2=80=99s partial) howeve=
r I think its importance comes across..
    -Bearer token usage RFC6750 call=
s it out (in threat mitigation) as the mechanism to prevent token redirect =
(and adds scope restriction as also important, however here we make it opti=
onal to acocut for non-delegations scenario).
    -Resource indicators RFC87=
07 refers to the same section of RFC7519 as one of the assumptions that mus=
t hold to prevent bearer tokens misuse 
    -BCP225 makes aud mandatory for =
AS which can issue JWTs for more than one app
  • Apart from Ping, for which some of its ex=
amples are without aud (but also without identifying scopes, given that the=
 one I retrieved had only =E2=80=9Copenid=E2=80=9D), all of the sample JWT =
ATs I received from vendors all featured an aud. I know one shoulnd=E2=80=
=99t overindex on those examples, but together with the above it seemed to =
point to something universally useful. One possible reason is that use of a=
 format for the AT is correlated with topologies where AS and RS are separa=
ted by some boundary (network, logical, business, code factoring, etc) henc=
e identifying the resource seems like a natural need. Again, not an iron cl=
ad law, but an indication.
  • A lot of people repurpose existing libraries for the JWT AT =
case, and some people even sends id_tokens in lieu of ATs. That doesn=E2=80=
=99t mean that we should condone any bad practices, but in tis particular c=
ase it suggests that lots of developers already expect/can handle an audien=
ce in the JWT used to call their API
None o=
f those are a slam dunk argument for mandatory, but I find them compelling =
enough to simplify validation and just require an aud to be there, as oppos=
ed to introduce complications that make it conditional to the presence of s=
copes or other disambiguation. One reason I feel pretty good about that is =
that adding a default audience isn=E2=80=99t very hard if any of the above =
assumptions end up not being true for a particular case
=C2=A0
> What=E2=80=99s=
 the rationale for using iat instead of nbf. 
That=E2=80=99s just straight from OIDC ID_tokens, and the considera=
tions about repurposing existing logic. I see there=E2=80=99s a thread on t=
his specifically, let me answer further on that branch.
=C2=A0
> This spec feel=
s somehow in between a profile and a BCP
You are right that this spec attempts to go beyond just declaring a layo=
ut, and I agree this means that this profile will not apply to absolutely e=
veryone. The reason I tried that route (at the cost of working way harder i=
n the last year for reaching consensus than if we would have just listed th=
e possible content), is that I often observe implementers make questionable=
 choices because of the large leeway specifications allow. My hope was that=
 the scope of this profile was small enough to make that extra level of gui=
dance achievable, whereas trying to do the same with a larger spec would ha=
ve been prohibitively expensive. 
I believe thing=
s worked out well so far: we had lots of constructive discussions, and I en=
ded up relaxing A LOT of the constraints I was originally envisioning. None=
theless, my hope is that we identified the right set of guidelines that wil=
l help people actually interoperate out of the box for the most basic/commo=
n scenarios, as opposed to complying with the letter of the spec but still =
having a lot to figure out out of band. 
=C2=A0
From: OAuth <oauth-bounces@ietf.org> On Behalf Of=
 Dominick Baier
Sent: Thursday, April 16, 2020 12:10 AM
To: Rifaat Shekh-Yusef <ri=
faat.ietf@gmail.com>; oauth <oa=
uth@ietf.org>
Subject: Re: [OAUTH-WG] Second WGLC on "=
;JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
=C2=A0
Since t=
his is the last call, I thought I bring up some of thoughts / concerns. Som=
e of them have been discussed before.
=C2=A0
client_i=
d vs sub
I am =
still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of the cla=
im types based on flow.
If t=
he intention is, that sub expresses the entity against which the resource w=
ill do authorisation (and that might be a client or a user) - I get it (and=
 maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there w=
as no distinction between user and service accounts (something that has bee=
n fixed IIRC in Windows Server 2012 R2).
=C2=A0
All othe=
r OAuth specs make a very clear distinction between users and client.
=C2=A0
Furthermore it says
=C2=A0
"Au=
thorization servers should prevent scenarios where clients can
=C2=A0 =C2=A0affect the value of the sub=
 claim in ways that could confuse resource
=C2=A0 =C2=A0servers.=E2=80=9D
=C2=A0
If =
we keep that dual semantics of the sub claim - it must be clearly stated, t=
hat subject ID and client ID are now in the same collision domain. So when =
an AS / OP creates them, they need to be unique across user ids and client =
ids.
=C2=A0
=

Maybe it should be also explicitly mentioned=
 that sub has a different semantic here as in OIDC - even though a majority=
 of the software built today will use them together.
<=
p class=3D"MsoNormal">=C2=A0
audience claim
I am not fully clear why aud is required. OAuth itself does not hav=
e a notion of an audience (in the JWT sense) - they have scopes (which is v=
ery similar). But in simple scenarios where resources don=E2=80=99t exist, =
you'd need to make up an audience just to fulfil this requirement. And =
in many case this will be either static or just repeat the scope values. Wh=
at=E2=80=99s the value of that?
=C2=A0
If the concept of=
 resources are used, I absolutely agree that aud should be used too. But I =
wouldn=E2=80=99t make it required.
=C2=A0
iat vs nbf<=
/span>
What=E2=80=99s=
 the rationale for using iat instead of nbf. Aren=E2=80=99t most JWT librar=
ies (including e.g. the .NET one) looking for nbf by default?
=C2=A0
General
This spec feels somehow in between a profile and a BCP. On one ha=
nd you define some claims and their semantics (good) - on the other hand th=
ere is some prescriptive guidance and maybe over-specification. My concern =
is, that in the end no-one will fully comply with it, because it doesn=E2=
=80=99t work one way or the other for them.
=C2=A0
I k=
now we just went though the discussion to make certain claims required as o=
pposed to optional - but maybe less is more.
=C2=A0
Tbh=
 - the most valuable part of the doc to me is the definition of the =E2=80=
=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see just so=
me standard claims and IF they are used, which semantics they have.<=
/p>
=C2=A0
cheers=C2=A0
=E2=80=
=94=E2=80=94=E2=80=94
Dominick Bai=
er
=C2=A0
On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:
<=
div>
Hi all,
=C2=A0
This is a second working group last call for &qu=
ot;JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".
=C2=A0
Here is the document:
https://tools.ietf.org/html/draft-ietf-oaut=
h-access-token-jwt-06
=C2=A0
Please send=
 your comments to the OAuth mailing list by April 29, 2020.
=C2=A0
Regards,
=C2=A0Rifaat & Hannes
=C2=A0
___________________=
____________________________ 
OAuth mailing list 
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth <=
/p>
But this feels like generic web app security advice rather than anything=
 specific to OAuth - always validate URLs before performing a redirect.

Neil

=

On 21 Apr 2020, at 20:28, George Fletcher <gffl=
etch=3D40aol.com@dmarc.ietf.org> wrote:

=EF=BB=BF
 =20
    
 =20
 =20
    +1

      

      However, we should be careful how we prohibit it... because if the
      state value is actually signed, having the URL there isn't a
      problem as the attacker can not manipulate the value without
      breaking the signature.

    

    
On 4/20/20 5:28 PM, Mike Jones wrote:
=

    

    

      
I've seen several circumstances=
 where "clever" clients implement an open redirector by encoding a URL to re=
direct to in the state parameter value.  Attackers can then utilize this ope=
n redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in draft-ietf-oau=
th-security-topics?

                                                       Thanks,
                                                       -- Mike




      

      

      
_______________________________=
________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

 =20

_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth
=

--Apple-Mail-768CBC63-9179-402C-8B95-086B5C91546D--


From nobody Tue Apr 21 15:49:05 2020
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 9BBF13A0D34 for ; Tue, 21 Apr 2020 15:49:03 -0700 (PDT)
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=pingidentity.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 CqdWiNBVCLVR for ; Tue, 21 Apr 2020 15:48:59 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A19593A0D32 for ; Tue, 21 Apr 2020 15:48:58 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id u15so251970ljd.3 for ; Tue, 21 Apr 2020 15:48:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=AQOaCxwllQXUZvzOKl5BOI9CVJOr+/7BtxlHitnITII=; b=VFK2WnfehgFuLq9A3ezspprKj+1hTIAzaJ6UCNFF9k6Uj2S7MWvAtOoLItC1TDYy5/ r8eDDQKteBsqDoBATF3/8GlNuD0V4F8m4tVI5BzMa+dtYHrDCKNLvNKZeEeJaBHd6XEL xuRylongihyLBt0X2m7NSi+r5Xod2InCUfbvNFOsCMYegBtButW0l1rjPFv88iDyxrxl ALdnNrwAVY444rvkUJlDPC0OefiYKdcbvjD0Z+HIsmGjnSmcRS+FDUAQKWpjFa0eSgxV XbSs4ctwHUiKh7BK1YbtyRZKDFAHoYpm3PyWrbkBMPyDufDTZIbR2ZcHpO4TKYbP1rTC 16WA==
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=AQOaCxwllQXUZvzOKl5BOI9CVJOr+/7BtxlHitnITII=; b=QPKqZZqN4A0qfbh/9vV2MXgNWUI/seBvaJYFWHLd6YTAa+mfCNjd5LaPBpgYRZQeh7 W0EH7hG4riLk0FN3LFjBivf2ECKRXIloGierEq34ESPblxNMBurM/QpUTw8YuaisazY6 vFujWC+UcgIXN8R3rsBhBmSpswO8NWZF09uIVd1t/WTYniUMy34M8sjqPBVwNHCXflHB 99RdLaTL24vwmxus621NmtKKxIN1E5QbBVrBnGU3zsduI/5mIegMq47RefurxeDTnbzT 08vs8OyMXggfO1299smLE+I5XLsudDaTH9hG+m7LUEVtYp68zWZhiV4luDqPZRshDosL wWnQ==
X-Gm-Message-State: AGi0PubERc854iH2pCXmCd9yGrko+YB/gzrYeTooHHJkdLL8aWVWowuJ vTjlkwr1paOmfuXousi1nAURijr80+irLowL/T35zrYOA3KFOB94n4Nfyeoq9zOwCo6EGe631Ti f1mNOclmtlu5JmVtJEOY=
X-Google-Smtp-Source: APiQypJAe9Z/4yJa77mk1nDrdGI2r28OlDBkkOP7fQeVFXsVENrmNvuExR9OWurfjdSW+/MH6a/uhBrGbOKkF5l6JtM=
X-Received: by 2002:a2e:b8c1:: with SMTP id s1mr15017354ljp.0.1587509335834; Tue, 21 Apr 2020 15:48:55 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell 
Date: Tue, 21 Apr 2020 16:48:29 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000000a578a05a3d4d2fa"
Archived-At: 
Subject: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
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, 21 Apr 2020 22:49:04 -0000

--0000000000000a578a05a3d4d2fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Been working on this on and off for a while now (it's not exactly short at
80+ pages, various other priorities, etc.) but wanted to share my thoughts
from an initial review of the OAuth 2.1 draft before the interim next week
where it is on the agenda
https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.
So for better or worse, here's that review:

Abstract:
"replaces and obsoletes the OAuth 2.0 Authorization Framework described in
RFC 6749."
I think "replaces" is probably unnecessary here and, to be pedantic, is
arguably inaccurate because published RFCs don't ever go away or get
replaced.
Probably should also consider using the official "obsoletes" attribute
marker too for 6749 https://tools.ietf.org/html/rfc7991#section-2.45.8 and
probably also "updates"/"obsoletes" for others based on the scope of the
rest of the document (not sure how this even works with a BCP or if you can
or would want to update or obsolete a BCP) if this work proceeds. That
scope could be better described in the abstract too as discussed somewhat
in the thead
https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/
and also the 1st paragraph of
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12.
What is and isn't in scope is another larger question that I"m not even
sure how to ask. What's included vs. what's referenced? Should this doc be
incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
antithetical to what a BCP is supposed to be but it's also a bit hard to
tell how much was used. I mean, what happens if/when the BCP is updated?
And that kinda begs the question of if it should also incorporate parts of
or even replace the browser based apps draft? I guess that's a TBD circa
page 68. There was talk about the device grant being in scope but I'm not
seeing it (not saying it should or shouldn't be there but it was talked
about). I dunno exactly but those are some scope questions that come to
mind.
Speaking of obsoleting, I do want to ensure that existing extensions and
profiles of RFC 6749 that use legitimate extension points still present and
unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
not sure how that should work in practice but want to be aware of it as/if
this work progresses.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1
"is designed for use with HTTP ([RFC2616])."
I was momentarily proud of myself for knowing that RFC 2616 is obsolete but
then remembered that the nits tool can automate the check for other
obsolete or problematic references
https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-parecki=
-oauth-v2-1-01.txt
so take a look at those issues.
Probably should also check the errata of any documents this one intends to
update/obsolete or just borrowed a lot of text from to see if anything
should be applied.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.1
"The interaction between the authorization server and resource server is
beyond the scope of this specification."
Don't want to try and change the scope but perhaps a mention that things
like RFC 7662 Token Introspection and self-contained tokens a la JWT exist
here (or sec 1.4 or 7 or...) would be worthwhile.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.5
"   Steps (3), (4), (5), and (6) are outside the scope of this
   specification, as described in Section 7."
But Section 7 incorporates parts of RFC 6750 so being out of scope isn't
really true.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.8
Not too sure about this section in this document but seems that it should
at least reflect the fact that some things like RFC 8414  Authorization
Server Metadata do now exist.


https://tools.ietf.org/html/rfc6749?#section-1.9
All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2
Mentioning the existence of RFC 7591 Dynamic Client Registration here seems
appropriate. And I think it's be super useful to say that even when RFC
7591 isn't being used directly, it (and registered extensions to it
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#cl=
ient-metadata)
imply a common general data model for clients that's pretty widely used and
useful even with so called static registration that "typically involve
end-user interaction with an HTML registration form."


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.2
"Authorization servers SHOULD NOT allow clients to influence their
   "client_id" or "sub" value or any other claim if that can cause
   confusion with a genuine resource owner."
This text taken from draft-ietf-oauth-security-topic is out of context and
somewhere between meaningless and confusing here in this document. Removing
it or maybe something like this might be more appropriate:
  "Authorization servers SHOULD NOT allow clients to influence their
"client_id" value in such a way that it might cause confusion with the
identifier of a genuine resource owner during subsequent protocol
interactions."


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.3.1
"The client MAY omit
      the [client_secret] parameter if the client secret is an empty
string."
Let's remove that sentence. As Michael Peck noted in his review, it doesn't
even make sense in the context of this section describing authentication of
confidential clients using a password/client secret. And that sentence has
been the source of some other problems. More detail is in this thread
https://mailarchive.ietf.org/arch/msg/oauth/D1-FrLrSeWrg9M_ca9dbkYeruc4/


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.3.2
"Other Authorization Methods" should be "Other *Authentication* Methods"
It's probably worthwhile to note or reference the other client
authentication methods that have been specified since this text was written
in 6749 and/or point to the OAuth Token Endpoint Authentication Methods
registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#to=
ken-endpoint-auth-method
for them and also maybe mention that, despite the Token Endpoint in the
name, they are general methods of client auth to the AS when making direct
requests.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1
"The means through which the client obtains the location of the
   authorization endpoint are beyond the scope of this specification,
   but the location is typically provided in the service documentation."
Maybe add something like "or in the authorization server's metadata
document [RFC8414]."
"Request and response parameters
   MUST NOT be included more than once."
please clarify that sentence to say:
"Request and response parameters
defined by this specification MUST NOT be included more than once."


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2
"   The authorization server MUST compare the two URIs using simple
   string comparison as defined in [RFC3986], Section 6.2.1."
There's absolutely no context here for understanding what two URIs are
being compared.
Mandating full redirect_uri comparison is maybe more appropriate in 4.1.1
with the redirect_uri parameter somewhere. And 3.1.2.3. and 3.1.2.2 needs
some attention with respect to this too.
But also an exception (for the port part) to full redirect_uri comparison
is needed for loopback redirect_uris on native clients as in
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.6.1 and
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.2 and
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-10.3.3


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.1
As Michael Peck noted in his review, it's probably okay now to just mandate
TLS for HTTP redirect URIs. Although custom scheme or loopback redirect
URIs for native apps wouldn't use or require TLS.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.2 and
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.3
Seem to still allow for registration of partial redirection URIs. Which
isn't gonna work with an exact match requirement.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.2
"Request and response parameters
   MUST NOT be included more than once."
please clarify that sentence to say:
"Request and response parameters
defined by this specification MUST NOT be included more than once."
"   The means through which the client obtains the location of the token
   endpoint are beyond the scope of this specification, but the location
   is typically provided in the service documentation."
Maybe add something like "or in the authorization server's metadata
document [RFC8414]."


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.2.1
"Client authentication is critical
      when an authorization code is transmitted to the redirection
      endpoint over an insecure channel or when the redirection URI has
      not been registered in full."
Isn't full registration of redirection URI now required (other than maybe
the port for native apps) by virtue of requiring a full comparison be done
when validating the authz request?  And other than a native app using the
loopback, maybe it's time to move to require that redirection URIs be
accessed via secure channel?


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.2
"Clients are
   permitted to use "plain" only if they cannot support "S256" for some
   technical reason and know via out-of-band configuration that the
   server supports "plain"."
With code_challenge_methods_supported from Authorization Server Metadata /
RFC 8414 it doesn't have to be out-of-band anymore.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.2
 " Typically, the "code_challenge" and "code_challenge_method" values
   are stored in encrypted form in the "code" itself but could
   alternatively "
'Typically' - really?


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.3
"   *  ensure that the "redirect_uri" parameter is present if the
      "redirect_uri" parameter was included in the initial authorization
      request as described in Section 4.1.1, and if included ensure that
      their values are identical."
The reference should be to 4.1.1.3.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.4
"   An example successful response:
   HTTP/1.1 200 OK
   Content-Type: application/json;charset=3DUTF-8
   Cache-Control: no-store
   Pragma: no-cache"
Pretty sure application/json shouldn't have a charset (see note at end of
section https://tools.ietf.org/html/rfc8259#section-11)
and I've long thought that "Pragma: no-cache" shouldn't be there (see
https://mailarchive.ietf.org/arch/msg/oauth/9DdkE2P0RrUZMeZAbdf3NrMfy0w/ )
Note that these apply to most of the example responses in the draft.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.3
" specifying the grant type
   using an absolute URI (defined by the authorization server) as the
   value of the "grant_type" parameter"
The words in the parenthetical have led to questions in AD review of
documents making use of the grant type extension point (see
https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1581) and I think
"understood by the authorization server" might be better phrasing or even
removing the parenthetical all together.
RFC7522 is mentioned here as an example extension grant but maybe worth
also including mention of others like RFC7523, RFC8628, RFC8693, and maybe
even non IETF ones.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6
 "  *  _Sender-constrained refresh tokens:_ the authorization server
      cryptographically binds the refresh token to a certain client
      instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]."
Given the relative immaturity of ways to do this, maybe something more open
ended would be appropriate? This reads like token-binding or MTLS are the
only ways allowed. I'd think wording that would allow for DPoP or some
yet-to-be-defined method would be better here. Also maybe drop the
token-binding reference all together (it's long expired and doesn't look
like that's gonna change).


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-7.4.4
The SHOULDs/RECOMMENDEDs in this section seem a little overzealous and/or
too specific.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.4
Seems to be a lot of overlap and duplication between 9.4. Access Tokens
(under 9. Security Considerations) and section 7.4. Access Token Security
Considerations, which could/should maybe be reconciled.
"(#pop_tokens)" hints that some text was copied from elsewhere but the
markdown references weren't fixed/updated


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.5
"(#refresh_token_protection)" same thing about markdown references not
fixed/updated


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.6
"(#insufficient_uri_validation)", "(#mix_up)",
"(#open_redirector_on_client)","(#csrf_countermeasures)", again
"(#mix_up)", and "(#redirect_307)"


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.7
"Attacker A4 in (#secmodel)"
"The use of PKCE is RECOMMENDED to this end."
PKCE is required elsewhere so this doesn't seem quite right. Similar
comments about text ijn
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14 that
talks as though PKCE might not be there.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.17.1
"(#redir_uri_open_redir)"


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.20
"(#client_impersonating)"


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
"   *  Redirect URIs must be compared using exact string matching as per
      Section 4.1.3 of [I-D.ietf-oauth-security-topics]"
Should that maybe be qualified to cover dynamic ports on ephemeral local
http servers used for redirect URI with native clients?
BTW, does [I-D.ietf-oauth-security-topics] need to make a similar
allowance?


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#appendix-C
"TBD"
Given the potentially high visibility of an OAuth 2.1 effort, I think it'd
be worthwhile to list organizational affiliations of individuals here in
the acknowledgements along with their names. Something like what was done
in the first part of
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A=
.
This can help with visibility and justification of (sometimes not
insignificant) time spent on the work by non-authors/editors.

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000000a578a05a3d4d2fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Been working on this on and off for a while now (it&#=
39;s not exactly short at 80+ pages, various other priorities, etc.) but wa=
nted to share my thoughts from an initial review of the OAuth 2.1 draft bef=
ore the interim next week where it is on the agenda https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/=
.=C2=A0 So for better or worse, here's that review: 
=

Abstract:
"replaces and obsoletes the OAuth 2=
.0 Authorization Framework described in RFC 6749." 
I th=
ink "replaces" is probably unnecessary here and, to be pedantic, =
is arguably inaccurate because published RFCs don't ever go away or get=
 replaced. 
Probably should also consider using the official =
"obsoletes" attribute marker too for 6749 https://tools.iet=
f.org/html/rfc7991#section-2.45.8 and probably also "updates"=
/"obsoletes" for others based on the scope of the rest of the doc=
ument (not sure how this even works with a BCP or if you can or would want =
to update or obsolete a BCP) if this work proceeds. That scope could be bet=
ter described in the abstract too as discussed somewhat in the thead https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP=
7SpC5051sSy6XnLDv0/ and also the 1st paragraph of https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12. 
What is and isn't in scope is another larger question that=
 I"m not even sure how to ask. What's included vs. what's refe=
renced? Should this doc be incorporating bits of BCP 212 - OAuth 2.0 for Na=
tive Apps? Seems kinda antithetical to what a BCP is supposed to be but it&=
#39;s also a bit hard to tell how much was used. I mean, what happens if/wh=
en the BCP is updated? And that kinda begs the question of if it should als=
o incorporate parts of or even replace the browser based apps draft? I gues=
s that's a TBD circa page 68. There was talk about the device grant bei=
ng in scope but I'm not seeing it (not saying it should or shouldn'=
t be there but it was talked about). I dunno exactly but those are some sco=
pe questions that come to mind. 
Speaking of obsoleting, I do=
 want to ensure that existing extensions and profiles of RFC 6749 that use =
legitimate extension points still present and unchanged in OAuth 2.1 aren&#=
39;t inadvertently impacted by this effort. I'm not sure how that shoul=
d work in practice but want to be aware of it as/if this work progresses. <=
br>


=
"is designed for use with HTTP ([RFC2616])."=C2=A0=C2=A0 
I was momentarily proud of myself for knowing that RFC 2616 is obsol=
ete but then remembered that the nits tool can automate the check for other=
 obsolete or problematic references https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/d=
raft-parecki-oauth-v2-1-01.txt so take a look at those issues. 
Probably should also check the errata of any documents this one inte=
nds to update/obsolete or just borrowed a lot of text from to see if anythi=
ng should be applied. 


"The interaction between the authorization serv=
er and resource server is beyond the scope of this specification." 
Don't want to try and change the scope but perhaps a mentio=
n that things like RFC 7662 Token Introspection and self-contained tokens a=
 la JWT exist here (or sec 1.4 or 7 or...) would be worthwhile. 
<=
div>

"=C2=
=A0=C2=A0 Steps (3), (4), (5), and (6) are outside the scope of this
=C2=
=A0 =C2=A0specification, as described in Section 7." 
Bu=
t Section 7 incorporates parts of RFC 6750 so being out of scope isn't =
really true. 




All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days. 
<=
/div>


Mentionin=
g the existence of RFC 7591 Dynamic Client Registration here seems appropri=
ate. And I think it's be super useful to say that even when RFC 7591 is=
n't being used directly, it (and registered extensions to it https://www.iana.org/assignments/oauth-pa=
rameters/oauth-parameters.xhtml#client-metadata) imply a common general=
 data model for clients that's pretty widely used and useful even with =
so called static registration that "typically involve end-user interac=
tion with an HTML registration form."


"Authorization servers SHOULD NO=
T allow clients to influence their
=C2=A0 =C2=A0"client_id" or=
 "sub" value or any other claim if that can cause
=C2=A0 =C2=
=A0confusion with a genuine resource owner."
This text taken=
 from draft-ietf-oauth-security-topic is out of context and somewhere betwe=
en meaningless and confusing here in this document. Removing it or maybe so=
mething like this might be more appropriate:
=C2=A0 "Aut=
horization servers SHOULD NOT allow clients to influence their "client=
_id" value in such a way that it might cause confusion with the identi=
fier of a genuine resource owner during subsequent protocol interactions.&q=
uot;


<=
div>"The client MAY omit
=C2=A0 =C2=A0 =C2=A0 the [client_secret] p=
arameter if the client secret is an empty string." 
Let&=
#39;s remove that sentence. As Michael Peck noted in his review, it doesn&#=
39;t even make sense in the context of this section describing authenticati=
on of confidential clients using a password/client secret. And that sentenc=
e has been the source of some other problems. More detail is in this thread=
 https://mailarchive.ietf.org/arch/msg/oauth/D1=
-FrLrSeWrg9M_ca9dbkYeruc4/ 


https://tools.ietf.org/html/draft-parecki-oauth-v=
2-1-01#section-2.3.2
"Other Authorization Methods" =
should be "Other *Authentication*  Methods"
It's pr=
obably worthwhile to note or reference the other client authentication meth=
ods that have been specified since this text was written in 6749 and/or poi=
nt to the OAuth Token Endpoint Authentication Methods registry https://www.iana.org/assignments=
/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method for=
 them and also maybe mention that, despite the Token Endpoint in the name, =
they are general methods of client auth to the AS when making direct reques=
ts. 


<=
div>"The means through which the client obtains the location of the=C2=A0 =C2=A0authorization endpoint are beyond the scope of this specifica=
tion,
=C2=A0 =C2=A0but the location is typically provided in the service=
 documentation." 
Maybe add something like "or in t=
he authorization server's metadata document [RFC8414]." 
=

"Request and response parameters
=C2=A0 =C2=A0MUST NOT be incl=
uded more than once."
please clarify that sentence to say:
"Request and response parameters

defined by this specification MUST NOT be included more than once<=
/span>."




As Michael Peck noted in his re=
view, it's probably okay now to just mandate TLS for HTTP redirect URIs=
. Although custom scheme or loopback redirect URIs for native apps wouldn&#=
39;t use or require TLS. 


Seem to st=
ill allow for registration of partial redirection URIs. Which isn't gon=
na work with an exact match requirement. 


=

"Request and response pa=
rameters
=C2=A0 =C2=A0MUST NOT be included more than once."
please clarify that sentence to say:
"Request and res=
ponse parameters

defined by this specification MUST NOT be included more than once<=
/span>."
"=C2=A0=C2=A0 The means through which th=
e client obtains the location of the token
=C2=A0 =C2=A0endpoint are bey=
ond the scope of this specification, but the location
=C2=A0 =C2=A0is ty=
pically provided in the service documentation."
Maybe add so=
mething like "or in the authorization server's metadata document [=
RFC8414]." 


"Client authentication is critical
=C2=A0 =C2=
=A0 =C2=A0 when an authorization code is transmitted to the redirection
=
=C2=A0 =C2=A0 =C2=A0 endpoint over an insecure channel or when the redirect=
ion URI has
=C2=A0 =C2=A0 =C2=A0 not been registered in full."
Isn't full registration of redirection URI now required (other th=
an maybe the port for native apps) by virtue of requiring a full comparison=
 be done when validating the authz request?=C2=A0 And other than a native a=
pp using the loopback, maybe it's time to move to require that redirect=
ion URIs be accessed via secure channel?


"Clients are
=C2=A0 =C2=
=A0permitted to use "plain" only if they cannot support "S25=
6" for some
=C2=A0 =C2=A0technical reason and know via out-of-band =
configuration that the
=C2=A0 =C2=A0server supports "plain".&q=
uot; 
With code_challenge_methods_supported from Authorizatio=
n Server Metadata / RFC 8414 it doesn't have to be out-of-band anymore.=
=C2=A0 


=C2=A0" Typically, the "code_challenge" and "=
;code_challenge_method" values
=C2=A0 =C2=A0are stored in encrypted=
 form in the "code" itself but could
=C2=A0 =C2=A0alternativel=
y " 
'Typically' - really?

<=
div>
"=C2=A0=C2=A0 * =
=C2=A0ensure that the "redirect_uri" parameter is present if the<=
br>=C2=A0 =C2=A0 =C2=A0 "redirect_uri" parameter was included in =
the initial authorization
=C2=A0 =C2=A0 =C2=A0 request as described in S=
ection 4.1.1, and if included ensure that
=C2=A0 =C2=A0 =C2=A0 their val=
ues are identical."
The reference should be to 4.1.1.3. 
=



=
"=C2=A0=C2=A0 An example successful response:
=C2=A0 =C2=A0HTTP/1.1=
 200 OK
=C2=A0 =C2=A0Content-Type: application/json;charset=3DUTF-8
=
=C2=A0 =C2=A0Cache-Control: no-store
=C2=A0 =C2=A0Pragma: no-cache"=

Pretty sure application/json shouldn't have a charset (see n=
ote at end of section https://tools.ietf.org/html/rfc8259#section-11)=
 
and I've long thought that "Pragma: no-cache"=
 shouldn't be there (see https://mailarchiv=
e.ietf.org/arch/msg/oauth/9DdkE2P0RrUZMeZAbdf3NrMfy0w/ ) 
Note that these apply to most of the example responses in the draft. 
<=
/div>


"=
; specifying the grant type
=C2=A0 =C2=A0using an absolute URI (defined =
by the authorization server) as the
=C2=A0 =C2=A0value of the "gran=
t_type" parameter"
The words in the parenthetical have =
led to questions in AD review of documents making use of the grant type ext=
ension point (see https://mozphab-ietf.devsvcdev.mozaws.net/=
D4278#inline-1581) and I think "understood by the authorization se=
rver" might be better phrasing or even removing the parenthetical all =
together.
RFC7522 is mentioned here as an example extension grant=
 but maybe worth also including mention of others like RFC7523, RFC8628, RF=
C8693, and maybe even non IETF ones.=C2=A0 


https://tools.ietf.org/html/draft-parecki-oau=
th-v2-1-01#section-6
=C2=A0"=C2=A0 * =C2=A0_Sender-constrained =
refresh tokens:_ the authorization server
=C2=A0 =C2=A0 =C2=A0 cryptogra=
phically binds the refresh token to a certain client
=C2=A0 =C2=A0 =C2=
=A0 instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]."=
;
Given the relative immaturity of ways to do this, maybe somethi=
ng more open ended would be appropriate? This reads like token-binding or M=
TLS are the only ways allowed. I'd think wording that would allow for D=
PoP or some yet-to-be-defined method would be better here. Also maybe drop =
the token-binding reference all together (it's long expired and doesn&#=
39;t look like that's gonna change). 


=

The SHOULDs/RECOMMENDEDs =
in this section seem a little overzealous and/or too specific. 


S=
eems to be a lot of overlap and duplication between 9.4. Access Tokens (und=
er 9. Security Considerations) and section 7.4. Access Token Security Consi=
derations, which could/should maybe be reconciled.=C2=A0 
&qu=
ot;(#pop_tokens)" hints that some text was copied from elsewhere but t=
he markdown references weren't fixed/updated

<=
br>
"(#refresh_token_protectio=
n)" same thing about markdown references not fixed/updated
<=
br>

"(#ins=
ufficient_uri_validation)", "(#mix_up)", "(#open_redire=
ctor_on_client)","(#csrf_countermeasures)", again "(#mi=
x_up)", and "(#redirect_307)" 

=

"Attacker A4 in (#secmode=
l)" 
"The use of PKCE is RECOMMENDED to this end.&q=
uot;
PKCE is required elsewhere so this doesn't seem quite ri=
ght. Similar comments about text ijn https://tools.=
ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14 that talks as th=
ough PKCE might not be there.=C2=A0 


"(#redir_uri_open_redir)&quo=
t; 


=

"(#client_impersonating)" 


=

https://tools.ietf.org/html/draft-parecki-=
oauth-v2-1-01#section-12
"=C2=A0=C2=A0 * =C2=A0Redirect URIs mu=
st be compared using exact string matching as per
=C2=A0 =C2=A0 =C2=A0 S=
ection 4.1.3 of [I-D.ietf-oauth-security-topics]"
Should tha=
t maybe be qualified to cover dynamic ports on ephemeral local http servers=
 used for redirect URI with native clients? 
BTW, does [I-D.i=
etf-oauth-security-topics] need to make a similar allowance?=C2=A0


"TBD"=
 
Given the potentially high visibility of an OAuth 2.1 effor=
t, I think it'd be worthwhile to list organizational affiliations of in=
dividuals here in the acknowledgements along with their names. Something li=
ke what was done in the first part of https:=
//tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A. =
This can help with visibility and justification of (sometimes not insignifi=
cant) time spent on the work by non-authors/editors. 








<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000000a578a05a3d4d2fa--


From nobody Wed Apr 22 00:26:52 2020
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 AA40B3A09A6 for ; Wed, 22 Apr 2020 00:26:48 -0700 (PDT)
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 dxtpScHeXuqn for ; Wed, 22 Apr 2020 00:26:44 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 E38973A09A5 for ; Wed, 22 Apr 2020 00:26:43 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id ms17so565921pjb.0 for ; Wed, 22 Apr 2020 00:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=tAkHjRcpPOg5wsVgB5CWO1YjoiBRFIEUk0qyuTopV9Y=; b=QbuiNdifXlW7i8/0RDSMz05N2qFDxDsYFGpjDHVVCZsOE0pPKMKBcGAkA+tNrGHbKI HODPu3sP+2XTi8NQZZ6ax4oaN2nTy3dwSSQaB2wkWsFOyw7vdKmHTA2lT1fA5i/eFR/0 KljFCM8jQhC7r6qfluavSIfvIXGrG/13mgZss6Kpi06uh1ZcgZ8PFy7MEaP0uHg+/j4k EuAD9wGgbRdl9kfkSvCAf+wWwIxhKgtBulfBlATVXEmXcIl/8gq2ZikLZCJK8VM+PPEE 2Abr0CsZNgGxs0FfQuJQ6UxAvN0iuycwF3D0VHRUc6pFNS4kQs8hQ5/Gcb5sHkcpAJPx okxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=tAkHjRcpPOg5wsVgB5CWO1YjoiBRFIEUk0qyuTopV9Y=; b=Bogdeqj/fQ802MqHCg2cSRWae+j7AfS1uHppj8xJljHQGxchCzspncatkiuhpSq4dQ 3OYTShKJ1Q7pPP4vsu8/cOpGag2h9UYH8Cgf6e4cZ8DG68m0oeSMxfAuS3tWX9JH4UYk cyrJokIUdcWQJYfXsrlnrKGGDnZWFi4ixGhcEQ0tdcsnnDUvz0XWnTEKxE2ZdifoC7Rd DujWro5usCU7iQ5RbjYGHjtM4dadscQkDWq+CS6MPkmw7X6AOWtAo993JL+FCSDkW0+L lTgYOtjZai+9MVEA/on2rj/cwhry1GoULuYl8OmfOxmJfUhDg6uaQtIM1XTI9bdimNGS quZQ==
X-Gm-Message-State: AGi0PuaOck6p5ruPeE+MlEqGsP7C6J+54xJFoOeZngkot6pMEK09pYX4 f+BSn/pvaPBgiSAox3OHGhcXoA==
X-Google-Smtp-Source: APiQypIrTVgkRbCJhJCPO2JloirCVVOBShan0u8BxsWQv1VPTSUbXW6m9GPi1LnFgSBbibowt1cS/g==
X-Received: by 2002:a17:902:8f90:: with SMTP id z16mr13633548plo.283.1587540402854;  Wed, 22 Apr 2020 00:26:42 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id c59sm4742034pje.10.2020.04.22.00.26.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2020 00:26:42 -0700 (PDT)
From: Vittorio Bertocci 
To: Mike Jones , oauth , Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: ATA3REUwwLM5q/LpIqzgbOsmuIv70cvCZjA6
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 22 Apr 2020 07:26:40 +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: multipart/alternative; boundary="_000_MWHPR19MB15017DDCA5AA4C8CC95605F8AED20MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 22 Apr 2020 07:26:49 -0000

--_000_MWHPR19MB15017DDCA5AA4C8CC95605F8AED20MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks Mike! Those are great comments.
Inline- also, who should I put in the acknowledgements for this contributio=
n? Or does the commenter wish to remain anonymous?

>spaces, typos, abbreviations etc
Fixed, thx!

> Use of =93MUST=94 saying one form must be used, followed by =93SHOULD=94 =
saying a different format should be used is a bit confusing. I get the poin=
t, but I had to read it several times.
The language follows fairly closely https://tools.ietf.org/html/rfc8417#sec=
tion-2.3. I think the twist here is that the MUST refers to the need to use=
 that media type rather than that particular format.

> Does this mean these claims should only be used when the subject is a use=
r? If so, then it might be good to clarify.
Good catch! I added language clarifying that those claims may be used in th=
e context of grants involving the resource owner. I didn=92t add language e=
xplicitly disallowing using acr/amr/auth_time in case of client only grants=
. Open to feedback on whether that=92s necessary.

> Use of =93resource owner=94 suggests the resource owner is the subject of=
 the token. This is not always true. In client credentials it=92s not, and =
even in scenarios with a user, is it necessarily the resource owner who is =
authenticated/authorized? (Or could it be a different user who has been sep=
arate authorized for the requested access by the resource owner?)
Similarly to the above, I think it=92s worth clarifying that the section re=
fers to grants where the resource owner is involved. I am adding language t=
o that effect.
For the delegation cascade scenario, I=92d prefer to avoid the complication=
 and stick with attributes of the authenticated subject.

> Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 o=
f this doc.
Oh wow. That=92s a feature of XML2RFC,=85 my source simply says by section =
4.1.2 of SCIM Core  in a  block, and the processor interpret it as an in=
ternal link. I=92ll need to dig on how to prevent that from happening for t=
his instance. Good catch!

>, =93groups=94 does have a syntax defined in SCIM
Hmm. What I really meant there is that there=92s no enumeration with fixed =
values, rather than a schema- but I can see how that might be confusing. Al=
so, I am not crazy about forcing people to build a composite structure when=
 a simple string might suffice. I=92ll cull =93As in their original definit=
ion in [RFC7643]=94.

> States the configuration metadata is used to: =93advertise to resource se=
rvers [and] what iss claim value to expect via the issuer metadata value=94=
. This seems circular, since the configuration metadata is itself obtained =
by appending a suffix to a known (and trusted) issuer value, right?
Well, maybe. It=92s true that an AS implementing RFC8414 must serve its met=
adata on a URL containing the issuer, but that=92s not necessarily the meth=
od a client in real scenarios will use to resolve that URL-  think metadata=
 document cached locally from earlier runs, a private URL mapper or any oth=
er proprietary discovery mechanism. I am not advocating that clients should=
 use any other method than direct retrieval from the well known URL, but gi=
ven that the issuer info is available in both the URL and the metadata, I s=
ee no harm in recommending that the value ins extracted from the metadata i=
f that results in a more generally applicable approach.

> The value =93application/at+jwt=94 should also be accepted.
>From the way it=92s currently phrased, both values should indeed be mention=
ed. Fixing that

> if the =93typ=94 value is not =93at+jwt=94, it should rejected for this p=
rofile. (But maybe that=92s already understood?)
I think it=92s fair to assume that everything unless otherwise specified is=
 for this profile

> Third bullet suggests the issuer identifier is obtained through discovery=
. Discovery defines the location of the metadata to be derived from the iss=
uer identifier. This circular reference is confusing.
See earlier comment, I don=92t think instantiating the issuer in the well k=
nown URL will be an operation performed by every client directly- and even =
if it would be, the issuer value is there anyway hence it remains actionabl=
e.

> Use of singular suggests there is only one possible =93aud=94 value that =
a resource server would accept.
Fair. Until recently, that was the case! Adjusted the language to still use=
 the singular, but switched to indefinite  articles to express the possibil=
ity of different values.

> States the signing key must be obtained from the authorization server. Is=
 this requirement necessary? (E.g. I believe Azure AD supports a resource s=
erver owner providing a custom signing key, in which case the RS is not ret=
rieving the signing key from the AS.)
I see the technical possibility of that scenario happening, but I am reluct=
ant to complicate the language and/or open up the possibility for errors he=
re.
I think the scenario you describe could be characterized as out of band set=
up, more about how the key is generated in the first place- but afterwards,=
 the key should end up in the AS metadata anyway regardless of how it has b=
een generated. Doing otherwise might make it more likely that people will e=
nd up with implementations that don=92t work well with key rotation, or rel=
y on out of band checks for key validity considerations.

> I expected some reference to JWT validation steps from RFC 7519
Are you thinking about anything in particular?

>=93as this would allow malicious clients to select the sub of a high privi=
lege resource owner=94: the subject of the access token is not necessarily =
the resource owner (e.g. client credentials).
True, but the existence of scenarios where this risk doesn=92t materialize =
doesn=92t make it any less of an issue in the cases where it does. Not sure=
 if clarifying that client only cases aren=92t affected would add much here=
.

>=93To preventing cross-JWT confusion=94: might be good to reference sectio=
n 2.8 of RFC 8725 to clarify what =93cross-JWT confusion=94 is
Added!

> slight conflict between the specs.
I think it=92s OK for a profile to be more restrictive. The language might =
be flipped to adopt the RS perspective and describe a more generic setup wh=
ere shared scopes are possible, but I worry about making the description of=
 the problem class less crisp. I avoided uppercase RFC keywords there, if t=
here=92s language that makes it even less normative without eroding its cla=
rity, I am all ears.

>    Missing double quotes around claim and parameter names (e.g. 2.2, 2.2.=
3),
Sigh, you=92re right. I was planning to add those eventually, I guess the t=
ime has come.


From: Mike Jones 
Date: Tuesday, April 21, 2020 at 11:07
To: oauth , Vittorio Bertocci 
Cc: Rifaat Shekh-Yusef 
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

This feedback is from a Microsoft engineer on the Azure Active Directory id=
entity team:


  *   1

     *   Missing space at =93Tokens(JWT)=94

  *   2.1

     *   Use of =93MUST=94 saying one form must be used, followed by =93SHO=
ULD=94 saying a different format should be used is a bit confusing. I get t=
he point, but I had to read it several times.
     *   Missing space at =93Therefore,the=94

  *   2.2.1

     *   References the definitions of =93acr=94, =93amr=94 and =93auth_tim=
e=94 from OpenID Connect. In OpenID Connect, these explicitly refer to the =
end-user=92s authentication. Does this mean these claims should only be use=
d when the subject is a user? If so, then it might be good to clarify. If n=
ot (and these also apply for client credentials, for example), then a refer=
ence to OpenID Connect may not be ideal.

  *   2.2.2

     *   Use of =93resource owner=94 suggests the resource owner is the sub=
ject of the token. This is not always true. In client credentials it=92s no=
t, and even in scenarios with a user, is it necessarily the resource owner =
who is authenticated/authorized? (Or could it be a different user who has b=
een separate authorized for the requested access by the resource owner?)

  *   2.2.3.1

     *   Link to section 4.1.2 of SCIM Core is actually linking to section =
4.1.2 of this doc.
     *   States =93groups=94, =93roles=94 and =93entitlements=94 in SCIM do=
n=92t have a vocabulary defined, but as far as I can tell, =93groups=94 doe=
s have a syntax defined in SCIM.

  *   3

     *   Missing newline in the example, before =93&state=94

  *   4

     *   States the configuration metadata is used to: =93advertise to reso=
urce servers [and] what iss claim value to expect via the issuer metadata v=
alue=94. This seems circular, since the configuration metadata is itself ob=
tained by appending a suffix to a known (and trusted) issuer value, right?
     *   =93AS=94 I used without having been introduced as abbreviation of =
=93authorization server=94.
     *   States that any JWT token with =93typ=94 value other than =93at+jw=
t=94 must be rejected.

        *   The value =93application/at+jwt=94 should also be accepted.
        *   As written, this might be interpreted to mean there is no possi=
bility of a future JWT token profile to be specified for use as a Bearer to=
ken (e.g. one with media type =93application/example+jwt=94). I believe the=
 intent is to say that if the =93typ=94 value is not =93at+jwt=94, it shoul=
d rejected for this profile. (But maybe that=92s already understood?)

     *   Third bullet suggests the issuer identifier is obtained through di=
scovery. Discovery defines the location of the metadata to be derived from =
the issuer identifier. This circular reference is confusing.
     *   Use of singular suggests there is only one possible =93aud=94 valu=
e that a resource server would accept.
     *   States the signing key must be obtained from the authorization ser=
ver. Is this requirement necessary? (E.g. I believe Azure AD supports a res=
ource server owner providing a custom signing key, in which case the RS is =
not retrieving the signing key from the AS.)
     *   I expected some reference to JWT validation steps from RFC 7519

  *   5

     *   =93as this would allow malicious clients to select the sub of a hi=
gh privilege resource owner=94: the subject of the access token is not nece=
ssarily the resource owner (e.g. client credentials).
     *   =93To preventing cross-JWT confusion=94: might be good to referenc=
e section 2.8 of RFC 8725 to clarify what =93cross-JWT confusion=94 is
     *   =93each scope string included in the resulting JWT access token, i=
f any, can be unambiguously correlated to a specific resource among the one=
s listed in the aud claim=94 specifies an unambiguous mapping, but section =
2.1.1 of RFC8693 suggest=
s a Catesian product of resources and scopes is possible, meaning that one =
scope value could (legitimately) map to multiple audience values. It=92s un=
clear if the intent here is to avoid the ambiguity for specifying that it m=
ust not be ambiguous, or if there=92s a slight conflict between the specs.
     *   Extra =91n=92 at =93OpennID Connect=92

  *   7.1.1

     *   Typo at =93JTW=94
     *   Missing =91A=92 at =93N/=94

  *   7.2

     *   Missing space at =91=94roles=94,=94groups=94=92

  *   Reference:

     *   No link to OpenID.Core

  *   All over:

     *   Missing double quotes around claim and parameter names (e.g. 2.2, =
2.2.3), which is inconsistent with other OAuth 2.0 specs, I think.


From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 15, 2020 11:59 AM
To: oauth 
Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth =
2.0 Access Tokens"

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile =
for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes


--_000_MWHPR19MB15017DDCA5AA4C8CC95605F8AED20MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thanks Mike! Those are great comments.

Inline- also, who should I put in the acknowledgemen=
ts for this contribution? Or does the commenter wish to remain anonymous?


 


>spaces, typos, abbreviations etc


Fixed, thx!


 


> Use of =93MUST=94 saying one form mus=
t be used, followed by =93SHOULD=94 saying a different format should be use=
d is a bit confusing. I get the point, but I had to read it several times.<=
o:p>


The language follows fairly closely https://tools.ietf.org/html/rfc8417#section-2.3.
I think the twist here is that the MUST refers to the need to use that =
media type rather than that particular format.


 


> Does this mean these claims should only be u=
sed when the subject is a user? If so, then it might be good to clarify.


Good catch! I added language clarifying that those c=
laims may be used in the context of grants involving the resource owner. I =
didn=92t add language explicitly disallowing using acr/amr/auth_time in cas=
e of client only grants. Open to feedback
 on whether that=92s necessary.


 


> Use of =93resource owner=94 suggests the res=
ource owner is the subject of the token. This is not always true. In client=
 credentials it=92s not, and even in scenarios with a user, is it necessari=
ly the resource owner who is authenticated/authorized?
 (Or could it be a different user who has been separate authorized for the =
requested access by the resource owner?)


Similarly to the above, I think it=92s worth clarify=
ing that the section refers to grants where the resource owner is involved.=
 I am adding language to that effect.


For the delegation cascade scenario, I=92d prefer to=
 avoid the complication and stick with attributes of the authenticated subj=
ect.


 


> Link to section 4.1.2 of SCIM Core is=
 actually linking to section 4.1.2 of this doc.


Oh wow. That=92s a feature of XML2RFC,=85 my source =
simply says by section 4.1.2 of SCIM Core&nbs=
p;
 in a <t> block, and the processor interpret it as an internal link. =
I=92ll need to dig on how to prevent that from happening for this instance.=
 Good catch!


=
 


>, =93groups=94 does have a syntax defined in =
SCIM


Hmm. What I really meant there is that there=92s no =
enumeration with fixed values, rather than a schema- but I can see how that=
 might be confusing. Also, I am not crazy about forcing people to build a c=
omposite structure when a simple string
 might suffice. I=92ll cull =93As in their original definition in [RFC7643]=
=94.


 


> States the configuration metadata is =
used to: =93advertise to resource servers [and] what iss claim value to exp=
ect via the issuer metadata value=94. This seems circular, since the config=
uration metadata is itself obtained by appending
 a suffix to a known (and trusted) issuer value, right?


Well, maybe. It=92s true that an AS implementing RFC=
8414 must serve its metadata on a URL containing the issuer, but that=92s n=
ot necessarily the method a client in real scenarios will use to resolve th=
at URL-  think metadata document cached
 locally from earlier runs, a private URL mapper or any other proprietary d=
iscovery mechanism. I am not advocating that clients should use any other m=
ethod than direct retrieval from the well known URL, but given that the iss=
uer info is available in both the
 URL and the metadata, I see no harm in recommending that the value ins ext=
racted from the metadata if that results in a more generally applicable app=
roach.   


 


> The value =93application/at+jwt=
=94 should also be accepted.


From the way it=92s currently phrased, both values s=
hould indeed be mentioned. Fixing that


 


> if the =93typ=94 value is not =93at&#=
43;jwt=94, it should rejected for this profile. (But maybe that=92s already=
 understood?)


I think it=92s fair to assume that everything unless=
 otherwise specified is for this profile


 


> Third bullet suggests the issuer iden=
tifier is obtained through discovery. Discovery defines the location of the=
 metadata to be derived from the issuer identifier. This circular reference=
 is confusing.


See earlier comment, I don=92t think instantiating t=
he issuer in the well known URL will be an operation performed by every cli=
ent directly- and even if it would be, the issuer value is there anyway hen=
ce it remains actionable.


 


> Use of singular suggests there is only one p=
ossible =93aud=94 value that a resource server would accept.



Fair. Until recently, that was the case! Adjusted th=
e language to still use the singular, but switched to indefinite  arti=
cles to express the possibility of different values.


 


> States the signing key must be obtained from=
 the authorization server. Is this requirement necessary? (E.g. I believe A=
zure AD supports a resource server owner providing a custom signing key, in=
 which case the RS is not retrieving
 the signing key from the AS.) 


I see the technical possibility of that scenario hap=
pening, but I am reluctant to complicate the language and/or open up the po=
ssibility for errors here.


I think the scenario you describe could be character=
ized as out of band setup, more about how the key is generated in the first=
 place- but afterwards, the key should end up in the AS metadata anyway reg=
ardless of how it has been generated.
 Doing otherwise might make it more likely that people will end up with imp=
lementations that don=92t work well with key rotation, or rely on out of ba=
nd checks for key validity considerations.


 


> I expected some reference to JWT validation =
steps from RFC 7519


Are you thinking about anything in particular?<=
/o:p>


 


>=93as this would allow malicious clients to s=
elect the sub of a high privilege resource owner=94: the subject of the acc=
ess token is not necessarily the resource owner (e.g. client credentials).<=
o:p>


True, but the existence of scenarios where this risk=
 doesn=92t materialize doesn=92t make it any less of an issue in the cases =
where it does. Not sure if clarifying that client only cases aren=92t affec=
ted would add much here.


 


>=93To preventing cross-JWT confusion=94: migh=
t be good to reference section 2.8 of RFC 8725 to clarify what =93cross-JWT=
 confusion=94 is


Added!


 


> slight conflict between the specs.


I think it=92s OK for a profile to be more restricti=
ve. The language might be flipped to adopt the RS perspective and describe =
a more generic setup where shared scopes are possible, but I worry about ma=
king the description of the problem
 class less crisp. I avoided uppercase RFC keywords there, if there=92s lan=
guage that makes it even less normative without eroding its clarity, I am a=
ll ears.


 


>    Missing double quotes around =
claim and parameter names (e.g. 2.2, 2.2.3),


Sigh, you=92re right. I was planning to add those ev=
entually, I guess the time has come.



 


 




From=
: Mike Jones <Mi=
chael.Jones@microsoft.com>

Date: Tuesday, April 21, 2020 at 11:07

To: oauth <oauth@ietf.org>, Vittorio Bertocci <Vittorio@aut=
h0.com>

Cc: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 






This feedback is from =
a Microsoft engineer on the Azure Active Directory identity team:


 


    

  • 1


    

      

    • Missing space at =93Tokens(JWT)=94
    



    

  • 2.1


    

      

    • Use of =93MUST=94 saying one form must be used, followed by =93SHOULD=
=94 saying a different format should be used is a bit confusing. I get the =
point, but I had to read it several times.
    • Missing spa=
ce at =93Therefore,the=94
    



    

  • 2.2.1


    

      

    • References the definitions of =93acr=94, =93amr=94 and =93auth_time=
=94 from OpenID Connect. In OpenID Connect, these explicitly refer to the e=
nd-user=92s authentication. Does this mean these claims
 should only be used when the subject is a user? If so, then it migh=
t be good to clarify. If not (and these also apply for client credentials, =
for example), then a reference to OpenID Connect may not be ideal.
    



    

  • 2.2.2


    

      

    • Use of =93resource owner=94 suggests the resource owner is the subjec=
t of the token. This is not always true. In client credentials it=92s not, =
and even in scenarios with a user, is it necessarily
 the resource owner who is authenticated/authorized? (Or could it be a diff=
erent user who has been separate authorized for the requested access by the=
 resource owner?)

    



    

  • 2.2.3.1


    

      

    • Link to section 4.1.2 of SCIM Core is actually linking to section 4.1=
.2 of this doc.
    • States =93groups=94, =93roles=94 and =
=93entitlements=94 in SCIM don=92t have a vocabulary defined, but as far as=
 I can tell, =93groups=94
does have a syntax defined in SCIM.
    



    

  • 3


    

      

    • Missing newline in the example, before =93&state=94
    



    

  • 4


    

      

    • States the configuration metadata is used to: =93advertise to resourc=
e servers [and] what iss claim value to expect via the issuer metadata valu=
e=94. This seems circular, since the configuration
 metadata is itself obtained by appending a suffix to a known (and trusted)=
 issuer value, right?
    • =93AS=94 I used without having=
 been introduced as abbreviation of =93authorization server=94.<=
/li>
    • States that any JWT token with =93typ=94 value other than =93at&#=
43;jwt=94 must be rejected.
    



    

      

        

      • The value =93application/at+jwt=94 should also be accepted.<=
/o:p>
      • As written, this might be interpreted to mean there is no p=
ossibility of a future JWT token profile to be specified for use as a Beare=
r token (e.g. one with media type =93application/example+jwt=94).
 I believe the intent is to say that if the =93typ=94 value is not =93at=
3;jwt=94, it should rejected
for this profile. (But maybe that=92s already understood?)
      

    



    

      

    • Third bullet suggests the issuer identifier is obtained through disco=
very. Discovery defines the location of the metadata to be derived from the=
 issuer identifier. This circular reference
 is confusing.
    • Use of singular suggests there is only =
one possible =93aud=94 value that a resource server would accept.

    • States the signing key
must be obtained from the authorization server. Is this requirement =
necessary? (E.g. I believe Azure AD supports a resource server owner provid=
ing a custom signing key, in which case the RS is not retrieving the signin=
g key from the AS.)

    • I expected some reference to JWT validation steps fro=
m RFC 7519
    



    

  • 5


    

      

    • =93as this would allow malicious clients to select the sub of a high =
privilege resource owner=94: the subject of the access token is not necessa=
rily the resource owner (e.g. client credentials).
    • =93=
To preventing cross-JWT confusion=94: might be good to reference section 2.=
8 of RFC 8725 to clarify what =93cross-JWT confusion=94 is
      • <=
li class=3D"MsoListParagraph" style=3D"margin-left:0in;mso-list:l1 level2 l=
fo1">=93each scope string included in the resulting JWT access token, if an=
y, can be unambiguously correlated to a specific resource among the ones li=
sted in the aud claim=94 specifies an unambiguous
 mapping, but section 2.1.1 of RFC8693 suggests a Catesian product of resources and =
scopes is possible, meaning that one scope value could (legitimately) map t=
o multiple audience values. It=92s unclear
 if the intent here is to avoid the ambiguity for specifying that it must n=
ot be ambiguous, or if there=92s a slight conflict between the specs.<=
/o:p>
    • Extra =91n=92 at =93OpennID Connect=92
    



    

  • 7.1.1


    

      

    • Typo at =93JTW=94
    • Missing =91A=92 at =93N/=94
    



    

  • 7.2


    

      

    • Missing space at =91=94roles=94,=94groups=94=92
    



    

  • Reference:


    

      

    • No link to OpenID.Core
    



    

  • All over:


    

      

    • Missing double quotes around claim and parameter names (e.g. 2.2, 2.2=
.3), which is inconsistent with other OAuth 2.0 specs, I think.<=
/li>
    



 


 




From: OAuth <oauth-bounces@ietf.org> On Behalf Of 
Rifaat Shekh-Yusef

Sent: Wednesday, April 15, 2020 11:59 AM

To: oauth <oauth@ietf.org>

Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profil=
e for OAuth 2.0 Access Tokens"




 




Hi all,


 


This is a second working =
group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access=
 Tokens".


 


Here is the document:


https://tools.ietf.org/=
html/draft-ietf-oauth-access-token-jwt-06


 


Please send your comments=
 to the OAuth mailing list by April 29, 2020.


 


Regards,


 Rifaat & Hannes=



 










--_000_MWHPR19MB15017DDCA5AA4C8CC95605F8AED20MWHPR19MB1501namp_--


From nobody Wed Apr 22 00:29:19 2020
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 674653A09AF for ; Wed, 22 Apr 2020 00:29:18 -0700 (PDT)
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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 AZgM13uqBzWF for ; Wed, 22 Apr 2020 00:29:16 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 D9D013A0868 for ; Wed, 22 Apr 2020 00:29:15 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id x17so370243wrt.5 for ; Wed, 22 Apr 2020 00:29:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=zV2Loll+GSRHJmS7uY7tz9X6jhnWeeoSRLWNMnMa3FE=; b=X/YmJaQgBjuJW7avD23o9zywz0lJbN0hEwJEH5kF62ivzWoX4idey8v/5+JKko+Ftw 6BNCpZqfmVnW9K9gVi4yP72mDiGLtiG7lMx5LCDECW6DgndtvmmXRtOu10DWHV/Gzf2j bfSFpuq6J9I8vnxeHthAwbDCSjunfp4UM/Qo4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=zV2Loll+GSRHJmS7uY7tz9X6jhnWeeoSRLWNMnMa3FE=; b=FIkXD3UwvwhAUWjcDYf/RdQw0CAyscq8f+5zs0m3ZNU4MCUIxTPg2GSMiYQCvgRAlz QL+6B8zMNCd7TDR+s4vYaW9HK4w4+HndnhOjjr0JO0jA5CrCRxsmNn96ZyfMUp1YKO2I ZN+Hs/8/6dUL85PlCs0L/u5vHuGwezsLUb/CP2AP9qUYzwa2JL9mpPoQLl8OEEv3fIqh 6T/PBkv0yvPo8eyX4TON3CAn76JCcDBwfILlVto2vOTJtug1OSY0/u/WSopE8Bp8YbS/ IftQfkzRhHQQWpS2kqG27bMR5lbyel/vVB8R40k682qej8DHUjbhArrFmiB+o91UIaIp /acg==
X-Gm-Message-State: AGi0PuZoVlEFE66VrZ1KUBlOztbbHyqU+y4L39fkbwQcEmfBWKMMgbS5 oAncYjKis+binXWW0xBihuNK3LF9E5+OZ3cWoNjA2t5ZkzUddjbEXF8ZQgTvoqWsTZPEQyrP7w7 O07HaE3oOGmdbCeohsvT7vhCiISSMq/HanIInS3wtm+t2/QHC+NCsk6sWp0RuQe0=
X-Google-Smtp-Source: APiQypJMRwV5qqVxyNwmI4fqTtsB/n+L6tGGaCktSck4+Mb9gZtFOm847NAxUD2HWQkwGv5Ky9PE8w==
X-Received: by 2002:adf:d091:: with SMTP id y17mr27277292wrh.418.1587540553989;  Wed, 22 Apr 2020 00:29:13 -0700 (PDT)
Received: from [10.0.0.3] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id b66sm6733677wmh.12.2020.04.22.00.29.13 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 00:29:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2869CC7B-6E61-460E-A2CB-F74FB4F4B3C7
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Wed, 22 Apr 2020 08:29:12 +0100
Message-Id: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com>
To: OAuth WG 
X-Mailer: iPhone Mail (17D50)
Archived-At: 
Subject: [OAUTH-WG] OAuth GREASE
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, 22 Apr 2020 07:29:18 -0000

--Apple-Mail-2869CC7B-6E61-460E-A2CB-F74FB4F4B3C7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Section 3.1 of RFC 6749 says (of the authorization endpoint):

The authorization server MUST ignore
   unrecognized request parameters.

We hoped to be able to use this to opportunistically apply PKCE - always sen=
d a code_challenge in the hope that the AS supports it and there should be n=
o harm if it doesn=E2=80=99t.=20

Sadly I learned yesterday of yet another public AS that fails hard if the re=
quest contains unrecognised parameters. It appears this part of the spec is w=
idely ignored.=20

Given that this hampers the ability to add new request parameters in future,=
 do we need our own GREASE to prevent these joints rusting tight?
https://www.rfc-editor.org/rfc/rfc8701.html

=E2=80=94 Neil=

--Apple-Mail-2869CC7B-6E61-460E-A2CB-F74FB4F4B3C7
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Section 3.1 of RFC 6749 says (of the author=
ization endpoint):

=

--Apple-Mail-2869CC7B-6E61-460E-A2CB-F74FB4F4B3C7--


From nobody Wed Apr 22 06:14:53 2020
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 C5FA43A0BEB for ; Wed, 22 Apr 2020 06:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NA38ma02WyDS for ; Wed, 22 Apr 2020 06:14:47 -0700 (PDT)
Received: from rhcavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (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 D2F523A0BE6 for ; Wed, 22 Apr 2020 06:14:46 -0700 (PDT)
X-KULeuven-Envelope-From: pieter.philippaerts@kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 4DFCB120008.A2F9C
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by rhcavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 4DFCB120008 for ; Wed, 22 Apr 2020 15:14:35 +0200 (CEST)
Received: from ICTS-S-EXMBX24.luna.kuleuven.be (icts-s-exmbx24.luna.kuleuven.be [10.112.11.59]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPS id 29A65200A9 for ; Wed, 22 Apr 2020 15:14:35 +0200 (CEST)
Received: from ICTS-S-EXMBX19.luna.kuleuven.be (10.112.11.50) by ICTS-S-EXMBX24.luna.kuleuven.be (10.112.11.59) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Apr 2020 15:14:34 +0200
Received: from ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396]) by ICTS-S-EXMBX19.luna.kuleuven.be ([fe80::b0b6:d4f7:5b6e:2396%21]) with mapi id 15.00.1497.006; Wed, 22 Apr 2020 15:14:34 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Philippaerts 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Caution about open redirectors using the state parameter
Thread-Index: AdYXSOJMqPEgvXlOQI+GZQm5PJwZ3AAuVAyAAARymQAAJBIdiw==
Date: Wed, 22 Apr 2020 13:14:34 +0000
Message-ID: <1587561273967.95187@kuleuven.be>
References: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com>, <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com>
In-Reply-To: <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com>
Accept-Language: en-US, nl-BE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.112.50.1]
Content-Type: multipart/alternative; boundary="_000_158756127396795187kuleuvenbe_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 22 Apr 2020 13:14:51 -0000

--_000_158756127396795187kuleuvenbe_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> I think the correct defence is to validate the URL


I agree. The URL can be whitelisted, signed, encrypted, ...


> > Can we please add an explicit prohibition of this practice in draft-iet=
f-oauth-security-topics?

> However, we should be careful how we prohibit it...


You could argue that it's already there. Section 4.7.1 says:


If "state" is used for carrying application state, and integrity
of its contents is a concern, clients MUST protect "state" against
tampering and swapping.  This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted
state values [I-D.bradley-oauth-jwt-encoded-state].


Implementations, like the ones you're seeing, where "state" stores a URL an=
d is used without validation do not comply with the above paragraph.


I do agree that the above paragraph is somewhat hidden in the CSRF section.=
 Perhaps a new subsection could be added to section 4 where attacks on the =
"state" parameter are discussed (and where countermeasures like signing the=
 state are repeated)?


Regards,

Pieter



________________________________
From: OAuth  on behalf of Neil Madden 
Sent: Tuesday, April 21, 2020 23:35
To: George Fletcher
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state para=
meter

I think the correct defence is to validate the URL (eg check against a whit=
elist) at the point you are going to redirect to it after the OAuth flow co=
mpletes, rather than before you begin the OAuth flow.

But this feels like generic web app security advice rather than anything sp=
ecific to OAuth - always validate URLs before performing a redirect.

Neil

On 21 Apr 2020, at 20:28, George Fletcher  wrote:

? +1

However, we should be careful how we prohibit it... because if the state va=
lue is actually signed, having the URL there isn't a problem as the attacke=
r can not manipulate the value without breaking the signature.

On 4/20/20 5:28 PM, Mike Jones wrote:

I've seen several circumstances where "clever" clients implement an open re=
director by encoding a URL to redirect to in the state parameter value.  At=
tackers can then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in draft-ietf-oa=
uth-security-topics?

                                                       Thanks,
                                                       -- Mike






_______________________________________________
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

--_000_158756127396795187kuleuvenbe_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








>
 I think the correct defence is to validate the URL







I agree. The URL can be whitelisted, signed, encrypted, …










> > Can we please add an explicit prohibition of this practice i=
n draft-ietf-oauth-security-topics?




> However, we should be careful how we prohibit it...









You could argue that it's already there. Section 4.7.1 says:











If "state" is used for carrying application state, and integ=
rity


of its contents is a concern, clients MUST protect "state" a=
gainst

tampering and swapping.  This can be achieved by binding the

contents of state to the browser session and/or signed/encrypted

state values [I-D.bradley-oauth-jwt-encoded-state].








Implementations, like the ones you're seeing, where "state" st=
ores a URL and is used without validation do not comply with the above para=
graph.







I do agree that the above paragraph is somewhat hidden in the CSRF secti=
on. Perhaps a new subsection could be added to section 4 where attacks on t=
he "state" parameter are discussed (and where countermeasures lik=
e signing the state are repeated)?









Regards,




Pieter
















From: OAuth <oauth-bounc=
es@ietf.org> on behalf of Neil Madden <neil.madden@forgerock.com><=
br>
Sent: Tuesday, April 21, 2020 23:35

To: George Fletcher

Cc: Mike Jones; oauth@ietf.org

Subject: Re: [OAUTH-WG] Caution about open redirectors using the sta=
te parameter

 








I think the correct defence is to validate the URL (eg che=
ck against a whitelist) at the point you are going to redirect to it after =
the OAuth flow completes, rather than before you begin the OAuth flow. =
;







But this feels like generic web app security advice rather=
 than anything specific to OAuth - always validate URLs before performing a=
 redirect.







Neil





On 21 Apr 2020, at 20:28, George Fletcher <gff=
letch=3D40aol.com@dmarc.ietf.org> wrote:










 +=
1



However, we should be careful how we prohibit it... because if the state va=
lue is actually signed, having the URL there isn't a problem as the attacke=
r can not manipulate the value without breaking the signature.




On 4/20/20 5:28 PM, Mike Jones wrote:






I've seen several circumstances where "cl=
ever" clients implement an open redirector by encoding a URL to redire=
ct to in the state parameter value.  Attackers can then utilize this open r=
edirector by choosing a state value.=0A=
=0A=
Can we please add an explicit prohibition of this practice in draft-ietf-oa=
uth-security-topics?=0A=
=0A=
                                                       Thanks,=0A=
                                                       -- Mike=0A=
=0A=
=0A=







______________________________________________=
_=0A=
OAuth mailing list=0A=
OAuth@=
ietf.org=0A=
https://www.ietf.org/mailman/listinfo/oauth=0A=






_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth












--_000_158756127396795187kuleuvenbe_--


From nobody Wed Apr 22 06:31:37 2020
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 A65123A0C66 for ; Wed, 22 Apr 2020 06:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 FOEFJDo8iMXr for ; Wed, 22 Apr 2020 06:31:34 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637F43A0C53 for ; Wed, 22 Apr 2020 06:31:34 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id CC0185C6D for ; Wed, 22 Apr 2020 13:31:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1587562286; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BzLNvBIsKrDOPuiYXLKuvADPdVyejtsON9ni46GUb8E=; b=XV/eMrph4A1XWrHOYs57nwRyhoucoLPVbZLwtit3IeI5kOo+31OojTIbeqD6382MyeyTzs et4j6gbt6ss4IR+6JEX4d+qG8bZS1/ELJB5XaCEoQVVxXWvVSkOtdTEgzcwzZWMz7qul3i Z0Hn1smOuV7AtFDi+9KzuHkD6WWdfWY=
To: oauth@ietf.org
References: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com> <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com> <1587561273967.95187@kuleuven.be>
From: Daniel Fett 
Message-ID: 
Date: Wed, 22 Apr 2020 15:31:25 +0200
MIME-Version: 1.0
In-Reply-To: <1587561273967.95187@kuleuven.be>
Content-Type: multipart/alternative; boundary="------------EBD580F5A4AFB31C775860FA"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1587562286; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BzLNvBIsKrDOPuiYXLKuvADPdVyejtsON9ni46GUb8E=; b=OfHBAqQr2hGXsIgCGGH9+H/uJW4xWNma5c919bWPd2F913r1FLjjfRxjM64IIZmTkMh/JO PhX3gZWSXVq1QNrCdDgMvZTYS/dP9arm5EH3Drx9iZ1+89vWqX7OF+OwPkj2dVgr+zgpUN 4Y5yHQdtm3sPilpVkP5RL/xEDOcJ9sc=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1587562286; a=rsa-sha256; cv=none; b=PZhesaCurnuS1Mg0cGgRxy114FnUtfQFYR6DtzLXJOA9sXk/RguReS/800+3IFFgjF9ETM PaGV99Wf/M2HcqMBi4raFkcVAGjSuHj3CVuRfZ0EIk2XltbsleQ3A8qRRNsJpa6AwTWEZY 7U/RkRlCXL0FkQtFBf2gnQNe8qkCXEk=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 22 Apr 2020 13:31:36 -0000

This is a multi-part message in MIME format.
--------------EBD580F5A4AFB31C775860FA
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Am 22.04.20 um 15:14 schrieb Pieter Philippaerts:
>
> You could argue that it's already there. Section 4.7.1 says:
>
>
We also have Section 4.9 on open redirectors:

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.9


-Daniel


--------------EBD580F5A4AFB31C775860FA
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Am 22.04.20 um 15:14 schrieb Pieter
      Philippaerts:

    

    

      
      
      
You could argue that it's already there. Section 4.7.1 says:

      

      


      

    

    
We also have Section 4.9 on open redirectors:

    
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.9

    


    

    
-Daniel

    

  


--------------EBD580F5A4AFB31C775860FA--


From nobody Wed Apr 22 07:17:20 2020
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 CDBAB3A0DAA for ; Wed, 22 Apr 2020 07:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_06_12=1.947, 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 Q2h6vD-hXyCT for ; Wed, 22 Apr 2020 07:17:08 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 B12C33A0EF4 for ; Wed, 22 Apr 2020 07:16:20 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id s10so1585041edy.9 for ; Wed, 22 Apr 2020 07:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zs6LKGbdpWKS7Ht2WHdaZxeqChSzUBnZY5HETM18Np0=; b=SJAxOuqnesNV9cXg7XeejwyYT6Fm2fl75/CCrjM1QXA6EYupA784E1r9sx3+12/8jx sCBm1NyDLLJwbRF5ddl+46pBD/Ap7aJVuxMw/ZZwJilewZnTVL4qbaRwo+gag7kIWURl n1ngDBQ90qY80mGRVfG5CH1B9M7oS8NhCgNS6fcAxNrjLf8yvckmEbPLf36Oo8VseYnl 0mhozLQiBzjA4p7eQ93JAFnnWa/E7xLLv+YaBHrCACjxQDAaXrswjMWM6NKHPL83iYXg S6EgiJtRLiyVmxp9XXsZt9xFJLS3Z/ewqnKMYiFQ9wTKIGGqu2ET6yBIPuBHxNVo0TM6 xK5A==
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=zs6LKGbdpWKS7Ht2WHdaZxeqChSzUBnZY5HETM18Np0=; b=AThh4iQidZyo5WDn5NYM3mOB+KV5y3Q1u1PV8vhzjq4l/HCelB4GgMBhMBio4Sjddt XC9QTtzSLUzd9BZwrDZwlodp/S6J92nvZ0CuoyQf57rFDE0rIU7PtJ7GlE/RRitbTVyq XQ29Lb4JLHVndH2nnYIzKd0uA3uICNgl+79tKRTpVhnFyY9+79hzYBsEjAR9AYARz+F2 63XwN8kOvgVy599tA2EJRnxdj4gop71wWXK5F/xAo8G1hNOhNxA6DimONXa10jejhucY 9Fp+4+02Rcsq620SyWGSAyo/HckmHD9JoFVMmmxhmNCoqGbOVxhTWbGRSdMmsYwbfGOG yAlg==
X-Gm-Message-State: AGi0PuZQRgQHRPL5GlVdRy1sTiTwnWNYNHhfDE7NWolSZlpBe0V2W58p 54e/Iim3HVmGkxW1qlUtc8FS2r9Kbpg4g/Txv1w=
X-Google-Smtp-Source: APiQypJk0G0gyr9S2VeASq2Fc5XpsJGhvxTJaWZrQVZcxuq+JFzmXnOwUgFyXw7jgN1V3iDeDp//gVTngzcisSbjSAk=
X-Received: by 2002:a50:cf4d:: with SMTP id d13mr24038079edk.175.1587564979130;  Wed, 22 Apr 2020 07:16:19 -0700 (PDT)
MIME-Version: 1.0
References: <8ef6dfa2-a3b0-3908-ac7d-b496908d07e1@aol.com> <39FB95F6-4542-4DA3-9F5A-7D64FDF507DD@forgerock.com> <1587561273967.95187@kuleuven.be> 
In-Reply-To: 
From: tt tt 
Date: Wed, 22 Apr 2020 15:16:22 -0700
Message-ID: 
To: Daniel Fett 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a395d205a3e1c632"
Archived-At: 
Subject: Re: [OAUTH-WG] Caution about open redirectors using the state parameter
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, 22 Apr 2020 14:17:18 -0000

--000000000000a395d205a3e1c632
Content-Type: text/plain; charset="UTF-8"

Could you please delete my email stop sending emails

On Wed, 22 Apr 2020 at 06:31, Daniel Fett  wrote:

> Am 22.04.20 um 15:14 schrieb Pieter Philippaerts:
>
> You could argue that it's already there. Section 4.7.1 says:
>
>
> We also have Section 4.9 on open redirectors:
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.9
>
>
> -Daniel
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000a395d205a3e1c632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Could you please delete my email stop sending emails
=

On Wed=
, 22 Apr 2020 at 06:31, Daniel Fett <fett@danielfett.de> wrote:

 =20
   =20
 =20
  

    
Am 22.04.20 um 15:14 schrieb Pieter
      Philippaerts:

    

    

     =20
     =20
      
You could argue that it's already there. Section 4.7.1 says:
      

      


      

    

    
We also have Section 4.9 on open redirectors:

    
https://tools.ietf.org/html/draft-iet=
f-oauth-security-topics-15#section-4.9

    


    

    
-Daniel

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000a395d205a3e1c632--


From nobody Wed Apr 22 07:38:36 2020
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 54B153A0DAC for ; Wed, 22 Apr 2020 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 Vpe5whsHpIGk for ; Wed, 22 Apr 2020 07:38:33 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89033A0DCD for ; Wed, 22 Apr 2020 07:38:32 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 18EAB5BED; Wed, 22 Apr 2020 14:38:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1587566311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=d3m/9JC7yfsLfsz8W6j1EgocOh4qgo0V8WiKdi+KOzY=; b=F9ZH3ezxTt5yg2qV3ASrgeQhd+vC4PWUqqhJ1E2JCs1ropiAQnT+fcWnKeHi8TZApg/wUn lG+2UjyL4euhkl16be7u2ELNvjrLueJ7UgUIHw428eWTAtc/3uad9ROTNI4tsVvesGEVVs ysWoD8Y6TTPaPfT2s/HUO7TvCCZFBPA=
From: Daniel Fett 
To: oauth@ietf.org, openid-specs-fapi@lists.openid.net, openid-specs-ab@lists.openid.net
Message-ID: 
Date: Wed, 22 Apr 2020 16:38:29 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------FFB8CE8EB6763CF89C2820ED"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1587566311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=d3m/9JC7yfsLfsz8W6j1EgocOh4qgo0V8WiKdi+KOzY=; b=eOU/JvlzZEEaHQLXjNZ5fNxMEJ0crDC/BCN+n7OWVMeSZK/MLW4aJ7LX/CogcZJ7WwRsfL 0hLjhP9hJ3ABOAZA9PWE7+/w73fk+phlhFd+7POelhpVUOEhdmSgA3JHNIFChyRZYujTsQ 3reUQdf/1f2WJvzQtJJ03si7C4kFTao=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1587566311; a=rsa-sha256; cv=none; b=hfilidTwZDzAeRxy0dpKem6LFyxaJR7FZkGxkbX0izkXMSg03HJbqXvaQudQL91ov0mFM6 te2iktgsF8sHTI7RSbIm6tiHWuTYWjb5R4yxYKLycjc9AqPc1/NIUf2YOb7GD7d1CLNuDr Q8ttU4lERQiNyvcdKnXMcCRlm7bD9Ak=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: ++
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Archived-At: 
Subject: [OAUTH-WG] OAuth Security Workshop 2020 going virtual / OAuth Security Workshop 2020+1
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, 22 Apr 2020 14:38:35 -0000

This is a multi-part message in MIME format.
--------------FFB8CE8EB6763CF89C2820ED
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all,

Like many other conferences and events, the OAuth Security Workshop is
affected by the Coronavirus pandemic. We do not expect that normal
international travel will be possible anytime soon.

Therefore, Steinar and I decided to hold a *virtual OAuth Security
Workshop* at the same dates as originally planned, July 22-24.

Additionally, we are looking into holding the *next in-person event in
March 2021 in Trondheim, Norway* (i.e., in proximity to IETF 110 Prague)
if the situation permits.

We will get back to you with a more detailed planning for both events as
soon as possible.

As before, the virtual event will also be a mixture of pre-scheduled
talks and an unconference part. We *extended the deadline for
submissions* for the pre-scheduled part until May 31. Please submit your
proposal here:
https://docs.google.com/forms/d/e/1FAIpQLSfqHnsKRodCWom4j4f7j791gnoaz2XLTOTiGCv4F_Wl9cNQSQ/viewform

If you have already proposed a session, please let us know if you cannot
or do not want to join the virtual event.

If you have any questions, please let us know!

-Daniel


--------------FFB8CE8EB6763CF89C2820ED
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hi all,

    
Like many other conferences and events, the OAuth Security
      Workshop is affected by the Coronavirus pandemic. We do not expect
      that normal international travel will be possible anytime soon.

    
Therefore, Steinar and I decided to hold a virtual OAuth
        Security Workshop at the same dates as originally planned,
      July 22-24. 

    

    
Additionally, we are looking into holding the next in-person
        event in March 2021 in Trondheim, Norway (i.e., in proximity
      to IETF 110 Prague) if the situation permits. 

    

    
We will get back to you with a more detailed planning for both
      events as soon as possible. 

    

    
As before, the virtual event will also be a mixture of
      pre-scheduled talks and an unconference part. We extended the
        deadline for submissions for the pre-scheduled part until
      May 31. Please submit your proposal here:
https://docs.google.com/forms/d/e/1FAIpQLSfqHnsKRodCWom4j4f7j791gnoaz2XLTOTiGCv4F_Wl9cNQSQ/viewform

    
If you have already proposed a session, please let us know if you
      cannot or do not want to join the virtual event.

    
If you have any questions, please let us know!

    
-Daniel

    

  


--------------FFB8CE8EB6763CF89C2820ED--


From nobody Wed Apr 22 16:36:27 2020
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 F3BEF3A0DCB for ; Wed, 22 Apr 2020 16:36:25 -0700 (PDT)
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=unavailable 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 CyUi8R1uyBU6 for ; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 36D553A0E61 for ; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id w20so4323232ljj.0 for ; Wed, 22 Apr 2020 16:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVy8w/osanS+ODuFpWCNRcxdx9w5n0z6l1q2/Ew0yUU=; b=WeTkn5PPqp6JxLE9qaADrrmfNlfFU6VlfJD62uaA9Gz8FGN23qDzasonEGgVQLs2bc I/vbKZrbMIYIh8sJCxCfynA9AsnsKbpLLYFVoM0cW/WnQ6ojxVCOk6vIXuzeVywsaLyM ymX3FJqThYDhe8iCukImnPPkMzBvIl3z6DlfoODJqZS+SqggYSD/KZj/fBQFqnTq1VLO yegn92uTMAgHPmpE/Qk6uoMYd+YpeLadyb2p//5+wVyQpe82AGU0/D5bW+Lhqw6NfJlN gYlT7UWFLgqtnCACP/60547kdkTNB/TTj0WB1kQydT9pshoK6M/DPw3FjfUrqVDO0EUF GSNg==
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=NVy8w/osanS+ODuFpWCNRcxdx9w5n0z6l1q2/Ew0yUU=; b=l7jmLu+MU2F0ta9WYqFk0MpN7C1G354La+D6Obh/5ekxcdqjJJo4pz24ob8QgQsXPW bfa/Oa072W31nMbZAVbXPpXleLdVcIM2fEvs+os7xTN/D4WmgspLuqm4MU2FBuYmhDKm H85D7pBhY7rLpLqZwwuOgNLCLou5bnPqYRmO4t2WkW6rpq3wb4N2JHvbkxnblUJPk/kz 0EKqFTiJiYJADbYNHgoaW51bldH4eHbyUuWHvh7/dk4pHGohMmIWpvL7NyjINbrrxYw2 mP7KVPeFOpqSDGQRf7LJbuNXTbpMe4wwCJYyo14X4yWNDW8gNDsK4y6EHwew40q5vjKx KiUA==
X-Gm-Message-State: AGi0PuakAo/tGBwNtjr4RMDnxTZmRzt7mveZAsHzjFAnk1EGu94TnG6C JoxtQbelbx1fQDPsMZ9Blugm/p27J5/FgUs6cpLwcTlg
X-Google-Smtp-Source: APiQypKfHPuVpYucT4KC5DQqTPoORsWGz6pq3myrmqWLFZdaiZ7SbCBTDkMBBEr/dh62QhH/5rIUr7ySsWGq1MvY0IA=
X-Received: by 2002:a2e:86c6:: with SMTP id n6mr704658ljj.236.1587598580129; Wed, 22 Apr 2020 16:36:20 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 22 Apr 2020 16:35:53 -0700
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000006a230405a3e999aa"
Archived-At: 
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
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, 22 Apr 2020 23:36:26 -0000

--0000000000006a230405a3e999aa
Content-Type: text/plain; charset="UTF-8"

Brian: many, many thanks for all the feedback!

I did a quick skim of your comments, and will address the first and last
ones.

On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell  wrote:

> Been working on this on and off for a while now (it's not exactly short at
> 80+ pages, various other priorities, etc.) but wanted to share my thoughts
> from an initial review of the OAuth 2.1 draft before the interim next week
> where it is on the agenda
> https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.
> So for better or worse, here's that review:
>
> Abstract:
> "replaces and obsoletes the OAuth 2..0 Authorization Framework described
> in RFC 6749."
> I think "replaces" is probably unnecessary here and, to be pedantic, is
> arguably inaccurate because published RFCs don't ever go away or get
> replaced.
>

I took this language from RFC 6749:

 This specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.


And adapted it.


> Probably should also consider using the official "obsoletes" attribute
> marker too for 6749 https://tools.ietf.org/html/rfc7991#section-2.45.8
> and probably also "updates"/"obsoletes" for others based on the scope of
> the rest of the document (not sure how this even works with a BCP or if you
> can or would want to update or obsolete a BCP) if this work proceeds. That
> scope could be better described in the abstract too as discussed somewhat
> in the thead
> https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/
> and also the 1st paragraph of
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12.
> What is and isn't in scope is another larger question that I"m not even
> sure how to ask. What's included vs. what's referenced? Should this doc be
> incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
> antithetical to what a BCP is supposed to be but it's also a bit hard to
> tell how much was used. I mean, what happens if/when the BCP is updated?
> And that kinda begs the question of if it should also incorporate parts of
> or even replace the browser based apps draft?
>

Our thinking was to include all the documents where the OAuth Security
Topics was obsoleting sections of documents so that it could stand on its
own, and roll up all the best practices.

If there are new best practices for OAuth 2.1, then that would be a new
BCP..



> I guess that's a TBD circa page 68. There was talk about the device grant
> being in scope but I'm not seeing it (not saying it should or shouldn't be
> there but it was talked about). I dunno exactly but those are some scope
> questions that come to mind.
> Speaking of obsoleting, I do want to ensure that existing extensions and
> profiles of RFC 6749 that use legitimate extension points still present and
> unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
> not sure how that should work in practice but want to be aware of it as/if
> this work progresses.
>

Perhaps have a section in the document listing all existing documents that
work fine with 2.1?




> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#appendix-C
> "TBD"
> Given the potentially high visibility of an OAuth 2.1 effort, I think it'd
> be worthwhile to list organizational affiliations of individuals here in
> the acknowledgements along with their names. Something like what was done
> in the first part of
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A.
> This can help with visibility and justification of (sometimes not
> insignificant) time spent on the work by non-authors/editors.
>

 Sure. Are you ok with being added there?

--0000000000006a230405a3e999aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Brian: many, many thanks for all the feed=
back!

I did a quick skim of your comments, and will addr=
ess the first and last ones.=C2=A0

On Tue, Apr 21, 2020 at 3:49 PM Bri=
an Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Been working o=
n this on and off for a while now (it's not exactly short at 80+ pages,=
 various other priorities, etc.) but wanted to share my thoughts from an in=
itial review of the OAuth 2.1 draft before the interim next week where it i=
s on the agenda https://datatracker.ietf.org/doc=
/agenda-interim-2020-oauth-06-oauth-01/.=C2=A0 So for better or worse, =
here's that review: 

Abstract:
&=
quot;replaces and obsoletes the OAuth 2..0 Authorization Framework describe=
d in RFC 6749." 
I think "replaces" is probabl=
y unnecessary here and, to be pedantic, is arguably inaccurate because publ=
ished RFCs don't ever go away or get replaced. 

I took this language from RFC 6749:

=

=C2=A0This specification replaces and obso=
letes the OAuth 1.0 protocol described in RFC 5849.

And adapted it.=C2=A0
=

=C2=A0
Probably should also consider using the official &=
quot;obsoletes" attribute marker too for 6749 https://tools.ietf=
.org/html/rfc7991#section-2.45.8 and probably also "updates"/=
"obsoletes" for others based on the scope of the rest of the docu=
ment (not sure how this even works with a BCP or if you can or would want t=
o update or obsolete a BCP) if this work proceeds. That scope could be bett=
er described in the abstract too as discussed somewhat in the thead https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7=
SpC5051sSy6XnLDv0/ and also the 1st paragraph of =
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12. 
What is and isn't in scope is another larger question that =
I"m not even sure how to ask. What's included vs. what's refer=
enced? Should this doc be incorporating bits of BCP 212 - OAuth 2.0 for Nat=
ive Apps? Seems kinda antithetical to what a BCP is supposed to be but it&#=
39;s also a bit hard to tell how much was used. I mean, what happens if/whe=
n the BCP is updated? And that kinda begs the question of if it should also=
 incorporate parts of or even replace the browser based apps draft? 
<=
/div>

Our thinking was to include all the d=
ocuments where the OAuth Security Topics was obsoleting sections of documen=
ts so that it could stand on its own, and roll up all the best practices.

If there are new best practices=C2=A0for OAuth 2.1,=
 then that would be a new BCP..

=C2=A0
I guess t=
hat's a TBD circa page 68. There was talk about the device grant being =
in scope but I'm not seeing it (not saying it should or shouldn't b=
e there but it was talked about). I dunno exactly but those are some scope =
questions that come to mind. 
Speaking of obsoleting, I do wa=
nt to ensure that existing extensions and profiles of RFC 6749 that use leg=
itimate extension points still present and unchanged in OAuth 2.1 aren'=
t inadvertently impacted by this effort. I'm not sure how that should w=
ork in practice but want to be aware of it as/if this work progresses. 
=


Perhaps have a section in the =
document listing all existing documents that work fine with 2.1?
=

<snip>


=C2=A0Sure. Are y=
ou ok with being added there?
The authorization server MUST ignore
   unrecognized request parameters.

We hoped to=
 be able to use this to opportunistically apply PKCE - always send a code_ch=
allenge in the hope that the AS supports it and there should be no harm if i=
t doesn=E2=80=99t. 

=

Sadly I learned yesterday of=
 yet another public AS that fails hard if the request contains unrecognised p=
arameters. It appears this part of the spec is widely ignored. <=
/font>

Given that this hampers the ability to add new request parame=
ters in future, do we need our own GREASE to prevent these joints rusting ti=
ght?
https://www.rfc-editor.org/rfc/rfc8701.htm=
l

=E2=80=94 Neil


--0000000000006a230405a3e999aa--


From nobody Thu Apr 23 00:55:04 2020
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 005CB3A1680 for ; Thu, 23 Apr 2020 00:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 bGvoA0-DtvAs for ; Thu, 23 Apr 2020 00:55:01 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 4965A3A167B for ; Thu, 23 Apr 2020 00:55:01 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id RWh2jhEUp9JjyRWh4jg5f2; Thu, 23 Apr 2020 00:55:00 -0700
X-CMAE-Analysis: v=2.3 cv=ZO6pZkzb c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=BqEg4_3jAAAA:8 a=Vq__D_9_wrZ_-0_00VMA:9 a=QEXdDO2ut3YA:10 a=gNR8PH0IMfoA:10 a=RQUf42KgQNQA:10 a=6Hd0po06xlgA:10 a=3aknrV82MZcA:10 a=UM_DoP-0AAAA:8 a=NqJpTMeShTPr8V1-VBAA:9 a=H3iPujJrdPWw1yro:21 a=_W_S_7VecoQA:10 a=ZkqgyM_Zep0A:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=0mFWnFbQd5xWBqmg7tTt:22 a=TEVHQOIvcflanWNqQbWu:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com>
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: 
Date: Thu, 23 Apr 2020 10:54:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050205010408080809080406"
X-CMAE-Envelope: MS4wfCxRNsF58t+FsENFmYM0ewTUwBPLdxjgB99q/0LOBTkKWqYV0d4QuCBnQrLIS18Ne1y6uteSPYwqa48X8NsUN8qySkqqNY03YFp7+r3sQNmjXM5nFWkX Pt5uPOh1u6oEB+iMZJfiRgd/avCXEoqSTh1Xe9nOgZP7Eu+zu/oPFqQy
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth GREASE
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, 23 Apr 2020 07:55:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms050205010408080809080406
Content-Type: multipart/alternative;
 boundary="------------C527532E365396A6B465F0F6"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------C527532E365396A6B465F0F6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I get your frustration with PKCE. It would be a bad policy and example
to burden compliant ASes with additional stuff just because a few AS
implementations are not complying with the spec. It's not fair and can
end up creating all sorts of bad incentives in future.

Vladimir

On 22/04/2020 10:29, Neil Madden wrote:
> Section 3.1 of RFC 6749 says (of the authorization endpoint):
>
> The authorization server MUST ignore
>    unrecognized request parameters.
> We hoped to be able to use this to opportunistically apply PKCE -
> always send a code_challenge in the hope that the AS supports it and
> there should be no harm if it doesn=E2=80=99t.=C2=A0
> Sadly I learned yesterday of yet another public AS that fails hard if
> the request contains unrecognised parameters. It appears this part of
> the spec is widely ignored.=C2=A0
> Given that this hampers the ability to add new request parameters in
> future, do we need our own GREASE to prevent these joints rusting tight=
?
> https://www.rfc-editor.org/rfc/rfc8701.html 
> =E2=80=94 Neil


--------------C527532E365396A6B465F0F6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I get your frustration with PKCE. It would be a bad policy and
      example to burden compliant ASes with additional stuff just
      because a few AS implementations are not complying with the spec.
      It's not fair and can end up creating all sorts of bad incentives
      in future.

    

    
Vladimir

    

    
On 22/04/2020 10:29, Neil Madden wrote=
:

    

    

      
      Section 3.1 of RFC 6749 says (of the authorization endpoint):
      


      

      

        
=
The authorization server MUST ignore
   unrecognized request parameters.

        
=



        
We hoped to be able to use this=
 to opportunistically apply PKCE - always send a code_challenge in the ho=
pe that the AS supports it and there should be no harm if it doesn=E2=80=99=
t.=C2=A0

        



        
Sadly I learned yesterday of ye=
t another public AS that fails hard if the request contains unrecognised =
parameters. It appears this part of the spec is widely ignored.=C2=A0

        



        
Given that this hampers the abi=
lity to add new request parameters in future, do we need our own GREASE t=
o prevent these joints rusting tight?

        
https://www.rfc-editor.=
org/rfc/rfc8701.html

        

        
=E2=80=94 Neil

      

    

    

  


--------------C527532E365396A6B465F0F6--

--------------ms050205010408080809080406
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
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MjMwNzU0NDJaMC8G
CSqGSIb3DQEJBDEiBCDZCrgn1wVQsD6XAOLLd4bI0nXfhu8WBZDzV6n7vXKOvjBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr
BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG
A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i
MA0GCSqGSIb3DQEBAQUABIIBAH3LCRhUIyLviVzA/muD4KkARLvzNt62pORFrVojXqOq70bz
f1chZFI46o1MWTgSCqjEpjRMGllS44z/mk9KNC8hk5dTVsAu8cxMGsMSpnZQQhBtlLLL92Xg
FJBLhZXkmIIeMJL5Ys8hazCxYlFKwMKjimQBtKIwUhce/lU6FeRR0Z8fGyu1A/Q6SIiuxP1j
6tgRGv7pNXqOPJjUji0nwbUa8/UaxAZ6phwk/s0yhp1WfELVI+/P8NWdR0I0Xpf6L2BOd/LL
ZpGt8U5d8pg4YiQ3CTKFu7FOcH9Afa4CDrEEsiY2/F4T3IMUMYnJ0Ss5z5jkg3Q6PquuBy2z
gI6zJrQAAAAAAAA=
--------------ms050205010408080809080406--


From nobody Thu Apr 23 02:29:46 2020
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 BB8723A17C5 for ; Thu, 23 Apr 2020 02:29:42 -0700 (PDT)
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 (1024-bit key) header.d=forgerock.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 CNObloYdNtBq for ; Thu, 23 Apr 2020 02:29:40 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 03C1D3A17B7 for ; Thu, 23 Apr 2020 02:29:35 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id h2so5650545wmb.4 for ; Thu, 23 Apr 2020 02:29:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=si9xs2Nd5djg301n4mOSeXIo9tq9aKeABCH9i/ZO/NQ=; b=ByHM4ik92YJeZE+4Q4cPnHj9cOgWFRLh9f8QXfR/7y9aAbsFaau6i3qi3Wwdj/BEdl Fv+4II7h7/9mX98KZnyjKx9YnhY9S5LFKiAW9Ft81cp5Fs9Aoh6xUUt0HiKi5YBVDRdx Cmw75N7325Qd0nfzOGdBv2QfOkxavPcQHYWRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=si9xs2Nd5djg301n4mOSeXIo9tq9aKeABCH9i/ZO/NQ=; b=n1OUcCSc2LSI8O2YEEAGqQgN7XvAbtRNru6e+C15CztiUFQFVUUnoOHRZnZw/R62Y1 RYj2JPdwrxQHoIfoAgshHodT+iaa1xOru9rUETBK/fPbdwrLHBervsGWMjygohqVqVb1 zQ8B70YYyquKHGM6AWYY6y0LWMPVMMmyvLVwws8vQwEajybtUfQhQfpYCnvmhiXuO7Cl a30yX8K+FbbTmBGpdf/8h4KXNJ8rKDfIKRnTyL/CE8MuKSvGxAv3huRkK0as+b8LwBVd GYmEpMH+gXX+kJTs2G8d7OXVPzG+npAA3SCIsTbXkJ4IHzWqlKFJmNGOEkMsB8/KdOfo 4StA==
X-Gm-Message-State: AGi0PuYh8tzQH9Xk8Sh7QfD2McBzCkvURojddrj2njv5X8zKyLs52pm4 KU8zOEs0D6MUGeWsfc0ljqtRnQ==
X-Google-Smtp-Source: APiQypKUv6Wxboj8C1yKtSH/DYYkVvBYDr2qvAj5S3JRj9HJL+RTqe3UX37yUed39VNAO+ERbMCrqA==
X-Received: by 2002:a1c:6a17:: with SMTP id f23mr2989091wmc.136.1587634174068;  Thu, 23 Apr 2020 02:29:34 -0700 (PDT)
Received: from [10.0.0.2] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id j13sm2869405wro.51.2020.04.23.02.29.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2020 02:29:33 -0700 (PDT)
From: Neil Madden 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_BAA363B3-0C48-46AE-AA29-9DF552D26546"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 23 Apr 2020 10:29:32 +0100
In-Reply-To: 
Cc: oauth@ietf.org
To: Vladimir Dzhuvinov 
References: <9F472A63-FC87-416E-A7FF-78B87B45EE18@forgerock.com> 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth GREASE
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, 23 Apr 2020 09:29:43 -0000

--Apple-Mail=_BAA363B3-0C48-46AE-AA29-9DF552D26546
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If a clients sends a handful of random additional parameters on =
authorization requests a compliant AS will already ignore them, so there =
should be no additional burden on the AS.

However, the ship may already have sailed on the specific issue of =
request parameters, as there are major deployed services already =
rejecting unknown parameters. (I won=E2=80=99t name them, but probably a =
fair proportion of people on this list have an account with at least one =
of them). Of course, even if they eventually do enable PKCE we won=E2=80=99=
t start using it until we notice and remove them from the blacklist, so =
this harms security as well as interoperability.

I=E2=80=99m not saying the situation is anywhere near as bad for OAuth =
as it is for TLS with all the incompatible middleboxes, but there are =
definitely some other areas of potential ossification:

- I know of services that error if a published JWKSet has more than one =
key in it=20
- some error if there=E2=80=99s a JWK with an unknown =E2=80=9Ckty=E2=80=9D=
 (e.g =E2=80=9Cokp=E2=80=9D) even if they don=E2=80=99t need to use that =
JWK, same for unknown =E2=80=9Ccrv=E2=80=9D values
- there are clients that error if any value in the =
id_token_signing_alg_values_supported is not one of the original JWS =
signing algorithms (e.g., =E2=80=9CEdDSA=E2=80=9D), making it hard to =
adopt a new signature algorithm

(Basically there are quite a few clients that use JSON mapping tools =
with enum types - List. I know there are parts of our own =
codebase where we do this too).

I was only semi-serious about GREASE, but I think this is a problem that =
will only get worse over time.

=E2=80=94 Neil

> On 23 Apr 2020, at 08:54, Vladimir Dzhuvinov  =
wrote:
>=20
> I get your frustration with PKCE. It would be a bad policy and example =
to burden compliant ASes with additional stuff just because a few AS =
implementations are not complying with the spec. It's not fair and can =
end up creating all sorts of bad incentives in future.
>=20
> Vladimir
>=20
> On 22/04/2020 10:29, Neil Madden wrote:
>> Section 3.1 of RFC 6749 says (of the authorization endpoint):
>>=20
>> The authorization server MUST ignore
>>    unrecognized request parameters.
>> We hoped to be able to use this to opportunistically apply PKCE - =
always send a code_challenge in the hope that the AS supports it and =
there should be no harm if it doesn=E2=80=99t.=20
>> Sadly I learned yesterday of yet another public AS that fails hard if =
the request contains unrecognised parameters. It appears this part of =
the spec is widely ignored.=20
>> Given that this hampers the ability to add new request parameters in =
future, do we need our own GREASE to prevent these joints rusting tight?
>> https://www.rfc-editor.org/rfc/rfc8701.html =

>> =E2=80=94 Neil
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_BAA363B3-0C48-46AE-AA29-9DF552D26546
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If =
a clients sends a handful of random additional parameters on =
authorization requests a compliant AS will already ignore them, so there =
should be no additional burden on the AS.

However, the ship may already have =
sailed on the specific issue of request parameters, as there are major =
deployed services already rejecting unknown parameters. (I won=E2=80=99t =
name them, but probably a fair proportion of people on this list have an =
account with at least one of them). Of course, even if they eventually =
do enable PKCE we won=E2=80=99t start using it until we notice and =
remove them from the blacklist, so this harms security as well as =
interoperability.

I=E2=80=99m not saying the situation is anywhere =
near as bad for OAuth as it is for TLS with all the incompatible =
middleboxes, but there are definitely some other areas of potential =
ossification:

- I know of services =
that error if a published JWKSet has more than one key in =
it 
- some error if there=E2=80=99s a JWK with an unknown =
=E2=80=9Ckty=E2=80=9D (e.g =E2=80=9Cokp=E2=80=9D) even if they don=E2=80=99=
t need to use that JWK, same for unknown =E2=80=9Ccrv=E2=80=9D =
values
- there are clients that error if any value in =
the id_token_signing_alg_values_supported is not one of the =
original JWS signing algorithms (e.g., =E2=80=9CEdDSA=E2=80=9D), making =
it hard to adopt a new signature algorithm

(Basically there are quite a few clients =
that use JSON mapping tools with enum types - List<JWSAlgorithm>. =
I know there are parts of our own codebase where we do this =
too).

I was only =
semi-serious about GREASE, but I think this is a problem that will only =
get worse over time.

=E2=80=94 =
Neil

On 23 Apr 2020, at 08:54, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  
I get your frustration with PKCE. It =
would be a bad policy and
      example to burden compliant ASes with additional stuff just
      because a few AS implementations are not complying with the spec.
      It's not fair and can end up creating all sorts of bad incentives
      in future.

    
Vladimir

    

    
On 22/04/2020 10:29, Neil Madden =
wrote:

    

    

      
      Section 3.1 of RFC 6749 says (of the authorization endpoint):
      


      

      

        
The authorization server MUST ignore
   unrecognized request parameters.

        

        
We hoped to be able to use this to opportunistically =
apply PKCE - always send a code_challenge in the hope that the AS =
supports it and there should be no harm if it =
doesn=E2=80=99t. 

        



        
Sadly I learned yesterday of yet another public AS =
that fails hard if the request contains unrecognised parameters. It =
appears this part of the spec is widely =
ignored. 

        



        
Given that this hampers the ability to add new =
request parameters in future, do we need our own GREASE to prevent these =
joints rusting tight?

        
https://www.rfc-editor.org/rfc/rfc8701.html

        

        
=E2=80=94 Neil

      

    

    

  


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

=

--Apple-Mail=_BAA363B3-0C48-46AE-AA29-9DF552D26546--


From nobody Thu Apr 23 09:53:02 2020
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 6F53F3A0C95 for ; Thu, 23 Apr 2020 09:52:59 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 8tVUkJBfZYG4 for ; Thu, 23 Apr 2020 09:52:56 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650123.outbound.protection.outlook.com [40.107.65.123]) (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 1EA003A0C8F for ; Thu, 23 Apr 2020 09:52:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JQhkl23Jb6J9hd/LXL5rjbHSDcClBg2sQcwcksKjktroJcmb3i6dseWFDqY6du4OLbSurdyFmEaFGWmE5NaisqcsBhAt0TPrjKajcRc/Gsvzvx8K4LjU/5t9xcWjgWwKR07MRriL6o9Nn+wayRPKFg9ERirChPydhLScaz6znof1xj2F3fT5lHcWImtvfJDbv0d6/FOVhXN+A8InAIU7J7bgiiDSN7jsBg8I4mTEQR7nT3sfFvizCXmJW6pjMUCWSwCnX9ZyNvQkFAGXagqpr/tAzJQlJWoYI2408shPX/phTR47N8/Kyth/IB9fY7Q+gUDG7K9zk0/6h8qjL67GUQ==
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=DkcB5tTyt/q9GWnZGAIqFnYvcUhAFbcAv+PWKJF5Aq4=; b=Sl0lMKlG9BORZVZSEa0cA37MVPVRtGns6bKibxfM9kB9rIsRRHBmadTk40GDZ3jyLGuKjLKysjwuyjajiljUxpsCpBZSk68KjsCqi+Hz0FH0lJjUSNctgtgNSnc5VAYi29/m5NJureXOL62Ouw6iAN9Pm33ELpWHNR6KazkIVeOvvGNQZdUvDBV0ZKJRqwMTkr1oFwdnfDIDNE2+qX9j+xbQcGTLf7PLp9E4ievjegkPdWQGZCefP5wrhD1G39tmLZHTuaDdXQUMrGjOEbyzLnZH7J9jm+7cJhrcWslYwlwNvJ+KA4nkPXWl0eZWEDbWemt9n8JRD4HbsQmrujAN0A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DkcB5tTyt/q9GWnZGAIqFnYvcUhAFbcAv+PWKJF5Aq4=; b=CPgqxRoI3NfifBNXIiblD+iVOhRhnrQCifVy6UY/tiAou507N9OTil9VyPgVF+fAjoiXLhmWxZdwXK66WLAEdEPCiUblPG0fZHNen0vDADQXHTbG2Lo7rumq8LEj28n0P4DJx0iX+XgL+28cmsDHdAKPTAL6IkOhsqgXUlR9hlw=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0853.namprd00.prod.outlook.com (2603:10b6:610:ad::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2975.0; Thu, 23 Apr 2020 16:52:50 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::9517:9630:ed53:8dd6]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::9517:9630:ed53:8dd6%6]) with mapi id 15.20.2977.000; Thu, 23 Apr 2020 16:52:50 +0000
From: Mike Jones 
To: Neil Madden , Vladimir Dzhuvinov 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth GREASE
Thread-Index: AdYZj537nA0KzPRCRTq0r9xWXlhR1Q==
Date: Thu, 23 Apr 2020 16:52:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=03c4bc6f-cc84-4b57-a43d-0000303a252f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-23T16:49:07Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 70933fa6-0fcf-4883-259c-08d7e7a6c1f7
x-ms-traffictypediagnostic: CH2PR00MB0853:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03827AF76E
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1r5dIvwaS6iX1GzRuf9PQLf7zbyPjCmy7YV4zzMUHu6NjbH/f5HFXwpz7H+eJSrF0FOcciWy2nCwiA7MthHGsMI8dDwq8D6sIostkag5wY3RnC1EssbyxtAIOh51GLc4nr6L3mimF+apyjQQWgdpSgfqMOAiW8JOmD0EFu5CVePBC4w9AIdjxrSK4VVYf1RrQ6S3S7D/p/RtgoaSd4ZKPzwEh6f58x9lTzlfA36lfpBvGAiZ2fgPVw6XpsGjyS46qos2VUnN8VZPx8UkO+cBpbLS5QP1OKSkNBG7LZ5CWs1KBLbIdUuVhPB+NQ3+vGFNteTfoDp9ycVDi9cRR08ZUmPc/KUOG0Ga7laP0CYHjs8dHQUVGB5VmnpWXsPSlBdVVRspsKijBu3KkMgqnpEuMGJtgqqaM9yfNpw9IMFjuXmBCOzPrl+Jro16OXBkFeq68zXzGW7eciEtck66daAowBQRoT9C3oR2jOBWMwpWmmCHm8lSb7wK/1YeoBy9JbVzYojkq79dRqDeyYmxVBg4QA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(346002)(396003)(376002)(39860400002)(366004)(76116006)(66476007)(66556008)(55016002)(66946007)(86362001)(316002)(10290500003)(5660300002)(33656002)(8990500004)(186003)(53546011)(7696005)(8936002)(71200400001)(2906002)(64756008)(52536014)(26005)(66446008)(6506007)(82950400001)(966005)(9686003)(8676002)(110136005)(478600001)(82960400001)(4326008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: cpHczLpicLIqbBZDHkOT99KoP1PA3IqyLOX12Mjgr/Qt2hNfYqisSIGnDNilm5awgew/mi3U0s/RVw3S1hYrM4Xf9dxzTlnM/pOi5S//sfSi/fSbvB4B0yfvmp8A+EOdAO4IDuvMyVdtWLJE0ZI870m7WYAqUlDnKBROsrvzi+L0cmE01RYLXGoKH9Rr5chZfftlsh0xBm1z3IZNrvuuzrafXWjMmrZdHebNkkS9c7IrRYtu4TKJltUN+3clbroLEgNxHdiWRVbyYzyu4Qi+jmf3cUpPNT2NgutN1NaBfP3CuL+oucHDR5gf95CHMzbb7N5YseFQXFzx0rviZOw3iU117Y6vKtp+BZnLX1JFkfCKVqQ10E49Zi14d0jpqRsocnP1JllqUSPlz5JaQGifcRjXrYv1e5E3PIQGlIkXIi5LV1jQiRJzHgfqydnbCNnuLpdXq5twyB+sfrqTx3oLgR3nQbOKwh1ruXvM3Om2+sQ3GwA9oJTvA12FGxOiAPy8IvoZRXQpC2oos5mODmCtjk1YBw0erQ/fa/FpOuflR2+CBq4KGVRvPwtkRZCp66uCtRePxm4g3KvRAIR7OSyGlo5lMeQw6PK8Fi8lfUjOUypRFoirbnCfIyB/OmNIUD6bYmIOQmQXOsdBTytZVsK4wH0WzaZTUa1fQw0lmB05nzVMTHnRgVE5A4VG5TsLn7UHjhMkZ6xtANesohi5qE6x6lTcpwGPO3lkouY/XD7EYKKOmvzs5zmF4GgikfLy9D0/6TE/J8/w4w7YLK2lk9tWnOcueZqUllVT1yt+yYNf07o=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB06788186BFF0F6BBBA0CAB90F5D30CH2PR00MB0678namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70933fa6-0fcf-4883-259c-08d7e7a6c1f7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 16:52:49.9866 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HD4dT583kBCjD0WUwa2HjlePgPrQ0JIquxwRhvxZKqDs+islnioJfE//M1PkxO+lVBiTcIUkCYZza8jrfwyxnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0853
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth GREASE
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, 23 Apr 2020 16:53:00 -0000

--_000_CH2PR00MB06788186BFF0F6BBBA0CAB90F5D30CH2PR00MB0678namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3aWxsIHBvaW50IG91dCB0aGF0IE9wZW5JRCBDb25uZWN0IGNlcnRpZmljYXRpb24gdGVzdHMg
dGhhdCB0aGUgaW1wbGVtZW50YXRpb24gaWdub3JlcyBub3QtdW5kZXJzdG9vZCByZXF1ZXN0IHBh
cmFtZXRlcnMuICBTbyBhdCBsZWFzdCBhbGwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycyB0aGF0
IGFyZSBhbHNvIGNlcnRpZmllZCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxk
IGJlIHN1Y2Nlc3NmdWxseSBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBwYXJhbWV0ZXJzLg0KDQpJ
4oCZZCBwZXJzb25hbGx5IHBvaW50IG91dCB0aGVzZSBub24tY29tcGxpYW50IGJlaGF2aW9ycyB0
byB0aGUgdmVuZG9ycyBhbmQgYXNrIHRoZW0gdG8gZml4IHRoZW0uICBUaGVpciBub24tY29tcGxp
YW5jZSBtYWtlcyBpdCBoYXJkZXIgZm9yIGNsaWVudHMgdG8gaW50ZXJvcGVyYXRlIHdpdGggdGhl
bSwgaHVydGluZyBib3RoLiAgTmFtZSBuYW1lcywgaWYgdGhhdOKAmXMgd2hhdCBpdCB0YWtlcy4N
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs
ZiBPZiBOZWlsIE1hZGRlbg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDIwIDI6MzAgQU0N
ClRvOiBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPg0KQ2M6IG9h
dXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBHUkVBU0UNCg0KSWYg
YSBjbGllbnRzIHNlbmRzIGEgaGFuZGZ1bCBvZiByYW5kb20gYWRkaXRpb25hbCBwYXJhbWV0ZXJz
IG9uIGF1dGhvcml6YXRpb24gcmVxdWVzdHMgYSBjb21wbGlhbnQgQVMgd2lsbCBhbHJlYWR5IGln
bm9yZSB0aGVtLCBzbyB0aGVyZSBzaG91bGQgYmUgbm8gYWRkaXRpb25hbCBidXJkZW4gb24gdGhl
IEFTLg0KDQpIb3dldmVyLCB0aGUgc2hpcCBtYXkgYWxyZWFkeSBoYXZlIHNhaWxlZCBvbiB0aGUg
c3BlY2lmaWMgaXNzdWUgb2YgcmVxdWVzdCBwYXJhbWV0ZXJzLCBhcyB0aGVyZSBhcmUgbWFqb3Ig
ZGVwbG95ZWQgc2VydmljZXMgYWxyZWFkeSByZWplY3RpbmcgdW5rbm93biBwYXJhbWV0ZXJzLiAo
SSB3b27igJl0IG5hbWUgdGhlbSwgYnV0IHByb2JhYmx5IGEgZmFpciBwcm9wb3J0aW9uIG9mIHBl
b3BsZSBvbiB0aGlzIGxpc3QgaGF2ZSBhbiBhY2NvdW50IHdpdGggYXQgbGVhc3Qgb25lIG9mIHRo
ZW0pLiBPZiBjb3Vyc2UsIGV2ZW4gaWYgdGhleSBldmVudHVhbGx5IGRvIGVuYWJsZSBQS0NFIHdl
IHdvbuKAmXQgc3RhcnQgdXNpbmcgaXQgdW50aWwgd2Ugbm90aWNlIGFuZCByZW1vdmUgdGhlbSBm
cm9tIHRoZSBibGFja2xpc3QsIHNvIHRoaXMgaGFybXMgc2VjdXJpdHkgYXMgd2VsbCBhcyBpbnRl
cm9wZXJhYmlsaXR5Lg0KDQpJ4oCZbSBub3Qgc2F5aW5nIHRoZSBzaXR1YXRpb24gaXMgYW55d2hl
cmUgbmVhciBhcyBiYWQgZm9yIE9BdXRoIGFzIGl0IGlzIGZvciBUTFMgd2l0aCBhbGwgdGhlIGlu
Y29tcGF0aWJsZSBtaWRkbGVib3hlcywgYnV0IHRoZXJlIGFyZSBkZWZpbml0ZWx5IHNvbWUgb3Ro
ZXIgYXJlYXMgb2YgcG90ZW50aWFsIG9zc2lmaWNhdGlvbjoNCg0KLSBJIGtub3cgb2Ygc2Vydmlj
ZXMgdGhhdCBlcnJvciBpZiBhIHB1Ymxpc2hlZCBKV0tTZXQgaGFzIG1vcmUgdGhhbiBvbmUga2V5
IGluIGl0DQotIHNvbWUgZXJyb3IgaWYgdGhlcmXigJlzIGEgSldLIHdpdGggYW4gdW5rbm93biDi
gJxrdHnigJ0gKGUuZyDigJxva3DigJ0pIGV2ZW4gaWYgdGhleSBkb27igJl0IG5lZWQgdG8gdXNl
IHRoYXQgSldLLCBzYW1lIGZvciB1bmtub3duIOKAnGNyduKAnSB2YWx1ZXMNCi0gdGhlcmUgYXJl
IGNsaWVudHMgdGhhdCBlcnJvciBpZiBhbnkgdmFsdWUgaW4gdGhlIGlkX3Rva2VuX3NpZ25pbmdf
YWxnX3ZhbHVlc19zdXBwb3J0ZWQgaXMgbm90IG9uZSBvZiB0aGUgb3JpZ2luYWwgSldTIHNpZ25p
bmcgYWxnb3JpdGhtcyAoZS5nLiwg4oCcRWREU0HigJ0pLCBtYWtpbmcgaXQgaGFyZCB0byBhZG9w
dCBhIG5ldyBzaWduYXR1cmUgYWxnb3JpdGhtDQoNCihCYXNpY2FsbHkgdGhlcmUgYXJlIHF1aXRl
IGEgZmV3IGNsaWVudHMgdGhhdCB1c2UgSlNPTiBtYXBwaW5nIHRvb2xzIHdpdGggZW51bSB0eXBl
cyAtIExpc3Q8SldTQWxnb3JpdGhtPi4gSSBrbm93IHRoZXJlIGFyZSBwYXJ0cyBvZiBvdXIgb3du
IGNvZGViYXNlIHdoZXJlIHdlIGRvIHRoaXMgdG9vKS4NCg0KSSB3YXMgb25seSBzZW1pLXNlcmlv
dXMgYWJvdXQgR1JFQVNFLCBidXQgSSB0aGluayB0aGlzIGlzIGEgcHJvYmxlbSB0aGF0IHdpbGwg
b25seSBnZXQgd29yc2Ugb3ZlciB0aW1lLg0KDQrigJQgTmVpbA0KDQoNCk9uIDIzIEFwciAyMDIw
LCBhdCAwODo1NCwgVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxt
YWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+PiB3cm90ZToNCg0KSSBnZXQgeW91ciBmcnVz
dHJhdGlvbiB3aXRoIFBLQ0UuIEl0IHdvdWxkIGJlIGEgYmFkIHBvbGljeSBhbmQgZXhhbXBsZSB0
byBidXJkZW4gY29tcGxpYW50IEFTZXMgd2l0aCBhZGRpdGlvbmFsIHN0dWZmIGp1c3QgYmVjYXVz
ZSBhIGZldyBBUyBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCBjb21wbHlpbmcgd2l0aCB0aGUgc3Bl
Yy4gSXQncyBub3QgZmFpciBhbmQgY2FuIGVuZCB1cCBjcmVhdGluZyBhbGwgc29ydHMgb2YgYmFk
IGluY2VudGl2ZXMgaW4gZnV0dXJlLg0KVmxhZGltaXINCk9uIDIyLzA0LzIwMjAgMTA6MjksIE5l
aWwgTWFkZGVuIHdyb3RlOg0KU2VjdGlvbiAzLjEgb2YgUkZDIDY3NDkgc2F5cyAob2YgdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQpOg0KDQoNClRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU
IGlnbm9yZQ0KDQogICB1bnJlY29nbml6ZWQgcmVxdWVzdCBwYXJhbWV0ZXJzLg0KDQpXZSBob3Bl
ZCB0byBiZSBhYmxlIHRvIHVzZSB0aGlzIHRvIG9wcG9ydHVuaXN0aWNhbGx5IGFwcGx5IFBLQ0Ug
LSBhbHdheXMgc2VuZCBhIGNvZGVfY2hhbGxlbmdlIGluIHRoZSBob3BlIHRoYXQgdGhlIEFTIHN1
cHBvcnRzIGl0IGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gaGFybSBpZiBpdCBkb2VzbuKAmXQuDQoN
ClNhZGx5IEkgbGVhcm5lZCB5ZXN0ZXJkYXkgb2YgeWV0IGFub3RoZXIgcHVibGljIEFTIHRoYXQg
ZmFpbHMgaGFyZCBpZiB0aGUgcmVxdWVzdCBjb250YWlucyB1bnJlY29nbmlzZWQgcGFyYW1ldGVy
cy4gSXQgYXBwZWFycyB0aGlzIHBhcnQgb2YgdGhlIHNwZWMgaXMgd2lkZWx5IGlnbm9yZWQuDQoN
CkdpdmVuIHRoYXQgdGhpcyBoYW1wZXJzIHRoZSBhYmlsaXR5IHRvIGFkZCBuZXcgcmVxdWVzdCBw
YXJhbWV0ZXJzIGluIGZ1dHVyZSwgZG8gd2UgbmVlZCBvdXIgb3duIEdSRUFTRSB0byBwcmV2ZW50
IHRoZXNlIGpvaW50cyBydXN0aW5nIHRpZ2h0Pw0KDQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y
Zy9yZmMvcmZjODcwMS5odG1sPGh0dHBzOi8vd3d3Li5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjODcw
MS5odG1sPg0KDQrigJQgTmVpbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQoNCg==

--_000_CH2PR00MB06788186BFF0F6BBBA0CAB90F5D30CH2PR00MB0678namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpVSUNURm9udFRleHRTdHlsZUJvZHk7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p
bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAw
MjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgd2lsbCBwb2lu
dCBvdXQgdGhhdCBPcGVuSUQgQ29ubmVjdCBjZXJ0aWZpY2F0aW9uIHRlc3RzIHRoYXQgdGhlIGlt
cGxlbWVudGF0aW9uIGlnbm9yZXMgbm90LXVuZGVyc3Rvb2QgcmVxdWVzdCBwYXJhbWV0ZXJzLiZu
YnNwOyBTbyBhdCBsZWFzdCBhbGwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycyB0aGF0IGFyZSBh
bHNvIGNlcnRpZmllZCBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMNCiBzaG91bGQgYmUg
c3VjY2Vzc2Z1bGx5IGlnbm9yaW5nIG5vdC11bmRlcnN0b29kIHBhcmFtZXRlcnMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J4oCZZCBwZXJzb25hbGx5IHBvaW50IG91dCB0
aGVzZSBub24tY29tcGxpYW50IGJlaGF2aW9ycyB0byB0aGUgdmVuZG9ycyBhbmQgYXNrIHRoZW0g
dG8gZml4IHRoZW0uJm5ic3A7IFRoZWlyIG5vbi1jb21wbGlhbmNlIG1ha2VzIGl0IGhhcmRlciBm
b3IgY2xpZW50cyB0byBpbnRlcm9wZXJhdGUgd2l0aCB0aGVtLCBodXJ0aW5nIGJvdGguJm5ic3A7
IE5hbWUgbmFtZXMsIGlmIHRoYXTigJlzDQogd2hhdCBpdCB0YWtlcy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJl
aGFsZiBPZiA8L2I+DQpOZWlsIE1hZGRlbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXBy
aWwgMjMsIDIwMjAgMjozMCBBTTxicj4NCjxiPlRvOjwvYj4gVmxhZGltaXIgRHpodXZpbm92ICZs
dDt2bGFkaW1pckBjb25uZWN0MmlkLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYu
b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIEdSRUFTRTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYSBjbGllbnRzIHNlbmRzIGEg
aGFuZGZ1bCBvZiByYW5kb20gYWRkaXRpb25hbCBwYXJhbWV0ZXJzIG9uIGF1dGhvcml6YXRpb24g
cmVxdWVzdHMgYSBjb21wbGlhbnQgQVMgd2lsbCBhbHJlYWR5IGlnbm9yZSB0aGVtLCBzbyB0aGVy
ZSBzaG91bGQgYmUgbm8gYWRkaXRpb25hbCBidXJkZW4gb24gdGhlIEFTLjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgdGhlIHNoaXAgbWF5IGFs
cmVhZHkgaGF2ZSBzYWlsZWQgb24gdGhlIHNwZWNpZmljIGlzc3VlIG9mIHJlcXVlc3QgcGFyYW1l
dGVycywgYXMgdGhlcmUgYXJlIG1ham9yIGRlcGxveWVkIHNlcnZpY2VzIGFscmVhZHkgcmVqZWN0
aW5nIHVua25vd24gcGFyYW1ldGVycy4gKEkgd29u4oCZdCBuYW1lIHRoZW0sIGJ1dCBwcm9iYWJs
eSBhIGZhaXIgcHJvcG9ydGlvbiBvZiBwZW9wbGUgb24gdGhpcyBsaXN0DQogaGF2ZSBhbiBhY2Nv
dW50IHdpdGggYXQgbGVhc3Qgb25lIG9mIHRoZW0pLiBPZiBjb3Vyc2UsIGV2ZW4gaWYgdGhleSBl
dmVudHVhbGx5IGRvIGVuYWJsZSBQS0NFIHdlIHdvbuKAmXQgc3RhcnQgdXNpbmcgaXQgdW50aWwg
d2Ugbm90aWNlIGFuZCByZW1vdmUgdGhlbSBmcm9tIHRoZSBibGFja2xpc3QsIHNvIHRoaXMgaGFy
bXMgc2VjdXJpdHkgYXMgd2VsbCBhcyBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IHNh
eWluZyB0aGUgc2l0dWF0aW9uIGlzIGFueXdoZXJlIG5lYXIgYXMgYmFkIGZvciBPQXV0aCBhcyBp
dCBpcyBmb3IgVExTIHdpdGggYWxsIHRoZSBpbmNvbXBhdGlibGUgbWlkZGxlYm94ZXMsIGJ1dCB0
aGVyZSBhcmUgZGVmaW5pdGVseSBzb21lIG90aGVyIGFyZWFzIG9mIHBvdGVudGlhbCBvc3NpZmlj
YXRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPi0gSSBrbm93IG9mIHNlcnZpY2VzIHRoYXQgZXJyb3IgaWYgYSBwdWJsaXNoZWQgSldLU2V0
IGhhcyBtb3JlIHRoYW4gb25lIGtleSBpbiBpdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBzb21lIGVycm9yIGlmIHRoZXJl4oCZcyBh
IEpXSyB3aXRoIGFuIHVua25vd24g4oCca3R54oCdIChlLmcg4oCcb2tw4oCdKSBldmVuIGlmIHRo
ZXkgZG9u4oCZdCBuZWVkIHRvIHVzZSB0aGF0IEpXSywgc2FtZSBmb3IgdW5rbm93biDigJxjcnbi
gJ0gdmFsdWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4tIHRoZXJlIGFyZSBjbGllbnRzIHRoYXQgZXJyb3IgaWYgYW55IHZhbHVlIGluIHRoZSZu
YnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy
aWYiPmlkX3Rva2VuX3NpZ25pbmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWQgaXMgbm90IG9uZSBvZiB0
aGUgb3JpZ2luYWwgSldTIHNpZ25pbmcgYWxnb3JpdGhtcyAoZS5nLiwg4oCcRWREU0HigJ0pLCBt
YWtpbmcgaXQgaGFyZCB0byBhZG9wdCBhIG5ldyBzaWduYXR1cmUNCiBhbGdvcml0aG08L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPihC
YXNpY2FsbHkgdGhlcmUgYXJlIHF1aXRlIGEgZmV3IGNsaWVudHMgdGhhdCB1c2UgSlNPTiBtYXBw
aW5nIHRvb2xzIHdpdGggZW51bSB0eXBlcyAtIExpc3QmbHQ7SldTQWxnb3JpdGhtJmd0Oy4gSSBr
bm93IHRoZXJlIGFyZSBwYXJ0cyBvZiBvdXIgb3duIGNvZGViYXNlIHdoZXJlIHdlIGRvIHRoaXMg
dG9vKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgd2FzIG9ubHkgc2VtaS1zZXJpb3VzIGFib3V0IEdSRUFTRSwgYnV0IEkgdGhp
bmsgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCB3aWxsIG9ubHkgZ2V0IHdvcnNlIG92ZXIgdGltZS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCU
IE5laWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gMjMgQXByIDIwMjAsIGF0IDA4OjU0LCBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhy
ZWY9Im1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSI+dmxhZGltaXJAY29ubmVjdDJpZC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+SSBnZXQgeW91ciBmcnVzdHJhdGlvbiB3aXRoIFBLQ0UuIEl0IHdvdWxkIGJlIGEg
YmFkIHBvbGljeSBhbmQgZXhhbXBsZSB0byBidXJkZW4gY29tcGxpYW50IEFTZXMgd2l0aCBhZGRp
dGlvbmFsIHN0dWZmIGp1c3QgYmVjYXVzZSBhIGZldyBBUyBpbXBsZW1lbnRhdGlvbnMgYXJlIG5v
dCBjb21wbHlpbmcgd2l0aA0KIHRoZSBzcGVjLiBJdCdzIG5vdCBmYWlyIGFuZCBjYW4gZW5kIHVw
IGNyZWF0aW5nIGFsbCBzb3J0cyBvZiBiYWQgaW5jZW50aXZlcyBpbiBmdXR1cmUuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlZsYWRpbWlyPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIvMDQvMjAyMCAxMDoyOSwgTmVpbCBNYWRk
ZW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
U2VjdGlvbiAzLjEgb2YgUkZDIDY3NDkgc2F5cyAob2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p
bnQpOg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSItd2Via2l0LXRleHQt
c2l6ZS1hZGp1c3Q6IGF1dG87YnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVycy48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzticmVh
ay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJpZiI+V2UgaG9wZWQgdG8gYmUg
YWJsZSB0byB1c2UgdGhpcyB0byBvcHBvcnR1bmlzdGljYWxseSBhcHBseSBQS0NFIC0gYWx3YXlz
IHNlbmQgYSBjb2RlX2NoYWxsZW5nZSBpbiB0aGUgaG9wZSB0aGF0IHRoZSBBUyBzdXBwb3J0cyBp
dCBhbmQgdGhlcmUgc2hvdWxkIGJlIG5vIGhhcm0gaWYgaXQgZG9lc27igJl0LiZuYnNwOzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OyxzZXJp
ZiI+U2FkbHkgSSBsZWFybmVkIHllc3RlcmRheSBvZiB5ZXQgYW5vdGhlciBwdWJsaWMgQVMgdGhh
dCBmYWlscyBoYXJkIGlmIHRoZSByZXF1ZXN0IGNvbnRhaW5zIHVucmVjb2duaXNlZCBwYXJhbWV0
ZXJzLiBJdCBhcHBlYXJzIHRoaXMgcGFydCBvZiB0aGUgc3BlYyBpcyB3aWRlbHkgaWdub3JlZC4m
bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkm
cXVvdDssc2VyaWYiPkdpdmVuIHRoYXQgdGhpcyBoYW1wZXJzIHRoZSBhYmlsaXR5IHRvIGFkZCBu
ZXcgcmVxdWVzdCBwYXJhbWV0ZXJzIGluIGZ1dHVyZSwgZG8gd2UgbmVlZCBvdXIgb3duIEdSRUFT
RSB0byBwcmV2ZW50IHRoZXNlIGpvaW50cyBydXN0aW5nIHRpZ2h0Pzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBo
cmVmPSJodHRwczovL3d3dy4ucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg3MDEuaHRtbCI+aHR0cHM6
Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg3MDEuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPuKAlCBOZWlsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CH2PR00MB06788186BFF0F6BBBA0CAB90F5D30CH2PR00MB0678namp_--


From nobody Thu Apr 23 10:15:31 2020
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 829AA3A0D57 for ; Thu, 23 Apr 2020 10:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlCkJ9JjHVBR for ; Thu, 23 Apr 2020 10:15:20 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 1FF713A0D23 for ; Thu, 23 Apr 2020 10:15:20 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id t63so7218680wmt.3 for ; Thu, 23 Apr 2020 10:15:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZpNf8yL8NZX/+xzasxcXVRCQyLeuZXYK1B8zEKr46l4=; b=FxQluEcIdlgz/8WMM6MvEI6HjIMIf16T6eFoHhVx2q+BoFbnvoaqKuoynT6mhDRa9m IzOhQJvdl0kHybdOcdOQo1RNesPrxb3bZKaJQ/FJvv4y5qM3uFXSP7ZGoYiuEuZhssoJ dGSyOdh4xrONUbGiNxkS6h+m/SVBj9N647IlOp5JdnCsuMbq7FsbuwJ8pCVYQpd/9Yhq 6riCBfjfasNd1OJvz29kXkMpmYOIf+z3qwAl0rC8fWKPBXa9Ww/4Xe1w0D53D9mHTHJA figfkKOpar3CG6EHMSRuk/rNe0wYvcMErhzSiK+Spy7UMcRPvb4SHc/7x1Jmik2KIBoS FZcQ==
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=ZpNf8yL8NZX/+xzasxcXVRCQyLeuZXYK1B8zEKr46l4=; b=um5r5uik2YldP/LCK/YnQwl79wJHdoh70Mt6zzC/LmktxVdgRFC0a/AHGLOgNMrBF8 uC7DHQrPua2hXy6zstd6DA3+r/tZPragzudrtwVoxXTOeeEehAfph9g9RtHMF/t3DvfY McFFW8rsprXG8YFS4P6tbk2FmgZ6vVHVq2p+0gCptWRzOu5qW3Cfc88e/MhoQASF/UuA +0L0UyxVDDmEOS3dcBLmleYHvGqypmKfOxtx8G2Kll9DWd6X7HriH+mLPdurQ0zRh7Ni Ygca5kSCji9hC4zd8r3daIZYp829cIcdBuegRKQekfpbYjvpyu/nl5OK/Zh8sN6Kbp/F SVlA==
X-Gm-Message-State: AGi0PuaDVUn3/eaOHVv0JJLqu6nHIPwu5Qc4Z+8CctrZMYE4LACvD4Vy 3gERqYsBUWMpmbVKCLHg1sUhwPcZVla0n5GI6hwVATQ/XAE=
X-Google-Smtp-Source: APiQypLoYR/UfMzJsY0DAPDDhLxfRXBTXNEgQixEa9HNCYqE2QHjjyCNttgnNHGH9nSmf5VPg7NOjm52ufUDkSDBk/c=
X-Received: by 2002:a1c:a549:: with SMTP id o70mr5150906wme.179.1587662117987;  Thu, 23 Apr 2020 10:15:17 -0700 (PDT)
MIME-Version: 1.0
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>    
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Fri, 24 Apr 2020 02:15:06 +0900
Message-ID: 
To: oauth 
Cc: Dominick Baier , Rifaat Shekh-Yusef ,  Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="00000000000090fffc05a3f8641a"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 23 Apr 2020 17:15:30 -0000

--00000000000090fffc05a3f8641a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

First, to make the discussion fair, I think I should share what I observed
today. Auth0's client_credentials flow requires an "audience" parameter,
which is equivalent to the "resource" parameter defined in RFC 8707, and
embeds the client ID in the generated JWT access token as the value of the
"sub" claim.

My opinion as a software engineer is as follows.

[aud]
The "aud" claim should be null or absent when the "resource" parameters are
not given in an authorization request. It is not good to introduce
inflexible rules to determine the default value for the "aud" claim based
on the "scope" parameter.

[sub]
The "sub" claim should be null or absent when a resource owner is not
involved in an authorization request. To be concrete, the "sub" claim
should be null or absent in the client credentials flow. The spec draft
says in "5. Security Considerations" as follows.

- - - - - - - - - -
Authorization servers should prevent scenarios where clients can affect the
value of the sub claim in ways that could confuse resource servers.  For
example: if the authorization server elects to use the client_id as the sub
value for access tokens issued client credentials grant, the authorization
server should prevent clients to register an arbitrary client_id value, as
this would allow malicious clients to select the sub of a high privilege
resource owner and confuse any authorization logic on the resource server
relying on the sub value.  For more details please refer to section 4.13 of
[OAuth2.Security.BestPractices].

To preventing cross-JWT confusion, authorization servers MUST use a
distinct identifier as "aud" claim value to uniquely identify access tokens
issued by the same issuer for distinct resources.
- - - - - - - - - -

However, the attack vector is brought about merely by introducing the
following rule defined in "2.2. Data Structure".

- - - - - - - - - -
In case of access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub SHOULD
correspond to an identifier the authorization server uses to indicate the
client application.
- - - - - - - - - -

If the rule is not introduced, the attack vector disappears and the "aud"
claim doesn't have to be mandatory.

Finally, to make the discussion fair, I should also mention that I myself
is a co-founder of Authlete, Inc. that provides an implementation of OAuth
and OpenID Connect. My thoughts about implementations of access tokens are
publicly described here:

OAuth Access Token Implementation
https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci  wrote:

> Ouch! Sorry =F0=9F=98=8A fixed
>
>
>
> *From: *Dominick Baier 
> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth , Rifaat Shekh-Yusef ,
> Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Oh and while we are at it - could you also fix the typo in my name? Thank=
s
> ;)
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
> vittorio.bertocci@auth0.com) wrote:
>
> This is a great point. In my head I just considered the OIDC semantic and
> thought only of highlighting the app identity case, but you are absolutel=
y
> right that not mentioning the user case at all is confusing. I added the
> language you suggested at the beginning of the sub definition.
>
> Thanks!
>
>
>
> *From: *Dominick Baier 
> *Date: *Monday, April 20, 2020 at 22:54
> *To: *oauth , Rifaat Shekh-Yusef ,
> "vittorio.bertocci@auth0.com" 
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> In case of access tokens obtained through grants where no resource owner =
is involved, such as the client credentials grant, the value of sub SHOULD =
correspond to an identifier the authorization server uses to indicate the c=
lient application.
>
>
>
> Maybe I am missing something, but does it say anywhere what to explicitly
> do in the case of an access token where a resource owner is involved?
>
>
>
> There=E2=80=99s some language that seems to imply that, e.g.:
>
>
>
> as this would allow malicious
>
>    clients to select the sub of a high privilege resource owner
>
> I would have expected to see something stronger like above just -
>
>
>
> In case of access tokens obtained through grants where a resource owner i=
s involved, such as the authorisation code grant, the value of sub SHOULD c=
orrespond to the subject identifier of the resource owner.
>
>
>
> If this spec is about interop, I think this should be at least a
> recommendation...
>
>
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (
> vittorio.bertocci@auth0.com) wrote:
>
> Thanks Dominick for your comments!
>
> Inline
>
>
>
> *>** All other OAuth specs make a very clear distinction between users
> and client.*
>
> There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In previ=
ous
> discussions on this topic it has been brought up that the JWT spec define=
s
> sub as identifying the principal that is the subject of the JWT, and that=
=E2=80=99s
> not necessarily limited to users.
>
> However I get the potential confusion, and I am happy to add clarifying l=
anguage if you have specific passages in the space you are particularly wor=
ried about: however I feel the matter is addressed upfront by the language =
in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtaine=
d through grants where no resource owner is involved, such as the client cr=
edentials grant, the value of sub SHOULD correspond to an identifier the au=
thorization server uses to indicate the client application.=E2=80=9C and Se=
ction 5 has an entire paragraph discussing things to watch out in assigning=
 sub values in the app identity case. Feel free to suggest additional langu=
age if you want to clarify further.
>
>
>
> *> sub has a different semantic here as in OIDC*
>
> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
> OIDC, to preempt that concern and keep the original sub semantic availabl=
e.
>
>
>
> *>** I am not fully clear why aud is required.*
>
> Aud is there mostly because of three reasons:
>
> =C2=B7         Many existing specs postulate its existence in the token. =
No
> one declares it as a proper MUST (apart from the BCP, but that=E2=80=99s =
partial)
> however I think its importance comes across..
> -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
> mechanism to prevent token redirect (and adds scope restriction as also
> important, however here we make it optional to acocut for non-delegations
> scenario).
> -Resource indicators RFC8707 refers to the same section of RFC7519 as one
> of the assumptions that must hold to prevent bearer tokens misuse
> -BCP225 makes aud mandatory for AS which can issue JWTs for more than one
> app
>
> =C2=B7         Apart from Ping, for which some of its examples are withou=
t aud
> (but also without identifying scopes, given that the one I retrieved had
> only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from=
 vendors all
> featured an aud. I know one shoulnd=E2=80=99t overindex on those examples=
, but
> together with the above it seemed to point to something universally usefu=
l.
> One possible reason is that use of a format for the AT is correlated with
> topologies where AS and RS are separated by some boundary (network,
> logical, business, code factoring, etc) hence identifying the resource
> seems like a natural need. Again, not an iron clad law, but an indication=
.
>
> =C2=B7         A lot of people repurpose existing libraries for the JWT A=
T
> case, and some people even sends id_tokens in lieu of ATs. That doesn=E2=
=80=99t
> mean that we should condone any bad practices, but in tis particular case
> it suggests that lots of developers already expect/can handle an audience
> in the JWT used to call their API
>
> None of those are a slam dunk argument for mandatory, but I find them
> compelling enough to simplify validation and just require an aud to be
> there, as opposed to introduce complications that make it conditional to
> the presence of scopes or other disambiguation. One reason I feel pretty
> good about that is that adding a default audience isn=E2=80=99t very hard=
 if any of
> the above assumptions end up not being true for a particular case
>
>
>
> *> What=E2=80=99s the rationale for using iat instead of nbf. *
>
> That=E2=80=99s just straight from OIDC ID_tokens, and the considerations =
about
> repurposing existing logic. I see there=E2=80=99s a thread on this specif=
ically,
> let me answer further on that branch.
>
>
>
> *> This spec feels somehow in between a profile and a BCP*
>
> You are right that this spec attempts to go beyond just declaring a
> layout, and I agree this means that this profile will not apply to
> absolutely everyone. The reason I tried that route (at the cost of workin=
g
> way harder in the last year for reaching consensus than if we would have
> just listed the possible content), is that I often observe implementers
> make questionable choices because of the large leeway specifications allo=
w.
> My hope was that the scope of this profile was small enough to make that
> extra level of guidance achievable, whereas trying to do the same with a
> larger spec would have been prohibitively expensive.
>
> I believe things worked out well so far: we had lots of constructive
> discussions, and I ended up relaxing A LOT of the constraints I was
> originally envisioning. Nonetheless, my hope is that we identified the
> right set of guidelines that will help people actually interoperate out o=
f
> the box for the most basic/common scenarios, as opposed to complying with
> the letter of the spec but still having a lot to figure out out of band.
>
>
>
> *From:* OAuth  *On Behalf Of *Dominick Baier
> *Sent:* Thursday, April 16, 2020 12:10 AM
> *To:* Rifaat Shekh-Yusef ; oauth 
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Since this is the last call, I thought I bring up some of thoughts /
> concerns. Some of them have been discussed before.
>
>
>
> *client_id vs sub*
>
> I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of =
the claim types
> based on flow.
>
> If the intention is, that sub expresses the entity against which the
> resource will do authorisation (and that might be a client or a user) - I
> get it (and maybe it should be stated like that) - but
>
> this thinking reminds me of the old AD days where there was no distinctio=
n
> between user and service accounts (something that has been fixed IIRC in
> Windows Server 2012 R2).
>
>
>
> All other OAuth specs make a very clear distinction between users and
> client.
>
>
>
> Furthermore it says
>
>
>
> "Authorization servers should prevent scenarios where clients can
>
>    affect the value of the sub claim in ways that could confuse resource
>
>    servers.=E2=80=9D
>
>
>
> If we keep that dual semantics of the sub claim - it must be clearly
> stated, that subject ID and client ID are now in the same collision domai=
n.
> So when an AS / OP creates them, they need to be unique across user ids a=
nd
> client ids.
>
>
>
> Maybe it should be also explicitly mentioned that sub has a different
> semantic here as in OIDC - even though a majority of the software built
> today will use them together.
>
>
>
> *audience claim*
>
> I am not fully clear why aud is required. OAuth itself does not have a
> notion of an audience (in the JWT sense) - they have scopes (which is ver=
y
> similar). But in simple scenarios where resources don=E2=80=99t exist, yo=
u'd need
> to make up an audience just to fulfil this requirement. And in many case
> this will be either static or just repeat the scope values. What=E2=80=99=
s the
> value of that?
>
>
>
> If the concept of resources are used, I absolutely agree that aud should
> be used too. But I wouldn=E2=80=99t make it required.
>
>
>
> *iat vs nbf*
>
> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t=
 most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?
>
>
>
> *General*
>
> This spec feels somehow in between a profile and a BCP. On one hand you
> define some claims and their semantics (good) - on the other hand there i=
s
> some prescriptive guidance and maybe over-specification. My concern is,
> that in the end no-one will fully comply with it, because it doesn=E2=80=
=99t work
> one way or the other for them.
>
>
>
> I know we just went though the discussion to make certain claims required
> as opposed to optional - but maybe less is more.
>
>
>
> Tbh - the most valuable part of the doc to me is the definition of the
> =E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see=
 just some standard claims
> and IF they are used, which semantics they have.
>
>
>
> cheers
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
> wrote:
>
> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profil=
e
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> _______________________________________________
> 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
>

--00000000000090fffc05a3f8641a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


First, to make the discussion fair, I think I should share=
 what I observed today. Auth0's client_credentials flow requires an &qu=
ot;audience" parameter, which is equivalent to the "resource"=
; parameter defined in RFC 8707, and embeds the client ID in the generated =
JWT access token as the value of the "sub" claim.

My opini=
on as a software engineer is as follows.

[aud]
The "aud"=
; claim should be null or absent when the "resource" parameters a=
re not given in an authorization request. It is not good to introduce infle=
xible rules to determine the default value for the "aud" claim ba=
sed on the "scope" parameter.

[sub]
The "sub"=
 claim should be null or absent when a resource owner is not involved in an=
 authorization request. To be concrete, the "sub" claim should be=
 null or absent in the client credentials flow. The spec draft says in &quo=
t;5. Security Considerations" as follows.

- - - - - - - - - -Authorization servers should prevent scenarios where clients can affect t=
he value of the sub claim in ways that could confuse resource servers.=C2=
=A0 For example: if the authorization server elects to use the client_id as=
 the sub value for access tokens issued client credentials grant, the autho=
rization server should prevent clients to register an arbitrary client_id v=
alue, as this would allow malicious clients to select the sub of a high pri=
vilege resource owner and confuse any authorization logic on the resource s=
erver relying on the sub value.=C2=A0 For more details please refer to sect=
ion 4.13 of [OAuth2.Security.BestPractices].

To preventing cross-JWT=
 confusion, authorization servers MUST use a distinct identifier as "a=
ud" claim value to uniquely identify access tokens issued by the same =
issuer for distinct resources.
- - - - - - - - - -

However, the a=
ttack vector is brought about merely by introducing the following rule defi=
ned in "2.2. Data Structure".

- - - - - - - - - -
In ca=
se of access tokens obtained through grants where no resource owner is invo=
lved, such as the client credentials grant, the value of sub SHOULD corresp=
ond to an identifier the authorization server uses to indicate the client a=
pplication.
- - - - - - - - - -

If the rule is not introduced, th=
e attack vector disappears and the "aud" claim doesn't have t=
o be mandatory.

Finally, to make the discussion fair, I should also =
mention that I myself is a co-founder of Authlete, Inc. that provides an im=
plementation of OAuth and OpenID Connect. My thoughts about implementations=
 of access tokens are publicly described here:

OAuth Access Token Im=
plementation
https://medium.com/@darutk/oauth-access-token-im=
plementation-30c2e8b90ff0

Best Regards,
Takahiko Kawasaki
=
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci <vit=
torio.bertocci=3D40auth0.com@=
dmarc.ietf.org> wrote:











Ouch! Sorry =F0=9F=98=8A fixed


=C2=A0




From: =
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Tuesday, April 21, 2020 at 10:23

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertoc=
ci <vit=
torio.bertocci@auth0.com>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






Oh and while we are at it - could you also fix the typo in my name? Thanks=
 ;)




=C2=A0




=E2=80=94=E2=80=94=E2=80=94 




Dominick Baier






=C2=A0


On 21. April 2020 at 09:4=
3:49, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:










This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the
 user case at all is confusing. I added the language you suggested at the b=
eginning of the sub definition.


Thanks!


=C2=A0




From:
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "vittorio.bertocci=
@auth0.com" <vittorio.bertocci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






In case =
of access tokens obtained through grants where no resource owner is involve=
d, such as the client credentials grant, the value of sub SHOULD correspond=
 to an identifier the authorization server uses to indicate the client appl=
ication.






=C2=A0






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






=C2=A0






There=E2=80=99s some language that seems to imply th=
at, e.g.:






=C2=A0






as this would allow malicious<=
/u>


=C2=A0=C2=A0 clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just -=C2=A0






=C2=A0






In=
 case of access tokens obtained through grants where a resource owner is in=
volved, such as the authorisation code grant, the value of sub SHOULD corre=
spond to the subject identifier of the resource owner.=







=C2=A0






If this spec is about interop, I think this should b=
e at least a recommendation...






=C2=A0




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 20. April 2020 at 09:=
48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


=C2=A0


> All other OAuth specs make a very clear distinction between=
 users and client.


There=E2=80=99s a nuance worth highlighting here: su=
b !=3D user. In previous discussions on this topic it has been brought up t=
hat the JWT spec defines sub as identifying the principal that
 is the subject of the JWT, and that=E2=80=99s not necessarily limited to u=
sers. 


However =
I get the potential confusion, and I am happy to add clarifying language if=
 you have specific passages in the space you are particularly worried about=
: however I feel the matter is addressed upfront by the language in Section=
 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained through grants where no resource =
owner is involved, such as the client credentials grant, the value of sub S=
HOULD correspond to an identifier the authorization server uses to indicate=
 the client application.=E2=80=9C and Section 5 has an entire paragra=
ph discussing things to watch out in assigning sub values in the app identi=
ty case. Feel free to suggest additional language if you want to clarify fu=
rther. 


=C2=A0


> sub has a different semantic here as in OIDC<=
/u>


The =C2=A0spec refers to RFC7519 in the sub definiti=
on in 2.2, rather than OIDC, to preempt that concern and keep the original =
sub semantic available.


=C2=A0


> I am not fully clear why aud is required.=



Aud is there mostly because of three reasons:=



=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Many existing specs postulate its existence in the token. No one dec=
lares it as a proper MUST (apart from the BCP, but that=E2=80=99s partial) =
however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp


=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Apart from Ping, for which some of its examples are without aud (but=
 also without identifying scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from vendor=
s all featured an aud. I know one shoulnd=E2=80=99t overindex
 on those examples, but together with the above it seemed to point to somet=
hing universally useful. One possible reason is that use of a format for th=
e AT is correlated with topologies where AS and RS are separated by some bo=
undary (network, logical, business,
 code factoring, etc) hence identifying the resource seems like a natural n=
eed. Again, not an iron clad law, but an indication.


=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
A lot of people repurpose existing libraries for the JWT AT case, an=
d some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t mea=
n that we should condone any bad practices, but in tis particular case it s=
uggests that lots of developers already
 expect/can handle an audience in the JWT used to call their API<=
/u>


None of those are a slam dunk argument for mandatory=
, but I find them compelling enough to simplify validation and just require=
 an aud to be there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
. One reason I feel pretty good about that is that adding a default audienc=
e isn=E2=80=99t very hard if any of the above assumptions end up not being =
true for a particular case


=C2=A0


> What=E2=80=99s the rationale for using iat instead of nbf.



That=E2=80=99s just straight from OIDC ID_tokens, an=
d the considerations about repurposing existing logic. I see there=E2=80=99=
s a thread on this specifically, let me answer further on that branch.


=C2=A0


> This spec feels somehow in between a profile and a BCP<=
u>


You are right that this spec attempts to go beyond j=
ust declaring a layout, and I agree this means that this profile will not a=
pply to absolutely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots=
 of constructive discussions, and I ended up relaxing A LOT of the constrai=
nts I was originally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



=C2=A0






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0




Since this is the last call, I thought I bring up some of thoughts / conce=
rns. Some of them have been discussed before.






=C2=A0






client_id vs sub






I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of t=
he claim types based on flow.






If the intention is, that sub expresses the entity against which the resou=
rce will do authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinking reminds me of the old AD days where there was no distinction=
 between user and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






=C2=A0






All other OAuth specs make a very clear distinction between users and clie=
nt.






=C2=A0






Furthermore it says






=C2=A0






"Authorization servers should prevent scenarios where clients can






=C2=A0 =C2=A0affect the value of the sub claim in ways that could confuse =
resource






=C2=A0 =C2=A0servers.=E2=80=9D






=C2=A0






If we keep that dual semantics of the sub claim - it must be clearly state=
d, that subject ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






=C2=A0






Maybe it should be also explicitly mentioned that sub has a different sema=
ntic here as in OIDC - even though a majority of the
 software built today will use them together.






=C2=A0






audience claim






I am not fully clear why aud is required. OAuth itself does not have a not=
ion of an audience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=E2=80=99t exist, you'd need to make up an audience just to fulfil thi=
s requirement. And in many case this will be either static or just repeat t=
he scope values. What=E2=80=99s the value of that?






=C2=A0






If the concept of resources are used, I absolutely agree that aud should b=
e used too. But I wouldn=E2=80=99t make it required.





=C2=A0






iat vs nbf






What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t =
most JWT libraries (including e.g. the .NET one) looking for nbf by
 default?






=C2=A0






General






This spec feels somehow in between a profile and a BCP. On one hand you de=
fine some claims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=E2=80=99t work one way or the other for them.






=C2=A0






I know we just went though the discussion to make certain claims required =
as opposed to optional - but maybe less is more.






=C2=A0






Tbh - the most valuable part of the doc to me is the definition of the =E2=
=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see just
 some standard claims and IF they are used, which semantics they have.






=C2=A0




cheers=C2=A0




=E2=80=94=E2=80=94=E2=80=94




Dominick Baier






=C2=A0


On 15. April 2020 at 20:59:31, Rifaat Shekh-Y=
usef (rifaat.iet=
f@gmail.com) wrote:











Hi all,



=C2=A0



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



=C2=A0



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-access-tok=
en-jwt-06



=C2=A0



Please send your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0




_______________________________________________


OAuth mailing list 

OAuth@ietf.org 

h=
ttps://www.ietf.org/mailman/listinfo/oauth





























_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--00000000000090fffc05a3f8641a--


From nobody Thu Apr 23 15:30:45 2020
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 98EE93A0045 for ; Thu, 23 Apr 2020 15:30:42 -0700 (PDT)
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=pingidentity.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 V21unhWoGhNn for ; Thu, 23 Apr 2020 15:30:40 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 120C53A003D for ; Thu, 23 Apr 2020 15:30:38 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id m2so6062619lfo.6 for ; Thu, 23 Apr 2020 15:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CHZhctslP/0Wsa1fJovp7gEZboXKkBTDeidCLcZeleg=; b=BYCT01dRx4pcgMLPsx/xAf2Uvic4q+J2ac+bVwgLNKVmCB60QMgpSHItS1+0P8jIbu sB2kQT9feZgYrJiLQamvB5iRNpuSYK0OfcVmR0+ofGAlJY6UrQuL9Roan1HxuVPH7Bl+ YhdgfRSixM+dYoqRbI/CjDlsuCVS5LkkawH5AGywaPPMlYdDEHmzRu3UhNgIZ+rk1CHV hPx+88FtDEhPQTNjGy8d+pXFGcs/1jXL4X8XzeYs6kihLrtV6X2BvDvzhHzijv3uOHHN JU/4gZH3e7r66l/zhuwHpcd6f8eZqaBcAnGkTZz5XqgTP+PxSPcrfEKeT/X/6r3WtBwJ jv2A==
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=CHZhctslP/0Wsa1fJovp7gEZboXKkBTDeidCLcZeleg=; b=PIZnUp9jVUYLWq+VETve4OJqvlExXRm8X3xZFIs0NE6btoOovzpo8Do4ht29mB+4yX Rd35hY+VXwTxigs9bhlf7UZmr7sH3lsKllilPv6SwyBofmJRCopVF1T4nWvfNZvUK8Vf daRQ0AM8M+mAoVT4GwcAJjE+86cYVML8Db8qLuWTCHMZMRqOl7iHWq7EVShKW3Z/e3xw vGkCjZR4sNfArkUhRe+lnhHIvKeg+dqZcarJxOvpLYBRVPN1A1DxIULjmjOU4+sQgt2A k5+6Mn9cvuX9lCpx9RFMmL6EczTvyUtzY/KBlXG5nRdu4Da1UCFQKtYJ9oc6OaTzsnMv yhHg==
X-Gm-Message-State: AGi0Pua1et1boWmnbgO494j77IeaQbXAGnIlYMFJYXZP1dTtVelhBI5a DJQSB+1L+pmoHBsVS+tbnVBggx6+SGc3FPT3/UQWd6+kqkiUkVw4cyXVbSUtK0aXwz2lzOqSXx0 bUjGELWdb8FtZbQ==
X-Google-Smtp-Source: APiQypJAk5p9qb50lkL0DNbq6dxO+4drmNPuBTxUK1Tz8Q8AUQhbim85pigfniagrw0htn7Dxjk8ZacFyZfedFp0y3s=
X-Received: by 2002:a05:6512:308c:: with SMTP id z12mr3815164lfd.195.1587681036116;  Thu, 23 Apr 2020 15:30:36 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Thu, 23 Apr 2020 16:30:09 -0600
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth , Roman Danyliw 
Content-Type: multipart/alternative; boundary="0000000000002ccbfe05a3fccc09"
Archived-At: 
Subject: Re: [OAUTH-WG] April 20th Interim Meeting Minutes
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, 23 Apr 2020 22:30:43 -0000

--0000000000002ccbfe05a3fccc09
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

An action item coming out of this latest interim meeting was to propose
some updated text for review on JAR to address the problem that PAR is
currently facing where it can be interpreted that JAR says that the
request_uri must refer to JWT.

I've taken a stab at such an update and proposed text changes can be seen
in this pull request
https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/3/attempt-to-tweak-the=
-wording-in-jar-so/diff



On Mon, Apr 20, 2020 at 12:08 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> You can find the minutes for this meeting on the following link:
>
> https://datatracker.ietf.org/meeting/interim-2020-oauth-05/materials/minu=
tes-interim-2020-oauth-05-202004201200
>
>
> Thanks to *Jared Jennings *for taking these notes.
>
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000002ccbfe05a3fccc09
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


An action item coming out of this latest interim meet=
ing was to propose some updated text for review on JAR to address the probl=
em that PAR is currently facing where it can be interpreted that JAR says t=
hat the request_uri must refer to JWT.

I've ta=
ken a stab at such an update and proposed text changes can be seen in this =
pull request https://bitbucket.org/Nat/=
oauth-jwsreq/pull-requests/3/attempt-to-tweak-the-wording-in-jar-so/diff



<=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 20, 2020 at 12:08 PM Rifaa=
t Shekh-Yusef <rifaat.ietf@gmai=
l.com> wrote:
All,

You can find the m=
inutes for this=C2=A0meeting on the following link:

Thanks to Jared Jenni=
ngs for taking these notes.

Regards,
=C2=A0Rifaat & Hannes=C2=A0

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000002ccbfe05a3fccc09--


From nobody Thu Apr 23 18:01:39 2020
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 182A03A0C3A for ; Thu, 23 Apr 2020 18:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWSEJ1xAWwPU for ; Thu, 23 Apr 2020 18:01:33 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 A081F3A0C40 for ; Thu, 23 Apr 2020 18:01:32 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id g13so8777965wrb.8 for ; Thu, 23 Apr 2020 18:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s+BTlEaUmx2PV75AzSShNP05ZQHxcp2IG/8hAcbV9d8=; b=rPSEf8F84VeWXkdC2S4EUEz3z7UYyxegMi5Ezp5/lgl2pfSzAjvd9roOTs2TBye1p9 ZqJtyeQvNb5aU+XIVCLwJSNP4dGNYT7+DUo5rGH4vYYlZwScEUIHxGlD0+4l3lmkKlF3 sc5cfdMwff2h6ViqN7Jw5pFwNuPUpQJWVTS5VDbmJITAvjr3NfoLmtLEgkigRM+NNVg/ XxRvMle+crFpgr57HCtaRsZttyP3gWJ2SztrTraoj3MUzVS/wH/07DK7jv9EXEpeERkW kzD1M5S7jiZ3gqJogr9zfhZX3TK7bqs9dgxsFwdaRUF7B7/izHhPhoepZ5s3iA0niOwJ Swww==
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=s+BTlEaUmx2PV75AzSShNP05ZQHxcp2IG/8hAcbV9d8=; b=inYeKn9l04KMMjon8uNdWV+jmLFy4jV7GPTFUM2wR79ZyRG890j9/duG4a7vz/ie+J R/J7MytbYXXmT1HOlx5kw02h/Z6idk6q4KBRJSaTfUMx+Ah2bMLwwQIqAcnOamIaWbq+ fsR+neBQ3Wa1W1EMohre4hGM12ZTXqetEay4XaMbP1aaGBsfTz1a575iWHx8jQXkF5lD x38QQo49v3oYqGqAlRffSbwO6GdAlS8NUwOy/s9Bb9F0cm+xs1AHA6lWW1hjy66cV1po 9i8WF1Y2CTokI92t4ilqHRZdyOLh2dQoBv1v784jt4arf5Ckmal301H3oPp19uTo7nyK ne2Q==
X-Gm-Message-State: AGi0PuZrJXI7iOYm70pgVRRgvHg3uIIADYXtLWVVU0gKJ1yg3v6s81eT S6ajsAgHV/Hw/71/2aWjIOSuS8LrwDn7q8K7tGpc5dX6Klg=
X-Google-Smtp-Source: APiQypI0TPazsCtz1ETvNf89BP4LN1aFUZeFOM7Ptr0kcV2M2qs7PTYnKHlZaG7IzG3lfG0VSgUXrmZExavy+iazmPw=
X-Received: by 2002:adf:df8e:: with SMTP id z14mr7784775wrl.319.1587690090385;  Thu, 23 Apr 2020 18:01:30 -0700 (PDT)
MIME-Version: 1.0
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>     
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Fri, 24 Apr 2020 10:01:18 +0900
Message-ID: 
To: oauth 
Cc: Dominick Baier , Rifaat Shekh-Yusef ,  Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="000000000000d9e5ed05a3fee789"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 24 Apr 2020 01:01:38 -0000

--000000000000d9e5ed05a3fee789
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I apologize if my previous post has made you all here feel unpleasant,
especially I'm sorry for the author, the chairs, and people who directly
joined the discussion about the spec. I could have expressed my
disagreement on the requirements for "aud" and "sub" in another different
way. For software specifications and architectures, I'm liable to get
excited and aggressive. Please forgive me.

Regarding the relationship between "aud" and "scope", the assumption in the
draft is not necessarily applicable to all possible use cases. For example,
multiple resources may share the same scopes. What if both "/resource1" and
"/resource2" recognize "get" scope and "update" scope? In this case, it is
not appropriate to determine the default resource indicator for "aud" from
the scopes. It is also impossible to map scopes to resources and vice
versa. The assumption in the current draft is too narrow to be included in
a standard. If the current description continues to exist, it will impose
big restrictions on the design of scopes and resources.

If you still think the "aud" claim should always exist, then the
authorization endpoint and/or the token endpoint (and/or the backchannel
authentication endpoint and/or the device authorization endpoint) of your
system can require the "resource" request parameter as mandatory. We don't
have to put rules to determine the default "aud" value into the spec about
JWT access tokens. The "resource" parameter defined in RFC 8707 can work
regardless of whether the format of access tokens is JWT or not. Therefore,
it is not appropriate to discuss the necessity of the "aud" claim only in
the context of "JWT" access tokens.

Regarding the "sub" claim, setting the client ID there, rather, will
confuse resource servers. If the "sub" claim is set even in the case of the
client credentials flow, resource servers cannot judge whether the "sub"
claim represents either the subject of the resource owner or the client ID.
On the other hand, if the "sub" claim is null or absent in the case of the
client credentials flow, resource servers can always handle the value of
the "sub" claim as the subject of the resource owner. For resource servers,
this logic is easier. Setting the "sub" claim in every case to make
resource server implementations simpler is not convincing.

Best Regards,
Taka

On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki  wrote=
:

> First, to make the discussion fair, I think I should share what I observe=
d
> today. Auth0's client_credentials flow requires an "audience" parameter,
> which is equivalent to the "resource" parameter defined in RFC 8707, and
> embeds the client ID in the generated JWT access token as the value of th=
e
> "sub" claim.
>
> My opinion as a software engineer is as follows.
>
> [aud]
> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> inflexible rules to determine the default value for the "aud" claim based
> on the "scope" parameter.
>
> [sub]
> The "sub" claim should be null or absent when a resource owner is not
> involved in an authorization request. To be concrete, the "sub" claim
> should be null or absent in the client credentials flow. The spec draft
> says in "5. Security Considerations" as follows.
>
> - - - - - - - - - -
> Authorization servers should prevent scenarios where clients can affect
> the value of the sub claim in ways that could confuse resource servers.
> For example: if the authorization server elects to use the client_id as t=
he
> sub value for access tokens issued client credentials grant, the
> authorization server should prevent clients to register an arbitrary
> client_id value, as this would allow malicious clients to select the sub =
of
> a high privilege resource owner and confuse any authorization logic on th=
e
> resource server relying on the sub value.  For more details please refer =
to
> section 4.13 of [OAuth2.Security.BestPractices].
>
> To preventing cross-JWT confusion, authorization servers MUST use a
> distinct identifier as "aud" claim value to uniquely identify access toke=
ns
> issued by the same issuer for distinct resources.
> - - - - - - - - - -
>
> However, the attack vector is brought about merely by introducing the
> following rule defined in "2.2. Data Structure".
>
> - - - - - - - - - -
> In case of access tokens obtained through grants where no resource owner
> is involved, such as the client credentials grant, the value of sub SHOUL=
D
> correspond to an identifier the authorization server uses to indicate the
> client application.
> - - - - - - - - - -
>
> If the rule is not introduced, the attack vector disappears and the "aud"
> claim doesn't have to be mandatory.
>
> Finally, to make the discussion fair, I should also mention that I myself
> is a co-founder of Authlete, Inc. that provides an implementation of OAut=
h
> and OpenID Connect. My thoughts about implementations of access tokens ar=
e
> publicly described here:
>
> OAuth Access Token Implementation
> https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci  40auth0.com@dmarc.ietf.org> wrote:
>
>> Ouch! Sorry =F0=9F=98=8A fixed
>>
>>
>>
>> *From: *Dominick Baier 
>> *Date: *Tuesday, April 21, 2020 at 10:23
>> *To: *oauth , Rifaat Shekh-Yusef =
,
>> Vittorio Bertocci 
>> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
>> for OAuth 2.0 Access Tokens"
>>
>>
>>
>> Oh and while we are at it - could you also fix the typo in my name?
>> Thanks ;)
>>
>>
>>
>> =E2=80=94=E2=80=94=E2=80=94
>>
>> Dominick Baier
>>
>>
>>
>> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
>> vittorio.bertocci@auth0.com) wrote:
>>
>> This is a great point. In my head I just considered the OIDC semantic an=
d
>> thought only of highlighting the app identity case, but you are absolute=
ly
>> right that not mentioning the user case at all is confusing. I added the
>> language you suggested at the beginning of the sub definition.
>>
>> Thanks!
>>
>>
>>
>> *From: *Dominick Baier 
>> *Date: *Monday, April 20, 2020 at 22:54
>> *To: *oauth , Rifaat Shekh-Yusef =
,
>> "vittorio.bertocci@auth0.com" 
>> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
>> for OAuth 2.0 Access Tokens"
>>
>>
>>
>> In case of access tokens obtained through grants where no resource owner=
 is involved, such as the client credentials grant, the value of sub SHOULD=
 correspond to an identifier the authorization server uses to indicate the =
client application.
>>
>>
>>
>> Maybe I am missing something, but does it say anywhere what to explicitl=
y
>> do in the case of an access token where a resource owner is involved?
>>
>>
>>
>> There=E2=80=99s some language that seems to imply that, e.g.:
>>
>>
>>
>> as this would allow malicious
>>
>>    clients to select the sub of a high privilege resource owner
>>
>> I would have expected to see something stronger like above just -
>>
>>
>>
>> In case of access tokens obtained through grants where a resource owner =
is involved, such as the authorisation code grant, the value of sub SHOULD =
correspond to the subject identifier of the resource owner.
>>
>>
>>
>> If this spec is about interop, I think this should be at least a
>> recommendation...
>>
>>
>>
>>
>>
>> =E2=80=94=E2=80=94=E2=80=94
>>
>> Dominick Baier
>>
>>
>>
>> On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (
>> vittorio.bertocci@auth0.com) wrote:
>>
>> Thanks Dominick for your comments!
>>
>> Inline
>>
>>
>>
>> *>** All other OAuth specs make a very clear distinction between users
>> and client.*
>>
>> There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In prev=
ious
>> discussions on this topic it has been brought up that the JWT spec defin=
es
>> sub as identifying the principal that is the subject of the JWT, and tha=
t=E2=80=99s
>> not necessarily limited to users.
>>
>> However I get the potential confusion, and I am happy to add clarifying =
language if you have specific passages in the space you are particularly wo=
rried about: however I feel the matter is addressed upfront by the language=
 in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtain=
ed through grants where no resource owner is involved, such as the client c=
redentials grant, the value of sub SHOULD correspond to an identifier the a=
uthorization server uses to indicate the client application.=E2=80=9C and S=
ection 5 has an entire paragraph discussing things to watch out in assignin=
g sub values in the app identity case. Feel free to suggest additional lang=
uage if you want to clarify further.
>>
>>
>>
>> *> sub has a different semantic here as in OIDC*
>>
>> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
>> OIDC, to preempt that concern and keep the original sub semantic availab=
le.
>>
>>
>>
>> *>** I am not fully clear why aud is required.*
>>
>> Aud is there mostly because of three reasons:
>>
>> =C2=B7         Many existing specs postulate its existence in the token.=
 No
>> one declares it as a proper MUST (apart from the BCP, but that=E2=80=99s=
 partial)
>> however I think its importance comes across..
>> -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
>> mechanism to prevent token redirect (and adds scope restriction as also
>> important, however here we make it optional to acocut for non-delegation=
s
>> scenario).
>> -Resource indicators RFC8707 refers to the same section of RFC7519 as on=
e
>> of the assumptions that must hold to prevent bearer tokens misuse
>> -BCP225 makes aud mandatory for AS which can issue JWTs for more than on=
e
>> app
>>
>> =C2=B7         Apart from Ping, for which some of its examples are witho=
ut
>> aud (but also without identifying scopes, given that the one I retrieved
>> had only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received=
 from vendors all
>> featured an aud. I know one shoulnd=E2=80=99t overindex on those example=
s, but
>> together with the above it seemed to point to something universally usef=
ul.
>> One possible reason is that use of a format for the AT is correlated wit=
h
>> topologies where AS and RS are separated by some boundary (network,
>> logical, business, code factoring, etc) hence identifying the resource
>> seems like a natural need. Again, not an iron clad law, but an indicatio=
n.
>>
>> =C2=B7         A lot of people repurpose existing libraries for the JWT =
AT
>> case, and some people even sends id_tokens in lieu of ATs. That doesn=E2=
=80=99t
>> mean that we should condone any bad practices, but in tis particular cas=
e
>> it suggests that lots of developers already expect/can handle an audienc=
e
>> in the JWT used to call their API
>>
>> None of those are a slam dunk argument for mandatory, but I find them
>> compelling enough to simplify validation and just require an aud to be
>> there, as opposed to introduce complications that make it conditional to
>> the presence of scopes or other disambiguation. One reason I feel pretty
>> good about that is that adding a default audience isn=E2=80=99t very har=
d if any of
>> the above assumptions end up not being true for a particular case
>>
>>
>>
>> *> What=E2=80=99s the rationale for using iat instead of nbf. *
>>
>> That=E2=80=99s just straight from OIDC ID_tokens, and the considerations=
 about
>> repurposing existing logic. I see there=E2=80=99s a thread on this speci=
fically,
>> let me answer further on that branch.
>>
>>
>>
>> *> This spec feels somehow in between a profile and a BCP*
>>
>> You are right that this spec attempts to go beyond just declaring a
>> layout, and I agree this means that this profile will not apply to
>> absolutely everyone. The reason I tried that route (at the cost of worki=
ng
>> way harder in the last year for reaching consensus than if we would have
>> just listed the possible content), is that I often observe implementers
>> make questionable choices because of the large leeway specifications all=
ow.
>> My hope was that the scope of this profile was small enough to make that
>> extra level of guidance achievable, whereas trying to do the same with a
>> larger spec would have been prohibitively expensive.
>>
>> I believe things worked out well so far: we had lots of constructive
>> discussions, and I ended up relaxing A LOT of the constraints I was
>> originally envisioning. Nonetheless, my hope is that we identified the
>> right set of guidelines that will help people actually interoperate out =
of
>> the box for the most basic/common scenarios, as opposed to complying wit=
h
>> the letter of the spec but still having a lot to figure out out of band.
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Dominick Baier
>> *Sent:* Thursday, April 16, 2020 12:10 AM
>> *To:* Rifaat Shekh-Yusef ; oauth 
>> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
>> for OAuth 2.0 Access Tokens"
>>
>>
>>
>> Since this is the last call, I thought I bring up some of thoughts /
>> concerns. Some of them have been discussed before.
>>
>>
>>
>> *client_id vs sub*
>>
>> I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of=
 the claim types
>> based on flow.
>>
>> If the intention is, that sub expresses the entity against which the
>> resource will do authorisation (and that might be a client or a user) - =
I
>> get it (and maybe it should be stated like that) - but
>>
>> this thinking reminds me of the old AD days where there was no
>> distinction between user and service accounts (something that has been
>> fixed IIRC in Windows Server 2012 R2).
>>
>>
>>
>> All other OAuth specs make a very clear distinction between users and
>> client.
>>
>>
>>
>> Furthermore it says
>>
>>
>>
>> "Authorization servers should prevent scenarios where clients can
>>
>>    affect the value of the sub claim in ways that could confuse resource
>>
>>    servers.=E2=80=9D
>>
>>
>>
>> If we keep that dual semantics of the sub claim - it must be clearly
>> stated, that subject ID and client ID are now in the same collision doma=
in.
>> So when an AS / OP creates them, they need to be unique across user ids =
and
>> client ids.
>>
>>
>>
>> Maybe it should be also explicitly mentioned that sub has a different
>> semantic here as in OIDC - even though a majority of the software built
>> today will use them together.
>>
>>
>>
>> *audience claim*
>>
>> I am not fully clear why aud is required. OAuth itself does not have a
>> notion of an audience (in the JWT sense) - they have scopes (which is ve=
ry
>> similar). But in simple scenarios where resources don=E2=80=99t exist, y=
ou'd need
>> to make up an audience just to fulfil this requirement. And in many case
>> this will be either static or just repeat the scope values. What=E2=80=
=99s the
>> value of that?
>>
>>
>>
>> If the concept of resources are used, I absolutely agree that aud should
>> be used too. But I wouldn=E2=80=99t make it required.
>>
>>
>>
>> *iat vs nbf*
>>
>> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99=
t most JWT
>> libraries (including e.g. the .NET one) looking for nbf by default?
>>
>>
>>
>> *General*
>>
>> This spec feels somehow in between a profile and a BCP. On one hand you
>> define some claims and their semantics (good) - on the other hand there =
is
>> some prescriptive guidance and maybe over-specification. My concern is,
>> that in the end no-one will fully comply with it, because it doesn=E2=80=
=99t work
>> one way or the other for them.
>>
>>
>>
>> I know we just went though the discussion to make certain claims require=
d
>> as opposed to optional - but maybe less is more.
>>
>>
>>
>> Tbh - the most valuable part of the doc to me is the definition of the
>> =E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to se=
e just some standard claims
>> and IF they are used, which semantics they have.
>>
>>
>>
>> cheers
>>
>> =E2=80=94=E2=80=94=E2=80=94
>>
>> Dominick Baier
>>
>>
>>
>> On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com=
)
>> wrote:
>>
>> Hi all,
>>
>>
>>
>> This is a second working group last call for "JSON Web Token (JWT)
>> Profile for OAuth 2.0 Access Tokens".
>>
>>
>>
>> Here is the document:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>>
>>
>>
>> Please send your comments to the OAuth mailing list by April 29, 2020.
>>
>>
>>
>> Regards,
>>
>>  Rifaat & Hannes
>>
>>
>>
>> _______________________________________________
>> 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
>>
>

--000000000000d9e5ed05a3fee789
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I apologize if my previous post has made you all here feel=
 unpleasant, especially I'm sorry for the author, the chairs, and peopl=
e who directly joined the discussion about the spec. I could have expressed=
 my disagreement on the requirements for "aud" and "sub"=
; in another different way. For software specifications and architectures, =
I'm liable to get excited and aggressive. Please forgive me.

Reg=
arding the relationship between "aud" and "scope", the =
assumption in the draft is not necessarily applicable to all possible use c=
ases. For example, multiple resources may share the same scopes. What if bo=
th "/resource1" and "/resource2" recognize "get&qu=
ot; scope and "update" scope? In this case, it is not appropriate=
 to determine the default resource indicator for "aud" from the s=
copes. It is also impossible to map scopes to resources and vice versa. The=
 assumption in the current draft is too narrow to be included in a standard=
. If the current description continues to exist, it will impose big restric=
tions on the design of scopes and resources.

If you still think the =
"aud" claim should always exist, then the authorization endpoint =
and/or the token endpoint (and/or the backchannel authentication endpoint a=
nd/or the device authorization endpoint) of your system can require the &qu=
ot;resource" request parameter as mandatory. We don't have to put =
rules to determine the default "aud" value into the spec about JW=
T access tokens. The "resource" parameter defined in RFC 8707 can=
 work regardless of whether the format of access tokens is JWT or not. Ther=
efore, it is not appropriate to discuss the necessity of the "aud"=
; claim only in the context of "JWT" access tokens.

Regard=
ing the "sub" claim, setting the client ID there, rather, will co=
nfuse resource servers. If the "sub" claim is set even in the cas=
e of the client credentials flow, resource servers cannot judge whether the=
 "sub" claim represents either the subject of the resource owner =
or the client ID. On the other hand, if the "sub" claim is null o=
r absent in the case of the client credentials flow, resource servers can a=
lways handle the value of the "sub" claim as the subject of the r=
esource owner. For resource servers, this logic is easier. Setting the &quo=
t;sub" claim in every case to make resource server implementations sim=
pler is not convincing. 

Best Regards,
Taka

On Fri, Apr 24, 20=
20 at 2:15 AM Takahiko Kawasaki <ta=
ka@authlete.com> wrote:
First, to make the discussion fair, I think=
 I should share what I observed today. Auth0's client_credentials flow =
requires an "audience" parameter, which is equivalent to the &quo=
t;resource" parameter defined in RFC 8707, and embeds the client ID in=
 the generated JWT access token as the value of the "sub" claim.<=
br>
My opinion as a software engineer is as follows.

[aud]
The=
 "aud" claim should be null or absent when the "resource&quo=
t; parameters are not given in an authorization request. It is not good to =
introduce inflexible rules to determine the default value for the "aud=
" claim based on the "scope" parameter.

[sub]
The =
"sub" claim should be null or absent when a resource owner is not=
 involved in an authorization request. To be concrete, the "sub" =
claim should be null or absent in the client credentials flow. The spec dra=
ft says in "5. Security Considerations" as follows.

- - - =
- - - - - - -
Authorization servers should prevent scenarios where clien=
ts can affect the value of the sub claim in ways that could confuse resourc=
e servers.=C2=A0 For example: if the authorization server elects to use the=
 client_id as the sub value for access tokens issued client credentials gra=
nt, the authorization server should prevent clients to register an arbitrar=
y client_id value, as this would allow malicious clients to select the sub =
of a high privilege resource owner and confuse any authorization logic on t=
he resource server relying on the sub value.=C2=A0 For more details please =
refer to section 4.13 of [OAuth2.Security.BestPractices].

To prevent=
ing cross-JWT confusion, authorization servers MUST use a distinct identifi=
er as "aud" claim value to uniquely identify access tokens issued=
 by the same issuer for distinct resources.
- - - - - - - - - -

H=
owever, the attack vector is brought about merely by introducing the follow=
ing rule defined in "2.2. Data Structure".

- - - - - - - -=
 - -
In case of access tokens obtained through grants where no resource =
owner is involved, such as the client credentials grant, the value of sub S=
HOULD correspond to an identifier the authorization server uses to indicate=
 the client application.
- - - - - - - - - -

If the rule is not i=
ntroduced, the attack vector disappears and the "aud" claim doesn=
't have to be mandatory.

Finally, to make the discussion fair, I=
 should also mention that I myself is a co-founder of Authlete, Inc. that p=
rovides an implementation of OAuth and OpenID Connect. My thoughts about im=
plementations of access tokens are publicly described here:

OAuth Ac=
cess Token Implementation
https://medium.co=
m/@darutk/oauth-access-token-implementation-30c2e8b90ff0

Best Re=
gards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:=
19 AM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro=
te:











Ouch! Sorry =F0=9F=98=8A fixed


=C2=A0




From: =
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Tuesday, April 21, 2020 at 10:23

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertoc=
ci <vit=
torio.bertocci@auth0.com>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






Oh and while we are at it - could you also fix the typo in my name? Thanks=
 ;)




=C2=A0




=E2=80=94=E2=80=94=E2=80=94 




Dominick Baier






=C2=A0


On 21. April 2020 at 09:43:49, Vittorio Bertocci (vittorio.bertocci@auth0.com)=
 wrote:










This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the
 user case at all is confusing. I added the language you suggested at the b=
eginning of the sub definition.


Thanks!


=C2=A0




From:
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "vittorio.bertocci=
@auth0.com" <vittorio.bertocci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






In case =
of access tokens obtained through grants where no resource owner is involve=
d, such as the client credentials grant, the value of sub SHOULD correspond=
 to an identifier the authorization server uses to indicate the client appl=
ication.






=C2=A0






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






=C2=A0






There=E2=80=99s some language that seems to imply th=
at, e.g.:






=C2=A0






as this would allow malicious<=
/u>


=C2=A0=C2=A0 clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just -=C2=A0






=C2=A0






In case of access tokens obtained throu=
gh grants where a resource owner is involved, such as the authorisation cod=
e grant, the value of sub SHOULD correspond to the subject identifier of th=
e resource owner.






=C2=A0






If this spec is about interop, I think this should b=
e at least a recommendation...






=C2=A0




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 20. April 2020 at 09:48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


=C2=A0


> All other OAuth specs make a very clear distinction between=
 users and client.


There=E2=80=99s a nuance worth highlighting here: su=
b !=3D user. In previous discussions on this topic it has been brought up t=
hat the JWT spec defines sub as identifying the principal that
 is the subject of the JWT, and that=E2=80=99s not necessarily limited to u=
sers. 


However =
I get the potential confusion, and I am happy to add clarifying language if=
 you have specific passages in the space you are particularly worried about=
: however I feel the matter is addressed upfront by the language in Section=
 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained through grants where no resource =
owner is involved, such as the client credentials grant, the value of sub S=
HOULD correspond to an identifier the authorization server uses to indicate=
 the client application.=E2=80=9C and Section 5 has an entire paragra=
ph discussing things to watch out in assigning sub values in the app identi=
ty case. Feel free to suggest additional language if you want to clarify fu=
rther. 


=C2=A0


> sub has a different semantic here as in OIDC<=
/u>


The =C2=A0spec refers to RFC7519 in the sub definiti=
on in 2.2, rather than OIDC, to preempt that concern and keep the original =
sub semantic available.


=C2=A0


> I am not fully clear why aud is required.=



Aud is there mostly because of three reasons:=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Many existing specs postulate its existence in the token. No one dec=
lares it as a proper MUST (apart from the BCP, but that=E2=80=99s partial) =
however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Apart from Ping, for which some of its examples are without aud (but=
 also without identifying scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from vendor=
s all featured an aud. I know one shoulnd=E2=80=99t overindex
 on those examples, but together with the above it seemed to point to somet=
hing universally useful. One possible reason is that use of a format for th=
e AT is correlated with topologies where AS and RS are separated by some bo=
undary (network, logical, business,
 code factoring, etc) hence identifying the resource seems like a natural n=
eed. Again, not an iron clad law, but an indication.


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
A lot of people repurpose existing libraries for the JWT AT case, an=
d some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t mea=
n that we should condone any bad practices, but in tis particular case it s=
uggests that lots of developers already
 expect/can handle an audience in the JWT used to call their API<=
/u>


None of those are a slam dunk argument for mandatory=
, but I find them compelling enough to simplify validation and just require=
 an aud to be there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
. One reason I feel pretty good about that is that adding a default audienc=
e isn=E2=80=99t very hard if any of the above assumptions end up not being =
true for a particular case


=C2=A0


> What=E2=80=99s the rationale for using iat instead of nbf.



That=E2=80=99s just straight from OIDC ID_tokens, an=
d the considerations about repurposing existing logic. I see there=E2=80=99=
s a thread on this specifically, let me answer further on that branch.


=C2=A0


> This spec feels somehow in between a profile and a BCP<=
u>


You are right that this spec attempts to go beyond j=
ust declaring a layout, and I agree this means that this profile will not a=
pply to absolutely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots=
 of constructive discussions, and I ended up relaxing A LOT of the constrai=
nts I was originally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



=C2=A0






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0




Since this is the last call, I thought I bring up some of thoughts / conce=
rns. Some of them have been discussed before.






=C2=A0






client_id vs sub






I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of t=
he claim types based on flow.






If the intention is, that sub expresses the entity against which the resou=
rce will do authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinking reminds me of the old AD days where there was no distinction=
 between user and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






=C2=A0






All other OAuth specs make a very clear distinction between users and clie=
nt.






=C2=A0






Furthermore it says






=C2=A0






"Authorization servers should prevent scenarios where clients can






=C2=A0 =C2=A0affect the value of the sub claim in ways that could confuse =
resource






=C2=A0 =C2=A0servers.=E2=80=9D






=C2=A0






If we keep that dual semantics of the sub claim - it must be clearly state=
d, that subject ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






=C2=A0






Maybe it should be also explicitly mentioned that sub has a different sema=
ntic here as in OIDC - even though a majority of the
 software built today will use them together.






=C2=A0






audience claim






I am not fully clear why aud is required. OAuth itself does not have a not=
ion of an audience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=E2=80=99t exist, you'd need to make up an audience just to fulfil thi=
s requirement. And in many case this will be either static or just repeat t=
he scope values. What=E2=80=99s the value of that?






=C2=A0






If the concept of resources are used, I absolutely agree that aud should b=
e used too. But I wouldn=E2=80=99t make it required.





=C2=A0






iat vs nbf






What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t =
most JWT libraries (including e.g. the .NET one) looking for nbf by
 default?






=C2=A0






General






This spec feels somehow in between a profile and a BCP. On one hand you de=
fine some claims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=E2=80=99t work one way or the other for them.






=C2=A0






I know we just went though the discussion to make certain claims required =
as opposed to optional - but maybe less is more.






=C2=A0






Tbh - the most valuable part of the doc to me is the definition of the =E2=
=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see just
 some standard claims and IF they are used, which semantics they have.






=C2=A0




cheers=C2=A0




=E2=80=94=E2=80=94=E2=80=94




Dominick Baier






=C2=A0


On 15. April 2020 a=
t 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:











Hi all,



=C2=A0



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



=C2=A0



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-access-tok=
en-jwt-06



=C2=A0



Please send your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0




_______________________________________________


OAuth mailing list 

OAuth@ietf.org 

h=
ttps://www.ietf.org/mailman/listinfo/oauth





























_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






--000000000000d9e5ed05a3fee789--


From nobody Thu Apr 23 19:55:41 2020
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 82EB93A0E60 for ; Thu, 23 Apr 2020 19:55:39 -0700 (PDT)
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 LKYhkk7dQHex for ; Thu, 23 Apr 2020 19:55:37 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 9565D3A0E5A for ; Thu, 23 Apr 2020 19:55:34 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id r16so6084031edw.5 for ; Thu, 23 Apr 2020 19:55:34 -0700 (PDT)
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=2/yOJeve7//uZF1XPSShIWKllUTpGgOoGSmZHcbMuJA=; b=bNnv4aWwQEWsDkCjcx/QIKvHNPGTRjASBD+4hW8dEoM9GQxamwP23UOa4EYokFt4mC nxZE2FKjQoeWLjXs/AxOTSUSNuiBXRe6ojOPGhecqhUzK4zltQ81kGvGB0Z1uce/2UJM +O/67jw46IGuKCyMSZLm/gu+3ER7y4S/tKNAHNqw777yQ1dU1U1c8DBHkEPmgbbc3nfd Rj088muCFIWDLTEkUDaHuzm9gCXnmQbOGgQLT9I+RxP+SXTs5N1jii9j5WMfIyeSm7h/ /TqCex8oGqOSbqm0nQK2NarZFjkMeOhb9GYRrU4Z2rMpmHs4YHJkT37fyhsdo3JKAlF3 D1DQ==
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=2/yOJeve7//uZF1XPSShIWKllUTpGgOoGSmZHcbMuJA=; b=sZ3eOmyB1uVVnT4Pi4lAebGEwGDjGl6pHd8tjSP6n4i5RY0Bz1NgdPfRvZDdHc4JjD hNScZyBJXFNU3S6QI2Dd4hHa5WU5AypBl85xlGzYEHK3Wl03/Tu7T1LqpwccW37J+Y+L 3vpDHVZn2FXqdTWz0IqJSoQ0o7J3Iywa3lnKpfKvpUkUNagHZYcJa1SV8zOE0oT4b4Pz +6xSZFuwkM+bRoCk5OSOL42IL0VQ5gIycHjxxvipJVPcYfqvbd7EWDi3J3tQLH//rDjX /3idF27bMtcvcCxcBTJOm3CE71HkGI1cVHZOl8LExqzy0IGCmT1uMj02NzcEqnoI/8+t ymOQ==
X-Gm-Message-State: AGi0PuaqLkSHiel7H6g09DtPpbZ62++kkjYt1u1nKzcmxpCvcEBaSCV2 Fb7NujDfyAFxX+A0vVovexiqkoKC5BTd2iJ5v76ApV7nkxI=
X-Google-Smtp-Source: APiQypKjwqosc0rRrksp/whCglhnXNWYTn5/Hb4v7BHcXSj7bZbddML8qnBqk283WZMR/IerdWEWb7qxwJ0CvyXIC7s=
X-Received: by 2002:aa7:cd08:: with SMTP id b8mr5216099edw.96.1587696932363; Thu, 23 Apr 2020 19:55:32 -0700 (PDT)
MIME-Version: 1.0
From: Jared Jennings 
Date: Thu, 23 Apr 2020 21:55:21 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000aa225d05a4007f78"
Archived-At: 
Subject: [OAUTH-WG] Structured management of working documents
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, 24 Apr 2020 02:55:40 -0000

--000000000000aa225d05a4007f78
Content-Type: text/plain; charset="UTF-8"

Hi all,

I know I am super new to the list, so bare with me with my
observations that I would like share with the group. Probably no one in the
list knows me, but I am used to online forms, mailing lists and I been
involved in various open source applications for many years. So, these
comments do not come from someone that isn't used to mailing lists.

With that said, I find it difficult to follow the different
threads, revisions, suggestions, comments, and topics that we discuss. It
also seems that the current format makes it very difficult for the
maintainer of the document.

As a suggestions or question, is there a reason we are not using a platform
designed for this type of work? Like Github, bitbucket, etc. A great
example is the link that Brian shared. I can see exactly what is going on
and I could even propose my own patch, which saves the editor loads of work.
https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/3/attempt-to-tweak-the-wording-in-jar-so/diff

Thanks for listening.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152

--000000000000aa225d05a4007f78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,

I know I am super new to the li=
st, so bare=C2=A0with me with my observations=C2=A0that I would like share =
with the group. Probably no one in the list knows me, but I am used to onli=
ne forms, mailing lists and I been involved in various=C2=A0open source app=
lications for many years. So, these comments=C2=A0do not come from someone =
that isn't used to mailing lists.

With that sa=
id, I find it difficult to follow the different threads,=C2=A0revisions, su=
ggestions, comments, and topics that we discuss. It also seems that the cur=
rent format makes it very difficult for the maintainer of the document.

As a suggestions or question, is there a reason we ar=
e not using a platform designed for this type of work? Like Github, bitbuck=
et, etc. A great example is the link that Brian shared. I can see exactly w=
hat is going on and I could even propose my own patch, which saves the edit=
or loads of work.

Thanks for listening.

-Jared
Skype=
:jaredljennings
Signal:+1 816.730.9540
WhatsApp:=C2=A0+=
1 816.678.4152


--000000000000aa225d05a4007f78--


From nobody Fri Apr 24 13:24:13 2020
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 6B07A3A0A94 for ; Fri, 24 Apr 2020 13:24:11 -0700 (PDT)
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 MQp62qXmn3JA for ; Fri, 24 Apr 2020 13:24:07 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 5E90F3A0A90 for ; Fri, 24 Apr 2020 13:24:07 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id x77so5353073pfc.0 for ; Fri, 24 Apr 2020 13:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=5O4QAiT3afxDdJ2AU0FrblY8TdE5xFwUoGRN/7R5mag=; b=DE1XTbuyJPVtg6Wff/XkogEM2qPghaDf6xHJQZobozX7SbI7mnjhy5wK25LPSrEVhm OeVS4vebZhl8prSwJPweeF1444e6AvW2xEklY53l3zLXN2CPLp7TtnUjtiP6JhEXa/O3 nWdWFypnp09ycs8PhS6Z6lGE3ruNT71QXgy3ddlS2TqP1Nyw5btQd1Zc0h5ek1+0CLIr Z79XGW78YOgor5AJmRMtQDTk0kcSLEw/Aqjv4x0c45Qy6pAdMpx9UAweOXHxTPlU9xnL TLyd2i0OpM0d0jzOlZtdLJqkzi/lxv7OfK+SDqV2gwoEnl0Sz+2erO/7e512DiU5yK3s ngDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=5O4QAiT3afxDdJ2AU0FrblY8TdE5xFwUoGRN/7R5mag=; b=jEcZFDzjoYX8mN8EiNeyTie0Elt29dW9Ihzo8ZHdoAfYeZV81eLvCm6nBa0Ii5uzDJ uoYrf3SY1NydDKwbkXZriO5ctv2C/l3LrrV9A2u2eqW3e79/kSPOJqnz/LhNWXhC0yRi 7bzQLlpV+Sf7+EXbp/LWoqz2xbaCKRWX20BqkaA2m4nG81LhT+mbMDOlsb7JZHZuRJtg ggkeMIHINy1Id+7eWJtsrW3N2eISbEdoYphvfkUNjlF+KfibNMHQSnZd6loorpECw4an kXU1TzZ8wm9y1/9MEEwCMkPzKphFihBMdla4fHtozJinKGDCKe3kyCa5O9u9f4g+PUef oJ5g==
X-Gm-Message-State: AGi0PuZpG5SJ8047ywJzZ3j1QB/Q9E6a2bCD4dazrN0gTfPsELtuK/pS r6JLybPWlOQYmlQDHsukTP6RXA==
X-Google-Smtp-Source: APiQypLW2ngH3ykdsqL6r61Ztyf9iqOYqo6cnHcLsaiXRHfOyBwcdpyiy2Ti9uJU6vGUxM+zlyy0Xw==
X-Received: by 2002:aa7:9683:: with SMTP id f3mr11887537pfk.278.1587759846169;  Fri, 24 Apr 2020 13:24:06 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id f2sm5275709pju.32.2020.04.24.13.24.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2020 13:24:05 -0700 (PDT)
From: Vittorio Bertocci 
To: Takahiko Kawasaki , oauth 
CC: Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AVF4SE4wBVS7+VylVCk8I90u7EWFcDA3MjMxh8DbSQCAAIJBAIABROAw
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 24 Apr 2020 20:24:04 +0000
Message-ID: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>      
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: multipart/alternative; boundary="_000_MWHPR19MB15012F3B9748A9CB00DE46C4AED00MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 24 Apr 2020 20:24:12 -0000

--_000_MWHPR19MB15012F3B9748A9CB00DE46C4AED00MWHPR19MB1501namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGFrYWhpcm8sDQpCZWZvcmUgSSBhY2tub3dsZWRnZSB5b3VyIGNvbW1lbnRzLCBJIHdvdWxkIGxp
a2UgdG8gY2xhcmlmeSBzb21lIGltcG9ydGFudCBwb2ludHMuDQpZb3VyIGZpcnN0IGVtYWlsLCBh
bmQgdmFyaW91cyB0d2VldHMgeW91IHB1Ymxpc2hlZCBjb250ZXh0dWFsbHkgKGh0dHBzOi8vdHdp
dHRlci5jb20vZGFydXRrL3N0YXR1cy8xMjUzMzc1MDM5NjgxODg0MTYwKSwgc3VnZ2VzdCB0aGF0
IHdpdGggbXkgd29yayBvbiB0aGUgc3BlYyBJIGFtIGRyaXZpbmcgc29tZSBoaWRkZW4gYWdlbmRh
IGZvciBteSBjb21wYW55LCBhbmQgeW91IGFyZSBleHBvc2luZyB0aGlzIHRoYW5rcyB0byBzb21l
IGZpbmRpbmdzIHlvdSB1bmNvdmVyZWQtIGFuZCB0aGF0IHRoZSBXRyBzb21laG93IG1pc3NlZC4N
ClRoaXMgaXMgb2YgY291cnNlIG5vbnNlbnNlLCBpbnN1bHRpbmcgdG8gbXkgb3duIHByb2Zlc3Np
b25hbCBpbnRlZ3JpdHkgYW5kIHRvIHRoZSBpbnRlbGxpZ2VuY2Ugb2YgdGhlIGNoYWlycywgd29y
a2luZyBncm91cCBhbmQgZXZlcnlvbmUgd2hvIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lv
bi4gSSBpbmNsdWRlIHRoZSB0d2VldHMgaW4gdGhlIGRpc2N1c3Npb24gYmVjYXVzZSB5b3UgaW5j
bHVkZWQgaW4gdGhlbSBhIGxpbmsgdG8gdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlcywgaGVuY2Ug
aW52b2x2aW5nIHRoZSBXRyBpbiB0aGUgcHJvY2Vzcy4NCg0KU29tZSBiYXNpYyBmYWN0czoNCg0K
ICAqICAgVGhlIHByb2ZpbGUgYXMgaXQgZXhpc3RzIHRvZGF5IGRvZXMgTk9UIHdvcmsgb3V0IG9m
IHRoZSBib3ggd2l0aCBBdXRoMCwgdGhlcmUgYXJlIHNldmVyYWwgdGhpbmdzIHRoYXQgd291bGQg
bmVlZCB0byBjaGFuZ2UgaW4gdGhlIHByb2R1Y3QgZm9yIHRoYXQgdG8gaGFwcGVuLSBpbmNsdWRp
bmcgYWRkaW5nIHN1cHBvcnQgZm9yIHJlc291cmNlIGluZGljYXRvcnMgd2hpY2ggaXMgY3VycmVu
dGx5IG1pc3NpbmcNCiAgKiAgIFRoZSBsYXlvdXQgb2YgdGhlIEF1dGgwIHRva2VuIGlzIGNlcnRh
aW5seSBub3QgYSBzZWNyZXQsIGdpdmVuIHRoYXQgaXQgd2FzIHByZXNlbnRlZCBhbG9uZ3NpZGUg
YWxsIHRoZSBvdGhlciB0b2tlbnMgb2J0YWluZWQgZnJvbSBvdGhlciB2ZW5kb3JzIGF0IHRoZSBP
U1cyMDE5IGluIE1hcmNoLCBpbiB0aGUgaW5pdGlhbCBkcmFmdCBwaXRjaCBhdCBJRVRGMTA0IGFz
IHJlY29yZGVkIGluIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0
ZXJpYWxzL3NsaWRlcy0xMDQtb2F1dGgtc2Vzc2Etand0LXByb2ZpbGUtZm9yLWFjY2Vzcy10b2tl
bi0wMCwgaW4gdGhlIGZpcnN0IGRpc2N1c3Npb24gYXQgSUVURjEwNSBhcyBzaG93biBpbiBodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA1L21hdGVyaWFscy9zbGlkZXMtMTA1
LW9hdXRoLXNlc3NhLWpzb24td2ViLXRva2VuLWp3dC1wcm9maWxlLWZvci1vYXV0aC0yMC1hY2Nl
c3MtdG9rZW5zLTAyLTAwLiBUaGUgdXNlIG9mIHJlc291cmNlIGluZGljYXRvcnMgZm9yIGNsaWVu
dCBjcmVkIGZsb3dzIGlzIGNlcnRhaW5seSBub3QgYSBkYXJrIHBsb3kgdG8gc211Z2dsZSB0aGUg
QXV0aDAgd2F5LCBpbiBmYWN0IGl04oCZcyBpbmZvcm1lZCBtb3JlIGJ5IG15IHdvcmsgb24gQXp1
cmUgQUQtIHdoZXJlIEkgZm91bmQgdGhlIHRyYW5zaXRpb24gZnJvbSBwc2V1ZG8gcmVzb3VyY2Ug
aW5kaWNhdG9ycyB0byBzY29wZXMgdG8gYmUgcmlkZGxlZCBieSBjaGFsbGVuZ2VzLiBPbmNlIGFn
YWluLCBhbGwgZGlzY3Vzc2lvbnMgd2VyZSBtYWRlIGluIGZ1bGwgdHJhbnNwYXJlbmN5Lg0KICAq
ICAgVGhlIGNvbmNlcm5zIGFib3V0IHN5bW1ldHJpYyBhbGdvcml0aG1zIGJlaW5nIGFsbG93ZWQs
IHdoaWNoIHlvdSBhcmUgb2RkbHkgYnJpbmdpbmcgdXAgaW4gYSB0d2VldCByYXRoZXIgdGhhbiBv
biB0aGUgbGlzdCwgYXJlIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBkaXNjdXNzaW9uOiBwZW9wbGUg
aW4gdGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBhc2tlZCBmb3Igc3ltbWV0cmljIHRvIGJl
IGFuIG9wdGlvbiBhbmQgZXZlbiB0byByZWxheCB0aGUgY3VycmVudCBsYW5ndWFnZSB0byBiZSBt
b3JlIHBlcm1pc3NpdmUsIHdoaWNoIEkgZ2VudGx5IHB1c2hlZCBiYWNrIGFnYWluc3QuIEFnYWlu
LCBub3QgYW4gb2JzY3VyZSBwbG95Lg0KDQpJIGFtIHNhZGRlbmVkIHRoYXQgeW91IGNob3NlIHRv
IG1ha2UgdGhvc2Ugc3RhdGVtZW50cyBvbiB0d2l0dGVyLiBUaGVyZSB3YXMgbm90aGluZyBmb3Ig
eW91IHRvIGRpc2NvdmVyLCBldmVyeXRoaW5nIHdhcyBhbHJlYWR5IG91dCBpbiB0aGUgb3Blbi4N
CllvdSBtaWdodCB3YW50IHRvIGNvbnNpZGVyIHJldHJhY3RpbmcgeW91ciBhY2N1c2F0aW9ucy4g
SSBhbSBub3Qgd29ycmllZCBhYm91dCBteXNlbGYsIG15IGNvbnNjaWVuY2UgaXMgcGVyZmVjdGx5
IGNsZWFuIGFuZCB0aGUgSUVURiBwcm9jZXNzIHJlY29yZHMgYmFjayBtZSB1cCwgYnV0IGJ5IHN1
Z2dlc3RpbmcgbGFjayBvZiB0cmFuc3BhcmVuY3kgeW91IGFyZSB1bmZhaXJseSBwb3J0cmF5aW5n
IHRoZSBJRVRGLCBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyBhbmQgdGhlIHBlb3BsZSB3aG8gZG8g
dGhlaXIgYmVzdCB0byBjaGVjayBhdCB0aGUgZG9vciB0aGVpciBhZmZpbGlhdGlvbnMgYW5kIGNv
bnRyaWJ1dGUgdGhlaXIgdGltZSBhbmQgZXhwZXJ0aXNlIGZvciB0aGUgYmVuZWZpdCBvZiB0aGUg
aW5kdXN0cnkgYXMgYSB3aG9sZS4NCg0KSSBhbSBhZGRpbmcgdGhlIHR3ZWV0cyBoZXJlIGZvciBy
ZWZlcmVuY2UsIHRvZ2V0aGVyIHdpdGggdGhlIHRyYW5zbGF0aW9uIFR3aXR0ZXIgcHJvdmlkZWQu
DQoNClRha2FAQXV0aGxldGUsIEJhYVMgZm9yIE9BdXRoIDIuMCAmIE9wZW5JRCBDb25uZWN0DQpA
ZGFydXRrDQrjgoLjgZfjgoTjgajmgJ3jgaPjgaboqr/jgbnjgabjgb/jgZ/jgonjgIFBdXRoMO+8
iOOCueODmuODg+OCr+ODquODvOODieOBruaJgOWxnuS8gealre+8ieOBriBjbGllbnRfY3JlZGVu
dGlhbHMg44OV44Ot44O844Gu5a6f6KOF44GvIGF1ZGllbmNl77yIUkZDIDg3MDcg44GuIHJlc291
cmNlIOebuOW9k++8ieOBjOW/hemgiOOBp+OAgeeUn+aIkOOBmeOCiyBKV1Qg44Ki44Kv44K744K5
44OI44O844Kv44Oz44GuIHN1YiDjgavjgq/jg6njgqTjgqLjg7Pjg4ggSUQg44KS5Z+L44KB6L68
44KA44CCSldUIOOCouOCr+OCu+OCueODiOODvOOCr+ODs+S7leanmOODieODqeODleODiOOBjOat
quOCk+OBp+OBhOOCi+OBruOBr+OBk+OCjOOBjOeQhueUseOBoOOCjeOBhuOAgg0KU3VkZGVubHks
IEkgc2VhcmNoZWQgYW5kIHRob3VnaHQsIGltcGxlbWVudGF0aW9uIG9mIGNsaWVudF9jcmVkZW50
aWFscyBmbG93IG9mIEF1dGgwIChjb21wYW55IG9mIFNwZWMgTGVhZCkgcmVxdWlyZXMgYXVkaWVu
Y2UgKGVxdWl2YWxlbnQgdG8gcmVzb3VyY2Ugb2YgUkZDIDg3MDcpLCBhbmQgZW1iZWQgY2xpZW50
IElEIGluIHN1YiBvZiBnZW5lcmF0ZWQgSldUIGFjY2VzcyB0b2tlbi4gVGhpcyBpcyBwcm9iYWJs
eSB0aGUgcmVhc29uIHdoeSB0aGUgSldUIGFjY2VzcyB0b2tlbiBzcGVjaWZpY2F0aW9uIGRyYWZ0
IGlzIGRpc3RvcnRlZC4NCg0K5YWD44CFIEF1dGgwIOOBruePvuWun+ijheOCkualreeVjOOBq+iq
jeOCgeOBleOBm+OCi+OBn+OCgeOBqyBKV1Qg44Ki44Kv44K744K544OI44O844Kv44Oz5qiZ5rqW
5LuV5qeY562W5a6a5L2c5qWt44GM6ZaL5aeL44GV44KM44Gf44Go5ZmC44Gn44Gv6IGe44GE44Gm
44GE44Gf44GM44CB5a6f6Zqb44Gr44Gd44GG44Gg44Gj44Gf44GL44CC5oqA6KGT55qE44Gr5LiN
6Ieq54S244Gq54K544GM5aSa44GE44GX6KOP5LqL5oOF44GM44Gv44Gj44GN44KK44GX44Gf5LuK
44Go44Gq44Gj44Gm44Gv6buZ44Gj44Gm44GE44KL6Kiz44Gr44KC44GE44GL44Gq44GE44Gu44Gn
44CB44Oh44O844Oq44Oz44Kw44Oq44K544OI44Gn5oSP6KaL44KS6L+w44G544Gf44CCDQoNCmh0
dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvSnkxZnBhcjZMS25OWF96
cG9UN19mcEN6QlNnLw0KSSd2ZSBoZWFyZCBydW1vcnMgdGhhdCB0aGUgSldUIEFjY2VzcyBUb2tl
biBzdGFuZGFyZCBzcGVjaWZpY2F0aW9uIHdvcmsgd2FzIHN0YXJ0ZWQgdG8gZ2V0IHRoZSBpbmR1
c3RyeSB0byBhY2NlcHQgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgQXV0aDAsIGJ1dCB3
YXMgdGhhdCByZWFsbHkgdGhlIGNhc2U/IFNpbmNlIHRoZXJlIGFyZSBtYW55IHRlY2huaWNhbCB1
bm5hdHVyYWwgcG9pbnRzIGFuZCBpdCBpcyBpbXBvc3NpYmxlIHRvIGtlZXAgc2lsZW50IG5vdyB0
aGF0IHRoZSBjaXJjdW1zdGFuY2VzIGFyZSBjbGVhciwgSSBtYWRlIGFuIG9waW5pb24gb24gdGhl
IG1haWxpbmcgbGlzdC4NCg0K44Gk44GE44Gn44Gr6KiA44Gj44Gm44GK44GP44Go44CBQXV0aDAg
44GM55Sf5oiQ44GZ44KLIEpXVCDjgqLjgq/jgrvjgrnjg4jjg7zjgq/jg7Pjga7nvbLlkI3jgqLj
g6vjgrTjg6rjgrrjg6DjgajjgZfjgabpgbjmip7jgafjgY3jgovjga7jga/jgIFIUzI1NiDjgagg
UlMyNTYg44Gu44G/44Gu44KI44GG44Gg44CCSFMyNTYg44Gv5a++56ew6Y2157O744Ki44Or44K0
44Oq44K644Og44CC5LiA5pa544GuIFJTMjU2IOOBr+mdnuWvvuensOmNteezu+OCouODq+OCtOOD
quOCuuODoOOBoOOBjOOAgeOCu+OCreODpeODquODhuOCo+ODvOS4iuOBrueQhueUseOBpyBGaW5h
bmNpYWwtZ3JhZGUgQVBJIFBhcnQgMiDjgafjga/kvb/nlKjnpoHmraLjgajjgZXjgozjgabjgYTj
govjgIINCkluY2lkZW50YWxseSwgaXQgc2VlbXMgdGhhdCBvbmx5IEhTMjU2IGFuZCBSUzI1NiBj
YW4gYmUgc2VsZWN0ZWQgYXMgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gZm9yIHRoZSBKV1QgYWNj
ZXNzIHRva2VuIGdlbmVyYXRlZCBieSBBdXRoMC4gSFMyNTYgaXMgYSBzeW1tZXRyaWMga2V5IGFs
Z29yaXRobS4gT24gdGhlIG90aGVyIGhhbmQsIFJTMjU2IGlzIGFuIGFzeW1tZXRyaWMga2V5IGFs
Z29yaXRobSwgYnV0IGZvciBzZWN1cml0eSByZWFzb25zLCBpdCBpcyBwcm9oaWJpdGVkIGluIEZp
bmFuY2lhbC1ncmFkZSBBUEkgUGFydCAyLg0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVGFrYWhpa28gS2F3YXNha2kgPHRha2FAYXV0aGxldGUu
Y29tPg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDIwIGF0IDE4OjAxDQpUbzogb2F1dGgg
PG9hdXRoQGlldGYub3JnPg0KQ2M6IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2Nj
aT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNl
Y29uZCBXR0xDIG9uICJKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAg
QWNjZXNzIFRva2VucyINCg0KSSBhcG9sb2dpemUgaWYgbXkgcHJldmlvdXMgcG9zdCBoYXMgbWFk
ZSB5b3UgYWxsIGhlcmUgZmVlbCB1bnBsZWFzYW50LCBlc3BlY2lhbGx5IEknbSBzb3JyeSBmb3Ig
dGhlIGF1dGhvciwgdGhlIGNoYWlycywgYW5kIHBlb3BsZSB3aG8gZGlyZWN0bHkgam9pbmVkIHRo
ZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBzcGVjLiBJIGNvdWxkIGhhdmUgZXhwcmVzc2VkIG15IGRp
c2FncmVlbWVudCBvbiB0aGUgcmVxdWlyZW1lbnRzIGZvciAiYXVkIiBhbmQgInN1YiIgaW4gYW5v
dGhlciBkaWZmZXJlbnQgd2F5LiBGb3Igc29mdHdhcmUgc3BlY2lmaWNhdGlvbnMgYW5kIGFyY2hp
dGVjdHVyZXMsIEknbSBsaWFibGUgdG8gZ2V0IGV4Y2l0ZWQgYW5kIGFnZ3Jlc3NpdmUuIFBsZWFz
ZSBmb3JnaXZlIG1lLg0KDQpSZWdhcmRpbmcgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuICJhdWQi
IGFuZCAic2NvcGUiLCB0aGUgYXNzdW1wdGlvbiBpbiB0aGUgZHJhZnQgaXMgbm90IG5lY2Vzc2Fy
aWx5IGFwcGxpY2FibGUgdG8gYWxsIHBvc3NpYmxlIHVzZSBjYXNlcy4gRm9yIGV4YW1wbGUsIG11
bHRpcGxlIHJlc291cmNlcyBtYXkgc2hhcmUgdGhlIHNhbWUgc2NvcGVzLiBXaGF0IGlmIGJvdGgg
Ii9yZXNvdXJjZTEiIGFuZCAiL3Jlc291cmNlMiIgcmVjb2duaXplICJnZXQiIHNjb3BlIGFuZCAi
dXBkYXRlIiBzY29wZT8gSW4gdGhpcyBjYXNlLCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgdG8gZGV0
ZXJtaW5lIHRoZSBkZWZhdWx0IHJlc291cmNlIGluZGljYXRvciBmb3IgImF1ZCIgZnJvbSB0aGUg
c2NvcGVzLiBJdCBpcyBhbHNvIGltcG9zc2libGUgdG8gbWFwIHNjb3BlcyB0byByZXNvdXJjZXMg
YW5kIHZpY2UgdmVyc2EuIFRoZSBhc3N1bXB0aW9uIGluIHRoZSBjdXJyZW50IGRyYWZ0IGlzIHRv
byBuYXJyb3cgdG8gYmUgaW5jbHVkZWQgaW4gYSBzdGFuZGFyZC4uIElmIHRoZSBjdXJyZW50IGRl
c2NyaXB0aW9uIGNvbnRpbnVlcyB0byBleGlzdCwgaXQgd2lsbCBpbXBvc2UgYmlnIHJlc3RyaWN0
aW9ucyBvbiB0aGUgZGVzaWduIG9mIHNjb3BlcyBhbmQgcmVzb3VyY2VzLg0KDQpJZiB5b3Ugc3Rp
bGwgdGhpbmsgdGhlICJhdWQiIGNsYWltIHNob3VsZCBhbHdheXMgZXhpc3QsIHRoZW4gdGhlIGF1
dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kL29yIHRoZSB0b2tlbiBlbmRwb2ludCAoYW5kL29yIHRo
ZSBiYWNrY2hhbm5lbCBhdXRoZW50aWNhdGlvbiBlbmRwb2ludCBhbmQvb3IgdGhlIGRldmljZSBh
dXRob3JpemF0aW9uIGVuZHBvaW50KSBvZiB5b3VyIHN5c3RlbSBjYW4gcmVxdWlyZSB0aGUgInJl
c291cmNlIiByZXF1ZXN0IHBhcmFtZXRlciBhcyBtYW5kYXRvcnkuIFdlIGRvbid0IGhhdmUgdG8g
cHV0IHJ1bGVzIHRvIGRldGVybWluZSB0aGUgZGVmYXVsdCAiYXVkIiB2YWx1ZSBpbnRvIHRoZSBz
cGVjIGFib3V0IEpXVCBhY2Nlc3MgdG9rZW5zLiBUaGUgInJlc291cmNlIiBwYXJhbWV0ZXIgZGVm
aW5lZCBpbiBSRkMgODcwNyBjYW4gd29yayByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGZvcm1h
dCBvZiBhY2Nlc3MgdG9rZW5zIGlzIEpXVCBvciBub3QuIFRoZXJlZm9yZSwgaXQgaXMgbm90IGFw
cHJvcHJpYXRlIHRvIGRpc2N1c3MgdGhlIG5lY2Vzc2l0eSBvZiB0aGUgImF1ZCIgY2xhaW0gb25s
eSBpbiB0aGUgY29udGV4dCBvZiAiSldUIiBhY2Nlc3MgdG9rZW5zLg0KDQpSZWdhcmRpbmcgdGhl
ICJzdWIiIGNsYWltLCBzZXR0aW5nIHRoZSBjbGllbnQgSUQgdGhlcmUsIHJhdGhlciwgd2lsbCBj
b25mdXNlIHJlc291cmNlIHNlcnZlcnMuIElmIHRoZSAic3ViIiBjbGFpbSBpcyBzZXQgZXZlbiBp
biB0aGUgY2FzZSBvZiB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGZsb3csIHJlc291cmNlIHNlcnZl
cnMgY2Fubm90IGp1ZGdlIHdoZXRoZXIgdGhlICJzdWIiIGNsYWltIHJlcHJlc2VudHMgZWl0aGVy
IHRoZSBzdWJqZWN0IG9mIHRoZSByZXNvdXJjZSBvd25lciBvciB0aGUgY2xpZW50IElELiBPbiB0
aGUgb3RoZXIgaGFuZCwgaWYgdGhlICJzdWIiIGNsYWltIGlzIG51bGwgb3IgYWJzZW50IGluIHRo
ZSBjYXNlIG9mIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdywgcmVzb3VyY2Ugc2VydmVycyBj
YW4gYWx3YXlzIGhhbmRsZSB0aGUgdmFsdWUgb2YgdGhlICJzdWIiIGNsYWltIGFzIHRoZSBzdWJq
ZWN0IG9mIHRoZSByZXNvdXJjZSBvd25lci4gRm9yIHJlc291cmNlIHNlcnZlcnMsIHRoaXMgbG9n
aWMgaXMgZWFzaWVyLiBTZXR0aW5nIHRoZSAic3ViIiBjbGFpbSBpbiBldmVyeSBjYXNlIHRvIG1h
a2UgcmVzb3VyY2Ugc2VydmVyIGltcGxlbWVudGF0aW9ucyBzaW1wbGVyIGlzIG5vdCBjb252aW5j
aW5nLg0KDQpCZXN0IFJlZ2FyZHMsDQpUYWthDQoNCk9uIEZyaSwgQXByIDI0LCAyMDIwIGF0IDI6
MTUgQU0gVGFrYWhpa28gS2F3YXNha2kgPHRha2FAYXV0aGxldGUuY29tPG1haWx0bzp0YWthQGF1
dGhsZXRlLmNvbT4+IHdyb3RlOg0KRmlyc3QsIHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gZmFpciwg
SSB0aGluayBJIHNob3VsZCBzaGFyZSB3aGF0IEkgb2JzZXJ2ZWQgdG9kYXkuIEF1dGgwJ3MgY2xp
ZW50X2NyZWRlbnRpYWxzIGZsb3cgcmVxdWlyZXMgYW4gImF1ZGllbmNlIiBwYXJhbWV0ZXIsIHdo
aWNoIGlzIGVxdWl2YWxlbnQgdG8gdGhlICJyZXNvdXJjZSIgcGFyYW1ldGVyIGRlZmluZWQgaW4g
UkZDIDg3MDcsIGFuZCBlbWJlZHMgdGhlIGNsaWVudCBJRCBpbiB0aGUgZ2VuZXJhdGVkIEpXVCBh
Y2Nlc3MgdG9rZW4gYXMgdGhlIHZhbHVlIG9mIHRoZSAic3ViIiBjbGFpbS4NCg0KTXkgb3Bpbmlv
biBhcyBhIHNvZnR3YXJlIGVuZ2luZWVyIGlzIGFzIGZvbGxvd3MuDQoNClthdWRdDQpUaGUgImF1
ZCIgY2xhaW0gc2hvdWxkIGJlIG51bGwgb3IgYWJzZW50IHdoZW4gdGhlICJyZXNvdXJjZSIgcGFy
YW1ldGVycyBhcmUgbm90IGdpdmVuIGluIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gSXQgaXMg
bm90IGdvb2QgdG8gaW50cm9kdWNlIGluZmxleGlibGUgcnVsZXMgdG8gZGV0ZXJtaW5lIHRoZSBk
ZWZhdWx0IHZhbHVlIGZvciB0aGUgImF1ZCIgY2xhaW0gYmFzZWQgb24gdGhlICJzY29wZSIgcGFy
YW1ldGVyLg0KDQpbc3ViXQ0KVGhlICJzdWIiIGNsYWltIHNob3VsZCBiZSBudWxsIG9yIGFic2Vu
dCB3aGVuIGEgcmVzb3VyY2Ugb3duZXIgaXMgbm90IGludm9sdmVkIGluIGFuIGF1dGhvcml6YXRp
b24gcmVxdWVzdC4gVG8gYmUgY29uY3JldGUsIHRoZSAic3ViIiBjbGFpbSBzaG91bGQgYmUgbnVs
bCBvciBhYnNlbnQgaW4gdGhlIGNsaWVudCBjcmVkZW50aWFscyBmbG93LiBUaGUgc3BlYyBkcmFm
dCBzYXlzIGluICI1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgYXMgZm9sbG93cy4NCg0KLSAt
IC0gLSAtIC0gLSAtIC0gLQ0KQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZCBwcmV2ZW50IHNj
ZW5hcmlvcyB3aGVyZSBjbGllbnRzIGNhbiBhZmZlY3QgdGhlIHZhbHVlIG9mIHRoZSBzdWIgY2xh
aW0gaW4gd2F5cyB0aGF0IGNvdWxkIGNvbmZ1c2UgcmVzb3VyY2Ugc2VydmVycy4gIEZvciBleGFt
cGxlOiBpZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZWxlY3RzIHRvIHVzZSB0aGUgY2xpZW50
X2lkIGFzIHRoZSBzdWIgdmFsdWUgZm9yIGFjY2VzcyB0b2tlbnMgaXNzdWVkIGNsaWVudCBjcmVk
ZW50aWFscyBncmFudCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCBwcmV2ZW50IGNs
aWVudHMgdG8gcmVnaXN0ZXIgYW4gYXJiaXRyYXJ5IGNsaWVudF9pZCB2YWx1ZSwgYXMgdGhpcyB3
b3VsZCBhbGxvdyBtYWxpY2lvdXMgY2xpZW50cyB0byBzZWxlY3QgdGhlIHN1YiBvZiBhIGhpZ2gg
cHJpdmlsZWdlIHJlc291cmNlIG93bmVyIGFuZCBjb25mdXNlIGFueSBhdXRob3JpemF0aW9uIGxv
Z2ljIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmVseWluZyBvbiB0aGUgc3ViIHZhbHVlLiAgRm9y
IG1vcmUgZGV0YWlscyBwbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA0LjEzIG9mIFtPQXV0aDIuU2Vj
dXJpdHkuQmVzdFByYWN0aWNlc10uDQoNClRvIHByZXZlbnRpbmcgY3Jvc3MtSldUIGNvbmZ1c2lv
biwgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgdXNlIGEgZGlzdGluY3QgaWRlbnRpZmllciBh
cyAiYXVkIiBjbGFpbSB2YWx1ZSB0byB1bmlxdWVseSBpZGVudGlmeSBhY2Nlc3MgdG9rZW5zIGlz
c3VlZCBieSB0aGUgc2FtZSBpc3N1ZXIgZm9yIGRpc3RpbmN0IHJlc291cmNlcy4NCi0gLSAtIC0g
LSAtIC0gLSAtIC0NCg0KSG93ZXZlciwgdGhlIGF0dGFjayB2ZWN0b3IgaXMgYnJvdWdodCBhYm91
dCBtZXJlbHkgYnkgaW50cm9kdWNpbmcgdGhlIGZvbGxvd2luZyBydWxlIGRlZmluZWQgaW4gIjIu
Mi4gRGF0YSBTdHJ1Y3R1cmUiLg0KDQotIC0gLSAtIC0gLSAtIC0gLSAtDQpJbiBjYXNlIG9mIGFj
Y2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hlcmUgbm8gcmVzb3VyY2Ugb3du
ZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCwgdGhl
IHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byBhbiBpZGVudGlmaWVyIHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciB1c2VzIHRvIGluZGljYXRlIHRoZSBjbGllbnQgYXBwbGljYXRpb24u
DQotIC0gLSAtIC0gLSAtIC0gLSAtDQoNCklmIHRoZSBydWxlIGlzIG5vdCBpbnRyb2R1Y2VkLCB0
aGUgYXR0YWNrIHZlY3RvciBkaXNhcHBlYXJzIGFuZCB0aGUgImF1ZCIgY2xhaW0gZG9lc24ndCBo
YXZlIHRvIGJlIG1hbmRhdG9yeS4NCg0KRmluYWxseSwgdG8gbWFrZSB0aGUgZGlzY3Vzc2lvbiBm
YWlyLCBJIHNob3VsZCBhbHNvIG1lbnRpb24gdGhhdCBJIG15c2VsZiBpcyBhIGNvLWZvdW5kZXIg
b2YgQXV0aGxldGUsIEluYy4gdGhhdCBwcm92aWRlcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiBPQXV0
aCBhbmQgT3BlbklEIENvbm5lY3QuIE15IHRob3VnaHRzIGFib3V0IGltcGxlbWVudGF0aW9ucyBv
ZiBhY2Nlc3MgdG9rZW5zIGFyZSBwdWJsaWNseSBkZXNjcmliZWQgaGVyZToNCg0KT0F1dGggQWNj
ZXNzIFRva2VuIEltcGxlbWVudGF0aW9uDQpodHRwczovL21lZGl1bS5jb20vQGRhcnV0ay9vYXV0
aC1hY2Nlc3MtdG9rZW4taW1wbGVtZW50YXRpb24tMzBjMmU4YjkwZmYwDQoNCkJlc3QgUmVnYXJk
cywNClRha2FoaWtvIEthd2FzYWtpDQpBdXRobGV0ZSwgSW5jLg0KDQpPbiBXZWQsIEFwciAyMiwg
MjAyMCBhdCA0OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1
dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+
PiB3cm90ZToNCk91Y2ghIFNvcnJ5IPCfmIogZml4ZWQNCg0KRnJvbTogRG9taW5pY2sgQmFpZXIg
PGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5j
b20+Pg0KRGF0ZTogVHVlc2RheSwgQXByaWwgMjEsIDIwMjAgYXQgMTA6MjMNClRvOiBvYXV0aCA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4sIFJpZmFhdCBTaGVraC1ZdXNl
ZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+Piwg
Vml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0
dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlY29u
ZCBXR0xDIG9uICJKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNj
ZXNzIFRva2VucyINCg0KT2ggYW5kIHdoaWxlIHdlIGFyZSBhdCBpdCAtIGNvdWxkIHlvdSBhbHNv
IGZpeCB0aGUgdHlwbyBpbiBteSBuYW1lPyBUaGFua3MgOykNCg0K4oCU4oCU4oCUDQpEb21pbmlj
ayBCYWllcg0KDQoNCk9uIDIxLiBBcHJpbCAyMDIwIGF0IDA5OjQzOjQ5LCBWaXR0b3JpbyBCZXJ0
b2NjaSAodml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2Nj
aUBhdXRoMC5jb20+KSB3cm90ZToNClRoaXMgaXMgYSBncmVhdCBwb2ludC4gSW4gbXkgaGVhZCBJ
IGp1c3QgY29uc2lkZXJlZCB0aGUgT0lEQyBzZW1hbnRpYyBhbmQgdGhvdWdodCBvbmx5IG9mIGhp
Z2hsaWdodGluZyB0aGUgYXBwIGlkZW50aXR5IGNhc2UsIGJ1dCB5b3UgYXJlIGFic29sdXRlbHkg
cmlnaHQgdGhhdCBub3QgbWVudGlvbmluZyB0aGUgdXNlciBjYXNlIGF0IGFsbCBpcyBjb25mdXNp
bmcuIEkgYWRkZWQgdGhlIGxhbmd1YWdlIHlvdSBzdWdnZXN0ZWQgYXQgdGhlIGJlZ2lubmluZyBv
ZiB0aGUgc3ViIGRlZmluaXRpb24uDQpUaGFua3MhDQoNCkZyb206IERvbWluaWNrIEJhaWVyIDxk
YmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t
Pj4NCkRhdGU6IE1vbmRheSwgQXByaWwgMjAsIDIwMjAgYXQgMjI6NTQNClRvOiBvYXV0aCA8b2F1
dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4sIFJpZmFhdCBTaGVraC1ZdXNlZiA8
cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiwgInZp
dHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAu
Y29tPiIgPHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8uYmVydG9j
Y2lAYXV0aDAuY29tPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICJK
U09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyIN
Cg0KDQpJbiBjYXNlIG9mIGFjY2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hl
cmUgbm8gcmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGNsaWVudCBjcmVk
ZW50aWFscyBncmFudCwgdGhlIHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byBhbiBp
ZGVudGlmaWVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB1c2VzIHRvIGluZGljYXRlIHRoZSBj
bGllbnQgYXBwbGljYXRpb24uDQoNCk1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBk
b2VzIGl0IHNheSBhbnl3aGVyZSB3aGF0IHRvIGV4cGxpY2l0bHkgZG8gaW4gdGhlIGNhc2Ugb2Yg
YW4gYWNjZXNzIHRva2VuIHdoZXJlIGEgcmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQ/DQoNClRo
ZXJl4oCZcyBzb21lIGxhbmd1YWdlIHRoYXQgc2VlbXMgdG8gaW1wbHkgdGhhdCwgZS5nLjoNCg0K
DQphcyB0aGlzIHdvdWxkIGFsbG93IG1hbGljaW91cw0KDQogICBjbGllbnRzIHRvIHNlbGVjdCB0
aGUgc3ViIG9mIGEgaGlnaCBwcml2aWxlZ2UgcmVzb3VyY2Ugb3duZXINCkkgd291bGQgaGF2ZSBl
eHBlY3RlZCB0byBzZWUgc29tZXRoaW5nIHN0cm9uZ2VyIGxpa2UgYWJvdmUganVzdCAtDQoNCg0K
SW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIGEg
cmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGF1dGhvcmlzYXRpb24gY29k
ZSBncmFudCwgdGhlIHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byB0aGUgc3ViamVj
dCBpZGVudGlmaWVyIG9mIHRoZSByZXNvdXJjZSBvd25lci4NCg0KSWYgdGhpcyBzcGVjIGlzIGFi
b3V0IGludGVyb3AsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYXQgbGVhc3QgYSByZWNvbW1lbmRh
dGlvbi4uLg0KDQoNCuKAlOKAlOKAlA0KRG9taW5pY2sgQmFpZXINCg0KDQpPbiAyMC4gQXByaWwg
MjAyMCBhdCAwOTo0ODo1MSwgdml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0
b3Jpby5iZXJ0b2NjaUBhdXRoMC4uY29tPiAodml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPG1h
aWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+KSB3cm90ZToNClRoYW5rcyBEb21pbmlj
ayBmb3IgeW91ciBjb21tZW50cyENCklubGluZQ0KDQo+IEFsbCBvdGhlciBPQXV0aCBzcGVjcyBt
YWtlIGEgdmVyeSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIHVzZXJzIGFuZCBjbGllbnQuDQpU
aGVyZeKAmXMgYSBudWFuY2Ugd29ydGggaGlnaGxpZ2h0aW5nIGhlcmU6IHN1YiAhPSB1c2VyLiBJ
biBwcmV2aW91cyBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGl0IGhhcyBiZWVuIGJyb3VnaHQg
dXAgdGhhdCB0aGUgSldUIHNwZWMgZGVmaW5lcyBzdWIgYXMgaWRlbnRpZnlpbmcgdGhlIHByaW5j
aXBhbCB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBKV1QsIGFuZCB0aGF04oCZcyBub3QgbmVj
ZXNzYXJpbHkgbGltaXRlZCB0byB1c2Vycy4NCg0KSG93ZXZlciBJIGdldCB0aGUgcG90ZW50aWFs
IGNvbmZ1c2lvbiwgYW5kIEkgYW0gaGFwcHkgdG8gYWRkIGNsYXJpZnlpbmcgbGFuZ3VhZ2UgaWYg
eW91IGhhdmUgc3BlY2lmaWMgcGFzc2FnZXMgaW4gdGhlIHNwYWNlIHlvdSBhcmUgcGFydGljdWxh
cmx5IHdvcnJpZWQgYWJvdXQ6IGhvd2V2ZXIgSSBmZWVsIHRoZSBtYXR0ZXIgaXMgYWRkcmVzc2Vk
IHVwZnJvbnQgYnkgdGhlIGxhbmd1YWdlIGluIFNlY3Rpb24gMi4yLiBpbiB0aGUgc3ViIGVudHJ5
LCDigJxJbiBjYXNlIG9mIGFjY2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hl
cmUgbm8gcmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGNsaWVudCBjcmVk
ZW50aWFscyBncmFudCwgdGhlIHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byBhbiBp
ZGVudGlmaWVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB1c2VzIHRvIGluZGljYXRlIHRoZSBj
bGllbnQgYXBwbGljYXRpb24u4oCcIGFuZCBTZWN0aW9uIDUgaGFzIGFuIGVudGlyZSBwYXJhZ3Jh
cGggZGlzY3Vzc2luZyB0aGluZ3MgdG8gd2F0Y2ggb3V0IGluIGFzc2lnbmluZyBzdWIgdmFsdWVz
IGluIHRoZSBhcHAgaWRlbnRpdHkgY2FzZS4gRmVlbCBmcmVlIHRvIHN1Z2dlc3QgYWRkaXRpb25h
bCBsYW5ndWFnZSBpZiB5b3Ugd2FudCB0byBjbGFyaWZ5IGZ1cnRoZXIuDQoNCj4gc3ViIGhhcyBh
IGRpZmZlcmVudCBzZW1hbnRpYyBoZXJlIGFzIGluIE9JREMNClRoZSAgc3BlYyByZWZlcnMgdG8g
UkZDNzUxOSBpbiB0aGUgc3ViIGRlZmluaXRpb24gaW4gMi4yLCByYXRoZXIgdGhhbiBPSURDLCB0
byBwcmVlbXB0IHRoYXQgY29uY2VybiBhbmQga2VlcCB0aGUgb3JpZ2luYWwgc3ViIHNlbWFudGlj
IGF2YWlsYWJsZS4NCg0KPiBJIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlzIHJlcXVpcmVk
Lg0KQXVkIGlzIHRoZXJlIG1vc3RseSBiZWNhdXNlIG9mIHRocmVlIHJlYXNvbnM6DQoNCuKAoiAg
ICAgICAgIE1hbnkgZXhpc3Rpbmcgc3BlY3MgcG9zdHVsYXRlIGl0cyBleGlzdGVuY2UgaW4gdGhl
IHRva2VuLiBObyBvbmUgZGVjbGFyZXMgaXQgYXMgYSBwcm9wZXIgTVVTVCAoYXBhcnQgZnJvbSB0
aGUgQkNQLCBidXQgdGhhdOKAmXMgcGFydGlhbCkgaG93ZXZlciBJIHRoaW5rIGl0cyBpbXBvcnRh
bmNlIGNvbWVzIGFjcm9zcy4uDQotQmVhcmVyIHRva2VuIHVzYWdlIFJGQzY3NTAgY2FsbHMgaXQg
b3V0IChpbiB0aHJlYXQgbWl0aWdhdGlvbikgYXMgdGhlIG1lY2hhbmlzbSB0byBwcmV2ZW50IHRv
a2VuIHJlZGlyZWN0IChhbmQgYWRkcyBzY29wZSByZXN0cmljdGlvbiBhcyBhbHNvIGltcG9ydGFu
dCwgaG93ZXZlciBoZXJlIHdlIG1ha2UgaXQgb3B0aW9uYWwgdG8gYWNvY3V0IGZvciBub24tZGVs
ZWdhdGlvbnMgc2NlbmFyaW8pLg0KLVJlc291cmNlIGluZGljYXRvcnMgUkZDODcwNyByZWZlcnMg
dG8gdGhlIHNhbWUgc2VjdGlvbiBvZiBSRkM3NTE5IGFzIG9uZSBvZiB0aGUgYXNzdW1wdGlvbnMg
dGhhdCBtdXN0IGhvbGQgdG8gcHJldmVudCBiZWFyZXIgdG9rZW5zIG1pc3VzZQ0KLUJDUDIyNSBt
YWtlcyBhdWQgbWFuZGF0b3J5IGZvciBBUyB3aGljaCBjYW4gaXNzdWUgSldUcyBmb3IgbW9yZSB0
aGFuIG9uZSBhcHANCg0K4oCiICAgICAgICAgQXBhcnQgZnJvbSBQaW5nLCBmb3Igd2hpY2ggc29t
ZSBvZiBpdHMgZXhhbXBsZXMgYXJlIHdpdGhvdXQgYXVkIChidXQgYWxzbyB3aXRob3V0IGlkZW50
aWZ5aW5nIHNjb3BlcywgZ2l2ZW4gdGhhdCB0aGUgb25lIEkgcmV0cmlldmVkIGhhZCBvbmx5IOKA
nG9wZW5pZOKAnSksIGFsbCBvZiB0aGUgc2FtcGxlIEpXVCBBVHMgSSByZWNlaXZlZCBmcm9tIHZl
bmRvcnMgYWxsIGZlYXR1cmVkIGFuIGF1ZC4gSSBrbm93IG9uZSBzaG91bG5k4oCZdCBvdmVyaW5k
ZXggb24gdGhvc2UgZXhhbXBsZXMsIGJ1dCB0b2dldGhlciB3aXRoIHRoZSBhYm92ZSBpdCBzZWVt
ZWQgdG8gcG9pbnQgdG8gc29tZXRoaW5nIHVuaXZlcnNhbGx5IHVzZWZ1bC4gT25lIHBvc3NpYmxl
IHJlYXNvbiBpcyB0aGF0IHVzZSBvZiBhIGZvcm1hdCBmb3IgdGhlIEFUIGlzIGNvcnJlbGF0ZWQg
d2l0aCB0b3BvbG9naWVzIHdoZXJlIEFTIGFuZCBSUyBhcmUgc2VwYXJhdGVkIGJ5IHNvbWUgYm91
bmRhcnkgKG5ldHdvcmssIGxvZ2ljYWwsIGJ1c2luZXNzLCBjb2RlIGZhY3RvcmluZywgZXRjKSBo
ZW5jZSBpZGVudGlmeWluZyB0aGUgcmVzb3VyY2Ugc2VlbXMgbGlrZSBhIG5hdHVyYWwgbmVlZC4g
QWdhaW4sIG5vdCBhbiBpcm9uIGNsYWQgbGF3LCBidXQgYW4gaW5kaWNhdGlvbi4NCg0K4oCiICAg
ICAgICAgQSBsb3Qgb2YgcGVvcGxlIHJlcHVycG9zZSBleGlzdGluZyBsaWJyYXJpZXMgZm9yIHRo
ZSBKV1QgQVQgY2FzZSwgYW5kIHNvbWUgcGVvcGxlIGV2ZW4gc2VuZHMgaWRfdG9rZW5zIGluIGxp
ZXUgb2YgQVRzLiBUaGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGNvbmRvbmUgYW55
IGJhZCBwcmFjdGljZXMsIGJ1dCBpbiB0aXMgcGFydGljdWxhciBjYXNlIGl0IHN1Z2dlc3RzIHRo
YXQgbG90cyBvZiBkZXZlbG9wZXJzIGFscmVhZHkgZXhwZWN0L2NhbiBoYW5kbGUgYW4gYXVkaWVu
Y2UgaW4gdGhlIEpXVCB1c2VkIHRvIGNhbGwgdGhlaXIgQVBJDQpOb25lIG9mIHRob3NlIGFyZSBh
IHNsYW0gZHVuayBhcmd1bWVudCBmb3IgbWFuZGF0b3J5LCBidXQgSSBmaW5kIHRoZW0gY29tcGVs
bGluZyBlbm91Z2ggdG8gc2ltcGxpZnkgdmFsaWRhdGlvbiBhbmQganVzdCByZXF1aXJlIGFuIGF1
ZCB0byBiZSB0aGVyZSwgYXMgb3Bwb3NlZCB0byBpbnRyb2R1Y2UgY29tcGxpY2F0aW9ucyB0aGF0
IG1ha2UgaXQgY29uZGl0aW9uYWwgdG8gdGhlIHByZXNlbmNlIG9mIHNjb3BlcyBvciBvdGhlciBk
aXNhbWJpZ3VhdGlvbi4uIE9uZSByZWFzb24gSSBmZWVsIHByZXR0eSBnb29kIGFib3V0IHRoYXQg
aXMgdGhhdCBhZGRpbmcgYSBkZWZhdWx0IGF1ZGllbmNlIGlzbuKAmXQgdmVyeSBoYXJkIGlmIGFu
eSBvZiB0aGUgYWJvdmUgYXNzdW1wdGlvbnMgZW5kIHVwIG5vdCBiZWluZyB0cnVlIGZvciBhIHBh
cnRpY3VsYXIgY2FzZQ0KDQo+IFdoYXTigJlzIHRoZSByYXRpb25hbGUgZm9yIHVzaW5nIGlhdCBp
bnN0ZWFkIG9mIG5iZi4NClRoYXTigJlzIGp1c3Qgc3RyYWlnaHQgZnJvbSBPSURDIElEX3Rva2Vu
cywgYW5kIHRoZSBjb25zaWRlcmF0aW9ucyBhYm91dCByZXB1cnBvc2luZyBleGlzdGluZyBsb2dp
Yy4gSSBzZWUgdGhlcmXigJlzIGEgdGhyZWFkIG9uIHRoaXMgc3BlY2lmaWNhbGx5LCBsZXQgbWUg
YW5zd2VyIGZ1cnRoZXIgb24gdGhhdCBicmFuY2guDQoNCj4gVGhpcyBzcGVjIGZlZWxzIHNvbWVo
b3cgaW4gYmV0d2VlbiBhIHByb2ZpbGUgYW5kIGEgQkNQDQpZb3UgYXJlIHJpZ2h0IHRoYXQgdGhp
cyBzcGVjIGF0dGVtcHRzIHRvIGdvIGJleW9uZCBqdXN0IGRlY2xhcmluZyBhIGxheW91dCwgYW5k
IEkgYWdyZWUgdGhpcyBtZWFucyB0aGF0IHRoaXMgcHJvZmlsZSB3aWxsIG5vdCBhcHBseSB0byBh
YnNvbHV0ZWx5IGV2ZXJ5b25lLiBUaGUgcmVhc29uIEkgdHJpZWQgdGhhdCByb3V0ZSAoYXQgdGhl
IGNvc3Qgb2Ygd29ya2luZyB3YXkgaGFyZGVyIGluIHRoZSBsYXN0IHllYXIgZm9yIHJlYWNoaW5n
IGNvbnNlbnN1cyB0aGFuIGlmIHdlIHdvdWxkIGhhdmUganVzdCBsaXN0ZWQgdGhlIHBvc3NpYmxl
IGNvbnRlbnQpLCBpcyB0aGF0IEkgb2Z0ZW4gb2JzZXJ2ZSBpbXBsZW1lbnRlcnMgbWFrZSBxdWVz
dGlvbmFibGUgY2hvaWNlcyBiZWNhdXNlIG9mIHRoZSBsYXJnZSBsZWV3YXkgc3BlY2lmaWNhdGlv
bnMgYWxsb3cuIE15IGhvcGUgd2FzIHRoYXQgdGhlIHNjb3BlIG9mIHRoaXMgcHJvZmlsZSB3YXMg
c21hbGwgZW5vdWdoIHRvIG1ha2UgdGhhdCBleHRyYSBsZXZlbCBvZiBndWlkYW5jZSBhY2hpZXZh
YmxlLCB3aGVyZWFzIHRyeWluZyB0byBkbyB0aGUgc2FtZSB3aXRoIGEgbGFyZ2VyIHNwZWMgd291
bGQgaGF2ZSBiZWVuIHByb2hpYml0aXZlbHkgZXhwZW5zaXZlLg0KSSBiZWxpZXZlIHRoaW5ncyB3
b3JrZWQgb3V0IHdlbGwgc28gZmFyOiB3ZSBoYWQgbG90cyBvZiBjb25zdHJ1Y3RpdmUgZGlzY3Vz
c2lvbnMsIGFuZCBJIGVuZGVkIHVwIHJlbGF4aW5nIEEgTE9UIG9mIHRoZSBjb25zdHJhaW50cyBJ
IHdhcyBvcmlnaW5hbGx5IGVudmlzaW9uaW5nLiBOb25ldGhlbGVzcywgbXkgaG9wZSBpcyB0aGF0
IHdlIGlkZW50aWZpZWQgdGhlIHJpZ2h0IHNldCBvZiBndWlkZWxpbmVzIHRoYXQgd2lsbCBoZWxw
IHBlb3BsZSBhY3R1YWxseSBpbnRlcm9wZXJhdGUgb3V0IG9mIHRoZSBib3ggZm9yIHRoZSBtb3N0
IGJhc2ljL2NvbW1vbiBzY2VuYXJpb3MsIGFzIG9wcG9zZWQgdG8gY29tcGx5aW5nIHdpdGggdGhl
IGxldHRlciBvZiB0aGUgc3BlYyBidXQgc3RpbGwgaGF2aW5nIGEgbG90IHRvIGZpZ3VyZSBvdXQg
b3V0IG9mIGJhbmQuDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERvbWluaWNrIEJhaWVyDQpT
ZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMjAgMTI6MTAgQU0NClRvOiBSaWZhYXQgU2hla2gt
WXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29t
Pj47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVj
dDogUmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gIkpTT04gV2ViIFRva2VuIChKV1QpIFBy
b2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIg0KDQpTaW5jZSB0aGlzIGlzIHRoZSBs
YXN0IGNhbGwsIEkgdGhvdWdodCBJIGJyaW5nIHVwIHNvbWUgb2YgdGhvdWdodHMgLyBjb25jZXJu
cy4gU29tZSBvZiB0aGVtIGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLg0KDQpjbGllbnRfaWQg
dnMgc3ViDQpJIGFtIHN0aWxsIG5vdCBlbnRpcmVseSBoYXBweSB3aXRoIHRoZSDigJxyZS1wdXJw
b3NpbmfigJ0gb2YgdGhlIGNsYWltIHR5cGVzIGJhc2VkIG9uIGZsb3cuDQpJZiB0aGUgaW50ZW50
aW9uIGlzLCB0aGF0IHN1YiBleHByZXNzZXMgdGhlIGVudGl0eSBhZ2FpbnN0IHdoaWNoIHRoZSBy
ZXNvdXJjZSB3aWxsIGRvIGF1dGhvcmlzYXRpb24gKGFuZCB0aGF0IG1pZ2h0IGJlIGEgY2xpZW50
IG9yIGEgdXNlcikgLSBJIGdldCBpdCAoYW5kIG1heWJlIGl0IHNob3VsZCBiZSBzdGF0ZWQgbGlr
ZSB0aGF0KSAtIGJ1dA0KdGhpcyB0aGlua2luZyByZW1pbmRzIG1lIG9mIHRoZSBvbGQgQUQgZGF5
cyB3aGVyZSB0aGVyZSB3YXMgbm8gZGlzdGluY3Rpb24gYmV0d2VlbiB1c2VyIGFuZCBzZXJ2aWNl
IGFjY291bnRzIChzb21ldGhpbmcgdGhhdCBoYXMgYmVlbiBmaXhlZCBJSVJDIGluIFdpbmRvd3Mg
U2VydmVyIDIwMTIgUjIpLg0KDQpBbGwgb3RoZXIgT0F1dGggc3BlY3MgbWFrZSBhIHZlcnkgY2xl
YXIgZGlzdGluY3Rpb24gYmV0d2VlbiB1c2VycyBhbmQgY2xpZW50Lg0KDQpGdXJ0aGVybW9yZSBp
dCBzYXlzDQoNCiJBdXRob3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIHByZXZlbnQgc2NlbmFyaW9z
IHdoZXJlIGNsaWVudHMgY2FuDQogICBhZmZlY3QgdGhlIHZhbHVlIG9mIHRoZSBzdWIgY2xhaW0g
aW4gd2F5cyB0aGF0IGNvdWxkIGNvbmZ1c2UgcmVzb3VyY2UNCiAgIHNlcnZlcnMu4oCdDQoNCklm
IHdlIGtlZXAgdGhhdCBkdWFsIHNlbWFudGljcyBvZiB0aGUgc3ViIGNsYWltIC0gaXQgbXVzdCBi
ZSBjbGVhcmx5IHN0YXRlZCwgdGhhdCBzdWJqZWN0IElEIGFuZCBjbGllbnQgSUQgYXJlIG5vdyBp
biB0aGUgc2FtZSBjb2xsaXNpb24gZG9tYWluLiBTbyB3aGVuIGFuIEFTIC8gT1AgY3JlYXRlcyB0
aGVtLCB0aGV5IG5lZWQgdG8gYmUgdW5pcXVlIGFjcm9zcyB1c2VyIGlkcyBhbmQgY2xpZW50IGlk
cy4NCg0KTWF5YmUgaXQgc2hvdWxkIGJlIGFsc28gZXhwbGljaXRseSBtZW50aW9uZWQgdGhhdCBz
dWIgaGFzIGEgZGlmZmVyZW50IHNlbWFudGljIGhlcmUgYXMgaW4gT0lEQyAtIGV2ZW4gdGhvdWdo
IGEgbWFqb3JpdHkgb2YgdGhlIHNvZnR3YXJlIGJ1aWx0IHRvZGF5IHdpbGwgdXNlIHRoZW0gdG9n
ZXRoZXIuDQoNCmF1ZGllbmNlIGNsYWltDQpJIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlz
IHJlcXVpcmVkLiBPQXV0aCBpdHNlbGYgZG9lcyBub3QgaGF2ZSBhIG5vdGlvbiBvZiBhbiBhdWRp
ZW5jZSAoaW4gdGhlIEpXVCBzZW5zZSkgLSB0aGV5IGhhdmUgc2NvcGVzICh3aGljaCBpcyB2ZXJ5
IHNpbWlsYXIpLiBCdXQgaW4gc2ltcGxlIHNjZW5hcmlvcyB3aGVyZSByZXNvdXJjZXMgZG9u4oCZ
dCBleGlzdCwgeW91J2QgbmVlZCB0byBtYWtlIHVwIGFuIGF1ZGllbmNlIGp1c3QgdG8gZnVsZmls
IHRoaXMgcmVxdWlyZW1lbnQuIEFuZCBpbiBtYW55IGNhc2UgdGhpcyB3aWxsIGJlIGVpdGhlciBz
dGF0aWMgb3IganVzdCByZXBlYXQgdGhlIHNjb3BlIHZhbHVlcy4gV2hhdOKAmXMgdGhlIHZhbHVl
IG9mIHRoYXQ/DQoNCklmIHRoZSBjb25jZXB0IG9mIHJlc291cmNlcyBhcmUgdXNlZCwgSSBhYnNv
bHV0ZWx5IGFncmVlIHRoYXQgYXVkIHNob3VsZCBiZSB1c2VkIHRvby4gQnV0IEkgd291bGRu4oCZ
dCBtYWtlIGl0IHJlcXVpcmVkLg0KDQppYXQgdnMgbmJmDQpXaGF04oCZcyB0aGUgcmF0aW9uYWxl
IGZvciB1c2luZyBpYXQgaW5zdGVhZCBvZiBuYmYuIEFyZW7igJl0IG1vc3QgSldUIGxpYnJhcmll
cyAoaW5jbHVkaW5nIGUuZy4gdGhlIC5ORVQgb25lKSBsb29raW5nIGZvciBuYmYgYnkgZGVmYXVs
dD8NCg0KR2VuZXJhbA0KVGhpcyBzcGVjIGZlZWxzIHNvbWVob3cgaW4gYmV0d2VlbiBhIHByb2Zp
bGUgYW5kIGEgQkNQLiBPbiBvbmUgaGFuZCB5b3UgZGVmaW5lIHNvbWUgY2xhaW1zIGFuZCB0aGVp
ciBzZW1hbnRpY3MgKGdvb2QpIC0gb24gdGhlIG90aGVyIGhhbmQgdGhlcmUgaXMgc29tZSBwcmVz
Y3JpcHRpdmUgZ3VpZGFuY2UgYW5kIG1heWJlIG92ZXItc3BlY2lmaWNhdGlvbi4gTXkgY29uY2Vy
biBpcywgdGhhdCBpbiB0aGUgZW5kIG5vLW9uZSB3aWxsIGZ1bGx5IGNvbXBseSB3aXRoIGl0LCBi
ZWNhdXNlIGl0IGRvZXNu4oCZdCB3b3JrIG9uZSB3YXkgb3IgdGhlIG90aGVyIGZvciB0aGVtLg0K
DQpJIGtub3cgd2UganVzdCB3ZW50IHRob3VnaCB0aGUgZGlzY3Vzc2lvbiB0byBtYWtlIGNlcnRh
aW4gY2xhaW1zIHJlcXVpcmVkIGFzIG9wcG9zZWQgdG8gb3B0aW9uYWwgLSBidXQgbWF5YmUgbGVz
cyBpcyBtb3JlLg0KDQpUYmggLSB0aGUgbW9zdCB2YWx1YWJsZSBwYXJ0IG9mIHRoZSBkb2MgdG8g
bWUgaXMgdGhlIGRlZmluaXRpb24gb2YgdGhlIOKAnGF0K2p3dOKAnSB0eXAuIEZvciB0aGUgcmVz
dCBJ4oCZZCByYXRoZXIgbGlrZSB0byBzZWUganVzdCBzb21lIHN0YW5kYXJkIGNsYWltcyBhbmQg
SUYgdGhleSBhcmUgdXNlZCwgd2hpY2ggc2VtYW50aWNzIHRoZXkgaGF2ZS4NCg0KY2hlZXJzDQri
gJTigJTigJQNCkRvbWluaWNrIEJhaWVyDQoNCg0KT24gMTUuIEFwcmlsIDIwMjAgYXQgMjA6NTk6
MzEsIFJpZmFhdCBTaGVraC1ZdXNlZiAocmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZh
YXQuaWV0ZkBnbWFpbC5jb20+KSB3cm90ZToNCkhpIGFsbCwNCg0KVGhpcyBpcyBhIHNlY29uZCB3
b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgIkpTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUg
Zm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIi4NCg0KSGVyZSBpcyB0aGUgZG9jdW1lbnQ6DQpo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4t
and0LTA2DQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIE9BdXRoIG1haWxpbmcg
bGlzdCBieSBBcHJpbCAyOSwgMjAyMC4NCg0KUmVnYXJkcywNCiBSaWZhYXQgJiBIYW5uZXMNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_MWHPR19MB15012F3B9748A9CB00DE46C4AED00MWHPR19MB1501namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg
MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7
DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1
IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl
LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXBw
bGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJQVCBNb25vIjsNCglwYW5vc2UtMToy
IDYgNSA5IDIgMiA1IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290
aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw
ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow
aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh
Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt
YXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0K
CW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3Bh
Y2U6YXV0bzsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFw
aEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5OjM0Ow0KCW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGlu
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6
LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWZv
bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs
IGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7
DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJh
Z3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBkaXYuTXNvTGlzdFBh
cmFncmFwaEN4U3BMYXN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h
cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg
ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p
bHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N
CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc4ODM1NjIwNDsNCgltc28tbGlzdC10eXBlOmh5YnJp
ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1MjkwNzA0ODAgNjc2OTg2ODkgNjc2OTg2OTEg
Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl
bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz
dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll
ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2
ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+
PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UYWthaGlybyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlZm9yZSBJ
IGFja25vd2xlZGdlIHlvdXIgY29tbWVudHMsIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5IHNvbWUg
aW1wb3J0YW50IHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv
dXIgZmlyc3QgZW1haWwsIGFuZCB2YXJpb3VzIHR3ZWV0cyB5b3UgcHVibGlzaGVkIGNvbnRleHR1
YWxseSAoPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9kYXJ1dGsvc3RhdHVzLzEyNTMzNzUw
Mzk2ODE4ODQxNjAiPmh0dHBzOi8vdHdpdHRlci5jb20vZGFydXRrL3N0YXR1cy8xMjUzMzc1MDM5
NjgxODg0MTYwPC9hPiksIHN1Z2dlc3QgdGhhdCB3aXRoIG15IHdvcmsgb24gdGhlIHNwZWMgSSBh
bSBkcml2aW5nDQogc29tZSBoaWRkZW4gYWdlbmRhIGZvciBteSBjb21wYW55LCBhbmQgeW91IGFy
ZSBleHBvc2luZyB0aGlzIHRoYW5rcyB0byBzb21lIGZpbmRpbmdzIHlvdSB1bmNvdmVyZWQtIGFu
ZCB0aGF0IHRoZSBXRyBzb21laG93IG1pc3NlZC48YnI+DQpUaGlzIGlzIG9mIGNvdXJzZSBub25z
ZW5zZSwgaW5zdWx0aW5nIHRvIG15IG93biBwcm9mZXNzaW9uYWwgaW50ZWdyaXR5IGFuZCB0byB0
aGUgaW50ZWxsaWdlbmNlIG9mIHRoZSBjaGFpcnMsIHdvcmtpbmcgZ3JvdXAgYW5kIGV2ZXJ5b25l
IHdobyBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb24uIEkgaW5jbHVkZSB0aGUgdHdlZXRz
IGluIHRoZSBkaXNjdXNzaW9uIGJlY2F1c2UgeW91IGluY2x1ZGVkIGluIHRoZW0gYSBsaW5rIHRv
IHRoZSBtYWlsaW5nDQogbGlzdCBhcmNoaXZlcywgaGVuY2UgaW52b2x2aW5nIHRoZSBXRyBpbiB0
aGUgcHJvY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBiYXNpYyBmYWN0czo8bzpw
PjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp
IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu
O21zby1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHByb2ZpbGUgYXMgaXQgZXhpc3RzIHRvZGF5IGRvZXMg
Tk9UIHdvcmsgb3V0IG9mIHRoZSBib3ggd2l0aCBBdXRoMCwgdGhlcmUgYXJlIHNldmVyYWwgdGhp
bmdzIHRoYXQgd291bGQgbmVlZCB0byBjaGFuZ2UgaW4gdGhlIHByb2R1Y3QgZm9yIHRoYXQgdG8g
aGFwcGVuLSBpbmNsdWRpbmcgYWRkaW5nIHN1cHBvcnQgZm9yIHJlc291cmNlIGluZGljYXRvcnMg
d2hpY2ggaXMgY3VycmVudGx5DQogbWlzc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt
c28tYWRkLXNwYWNlOmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBsYXlvdXQgb2YgdGhlIEF1dGgwIHRva2VuIGlzIGNlcnRh
aW5seSBub3QgYSBzZWNyZXQsIGdpdmVuIHRoYXQgaXQgd2FzIHByZXNlbnRlZCBhbG9uZ3NpZGUg
YWxsIHRoZSBvdGhlciB0b2tlbnMgb2J0YWluZWQgZnJvbSBvdGhlciB2ZW5kb3JzIGF0IHRoZSBP
U1cyMDE5IGluIE1hcmNoLCBpbiB0aGUgaW5pdGlhbCBkcmFmdCBwaXRjaCBhdCBJRVRGMTA0IGFz
IHJlY29yZGVkIGluDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhy
ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3Ns
aWRlcy0xMDQtb2F1dGgtc2Vzc2Etand0LXByb2ZpbGUtZm9yLWFjY2Vzcy10b2tlbi0wMCI+aHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9tYXRlcmlhbHMvc2xpZGVzLTEw
NC1vYXV0aC1zZXNzYS1qd3QtcHJvZmlsZS1mb3ItYWNjZXNzLXRva2VuLTAwPC9hPiwNCiBpbiB0
aGUgZmlyc3QgZGlzY3Vzc2lvbiBhdCBJRVRGMTA1IGFzIHNob3duIGluIDxhIGhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDUvbWF0ZXJpYWxzL3NsaWRlcy0xMDUt
b2F1dGgtc2Vzc2EtanNvbi13ZWItdG9rZW4tand0LXByb2ZpbGUtZm9yLW9hdXRoLTIwLWFjY2Vz
cy10b2tlbnMtMDItMDAiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEw
NS9tYXRlcmlhbHMvc2xpZGVzLTEwNS1vYXV0aC1zZXNzYS1qc29uLXdlYi10b2tlbi1qd3QtcHJv
ZmlsZS1mb3Itb2F1dGgtMjAtYWNjZXNzLXRva2Vucy0wMi0wMDwvYT4uIFRoZSB1c2Ugb2YgcmVz
b3VyY2UgaW5kaWNhdG9ycyBmb3IgY2xpZW50IGNyZWQgZmxvd3MgaXMgY2VydGFpbmx5IG5vdCBh
IGRhcmsgcGxveSB0byBzbXVnZ2xlIHRoZSBBdXRoMCB3YXksIGluIGZhY3QgaXTigJlzDQogaW5m
b3JtZWQgbW9yZSBieSBteSB3b3JrIG9uIEF6dXJlIEFELSB3aGVyZSBJIGZvdW5kIHRoZSB0cmFu
c2l0aW9uIGZyb20gcHNldWRvIHJlc291cmNlIGluZGljYXRvcnMgdG8gc2NvcGVzIHRvIGJlIHJp
ZGRsZWQgYnkgY2hhbGxlbmdlcy4gT25jZSBhZ2FpbiwgYWxsIGRpc2N1c3Npb25zIHdlcmUgbWFk
ZSBpbiBmdWxsIHRyYW5zcGFyZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i
TXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQt
c3BhY2U6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+VGhlIGNvbmNlcm5zIGFib3V0IHN5bW1ldHJpYyBhbGdvcml0aG1zIGJlaW5n
IGFsbG93ZWQsIHdoaWNoIHlvdSBhcmUgb2RkbHkgYnJpbmdpbmcgdXAgaW4gYSB0d2VldCByYXRo
ZXIgdGhhbiBvbiB0aGUgbGlzdCwgYXJlIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBkaXNjdXNzaW9u
OiBwZW9wbGUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBhc2tlZCBmb3Igc3ltbWV0
cmljIHRvIGJlDQogYW4gb3B0aW9uIGFuZCBldmVuIHRvIHJlbGF4IHRoZSBjdXJyZW50IGxhbmd1
YWdlIHRvIGJlIG1vcmUgcGVybWlzc2l2ZSwgd2hpY2ggSSBnZW50bHkgcHVzaGVkIGJhY2sgYWdh
aW5zdC4gQWdhaW4sIG5vdCBhbiBvYnNjdXJlIHBsb3kuPG86cD48L286cD48L3NwYW4+PC9saT48
L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIGFtIHNhZGRlbmVkIHRoYXQgeW91IGNob3NlIHRvIG1ha2UgdGhvc2Ug
c3RhdGVtZW50cyBvbiB0d2l0dGVyLiBUaGVyZSB3YXMgbm90aGluZyBmb3IgeW91IHRvIGRpc2Nv
dmVyLCBldmVyeXRoaW5nIHdhcyBhbHJlYWR5IG91dCBpbiB0aGUgb3Blbi4NCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IG1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgcmV0
cmFjdGluZyB5b3VyIGFjY3VzYXRpb25zLiBJIGFtIG5vdCB3b3JyaWVkIGFib3V0IG15c2VsZiwg
bXkgY29uc2NpZW5jZSBpcyBwZXJmZWN0bHkgY2xlYW4gYW5kIHRoZSBJRVRGIHByb2Nlc3MgcmVj
b3JkcyBiYWNrIG1lIHVwLCBidXQgYnkgc3VnZ2VzdGluZyBsYWNrIG9mIHRyYW5zcGFyZW5jeSB5
b3UgYXJlIHVuZmFpcmx5IHBvcnRyYXlpbmcgdGhlIElFVEYsDQogc3RhbmRhcmRpemF0aW9uIHBy
b2Nlc3MgYW5kIHRoZSBwZW9wbGUgd2hvIGRvIHRoZWlyIGJlc3QgdG8gY2hlY2sgYXQgdGhlIGRv
b3IgdGhlaXIgYWZmaWxpYXRpb25zIGFuZCBjb250cmlidXRlIHRoZWlyIHRpbWUgYW5kIGV4cGVy
dGlzZSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIGluZHVzdHJ5IGFzIGEgd2hvbGUuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgYW0gYWRkaW5nIHRoZSB0d2VldHMgaGVyZSBmb3IgcmVmZXJlbmNl
LCB0b2dldGhlciB3aXRoIHRoZSB0cmFuc2xhdGlvbiBUd2l0dGVyIHByb3ZpZGVkLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UYWthQEF1dGhsZXRlLCBCYWFTIGZvciBPQXV0aCAyLjAgJmFtcDsg
T3BlbklEIENvbm5lY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBkYXJ1
dGs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOCguOBl+OChOOBqOaAneOBo+OBpuiqv+OB
ueOBpuOBv+OBn+OCieOAgTwvc3Bhbj5BdXRoMDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtNUyBHb3RoaWMmcXVvdDsiPu+8iOOCueODmuODg+OCr+ODquODvOODieOBruaJgOWxnuS8geal
re+8ieOBrjwvc3Bhbj4gY2xpZW50X2NyZWRlbnRpYWxzDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jg5Xjg63jg7zjga7lrp/oo4Xjga88L3NwYW4+IGF1
ZGllbmNlPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yI
PC9zcGFuPlJGQyA4NzA3DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7jga48L3NwYW4+IHJlc291cmNlIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtNUyBHb3RoaWMmcXVvdDsiPg0K55u45b2T77yJ44GM5b+F6aCI44Gn44CB55Sf5oiQ44GZ44KL
PC9zcGFuPiBKV1QgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90
OyI+44Ki44Kv44K744K544OI44O844Kv44Oz44GuPC9zcGFuPiBzdWINCjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOBq+OCr+ODqeOCpOOCouODs+ODiDwv
c3Bhbj4gSUQgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+
DQrjgpLln4vjgoHovrzjgoDjgII8L3NwYW4+SldUIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOCouOCr+OCu+OCueODiOODvOOCr+ODs+S7leanmOODieOD
qeODleODiOOBjOatquOCk+OBp+OBhOOCi+OBruOBr+OBk+OCjOOBjOeQhueUseOBoOOCjeOBhuOA
gjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1ZGRlbmx5LCBJ
IHNlYXJjaGVkIGFuZCB0aG91Z2h0LCBpbXBsZW1lbnRhdGlvbiBvZiBjbGllbnRfY3JlZGVudGlh
bHMgZmxvdyBvZiBBdXRoMCAoY29tcGFueSBvZiBTcGVjIExlYWQpIHJlcXVpcmVzIGF1ZGllbmNl
IChlcXVpdmFsZW50IHRvIHJlc291cmNlIG9mIFJGQyA4NzA3KSwgYW5kIGVtYmVkIGNsaWVudCBJ
RCBpbiBzdWIgb2YgZ2VuZXJhdGVkIEpXVCBhY2Nlc3MgdG9rZW4uIFRoaXMgaXMgcHJvYmFibHkN
CiB0aGUgcmVhc29uIHdoeSB0aGUgSldUIGFjY2VzcyB0b2tlbiBzcGVjaWZpY2F0aW9uIGRyYWZ0
IGlzIGRpc3RvcnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5YWD44CFPC9zcGFuPiBBdXRoMCA8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij4NCuOBruePvuWun+ijheOC
kualreeVjOOBq+iqjeOCgeOBleOBm+OCi+OBn+OCgeOBqzwvc3Bhbj4gSldUIDxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuOCouOCr+OCu+OCueODiOODvOOC
r+ODs+aomea6luS7leanmOetluWumuS9nOalreOBjOmWi+Wni+OBleOCjOOBn+OBqOWZguOBp+OB
r+iBnuOBhOOBpuOBhOOBn+OBjOOAgeWun+mam+OBq+OBneOBhuOBoOOBo+OBn+OBi+OAguaKgOih
k+eahOOBq+S4jeiHqueEtuOBqueCueOBjOWkmuOBhOOBl+ijj+S6i+aDheOBjOOBr+OBo+OBjeOC
iuOBl+OBn+S7iuOBqOOBquOBo+OBpuOBr+m7meOBo+OBpuOBhOOCi+ios+OBq+OCguOBhOOBi+OB
quOBhOOBruOBp+OAgeODoeODvOODquODs+OCsOODquOCueODiOOBp+aEj+imi+OCkui/sOOBueOB
n+OAgjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p
ZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9KeTFmcGFyNkxLbk5YX3pwb1Q3X2ZwQ3pCU2cvPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIGhlYXJkIHJ1bW9ycyB0aGF0IHRo
ZSBKV1QgQWNjZXNzIFRva2VuIHN0YW5kYXJkIHNwZWNpZmljYXRpb24gd29yayB3YXMgc3RhcnRl
ZCB0byBnZXQgdGhlIGluZHVzdHJ5IHRvIGFjY2VwdCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlv
biBvZiBBdXRoMCwgYnV0IHdhcyB0aGF0IHJlYWxseSB0aGUgY2FzZT8gU2luY2UgdGhlcmUgYXJl
IG1hbnkgdGVjaG5pY2FsIHVubmF0dXJhbCBwb2ludHMgYW5kIGl0DQogaXMgaW1wb3NzaWJsZSB0
byBrZWVwIHNpbGVudCBub3cgdGhhdCB0aGUgY2lyY3Vtc3RhbmNlcyBhcmUgY2xlYXIsIEkgbWFk
ZSBhbiBvcGluaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOBpOOBhOOB
p+OBq+iogOOBo+OBpuOBiuOBj+OBqOOAgTwvc3Bhbj5BdXRoMA0KPHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44GM55Sf5oiQ44GZ44KLPC9zcGFuPiBKV1Qg
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+DQrjgqLjgq/j
grvjgrnjg4jjg7zjgq/jg7Pjga7nvbLlkI3jgqLjg6vjgrTjg6rjgrrjg6DjgajjgZfjgabpgbjm
ip7jgafjgY3jgovjga7jga/jgIE8L3NwYW4+SFMyNTYgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44GoPC9zcGFuPiBSUzI1Ng0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gu44G/44Gu44KI44GG44Gg44CCPC9z
cGFuPkhTMjU2IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi
Pg0K44Gv5a++56ew6Y2157O744Ki44Or44K044Oq44K644Og44CC5LiA5pa544GuPC9zcGFuPiBS
UzI1NiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jga/p
nZ7lr77np7DpjbXns7vjgqLjg6vjgrTjg6rjgrrjg6DjgaDjgYzjgIHjgrvjgq3jg6Xjg6rjg4bj
gqPjg7zkuIrjga7nkIbnlLHjgac8L3NwYW4+IEZpbmFuY2lhbC1ncmFkZSBBUEkgUGFydCAyDQo8
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgafjga/kvb/n
lKjnpoHmraLjgajjgZXjgozjgabjgYTjgovjgII8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JbmNpZGVudGFsbHksIGl0IHNlZW1zIHRoYXQgb25seSBIUzI1NiBh
bmQgUlMyNTYgY2FuIGJlIHNlbGVjdGVkIGFzIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGZvciB0
aGUgSldUIGFjY2VzcyB0b2tlbiBnZW5lcmF0ZWQgYnkgQXV0aDAuIEhTMjU2IGlzIGEgc3ltbWV0
cmljIGtleSBhbGdvcml0aG0uIE9uIHRoZSBvdGhlciBoYW5kLCBSUzI1NiBpcyBhbiBhc3ltbWV0
cmljIGtleSBhbGdvcml0aG0sIGJ1dCBmb3INCiBzZWN1cml0eSByZWFzb25zLCBpdCBpcyBwcm9o
aWJpdGVkIGluIEZpbmFuY2lhbC1ncmFkZSBBUEkgUGFydCAyLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv
bG9yOmJsYWNrIj5PQXV0aCAmbHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm
IG9mIFRha2FoaWtvIEthd2FzYWtpICZsdDt0YWthQGF1dGhsZXRlLmNvbSZndDs8YnI+DQo8Yj5E
YXRlOiA8L2I+VGh1cnNkYXksIEFwcmlsIDIzLCAyMDIwIGF0IDE4OjAxPGJyPg0KPGI+VG86IDwv
Yj5vYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5WaXR0b3JpbyBC
ZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmcm
Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICZx
dW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9r
ZW5zJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIGFwb2xvZ2l6ZSBpZiBteSBwcmV2aW91cyBwb3N0IGhhcyBtYWRlIHlv
dSBhbGwgaGVyZSBmZWVsIHVucGxlYXNhbnQsIGVzcGVjaWFsbHkgSSdtIHNvcnJ5IGZvciB0aGUg
YXV0aG9yLCB0aGUgY2hhaXJzLCBhbmQgcGVvcGxlIHdobyBkaXJlY3RseSBqb2luZWQgdGhlIGRp
c2N1c3Npb24gYWJvdXQgdGhlIHNwZWMuIEkgY291bGQgaGF2ZSBleHByZXNzZWQgbXkgZGlzYWdy
ZWVtZW50IG9uIHRoZSByZXF1aXJlbWVudHMNCiBmb3IgJnF1b3Q7YXVkJnF1b3Q7IGFuZCAmcXVv
dDtzdWImcXVvdDsgaW4gYW5vdGhlciBkaWZmZXJlbnQgd2F5LiBGb3Igc29mdHdhcmUgc3BlY2lm
aWNhdGlvbnMgYW5kIGFyY2hpdGVjdHVyZXMsIEknbSBsaWFibGUgdG8gZ2V0IGV4Y2l0ZWQgYW5k
IGFnZ3Jlc3NpdmUuIFBsZWFzZSBmb3JnaXZlIG1lLjxicj4NCjxicj4NClJlZ2FyZGluZyB0aGUg
cmVsYXRpb25zaGlwIGJldHdlZW4gJnF1b3Q7YXVkJnF1b3Q7IGFuZCAmcXVvdDtzY29wZSZxdW90
OywgdGhlIGFzc3VtcHRpb24gaW4gdGhlIGRyYWZ0IGlzIG5vdCBuZWNlc3NhcmlseSBhcHBsaWNh
YmxlIHRvIGFsbCBwb3NzaWJsZSB1c2UgY2FzZXMuIEZvciBleGFtcGxlLCBtdWx0aXBsZSByZXNv
dXJjZXMgbWF5IHNoYXJlIHRoZSBzYW1lIHNjb3Blcy4gV2hhdCBpZiBib3RoICZxdW90Oy9yZXNv
dXJjZTEmcXVvdDsgYW5kICZxdW90Oy9yZXNvdXJjZTImcXVvdDsgcmVjb2duaXplICZxdW90O2dl
dCZxdW90Ow0KIHNjb3BlIGFuZCAmcXVvdDt1cGRhdGUmcXVvdDsgc2NvcGU/IEluIHRoaXMgY2Fz
ZSwgaXQgaXMgbm90IGFwcHJvcHJpYXRlIHRvIGRldGVybWluZSB0aGUgZGVmYXVsdCByZXNvdXJj
ZSBpbmRpY2F0b3IgZm9yICZxdW90O2F1ZCZxdW90OyBmcm9tIHRoZSBzY29wZXMuIEl0IGlzIGFs
c28gaW1wb3NzaWJsZSB0byBtYXAgc2NvcGVzIHRvIHJlc291cmNlcyBhbmQgdmljZSB2ZXJzYS4g
VGhlIGFzc3VtcHRpb24gaW4gdGhlIGN1cnJlbnQgZHJhZnQgaXMgdG9vIG5hcnJvdyB0byBiZSBp
bmNsdWRlZA0KIGluIGEgc3RhbmRhcmQuLiBJZiB0aGUgY3VycmVudCBkZXNjcmlwdGlvbiBjb250
aW51ZXMgdG8gZXhpc3QsIGl0IHdpbGwgaW1wb3NlIGJpZyByZXN0cmljdGlvbnMgb24gdGhlIGRl
c2lnbiBvZiBzY29wZXMgYW5kIHJlc291cmNlcy48YnI+DQo8YnI+DQpJZiB5b3Ugc3RpbGwgdGhp
bmsgdGhlICZxdW90O2F1ZCZxdW90OyBjbGFpbSBzaG91bGQgYWx3YXlzIGV4aXN0LCB0aGVuIHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFuZC9vciB0aGUgdG9rZW4gZW5kcG9pbnQgKGFuZC9v
ciB0aGUgYmFja2NoYW5uZWwgYXV0aGVudGljYXRpb24gZW5kcG9pbnQgYW5kL29yIHRoZSBkZXZp
Y2UgYXV0aG9yaXphdGlvbiBlbmRwb2ludCkgb2YgeW91ciBzeXN0ZW0gY2FuIHJlcXVpcmUgdGhl
ICZxdW90O3Jlc291cmNlJnF1b3Q7IHJlcXVlc3QgcGFyYW1ldGVyDQogYXMgbWFuZGF0b3J5LiBX
ZSBkb24ndCBoYXZlIHRvIHB1dCBydWxlcyB0byBkZXRlcm1pbmUgdGhlIGRlZmF1bHQgJnF1b3Q7
YXVkJnF1b3Q7IHZhbHVlIGludG8gdGhlIHNwZWMgYWJvdXQgSldUIGFjY2VzcyB0b2tlbnMuIFRo
ZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBSRkMgODcwNyBjYW4g
d29yayByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIGZvcm1hdCBvZiBhY2Nlc3MgdG9rZW5zIGlz
IEpXVCBvciBub3QuIFRoZXJlZm9yZSwgaXQgaXMgbm90DQogYXBwcm9wcmlhdGUgdG8gZGlzY3Vz
cyB0aGUgbmVjZXNzaXR5IG9mIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gb25seSBpbiB0aGUg
Y29udGV4dCBvZiAmcXVvdDtKV1QmcXVvdDsgYWNjZXNzIHRva2Vucy48YnI+DQo8YnI+DQpSZWdh
cmRpbmcgdGhlICZxdW90O3N1YiZxdW90OyBjbGFpbSwgc2V0dGluZyB0aGUgY2xpZW50IElEIHRo
ZXJlLCByYXRoZXIsIHdpbGwgY29uZnVzZSByZXNvdXJjZSBzZXJ2ZXJzLiBJZiB0aGUgJnF1b3Q7
c3ViJnF1b3Q7IGNsYWltIGlzIHNldCBldmVuIGluIHRoZSBjYXNlIG9mIHRoZSBjbGllbnQgY3Jl
ZGVudGlhbHMgZmxvdywgcmVzb3VyY2Ugc2VydmVycyBjYW5ub3QganVkZ2Ugd2hldGhlciB0aGUg
JnF1b3Q7c3ViJnF1b3Q7IGNsYWltIHJlcHJlc2VudHMgZWl0aGVyIHRoZSBzdWJqZWN0IG9mDQog
dGhlIHJlc291cmNlIG93bmVyIG9yIHRoZSBjbGllbnQgSUQuIE9uIHRoZSBvdGhlciBoYW5kLCBp
ZiB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNsYWltIGlzIG51bGwgb3IgYWJzZW50IGluIHRoZSBjYXNl
IG9mIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdywgcmVzb3VyY2Ugc2VydmVycyBjYW4gYWx3
YXlzIGhhbmRsZSB0aGUgdmFsdWUgb2YgdGhlICZxdW90O3N1YiZxdW90OyBjbGFpbSBhcyB0aGUg
c3ViamVjdCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuIEZvciByZXNvdXJjZSBzZXJ2ZXJzLA0KIHRo
aXMgbG9naWMgaXMgZWFzaWVyLiBTZXR0aW5nIHRoZSAmcXVvdDtzdWImcXVvdDsgY2xhaW0gaW4g
ZXZlcnkgY2FzZSB0byBtYWtlIHJlc291cmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgc2ltcGxl
ciBpcyBub3QgY29udmluY2luZy4NCjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpUYWth
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEFw
ciAyNCwgMjAyMCBhdCAyOjE1IEFNIFRha2FoaWtvIEthd2FzYWtpICZsdDs8YSBocmVmPSJtYWls
dG86dGFrYUBhdXRobGV0ZS5jb20iPnRha2FAYXV0aGxldGUuY29tPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Rmlyc3QsIHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gZmFpciwgSSB0aGluayBJIHNob3Vs
ZCBzaGFyZSB3aGF0IEkgb2JzZXJ2ZWQgdG9kYXkuIEF1dGgwJ3MgY2xpZW50X2NyZWRlbnRpYWxz
IGZsb3cgcmVxdWlyZXMgYW4gJnF1b3Q7YXVkaWVuY2UmcXVvdDsgcGFyYW1ldGVyLCB3aGljaCBp
cyBlcXVpdmFsZW50IHRvIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXIgZGVmaW5l
ZCBpbiBSRkMgODcwNywgYW5kIGVtYmVkcyB0aGUgY2xpZW50DQogSUQgaW4gdGhlIGdlbmVyYXRl
ZCBKV1QgYWNjZXNzIHRva2VuIGFzIHRoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNs
YWltLjxicj4NCjxicj4NCk15IG9waW5pb24gYXMgYSBzb2Z0d2FyZSBlbmdpbmVlciBpcyBhcyBm
b2xsb3dzLjxicj4NCjxicj4NClthdWRdPGJyPg0KVGhlICZxdW90O2F1ZCZxdW90OyBjbGFpbSBz
aG91bGQgYmUgbnVsbCBvciBhYnNlbnQgd2hlbiB0aGUgJnF1b3Q7cmVzb3VyY2UmcXVvdDsgcGFy
YW1ldGVycyBhcmUgbm90IGdpdmVuIGluIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gSXQgaXMg
bm90IGdvb2QgdG8gaW50cm9kdWNlIGluZmxleGlibGUgcnVsZXMgdG8gZGV0ZXJtaW5lIHRoZSBk
ZWZhdWx0IHZhbHVlIGZvciB0aGUgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIGJhc2VkIG9uIHRoZSAm
cXVvdDtzY29wZSZxdW90OyBwYXJhbWV0ZXIuPGJyPg0KPGJyPg0KW3N1Yl08YnI+DQpUaGUgJnF1
b3Q7c3ViJnF1b3Q7IGNsYWltIHNob3VsZCBiZSBudWxsIG9yIGFic2VudCB3aGVuIGEgcmVzb3Vy
Y2Ugb3duZXIgaXMgbm90IGludm9sdmVkIGluIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVG8g
YmUgY29uY3JldGUsIHRoZSAmcXVvdDtzdWImcXVvdDsgY2xhaW0gc2hvdWxkIGJlIG51bGwgb3Ig
YWJzZW50IGluIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdy4gVGhlIHNwZWMgZHJhZnQgc2F5
cyBpbiAmcXVvdDs1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyZxdW90OyBhcyBmb2xsb3dzLjxi
cj4NCjxicj4NCi0gLSAtIC0gLSAtIC0gLSAtIC08YnI+DQpBdXRob3JpemF0aW9uIHNlcnZlcnMg
c2hvdWxkIHByZXZlbnQgc2NlbmFyaW9zIHdoZXJlIGNsaWVudHMgY2FuIGFmZmVjdCB0aGUgdmFs
dWUgb2YgdGhlIHN1YiBjbGFpbSBpbiB3YXlzIHRoYXQgY291bGQgY29uZnVzZSByZXNvdXJjZSBz
ZXJ2ZXJzLiZuYnNwOyBGb3IgZXhhbXBsZTogaWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVs
ZWN0cyB0byB1c2UgdGhlIGNsaWVudF9pZCBhcyB0aGUgc3ViIHZhbHVlIGZvciBhY2Nlc3MgdG9r
ZW5zIGlzc3VlZCBjbGllbnQNCiBjcmVkZW50aWFscyBncmFudCwgdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyIHNob3VsZCBwcmV2ZW50IGNsaWVudHMgdG8gcmVnaXN0ZXIgYW4gYXJiaXRyYXJ5IGNs
aWVudF9pZCB2YWx1ZSwgYXMgdGhpcyB3b3VsZCBhbGxvdyBtYWxpY2lvdXMgY2xpZW50cyB0byBz
ZWxlY3QgdGhlIHN1YiBvZiBhIGhpZ2ggcHJpdmlsZWdlIHJlc291cmNlIG93bmVyIGFuZCBjb25m
dXNlIGFueSBhdXRob3JpemF0aW9uIGxvZ2ljIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXINCiByZWx5
aW5nIG9uIHRoZSBzdWIgdmFsdWUuJm5ic3A7IEZvciBtb3JlIGRldGFpbHMgcGxlYXNlIHJlZmVy
IHRvIHNlY3Rpb24gNC4xMyBvZiBbT0F1dGgyLlNlY3VyaXR5LkJlc3RQcmFjdGljZXNdLjxicj4N
Cjxicj4NClRvIHByZXZlbnRpbmcgY3Jvc3MtSldUIGNvbmZ1c2lvbiwgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXJzIE1VU1QgdXNlIGEgZGlzdGluY3QgaWRlbnRpZmllciBhcyAmcXVvdDthdWQmcXVvdDsg
Y2xhaW0gdmFsdWUgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYWNjZXNzIHRva2VucyBpc3N1ZWQgYnkg
dGhlIHNhbWUgaXNzdWVyIGZvciBkaXN0aW5jdCByZXNvdXJjZXMuPGJyPg0KLSAtIC0gLSAtIC0g
LSAtIC0gLTxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBhdHRhY2sgdmVjdG9yIGlzIGJyb3VnaHQg
YWJvdXQgbWVyZWx5IGJ5IGludHJvZHVjaW5nIHRoZSBmb2xsb3dpbmcgcnVsZSBkZWZpbmVkIGlu
ICZxdW90OzIuMi4gRGF0YSBTdHJ1Y3R1cmUmcXVvdDsuPGJyPg0KPGJyPg0KLSAtIC0gLSAtIC0g
LSAtIC0gLTxicj4NCkluIGNhc2Ugb2YgYWNjZXNzIHRva2VucyBvYnRhaW5lZCB0aHJvdWdoIGdy
YW50cyB3aGVyZSBubyByZXNvdXJjZSBvd25lciBpcyBpbnZvbHZlZCwgc3VjaCBhcyB0aGUgY2xp
ZW50IGNyZWRlbnRpYWxzIGdyYW50LCB0aGUgdmFsdWUgb2Ygc3ViIFNIT1VMRCBjb3JyZXNwb25k
IHRvIGFuIGlkZW50aWZpZXIgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzZXMgdG8gaW5kaWNh
dGUgdGhlIGNsaWVudCBhcHBsaWNhdGlvbi48YnI+DQotIC0gLSAtIC0gLSAtIC0gLSAtPGJyPg0K
PGJyPg0KSWYgdGhlIHJ1bGUgaXMgbm90IGludHJvZHVjZWQsIHRoZSBhdHRhY2sgdmVjdG9yIGRp
c2FwcGVhcnMgYW5kIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gZG9lc24ndCBoYXZlIHRvIGJl
IG1hbmRhdG9yeS48YnI+DQo8YnI+DQpGaW5hbGx5LCB0byBtYWtlIHRoZSBkaXNjdXNzaW9uIGZh
aXIsIEkgc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IEkgbXlzZWxmIGlzIGEgY28tZm91bmRlciBv
ZiBBdXRobGV0ZSwgSW5jLiB0aGF0IHByb3ZpZGVzIGFuIGltcGxlbWVudGF0aW9uIG9mIE9BdXRo
IGFuZCBPcGVuSUQgQ29ubmVjdC4gTXkgdGhvdWdodHMgYWJvdXQgaW1wbGVtZW50YXRpb25zIG9m
IGFjY2VzcyB0b2tlbnMgYXJlIHB1YmxpY2x5IGRlc2NyaWJlZCBoZXJlOjxicj4NCjxicj4NCk9B
dXRoIEFjY2VzcyBUb2tlbiBJbXBsZW1lbnRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbWVk
aXVtLmNvbS9AZGFydXRrL29hdXRoLWFjY2Vzcy10b2tlbi1pbXBsZW1lbnRhdGlvbi0zMGMyZThi
OTBmZjAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21lZGl1bS5jb20vQGRhcnV0ay9vYXV0aC1h
Y2Nlc3MtdG9rZW4taW1wbGVtZW50YXRpb24tMzBjMmU4YjkwZmYwPC9hPjxicj4NCjxicj4NCkJl
c3QgUmVnYXJkcyw8YnI+DQpUYWthaGlrbyBLYXdhc2FraTxicj4NCkF1dGhsZXRlLCBJbmMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciAy
MiwgMjAyMCBhdCA0OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2Nj
aT08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPk91Y2ghIFNvcnJ5DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUg
Q29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTIyOzwvc3Bhbj4gZml4ZWQ8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RG9taW5pY2sgQmFpZXIgJmx0OzxhIGhy
ZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJh
aWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXks
IEFwcmlsIDIxLCAyMDIwIGF0IDEwOjIzPGJyPg0KPGI+VG86IDwvYj5vYXV0aCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8
L2E+Jmd0OywgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0Lmll
dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZn
dDssIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9j
Y2lAYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29t
PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMg
b24gJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2Vz
cyBUb2tlbnMmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPk9oIGFuZCB3aGlsZSB3ZSBhcmUgYXQgaXQgLSBjb3VsZCB5b3Ug
YWxzbyBmaXggdGhlIHR5cG8gaW4gbXkgbmFtZT8gVGhhbmtzIDspPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+4oCU4oCU4oCUDQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvbWluaWNrIEJhaWVyPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwPk9uIDIxLiBBcHJpbCAyMDIwIGF0IDA5OjQzOjQ5LCBWaXR0b3JpbyBC
ZXJ0b2NjaSAoPGEgaHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4pIHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlRoaXMgaXMgYSBncmVhdCBwb2ludC4gSW4gbXkgaGVhZCBJIGp1c3QgY29uc2lkZXJlZCB0aGUg
T0lEQyBzZW1hbnRpYyBhbmQgdGhvdWdodCBvbmx5IG9mIGhpZ2hsaWdodGluZyB0aGUgYXBwIGlk
ZW50aXR5IGNhc2UsIGJ1dCB5b3UgYXJlIGFic29sdXRlbHkgcmlnaHQgdGhhdCBub3QgbWVudGlv
bmluZyB0aGUNCiB1c2VyIGNhc2UgYXQgYWxsIGlzIGNvbmZ1c2luZy4gSSBhZGRlZCB0aGUgbGFu
Z3VhZ2UgeW91IHN1Z2dlc3RlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzdWIgZGVmaW5pdGlv
bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzITxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Eb21pbmljayBCYWllciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2Js
YW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+
TW9uZGF5LCBBcHJpbCAyMCwgMjAyMCBhdCAyMjo1NDxicj4NCjxiPlRvOiA8L2I+b2F1dGggJmx0
OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll
dGYub3JnPC9hPiZndDssIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp
ZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNv
bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9hPiZxdW90
Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9hPiZndDs8YnI+DQo8Yj5T
dWJqZWN0OiA8L2I+UkU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gJnF1b3Q7SlNPTiBXZWIg
VG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id2hpdGUt
c3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBjYXNlIG9m
IGFjY2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hlcmUgbm8gcmVzb3VyY2Ug
b3duZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCwg
dGhlIHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byBhbiBpZGVudGlmaWVyIHRoZSBh
dXRob3JpemF0aW9uIHNlcnZlciB1c2VzIHRvIGluZGljYXRlIHRoZSBjbGllbnQgYXBwbGljYXRp
b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5NYXliZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgZG9lcyBpdCBz
YXkgYW55d2hlcmUgd2hhdCB0byBleHBsaWNpdGx5IGRvIGluIHRoZSBjYXNlIG9mIGFuIGFjY2Vz
cyB0b2tlbiB3aGVyZSBhIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVkPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmXigJlzIHNv
bWUgbGFuZ3VhZ2UgdGhhdCBzZWVtcyB0byBpbXBseSB0aGF0LCBlLmcuOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsO2Jv
eC1zaXppbmc6Ym9yZGVyLWJveDtib3JkZXItcmFkaXVzOjRweDtmb250LXZhcmlhbnQtbGlnYXR1
cmVzOm5vcm1hbDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7Ij5hcyB0aGlzIHdvdWxkIGFsbG93IG1hbGlj
aW91czwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC1icmVhazpicmVh
ay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BU
IE1vbm8mcXVvdDsiPiZuYnNwOyZuYnNwOyBjbGllbnRzIHRvIHNlbGVjdCB0aGUgc3ViIG9mIGEg
aGlnaCBwcml2aWxlZ2UgcmVzb3VyY2Ugb3duZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBoYXZlIGV4cGVjdGVk
IHRvIHNlZSBzb21ldGhpbmcgc3Ryb25nZXIgbGlrZSBhYm92ZSBqdXN0IC0mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij5JbiBjYXNlIG9mIGFjY2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMg
d2hlcmUgYSByZXNvdXJjZSBvd25lciBpcyBpbnZvbHZlZCwgc3VjaCBhcyB0aGUgYXV0aG9yaXNh
dGlvbiBjb2RlIGdyYW50LCB0aGUgdmFsdWUgb2Ygc3ViIFNIT1VMRCBjb3JyZXNwb25kIHRvIHRo
ZSBzdWJqZWN0IGlkZW50aWZpZXIgb2YgdGhlIHJlc291cmNlIG93bmVyLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYg
dGhpcyBzcGVjIGlzIGFib3V0IGludGVyb3AsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYXQgbGVh
c3QgYSByZWNvbW1lbmRhdGlvbi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPuKAlOKAlOKAlA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5Eb21pbmljayBCYWllcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PbiAy
MC4gQXByaWwgMjAyMCBhdCAwOTo0ODo1MSwgPGEgaHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRv
Y2NpQGF1dGgwLi5jb20iIHRhcmdldD0iX2JsYW5rIj4NCnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgw
LmNvbTwvYT4gKDxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iIHRh
cmdldD0iX2JsYW5rIj52aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208L2E+KSB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5UaGFua3MgRG9taW5pY2sgZm9yIHlvdXIgY29tbWVudHMhPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPklubGluZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+
Jmd0OzwvaT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPiBBbGwgb3RoZXIgT0F1dGggc3BlY3MgbWFrZSBhIHZlcnkgY2xlYXIgZGlzdGluY3Rp
b24gYmV0d2VlbiB1c2VycyBhbmQgY2xpZW50Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJl4oCZcyBhIG51YW5jZSB3b3J0aCBoaWdobGlnaHRp
bmcgaGVyZTogc3ViICE9IHVzZXIuIEluIHByZXZpb3VzIGRpc2N1c3Npb25zIG9uIHRoaXMgdG9w
aWMgaXQgaGFzIGJlZW4gYnJvdWdodCB1cCB0aGF0IHRoZSBKV1Qgc3BlYyBkZWZpbmVzIHN1YiBh
cyBpZGVudGlmeWluZyB0aGUgcHJpbmNpcGFsIHRoYXQNCiBpcyB0aGUgc3ViamVjdCBvZiB0aGUg
SldULCBhbmQgdGhhdOKAmXMgbm90IG5lY2Vzc2FyaWx5IGxpbWl0ZWQgdG8gdXNlcnMuIDxvOnA+
PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhvd2V2ZXIgSSBnZXQgdGhlIHBvdGVu
dGlhbCBjb25mdXNpb24sIGFuZCBJIGFtIGhhcHB5IHRvIGFkZCBjbGFyaWZ5aW5nIGxhbmd1YWdl
IGlmIHlvdSBoYXZlIHNwZWNpZmljIHBhc3NhZ2VzIGluIHRoZSBzcGFjZSB5b3UgYXJlIHBhcnRp
Y3VsYXJseSB3b3JyaWVkIGFib3V0OiBob3dldmVyIEkgZmVlbCB0aGUgbWF0dGVyIGlzIGFkZHJl
c3NlZCB1cGZyb250IGJ5IHRoZSBsYW5ndWFnZSBpbiBTZWN0aW9uIDIuMi4gaW4gdGhlIHN1YiBl
bnRyeSwg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr
Ij5JbiBjYXNlIG9mIGFjY2VzcyB0b2tlbnMgb2J0YWluZWQgdGhyb3VnaCBncmFudHMgd2hlcmUg
bm8gcmVzb3VyY2Ugb3duZXIgaXMgaW52b2x2ZWQsIHN1Y2ggYXMgdGhlIGNsaWVudCBjcmVkZW50
aWFscyBncmFudCwgdGhlIHZhbHVlIG9mIHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byBhbiBpZGVu
dGlmaWVyIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB1c2VzIHRvIGluZGljYXRlIHRoZSBjbGll
bnQgYXBwbGljYXRpb24u4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IGFu
ZCBTZWN0aW9uIDUgaGFzIGFuIGVudGlyZSBwYXJhZ3JhcGggZGlzY3Vzc2luZyB0aGluZ3MgdG8g
d2F0Y2ggb3V0IGluIGFzc2lnbmluZyBzdWIgdmFsdWVzIGluIHRoZSBhcHAgaWRlbnRpdHkgY2Fz
ZS4gRmVlbCBmcmVlIHRvIHN1Z2dlc3QgYWRkaXRpb25hbCBsYW5ndWFnZSBpZiB5b3Ugd2FudCB0
byBjbGFyaWZ5IGZ1cnRoZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4m
Z3Q7IHN1YiBoYXMgYSBkaWZmZXJlbnQgc2VtYW50aWMgaGVyZSBhcyBpbiBPSURDPC9zcGFuPjwv
aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlICZuYnNwO3NwZWMg
cmVmZXJzIHRvIFJGQzc1MTkgaW4gdGhlIHN1YiBkZWZpbml0aW9uIGluIDIuMiwgcmF0aGVyIHRo
YW4gT0lEQywgdG8gcHJlZW1wdCB0aGF0IGNvbmNlcm4gYW5kIGtlZXAgdGhlIG9yaWdpbmFsIHN1
YiBzZW1hbnRpYyBhdmFpbGFibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT4mZ3Q7
PC9pPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+IEkgYW0gbm90IGZ1bGx5IGNsZWFyIHdoeSBhdWQgaXMgcmVxdWlyZWQuPC9zcGFuPjwvaT48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXVkIGlzIHRoZXJlIG1vc3Rs
eSBiZWNhdXNlIG9mIHRocmVlIHJlYXNvbnM6PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzkuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5NYW55IGV4aXN0aW5nIHNwZWNz
IHBvc3R1bGF0ZSBpdHMgZXhpc3RlbmNlIGluIHRoZSB0b2tlbi4gTm8gb25lIGRlY2xhcmVzIGl0
IGFzIGEgcHJvcGVyIE1VU1QgKGFwYXJ0IGZyb20gdGhlIEJDUCwgYnV0IHRoYXTigJlzIHBhcnRp
YWwpIGhvd2V2ZXIgSSB0aGluayBpdHMgaW1wb3J0YW5jZSBjb21lcyBhY3Jvc3MuLjxicj4NCi1C
ZWFyZXIgdG9rZW4gdXNhZ2UgUkZDNjc1MCBjYWxscyBpdCBvdXQgKGluIHRocmVhdCBtaXRpZ2F0
aW9uKSBhcyB0aGUgbWVjaGFuaXNtIHRvIHByZXZlbnQgdG9rZW4gcmVkaXJlY3QgKGFuZCBhZGRz
IHNjb3BlIHJlc3RyaWN0aW9uIGFzIGFsc28gaW1wb3J0YW50LCBob3dldmVyIGhlcmUgd2UgbWFr
ZSBpdCBvcHRpb25hbCB0byBhY29jdXQgZm9yIG5vbi1kZWxlZ2F0aW9ucyBzY2VuYXJpbykuPGJy
Pg0KLVJlc291cmNlIGluZGljYXRvcnMgUkZDODcwNyByZWZlcnMgdG8gdGhlIHNhbWUgc2VjdGlv
biBvZiBSRkM3NTE5IGFzIG9uZSBvZiB0aGUgYXNzdW1wdGlvbnMgdGhhdCBtdXN0IGhvbGQgdG8g
cHJldmVudCBiZWFyZXIgdG9rZW5zIG1pc3VzZQ0KPGJyPg0KLUJDUDIyNSBtYWtlcyBhdWQgbWFu
ZGF0b3J5IGZvciBBUyB3aGljaCBjYW4gaXNzdWUgSldUcyBmb3IgbW9yZSB0aGFuIG9uZSBhcHA8
bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Ow0KPC9zcGFuPkFwYXJ0IGZyb20gUGluZywgZm9yIHdoaWNoIHNvbWUgb2YgaXRzIGV4YW1wbGVz
IGFyZSB3aXRob3V0IGF1ZCAoYnV0IGFsc28gd2l0aG91dCBpZGVudGlmeWluZyBzY29wZXMsIGdp
dmVuIHRoYXQgdGhlIG9uZSBJIHJldHJpZXZlZCBoYWQgb25seSDigJxvcGVuaWTigJ0pLCBhbGwg
b2YgdGhlIHNhbXBsZSBKV1QgQVRzIEkgcmVjZWl2ZWQgZnJvbSB2ZW5kb3JzIGFsbCBmZWF0dXJl
ZCBhbiBhdWQuIEkga25vdyBvbmUgc2hvdWxuZOKAmXQgb3ZlcmluZGV4DQogb24gdGhvc2UgZXhh
bXBsZXMsIGJ1dCB0b2dldGhlciB3aXRoIHRoZSBhYm92ZSBpdCBzZWVtZWQgdG8gcG9pbnQgdG8g
c29tZXRoaW5nIHVuaXZlcnNhbGx5IHVzZWZ1bC4gT25lIHBvc3NpYmxlIHJlYXNvbiBpcyB0aGF0
IHVzZSBvZiBhIGZvcm1hdCBmb3IgdGhlIEFUIGlzIGNvcnJlbGF0ZWQgd2l0aCB0b3BvbG9naWVz
IHdoZXJlIEFTIGFuZCBSUyBhcmUgc2VwYXJhdGVkIGJ5IHNvbWUgYm91bmRhcnkgKG5ldHdvcmss
IGxvZ2ljYWwsIGJ1c2luZXNzLA0KIGNvZGUgZmFjdG9yaW5nLCBldGMpIGhlbmNlIGlkZW50aWZ5
aW5nIHRoZSByZXNvdXJjZSBzZWVtcyBsaWtlIGEgbmF0dXJhbCBuZWVkLiBBZ2Fpbiwgbm90IGFu
IGlyb24gY2xhZCBsYXcsIGJ1dCBhbiBpbmRpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM5LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+QSBsb3Qgb2YgcGVv
cGxlIHJlcHVycG9zZSBleGlzdGluZyBsaWJyYXJpZXMgZm9yIHRoZSBKV1QgQVQgY2FzZSwgYW5k
IHNvbWUgcGVvcGxlIGV2ZW4gc2VuZHMgaWRfdG9rZW5zIGluIGxpZXUgb2YgQVRzLiBUaGF0IGRv
ZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGNvbmRvbmUgYW55IGJhZCBwcmFjdGljZXMsIGJ1
dCBpbiB0aXMgcGFydGljdWxhciBjYXNlIGl0IHN1Z2dlc3RzIHRoYXQgbG90cyBvZiBkZXZlbG9w
ZXJzIGFscmVhZHkNCiBleHBlY3QvY2FuIGhhbmRsZSBhbiBhdWRpZW5jZSBpbiB0aGUgSldUIHVz
ZWQgdG8gY2FsbCB0aGVpciBBUEk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Tm9uZSBvZiB0aG9zZSBhcmUgYSBzbGFtIGR1bmsgYXJndW1lbnQgZm9yIG1hbmRhdG9yeSwg
YnV0IEkgZmluZCB0aGVtIGNvbXBlbGxpbmcgZW5vdWdoIHRvIHNpbXBsaWZ5IHZhbGlkYXRpb24g
YW5kIGp1c3QgcmVxdWlyZSBhbiBhdWQgdG8gYmUgdGhlcmUsIGFzIG9wcG9zZWQgdG8gaW50cm9k
dWNlIGNvbXBsaWNhdGlvbnMNCiB0aGF0IG1ha2UgaXQgY29uZGl0aW9uYWwgdG8gdGhlIHByZXNl
bmNlIG9mIHNjb3BlcyBvciBvdGhlciBkaXNhbWJpZ3VhdGlvbi4uIE9uZSByZWFzb24gSSBmZWVs
IHByZXR0eSBnb29kIGFib3V0IHRoYXQgaXMgdGhhdCBhZGRpbmcgYSBkZWZhdWx0IGF1ZGllbmNl
IGlzbuKAmXQgdmVyeSBoYXJkIGlmIGFueSBvZiB0aGUgYWJvdmUgYXNzdW1wdGlvbnMgZW5kIHVw
IG5vdCBiZWluZyB0cnVlIGZvciBhIHBhcnRpY3VsYXIgY2FzZTxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj4mZ3Q7IFdoYXTigJlzIHRoZSByYXRpb25hbGUgZm9yIHVzaW5nIGlhdCBpbnN0
ZWFkIG9mIG5iZi4NCjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPlRoYXTigJlzIGp1c3Qgc3RyYWlnaHQgZnJvbSBPSURDIElEX3Rva2VucywgYW5kIHRo
ZSBjb25zaWRlcmF0aW9ucyBhYm91dCByZXB1cnBvc2luZyBleGlzdGluZyBsb2dpYy4gSSBzZWUg
dGhlcmXigJlzIGEgdGhyZWFkIG9uIHRoaXMgc3BlY2lmaWNhbGx5LCBsZXQgbWUgYW5zd2VyIGZ1
cnRoZXIgb24gdGhhdCBicmFuY2guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZndDsg
VGhpcyBzcGVjIGZlZWxzIHNvbWVob3cgaW4gYmV0d2VlbiBhIHByb2ZpbGUgYW5kIGEgQkNQPC9z
cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91IGFyZSBy
aWdodCB0aGF0IHRoaXMgc3BlYyBhdHRlbXB0cyB0byBnbyBiZXlvbmQganVzdCBkZWNsYXJpbmcg
YSBsYXlvdXQsIGFuZCBJIGFncmVlIHRoaXMgbWVhbnMgdGhhdCB0aGlzIHByb2ZpbGUgd2lsbCBu
b3QgYXBwbHkgdG8gYWJzb2x1dGVseSBldmVyeW9uZS4gVGhlIHJlYXNvbiBJIHRyaWVkIHRoYXQN
CiByb3V0ZSAoYXQgdGhlIGNvc3Qgb2Ygd29ya2luZyB3YXkgaGFyZGVyIGluIHRoZSBsYXN0IHll
YXIgZm9yIHJlYWNoaW5nIGNvbnNlbnN1cyB0aGFuIGlmIHdlIHdvdWxkIGhhdmUganVzdCBsaXN0
ZWQgdGhlIHBvc3NpYmxlIGNvbnRlbnQpLCBpcyB0aGF0IEkgb2Z0ZW4gb2JzZXJ2ZSBpbXBsZW1l
bnRlcnMgbWFrZSBxdWVzdGlvbmFibGUgY2hvaWNlcyBiZWNhdXNlIG9mIHRoZSBsYXJnZSBsZWV3
YXkgc3BlY2lmaWNhdGlvbnMgYWxsb3cuIE15IGhvcGUNCiB3YXMgdGhhdCB0aGUgc2NvcGUgb2Yg
dGhpcyBwcm9maWxlIHdhcyBzbWFsbCBlbm91Z2ggdG8gbWFrZSB0aGF0IGV4dHJhIGxldmVsIG9m
IGd1aWRhbmNlIGFjaGlldmFibGUsIHdoZXJlYXMgdHJ5aW5nIHRvIGRvIHRoZSBzYW1lIHdpdGgg
YSBsYXJnZXIgc3BlYyB3b3VsZCBoYXZlIGJlZW4gcHJvaGliaXRpdmVseSBleHBlbnNpdmUuDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBiZWxpZXZlIHRoaW5ncyB3
b3JrZWQgb3V0IHdlbGwgc28gZmFyOiB3ZSBoYWQgbG90cyBvZiBjb25zdHJ1Y3RpdmUgZGlzY3Vz
c2lvbnMsIGFuZCBJIGVuZGVkIHVwIHJlbGF4aW5nIEEgTE9UIG9mIHRoZSBjb25zdHJhaW50cyBJ
IHdhcyBvcmlnaW5hbGx5IGVudmlzaW9uaW5nLiBOb25ldGhlbGVzcywgbXkNCiBob3BlIGlzIHRo
YXQgd2UgaWRlbnRpZmllZCB0aGUgcmlnaHQgc2V0IG9mIGd1aWRlbGluZXMgdGhhdCB3aWxsIGhl
bHAgcGVvcGxlIGFjdHVhbGx5IGludGVyb3BlcmF0ZSBvdXQgb2YgdGhlIGJveCBmb3IgdGhlIG1v
c3QgYmFzaWMvY29tbW9uIHNjZW5hcmlvcywgYXMgb3Bwb3NlZCB0byBjb21wbHlpbmcgd2l0aCB0
aGUgbGV0dGVyIG9mIHRoZSBzcGVjIGJ1dCBzdGlsbCBoYXZpbmcgYSBsb3QgdG8gZmlndXJlIG91
dCBvdXQgb2YgYmFuZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RG9taW5pY2sgQmFpZXI8YnI+
DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDE2LCAyMDIwIDEyOjEwIEFNPGJyPg0KPGI+
VG86PC9iPiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0
ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0
Ozsgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU
SC1XR10gU2Vjb25kIFdHTEMgb24gJnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBm
b3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5TaW5jZSB0aGlzIGlzIHRoZSBsYXN0IGNhbGwsIEkgdGhv
dWdodCBJIGJyaW5nIHVwIHNvbWUgb2YgdGhvdWdodHMgLyBjb25jZXJucy4gU29tZSBvZiB0aGVt
IGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Y2xpZW50X2lkIHZzIHN1Yjwv
c3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+SSBhbSBzdGlsbCBub3QgZW50aXJlbHkgaGFwcHkgd2l0aCB0aGUg4oCccmUtcHVycG9zaW5n
4oCdIG9mIHRoZSBjbGFpbSB0eXBlcyBiYXNlZCBvbiBmbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JZiB0aGUgaW50ZW50aW9uIGlz
LCB0aGF0IHN1YiBleHByZXNzZXMgdGhlIGVudGl0eSBhZ2FpbnN0IHdoaWNoIHRoZSByZXNvdXJj
ZSB3aWxsIGRvIGF1dGhvcmlzYXRpb24gKGFuZCB0aGF0IG1pZ2h0IGJlIGEgY2xpZW50DQogb3Ig
YSB1c2VyKSAtIEkgZ2V0IGl0IChhbmQgbWF5YmUgaXQgc2hvdWxkIGJlIHN0YXRlZCBsaWtlIHRo
YXQpIC0gYnV0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPnRoaXMgdGhpbmtpbmcgcmVtaW5kcyBtZSBvZiB0aGUgb2xkIEFEIGRheXMgd2hl
cmUgdGhlcmUgd2FzIG5vIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlciBhbmQgc2VydmljZSBhY2Nv
dW50cyAoc29tZXRoaW5nIHRoYXQNCiBoYXMgYmVlbiBmaXhlZCBJSVJDIGluIFdpbmRvd3MgU2Vy
dmVyIDIwMTIgUjIpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+QWxsIG90aGVyIE9BdXRoIHNwZWNzIG1ha2UgYSB2ZXJ5IGNs
ZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlcnMgYW5kIGNsaWVudC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkZ1cnRoZXJt
b3JlIGl0IHNheXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPiZxdW90O0F1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQgcHJl
dmVudCBzY2VuYXJpb3Mgd2hlcmUgY2xpZW50cyBjYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7ICZuYnNwO2FmZmVjdCB0aGUg
dmFsdWUgb2YgdGhlIHN1YiBjbGFpbSBpbiB3YXlzIHRoYXQgY291bGQgY29uZnVzZSByZXNvdXJj
ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh
Ij4mbmJzcDsgJm5ic3A7c2VydmVycy7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPklmIHdlIGtlZXAgdGhhdCBkdWFsIHNl
bWFudGljcyBvZiB0aGUgc3ViIGNsYWltIC0gaXQgbXVzdCBiZSBjbGVhcmx5IHN0YXRlZCwgdGhh
dCBzdWJqZWN0IElEIGFuZCBjbGllbnQgSUQgYXJlIG5vdyBpbiB0aGUgc2FtZQ0KIGNvbGxpc2lv
biBkb21haW4uIFNvIHdoZW4gYW4gQVMgLyBPUCBjcmVhdGVzIHRoZW0sIHRoZXkgbmVlZCB0byBi
ZSB1bmlxdWUgYWNyb3NzIHVzZXIgaWRzIGFuZCBjbGllbnQgaWRzLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+TWF5YmUgaXQg
c2hvdWxkIGJlIGFsc28gZXhwbGljaXRseSBtZW50aW9uZWQgdGhhdCBzdWIgaGFzIGEgZGlmZmVy
ZW50IHNlbWFudGljIGhlcmUgYXMgaW4gT0lEQyAtIGV2ZW4gdGhvdWdoIGEgbWFqb3JpdHkgb2Yg
dGhlDQogc29mdHdhcmUgYnVpbHQgdG9kYXkgd2lsbCB1c2UgdGhlbSB0b2dldGhlci48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPmF1ZGllbmNlIGNsYWltPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JIGFtIG5vdCBmdWxseSBjbGVhciB3aHkgYXVkIGlzIHJl
cXVpcmVkLiBPQXV0aCBpdHNlbGYgZG9lcyBub3QgaGF2ZSBhIG5vdGlvbiBvZiBhbiBhdWRpZW5j
ZSAoaW4gdGhlIEpXVCBzZW5zZSkgLSB0aGV5IGhhdmUNCiBzY29wZXMgKHdoaWNoIGlzIHZlcnkg
c2ltaWxhcikuIEJ1dCBpbiBzaW1wbGUgc2NlbmFyaW9zIHdoZXJlIHJlc291cmNlcyBkb27igJl0
IGV4aXN0LCB5b3UnZCBuZWVkIHRvIG1ha2UgdXAgYW4gYXVkaWVuY2UganVzdCB0byBmdWxmaWwg
dGhpcyByZXF1aXJlbWVudC4gQW5kIGluIG1hbnkgY2FzZSB0aGlzIHdpbGwgYmUgZWl0aGVyIHN0
YXRpYyBvciBqdXN0IHJlcGVhdCB0aGUgc2NvcGUgdmFsdWVzLiBXaGF04oCZcyB0aGUgdmFsdWUg
b2YgdGhhdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPklmIHRoZSBjb25jZXB0IG9mIHJlc291cmNlcyBhcmUgdXNlZCwgSSBh
YnNvbHV0ZWx5IGFncmVlIHRoYXQgYXVkIHNob3VsZCBiZSB1c2VkIHRvby4gQnV0IEkgd291bGRu
4oCZdCBtYWtlIGl0IHJlcXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+aWF0IHZzIG5iZjwvc3Bhbj48L2I+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+V2hhdOKAmXMg
dGhlIHJhdGlvbmFsZSBmb3IgdXNpbmcgaWF0IGluc3RlYWQgb2YgbmJmLiBBcmVu4oCZdCBtb3N0
IEpXVCBsaWJyYXJpZXMgKGluY2x1ZGluZyBlLmcuIHRoZSAuTkVUIG9uZSkgbG9va2luZyBmb3Ig
bmJmIGJ5DQogZGVmYXVsdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkdlbmVyYWw8L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgc3BlYyBmZWVscyBz
b21laG93IGluIGJldHdlZW4gYSBwcm9maWxlIGFuZCBhIEJDUC4gT24gb25lIGhhbmQgeW91IGRl
ZmluZSBzb21lIGNsYWltcyBhbmQgdGhlaXIgc2VtYW50aWNzIChnb29kKSAtIG9uIHRoZQ0KIG90
aGVyIGhhbmQgdGhlcmUgaXMgc29tZSBwcmVzY3JpcHRpdmUgZ3VpZGFuY2UgYW5kIG1heWJlIG92
ZXItc3BlY2lmaWNhdGlvbi4gTXkgY29uY2VybiBpcywgdGhhdCBpbiB0aGUgZW5kIG5vLW9uZSB3
aWxsIGZ1bGx5IGNvbXBseSB3aXRoIGl0LCBiZWNhdXNlIGl0IGRvZXNu4oCZdCB3b3JrIG9uZSB3
YXkgb3IgdGhlIG90aGVyIGZvciB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSBrbm93IHdlIGp1c3Qgd2VudCB0aG91
Z2ggdGhlIGRpc2N1c3Npb24gdG8gbWFrZSBjZXJ0YWluIGNsYWltcyByZXF1aXJlZCBhcyBvcHBv
c2VkIHRvIG9wdGlvbmFsIC0gYnV0IG1heWJlIGxlc3MgaXMgbW9yZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRiaCAtIHRo
ZSBtb3N0IHZhbHVhYmxlIHBhcnQgb2YgdGhlIGRvYyB0byBtZSBpcyB0aGUgZGVmaW5pdGlvbiBv
ZiB0aGUg4oCcYXQmIzQzO2p3dOKAnSB0eXAuIEZvciB0aGUgcmVzdCBJ4oCZZCByYXRoZXIgbGlr
ZSB0byBzZWUganVzdA0KIHNvbWUgc3RhbmRhcmQgY2xhaW1zIGFuZCBJRiB0aGV5IGFyZSB1c2Vk
LCB3aGljaCBzZW1hbnRpY3MgdGhleSBoYXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5jaGVlcnMmbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPuKAlOKAlOKAlDwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+RG9taW5pY2sgQmFpZXI8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+T24gMTUuIEFwcmlsIDIwMjAgYXQgMjA6NTk6MzEsIFJp
ZmFhdCBTaGVraC1ZdXNlZiAoPGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4pIHdyb3RlOjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KSGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQpUaGlzIGlzIGEgc2Vjb25k
IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSBQ
cm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90Oy48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KSGVyZSBp
cyB0aGUgZG9jdW1lbnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGlu
ZS1oZWlnaHQ6MTE1JSI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0w
NjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDox
MTUlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUt
aGVpZ2h0OjExNSUiPg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgT0F1dGggbWFp
bGluZyBsaXN0IGJ5IEFwcmlsIDI5LCAyMDIwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7Umlm
YWF0ICZhbXA7IEhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xp
bmUtaGVpZ2h0OjExNSUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPiA8YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4NCjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_MWHPR19MB15012F3B9748A9CB00DE46C4AED00MWHPR19MB1501namp_--


From nobody Fri Apr 24 13:36:58 2020
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 0E0D43A0AD3 for ; Fri, 24 Apr 2020 13:36:56 -0700 (PDT)
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=pingidentity.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 lUFPMUkCiXkv for ; Fri, 24 Apr 2020 13:36:53 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 92C623A0AD1 for ; Fri, 24 Apr 2020 13:36:52 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id n6so11313425ljg.12 for ; Fri, 24 Apr 2020 13:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lG3On5XVOoJefWXnPu2ZH6/2yWim+ASw0LJA3WmTTHM=; b=J9X13ok9gG6EIZ8S5eooe0l4j5g5smKvkbbAqe1rXzgsh/LUgdMT7ssp5NStDgR/KG DUpzE81s/+JrbjjtwWEtKNKHI9LnAzgaRJ/qdDQOIdHB1Mt3eFgwwpOOhXaVYulOJijx d+LH+Ngnr4K09nyifedXLaGJ/nsr7IoR9JdzhESDXUcsKIMs7FQCWy+ueq65pUqyyeoP CjBJqALiUACgM0uLD/v+9kIr8lebkOb054kOW2AS8S/etmtdHba+/r/zm0vdRMfDP7pd UcsdeoMxAQs5fCmT2pPGbBmBh+vYKvzSamgJzL8sd07we365eCRhD4jcowrRqhBP+fEC lM2g==
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=lG3On5XVOoJefWXnPu2ZH6/2yWim+ASw0LJA3WmTTHM=; b=R7/U+PoTtR3tnas8zH9t54vGpBYqpsUfBJ1WAs/zr8x3JOzZok8HoGsm68vTDcWH7p t7gzFU50yH3p99We8kmyKAg/JZ4xag3qvhb3TcVrS0MpV5wtdLrgf+6nOGDErQuzjTBa NaNX8Bahxg2wyFhBQiYQsMhTzEuMfoMReim0VPQBhX8CebbDfgtmCGm4TZH72VIxWpeo S3aRKbDqLEFxrn2Ut0nYNcO5Dqj2qg1vr3NGScbivYztmFqNhMa08mhEJxy323BjMZCx J0bH+GvvWuTPltEgA5Hw80fR/EP5r/ZQkeVWNoZ39xH02OZeU2g1Wk2Gh6jbTGwN6bsi OyHg==
X-Gm-Message-State: AGi0PuZR8mbDBy3YhhCNBZqvHIY8HoaTZfAK6nSphKIOm8E5OyH4Gq80 C8GvJMDFNqizhhQeoJlJy7sayIA8wHM/5k0qYJV0h5IJO8clqlWi+Gdmhfd5f79KNIAnIiklCyn 6uA0lxrwsU9x+Qw==
X-Google-Smtp-Source: APiQypJ0ixB+eM/rGIoqFRFIFAp/t2Kt6NVraoQjYt3ypfqybcuplboHRFkBAx6wJozY3LH37IOMze6tfWgLBpc5qVU=
X-Received: by 2002:a05:651c:505:: with SMTP id o5mr449321ljp.0.1587760610764;  Fri, 24 Apr 2020 13:36:50 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 24 Apr 2020 14:36:24 -0600
Message-ID: 
To: Dick Hardt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000031816905a40f5365"
Archived-At: 
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
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, 24 Apr 2020 20:36:56 -0000

--00000000000031816905a40f5365
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 22, 2020 at 5:36 PM Dick Hardt  wrote:

> Brian: many, many thanks for all the feedback!
>

You are welcome. I won't lie - it was not a quick exercise :)


>
> I did a quick skim of your comments, and will address the first and last
> ones.
>
> On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell  40pingidentity.com@dmarc.ietf.org <40pingidentity.com@dmarc.ietf..org>>
> wrote:
>
>> Been working on this on and off for a while now (it's not exactly short
>> at 80+ pages, various other priorities, etc.) but wanted to share my
>> thoughts from an initial review of the OAuth 2.1 draft before the interi=
m
>> next week where it is on the agenda
>> https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.
>> So for better or worse, here's that review:
>>
>> Abstract:
>> "replaces and obsoletes the OAuth 2..0 Authorization Framework described
>> in RFC 6749."
>> I think "replaces" is probably unnecessary here and, to be pedantic, is
>> arguably inaccurate because published RFCs don't ever go away or get
>> replaced.
>>
>
> I took this language from RFC 6749:
>
>  This specification replaces and obsoletes the OAuth 1.0 protocol
> described in RFC 5849.
>
>
> And adapted it.
>

Well then, I guess there's precedent for it. To me, it doesn't seem quite
right. But I won't argue further with precedent.


Probably should also consider using the official "obsoletes" attribute
>> marker too for 6749 https://tools.ietf..org/html/rfc7991#section-2.45.8
>>  and probably also
>> "updates"/"obsoletes" for others based on the scope of the rest of the
>> document (not sure how this even works with a BCP or if you can or would
>> want to update or obsolete a BCP) if this work proceeds. That scope coul=
d
>> be better described in the abstract too as discussed somewhat in the the=
ad
>> https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/
>> and also the 1st paragraph of
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12.
>> What is and isn't in scope is another larger question that I"m not even
>> sure how to ask. What's included vs. what's referenced? Should this doc =
be
>> incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
>> antithetical to what a BCP is supposed to be but it's also a bit hard to
>> tell how much was used. I mean, what happens if/when the BCP is updated?
>> And that kinda begs the question of if it should also incorporate parts =
of
>> or even replace the browser based apps draft?
>>
>
> Our thinking was to include all the documents where the OAuth Security
> Topics was obsoleting sections of documents so that it could stand on its
> own, and roll up all the best practices.
>
> If there are new best practices for OAuth 2.1, then that would be a new
> BCP..
>

Okay, thanks for the explanation. I think that generally makes sense.

I was thinking more about the other direction like what it would mean for
OAuth 2.1 to update or obsolete the existing BCP 212. But maybe that's not
even an issue.


I guess that's a TBD circa page 68. There was talk about the device grant
>> being in scope but I'm not seeing it (not saying it should or shouldn't =
be
>> there but it was talked about). I dunno exactly but those are some scope
>> questions that come to mind.
>> Speaking of obsoleting, I do want to ensure that existing extensions and
>> profiles of RFC 6749 that use legitimate extension points still present =
and
>> unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
>> not sure how that should work in practice but want to be aware of it as/=
if
>> this work progresses.
>>
>
> Perhaps have a section in the document listing all existing documents tha=
t
> work fine with 2.1?
>

I'm honestly not sure if anything is needed or not. But I do want to try
and ensure that such a perception problem doesn't arise.

Perhaps have a small section that says more or less what I'd said above -
that existing extensions and profiles of RFC 6749 that use legitimate
extension points still present and unchanged in OAuth 2.1 are still okay as
they are now? And include a not-meant-to-be exhaustive list of such
documents as examples thereof.



> 
>
>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#appendix-C
>> "TBD"
>> Given the potentially high visibility of an OAuth 2.1 effort, I think
>> it'd be worthwhile to list organizational affiliations of individuals he=
re
>> in the acknowledgements along with their names. Something like what was
>> done in the first part of
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendi=
x-A.
>> This can help with visibility and justification of (sometimes not
>> insignificant) time spent on the work by non-authors/editors.
>>
>
>  Sure. Are you ok with being added there?
>

Yes, thank you. That was sort of implicit in my suggestion but perhaps I
should have been explicit.

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000031816905a40f5365
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Apr 22, 2020 at 5:36 PM Dick =
Hardt <dick.ha=
rdt@gmail.com> wrote:
Brian: many, many thanks for=
 all the feedback!

You are welc=
ome. I won't lie - it was not a quick exercise :) 
=C2=A0=


I did a quick skim of your comments, and=
 will address the first and last ones.=C2=A0

On Tue, Apr 21, 2020 at 3=
:49 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org>=
; wrote:
Been working on this on and off for a while now (it's no=
t exactly short at 80+ pages, various other priorities, etc.) but wanted to=
 share my thoughts from an initial review of the OAuth 2.1 draft before the=
 interim next week where it is on the agenda htt=
ps://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.=
=C2=A0 So for better or worse, here's that review: 

<=
/div>
Abstract:
"replaces and obsoletes the OAuth 2..0 A=
uthorization Framework described in RFC 6749." 
I think =
"replaces" is probably unnecessary here and, to be pedantic, is a=
rguably inaccurate because published RFCs don't ever go away or get rep=
laced. 

I took this languag=
e from RFC 6749:

=C2=A0This specification replaces and obsoletes the OAuth 1.0 protocol de=
scribed in RFC 5849.

And adapted it.=C2=A0
<=
br>
Well then, I guess there's precedent for it. To me, it do=
esn't seem quite right. But I won't argue further with precedent.


Probably =
should also consider using the official "obsoletes" attribute mar=
ker too for 6749 https://tools.ietf..org/html/rfc7991#section-2.45.8=
 and probably also "updates"/"obsoletes" for others=
 based on the scope of the rest of the document (not sure how this even wor=
ks with a BCP or if you can or would want to update or obsolete a BCP) if t=
his work proceeds. That scope could be better described in the abstract too=
 as discussed somewhat in the thead https://mai=
larchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/ and also =
the 1st paragraph of https://tools.ietf.org/html/draf=
t-parecki-oauth-v2-1-01#section-12. 
What is and isn'=
t in scope is another larger question that I"m not even sure how to as=
k. What's included vs. what's referenced? Should this doc be incorp=
orating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda antithetic=
al to what a BCP is supposed to be but it's also a bit hard to tell how=
 much was used. I mean, what happens if/when the BCP is updated? And that k=
inda begs the question of if it should also incorporate parts of or even re=
place the browser based apps draft? 

Our thinking was to include all the documents where the OAuth Securit=
y Topics was obsoleting sections of documents so that it could stand on its=
 own, and roll up all the best practices.

If there=
 are new best practices=C2=A0for OAuth 2.1, then that would be a new BCP..<=
/div>

Okay, thanks for the expl=
anation. I think that generally makes sense. 

=
I was thinking more about the other direction like what it would mean for O=
Auth 2.1 to update or obsolete the existing BCP 212.=C2=A0But maybe that=
9;s not even an issue. 


<=
div>I guess that's a TBD circa page 68. There was talk about the device=
 grant being in scope but I'm not seeing it (not saying it should or sh=
ouldn't be there but it was talked about). I dunno exactly but those ar=
e some scope questions that come to mind. 
Speaking of obsole=
ting, I do want to ensure that existing extensions and profiles of RFC 6749=
 that use legitimate extension points still present and unchanged in OAuth =
2.1 aren't inadvertently impacted by this effort. I'm not sure how =
that should work in practice but want to be aware of it as/if this work pro=
gresses. 

Perhaps have a se=
ction in the document listing all existing documents that work fine with 2.=
1?

I'm honestly not s=
ure if anything is needed or not. But I do want to try and ensure that such=
 a perception problem doesn't arise. 

Perh=
aps have a small section that says more or less what I'd said above - t=
hat existing extensions and profiles of RFC 6749 that use legitimate extens=
ion points still present and unchanged in OAuth 2.1 are still okay as they =
are now? And include a not-meant-to-be exhaustive list of such documents as=
 examples thereof. 
=C2=A0
=C2=A0
<snip>


"TBD" 
Given the potentially=
 high visibility of an OAuth 2.1 effort, I think it'd be worthwhile to =
list organizational affiliations of individuals here in the acknowledgement=
s along with their names. Something like what was done in the first part of=
 https://tools.ietf.org/html/draft-ietf-oaut=
h-access-token-jwt-06#appendix-A. This can help with visibility and jus=
tification of (sometimes not insignificant) time spent on the work by non-a=
uthors/editors.=C2=A0

=C2=A0Sur=
e. Are you ok with being added there?
Yes, thank you. That was sort of implicit in my suggestion but=
 perhaps I should have been explicit.=C2=A0 




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000031816905a40f5365--


From nobody Fri Apr 24 15:36:22 2020
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 B29843A0E58 for ; Fri, 24 Apr 2020 15:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.655
X-Spam-Level: 
X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoAhudvEieCm for ; Fri, 24 Apr 2020 15:36:14 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 E23AD3A0E51 for ; Fri, 24 Apr 2020 15:36:13 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id m5so2584481ilj.10 for ; Fri, 24 Apr 2020 15:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YH8TsPqHQOKE/P67OMzlpvHJJuWFaa+0xhRP2Nt8pRg=; b=SaomwN1ICdHzYBpzMSm+TZ+E9zVPcWXBlin6hQj/imbVDnUsFZgf0KeMQwLrgN8R9u YbDG5H1LojNzYF7huQHoI7ijFIoJXfbaXzv0nIr0MWgG8jLNJV5+VF07sWt4ooIz+inv RJvbp3Xx6yeeEk0dveaVHxzIXPYnM8lzu4oYfWawlDGj6rtETuCa6hS+/FKoJw8aBklO +vQY+1eZm3v4YMRhfFrWG/xBJx5xug81pI7lqaVzjMTnwo75WHbBngVwjd4XrKLzBbuW Za3ihML65lvSC9KhJq1xGOhlZXhxZwxqEobCOn/tc3t7vSCDI1uJDZD2ooVXaVkN5xA6 K4xw==
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=YH8TsPqHQOKE/P67OMzlpvHJJuWFaa+0xhRP2Nt8pRg=; b=Io9iO404Kr2M4Z/anC6QOykWHb1xDeRg8pCHcmbhXh5VbdrdneA9vZWVBjww5qL5xq J7SVqB951jk5pkrw/wnfw0vuu71R2hvp4s1AZ141QsnUO1SFpz6q+8JDRMJ99j0pT5ej XghdnwpQC4NqN+7hgtnbYVHakIGqFg+FVPnqWBHJRDFxRlZkOaSLw3yf0PtfMNYUAruP d1bCiSsrZK4i4sro8JupJMVhgSsUWP6YAvKCg0lxtQITR2jwzp+LvMO1x2l50tkvmfOI 5SmUugUeS2Th10Iv4If0A9yR4oslfHdfcBYa4VUW7wp2bFbBgZtunyxQmqjcPTmoKGpI ePVg==
X-Gm-Message-State: AGi0PuZhmFDLHswQDxBpaoN58+BasvCtupMmKc1rqCVH9VXMpar1NUkp Mc8GPJQ7qwNCF4fo7wR19K8Qts3BREI=
X-Google-Smtp-Source: APiQypIO7ILazaSsLdY4yRVc5qdVKtXAEYgJ3FZtnv2aW06eXWCD06gc5upkwrHTCKyVQY7UCGLtMQ==
X-Received: by 2002:a92:1b91:: with SMTP id f17mr10895320ill.142.1587767772329;  Fri, 24 Apr 2020 15:36:12 -0700 (PDT)
Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id k11sm2268990iom.43.2020.04.24.15.36.11 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 15:36:11 -0700 (PDT)
Received: by mail-il1-f171.google.com with SMTP id u189so10847466ilc.4 for ; Fri, 24 Apr 2020 15:36:11 -0700 (PDT)
X-Received: by 2002:a92:ddca:: with SMTP id d10mr4277456ilr.166.1587767770826;  Fri, 24 Apr 2020 15:36:10 -0700 (PDT)
MIME-Version: 1.0
References: <355609CC-D224-4437-9735-E8B603A4FE3A@mitre.org>
In-Reply-To: <355609CC-D224-4437-9735-E8B603A4FE3A@mitre.org>
From: Aaron Parecki 
Date: Fri, 24 Apr 2020 15:35:59 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "Peck, Michael A" 
Cc: OAuth WG 
Content-Type: multipart/alternative; boundary="000000000000f74e5105a410fd5e"
Archived-At: 
Subject: Re: [OAUTH-WG] First Draft of OAuth 2.1
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, 24 Apr 2020 22:36:20 -0000

--000000000000f74e5105a410fd5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the review, Mike. I've fixed the minor typos. Some other notes
below.

Section 3.1.2.1 currently retains this language from RFC 6749: =E2=80=9CThe
> redirection endpoint SHOULD require the use of TLS=E2=80=A6 This specific=
ation does
> not mandate the use of TLS because at the time of this writing, requiring
> clients to deploy TLS is a significant hurdle=E2=80=A6=E2=80=9D
> I suggest updating this text to mandate TLS, and/or a blanket statement
> should be made that TLS is required for all protocol interactions (rather
> than or in addition to the statements throughout the draft). I don't thin=
k
> "requiring clients to deploy TLS is a significant hurdle" is an accurate
> statement at the present time.


For now I've removed the "significant hurdle" sentence, since it's only a
minor hurdle these days. Whether we should/can require TLS on redirect URLs
is an interesting question and warrants some discussion. I'll bring this up
at the next meeting.

Section 1.7:
> Consider incorporating new guidance on HTTP redirects as specified in
> draft-ietf-oauth-security-topics section 4.10.


Thank you, good catch. I've updated the sentence in 1.7 to match the
security BCP disallowing HTTP 307, and added the details from section 4.10
later in the document.

Section 2.1:
> =E2=80=9CAuthorization servers SHOULD consider the level of confidence in=
 a
> client=E2=80=99s identity when deciding whether they allow such a client =
access to
> more critical functions, such as the client credentials grant type.=E2=80=
=9D
> The client credentials example possibly conflicts with the section 4.2
> statement =E2=80=9CThe client credentials grant MUST only be used by conf=
idential
> clients=E2=80=9D and the statement earlier in section 2.1 =E2=80=9CClient=
s requiring a
> higher level of confidence=E2=80=A6use credentials to authenticate with t=
he
> authorization server.=E2=80=9D


Others can correct me if I'm wrong, but I feel like this text is okay,
since the use of a client secret doesn't necessarily correlate with
confidence in client identity. For example if a client uses dynamic client
registration to get a client ID and secret, the AS doesn't really have any
assurance of that client's identity if the registration request was made
without authentication itself.

Section 2.3.1:
> (This text is in RFC 6749 too)
> client_secret =E2=80=93 =E2=80=9CREQUIRED=E2=80=A6The client MAY omit the=
 parameter if the client
> secret is an empty string.=E2=80=9D
> Since this section describes authentication using a password by
> confidential clients, it doesn=E2=80=99t make sense that the client secre=
t would be
> an empty string?


I agree this doesn't make much sense, I will take out "The client MAY omit
the parameter if the client secret is an empty string." unless there are
any objections.

Section 2.3.2:
> =E2=80=9CMAY support any suitable HTTP authentication scheme=E2=80=9D =E2=
=80=93 should the word
> =E2=80=9CHTTP=E2=80=9D be removed as being too specific? I don=E2=80=99t =
think methods such as mTLS
> and private_key_jwt are HTTP authentication schemes?


Agreed, removing "HTTP" sounds better.

Section 3.1.2.2:
> =E2=80=9CThe authorization server SHOULD require the client to provide th=
e
> complete redirection URI=E2=80=9D -
> Given the section 3.1.2 requirement to compare redirect URIs using =E2=80=
=9Csimple
> string comparison=E2=80=9D, should that instead be a MUST?


Yes, thanks, with the requirement of exact redirect URI matching this is
required.

Section 3.1.2.3:
> Consider removing the second paragraph, it looks redundant given the new
> section 3.1.2 requirement for =E2=80=9Csimple string comparison=E2=80=9D.


Agreed, it looks like this section refers to things that would only be
possible with partial redirect URI registration/matching.

Section 3.2.1:
> =E2=80=9Can unauthenticated client MUST sent its =E2=80=9Cclient_id=E2=80=
=9D=E2=80=A6[t]his protects the
> client from substitution of the authentication code.=E2=80=9D:
> =E2=80=9Cauthentication code=E2=80=9D should be =E2=80=9Cauthorization co=
de=E2=80=9D (typo also present in
> RFC 6749), also I don=E2=80=99t think this is true anymore with the requi=
rement to
> use PKCE? However it=E2=80=99s probably still a good requirement, since e=
xplicitly
> identifying the client may make it easier for the AS to look up whether t=
he
> authorization code is valid?


We don't want to change the behavior from OAuth 2.0 here, so whether the
client_id parameter is required shouldn't change, but I can remove the
language about authorization code substitution because PKCE is a better
solution. In fact, this whole paragraph is redundant, since the access
token request already requires public clients send the client_id parameter
and PKCE protects against authorization code substitution.

Section 4.1:
> =E2=80=9CThe client includes its =E2=80=A6 requested scope, local state =
=E2=80=A6=E2=80=9D Consider
> indicating that requested scope and local state are optional?


Sure, thanks.

Section 4.1.1.1:
> (I guess this is more of an RFC 7636 question since the text comes from
> there.)
> Why is the entropy requirement for the PKCE code verifier only SHOULD /
> RECOMMENDED rather than MUST?


Good question. Is this worth bringing up in the context of the Security BCP
as well?


----
Aaron Parecki
aaronparecki.com
@aaronpk 



On Thu, Mar 12, 2020 at 7:00 AM Peck, Michael A  wrote:

> This looks like a great initial draft, and I hope to see it move forward.
>
> Some comments so far:
>
> Section 1.6:
> =E2=80=9CAt the time of this writing=E2=80=9D is duplicated.
>
> Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 /
> 3.2 that mandate TLS):
> Section 3.1.2.1 currently retains this language from RFC 6749: =E2=80=9CT=
he
> redirection endpoint SHOULD require the use of TLS=E2=80=A6 This specific=
ation does
> not mandate the use of TLS because at the time of this writing, requiring
> clients to deploy TLS is a significant hurdle=E2=80=A6=E2=80=9D
> I suggest updating this text to mandate TLS, and/or a blanket statement
> should be made that TLS is required for all protocol interactions (rather
> than or in addition to the statements throughout the draft). I don't thin=
k
> "requiring clients to deploy TLS is a significant hurdle" is an accurate
> statement at the present time.
>
> Section 1.7:
> Consider incorporating new guidance on HTTP redirects as specified in
> draft-ietf-oauth-security-topics section 4.10.
>
> Section 1.8 / 2 / 3.1 / 3.2:
> Consider including informative references to RFC 7591 (Dynamic Client
> Registration) and RFC 8414 (OAuth 2.0 Authorization Server Metadata) as
> optional methods that may be useful for client registration, determining =
AS
> capabilities, and endpoint discovery.
>
> Section 2.1:
> =E2=80=9CAuthorization servers SHOULD consider the level of confidence in=
 a
> client=E2=80=99s identity when deciding whether they allow such a client =
access to
> more critical functions, such as the client credentials grant type.=E2=80=
=9D
> The client credentials example possibly conflicts with the section 4.2
> statement =E2=80=9CThe client credentials grant MUST only be used by conf=
idential
> clients=E2=80=9D and the statement earlier in section 2.1 =E2=80=9CClient=
s requiring a
> higher level of confidence=E2=80=A6use credentials to authenticate with t=
he
> authorization server.=E2=80=9D
>
> Section 2.3.1:
> (This text is in RFC 6749 too)
> client_secret =E2=80=93 =E2=80=9CREQUIRED=E2=80=A6The client MAY omit the=
 parameter if the client
> secret is an empty string.=E2=80=9D
> Since this section describes authentication using a password by
> confidential clients, it doesn=E2=80=99t make sense that the client secre=
t would be
> an empty string?
> (Certainly there may be situations where a client_id but not a
> client_secret would be sent =E2=80=93 e.g. public clients, or if the clie=
nt
> authenticates another way --  but that=E2=80=99d be out of scope of what =
section
> 2.3.1 is describing?)
>
> Section 2.3.2:
> =E2=80=9CMAY support any suitable HTTP authentication scheme=E2=80=9D =E2=
=80=93 should the word
> =E2=80=9CHTTP=E2=80=9D be removed as being too specific? I don=E2=80=99t =
think methods such as mTLS
> and private_key_jwt are HTTP authentication schemes?
>
> Section 3.1.2.2:
> =E2=80=9CThe authorization server SHOULD require the client to provide th=
e
> complete redirection URI=E2=80=9D -
> Given the section 3.1.2 requirement to compare redirect URIs using =E2=80=
=9Csimple
> string comparison=E2=80=9D, should that instead be a MUST?
>
> Section 3.1.2.3:
> Consider removing the second paragraph, it looks redundant given the new
> section 3.1.2 requirement for =E2=80=9Csimple string comparison=E2=80=9D.
>
> Section 3.2.1:
> =E2=80=9Can unauthenticated client MUST sent its =E2=80=9Cclient_id=E2=80=
=9D=E2=80=A6[t]his protects the
> client from substitution of the authentication code.=E2=80=9D:
>
> =E2=80=9Cauthentication code=E2=80=9D should be =E2=80=9Cauthorization co=
de=E2=80=9D (typo also present in
> RFC 6749), also I don=E2=80=99t think this is true anymore with the requi=
rement to
> use PKCE? However it=E2=80=99s probably still a good requirement, since e=
xplicitly
> identifying the client may make it easier for the AS to look up whether t=
he
> authorization code is valid?
>
> Section 4.1:
> =E2=80=9CThe client includes its =E2=80=A6 requested scope, local state =
=E2=80=A6=E2=80=9D Consider
> indicating that requested scope and local state are optional?
>
> Section 4.1.1.1:
> (I guess this is more of an RFC 7636 question since the text comes from
> there.)
> Why is the entropy requirement for the PKCE code verifier only SHOULD /
> RECOMMENDED rather than MUST?
>
> Section 9.7:
> (Already pointed out by Pieter this morning.)
> Typo: RFC8418 should be RFC8414.
>
> Thanks,
> Mike
>
> =EF=BB=BFOn 3/11/20, 8:29 PM, "OAuth on behalf of Aaron Parecki" <
> oauth-bounces@ietf.org on behalf of aaron@parecki.com> wrote:
>
>     I'm happy to share that Dick and Torsten and I have published a first
>     draft of OAuth 2.1. We've taken the feedback from the discussions on
>     the list and incorporated that into the draft.
>
>     https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>
>     A summary of the differences between this draft and OAuth 2.0 can be
>     found in section 12, and I've copied them here below.
>
>     > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>     > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>     > (RFC7636), OAuth 2.0 for Browser-Based Apps
>     > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>     > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>     > (RFC6750).
>     >
>     >   Where a later draft updates or obsoletes functionality found in t=
he
>     >   original [RFC6749], that functionality in this draft is updated
> with
>     >   the normative changes described in a later draft, or removed
>     >   entirely.
>     >
>     >   A non-normative list of changes from OAuth 2.0 is listed below:
>     >
>     >   *  The authorization code grant is extended with the functionalit=
y
>     >      from PKCE ([RFC7636]) such that the only method of using the
>     >      authorization code grant according to this specification
> requires
>     >      the addition of the PKCE mechanism
>     >
>     >   *  Redirect URIs must be compared using exact string matching as
> per
>     >      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>     >
>     >   *  The Implicit grant ("response_type=3Dtoken") is omitted from t=
his
>     >      specification as per Section 2.1.2 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  The Resource Owner Password Credentials grant is omitted from
> this
>     >      specification as per Section 2.4 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  Bearer token usage omits the use of bearer tokens in the query
>     >      string of URIs as per Section 4.3.2 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  Refresh tokens must either be sender-constrained or one-time u=
se
>     >      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
>
>     https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
>
>     I'm excited for the direction this is taking, and it has been a
>     pleasure working with Dick and Torsten on this so far. My hope is tha=
t
>     this first draft can serve as a good starting point for our future
>     discussions!
>
>     ----
>     Aaron Parecki
>     aaronparecki.com
>     @aaronpk
>
>     P.S. This notice was also posted at
>     https://aaronparecki.com/2020/03/11/14/oauth-2-1
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--000000000000f74e5105a410fd5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the review, Mike. I've fix=
ed the minor typos. Some other notes below.

Section 3.1.2.1 currently retains thi=
s language from RFC 6749: =E2=80=9CThe redirection endpoint SHOULD require =
the use of TLS=E2=80=A6 This specification does not mandate the use of TLS =
because at the time of this writing, requiring clients to deploy TLS is a s=
ignificant hurdle=E2=80=A6=E2=80=9D

I suggest updating this text to mandate TLS, and/or a blanket statement sho=
uld be made that TLS is required for all protocol interactions (rather than=
 or in addition to the statements throughout the draft). I don't think =
"requiring clients to deploy TLS is a significant hurdle" is an a=
ccurate statement at the present time.

For =
now I've removed the "significant hurdle" sentence, since it&=
#39;s only a minor hurdle these days. Whether we should/can require TLS on =
redirect URLs is an interesting question and warrants some discussion. I=
9;ll bring this up at the next meeting.

Section 1.7:

Consider incorporating new guidance on HTTP redirects as specified in draft=
-ietf-oauth-security-topics section 4.10.

T=
hank you, good catch. I've updated the sentence in 1.7 to match the sec=
urity BCP disallowing HTTP 307, and added the details from section 4.10 lat=
er in the document.

Section 2.1:

=E2=80=9CAuthorization servers SHOULD consider the level of confidence in a=
 client=E2=80=99s identity when deciding whether they allow such a client a=
ccess to more critical functions, such as the client credentials grant type=
.=E2=80=9D

The client credentials example possibly conflicts with the section 4.2 stat=
ement =E2=80=9CThe client credentials grant MUST only be used by confidenti=
al clients=E2=80=9D and the statement earlier in section 2.1 =E2=80=9CClien=
ts requiring a higher level of confidence=E2=80=A6use credentials to authen=
ticate with the authorization server.=E2=80=9D

<=
div>Others can correct me if I'm wrong, but I feel like this text is ok=
ay, since the use of a client secret doesn't necessarily correlate with=
 confidence in client identity. For example if a client uses dynamic client=
 registration to get a client ID and secret, the AS doesn't really have=
 any assurance of that client's identity if the registration request wa=
s made without authentication itself.=C2=A0

Section 2.3.1:

(This text is in RFC 6749 too)

client_secret =E2=80=93 =E2=80=9CREQUIRED=E2=80=A6The client MAY omit the p=
arameter if the client secret is an empty string.=E2=80=9D

Since this section describes authentication using a password by confidentia=
l clients, it doesn=E2=80=99t make sense that the client secret would be an=
 empty string?

I agree this doesn't mak=
e much sense, I will take out "The client MAY omit the parameter if th=
e client secret is an empty string." unless there are any objections.<=
/div>

Secti=
on 2.3.2:

=E2=80=9CMAY support any suitable HTTP authentication scheme=E2=80=9D =E2=
=80=93 should the word =E2=80=9CHTTP=E2=80=9D be removed as being too speci=
fic? I don=E2=80=99t think methods such as mTLS and private_key_jwt are HTT=
P authentication schemes?

Agreed, removing =
"HTTP" sounds better.

Section 3.1.2.2:<=
br>=E2=80=9CThe authorization server SHOULD require the client to provide t=
he complete redirection URI=E2=80=9D -
Given the section 3.1.2 requireme=
nt to compare redirect URIs using =E2=80=9Csimple string comparison=E2=80=
=9D, should that instead be a MUST?

Yes, th=
anks, with the requirement of exact redirect URI matching this is required.=


Sect=
ion 3.1.2.3=
:

Consider removing the second paragraph, it looks redundant given the new se=
ction 3.1.2 requirement for =E2=80=9Csimple string comparison=E2=80=9D.

Agreed, it looks like this section refers to t=
hings that would only be possible with partial redirect URI registration/ma=
tching.

Section 3.2.1:

=E2=80=9Can unauthenticated client MUST sent its =E2=80=9Cclient_id=E2=80=
=9D=E2=80=A6[t]his protects the client from substitution of the authenticat=
ion code.=E2=80=9D:

=E2=80=9Cauthentication code=E2=80=9D should be =E2=80=9Cauthorization code=
=E2=80=9D (typo also present in RFC 6749), also I don=E2=80=99t think this =
is true anymore with the requirement to use PKCE? However it=E2=80=99s prob=
ably still a good requirement, since explicitly identifying the client may =
make it easier for the AS to look up whether the authorization code is vali=
d?



We don't want to change the behavior from OAuth 2.0 here=
, so whether the client_id parameter is required shouldn't change, but =
I can remove the language about authorization code substitution because PKC=
E is a better solution. In fact, this whole paragraph is redundant, since t=
he access token request already requires public clients send the client_id =
parameter and PKCE protects against authorization code substitution.
<=
div>
Section 4.1=
:

=E2=80=9CThe client includes its =E2=80=A6 requested scope, local state =E2=
=80=A6=E2=80=9D Consider indicating that requested scope and local state ar=
e optional?

Sure, thanks.

Section 4.1.1.1:

(I guess this is more of an RFC 7636 question since the text comes from the=
re.)

Why is the entropy requirement for the PKCE code verifier only SHOULD / REC=
OMMENDED rather than MUST?

Good question. I=
s this worth bringing up in the context of the Security BCP as well?
<=
div>

----
Aaron Pare=
cki


On Thu, =
Mar 12, 2020 at 7:00 AM Peck, Michael A <mpeck@mitre.org> wrote:
This looks like a great initial draft, and I hope to see=
 it move forward.



Some comments so far:



Section 1.6:

=E2=80=9CAt the time of this writing=E2=80=9D is duplicated.



Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 / 3.=
2 that mandate TLS):

Section 3.1.2.1 currently retains this language from RFC 6749: =E2=80=9CThe=
 redirection endpoint SHOULD require the use of TLS=E2=80=A6 This specifica=
tion does not mandate the use of TLS because at the time of this writing, r=
equiring clients to deploy TLS is a significant hurdle=E2=80=A6=E2=80=9D
I suggest updating this text to mandate TLS, and/or a blanket statement sho=
uld be made that TLS is required for all protocol interactions (rather than=
 or in addition to the statements throughout the draft). I don't think =
"requiring clients to deploy TLS is a significant hurdle" is an a=
ccurate statement at the present time.



Section 1.7:

Consider incorporating new guidance on HTTP redirects as specified in draft=
-ietf-oauth-security-topics section 4.10.



Section 1.8 / 2 / 3.1 / 3.2:

Consider including informative references to RFC 7591 (Dynamic Client Regis=
tration) and RFC 8414 (OAuth 2.0 Authorization Server Metadata) as optional=
 methods that may be useful for client registration, determining AS capabil=
ities, and endpoint discovery.



Section 2.1:

=E2=80=9CAuthorization servers SHOULD consider the level of confidence in a=
 client=E2=80=99s identity when deciding whether they allow such a client a=
ccess to more critical functions, such as the client credentials grant type=
.=E2=80=9D

The client credentials example possibly conflicts with the section 4.2 stat=
ement =E2=80=9CThe client credentials grant MUST only be used by confidenti=
al clients=E2=80=9D and the statement earlier in section 2.1 =E2=80=9CClien=
ts requiring a higher level of confidence=E2=80=A6use credentials to authen=
ticate with the authorization server.=E2=80=9D



Section 2.3.1:

(This text is in RFC 6749 too)

client_secret =E2=80=93 =E2=80=9CREQUIRED=E2=80=A6The client MAY omit the p=
arameter if the client secret is an empty string.=E2=80=9D

Since this section describes authentication using a password by confidentia=
l clients, it doesn=E2=80=99t make sense that the client secret would be an=
 empty string?

(Certainly there may be situations where a client_id but not a client_secre=
t would be sent =E2=80=93 e.g. public clients, or if the client authenticat=
es another way --=C2=A0 but that=E2=80=99d be out of scope of what section =
2.3.1 is describing?)



Section 2.3.2:

=E2=80=9CMAY support any suitable HTTP authentication scheme=E2=80=9D =E2=
=80=93 should the word =E2=80=9CHTTP=E2=80=9D be removed as being too speci=
fic? I don=E2=80=99t think methods such as mTLS and private_key_jwt are HTT=
P authentication schemes?



Section 3.1=
.2.2:

=E2=80=9CThe authorization server SHOULD require the client to provide the =
complete redirection URI=E2=80=9D -

Given the section 3.1.2 requirement to compare redirect URIs using =E2=80=
=9Csimple string comparison=E2=80=9D, should that instead be a MUST?



Section 3.1=
.2.3:

Consider removing the second paragraph, it looks redundant given the new se=
ction 3.1.2 requirement for =E2=80=9Csimple string comparison=E2=80=9D.



Section 3.2.1:

=E2=80=9Can unauthenticated client MUST sent its =E2=80=9Cclient_id=E2=80=
=9D=E2=80=A6[t]his protects the client from substitution of the authenticat=
ion code.=E2=80=9D:



=E2=80=9Cauthentication code=E2=80=9D should be =E2=80=9Cauthorization code=
=E2=80=9D (typo also present in RFC 6749), also I don=E2=80=99t think this =
is true anymore with the requirement to use PKCE? However it=E2=80=99s prob=
ably still a good requirement, since explicitly identifying the client may =
make it easier for the AS to look up whether the authorization code is vali=
d?



Section 4.1:

=E2=80=9CThe client includes its =E2=80=A6 requested scope, local state =E2=
=80=A6=E2=80=9D Consider indicating that requested scope and local state ar=
e optional?



Section 4.1=
.1.1:

(I guess this is more of an RFC 7636 question since the text comes from the=
re.)

Why is the entropy requirement for the PKCE code verifier only SHOULD / REC=
OMMENDED rather than MUST?



Section 9.7:

(Already pointed out by Pieter this morning.)

Typo: RFC8418 should be RFC8414.



Thanks,

Mike



=EF=BB=BFOn 3/11/20, 8:29 PM, "OAuth on behalf of Aaron Parecki" =
<oauth-bounc=
es@ietf.org on behalf of aaron@parecki.com> wrote:



=C2=A0 =C2=A0 I'm happy to share that Dick and Torsten and I have publi=
shed a first

=C2=A0 =C2=A0 draft of OAuth 2.1. We've taken the feedback from the dis=
cussions on

=C2=A0 =C2=A0 the list and incorporated that into the draft.



=C2=A0 =C2=A0 https://tools.ietf.org/html/dra=
ft-parecki-oauth-v2-1-01



=C2=A0 =C2=A0 A summary of the differences between this draft and OAuth 2.0=
 can be

=C2=A0 =C2=A0 found in section 12, and I've copied them here below.



=C2=A0 =C2=A0 > This draft consolidates the functionality in OAuth 2.0 (=
RFC6749),

=C2=A0 =C2=A0 > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code =
Exchange

=C2=A0 =C2=A0 > (RFC7636), OAuth 2.0 for Browser-Based Apps

=C2=A0 =C2=A0 > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best=
 Current

=C2=A0 =C2=A0 > Practice (I-D.ietf-oauth-security-topics), and Bearer To=
ken Usage

=C2=A0 =C2=A0 > (RFC6750).

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0Where a later draft updates or obsoletes fun=
ctionality found in the

=C2=A0 =C2=A0 >=C2=A0 =C2=A0original [RFC6749], that functionality in th=
is draft is updated with

=C2=A0 =C2=A0 >=C2=A0 =C2=A0the normative changes described in a later d=
raft, or removed

=C2=A0 =C2=A0 >=C2=A0 =C2=A0entirely.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0A non-normative list of changes from OAuth 2=
.0 is listed below:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 The authorization code grant is exte=
nded with the functionality

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 from PKCE ([RFC7636]) such that the =
only method of using the

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 authorization code grant according t=
o this specification requires

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 the addition of the PKCE mechanism
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 Redirect URIs must be compared using=
 exact string matching as per

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 Section 4.1.3 of [I-D.ietf-oauth-sec=
urity-topics]

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 The Implicit grant ("response_t=
ype=3Dtoken") is omitted from this

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 specification as per Section 2.1.2 o=
f

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-oauth-security-topics]

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 The Resource Owner Password Credenti=
als grant is omitted from this

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 specification as per Section 2.4 of<=
br>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-oauth-security-topics]

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 Bearer token usage omits the use of =
bearer tokens in the query

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 string of URIs as per Section 4.3.2 =
of

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-oauth-security-topics]

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0*=C2=A0 Refresh tokens must either be sender=
-constrained or one-time use

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 as per Section 4.12.2 of [I-D.ietf-o=
auth-security-topics]



=C2=A0 =C2=A0 https://tools.ietf.o=
rg/html/draft-parecki-oauth-v2-1-01#section-12



=C2=A0 =C2=A0 I'm excited for the direction this is taking, and it has =
been a

=C2=A0 =C2=A0 pleasure working with Dick and Torsten on this so far. My hop=
e is that

=C2=A0 =C2=A0 this first draft can serve as a good starting point for our f=
uture

=C2=A0 =C2=A0 discussions!



=C2=A0 =C2=A0 ----

=C2=A0 =C2=A0 Aaron Parecki

=C2=A0 =C2=A0 aaronparecki.com

=C2=A0 =C2=A0 @aaronpk



=C2=A0 =C2=A0 P.S. This notice was also posted at

=C2=A0 =C2=A0 https://aaronparecki.com/2020/03/11/14=
/oauth-2-1



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 OAuth mailing list

=C2=A0 =C2=A0 OAuth@iet=
f.org

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oau=
th








--000000000000f74e5105a410fd5e--


From nobody Fri Apr 24 15:49:33 2020
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 720EA3A0F1B for ; Fri, 24 Apr 2020 15:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh-Lp5hxpYVj for ; Fri, 24 Apr 2020 15:49:23 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 1096A3A0ED9 for ; Fri, 24 Apr 2020 15:49:22 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id k12so4092372wmj.3 for ; Fri, 24 Apr 2020 15:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3wEZRdOXUVkF9/+M1DIHG0P9tcIz6stkQK3XLmQZIas=; b=1akmH1N63gy9VDgk2kxrDbuL5ijepBRpDcFHY2Oy0gXnc1XR3vGU0YYJFpYRfhs8sa d2Y6Sm+t4d3vZTC12TcRjnu5fHhRjlK0jG5/ca0NgBFlBnsqfpR5KMVUeAnRxaY4NPyp g54z5PF3DcW+3ApcBUGd7dNYn6mZhf7iQ/TutI2oxjY0OzvbOy3tnUlLVkFwu4YB8s7T +h+Wg7ZRUm6iniKhOT5JZchpGoFcBaL633tQiUYE+lPoE1T9gyEb7VRgJPs1uv4gnle3 dxXsPn7BNjvZDOQjLJ1b14hh97gNao9bG8sV0DNIHqnRzAwIemmtb6z3FUHQAPYSC7v3 4TKw==
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=3wEZRdOXUVkF9/+M1DIHG0P9tcIz6stkQK3XLmQZIas=; b=FUdhmLLEW9lKDYr7gPYVhvc94UpfGKpGmNqQGmaPkuDyCcTewqfZekUSfN1gyFSszL LHKs8F3xHDlmroCCnEDcg92XnNmfs768Yi0rjM59gojFIutoegiaIY1lVGPT9aeyqG/K FzP3RTqTqWKYGnOQDlhcblFbn5MH7hNCxDb+CFk9LY6DSsNcuGGHpmBrtvNz9LE9IFHq gpyCirinOdS1VInMYvFTGdE7G7udWsadxCZpYSFAq3+D/UjTUc4LBWxqW/AOGAFyLYQO VlYJkrJM2jsIFQUow9G9qLBS7x/Aqo6idvzpD2SUVGHaEvOjphBM6L1LUhwUPNCYziLw ARkw==
X-Gm-Message-State: AGi0PuZR2unfYGoULe/BPMILrhEOEnyyL3+rALs8lNeNYT+YjWuIGH8s HUMf6Lneg04yiy3ckbnG9aYUADtsgQBEslfZLcCcVA==
X-Google-Smtp-Source: APiQypLEGZCdxmHXimwAJA+xFjXtGTOQm87nACvnvdCABFlQsWEO4+df8hpQ9U/Vh4bHfC2KbAp3ULBu//6rzKNkCIA=
X-Received: by 2002:a7b:c941:: with SMTP id i1mr11815961wml.132.1587768561231;  Fri, 24 Apr 2020 15:49:21 -0700 (PDT)
MIME-Version: 1.0
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>       
In-Reply-To: 
From: Takahiko Kawasaki 
Date: Sat, 25 Apr 2020 07:49:09 +0900
Message-ID: 
To: Vittorio Bertocci 
Cc: oauth ,  Vittorio Bertocci 
Content-Type: multipart/alternative; boundary="0000000000001401a605a4112d57"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 24 Apr 2020 22:49:32 -0000

--0000000000001401a605a4112d57
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Vittorio,

I apologize. To me, the requirements on "aud" and "sub" sounded too strange
and the logic to deny counter proposals sounded unnaturally unconvincing,
too. They made me suspicious, and unfortunately and accidentally, my
subsequent observation matched my doubt, and it made me feel I should bring
it here with a kind of sense of justice, but I was a way too stupid. I
wanted to discuss the requirements purely technically by removing politics,
which I thought existed but did not exist actually. The ironic result was
that my previous post itself was politics. I stop making comments to the
spec.

I'm sorry for my tweets. Because they have been copied to here in an
unremovable way, allow me to remove them from Twitter to reflect my conduct=
.

I'm sorry for having cast doubt although I've actually respected you since
long before without your knowing. Hopefully, I want mercy from you and the
community in spite of my conduct.

Takahiko

On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci <
vittorio.bertocci@auth0.com> wrote:

> Takahiro,
>
> Before I acknowledge your comments, I would like to clarify some importan=
t
> points.
>
> Your first email, and various tweets you published contextually (
> https://twitter.com/darutk/status/1253375039681884160), suggest that with
> my work on the spec I am driving some hidden agenda for my company, and y=
ou
> are exposing this thanks to some findings you uncovered- and that the WG
> somehow missed.
> This is of course nonsense, insulting to my own professional integrity an=
d
> to the intelligence of the chairs, working group and everyone who
> participated in the discussion. I include the tweets in the discussion
> because you included in them a link to the mailing list archives, hence
> involving the WG in the process.
>
>
>
> Some basic facts:
>
>    - The profile as it exists today does NOT work out of the box with
>    Auth0, there are several things that would need to change in the produ=
ct
>    for that to happen- including adding support for resource indicators w=
hich
>    is currently missing
>    - The layout of the Auth0 token is certainly not a secret, given that
>    it was presented alongside all the other tokens obtained from other ve=
ndors
>    at the OSW2019 in March, in the initial draft pitch at IETF104 as reco=
rded
>    in
>    https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-se=
ssa-jwt-profile-for-access-token-00,
>    in the first discussion at IETF105 as shown in
>    https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-se=
ssa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02-00.
>    The use of resource indicators for client cred flows is certainly not =
a
>    dark ploy to smuggle the Auth0 way, in fact it=E2=80=99s informed more=
 by my work
>    on Azure AD- where I found the transition from pseudo resource indicat=
ors
>    to scopes to be riddled by challenges. Once again, all discussions wer=
e
>    made in full transparency.
>    - The concerns about symmetric algorithms being allowed, which you are
>    oddly bringing up in a tweet rather than on the list, are disconnected=
 from
>    the discussion: people in the working group explicitly asked for symme=
tric
>    to be an option and even to relax the current language to be more
>    permissive, which I gently pushed back against. Again, not an obscure =
ploy.
>
>
>
> I am saddened that you chose to make those statements on twitter. There
> was nothing for you to discover, everything was already out in the open.
>
> You might want to consider retracting your accusations. I am not worried
> about myself, my conscience is perfectly clean and the IETF process recor=
ds
> back me up, but by suggesting lack of transparency you are unfairly
> portraying the IETF, standardization process and the people who do their
> best to check at the door their affiliations and contribute their time an=
d
> expertise for the benefit of the industry as a whole.
>
>
>
> I am adding the tweets here for reference, together with the translation
> Twitter provided.
>
>
>
> Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect
>
> @darutk
>
> =E3=82=82=E3=81=97=E3=82=84=E3=81=A8=E6=80=9D=E3=81=A3=E3=81=A6=E8=AA=BF=
=E3=81=B9=E3=81=A6=E3=81=BF=E3=81=9F=E3=82=89=E3=80=81Auth0=EF=BC=88=E3=82=
=B9=E3=83=9A=E3=83=83=E3=82=AF=E3=83=AA=E3=83=BC=E3=83=89=E3=81=AE=E6=89=80=
=E5=B1=9E=E4=BC=81=E6=A5=AD=EF=BC=89=E3=81=AE client_credentials =E3=83=95=
=E3=83=AD=E3=83=BC=E3=81=AE=E5=AE=9F=E8=A3=85=E3=81=AF audience=EF=BC=88RFC
> 8707 =E3=81=AE resource =E7=9B=B8=E5=BD=93=EF=BC=89=E3=81=8C=E5=BF=85=E9=
=A0=88=E3=81=A7=E3=80=81=E7=94=9F=E6=88=90=E3=81=99=E3=82=8B JWT =E3=82=A2=
=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E3=81=AE su=
b =E3=81=AB=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88 ID =E3=82=
=92=E5=9F=8B=E3=82=81=E8=BE=BC=E3=82=80=E3=80=82JWT
> =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=
=E4=BB=95=E6=A7=98=E3=83=89=E3=83=A9=E3=83=95=E3=83=88=E3=81=8C=E6=AD=AA=E3=
=82=93=E3=81=A7=E3=81=84=E3=82=8B=E3=81=AE=E3=81=AF=E3=81=93=E3=82=8C=E3=81=
=8C=E7=90=86=E7=94=B1=E3=81=A0=E3=82=8D=E3=81=86=E3=80=82
>
> Suddenly, I searched and thought, implementation of client_credentials
> flow of Auth0 (company of Spec Lead) requires audience (equivalent to
> resource of RFC 8707), and embed client ID in sub of generated JWT access
> token. This is probably the reason why the JWT access token specification
> draft is distorted.
>
>
>
> =E5=85=83=E3=80=85 Auth0 =E3=81=AE=E7=8F=BE=E5=AE=9F=E8=A3=85=E3=82=92=E6=
=A5=AD=E7=95=8C=E3=81=AB=E8=AA=8D=E3=82=81=E3=81=95=E3=81=9B=E3=82=8B=E3=81=
=9F=E3=82=81=E3=81=AB JWT
> =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=
=E6=A8=99=E6=BA=96=E4=BB=95=E6=A7=98=E7=AD=96=E5=AE=9A=E4=BD=9C=E6=A5=AD=E3=
=81=8C=E9=96=8B=E5=A7=8B=E3=81=95=E3=82=8C=E3=81=9F=E3=81=A8=E5=99=82=E3=81=
=A7=E3=81=AF=E8=81=9E=E3=81=84=E3=81=A6=E3=81=84=E3=81=9F=E3=81=8C=E3=80=81=
=E5=AE=9F=E9=9A=9B=E3=81=AB=E3=81=9D=E3=81=86=E3=81=A0=E3=81=A3=E3=81=9F=E3=
=81=8B=E3=80=82=E6=8A=80=E8=A1=93=E7=9A=84=E3=81=AB=E4=B8=8D=E8=87=AA=E7=84=
=B6=E3=81=AA=E7=82=B9=E3=81=8C=E5=A4=9A=E3=81=84=E3=81=97=E8=A3=8F=E4=BA=8B=
=E6=83=85=E3=81=8C=E3=81=AF=E3=81=A3=E3=81=8D=E3=82=8A=E3=81=97=E3=81=9F=E4=
=BB=8A=E3=81=A8=E3=81=AA=E3=81=A3=E3=81=A6=E3=81=AF=E9=BB=99=E3=81=A3=E3=81=
=A6=E3=81=84=E3=82=8B=E8=A8=B3=E3=81=AB=E3=82=82=E3=81=84=E3=81=8B=E3=81=AA=
=E3=81=84=E3=81=AE=E3=81=A7=E3=80=81=E3=83=A1=E3=83=BC=E3=83=AA=E3=83=B3=E3=
=82=B0=E3=83=AA=E3=82=B9=E3=83=88=E3=81=A7=E6=84=8F=E8=A6=8B=E3=82=92=E8=BF=
=B0=E3=81=B9=E3=81=9F=E3=80=82
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/
>
> I've heard rumors that the JWT Access Token standard specification work
> was started to get the industry to accept the current implementation of
> Auth0, but was that really the case? Since there are many technical
> unnatural points and it is impossible to keep silent now that the
> circumstances are clear, I made an opinion on the mailing list.
>
>
>
> =E3=81=A4=E3=81=84=E3=81=A7=E3=81=AB=E8=A8=80=E3=81=A3=E3=81=A6=E3=81=8A=
=E3=81=8F=E3=81=A8=E3=80=81Auth0 =E3=81=8C=E7=94=9F=E6=88=90=E3=81=99=E3=82=
=8B JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=
=83=B3=E3=81=AE=E7=BD=B2=E5=90=8D=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=
=BA=E3=83=A0=E3=81=A8=E3=81=97=E3=81=A6=E9=81=B8=E6=8A=9E=E3=81=A7=E3=81=8D=
=E3=82=8B=E3=81=AE=E3=81=AF=E3=80=81HS256 =E3=81=A8 RS256
> =E3=81=AE=E3=81=BF=E3=81=AE=E3=82=88=E3=81=86=E3=81=A0=E3=80=82HS256 =E3=
=81=AF=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=
=AA=E3=82=BA=E3=83=A0=E3=80=82=E4=B8=80=E6=96=B9=E3=81=AE RS256 =E3=81=AF=
=E9=9D=9E=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=
=83=AA=E3=82=BA=E3=83=A0=E3=81=A0=E3=81=8C=E3=80=81=E3=82=BB=E3=82=AD=E3=83=
=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=BC=E4=B8=8A=E3=81=AE=E7=90=86=E7=94=B1=
=E3=81=A7
> Financial-grade API Part 2 =E3=81=A7=E3=81=AF=E4=BD=BF=E7=94=A8=E7=A6=81=
=E6=AD=A2=E3=81=A8=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E3=80=82
>
> Incidentally, it seems that only HS256 and RS256 can be selected as the
> signature algorithm for the JWT access token generated by Auth0. HS256 is=
 a
> symmetric key algorithm. On the other hand, RS256 is an asymmetric key
> algorithm, but for security reasons, it is prohibited in Financial-grade
> API Part 2.
>
>
>
>
>
> *From: *OAuth  on behalf of Takahiko Kawasaki <
> taka@authlete.com>
> *Date: *Thursday, April 23, 2020 at 18:01
> *To: *oauth 
> *Cc: *Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> I apologize if my previous post has made you all here feel unpleasant,
> especially I'm sorry for the author, the chairs, and people who directly
> joined the discussion about the spec. I could have expressed my
> disagreement on the requirements for "aud" and "sub" in another different
> way. For software specifications and architectures, I'm liable to get
> excited and aggressive. Please forgive me.
>
> Regarding the relationship between "aud" and "scope", the assumption in
> the draft is not necessarily applicable to all possible use cases. For
> example, multiple resources may share the same scopes. What if both
> "/resource1" and "/resource2" recognize "get" scope and "update" scope? I=
n
> this case, it is not appropriate to determine the default resource
> indicator for "aud" from the scopes. It is also impossible to map scopes =
to
> resources and vice versa. The assumption in the current draft is too narr=
ow
> to be included in a standard.. If the current description continues to
> exist, it will impose big restrictions on the design of scopes and
> resources.
>
> If you still think the "aud" claim should always exist, then the
> authorization endpoint and/or the token endpoint (and/or the backchannel
> authentication endpoint and/or the device authorization endpoint) of your
> system can require the "resource" request parameter as mandatory. We don'=
t
> have to put rules to determine the default "aud" value into the spec abou=
t
> JWT access tokens. The "resource" parameter defined in RFC 8707 can work
> regardless of whether the format of access tokens is JWT or not. Therefor=
e,
> it is not appropriate to discuss the necessity of the "aud" claim only in
> the context of "JWT" access tokens.
>
> Regarding the "sub" claim, setting the client ID there, rather, will
> confuse resource servers. If the "sub" claim is set even in the case of t=
he
> client credentials flow, resource servers cannot judge whether the "sub"
> claim represents either the subject of the resource owner or the client I=
D.
> On the other hand, if the "sub" claim is null or absent in the case of th=
e
> client credentials flow, resource servers can always handle the value of
> the "sub" claim as the subject of the resource owner. For resource server=
s,
> this logic is easier. Setting the "sub" claim in every case to make
> resource server implementations simpler is not convincing.
>
> Best Regards,
> Taka
>
>
>
> On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki 
> wrote:
>
> First, to make the discussion fair, I think I should share what I observe=
d
> today. Auth0's client_credentials flow requires an "audience" parameter,
> which is equivalent to the "resource" parameter defined in RFC 8707, and
> embeds the client ID in the generated JWT access token as the value of th=
e
> "sub" claim.
>
> My opinion as a software engineer is as follows.
>
> [aud]
> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> inflexible rules to determine the default value for the "aud" claim based
> on the "scope" parameter.
>
> [sub]
> The "sub" claim should be null or absent when a resource owner is not
> involved in an authorization request. To be concrete, the "sub" claim
> should be null or absent in the client credentials flow. The spec draft
> says in "5. Security Considerations" as follows.
>
> - - - - - - - - - -
> Authorization servers should prevent scenarios where clients can affect
> the value of the sub claim in ways that could confuse resource servers.
> For example: if the authorization server elects to use the client_id as t=
he
> sub value for access tokens issued client credentials grant, the
> authorization server should prevent clients to register an arbitrary
> client_id value, as this would allow malicious clients to select the sub =
of
> a high privilege resource owner and confuse any authorization logic on th=
e
> resource server relying on the sub value.  For more details please refer =
to
> section 4.13 of [OAuth2.Security.BestPractices].
>
> To preventing cross-JWT confusion, authorization servers MUST use a
> distinct identifier as "aud" claim value to uniquely identify access toke=
ns
> issued by the same issuer for distinct resources.
> - - - - - - - - - -
>
> However, the attack vector is brought about merely by introducing the
> following rule defined in "2.2. Data Structure".
>
> - - - - - - - - - -
> In case of access tokens obtained through grants where no resource owner
> is involved, such as the client credentials grant, the value of sub SHOUL=
D
> correspond to an identifier the authorization server uses to indicate the
> client application.
> - - - - - - - - - -
>
> If the rule is not introduced, the attack vector disappears and the "aud"
> claim doesn't have to be mandatory.
>
> Finally, to make the discussion fair, I should also mention that I myself
> is a co-founder of Authlete, Inc. that provides an implementation of OAut=
h
> and OpenID Connect. My thoughts about implementations of access tokens ar=
e
> publicly described here:
>
> OAuth Access Token Implementation
> https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
> On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci  40auth0.com@dmarc.ietf.org> wrote:
>
> Ouch! Sorry =F0=9F=98=8A fixed
>
>
>
> *From: *Dominick Baier 
> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth , Rifaat Shekh-Yusef ,
> Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Oh and while we are at it - could you also fix the typo in my name? Thank=
s
> ;)
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
> vittorio.bertocci@auth0.com) wrote:
>
> This is a great point. In my head I just considered the OIDC semantic and
> thought only of highlighting the app identity case, but you are absolutel=
y
> right that not mentioning the user case at all is confusing. I added the
> language you suggested at the beginning of the sub definition.
>
> Thanks!
>
>
>
> *From: *Dominick Baier 
> *Date: *Monday, April 20, 2020 at 22:54
> *To: *oauth , Rifaat Shekh-Yusef ,
> "vittorio.bertocci@auth0.com" 
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> In case of access tokens obtained through grants where no resource owner =
is involved, such as the client credentials grant, the value of sub SHOULD =
correspond to an identifier the authorization server uses to indicate the c=
lient application.
>
>
>
> Maybe I am missing something, but does it say anywhere what to explicitly
> do in the case of an access token where a resource owner is involved?
>
>
>
> There=E2=80=99s some language that seems to imply that, e.g.:
>
>
>
> as this would allow malicious
>
>    clients to select the sub of a high privilege resource owner
>
> I would have expected to see something stronger like above just -
>
>
>
> In case of access tokens obtained through grants where a resource owner i=
s involved, such as the authorisation code grant, the value of sub SHOULD c=
orrespond to the subject identifier of the resource owner.
>
>
>
> If this spec is about interop, I think this should be at least a
> recommendation...
>
>
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com
>  (vittorio.bertocci@auth0.com) wrote:
>
> Thanks Dominick for your comments!
>
> Inline
>
>
>
> *>** All other OAuth specs make a very clear distinction between users
> and client.*
>
> There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In previ=
ous
> discussions on this topic it has been brought up that the JWT spec define=
s
> sub as identifying the principal that is the subject of the JWT, and that=
=E2=80=99s
> not necessarily limited to users.
>
> However I get the potential confusion, and I am happy to add clarifying l=
anguage if you have specific passages in the space you are particularly wor=
ried about: however I feel the matter is addressed upfront by the language =
in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtaine=
d through grants where no resource owner is involved, such as the client cr=
edentials grant, the value of sub SHOULD correspond to an identifier the au=
thorization server uses to indicate the client application.=E2=80=9C and Se=
ction 5 has an entire paragraph discussing things to watch out in assigning=
 sub values in the app identity case. Feel free to suggest additional langu=
age if you want to clarify further.
>
>
>
> *> sub has a different semantic here as in OIDC*
>
> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
> OIDC, to preempt that concern and keep the original sub semantic availabl=
e.
>
>
>
> *>** I am not fully clear why aud is required.*
>
> Aud is there mostly because of three reasons:
>
> =C2=B7         Many existing specs postulate its existence in the token. =
No
> one declares it as a proper MUST (apart from the BCP, but that=E2=80=99s =
partial)
> however I think its importance comes across..
> -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
> mechanism to prevent token redirect (and adds scope restriction as also
> important, however here we make it optional to acocut for non-delegations
> scenario).
> -Resource indicators RFC8707 refers to the same section of RFC7519 as one
> of the assumptions that must hold to prevent bearer tokens misuse
> -BCP225 makes aud mandatory for AS which can issue JWTs for more than one
> app
>
> =C2=B7         Apart from Ping, for which some of its examples are withou=
t aud
> (but also without identifying scopes, given that the one I retrieved had
> only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from=
 vendors all
> featured an aud. I know one shoulnd=E2=80=99t overindex on those examples=
, but
> together with the above it seemed to point to something universally usefu=
l.
> One possible reason is that use of a format for the AT is correlated with
> topologies where AS and RS are separated by some boundary (network,
> logical, business, code factoring, etc) hence identifying the resource
> seems like a natural need. Again, not an iron clad law, but an indication=
.
>
> =C2=B7         A lot of people repurpose existing libraries for the JWT A=
T
> case, and some people even sends id_tokens in lieu of ATs. That doesn=E2=
=80=99t
> mean that we should condone any bad practices, but in tis particular case
> it suggests that lots of developers already expect/can handle an audience
> in the JWT used to call their API
>
> None of those are a slam dunk argument for mandatory, but I find them
> compelling enough to simplify validation and just require an aud to be
> there, as opposed to introduce complications that make it conditional to
> the presence of scopes or other disambiguation.. One reason I feel pretty
> good about that is that adding a default audience isn=E2=80=99t very hard=
 if any of
> the above assumptions end up not being true for a particular case
>
>
>
> *> What=E2=80=99s the rationale for using iat instead of nbf. *
>
> That=E2=80=99s just straight from OIDC ID_tokens, and the considerations =
about
> repurposing existing logic. I see there=E2=80=99s a thread on this specif=
ically,
> let me answer further on that branch.
>
>
>
> *> This spec feels somehow in between a profile and a BCP*
>
> You are right that this spec attempts to go beyond just declaring a
> layout, and I agree this means that this profile will not apply to
> absolutely everyone. The reason I tried that route (at the cost of workin=
g
> way harder in the last year for reaching consensus than if we would have
> just listed the possible content), is that I often observe implementers
> make questionable choices because of the large leeway specifications allo=
w.
> My hope was that the scope of this profile was small enough to make that
> extra level of guidance achievable, whereas trying to do the same with a
> larger spec would have been prohibitively expensive.
>
> I believe things worked out well so far: we had lots of constructive
> discussions, and I ended up relaxing A LOT of the constraints I was
> originally envisioning. Nonetheless, my hope is that we identified the
> right set of guidelines that will help people actually interoperate out o=
f
> the box for the most basic/common scenarios, as opposed to complying with
> the letter of the spec but still having a lot to figure out out of band.
>
>
>
> *From:* OAuth  *On Behalf Of *Dominick Baier
> *Sent:* Thursday, April 16, 2020 12:10 AM
> *To:* Rifaat Shekh-Yusef ; oauth 
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Since this is the last call, I thought I bring up some of thoughts /
> concerns. Some of them have been discussed before.
>
>
>
> *client_id vs sub*
>
> I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of =
the claim types
> based on flow.
>
> If the intention is, that sub expresses the entity against which the
> resource will do authorisation (and that might be a client or a user) - I
> get it (and maybe it should be stated like that) - but
>
> this thinking reminds me of the old AD days where there was no distinctio=
n
> between user and service accounts (something that has been fixed IIRC in
> Windows Server 2012 R2).
>
>
>
> All other OAuth specs make a very clear distinction between users and
> client.
>
>
>
> Furthermore it says
>
>
>
> "Authorization servers should prevent scenarios where clients can
>
>    affect the value of the sub claim in ways that could confuse resource
>
>    servers.=E2=80=9D
>
>
>
> If we keep that dual semantics of the sub claim - it must be clearly
> stated, that subject ID and client ID are now in the same collision domai=
n.
> So when an AS / OP creates them, they need to be unique across user ids a=
nd
> client ids.
>
>
>
> Maybe it should be also explicitly mentioned that sub has a different
> semantic here as in OIDC - even though a majority of the software built
> today will use them together.
>
>
>
> *audience claim*
>
> I am not fully clear why aud is required. OAuth itself does not have a
> notion of an audience (in the JWT sense) - they have scopes (which is ver=
y
> similar). But in simple scenarios where resources don=E2=80=99t exist, yo=
u'd need
> to make up an audience just to fulfil this requirement. And in many case
> this will be either static or just repeat the scope values. What=E2=80=99=
s the
> value of that?
>
>
>
> If the concept of resources are used, I absolutely agree that aud should
> be used too. But I wouldn=E2=80=99t make it required.
>
>
>
> *iat vs nbf*
>
> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t=
 most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?
>
>
>
> *General*
>
> This spec feels somehow in between a profile and a BCP. On one hand you
> define some claims and their semantics (good) - on the other hand there i=
s
> some prescriptive guidance and maybe over-specification. My concern is,
> that in the end no-one will fully comply with it, because it doesn=E2=80=
=99t work
> one way or the other for them.
>
>
>
> I know we just went though the discussion to make certain claims required
> as opposed to optional - but maybe less is more.
>
>
>
> Tbh - the most valuable part of the doc to me is the definition of the
> =E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see=
 just some standard claims
> and IF they are used, which semantics they have.
>
>
>
> cheers
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
> wrote:
>
> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profil=
e
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> _______________________________________________
> 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
>
>

--0000000000001401a605a4112d57
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear Vittorio,

I apologize. To me, the requirements=
 on "aud" and "sub" sounded too strange and the logic t=
o deny counter proposals sounded unnaturally unconvincing, too. They made m=
e suspicious, and unfortunately and accidentally, my subsequent observation=
 matched my doubt, and it made me feel I should bring it here with a kind o=
f sense of justice, but I was a way too stupid. I wanted to discuss the req=
uirements purely technically by removing politics, which I thought existed =
but did not exist actually. The ironic result was that my previous post its=
elf was politics. I stop making comments to the spec.

I'm sorry =
for my tweets. Because they have been copied to here in an unremovable way,=
 allow me to remove them from Twitter to reflect my conduct.

I'm=
 sorry for having cast doubt although I've actually respected you since=
 long before without your knowing. Hopefully, I want mercy from you and the=
 community in spite of my conduct.

Takahiko

On Sat, Apr 25, 2020=
 at 5:24 AM Vittorio Bertocci <vittorio.bertocci@auth0.com> wrote:











Takahiro,


Before I acknowledge your comments, I would like to =
clarify some important points.


Your first email, and various tweets you published c=
ontextually (https://twitter.com/darutk/status/1253375039681884160=
), suggest that with my work on the spec I am driving
 some hidden agenda for my company, and you are exposing this thanks to som=
e findings you uncovered- and that the WG somehow missed.

This is of course nonsense, insulting to my own professional integrity and =
to the intelligence of the chairs, working group and everyone who participa=
ted in the discussion. I include the tweets in the discussion because you i=
ncluded in them a link to the mailing
 list archives, hence involving the WG in the process.


=C2=A0


Some basic facts:


    

  • 
The profile as it exists today does NOT work=
 out of the box with Auth0, there are several things that would need to cha=
nge in the product for that to happen- including adding support for resourc=
e indicators which is currently
 missing
  • 
The layout of the Auth0 token is certainly n=
ot a secret, given that it was presented alongside all the other tokens obt=
ained from other vendors at the OSW2019 in March, in the initial draft pitc=
h at IETF104 as recorded in
https://datatracker.ietf.org/meeting/104/materials/=
slides-104-oauth-sessa-jwt-profile-for-access-token-00,
 in the first discussion at IETF105 as shown in 
https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-j=
son-web-token-jwt-profile-for-oauth-20-access-tokens-02-00. The use of =
resource indicators for client cred flows is certainly not a dark ploy to s=
muggle the Auth0 way, in fact it=E2=80=99s
 informed more by my work on Azure AD- where I found the transition from ps=
eudo resource indicators to scopes to be riddled by challenges. Once again,=
 all discussions were made in full transparency.
    • <=
li class=3D"gmail-m_68019837002168231MsoListParagraphCxSpLast" style=3D"mar=
gin-left:0in">
The concerns about symmetric algorithms bein=
g allowed, which you are oddly bringing up in a tweet rather than on the li=
st, are disconnected from the discussion: people in the working group expli=
citly asked for symmetric to be
 an option and even to relax the current language to be more permissive, wh=
ich I gently pushed back against. Again, not an obscure ploy.=



=C2=A0


I am saddened that you chose to make those statement=
s on twitter. There was nothing for you to discover, everything was already=
 out in the open.



You might want to consider retracting your accusatio=
ns. I am not worried about myself, my conscience is perfectly clean and the=
 IETF process records back me up, but by suggesting lack of transparency yo=
u are unfairly portraying the IETF,
 standardization process and the people who do their best to check at the d=
oor their affiliations and contribute their time and expertise for the bene=
fit of the industry as a whole.


=C2=A0


I am adding the tweets here for reference, together =
with the translation Twitter provided.


=C2=A0


Taka@Authlete, BaaS for OAuth 2.0 & OpenID Conne=
ct


@darutk


=
=E3=82=82=E3=81=97=E3=82=84=E3=81=A8=E6=80=9D=E3=81=A3=E3=81=A6=E8=AA=BF=E3=
=81=B9=E3=81=A6=E3=81=BF=E3=81=9F=E3=82=89=E3=80=81Auth0=EF=BC=88=E3=82=B9=E3=83=9A=E3=83=83=
=E3=82=AF=E3=83=AA=E3=83=BC=E3=83=89=E3=81=AE=E6=89=80=E5=B1=9E=E4=BC=81=E6=
=A5=AD=EF=BC=89=E3=81=AE client_credentials
=E3=83=95=E3=83=AD=E3=83=
=BC=E3=81=AE=E5=AE=9F=E8=A3=85=E3=81=AF audience=EF=BC=88RFC 8707
=E3=81=AE resource=
 
=E7=9B=B8=E5=BD=93=EF=BC=89=E3=81=8C=E5=BF=85=E9=A0=88=E3=81=A7=E3=80=81=E7=
=94=9F=E6=88=90=E3=81=99=E3=82=8B JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=
=E3=82=AF=E3=83=B3=E3=81=AE sub
=E3=81=AB=E3=82=AF=E3=83=
=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88 ID 
=E3=82=92=E5=9F=8B=E3=82=81=E8=BE=BC=E3=82=80=E3=80=82JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=
=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E4=BB=95=E6=A7=98=E3=83=89=E3=83=A9=
=E3=83=95=E3=83=88=E3=81=8C=E6=AD=AA=E3=82=93=E3=81=A7=E3=81=84=E3=82=8B=E3=
=81=AE=E3=81=AF=E3=81=93=E3=82=8C=E3=81=8C=E7=90=86=E7=94=B1=E3=81=A0=E3=82=
=8D=E3=81=86=E3=80=82


Suddenly, I searched and thought, implementation of =
client_credentials flow of Auth0 (company of Spec Lead) requires audience (=
equivalent to resource of RFC 8707), and embed client ID in sub of generate=
d JWT access token. This is probably
 the reason why the JWT access token specification draft is distorted.


=C2=A0


=
=E5=85=83=E3=80=85 Auth0 
=E3=81=AE=E7=8F=BE=E5=AE=9F=E8=A3=85=E3=82=92=E6=A5=AD=E7=95=8C=E3=81=AB=E8=
=AA=8D=E3=82=81=E3=81=95=E3=81=9B=E3=82=8B=E3=81=9F=E3=82=81=E3=81=AB JWT =E3=82=A2=E3=82=AF=
=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E6=A8=99=E6=BA=96=E4=
=BB=95=E6=A7=98=E7=AD=96=E5=AE=9A=E4=BD=9C=E6=A5=AD=E3=81=8C=E9=96=8B=E5=A7=
=8B=E3=81=95=E3=82=8C=E3=81=9F=E3=81=A8=E5=99=82=E3=81=A7=E3=81=AF=E8=81=9E=
=E3=81=84=E3=81=A6=E3=81=84=E3=81=9F=E3=81=8C=E3=80=81=E5=AE=9F=E9=9A=9B=E3=
=81=AB=E3=81=9D=E3=81=86=E3=81=A0=E3=81=A3=E3=81=9F=E3=81=8B=E3=80=82=E6=8A=
=80=E8=A1=93=E7=9A=84=E3=81=AB=E4=B8=8D=E8=87=AA=E7=84=B6=E3=81=AA=E7=82=B9=
=E3=81=8C=E5=A4=9A=E3=81=84=E3=81=97=E8=A3=8F=E4=BA=8B=E6=83=85=E3=81=8C=E3=
=81=AF=E3=81=A3=E3=81=8D=E3=82=8A=E3=81=97=E3=81=9F=E4=BB=8A=E3=81=A8=E3=81=
=AA=E3=81=A3=E3=81=A6=E3=81=AF=E9=BB=99=E3=81=A3=E3=81=A6=E3=81=84=E3=82=8B=
=E8=A8=B3=E3=81=AB=E3=82=82=E3=81=84=E3=81=8B=E3=81=AA=E3=81=84=E3=81=AE=E3=
=81=A7=E3=80=81=E3=83=A1=E3=83=BC=E3=83=AA=E3=83=B3=E3=82=B0=E3=83=AA=E3=82=
=B9=E3=83=88=E3=81=A7=E6=84=8F=E8=A6=8B=E3=82=92=E8=BF=B0=E3=81=B9=E3=81=9F=
=E3=80=82


=C2=A0


https://mailarchive.ietf=
.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/


I've heard rumors that the JWT Access Token stan=
dard specification work was started to get the industry to accept the curre=
nt implementation of Auth0, but was that really the case? Since there are m=
any technical unnatural points and it
 is impossible to keep silent now that the circumstances are clear, I made =
an opinion on the mailing list.


=C2=A0


=
=E3=81=A4=E3=81=84=E3=81=A7=E3=81=AB=E8=A8=80=E3=81=A3=E3=81=A6=E3=81=8A=E3=
=81=8F=E3=81=A8=E3=80=81Auth0
=E3=81=8C=E7=94=9F=E6=88=
=90=E3=81=99=E3=82=8B JWT 
=E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E3=
=81=AE=E7=BD=B2=E5=90=8D=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=BA=E3=83=
=A0=E3=81=A8=E3=81=97=E3=81=A6=E9=81=B8=E6=8A=9E=E3=81=A7=E3=81=8D=E3=82=8B=
=E3=81=AE=E3=81=AF=E3=80=81HS256 =E3=81=A8 RS256
=E3=81=AE=E3=81=BF=E3=81=
=AE=E3=82=88=E3=81=86=E3=81=A0=E3=80=82HS256 
=E3=81=AF=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=
=83=AA=E3=82=BA=E3=83=A0=E3=80=82=E4=B8=80=E6=96=B9=E3=81=AE RS256 <=
span style=3D"font-family:"MS Gothic"">=E3=81=AF=E9=9D=9E=E5=AF=
=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=BA=
=E3=83=A0=E3=81=A0=E3=81=8C=E3=80=81=E3=82=BB=E3=82=AD=E3=83=A5=E3=83=AA=E3=
=83=86=E3=82=A3=E3=83=BC=E4=B8=8A=E3=81=AE=E7=90=86=E7=94=B1=E3=81=A7 Financial-grade API Part 2
=E3=81=A7=E3=81=AF=E4=BD=
=BF=E7=94=A8=E7=A6=81=E6=AD=A2=E3=81=A8=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E3=80=82


Incidentally, it seems that only HS256 and RS256 can=
 be selected as the signature algorithm for the JWT access token generated =
by Auth0. HS256 is a symmetric key algorithm. On the other hand, RS256 is a=
n asymmetric key algorithm, but for
 security reasons, it is prohibited in Financial-grade API Part 2.


=C2=A0


=C2=A0




From: =
OAuth <oauth-bounces@ietf.org=
> on behalf of Takahiko Kawasaki <taka@authlete.com>

Date: Thursday, April 23, 2020 at 18:01

To: oauth <oa=
uth@ietf.org>

Cc: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>=
;

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






I apologize if my previous post has made you all her=
e feel unpleasant, especially I'm sorry for the author, the chairs, and=
 people who directly joined the discussion about the spec. I could have exp=
ressed my disagreement on the requirements
 for "aud" and "sub" in another different way. For soft=
ware specifications and architectures, I'm liable to get excited and ag=
gressive. Please forgive me.



Regarding the relationship between "aud" and "scope", t=
he assumption in the draft is not necessarily applicable to all possible us=
e cases. For example, multiple resources may share the same scopes. What if=
 both "/resource1" and "/resource2" recognize "get=
"
 scope and "update" scope? In this case, it is not appropriate to=
 determine the default resource indicator for "aud" from the scop=
es. It is also impossible to map scopes to resources and vice versa. The as=
sumption in the current draft is too narrow to be included
 in a standard.. If the current description continues to exist, it will imp=
ose big restrictions on the design of scopes and resources.



If you still think the "aud" claim should always exist, then the =
authorization endpoint and/or the token endpoint (and/or the backchannel au=
thentication endpoint and/or the device authorization endpoint) of your sys=
tem can require the "resource" request parameter
 as mandatory. We don't have to put rules to determine the default &quo=
t;aud" value into the spec about JWT access tokens. The "resource=
" parameter defined in RFC 8707 can work regardless of whether the for=
mat of access tokens is JWT or not. Therefore, it is not
 appropriate to discuss the necessity of the "aud" claim only in =
the context of "JWT" access tokens.



Regarding the "sub" claim, setting the client ID there, rather, w=
ill confuse resource servers. If the "sub" claim is set even in t=
he case of the client credentials flow, resource servers cannot judge wheth=
er the "sub" claim represents either the subject of
 the resource owner or the client ID. On the other hand, if the "sub&q=
uot; claim is null or absent in the case of the client credentials flow, re=
source servers can always handle the value of the "sub" claim as =
the subject of the resource owner. For resource servers,
 this logic is easier. Setting the "sub" claim in every case to m=
ake resource server implementations simpler is not convincing.




Best Regards,

Taka




=C2=A0






On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki &l=
t;taka@authlete.com<=
/a>> wrote:








First, to make the discussion fair, I think I should=
 share what I observed today. Auth0's client_credentials flow requires =
an "audience" parameter, which is equivalent to the "resourc=
e" parameter defined in RFC 8707, and embeds the client
 ID in the generated JWT access token as the value of the "sub" c=
laim.



My opinion as a software engineer is as follows.



[aud]

The "aud" claim should be null or absent when the "resource&=
quot; parameters are not given in an authorization request. It is not good =
to introduce inflexible rules to determine the default value for the "=
aud" claim based on the "scope" parameter.



[sub]

The "sub" claim should be null or absent when a resource owner is=
 not involved in an authorization request. To be concrete, the "sub&qu=
ot; claim should be null or absent in the client credentials flow. The spec=
 draft says in "5. Security Considerations" as follows.



- - - - - - - - - -

Authorization servers should prevent scenarios where clients can affect the=
 value of the sub claim in ways that could confuse resource servers.=C2=A0 =
For example: if the authorization server elects to use the client_id as the=
 sub value for access tokens issued client
 credentials grant, the authorization server should prevent clients to regi=
ster an arbitrary client_id value, as this would allow malicious clients to=
 select the sub of a high privilege resource owner and confuse any authoriz=
ation logic on the resource server
 relying on the sub value.=C2=A0 For more details please refer to section 4=
.13 of [OAuth2.Security.BestPractices].



To preventing cross-JWT confusion, authorization servers MUST use a distinc=
t identifier as "aud" claim value to uniquely identify access tok=
ens issued by the same issuer for distinct resources.

- - - - - - - - - -



However, the attack vector is brought about merely by introducing the follo=
wing rule defined in "2.2. Data Structure".



- - - - - - - - - -

In case of access tokens obtained through grants where no resource owner is=
 involved, such as the client credentials grant, the value of sub SHOULD co=
rrespond to an identifier the authorization server uses to indicate the cli=
ent application.

- - - - - - - - - -



If the rule is not introduced, the attack vector disappears and the "a=
ud" claim doesn't have to be mandatory.



Finally, to make the discussion fair, I should also mention that I myself i=
s a co-founder of Authlete, Inc. that provides an implementation of OAuth a=
nd OpenID Connect. My thoughts about implementations of access tokens are p=
ublicly described here:



OAuth Access Token Implementation

https://medium.com/@darutk/oauth-access-token-=
implementation-30c2e8b90ff0



Best Regards,

Takahiko Kawasaki

Authlete, Inc.




=C2=A0






On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci &l=
t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:










Ouch! Sorry
=F0=9F=98=8A fixed


=C2=A0




From:
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Tuesday, April 21, 2020 at 10:23

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertoc=
ci <vit=
torio.bertocci@auth0.com>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






Oh and while we are at it - could you also fix the typo in my name? Thanks=
 ;)




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 21. April 2020 at 09:43:49, Vittorio Bertocci (vittorio.bertocci@auth0.com)=
 wrote:










This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the
 user case at all is confusing. I added the language you suggested at the b=
eginning of the sub definition.


Thanks!


=C2=A0




From:
Dominick Baier <dbaier@leastpr=
ivilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "vittorio.bertocci=
@auth0.com"
 <vitto=
rio.bertocci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






In case =
of access tokens obtained through grants where no resource owner is involve=
d, such as the client credentials grant, the value of sub SHOULD correspond=
 to an identifier the authorization server uses to indicate the client appl=
ication.






=C2=A0






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






=C2=A0






There=E2=80=99s some language that seems to imply th=
at, e.g.:






=C2=A0






as this would allow malicious<=
/u>


=C2=A0=C2=A0 clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just -=C2=A0






=C2=A0






In case of access tokens obtained throu=
gh grants where a resource owner is involved, such as the authorisation cod=
e grant, the value of sub SHOULD correspond to the subject identifier of th=
e resource owner.






=C2=A0






If this spec is about interop, I think this should b=
e at least a recommendation...






=C2=A0




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 20. April 2020 at 09:48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


=C2=A0


> All other OAuth specs make a very clear distinction between=
 users and client.


There=E2=80=99s a nuance worth highlighting here: su=
b !=3D user. In previous discussions on this topic it has been brought up t=
hat the JWT spec defines sub as identifying the principal that
 is the subject of the JWT, and that=E2=80=99s not necessarily limited to u=
sers. 


However =
I get the potential confusion, and I am happy to add clarifying language if=
 you have specific passages in the space you are particularly worried about=
: however I feel the matter is addressed upfront by the language in Section=
 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained through grants where no resource =
owner is involved, such as the client credentials grant, the value of sub S=
HOULD correspond to an identifier the authorization server uses to indicate=
 the client application.=E2=80=9C and Section 5 has an entire paragra=
ph discussing things to watch out in assigning sub values in the app identi=
ty case. Feel free to suggest additional language if you want to clarify fu=
rther. 


=C2=A0


> sub has a different semantic here as in OIDC<=
/u>


The =C2=A0spec refers to RFC7519 in the sub definiti=
on in 2.2, rather than OIDC, to preempt that concern and keep the original =
sub semantic available.


=C2=A0


> I am not fully clear why aud is required.=



Aud is there mostly because of three reasons:=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Many existing specs postulate its existence in the token. No one dec=
lares it as a proper MUST (apart from the BCP, but that=E2=80=99s partial) =
however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Apart from Ping, for which some of its examples are without aud (but=
 also without identifying scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from vendor=
s all featured an aud. I know one shoulnd=E2=80=99t overindex
 on those examples, but together with the above it seemed to point to somet=
hing universally useful. One possible reason is that use of a format for th=
e AT is correlated with topologies where AS and RS are separated by some bo=
undary (network, logical, business,
 code factoring, etc) hence identifying the resource seems like a natural n=
eed. Again, not an iron clad law, but an indication.


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
A lot of people repurpose existing libraries for the JWT AT case, an=
d some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t mea=
n that we should condone any bad practices, but in tis particular case it s=
uggests that lots of developers already
 expect/can handle an audience in the JWT used to call their API<=
/u>


None of those are a slam dunk argument for mandatory=
, but I find them compelling enough to simplify validation and just require=
 an aud to be there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
.. One reason I feel pretty good about that is that adding a default audien=
ce isn=E2=80=99t very hard if any of the above assumptions end up not being=
 true for a particular case


=C2=A0


> What=E2=80=99s the rationale for using iat instead of nbf.



That=E2=80=99s just straight from OIDC ID_tokens, an=
d the considerations about repurposing existing logic. I see there=E2=80=99=
s a thread on this specifically, let me answer further on that branch.


=C2=A0


> This spec feels somehow in between a profile and a BCP<=
u>


You are right that this spec attempts to go beyond j=
ust declaring a layout, and I agree this means that this profile will not a=
pply to absolutely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots=
 of constructive discussions, and I ended up relaxing A LOT of the constrai=
nts I was originally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



=C2=A0






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0




Since this is the last call, I thought I bring up some of thoughts / conce=
rns. Some of them have been discussed before.






=C2=A0






client_id vs sub






I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of t=
he claim types based on flow.






If the intention is, that sub expresses the entity against which the resou=
rce will do authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinking reminds me of the old AD days where there was no distinction=
 between user and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






=C2=A0






All other OAuth specs make a very clear distinction between users and clie=
nt.






=C2=A0






Furthermore it says






=C2=A0






"Authorization servers should prevent scenarios where clients can






=C2=A0 =C2=A0affect the value of the sub claim in ways that could confuse =
resource






=C2=A0 =C2=A0servers.=E2=80=9D






=C2=A0






If we keep that dual semantics of the sub claim - it must be clearly state=
d, that subject ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






=C2=A0






Maybe it should be also explicitly mentioned that sub has a different sema=
ntic here as in OIDC - even though a majority of the
 software built today will use them together.






=C2=A0






audience claim






I am not fully clear why aud is required. OAuth itself does not have a not=
ion of an audience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=E2=80=99t exist, you'd need to make up an audience just to fulfil thi=
s requirement. And in many case this will be either static or just repeat t=
he scope values. What=E2=80=99s the value of that?






=C2=A0






If the concept of resources are used, I absolutely agree that aud should b=
e used too. But I wouldn=E2=80=99t make it required.





=C2=A0






iat vs nbf






What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t =
most JWT libraries (including e.g. the .NET one) looking for nbf by
 default?






=C2=A0






General






This spec feels somehow in between a profile and a BCP. On one hand you de=
fine some claims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=E2=80=99t work one way or the other for them.






=C2=A0






I know we just went though the discussion to make certain claims required =
as opposed to optional - but maybe less is more.






=C2=A0






Tbh - the most valuable part of the doc to me is the definition of the =E2=
=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see just
 some standard claims and IF they are used, which semantics they have.






=C2=A0




cheers=C2=A0




=E2=80=94=E2=80=94=E2=80=94




Dominick Baier






=C2=A0


On 15. April 2020 a=
t 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:











Hi all,



=C2=A0



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



=C2=A0



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-access-tok=
en-jwt-06



=C2=A0



Please send your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0




_______________________________________________


OAuth mailing list 

OAuth@ietf.org 

h=
ttps://www.ietf.org/mailman/listinfo/oauth





























_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

















--0000000000001401a605a4112d57--


From nobody Fri Apr 24 16:14:37 2020
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 0D8D43A0F5C for ; Fri, 24 Apr 2020 16:14:36 -0700 (PDT)
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 mv7luWqGBZkG for ; Fri, 24 Apr 2020 16:14:30 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 858E13A0F65 for ; Fri, 24 Apr 2020 16:14:30 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id v63so5536242pfb.10 for ; Fri, 24 Apr 2020 16:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=w9CnuuA1Tegcm1Ph8G4jPdmzAdSsY4OjmtLIuc+n1Zs=; b=CsXNzX2m9zspJiqHoq0m7oXkBJgga+rm/WpoOqZkeUAD7W05MV1roHw4a3jU5rcWs2 1/zNaLeIyZ5m7ktiX+r42l5Qz1T4NUXvQTy081HKOMFzG4CHczslEfUfyiLl5WNacTfx k6XAEcTUuBwUIoFWWtT/iq3pe/GOIYEdSL9VeONI08x21Ek72dqeWzkVW4S5vCQJMhkW RXnCEAca3kQBppqb+3nIFcNLaeO2SS1DSiYSQhdnpFZnXa50gBD0RNRvg7jbes6Y7TCq EboUZcpFjLcpjKexntPcmzKmYJWHdupDyicBUCqaTu9Z/sw99EqCIO5RU445+Kjh06aj 963A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=w9CnuuA1Tegcm1Ph8G4jPdmzAdSsY4OjmtLIuc+n1Zs=; b=CZbD0/L95F9JQ380drjFddfe9ZI4V3Fq5dzwMwSE2O3FiqQsSnfdnO5IBn8icFmbWs WJyt0A6xgxbbYcF53L/Pm8fP/kC5Pq5nBrkhhTZCHA5Du+Din1tmj4igwPsIhb39GMYP 05FIPBeKWHhdLjl//hb+HZA6yq2Scz3hTXGgxTYwoV/F1WIA3e/jP9YHYDU5vih4lquG onff+x7GMBAUKjnp1Nz+fW6GJRF9La5KE5h7JHJaBoEipadb9Iq7bgQAmDC/3/7OIk86 j6RVpS0djdn36P1p+w0Fs8Y3yZub2yzB/Xz6AHObhBtEfDpywCgbqgxY05GNn/cd3bux BDaA==
X-Gm-Message-State: AGi0PuYjSsxCLyqwzWYxIkiD5PK5jJSGDv+7Ty/Ors5NBTDUX7HD+XmD H5yV4sIIVAw1lgNGelO2I4/0B9YNtrw=
X-Google-Smtp-Source: APiQypJxUP4Q9G0Kn9CAgrrE0SwxfLwH1orfIQsvGVcSSdbw6beCfrCt0GEcJ+hZ7v2psYuSt4tQAw==
X-Received: by 2002:a63:5642:: with SMTP id g2mr11954365pgm.211.1587770069365;  Fri, 24 Apr 2020 16:14:29 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id r12sm5684643pgv.59.2020.04.24.16.14.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2020 16:14:28 -0700 (PDT)
From: Vittorio Bertocci 
To: Takahiko Kawasaki 
CC: oauth , Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AXd5VHlHYl9QAsOR1zdXFne9zGFp1jA2Q0Ixu8C6FICAAAcS+g==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 24 Apr 2020 23:14:27 +0000
Message-ID: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>        
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: multipart/alternative; boundary="_000_MWHPR19MB15011471BBF5E5B337463500AED00MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 24 Apr 2020 23:14:36 -0000

--_000_MWHPR19MB15011471BBF5E5B337463500AED00MWHPR19MB1501namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBUYWthaGlrbywNClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIGtpbmQgYW5kIHByb21w
dCByZXNwb25zZSwgYW5kIGZvciBoYXZpbmcgZGVsZXRlZCB0aGUgdHdlZXRzLiBXZSBhbGwgY2Fy
ZSBhIGxvdCBhYm91dCBkb2luZyB0aGUgcmlnaHQgdGhpbmcsIGFuZCBJIGZ1bGx5IHVuZGVyc3Rh
bmQgaG93IHBhc3Npb24gY2FuIHNvbWV0aW1lcyBjYXJyeSB1cyBhd2F5LiBGb3IgbWUgdGhpcyBy
ZXNvbHZlcyB0aGUgbWF0dGVyIDEwMCUuDQpUaGFua3MgYWdhaW4sDQpWLg0KDQpGcm9tOiBUYWth
aGlrbyBLYXdhc2FraSA8dGFrYUBhdXRobGV0ZS5jb20+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDI0
LCAyMDIwIGF0IDE1OjQ5DQpUbzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2Np
QGF1dGgwLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+LCBWaXR0b3JpbyBCZXJ0b2Nj
aSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAiSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJv
ZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiDQoNCkRlYXIgVml0dG9yaW8sDQoNCkkg
YXBvbG9naXplLiBUbyBtZSwgdGhlIHJlcXVpcmVtZW50cyBvbiAiYXVkIiBhbmQgInN1YiIgc291
bmRlZCB0b28gc3RyYW5nZSBhbmQgdGhlIGxvZ2ljIHRvIGRlbnkgY291bnRlciBwcm9wb3NhbHMg
c291bmRlZCB1bm5hdHVyYWxseSB1bmNvbnZpbmNpbmcsIHRvby4gVGhleSBtYWRlIG1lIHN1c3Bp
Y2lvdXMsIGFuZCB1bmZvcnR1bmF0ZWx5IGFuZCBhY2NpZGVudGFsbHksIG15IHN1YnNlcXVlbnQg
b2JzZXJ2YXRpb24gbWF0Y2hlZCBteSBkb3VidCwgYW5kIGl0IG1hZGUgbWUgZmVlbCBJIHNob3Vs
ZCBicmluZyBpdCBoZXJlIHdpdGggYSBraW5kIG9mIHNlbnNlIG9mIGp1c3RpY2UsIGJ1dCBJIHdh
cyBhIHdheSB0b28gc3R1cGlkLiBJIHdhbnRlZCB0byBkaXNjdXNzIHRoZSByZXF1aXJlbWVudHMg
cHVyZWx5IHRlY2huaWNhbGx5IGJ5IHJlbW92aW5nIHBvbGl0aWNzLCB3aGljaCBJIHRob3VnaHQg
ZXhpc3RlZCBidXQgZGlkIG5vdCBleGlzdCBhY3R1YWxseS4gVGhlIGlyb25pYyByZXN1bHQgd2Fz
IHRoYXQgbXkgcHJldmlvdXMgcG9zdCBpdHNlbGYgd2FzIHBvbGl0aWNzLiBJIHN0b3AgbWFraW5n
IGNvbW1lbnRzIHRvIHRoZSBzcGVjLg0KDQpJJ20gc29ycnkgZm9yIG15IHR3ZWV0cy4gQmVjYXVz
ZSB0aGV5IGhhdmUgYmVlbiBjb3BpZWQgdG8gaGVyZSBpbiBhbiB1bnJlbW92YWJsZSB3YXksIGFs
bG93IG1lIHRvIHJlbW92ZSB0aGVtIGZyb20gVHdpdHRlciB0byByZWZsZWN0IG15IGNvbmR1Y3Qu
DQoNCkknbSBzb3JyeSBmb3IgaGF2aW5nIGNhc3QgZG91YnQgYWx0aG91Z2ggSSd2ZSBhY3R1YWxs
eSByZXNwZWN0ZWQgeW91IHNpbmNlIGxvbmcgYmVmb3JlIHdpdGhvdXQgeW91ciBrbm93aW5nLiBI
b3BlZnVsbHksIEkgd2FudCBtZXJjeSBmcm9tIHlvdSBhbmQgdGhlIGNvbW11bml0eSBpbiBzcGl0
ZSBvZiBteSBjb25kdWN0Lg0KDQpUYWthaGlrbw0KDQpPbiBTYXQsIEFwciAyNSwgMjAyMCBhdCA1
OjI0IEFNIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFp
bHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4+IHdyb3RlOg0KVGFrYWhpcm8sDQpCZWZv
cmUgSSBhY2tub3dsZWRnZSB5b3VyIGNvbW1lbnRzLCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBz
b21lIGltcG9ydGFudCBwb2ludHMuDQpZb3VyIGZpcnN0IGVtYWlsLCBhbmQgdmFyaW91cyB0d2Vl
dHMgeW91IHB1Ymxpc2hlZCBjb250ZXh0dWFsbHkgKGh0dHBzOi8vdHdpdHRlci5jb20vZGFydXRr
L3N0YXR1cy8xMjUzMzc1MDM5NjgxODg0MTYwKSwgc3VnZ2VzdCB0aGF0IHdpdGggbXkgd29yayBv
biB0aGUgc3BlYyBJIGFtIGRyaXZpbmcgc29tZSBoaWRkZW4gYWdlbmRhIGZvciBteSBjb21wYW55
LCBhbmQgeW91IGFyZSBleHBvc2luZyB0aGlzIHRoYW5rcyB0byBzb21lIGZpbmRpbmdzIHlvdSB1
bmNvdmVyZWQtIGFuZCB0aGF0IHRoZSBXRyBzb21laG93IG1pc3NlZC4NClRoaXMgaXMgb2YgY291
cnNlIG5vbnNlbnNlLCBpbnN1bHRpbmcgdG8gbXkgb3duIHByb2Zlc3Npb25hbCBpbnRlZ3JpdHkg
YW5kIHRvIHRoZSBpbnRlbGxpZ2VuY2Ugb2YgdGhlIGNoYWlycywgd29ya2luZyBncm91cCBhbmQg
ZXZlcnlvbmUgd2hvIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lvbi4gSSBpbmNsdWRlIHRo
ZSB0d2VldHMgaW4gdGhlIGRpc2N1c3Npb24gYmVjYXVzZSB5b3UgaW5jbHVkZWQgaW4gdGhlbSBh
IGxpbmsgdG8gdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlcywgaGVuY2UgaW52b2x2aW5nIHRoZSBX
RyBpbiB0aGUgcHJvY2Vzcy4NCg0KU29tZSBiYXNpYyBmYWN0czoNCg0KICAqICAgVGhlIHByb2Zp
bGUgYXMgaXQgZXhpc3RzIHRvZGF5IGRvZXMgTk9UIHdvcmsgb3V0IG9mIHRoZSBib3ggd2l0aCBB
dXRoMCwgdGhlcmUgYXJlIHNldmVyYWwgdGhpbmdzIHRoYXQgd291bGQgbmVlZCB0byBjaGFuZ2Ug
aW4gdGhlIHByb2R1Y3QgZm9yIHRoYXQgdG8gaGFwcGVuLSBpbmNsdWRpbmcgYWRkaW5nIHN1cHBv
cnQgZm9yIHJlc291cmNlIGluZGljYXRvcnMgd2hpY2ggaXMgY3VycmVudGx5IG1pc3NpbmcNCiAg
KiAgIFRoZSBsYXlvdXQgb2YgdGhlIEF1dGgwIHRva2VuIGlzIGNlcnRhaW5seSBub3QgYSBzZWNy
ZXQsIGdpdmVuIHRoYXQgaXQgd2FzIHByZXNlbnRlZCBhbG9uZ3NpZGUgYWxsIHRoZSBvdGhlciB0
b2tlbnMgb2J0YWluZWQgZnJvbSBvdGhlciB2ZW5kb3JzIGF0IHRoZSBPU1cyMDE5IGluIE1hcmNo
LCBpbiB0aGUgaW5pdGlhbCBkcmFmdCBwaXRjaCBhdCBJRVRGMTA0IGFzIHJlY29yZGVkIGluIGh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0x
MDQtb2F1dGgtc2Vzc2Etand0LXByb2ZpbGUtZm9yLWFjY2Vzcy10b2tlbi0wMCwgaW4gdGhlIGZp
cnN0IGRpc2N1c3Npb24gYXQgSUVURjEwNSBhcyBzaG93biBpbiBodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL21lZXRpbmcvMTA1L21hdGVyaWFscy9zbGlkZXMtMTA1LW9hdXRoLXNlc3NhLWpz
b24td2ViLXRva2VuLWp3dC1wcm9maWxlLWZvci1vYXV0aC0yMC1hY2Nlc3MtdG9rZW5zLTAyLTAw
LiBUaGUgdXNlIG9mIHJlc291cmNlIGluZGljYXRvcnMgZm9yIGNsaWVudCBjcmVkIGZsb3dzIGlz
IGNlcnRhaW5seSBub3QgYSBkYXJrIHBsb3kgdG8gc211Z2dsZSB0aGUgQXV0aDAgd2F5LCBpbiBm
YWN0IGl04oCZcyBpbmZvcm1lZCBtb3JlIGJ5IG15IHdvcmsgb24gQXp1cmUgQUQtIHdoZXJlIEkg
Zm91bmQgdGhlIHRyYW5zaXRpb24gZnJvbSBwc2V1ZG8gcmVzb3VyY2UgaW5kaWNhdG9ycyB0byBz
Y29wZXMgdG8gYmUgcmlkZGxlZCBieSBjaGFsbGVuZ2VzLiBPbmNlIGFnYWluLCBhbGwgZGlzY3Vz
c2lvbnMgd2VyZSBtYWRlIGluIGZ1bGwgdHJhbnNwYXJlbmN5Lg0KICAqICAgVGhlIGNvbmNlcm5z
IGFib3V0IHN5bW1ldHJpYyBhbGdvcml0aG1zIGJlaW5nIGFsbG93ZWQsIHdoaWNoIHlvdSBhcmUg
b2RkbHkgYnJpbmdpbmcgdXAgaW4gYSB0d2VldCByYXRoZXIgdGhhbiBvbiB0aGUgbGlzdCwgYXJl
IGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBkaXNjdXNzaW9uOiBwZW9wbGUgaW4gdGhlIHdvcmtpbmcg
Z3JvdXAgZXhwbGljaXRseSBhc2tlZCBmb3Igc3ltbWV0cmljIHRvIGJlIGFuIG9wdGlvbiBhbmQg
ZXZlbiB0byByZWxheCB0aGUgY3VycmVudCBsYW5ndWFnZSB0byBiZSBtb3JlIHBlcm1pc3NpdmUs
IHdoaWNoIEkgZ2VudGx5IHB1c2hlZCBiYWNrIGFnYWluc3QuIEFnYWluLCBub3QgYW4gb2JzY3Vy
ZSBwbG95Lg0KDQpJIGFtIHNhZGRlbmVkIHRoYXQgeW91IGNob3NlIHRvIG1ha2UgdGhvc2Ugc3Rh
dGVtZW50cyBvbiB0d2l0dGVyLiBUaGVyZSB3YXMgbm90aGluZyBmb3IgeW91IHRvIGRpc2NvdmVy
LCBldmVyeXRoaW5nIHdhcyBhbHJlYWR5IG91dCBpbiB0aGUgb3Blbi4NCllvdSBtaWdodCB3YW50
IHRvIGNvbnNpZGVyIHJldHJhY3RpbmcgeW91ciBhY2N1c2F0aW9ucy4gSSBhbSBub3Qgd29ycmll
ZCBhYm91dCBteXNlbGYsIG15IGNvbnNjaWVuY2UgaXMgcGVyZmVjdGx5IGNsZWFuIGFuZCB0aGUg
SUVURiBwcm9jZXNzIHJlY29yZHMgYmFjayBtZSB1cCwgYnV0IGJ5IHN1Z2dlc3RpbmcgbGFjayBv
ZiB0cmFuc3BhcmVuY3kgeW91IGFyZSB1bmZhaXJseSBwb3J0cmF5aW5nIHRoZSBJRVRGLCBzdGFu
ZGFyZGl6YXRpb24gcHJvY2VzcyBhbmQgdGhlIHBlb3BsZSB3aG8gZG8gdGhlaXIgYmVzdCB0byBj
aGVjayBhdCB0aGUgZG9vciB0aGVpciBhZmZpbGlhdGlvbnMgYW5kIGNvbnRyaWJ1dGUgdGhlaXIg
dGltZSBhbmQgZXhwZXJ0aXNlIGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgaW5kdXN0cnkgYXMgYSB3
aG9sZS4NCg0KSSBhbSBhZGRpbmcgdGhlIHR3ZWV0cyBoZXJlIGZvciByZWZlcmVuY2UsIHRvZ2V0
aGVyIHdpdGggdGhlIHRyYW5zbGF0aW9uIFR3aXR0ZXIgcHJvdmlkZWQuDQoNClRha2FAQXV0aGxl
dGUsIEJhYVMgZm9yIE9BdXRoIDIuMCAmIE9wZW5JRCBDb25uZWN0DQpAZGFydXRrDQrjgoLjgZfj
goTjgajmgJ3jgaPjgaboqr/jgbnjgabjgb/jgZ/jgonjgIFBdXRoMO+8iOOCueODmuODg+OCr+OD
quODvOODieOBruaJgOWxnuS8gealre+8ieOBriBjbGllbnRfY3JlZGVudGlhbHMg44OV44Ot44O8
44Gu5a6f6KOF44GvIGF1ZGllbmNl77yIUkZDIDg3MDcg44GuIHJlc291cmNlIOebuOW9k++8ieOB
jOW/hemgiOOBp+OAgeeUn+aIkOOBmeOCiyBKV1Qg44Ki44Kv44K744K544OI44O844Kv44Oz44Gu
IHN1YiDjgavjgq/jg6njgqTjgqLjg7Pjg4ggSUQg44KS5Z+L44KB6L6844KA44CCSldUIOOCouOC
r+OCu+OCueODiOODvOOCr+ODs+S7leanmOODieODqeODleODiOOBjOatquOCk+OBp+OBhOOCi+OB
ruOBr+OBk+OCjOOBjOeQhueUseOBoOOCjeOBhuOAgg0KU3VkZGVubHksIEkgc2VhcmNoZWQgYW5k
IHRob3VnaHQsIGltcGxlbWVudGF0aW9uIG9mIGNsaWVudF9jcmVkZW50aWFscyBmbG93IG9mIEF1
dGgwIChjb21wYW55IG9mIFNwZWMgTGVhZCkgcmVxdWlyZXMgYXVkaWVuY2UgKGVxdWl2YWxlbnQg
dG8gcmVzb3VyY2Ugb2YgUkZDIDg3MDcpLCBhbmQgZW1iZWQgY2xpZW50IElEIGluIHN1YiBvZiBn
ZW5lcmF0ZWQgSldUIGFjY2VzcyB0b2tlbi4gVGhpcyBpcyBwcm9iYWJseSB0aGUgcmVhc29uIHdo
eSB0aGUgSldUIGFjY2VzcyB0b2tlbiBzcGVjaWZpY2F0aW9uIGRyYWZ0IGlzIGRpc3RvcnRlZC4N
Cg0K5YWD44CFIEF1dGgwIOOBruePvuWun+ijheOCkualreeVjOOBq+iqjeOCgeOBleOBm+OCi+OB
n+OCgeOBqyBKV1Qg44Ki44Kv44K744K544OI44O844Kv44Oz5qiZ5rqW5LuV5qeY562W5a6a5L2c
5qWt44GM6ZaL5aeL44GV44KM44Gf44Go5ZmC44Gn44Gv6IGe44GE44Gm44GE44Gf44GM44CB5a6f
6Zqb44Gr44Gd44GG44Gg44Gj44Gf44GL44CC5oqA6KGT55qE44Gr5LiN6Ieq54S244Gq54K544GM
5aSa44GE44GX6KOP5LqL5oOF44GM44Gv44Gj44GN44KK44GX44Gf5LuK44Go44Gq44Gj44Gm44Gv
6buZ44Gj44Gm44GE44KL6Kiz44Gr44KC44GE44GL44Gq44GE44Gu44Gn44CB44Oh44O844Oq44Oz
44Kw44Oq44K544OI44Gn5oSP6KaL44KS6L+w44G544Gf44CCDQoNCmh0dHBzOi8vbWFpbGFyY2hp
dmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvSnkxZnBhcjZMS25OWF96cG9UN19mcEN6QlNnLw0K
SSd2ZSBoZWFyZCBydW1vcnMgdGhhdCB0aGUgSldUIEFjY2VzcyBUb2tlbiBzdGFuZGFyZCBzcGVj
aWZpY2F0aW9uIHdvcmsgd2FzIHN0YXJ0ZWQgdG8gZ2V0IHRoZSBpbmR1c3RyeSB0byBhY2NlcHQg
dGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgQXV0aDAsIGJ1dCB3YXMgdGhhdCByZWFsbHkg
dGhlIGNhc2U/IFNpbmNlIHRoZXJlIGFyZSBtYW55IHRlY2huaWNhbCB1bm5hdHVyYWwgcG9pbnRz
IGFuZCBpdCBpcyBpbXBvc3NpYmxlIHRvIGtlZXAgc2lsZW50IG5vdyB0aGF0IHRoZSBjaXJjdW1z
dGFuY2VzIGFyZSBjbGVhciwgSSBtYWRlIGFuIG9waW5pb24gb24gdGhlIG1haWxpbmcgbGlzdC4N
Cg0K44Gk44GE44Gn44Gr6KiA44Gj44Gm44GK44GP44Go44CBQXV0aDAg44GM55Sf5oiQ44GZ44KL
IEpXVCDjgqLjgq/jgrvjgrnjg4jjg7zjgq/jg7Pjga7nvbLlkI3jgqLjg6vjgrTjg6rjgrrjg6Dj
gajjgZfjgabpgbjmip7jgafjgY3jgovjga7jga/jgIFIUzI1NiDjgaggUlMyNTYg44Gu44G/44Gu
44KI44GG44Gg44CCSFMyNTYg44Gv5a++56ew6Y2157O744Ki44Or44K044Oq44K644Og44CC5LiA
5pa544GuIFJTMjU2IOOBr+mdnuWvvuensOmNteezu+OCouODq+OCtOODquOCuuODoOOBoOOBjOOA
geOCu+OCreODpeODquODhuOCo+ODvOS4iuOBrueQhueUseOBpyBGaW5hbmNpYWwtZ3JhZGUgQVBJ
IFBhcnQgMiDjgafjga/kvb/nlKjnpoHmraLjgajjgZXjgozjgabjgYTjgovjgIINCkluY2lkZW50
YWxseSwgaXQgc2VlbXMgdGhhdCBvbmx5IEhTMjU2IGFuZCBSUzI1NiBjYW4gYmUgc2VsZWN0ZWQg
YXMgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gZm9yIHRoZSBKV1QgYWNjZXNzIHRva2VuIGdlbmVy
YXRlZCBieSBBdXRoMC4gSFMyNTYgaXMgYSBzeW1tZXRyaWMga2V5IGFsZ29yaXRobS4gT24gdGhl
IG90aGVyIGhhbmQsIFJTMjU2IGlzIGFuIGFzeW1tZXRyaWMga2V5IGFsZ29yaXRobSwgYnV0IGZv
ciBzZWN1cml0eSByZWFzb25zLCBpdCBpcyBwcm9oaWJpdGVkIGluIEZpbmFuY2lhbC1ncmFkZSBB
UEkgUGFydCAyLg0KDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFRha2FoaWtvIEthd2FzYWtp
IDx0YWthQGF1dGhsZXRlLmNvbTxtYWlsdG86dGFrYUBhdXRobGV0ZS5jb20+Pg0KRGF0ZTogVGh1
cnNkYXksIEFwcmlsIDIzLCAyMDIwIGF0IDE4OjAxDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3Jn
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpDYzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlv
LmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBk
bWFyYy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAi
SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMi
DQoNCkkgYXBvbG9naXplIGlmIG15IHByZXZpb3VzIHBvc3QgaGFzIG1hZGUgeW91IGFsbCBoZXJl
IGZlZWwgdW5wbGVhc2FudCwgZXNwZWNpYWxseSBJJ20gc29ycnkgZm9yIHRoZSBhdXRob3IsIHRo
ZSBjaGFpcnMsIGFuZCBwZW9wbGUgd2hvIGRpcmVjdGx5IGpvaW5lZCB0aGUgZGlzY3Vzc2lvbiBh
Ym91dCB0aGUgc3BlYy4gSSBjb3VsZCBoYXZlIGV4cHJlc3NlZCBteSBkaXNhZ3JlZW1lbnQgb24g
dGhlIHJlcXVpcmVtZW50cyBmb3IgImF1ZCIgYW5kICJzdWIiIGluIGFub3RoZXIgZGlmZmVyZW50
IHdheS4gRm9yIHNvZnR3YXJlIHNwZWNpZmljYXRpb25zIGFuZCBhcmNoaXRlY3R1cmVzLCBJJ20g
bGlhYmxlIHRvIGdldCBleGNpdGVkIGFuZCBhZ2dyZXNzaXZlLiBQbGVhc2UgZm9yZ2l2ZSBtZS4N
Cg0KUmVnYXJkaW5nIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiAiYXVkIiBhbmQgInNjb3BlIiwg
dGhlIGFzc3VtcHRpb24gaW4gdGhlIGRyYWZ0IGlzIG5vdCBuZWNlc3NhcmlseSBhcHBsaWNhYmxl
IHRvIGFsbCBwb3NzaWJsZSB1c2UgY2FzZXMuIEZvciBleGFtcGxlLCBtdWx0aXBsZSByZXNvdXJj
ZXMgbWF5IHNoYXJlIHRoZSBzYW1lIHNjb3Blcy4gV2hhdCBpZiBib3RoICIvcmVzb3VyY2UxIiBh
bmQgIi9yZXNvdXJjZTIiIHJlY29nbml6ZSAiZ2V0IiBzY29wZSBhbmQgInVwZGF0ZSIgc2NvcGU/
IEluIHRoaXMgY2FzZSwgaXQgaXMgbm90IGFwcHJvcHJpYXRlIHRvIGRldGVybWluZSB0aGUgZGVm
YXVsdCByZXNvdXJjZSBpbmRpY2F0b3IgZm9yICJhdWQiIGZyb20gdGhlIHNjb3Blcy4gSXQgaXMg
YWxzbyBpbXBvc3NpYmxlIHRvIG1hcCBzY29wZXMgdG8gcmVzb3VyY2VzIGFuZCB2aWNlIHZlcnNh
LiBUaGUgYXNzdW1wdGlvbiBpbiB0aGUgY3VycmVudCBkcmFmdCBpcyB0b28gbmFycm93IHRvIGJl
IGluY2x1ZGVkIGluIGEgc3RhbmRhcmQuLiBJZiB0aGUgY3VycmVudCBkZXNjcmlwdGlvbiBjb250
aW51ZXMgdG8gZXhpc3QsIGl0IHdpbGwgaW1wb3NlIGJpZyByZXN0cmljdGlvbnMgb24gdGhlIGRl
c2lnbiBvZiBzY29wZXMgYW5kIHJlc291cmNlcy4NCg0KSWYgeW91IHN0aWxsIHRoaW5rIHRoZSAi
YXVkIiBjbGFpbSBzaG91bGQgYWx3YXlzIGV4aXN0LCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIGVu
ZHBvaW50IGFuZC9vciB0aGUgdG9rZW4gZW5kcG9pbnQgKGFuZC9vciB0aGUgYmFja2NoYW5uZWwg
YXV0aGVudGljYXRpb24gZW5kcG9pbnQgYW5kL29yIHRoZSBkZXZpY2UgYXV0aG9yaXphdGlvbiBl
bmRwb2ludCkgb2YgeW91ciBzeXN0ZW0gY2FuIHJlcXVpcmUgdGhlICJyZXNvdXJjZSIgcmVxdWVz
dCBwYXJhbWV0ZXIgYXMgbWFuZGF0b3J5LiBXZSBkb24ndCBoYXZlIHRvIHB1dCBydWxlcyB0byBk
ZXRlcm1pbmUgdGhlIGRlZmF1bHQgImF1ZCIgdmFsdWUgaW50byB0aGUgc3BlYyBhYm91dCBKV1Qg
YWNjZXNzIHRva2Vucy4gVGhlICJyZXNvdXJjZSIgcGFyYW1ldGVyIGRlZmluZWQgaW4gUkZDIDg3
MDcgY2FuIHdvcmsgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBmb3JtYXQgb2YgYWNjZXNzIHRv
a2VucyBpcyBKV1Qgb3Igbm90LiBUaGVyZWZvcmUsIGl0IGlzIG5vdCBhcHByb3ByaWF0ZSB0byBk
aXNjdXNzIHRoZSBuZWNlc3NpdHkgb2YgdGhlICJhdWQiIGNsYWltIG9ubHkgaW4gdGhlIGNvbnRl
eHQgb2YgIkpXVCIgYWNjZXNzIHRva2Vucy4NCg0KUmVnYXJkaW5nIHRoZSAic3ViIiBjbGFpbSwg
c2V0dGluZyB0aGUgY2xpZW50IElEIHRoZXJlLCByYXRoZXIsIHdpbGwgY29uZnVzZSByZXNvdXJj
ZSBzZXJ2ZXJzLiBJZiB0aGUgInN1YiIgY2xhaW0gaXMgc2V0IGV2ZW4gaW4gdGhlIGNhc2Ugb2Yg
dGhlIGNsaWVudCBjcmVkZW50aWFscyBmbG93LCByZXNvdXJjZSBzZXJ2ZXJzIGNhbm5vdCBqdWRn
ZSB3aGV0aGVyIHRoZSAic3ViIiBjbGFpbSByZXByZXNlbnRzIGVpdGhlciB0aGUgc3ViamVjdCBv
ZiB0aGUgcmVzb3VyY2Ugb3duZXIgb3IgdGhlIGNsaWVudCBJRC4gT24gdGhlIG90aGVyIGhhbmQs
IGlmIHRoZSAic3ViIiBjbGFpbSBpcyBudWxsIG9yIGFic2VudCBpbiB0aGUgY2FzZSBvZiB0aGUg
Y2xpZW50IGNyZWRlbnRpYWxzIGZsb3csIHJlc291cmNlIHNlcnZlcnMgY2FuIGFsd2F5cyBoYW5k
bGUgdGhlIHZhbHVlIG9mIHRoZSAic3ViIiBjbGFpbSBhcyB0aGUgc3ViamVjdCBvZiB0aGUgcmVz
b3VyY2Ugb3duZXIuIEZvciByZXNvdXJjZSBzZXJ2ZXJzLCB0aGlzIGxvZ2ljIGlzIGVhc2llci4g
U2V0dGluZyB0aGUgInN1YiIgY2xhaW0gaW4gZXZlcnkgY2FzZSB0byBtYWtlIHJlc291cmNlIHNl
cnZlciBpbXBsZW1lbnRhdGlvbnMgc2ltcGxlciBpcyBub3QgY29udmluY2luZy4NCg0KQmVzdCBS
ZWdhcmRzLA0KVGFrYQ0KDQpPbiBGcmksIEFwciAyNCwgMjAyMCBhdCAyOjE1IEFNIFRha2FoaWtv
IEthd2FzYWtpIDx0YWthQGF1dGhsZXRlLmNvbTxtYWlsdG86dGFrYUBhdXRobGV0ZS5jb20+PiB3
cm90ZToNCkZpcnN0LCB0byBtYWtlIHRoZSBkaXNjdXNzaW9uIGZhaXIsIEkgdGhpbmsgSSBzaG91
bGQgc2hhcmUgd2hhdCBJIG9ic2VydmVkIHRvZGF5LiBBdXRoMCdzIGNsaWVudF9jcmVkZW50aWFs
cyBmbG93IHJlcXVpcmVzIGFuICJhdWRpZW5jZSIgcGFyYW1ldGVyLCB3aGljaCBpcyBlcXVpdmFs
ZW50IHRvIHRoZSAicmVzb3VyY2UiIHBhcmFtZXRlciBkZWZpbmVkIGluIFJGQyA4NzA3LCBhbmQg
ZW1iZWRzIHRoZSBjbGllbnQgSUQgaW4gdGhlIGdlbmVyYXRlZCBKV1QgYWNjZXNzIHRva2VuIGFz
IHRoZSB2YWx1ZSBvZiB0aGUgInN1YiIgY2xhaW0uDQoNCk15IG9waW5pb24gYXMgYSBzb2Z0d2Fy
ZSBlbmdpbmVlciBpcyBhcyBmb2xsb3dzLg0KDQpbYXVkXQ0KVGhlICJhdWQiIGNsYWltIHNob3Vs
ZCBiZSBudWxsIG9yIGFic2VudCB3aGVuIHRoZSAicmVzb3VyY2UiIHBhcmFtZXRlcnMgYXJlIG5v
dCBnaXZlbiBpbiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QuIEl0IGlzIG5vdCBnb29kIHRvIGlu
dHJvZHVjZSBpbmZsZXhpYmxlIHJ1bGVzIHRvIGRldGVybWluZSB0aGUgZGVmYXVsdCB2YWx1ZSBm
b3IgdGhlICJhdWQiIGNsYWltIGJhc2VkIG9uIHRoZSAic2NvcGUiIHBhcmFtZXRlci4NCg0KW3N1
Yl0NClRoZSAic3ViIiBjbGFpbSBzaG91bGQgYmUgbnVsbCBvciBhYnNlbnQgd2hlbiBhIHJlc291
cmNlIG93bmVyIGlzIG5vdCBpbnZvbHZlZCBpbiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRv
IGJlIGNvbmNyZXRlLCB0aGUgInN1YiIgY2xhaW0gc2hvdWxkIGJlIG51bGwgb3IgYWJzZW50IGlu
IHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdy4gVGhlIHNwZWMgZHJhZnQgc2F5cyBpbiAiNS4g
U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiIGFzIGZvbGxvd3MuDQoNCi0gLSAtIC0gLSAtIC0gLSAt
IC0NCkF1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQgcHJldmVudCBzY2VuYXJpb3Mgd2hlcmUg
Y2xpZW50cyBjYW4gYWZmZWN0IHRoZSB2YWx1ZSBvZiB0aGUgc3ViIGNsYWltIGluIHdheXMgdGhh
dCBjb3VsZCBjb25mdXNlIHJlc291cmNlIHNlcnZlcnMuICBGb3IgZXhhbXBsZTogaWYgdGhlIGF1
dGhvcml6YXRpb24gc2VydmVyIGVsZWN0cyB0byB1c2UgdGhlIGNsaWVudF9pZCBhcyB0aGUgc3Vi
IHZhbHVlIGZvciBhY2Nlc3MgdG9rZW5zIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQs
IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgcHJldmVudCBjbGllbnRzIHRvIHJlZ2lz
dGVyIGFuIGFyYml0cmFyeSBjbGllbnRfaWQgdmFsdWUsIGFzIHRoaXMgd291bGQgYWxsb3cgbWFs
aWNpb3VzIGNsaWVudHMgdG8gc2VsZWN0IHRoZSBzdWIgb2YgYSBoaWdoIHByaXZpbGVnZSByZXNv
dXJjZSBvd25lciBhbmQgY29uZnVzZSBhbnkgYXV0aG9yaXphdGlvbiBsb2dpYyBvbiB0aGUgcmVz
b3VyY2Ugc2VydmVyIHJlbHlpbmcgb24gdGhlIHN1YiB2YWx1ZS4gIEZvciBtb3JlIGRldGFpbHMg
cGxlYXNlIHJlZmVyIHRvIHNlY3Rpb24gNC4xMyBvZiBbT0F1dGgyLlNlY3VyaXR5LkJlc3RQcmFj
dGljZXNdLg0KDQpUbyBwcmV2ZW50aW5nIGNyb3NzLUpXVCBjb25mdXNpb24sIGF1dGhvcml6YXRp
b24gc2VydmVycyBNVVNUIHVzZSBhIGRpc3RpbmN0IGlkZW50aWZpZXIgYXMgImF1ZCIgY2xhaW0g
dmFsdWUgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYWNjZXNzIHRva2VucyBpc3N1ZWQgYnkgdGhlIHNh
bWUgaXNzdWVyIGZvciBkaXN0aW5jdCByZXNvdXJjZXMuDQotIC0gLSAtIC0gLSAtIC0gLSAtDQoN
Ckhvd2V2ZXIsIHRoZSBhdHRhY2sgdmVjdG9yIGlzIGJyb3VnaHQgYWJvdXQgbWVyZWx5IGJ5IGlu
dHJvZHVjaW5nIHRoZSBmb2xsb3dpbmcgcnVsZSBkZWZpbmVkIGluICIyLjIuIERhdGEgU3RydWN0
dXJlIi4NCg0KLSAtIC0gLSAtIC0gLSAtIC0gLQ0KSW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9i
dGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVk
LCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHRoZSB2YWx1ZSBvZiBzdWIg
U0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLg0KLSAtIC0gLSAtIC0g
LSAtIC0gLQ0KDQpJZiB0aGUgcnVsZSBpcyBub3QgaW50cm9kdWNlZCwgdGhlIGF0dGFjayB2ZWN0
b3IgZGlzYXBwZWFycyBhbmQgdGhlICJhdWQiIGNsYWltIGRvZXNuJ3QgaGF2ZSB0byBiZSBtYW5k
YXRvcnkuDQoNCkZpbmFsbHksIHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gZmFpciwgSSBzaG91bGQg
YWxzbyBtZW50aW9uIHRoYXQgSSBteXNlbGYgaXMgYSBjby1mb3VuZGVyIG9mIEF1dGhsZXRlLCBJ
bmMuIHRoYXQgcHJvdmlkZXMgYW4gaW1wbGVtZW50YXRpb24gb2YgT0F1dGggYW5kIE9wZW5JRCBD
b25uZWN0LiBNeSB0aG91Z2h0cyBhYm91dCBpbXBsZW1lbnRhdGlvbnMgb2YgYWNjZXNzIHRva2Vu
cyBhcmUgcHVibGljbHkgZGVzY3JpYmVkIGhlcmU6DQoNCk9BdXRoIEFjY2VzcyBUb2tlbiBJbXBs
ZW1lbnRhdGlvbg0KaHR0cHM6Ly9tZWRpdW0uY29tL0BkYXJ1dGsvb2F1dGgtYWNjZXNzLXRva2Vu
LWltcGxlbWVudGF0aW9uLTMwYzJlOGI5MGZmMA0KDQpCZXN0IFJlZ2FyZHMsDQpUYWthaGlrbyBL
YXdhc2FraQ0KQXV0aGxldGUsIEluYy4NCg0KT24gV2VkLCBBcHIgMjIsIDIwMjAgYXQgNDoxOSBB
TSBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMu
aWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpPdWNo
ISBTb3JyeSDwn5iKIGZpeGVkDQoNCkZyb206IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rw
cml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4NCkRhdGU6IFR1
ZXNkYXksIEFwcmlsIDIxLCAyMDIwIGF0IDEwOjIzDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3Jn
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+LCBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRm
QGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4sIFZpdHRvcmlvIEJlcnRv
Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2Np
QGF1dGgwLmNvbT4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAiSlNP
TiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiDQoN
Ck9oIGFuZCB3aGlsZSB3ZSBhcmUgYXQgaXQgLSBjb3VsZCB5b3UgYWxzbyBmaXggdGhlIHR5cG8g
aW4gbXkgbmFtZT8gVGhhbmtzIDspDQoNCuKAlOKAlOKAlA0KRG9taW5pY2sgQmFpZXINCg0KDQpP
biAyMS4gQXByaWwgMjAyMCBhdCAwOTo0Mzo0OSwgVml0dG9yaW8gQmVydG9jY2kgKHZpdHRvcmlv
LmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPikg
d3JvdGU6DQpUaGlzIGlzIGEgZ3JlYXQgcG9pbnQuIEluIG15IGhlYWQgSSBqdXN0IGNvbnNpZGVy
ZWQgdGhlIE9JREMgc2VtYW50aWMgYW5kIHRob3VnaHQgb25seSBvZiBoaWdobGlnaHRpbmcgdGhl
IGFwcCBpZGVudGl0eSBjYXNlLCBidXQgeW91IGFyZSBhYnNvbHV0ZWx5IHJpZ2h0IHRoYXQgbm90
IG1lbnRpb25pbmcgdGhlIHVzZXIgY2FzZSBhdCBhbGwgaXMgY29uZnVzaW5nLiBJIGFkZGVkIHRo
ZSBsYW5ndWFnZSB5b3Ugc3VnZ2VzdGVkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHN1YiBkZWZp
bml0aW9uLg0KVGhhbmtzIQ0KDQpGcm9tOiBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJp
dmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4+DQpEYXRlOiBNb25k
YXksIEFwcmlsIDIwLCAyMDIwIGF0IDIyOjU0DQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4+LCBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdt
YWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tPj4sICJ2aXR0b3Jpby5iZXJ0b2Nj
aUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4iIDx2aXR0b3Jp
by5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4+
DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAiSlNPTiBXZWIgVG9rZW4g
KEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMiDQoNCg0KSW4gY2FzZSBv
ZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNl
IG93bmVyIGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQs
IHRoZSB2YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0
aW9uLg0KDQpNYXliZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgZG9lcyBpdCBzYXkgYW55
d2hlcmUgd2hhdCB0byBleHBsaWNpdGx5IGRvIGluIHRoZSBjYXNlIG9mIGFuIGFjY2VzcyB0b2tl
biB3aGVyZSBhIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVkPw0KDQpUaGVyZeKAmXMgc29tZSBs
YW5ndWFnZSB0aGF0IHNlZW1zIHRvIGltcGx5IHRoYXQsIGUuZy46DQoNCg0KYXMgdGhpcyB3b3Vs
ZCBhbGxvdyBtYWxpY2lvdXMNCg0KICAgY2xpZW50cyB0byBzZWxlY3QgdGhlIHN1YiBvZiBhIGhp
Z2ggcHJpdmlsZWdlIHJlc291cmNlIG93bmVyDQpJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgdG8gc2Vl
IHNvbWV0aGluZyBzdHJvbmdlciBsaWtlIGFib3ZlIGp1c3QgLQ0KDQoNCkluIGNhc2Ugb2YgYWNj
ZXNzIHRva2VucyBvYnRhaW5lZCB0aHJvdWdoIGdyYW50cyB3aGVyZSBhIHJlc291cmNlIG93bmVy
IGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBhdXRob3Jpc2F0aW9uIGNvZGUgZ3JhbnQsIHRoZSB2
YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3BvbmQgdG8gdGhlIHN1YmplY3QgaWRlbnRpZmllciBv
ZiB0aGUgcmVzb3VyY2Ugb3duZXIuDQoNCklmIHRoaXMgc3BlYyBpcyBhYm91dCBpbnRlcm9wLCBJ
IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGF0IGxlYXN0IGEgcmVjb21tZW5kYXRpb24uLi4NCg0KDQri
gJTigJTigJQNCkRvbWluaWNrIEJhaWVyDQoNCg0KT24gMjAuIEFwcmlsIDIwMjAgYXQgMDk6NDg6
NTEsIHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8uYmVydG9jY2lA
YXV0aDAuLmNvbT4gKHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8u
YmVydG9jY2lAYXV0aDAuY29tPikgd3JvdGU6DQpUaGFua3MgRG9taW5pY2sgZm9yIHlvdXIgY29t
bWVudHMhDQpJbmxpbmUNCg0KPiBBbGwgb3RoZXIgT0F1dGggc3BlY3MgbWFrZSBhIHZlcnkgY2xl
YXIgZGlzdGluY3Rpb24gYmV0d2VlbiB1c2VycyBhbmQgY2xpZW50Lg0KVGhlcmXigJlzIGEgbnVh
bmNlIHdvcnRoIGhpZ2hsaWdodGluZyBoZXJlOiBzdWIgIT0gdXNlci4gSW4gcHJldmlvdXMgZGlz
Y3Vzc2lvbnMgb24gdGhpcyB0b3BpYyBpdCBoYXMgYmVlbiBicm91Z2h0IHVwIHRoYXQgdGhlIEpX
VCBzcGVjIGRlZmluZXMgc3ViIGFzIGlkZW50aWZ5aW5nIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0
aGUgc3ViamVjdCBvZiB0aGUgSldULCBhbmQgdGhhdOKAmXMgbm90IG5lY2Vzc2FyaWx5IGxpbWl0
ZWQgdG8gdXNlcnMuDQoNCkhvd2V2ZXIgSSBnZXQgdGhlIHBvdGVudGlhbCBjb25mdXNpb24sIGFu
ZCBJIGFtIGhhcHB5IHRvIGFkZCBjbGFyaWZ5aW5nIGxhbmd1YWdlIGlmIHlvdSBoYXZlIHNwZWNp
ZmljIHBhc3NhZ2VzIGluIHRoZSBzcGFjZSB5b3UgYXJlIHBhcnRpY3VsYXJseSB3b3JyaWVkIGFi
b3V0OiBob3dldmVyIEkgZmVlbCB0aGUgbWF0dGVyIGlzIGFkZHJlc3NlZCB1cGZyb250IGJ5IHRo
ZSBsYW5ndWFnZSBpbiBTZWN0aW9uIDIuMi4gaW4gdGhlIHN1YiBlbnRyeSwg4oCcSW4gY2FzZSBv
ZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNl
IG93bmVyIGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQs
IHRoZSB2YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0
aW9uLuKAnCBhbmQgU2VjdGlvbiA1IGhhcyBhbiBlbnRpcmUgcGFyYWdyYXBoIGRpc2N1c3Npbmcg
dGhpbmdzIHRvIHdhdGNoIG91dCBpbiBhc3NpZ25pbmcgc3ViIHZhbHVlcyBpbiB0aGUgYXBwIGlk
ZW50aXR5IGNhc2UuIEZlZWwgZnJlZSB0byBzdWdnZXN0IGFkZGl0aW9uYWwgbGFuZ3VhZ2UgaWYg
eW91IHdhbnQgdG8gY2xhcmlmeSBmdXJ0aGVyLg0KDQo+IHN1YiBoYXMgYSBkaWZmZXJlbnQgc2Vt
YW50aWMgaGVyZSBhcyBpbiBPSURDDQpUaGUgIHNwZWMgcmVmZXJzIHRvIFJGQzc1MTkgaW4gdGhl
IHN1YiBkZWZpbml0aW9uIGluIDIuMiwgcmF0aGVyIHRoYW4gT0lEQywgdG8gcHJlZW1wdCB0aGF0
IGNvbmNlcm4gYW5kIGtlZXAgdGhlIG9yaWdpbmFsIHN1YiBzZW1hbnRpYyBhdmFpbGFibGUuDQoN
Cj4gSSBhbSBub3QgZnVsbHkgY2xlYXIgd2h5IGF1ZCBpcyByZXF1aXJlZC4NCkF1ZCBpcyB0aGVy
ZSBtb3N0bHkgYmVjYXVzZSBvZiB0aHJlZSByZWFzb25zOg0KDQrigKIgICAgICAgICBNYW55IGV4
aXN0aW5nIHNwZWNzIHBvc3R1bGF0ZSBpdHMgZXhpc3RlbmNlIGluIHRoZSB0b2tlbi4gTm8gb25l
IGRlY2xhcmVzIGl0IGFzIGEgcHJvcGVyIE1VU1QgKGFwYXJ0IGZyb20gdGhlIEJDUCwgYnV0IHRo
YXTigJlzIHBhcnRpYWwpIGhvd2V2ZXIgSSB0aGluayBpdHMgaW1wb3J0YW5jZSBjb21lcyBhY3Jv
c3MuLg0KLUJlYXJlciB0b2tlbiB1c2FnZSBSRkM2NzUwIGNhbGxzIGl0IG91dCAoaW4gdGhyZWF0
IG1pdGlnYXRpb24pIGFzIHRoZSBtZWNoYW5pc20gdG8gcHJldmVudCB0b2tlbiByZWRpcmVjdCAo
YW5kIGFkZHMgc2NvcGUgcmVzdHJpY3Rpb24gYXMgYWxzbyBpbXBvcnRhbnQsIGhvd2V2ZXIgaGVy
ZSB3ZSBtYWtlIGl0IG9wdGlvbmFsIHRvIGFjb2N1dCBmb3Igbm9uLWRlbGVnYXRpb25zIHNjZW5h
cmlvKS4NCi1SZXNvdXJjZSBpbmRpY2F0b3JzIFJGQzg3MDcgcmVmZXJzIHRvIHRoZSBzYW1lIHNl
Y3Rpb24gb2YgUkZDNzUxOSBhcyBvbmUgb2YgdGhlIGFzc3VtcHRpb25zIHRoYXQgbXVzdCBob2xk
IHRvIHByZXZlbnQgYmVhcmVyIHRva2VucyBtaXN1c2UNCi1CQ1AyMjUgbWFrZXMgYXVkIG1hbmRh
dG9yeSBmb3IgQVMgd2hpY2ggY2FuIGlzc3VlIEpXVHMgZm9yIG1vcmUgdGhhbiBvbmUgYXBwDQoN
CuKAoiAgICAgICAgIEFwYXJ0IGZyb20gUGluZywgZm9yIHdoaWNoIHNvbWUgb2YgaXRzIGV4YW1w
bGVzIGFyZSB3aXRob3V0IGF1ZCAoYnV0IGFsc28gd2l0aG91dCBpZGVudGlmeWluZyBzY29wZXMs
IGdpdmVuIHRoYXQgdGhlIG9uZSBJIHJldHJpZXZlZCBoYWQgb25seSDigJxvcGVuaWTigJ0pLCBh
bGwgb2YgdGhlIHNhbXBsZSBKV1QgQVRzIEkgcmVjZWl2ZWQgZnJvbSB2ZW5kb3JzIGFsbCBmZWF0
dXJlZCBhbiBhdWQuIEkga25vdyBvbmUgc2hvdWxuZOKAmXQgb3ZlcmluZGV4IG9uIHRob3NlIGV4
YW1wbGVzLCBidXQgdG9nZXRoZXIgd2l0aCB0aGUgYWJvdmUgaXQgc2VlbWVkIHRvIHBvaW50IHRv
IHNvbWV0aGluZyB1bml2ZXJzYWxseSB1c2VmdWwuIE9uZSBwb3NzaWJsZSByZWFzb24gaXMgdGhh
dCB1c2Ugb2YgYSBmb3JtYXQgZm9yIHRoZSBBVCBpcyBjb3JyZWxhdGVkIHdpdGggdG9wb2xvZ2ll
cyB3aGVyZSBBUyBhbmQgUlMgYXJlIHNlcGFyYXRlZCBieSBzb21lIGJvdW5kYXJ5IChuZXR3b3Jr
LCBsb2dpY2FsLCBidXNpbmVzcywgY29kZSBmYWN0b3JpbmcsIGV0YykgaGVuY2UgaWRlbnRpZnlp
bmcgdGhlIHJlc291cmNlIHNlZW1zIGxpa2UgYSBuYXR1cmFsIG5lZWQuIEFnYWluLCBub3QgYW4g
aXJvbiBjbGFkIGxhdywgYnV0IGFuIGluZGljYXRpb24uDQoNCuKAoiAgICAgICAgIEEgbG90IG9m
IHBlb3BsZSByZXB1cnBvc2UgZXhpc3RpbmcgbGlicmFyaWVzIGZvciB0aGUgSldUIEFUIGNhc2Us
IGFuZCBzb21lIHBlb3BsZSBldmVuIHNlbmRzIGlkX3Rva2VucyBpbiBsaWV1IG9mIEFUcy4gVGhh
dCBkb2VzbuKAmXQgbWVhbiB0aGF0IHdlIHNob3VsZCBjb25kb25lIGFueSBiYWQgcHJhY3RpY2Vz
LCBidXQgaW4gdGlzIHBhcnRpY3VsYXIgY2FzZSBpdCBzdWdnZXN0cyB0aGF0IGxvdHMgb2YgZGV2
ZWxvcGVycyBhbHJlYWR5IGV4cGVjdC9jYW4gaGFuZGxlIGFuIGF1ZGllbmNlIGluIHRoZSBKV1Qg
dXNlZCB0byBjYWxsIHRoZWlyIEFQSQ0KTm9uZSBvZiB0aG9zZSBhcmUgYSBzbGFtIGR1bmsgYXJn
dW1lbnQgZm9yIG1hbmRhdG9yeSwgYnV0IEkgZmluZCB0aGVtIGNvbXBlbGxpbmcgZW5vdWdoIHRv
IHNpbXBsaWZ5IHZhbGlkYXRpb24gYW5kIGp1c3QgcmVxdWlyZSBhbiBhdWQgdG8gYmUgdGhlcmUs
IGFzIG9wcG9zZWQgdG8gaW50cm9kdWNlIGNvbXBsaWNhdGlvbnMgdGhhdCBtYWtlIGl0IGNvbmRp
dGlvbmFsIHRvIHRoZSBwcmVzZW5jZSBvZiBzY29wZXMgb3Igb3RoZXIgZGlzYW1iaWd1YXRpb24u
LiBPbmUgcmVhc29uIEkgZmVlbCBwcmV0dHkgZ29vZCBhYm91dCB0aGF0IGlzIHRoYXQgYWRkaW5n
IGEgZGVmYXVsdCBhdWRpZW5jZSBpc27igJl0IHZlcnkgaGFyZCBpZiBhbnkgb2YgdGhlIGFib3Zl
IGFzc3VtcHRpb25zIGVuZCB1cCBub3QgYmVpbmcgdHJ1ZSBmb3IgYSBwYXJ0aWN1bGFyIGNhc2UN
Cg0KPiBXaGF04oCZcyB0aGUgcmF0aW9uYWxlIGZvciB1c2luZyBpYXQgaW5zdGVhZCBvZiBuYmYu
DQpUaGF04oCZcyBqdXN0IHN0cmFpZ2h0IGZyb20gT0lEQyBJRF90b2tlbnMsIGFuZCB0aGUgY29u
c2lkZXJhdGlvbnMgYWJvdXQgcmVwdXJwb3NpbmcgZXhpc3RpbmcgbG9naWMuIEkgc2VlIHRoZXJl
4oCZcyBhIHRocmVhZCBvbiB0aGlzIHNwZWNpZmljYWxseSwgbGV0IG1lIGFuc3dlciBmdXJ0aGVy
IG9uIHRoYXQgYnJhbmNoLg0KDQo+IFRoaXMgc3BlYyBmZWVscyBzb21laG93IGluIGJldHdlZW4g
YSBwcm9maWxlIGFuZCBhIEJDUA0KWW91IGFyZSByaWdodCB0aGF0IHRoaXMgc3BlYyBhdHRlbXB0
cyB0byBnbyBiZXlvbmQganVzdCBkZWNsYXJpbmcgYSBsYXlvdXQsIGFuZCBJIGFncmVlIHRoaXMg
bWVhbnMgdGhhdCB0aGlzIHByb2ZpbGUgd2lsbCBub3QgYXBwbHkgdG8gYWJzb2x1dGVseSBldmVy
eW9uZS4gVGhlIHJlYXNvbiBJIHRyaWVkIHRoYXQgcm91dGUgKGF0IHRoZSBjb3N0IG9mIHdvcmtp
bmcgd2F5IGhhcmRlciBpbiB0aGUgbGFzdCB5ZWFyIGZvciByZWFjaGluZyBjb25zZW5zdXMgdGhh
biBpZiB3ZSB3b3VsZCBoYXZlIGp1c3QgbGlzdGVkIHRoZSBwb3NzaWJsZSBjb250ZW50KSwgaXMg
dGhhdCBJIG9mdGVuIG9ic2VydmUgaW1wbGVtZW50ZXJzIG1ha2UgcXVlc3Rpb25hYmxlIGNob2lj
ZXMgYmVjYXVzZSBvZiB0aGUgbGFyZ2UgbGVld2F5IHNwZWNpZmljYXRpb25zIGFsbG93LiBNeSBo
b3BlIHdhcyB0aGF0IHRoZSBzY29wZSBvZiB0aGlzIHByb2ZpbGUgd2FzIHNtYWxsIGVub3VnaCB0
byBtYWtlIHRoYXQgZXh0cmEgbGV2ZWwgb2YgZ3VpZGFuY2UgYWNoaWV2YWJsZSwgd2hlcmVhcyB0
cnlpbmcgdG8gZG8gdGhlIHNhbWUgd2l0aCBhIGxhcmdlciBzcGVjIHdvdWxkIGhhdmUgYmVlbiBw
cm9oaWJpdGl2ZWx5IGV4cGVuc2l2ZS4NCkkgYmVsaWV2ZSB0aGluZ3Mgd29ya2VkIG91dCB3ZWxs
IHNvIGZhcjogd2UgaGFkIGxvdHMgb2YgY29uc3RydWN0aXZlIGRpc2N1c3Npb25zLCBhbmQgSSBl
bmRlZCB1cCByZWxheGluZyBBIExPVCBvZiB0aGUgY29uc3RyYWludHMgSSB3YXMgb3JpZ2luYWxs
eSBlbnZpc2lvbmluZy4gTm9uZXRoZWxlc3MsIG15IGhvcGUgaXMgdGhhdCB3ZSBpZGVudGlmaWVk
IHRoZSByaWdodCBzZXQgb2YgZ3VpZGVsaW5lcyB0aGF0IHdpbGwgaGVscCBwZW9wbGUgYWN0dWFs
bHkgaW50ZXJvcGVyYXRlIG91dCBvZiB0aGUgYm94IGZvciB0aGUgbW9zdCBiYXNpYy9jb21tb24g
c2NlbmFyaW9zLCBhcyBvcHBvc2VkIHRvIGNvbXBseWluZyB3aXRoIHRoZSBsZXR0ZXIgb2YgdGhl
IHNwZWMgYnV0IHN0aWxsIGhhdmluZyBhIGxvdCB0byBmaWd1cmUgb3V0IG91dCBvZiBiYW5kLg0K
DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBEb21pbmljayBCYWllcg0KU2VudDogVGh1cnNkYXks
IEFwcmlsIDE2LCAyMDIwIDEyOjEwIEFNDQpUbzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQu
aWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+OyBvYXV0aCA8b2F1
dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIFNlY29uZCBXR0xDIG9uICJKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0
aCAyLjAgQWNjZXNzIFRva2VucyINCg0KU2luY2UgdGhpcyBpcyB0aGUgbGFzdCBjYWxsLCBJIHRo
b3VnaHQgSSBicmluZyB1cCBzb21lIG9mIHRob3VnaHRzIC8gY29uY2VybnMuIFNvbWUgb2YgdGhl
bSBoYXZlIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS4NCg0KY2xpZW50X2lkIHZzIHN1Yg0KSSBhbSBz
dGlsbCBub3QgZW50aXJlbHkgaGFwcHkgd2l0aCB0aGUg4oCccmUtcHVycG9zaW5n4oCdIG9mIHRo
ZSBjbGFpbSB0eXBlcyBiYXNlZCBvbiBmbG93Lg0KSWYgdGhlIGludGVudGlvbiBpcywgdGhhdCBz
dWIgZXhwcmVzc2VzIHRoZSBlbnRpdHkgYWdhaW5zdCB3aGljaCB0aGUgcmVzb3VyY2Ugd2lsbCBk
byBhdXRob3Jpc2F0aW9uIChhbmQgdGhhdCBtaWdodCBiZSBhIGNsaWVudCBvciBhIHVzZXIpIC0g
SSBnZXQgaXQgKGFuZCBtYXliZSBpdCBzaG91bGQgYmUgc3RhdGVkIGxpa2UgdGhhdCkgLSBidXQN
CnRoaXMgdGhpbmtpbmcgcmVtaW5kcyBtZSBvZiB0aGUgb2xkIEFEIGRheXMgd2hlcmUgdGhlcmUg
d2FzIG5vIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlciBhbmQgc2VydmljZSBhY2NvdW50cyAoc29t
ZXRoaW5nIHRoYXQgaGFzIGJlZW4gZml4ZWQgSUlSQyBpbiBXaW5kb3dzIFNlcnZlciAyMDEyIFIy
KS4NCg0KQWxsIG90aGVyIE9BdXRoIHNwZWNzIG1ha2UgYSB2ZXJ5IGNsZWFyIGRpc3RpbmN0aW9u
IGJldHdlZW4gdXNlcnMgYW5kIGNsaWVudC4NCg0KRnVydGhlcm1vcmUgaXQgc2F5cw0KDQoiQXV0
aG9yaXphdGlvbiBzZXJ2ZXJzIHNob3VsZCBwcmV2ZW50IHNjZW5hcmlvcyB3aGVyZSBjbGllbnRz
IGNhbg0KICAgYWZmZWN0IHRoZSB2YWx1ZSBvZiB0aGUgc3ViIGNsYWltIGluIHdheXMgdGhhdCBj
b3VsZCBjb25mdXNlIHJlc291cmNlDQogICBzZXJ2ZXJzLuKAnQ0KDQpJZiB3ZSBrZWVwIHRoYXQg
ZHVhbCBzZW1hbnRpY3Mgb2YgdGhlIHN1YiBjbGFpbSAtIGl0IG11c3QgYmUgY2xlYXJseSBzdGF0
ZWQsIHRoYXQgc3ViamVjdCBJRCBhbmQgY2xpZW50IElEIGFyZSBub3cgaW4gdGhlIHNhbWUgY29s
bGlzaW9uIGRvbWFpbi4gU28gd2hlbiBhbiBBUyAvIE9QIGNyZWF0ZXMgdGhlbSwgdGhleSBuZWVk
IHRvIGJlIHVuaXF1ZSBhY3Jvc3MgdXNlciBpZHMgYW5kIGNsaWVudCBpZHMuDQoNCk1heWJlIGl0
IHNob3VsZCBiZSBhbHNvIGV4cGxpY2l0bHkgbWVudGlvbmVkIHRoYXQgc3ViIGhhcyBhIGRpZmZl
cmVudCBzZW1hbnRpYyBoZXJlIGFzIGluIE9JREMgLSBldmVuIHRob3VnaCBhIG1ham9yaXR5IG9m
IHRoZSBzb2Z0d2FyZSBidWlsdCB0b2RheSB3aWxsIHVzZSB0aGVtIHRvZ2V0aGVyLg0KDQphdWRp
ZW5jZSBjbGFpbQ0KSSBhbSBub3QgZnVsbHkgY2xlYXIgd2h5IGF1ZCBpcyByZXF1aXJlZC4gT0F1
dGggaXRzZWxmIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgYW4gYXVkaWVuY2UgKGluIHRoZSBK
V1Qgc2Vuc2UpIC0gdGhleSBoYXZlIHNjb3BlcyAod2hpY2ggaXMgdmVyeSBzaW1pbGFyKS4gQnV0
IGluIHNpbXBsZSBzY2VuYXJpb3Mgd2hlcmUgcmVzb3VyY2VzIGRvbuKAmXQgZXhpc3QsIHlvdSdk
IG5lZWQgdG8gbWFrZSB1cCBhbiBhdWRpZW5jZSBqdXN0IHRvIGZ1bGZpbCB0aGlzIHJlcXVpcmVt
ZW50LiBBbmQgaW4gbWFueSBjYXNlIHRoaXMgd2lsbCBiZSBlaXRoZXIgc3RhdGljIG9yIGp1c3Qg
cmVwZWF0IHRoZSBzY29wZSB2YWx1ZXMuIFdoYXTigJlzIHRoZSB2YWx1ZSBvZiB0aGF0Pw0KDQpJ
ZiB0aGUgY29uY2VwdCBvZiByZXNvdXJjZXMgYXJlIHVzZWQsIEkgYWJzb2x1dGVseSBhZ3JlZSB0
aGF0IGF1ZCBzaG91bGQgYmUgdXNlZCB0b28uIEJ1dCBJIHdvdWxkbuKAmXQgbWFrZSBpdCByZXF1
aXJlZC4NCg0KaWF0IHZzIG5iZg0KV2hhdOKAmXMgdGhlIHJhdGlvbmFsZSBmb3IgdXNpbmcgaWF0
IGluc3RlYWQgb2YgbmJmLiBBcmVu4oCZdCBtb3N0IEpXVCBsaWJyYXJpZXMgKGluY2x1ZGluZyBl
LmcuIHRoZSAuTkVUIG9uZSkgbG9va2luZyBmb3IgbmJmIGJ5IGRlZmF1bHQ/DQoNCkdlbmVyYWwN
ClRoaXMgc3BlYyBmZWVscyBzb21laG93IGluIGJldHdlZW4gYSBwcm9maWxlIGFuZCBhIEJDUC4g
T24gb25lIGhhbmQgeW91IGRlZmluZSBzb21lIGNsYWltcyBhbmQgdGhlaXIgc2VtYW50aWNzIChn
b29kKSAtIG9uIHRoZSBvdGhlciBoYW5kIHRoZXJlIGlzIHNvbWUgcHJlc2NyaXB0aXZlIGd1aWRh
bmNlIGFuZCBtYXliZSBvdmVyLXNwZWNpZmljYXRpb24uIE15IGNvbmNlcm4gaXMsIHRoYXQgaW4g
dGhlIGVuZCBuby1vbmUgd2lsbCBmdWxseSBjb21wbHkgd2l0aCBpdCwgYmVjYXVzZSBpdCBkb2Vz
buKAmXQgd29yayBvbmUgd2F5IG9yIHRoZSBvdGhlciBmb3IgdGhlbS4NCg0KSSBrbm93IHdlIGp1
c3Qgd2VudCB0aG91Z2ggdGhlIGRpc2N1c3Npb24gdG8gbWFrZSBjZXJ0YWluIGNsYWltcyByZXF1
aXJlZCBhcyBvcHBvc2VkIHRvIG9wdGlvbmFsIC0gYnV0IG1heWJlIGxlc3MgaXMgbW9yZS4NCg0K
VGJoIC0gdGhlIG1vc3QgdmFsdWFibGUgcGFydCBvZiB0aGUgZG9jIHRvIG1lIGlzIHRoZSBkZWZp
bml0aW9uIG9mIHRoZSDigJxhdCtqd3TigJ0gdHlwLiBGb3IgdGhlIHJlc3QgSeKAmWQgcmF0aGVy
IGxpa2UgdG8gc2VlIGp1c3Qgc29tZSBzdGFuZGFyZCBjbGFpbXMgYW5kIElGIHRoZXkgYXJlIHVz
ZWQsIHdoaWNoIHNlbWFudGljcyB0aGV5IGhhdmUuDQoNCmNoZWVycw0K4oCU4oCU4oCUDQpEb21p
bmljayBCYWllcg0KDQoNCk9uIDE1LiBBcHJpbCAyMDIwIGF0IDIwOjU5OjMxLCBSaWZhYXQgU2hl
a2gtWXVzZWYgKHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwu
Y29tPikgd3JvdGU6DQpIaSBhbGwsDQoNClRoaXMgaXMgYSBzZWNvbmQgd29ya2luZyBncm91cCBs
YXN0IGNhbGwgZm9yICJKU09OIFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAg
QWNjZXNzIFRva2VucyIuDQoNCkhlcmUgaXMgdGhlIGRvY3VtZW50Og0KaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wNg0KDQpQbGVh
c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBPQXV0aCBtYWlsaW5nIGxpc3QgYnkgQXByaWwg
MjksIDIwMjAuDQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgSGFubmVzDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg==

--_000_MWHPR19MB15011471BBF5E5B337463500AED00MWHPR19MB1501namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg
MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGlj
IjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFwcGxlIENvbG9yIEVtb2pp
IjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MiA2IDUgOSAyIDIgNSAy
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3Nl
LTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN
UyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt
c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy
Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm
dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjt9DQpwLmdtYWlsLW02ODAxOTgzNzAwMjE2ODIzMW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdt
YWlsLW02ODAxOTgzNzAwMjE2ODIzMW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNjgwMTk4
MzcwMDIxNjgyMzFtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fNjgw
MTk4MzcwMDIxNjgyMzFtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFz
IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu
Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ
e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ
e21zby1saXN0LWlkOjg4Mzc2MDg2MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzY5MzY2OTY0
O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2
ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5EZWFyIFRha2FoaWtvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIga2luZCBhbmQgcHJvbXB0IHJlc3Bv
bnNlLCBhbmQgZm9yIGhhdmluZyBkZWxldGVkIHRoZSB0d2VldHMuIFdlIGFsbCBjYXJlIGEgbG90
IGFib3V0IGRvaW5nIHRoZSByaWdodCB0aGluZywgYW5kIEkgZnVsbHkgdW5kZXJzdGFuZCBob3cg
cGFzc2lvbiBjYW4gc29tZXRpbWVzIGNhcnJ5IHVzIGF3YXkuIEZvciBtZSB0aGlzIHJlc29sdmVz
IHRoZSBtYXR0ZXIgMTAwJS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
YW5rcyBhZ2Fpbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlYuIDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGFrYWhpa28gS2F3YXNha2kg
Jmx0O3Rha2FAYXV0aGxldGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEFwcmls
IDI0LCAyMDIwIGF0IDE1OjQ5PGJyPg0KPGI+VG86IDwvYj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7
dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0
O29hdXRoQGlldGYub3JnJmd0OywgVml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRv
Y2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S
ZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAmcXVvdDtKU09OIFdlYiBUb2tlbiAoSldUKSBQ
cm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBWaXR0b3Jp
byw8YnI+DQo8YnI+DQpJIGFwb2xvZ2l6ZS4gVG8gbWUsIHRoZSByZXF1aXJlbWVudHMgb24gJnF1
b3Q7YXVkJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDsgc291bmRlZCB0b28gc3RyYW5nZSBhbmQg
dGhlIGxvZ2ljIHRvIGRlbnkgY291bnRlciBwcm9wb3NhbHMgc291bmRlZCB1bm5hdHVyYWxseSB1
bmNvbnZpbmNpbmcsIHRvby4gVGhleSBtYWRlIG1lIHN1c3BpY2lvdXMsIGFuZCB1bmZvcnR1bmF0
ZWx5IGFuZCBhY2NpZGVudGFsbHksIG15IHN1YnNlcXVlbnQgb2JzZXJ2YXRpb24gbWF0Y2hlZCBt
eSBkb3VidCwNCiBhbmQgaXQgbWFkZSBtZSBmZWVsIEkgc2hvdWxkIGJyaW5nIGl0IGhlcmUgd2l0
aCBhIGtpbmQgb2Ygc2Vuc2Ugb2YganVzdGljZSwgYnV0IEkgd2FzIGEgd2F5IHRvbyBzdHVwaWQu
IEkgd2FudGVkIHRvIGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50cyBwdXJlbHkgdGVjaG5pY2FsbHkg
YnkgcmVtb3ZpbmcgcG9saXRpY3MsIHdoaWNoIEkgdGhvdWdodCBleGlzdGVkIGJ1dCBkaWQgbm90
IGV4aXN0IGFjdHVhbGx5LiBUaGUgaXJvbmljIHJlc3VsdCB3YXMNCiB0aGF0IG15IHByZXZpb3Vz
IHBvc3QgaXRzZWxmIHdhcyBwb2xpdGljcy4gSSBzdG9wIG1ha2luZyBjb21tZW50cyB0byB0aGUg
c3BlYy48YnI+DQo8YnI+DQpJJ20gc29ycnkgZm9yIG15IHR3ZWV0cy4gQmVjYXVzZSB0aGV5IGhh
dmUgYmVlbiBjb3BpZWQgdG8gaGVyZSBpbiBhbiB1bnJlbW92YWJsZSB3YXksIGFsbG93IG1lIHRv
IHJlbW92ZSB0aGVtIGZyb20gVHdpdHRlciB0byByZWZsZWN0IG15IGNvbmR1Y3QuPGJyPg0KPGJy
Pg0KSSdtIHNvcnJ5IGZvciBoYXZpbmcgY2FzdCBkb3VidCBhbHRob3VnaCBJJ3ZlIGFjdHVhbGx5
IHJlc3BlY3RlZCB5b3Ugc2luY2UgbG9uZyBiZWZvcmUgd2l0aG91dCB5b3VyIGtub3dpbmcuIEhv
cGVmdWxseSwgSSB3YW50IG1lcmN5IGZyb20geW91IGFuZCB0aGUgY29tbXVuaXR5IGluIHNwaXRl
IG9mIG15IGNvbmR1Y3QuPGJyPg0KPGJyPg0KVGFrYWhpa288bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgQXByIDI1LCAyMDIwIGF0IDU6MjQgQU0g
Vml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBh
dXRoMC5jb20iPnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlRha2FoaXJvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5CZWZvcmUgSSBhY2tub3dsZWRnZSB5b3VyIGNvbW1lbnRzLCBJIHdvdWxkIGxpa2UgdG8g
Y2xhcmlmeSBzb21lIGltcG9ydGFudCBwb2ludHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPllvdXIgZmlyc3QgZW1haWwsIGFuZCB2YXJpb3VzIHR3ZWV0cyB5b3UgcHVi
bGlzaGVkIGNvbnRleHR1YWxseSAoPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9kYXJ1dGsv
c3RhdHVzLzEyNTMzNzUwMzk2ODE4ODQxNjAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3R3aXR0
ZXIuY29tL2RhcnV0ay9zdGF0dXMvMTI1MzM3NTAzOTY4MTg4NDE2MDwvYT4pLA0KIHN1Z2dlc3Qg
dGhhdCB3aXRoIG15IHdvcmsgb24gdGhlIHNwZWMgSSBhbSBkcml2aW5nIHNvbWUgaGlkZGVuIGFn
ZW5kYSBmb3IgbXkgY29tcGFueSwgYW5kIHlvdSBhcmUgZXhwb3NpbmcgdGhpcyB0aGFua3MgdG8g
c29tZSBmaW5kaW5ncyB5b3UgdW5jb3ZlcmVkLSBhbmQgdGhhdCB0aGUgV0cgc29tZWhvdyBtaXNz
ZWQuPGJyPg0KVGhpcyBpcyBvZiBjb3Vyc2Ugbm9uc2Vuc2UsIGluc3VsdGluZyB0byBteSBvd24g
cHJvZmVzc2lvbmFsIGludGVncml0eSBhbmQgdG8gdGhlIGludGVsbGlnZW5jZSBvZiB0aGUgY2hh
aXJzLCB3b3JraW5nIGdyb3VwIGFuZCBldmVyeW9uZSB3aG8gcGFydGljaXBhdGVkIGluIHRoZSBk
aXNjdXNzaW9uLiBJIGluY2x1ZGUgdGhlIHR3ZWV0cyBpbiB0aGUgZGlzY3Vzc2lvbiBiZWNhdXNl
IHlvdSBpbmNsdWRlZCBpbiB0aGVtIGEgbGluayB0byB0aGUgbWFpbGluZw0KIGxpc3QgYXJjaGl2
ZXMsIGhlbmNlIGludm9sdmluZyB0aGUgV0cgaW4gdGhlIHByb2Nlc3MuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5Tb21lIGJhc2ljIGZhY3RzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9
ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tNjgwMTk4MzcwMDIxNjgyMzFtc29saXN0cGFyYWdy
YXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIHByb2ZpbGUgYXMgaXQg
ZXhpc3RzIHRvZGF5IGRvZXMgTk9UIHdvcmsgb3V0IG9mIHRoZSBib3ggd2l0aCBBdXRoMCwgdGhl
cmUgYXJlIHNldmVyYWwgdGhpbmdzIHRoYXQgd291bGQgbmVlZCB0byBjaGFuZ2UgaW4gdGhlIHBy
b2R1Y3QgZm9yIHRoYXQgdG8gaGFwcGVuLSBpbmNsdWRpbmcgYWRkaW5nIHN1cHBvcnQgZm9yIHJl
c291cmNlIGluZGljYXRvcnMgd2hpY2ggaXMgY3VycmVudGx5IG1pc3Npbmc8bzpwPjwvbzpwPjwv
bGk+PGxpIGNsYXNzPSJnbWFpbC1tNjgwMTk4MzcwMDIxNjgyMzFtc29saXN0cGFyYWdyYXBoIiBz
dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIGxheW91dCBvZiB0aGUgQXV0aDAg
dG9rZW4gaXMgY2VydGFpbmx5IG5vdCBhIHNlY3JldCwgZ2l2ZW4gdGhhdCBpdCB3YXMgcHJlc2Vu
dGVkIGFsb25nc2lkZSBhbGwgdGhlIG90aGVyIHRva2VucyBvYnRhaW5lZCBmcm9tIG90aGVyIHZl
bmRvcnMgYXQgdGhlIE9TVzIwMTkgaW4gTWFyY2gsIGluIHRoZSBpbml0aWFsIGRyYWZ0IHBpdGNo
IGF0IElFVEYxMDQgYXMgcmVjb3JkZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQtb2F1dGgtc2Vzc2Etand0
LXByb2ZpbGUtZm9yLWFjY2Vzcy10b2tlbi0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9tYXRlcmlhbHMvc2xpZGVzLTEwNC1vYXV0
aC1zZXNzYS1qd3QtcHJvZmlsZS1mb3ItYWNjZXNzLXRva2VuLTAwPC9hPiwgaW4gdGhlIGZpcnN0
IGRpc2N1c3Npb24gYXQgSUVURjEwNSBhcyBzaG93biBpbg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNS9tYXRlcmlhbHMvc2xpZGVzLTEwNS1vYXV0aC1z
ZXNzYS1qc29uLXdlYi10b2tlbi1qd3QtcHJvZmlsZS1mb3Itb2F1dGgtMjAtYWNjZXNzLXRva2Vu
cy0wMi0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9t
ZWV0aW5nLzEwNS9tYXRlcmlhbHMvc2xpZGVzLTEwNS1vYXV0aC1zZXNzYS1qc29uLXdlYi10b2tl
bi1qd3QtcHJvZmlsZS1mb3Itb2F1dGgtMjAtYWNjZXNzLXRva2Vucy0wMi0wMDwvYT4uIFRoZSB1
c2Ugb2YgcmVzb3VyY2UgaW5kaWNhdG9ycyBmb3IgY2xpZW50IGNyZWQgZmxvd3MgaXMgY2VydGFp
bmx5IG5vdCBhIGRhcmsgcGxveSB0byBzbXVnZ2xlIHRoZSBBdXRoMCB3YXksIGluIGZhY3QgaXTi
gJlzDQogaW5mb3JtZWQgbW9yZSBieSBteSB3b3JrIG9uIEF6dXJlIEFELSB3aGVyZSBJIGZvdW5k
IHRoZSB0cmFuc2l0aW9uIGZyb20gcHNldWRvIHJlc291cmNlIGluZGljYXRvcnMgdG8gc2NvcGVz
IHRvIGJlIHJpZGRsZWQgYnkgY2hhbGxlbmdlcy4gT25jZSBhZ2FpbiwgYWxsIGRpc2N1c3Npb25z
IHdlcmUgbWFkZSBpbiBmdWxsIHRyYW5zcGFyZW5jeS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJnbWFpbC1tNjgwMTk4MzcwMDIxNjgyMzFtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIGNvbmNlcm5zIGFib3V0IHN5bW1ldHJpYyBhbGdvcml0
aG1zIGJlaW5nIGFsbG93ZWQsIHdoaWNoIHlvdSBhcmUgb2RkbHkgYnJpbmdpbmcgdXAgaW4gYSB0
d2VldCByYXRoZXIgdGhhbiBvbiB0aGUgbGlzdCwgYXJlIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBk
aXNjdXNzaW9uOiBwZW9wbGUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgZXhwbGljaXRseSBhc2tlZCBm
b3Igc3ltbWV0cmljIHRvIGJlIGFuIG9wdGlvbiBhbmQgZXZlbiB0byByZWxheCB0aGUNCiBjdXJy
ZW50IGxhbmd1YWdlIHRvIGJlIG1vcmUgcGVybWlzc2l2ZSwgd2hpY2ggSSBnZW50bHkgcHVzaGVk
IGJhY2sgYWdhaW5zdC4gQWdhaW4sIG5vdCBhbiBvYnNjdXJlIHBsb3kuPG86cD48L286cD48L2xp
PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIHNhZGRlbmVkIHRoYXQgeW91IGNob3NlIHRvIG1ha2Ug
dGhvc2Ugc3RhdGVtZW50cyBvbiB0d2l0dGVyLiBUaGVyZSB3YXMgbm90aGluZyBmb3IgeW91IHRv
IGRpc2NvdmVyLCBldmVyeXRoaW5nIHdhcyBhbHJlYWR5IG91dCBpbiB0aGUgb3Blbi4NCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3UgbWlnaHQgd2FudCB0byBjb25z
aWRlciByZXRyYWN0aW5nIHlvdXIgYWNjdXNhdGlvbnMuIEkgYW0gbm90IHdvcnJpZWQgYWJvdXQg
bXlzZWxmLCBteSBjb25zY2llbmNlIGlzIHBlcmZlY3RseSBjbGVhbiBhbmQgdGhlIElFVEYgcHJv
Y2VzcyByZWNvcmRzIGJhY2sgbWUgdXAsIGJ1dCBieSBzdWdnZXN0aW5nDQogbGFjayBvZiB0cmFu
c3BhcmVuY3kgeW91IGFyZSB1bmZhaXJseSBwb3J0cmF5aW5nIHRoZSBJRVRGLCBzdGFuZGFyZGl6
YXRpb24gcHJvY2VzcyBhbmQgdGhlIHBlb3BsZSB3aG8gZG8gdGhlaXIgYmVzdCB0byBjaGVjayBh
dCB0aGUgZG9vciB0aGVpciBhZmZpbGlhdGlvbnMgYW5kIGNvbnRyaWJ1dGUgdGhlaXIgdGltZSBh
bmQgZXhwZXJ0aXNlIGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgaW5kdXN0cnkgYXMgYSB3aG9sZS48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gYWRkaW5nIHRoZSB0d2VldHMgaGVyZSBm
b3IgcmVmZXJlbmNlLCB0b2dldGhlciB3aXRoIHRoZSB0cmFuc2xhdGlvbiBUd2l0dGVyIHByb3Zp
ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGFrYUBBdXRobGV0ZSwgQmFhUyBmb3Ig
T0F1dGggMi4wICZhbXA7IE9wZW5JRCBDb25uZWN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkBkYXJ1dGs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44KC44GX
44KE44Go5oCd44Gj44Gm6Kq/44G544Gm44G/44Gf44KJ44CBPC9zcGFuPkF1dGgwPHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yI44K544Oa44OD44Kv44Oq
44O844OJ44Gu5omA5bGe5LyB5qWt77yJ44GuPC9zcGFuPiBjbGllbnRfY3JlZGVudGlhbHMNCjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuODleODreODvOOB
ruWun+ijheOBrzwvc3Bhbj4gYXVkaWVuY2U8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
TVMgR290aGljJnF1b3Q7Ij7vvIg8L3NwYW4+UkZDIDg3MDcNCjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOBrjwvc3Bhbj4gcmVzb3VyY2UgPHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+DQrnm7jlvZPvvInjgYzlv4Xp
oIjjgafjgIHnlJ/miJDjgZnjgos8L3NwYW4+IEpXVCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgqLjgq/jgrvjgrnjg4jjg7zjgq/jg7Pjga48L3NwYW4+
IHN1Yg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gr
44Kv44Op44Kk44Ki44Oz44OIPC9zcGFuPiBJRCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TVMgR290aGljJnF1b3Q7Ij4NCuOCkuWfi+OCgei+vOOCgOOAgjwvc3Bhbj5KV1QgPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Ki44Kv44K744K544OI
44O844Kv44Oz5LuV5qeY44OJ44Op44OV44OI44GM5q2q44KT44Gn44GE44KL44Gu44Gv44GT44KM
44GM55CG55Sx44Gg44KN44GG44CCPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5TdWRkZW5seSwgSSBzZWFyY2hlZCBhbmQgdGhvdWdodCwgaW1wbGVtZW50YXRp
b24gb2YgY2xpZW50X2NyZWRlbnRpYWxzIGZsb3cgb2YgQXV0aDAgKGNvbXBhbnkgb2YgU3BlYyBM
ZWFkKSByZXF1aXJlcyBhdWRpZW5jZSAoZXF1aXZhbGVudCB0byByZXNvdXJjZSBvZiBSRkMgODcw
NyksIGFuZCBlbWJlZCBjbGllbnQNCiBJRCBpbiBzdWIgb2YgZ2VuZXJhdGVkIEpXVCBhY2Nlc3Mg
dG9rZW4uIFRoaXMgaXMgcHJvYmFibHkgdGhlIHJlYXNvbiB3aHkgdGhlIEpXVCBhY2Nlc3MgdG9r
ZW4gc3BlY2lmaWNhdGlvbiBkcmFmdCBpcyBkaXN0b3J0ZWQuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7l
hYPjgIU8L3NwYW4+IEF1dGgwDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWlu
Y2hvJnF1b3Q7Ij7jga7nj77lrp/oo4XjgpLmpa3nlYzjgavoqo3jgoHjgZXjgZvjgovjgZ/jgoHj
gas8L3NwYW4+IEpXVCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1
b3Q7Ij4NCuOCouOCr+OCu+OCueODiOODvOOCr+ODs+aomea6luS7leanmOetluWumuS9nOalreOB
jOmWi+Wni+OBleOCjOOBn+OBqOWZguOBp+OBr+iBnuOBhOOBpuOBhOOBn+OBjOOAgeWun+mam+OB
q+OBneOBhuOBoOOBo+OBn+OBi+OAguaKgOihk+eahOOBq+S4jeiHqueEtuOBqueCueOBjOWkmuOB
hOOBl+ijj+S6i+aDheOBjOOBr+OBo+OBjeOCiuOBl+OBn+S7iuOBqOOBquOBo+OBpuOBr+m7meOB
o+OBpuOBhOOCi+ios+OBq+OCguOBhOOBi+OBquOBhOOBruOBp+OAgeODoeODvOODquODs+OCsOOD
quOCueODiOOBp+aEj+imi+OCkui/sOOBueOBn+OAgjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv
b2F1dGgvSnkxZnBhcjZMS25OWF96cG9UN19mcEN6QlNnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvSnkxZnBhcjZMS25OWF96cG9U
N19mcEN6QlNnLzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSd2
ZSBoZWFyZCBydW1vcnMgdGhhdCB0aGUgSldUIEFjY2VzcyBUb2tlbiBzdGFuZGFyZCBzcGVjaWZp
Y2F0aW9uIHdvcmsgd2FzIHN0YXJ0ZWQgdG8gZ2V0IHRoZSBpbmR1c3RyeSB0byBhY2NlcHQgdGhl
IGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgQXV0aDAsIGJ1dCB3YXMgdGhhdCByZWFsbHkgdGhl
IGNhc2U/DQogU2luY2UgdGhlcmUgYXJlIG1hbnkgdGVjaG5pY2FsIHVubmF0dXJhbCBwb2ludHMg
YW5kIGl0IGlzIGltcG9zc2libGUgdG8ga2VlcCBzaWxlbnQgbm93IHRoYXQgdGhlIGNpcmN1bXN0
YW5jZXMgYXJlIGNsZWFyLCBJIG1hZGUgYW4gb3BpbmlvbiBvbiB0aGUgbWFpbGluZyBsaXN0Ljxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O01TIEdvdGhpYyZxdW90OyI+44Gk44GE44Gn44Gr6KiA44Gj44Gm44GK44GP44Go44CBPC9zcGFu
PkF1dGgwDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7j
gYznlJ/miJDjgZnjgos8L3NwYW4+IEpXVCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
TVMgR290aGljJnF1b3Q7Ij4NCuOCouOCr+OCu+OCueODiOODvOOCr+ODs+OBrue9suWQjeOCouOD
q+OCtOODquOCuuODoOOBqOOBl+OBpumBuOaKnuOBp+OBjeOCi+OBruOBr+OAgTwvc3Bhbj5IUzI1
NiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgag8L3Nw
YW4+IFJTMjU2DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7
Ij7jga7jgb/jga7jgojjgYbjgaDjgII8L3NwYW4+SFMyNTYgPHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+DQrjga/lr77np7DpjbXns7vjgqLjg6vjgrTjg6rj
grrjg6DjgILkuIDmlrnjga48L3NwYW4+IFJTMjU2IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOBr+mdnuWvvuensOmNteezu+OCouODq+OCtOODquOCuuOD
oOOBoOOBjOOAgeOCu+OCreODpeODquODhuOCo+ODvOS4iuOBrueQhueUseOBpzwvc3Bhbj4gRmlu
YW5jaWFsLWdyYWRlIEFQSSBQYXJ0IDINCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN
UyBHb3RoaWMmcXVvdDsiPuOBp+OBr+S9v+eUqOemgeatouOBqOOBleOCjOOBpuOBhOOCi+OAgjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5jaWRlbnRhbGx5
LCBpdCBzZWVtcyB0aGF0IG9ubHkgSFMyNTYgYW5kIFJTMjU2IGNhbiBiZSBzZWxlY3RlZCBhcyB0
aGUgc2lnbmF0dXJlIGFsZ29yaXRobSBmb3IgdGhlIEpXVCBhY2Nlc3MgdG9rZW4gZ2VuZXJhdGVk
IGJ5IEF1dGgwLiBIUzI1NiBpcyBhIHN5bW1ldHJpYyBrZXkgYWxnb3JpdGhtLiBPbiB0aGUNCiBv
dGhlciBoYW5kLCBSUzI1NiBpcyBhbiBhc3ltbWV0cmljIGtleSBhbGdvcml0aG0sIGJ1dCBmb3Ig
c2VjdXJpdHkgcmVhc29ucywgaXQgaXMgcHJvaGliaXRlZCBpbiBGaW5hbmNpYWwtZ3JhZGUgQVBJ
IFBhcnQgMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDs8
YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgVGFrYWhpa28gS2F3YXNh
a2kgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWthQGF1dGhsZXRlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnRha2FAYXV0aGxldGUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEFw
cmlsIDIzLCAyMDIwIGF0IDE4OjAxPGJyPg0KPGI+VG86IDwvYj5vYXV0aCAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRv
Y2NpPTxhIGhyZWY9Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0
OiA8L2I+UmU6IFtPQVVUSC1XR10gU2Vjb25kIFdHTEMgb24gJnF1b3Q7SlNPTiBXZWIgVG9rZW4g
KEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBUb2tlbnMmcXVvdDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J
IGFwb2xvZ2l6ZSBpZiBteSBwcmV2aW91cyBwb3N0IGhhcyBtYWRlIHlvdSBhbGwgaGVyZSBmZWVs
IHVucGxlYXNhbnQsIGVzcGVjaWFsbHkgSSdtIHNvcnJ5IGZvciB0aGUgYXV0aG9yLCB0aGUgY2hh
aXJzLCBhbmQgcGVvcGxlIHdobyBkaXJlY3RseSBqb2luZWQgdGhlIGRpc2N1c3Npb24gYWJvdXQg
dGhlIHNwZWMuDQogSSBjb3VsZCBoYXZlIGV4cHJlc3NlZCBteSBkaXNhZ3JlZW1lbnQgb24gdGhl
IHJlcXVpcmVtZW50cyBmb3IgJnF1b3Q7YXVkJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDsgaW4g
YW5vdGhlciBkaWZmZXJlbnQgd2F5LiBGb3Igc29mdHdhcmUgc3BlY2lmaWNhdGlvbnMgYW5kIGFy
Y2hpdGVjdHVyZXMsIEknbSBsaWFibGUgdG8gZ2V0IGV4Y2l0ZWQgYW5kIGFnZ3Jlc3NpdmUuIFBs
ZWFzZSBmb3JnaXZlIG1lLjxicj4NCjxicj4NClJlZ2FyZGluZyB0aGUgcmVsYXRpb25zaGlwIGJl
dHdlZW4gJnF1b3Q7YXVkJnF1b3Q7IGFuZCAmcXVvdDtzY29wZSZxdW90OywgdGhlIGFzc3VtcHRp
b24gaW4gdGhlIGRyYWZ0IGlzIG5vdCBuZWNlc3NhcmlseSBhcHBsaWNhYmxlIHRvIGFsbCBwb3Nz
aWJsZSB1c2UgY2FzZXMuIEZvciBleGFtcGxlLCBtdWx0aXBsZSByZXNvdXJjZXMgbWF5IHNoYXJl
IHRoZSBzYW1lIHNjb3Blcy4gV2hhdCBpZiBib3RoICZxdW90Oy9yZXNvdXJjZTEmcXVvdDsgYW5k
ICZxdW90Oy9yZXNvdXJjZTImcXVvdDsgcmVjb2duaXplICZxdW90O2dldCZxdW90Ow0KIHNjb3Bl
IGFuZCAmcXVvdDt1cGRhdGUmcXVvdDsgc2NvcGU/IEluIHRoaXMgY2FzZSwgaXQgaXMgbm90IGFw
cHJvcHJpYXRlIHRvIGRldGVybWluZSB0aGUgZGVmYXVsdCByZXNvdXJjZSBpbmRpY2F0b3IgZm9y
ICZxdW90O2F1ZCZxdW90OyBmcm9tIHRoZSBzY29wZXMuIEl0IGlzIGFsc28gaW1wb3NzaWJsZSB0
byBtYXAgc2NvcGVzIHRvIHJlc291cmNlcyBhbmQgdmljZSB2ZXJzYS4gVGhlIGFzc3VtcHRpb24g
aW4gdGhlIGN1cnJlbnQgZHJhZnQgaXMgdG9vIG5hcnJvdyB0byBiZSBpbmNsdWRlZA0KIGluIGEg
c3RhbmRhcmQuLiBJZiB0aGUgY3VycmVudCBkZXNjcmlwdGlvbiBjb250aW51ZXMgdG8gZXhpc3Qs
IGl0IHdpbGwgaW1wb3NlIGJpZyByZXN0cmljdGlvbnMgb24gdGhlIGRlc2lnbiBvZiBzY29wZXMg
YW5kIHJlc291cmNlcy48YnI+DQo8YnI+DQpJZiB5b3Ugc3RpbGwgdGhpbmsgdGhlICZxdW90O2F1
ZCZxdW90OyBjbGFpbSBzaG91bGQgYWx3YXlzIGV4aXN0LCB0aGVuIHRoZSBhdXRob3JpemF0aW9u
IGVuZHBvaW50IGFuZC9vciB0aGUgdG9rZW4gZW5kcG9pbnQgKGFuZC9vciB0aGUgYmFja2NoYW5u
ZWwgYXV0aGVudGljYXRpb24gZW5kcG9pbnQgYW5kL29yIHRoZSBkZXZpY2UgYXV0aG9yaXphdGlv
biBlbmRwb2ludCkgb2YgeW91ciBzeXN0ZW0gY2FuIHJlcXVpcmUgdGhlICZxdW90O3Jlc291cmNl
JnF1b3Q7IHJlcXVlc3QgcGFyYW1ldGVyDQogYXMgbWFuZGF0b3J5LiBXZSBkb24ndCBoYXZlIHRv
IHB1dCBydWxlcyB0byBkZXRlcm1pbmUgdGhlIGRlZmF1bHQgJnF1b3Q7YXVkJnF1b3Q7IHZhbHVl
IGludG8gdGhlIHNwZWMgYWJvdXQgSldUIGFjY2VzcyB0b2tlbnMuIFRoZSAmcXVvdDtyZXNvdXJj
ZSZxdW90OyBwYXJhbWV0ZXIgZGVmaW5lZCBpbiBSRkMgODcwNyBjYW4gd29yayByZWdhcmRsZXNz
IG9mIHdoZXRoZXIgdGhlIGZvcm1hdCBvZiBhY2Nlc3MgdG9rZW5zIGlzIEpXVCBvciBub3QuIFRo
ZXJlZm9yZSwgaXQgaXMgbm90DQogYXBwcm9wcmlhdGUgdG8gZGlzY3VzcyB0aGUgbmVjZXNzaXR5
IG9mIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gb25seSBpbiB0aGUgY29udGV4dCBvZiAmcXVv
dDtKV1QmcXVvdDsgYWNjZXNzIHRva2Vucy48YnI+DQo8YnI+DQpSZWdhcmRpbmcgdGhlICZxdW90
O3N1YiZxdW90OyBjbGFpbSwgc2V0dGluZyB0aGUgY2xpZW50IElEIHRoZXJlLCByYXRoZXIsIHdp
bGwgY29uZnVzZSByZXNvdXJjZSBzZXJ2ZXJzLiBJZiB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNsYWlt
IGlzIHNldCBldmVuIGluIHRoZSBjYXNlIG9mIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZmxvdywg
cmVzb3VyY2Ugc2VydmVycyBjYW5ub3QganVkZ2Ugd2hldGhlciB0aGUgJnF1b3Q7c3ViJnF1b3Q7
IGNsYWltIHJlcHJlc2VudHMgZWl0aGVyIHRoZSBzdWJqZWN0IG9mDQogdGhlIHJlc291cmNlIG93
bmVyIG9yIHRoZSBjbGllbnQgSUQuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgJnF1b3Q7c3Vi
JnF1b3Q7IGNsYWltIGlzIG51bGwgb3IgYWJzZW50IGluIHRoZSBjYXNlIG9mIHRoZSBjbGllbnQg
Y3JlZGVudGlhbHMgZmxvdywgcmVzb3VyY2Ugc2VydmVycyBjYW4gYWx3YXlzIGhhbmRsZSB0aGUg
dmFsdWUgb2YgdGhlICZxdW90O3N1YiZxdW90OyBjbGFpbSBhcyB0aGUgc3ViamVjdCBvZiB0aGUg
cmVzb3VyY2Ugb3duZXIuIEZvciByZXNvdXJjZSBzZXJ2ZXJzLA0KIHRoaXMgbG9naWMgaXMgZWFz
aWVyLiBTZXR0aW5nIHRoZSAmcXVvdDtzdWImcXVvdDsgY2xhaW0gaW4gZXZlcnkgY2FzZSB0byBt
YWtlIHJlc291cmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgc2ltcGxlciBpcyBub3QgY29udmlu
Y2luZy4NCjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpUYWthPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBcHIgMjQsIDIwMjAg
YXQgMjoxNSBBTSBUYWthaGlrbyBLYXdhc2FraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRha2FAYXV0
aGxldGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFrYUBhdXRobGV0ZS5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GaXJzdCwg
dG8gbWFrZSB0aGUgZGlzY3Vzc2lvbiBmYWlyLCBJIHRoaW5rIEkgc2hvdWxkIHNoYXJlIHdoYXQg
SSBvYnNlcnZlZCB0b2RheS4gQXV0aDAncyBjbGllbnRfY3JlZGVudGlhbHMgZmxvdyByZXF1aXJl
cyBhbiAmcXVvdDthdWRpZW5jZSZxdW90OyBwYXJhbWV0ZXIsIHdoaWNoIGlzIGVxdWl2YWxlbnQg
dG8gdGhlICZxdW90O3Jlc291cmNlJnF1b3Q7DQogcGFyYW1ldGVyIGRlZmluZWQgaW4gUkZDIDg3
MDcsIGFuZCBlbWJlZHMgdGhlIGNsaWVudCBJRCBpbiB0aGUgZ2VuZXJhdGVkIEpXVCBhY2Nlc3Mg
dG9rZW4gYXMgdGhlIHZhbHVlIG9mIHRoZSAmcXVvdDtzdWImcXVvdDsgY2xhaW0uPGJyPg0KPGJy
Pg0KTXkgb3BpbmlvbiBhcyBhIHNvZnR3YXJlIGVuZ2luZWVyIGlzIGFzIGZvbGxvd3MuPGJyPg0K
PGJyPg0KW2F1ZF08YnI+DQpUaGUgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltIHNob3VsZCBiZSBudWxs
IG9yIGFic2VudCB3aGVuIHRoZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXJzIGFyZSBu
b3QgZ2l2ZW4gaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBJdCBpcyBub3QgZ29vZCB0byBp
bnRyb2R1Y2UgaW5mbGV4aWJsZSBydWxlcyB0byBkZXRlcm1pbmUgdGhlIGRlZmF1bHQgdmFsdWUg
Zm9yIHRoZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0gYmFzZWQgb24gdGhlICZxdW90O3Njb3BlJnF1
b3Q7IHBhcmFtZXRlci48YnI+DQo8YnI+DQpbc3ViXTxicj4NClRoZSAmcXVvdDtzdWImcXVvdDsg
Y2xhaW0gc2hvdWxkIGJlIG51bGwgb3IgYWJzZW50IHdoZW4gYSByZXNvdXJjZSBvd25lciBpcyBu
b3QgaW52b2x2ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUbyBiZSBjb25jcmV0ZSwg
dGhlICZxdW90O3N1YiZxdW90OyBjbGFpbSBzaG91bGQgYmUgbnVsbCBvciBhYnNlbnQgaW4gdGhl
IGNsaWVudCBjcmVkZW50aWFscyBmbG93LiBUaGUgc3BlYyBkcmFmdCBzYXlzIGluICZxdW90OzUu
IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zJnF1b3Q7IGFzIGZvbGxvd3MuPGJyPg0KPGJyPg0KLSAt
IC0gLSAtIC0gLSAtIC0gLTxicj4NCkF1dGhvcml6YXRpb24gc2VydmVycyBzaG91bGQgcHJldmVu
dCBzY2VuYXJpb3Mgd2hlcmUgY2xpZW50cyBjYW4gYWZmZWN0IHRoZSB2YWx1ZSBvZiB0aGUgc3Vi
IGNsYWltIGluIHdheXMgdGhhdCBjb3VsZCBjb25mdXNlIHJlc291cmNlIHNlcnZlcnMuJm5ic3A7
IEZvciBleGFtcGxlOiBpZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZWxlY3RzIHRvIHVzZSB0
aGUgY2xpZW50X2lkIGFzIHRoZSBzdWIgdmFsdWUgZm9yIGFjY2VzcyB0b2tlbnMgaXNzdWVkIGNs
aWVudA0KIGNyZWRlbnRpYWxzIGdyYW50LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxk
IHByZXZlbnQgY2xpZW50cyB0byByZWdpc3RlciBhbiBhcmJpdHJhcnkgY2xpZW50X2lkIHZhbHVl
LCBhcyB0aGlzIHdvdWxkIGFsbG93IG1hbGljaW91cyBjbGllbnRzIHRvIHNlbGVjdCB0aGUgc3Vi
IG9mIGEgaGlnaCBwcml2aWxlZ2UgcmVzb3VyY2Ugb3duZXIgYW5kIGNvbmZ1c2UgYW55IGF1dGhv
cml6YXRpb24gbG9naWMgb24gdGhlIHJlc291cmNlIHNlcnZlcg0KIHJlbHlpbmcgb24gdGhlIHN1
YiB2YWx1ZS4mbmJzcDsgRm9yIG1vcmUgZGV0YWlscyBwbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA0
LjEzIG9mIFtPQXV0aDIuU2VjdXJpdHkuQmVzdFByYWN0aWNlc10uPGJyPg0KPGJyPg0KVG8gcHJl
dmVudGluZyBjcm9zcy1KV1QgY29uZnVzaW9uLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCB1
c2UgYSBkaXN0aW5jdCBpZGVudGlmaWVyIGFzICZxdW90O2F1ZCZxdW90OyBjbGFpbSB2YWx1ZSB0
byB1bmlxdWVseSBpZGVudGlmeSBhY2Nlc3MgdG9rZW5zIGlzc3VlZCBieSB0aGUgc2FtZSBpc3N1
ZXIgZm9yIGRpc3RpbmN0IHJlc291cmNlcy48YnI+DQotIC0gLSAtIC0gLSAtIC0gLSAtPGJyPg0K
PGJyPg0KSG93ZXZlciwgdGhlIGF0dGFjayB2ZWN0b3IgaXMgYnJvdWdodCBhYm91dCBtZXJlbHkg
YnkgaW50cm9kdWNpbmcgdGhlIGZvbGxvd2luZyBydWxlIGRlZmluZWQgaW4gJnF1b3Q7Mi4yLiBE
YXRhIFN0cnVjdHVyZSZxdW90Oy48YnI+DQo8YnI+DQotIC0gLSAtIC0gLSAtIC0gLSAtPGJyPg0K
SW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5v
IHJlc291cmNlIG93bmVyIGlzIGludm9sdmVkLCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlh
bHMgZ3JhbnQsIHRoZSB2YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRp
ZmllciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50
IGFwcGxpY2F0aW9uLjxicj4NCi0gLSAtIC0gLSAtIC0gLSAtIC08YnI+DQo8YnI+DQpJZiB0aGUg
cnVsZSBpcyBub3QgaW50cm9kdWNlZCwgdGhlIGF0dGFjayB2ZWN0b3IgZGlzYXBwZWFycyBhbmQg
dGhlICZxdW90O2F1ZCZxdW90OyBjbGFpbSBkb2Vzbid0IGhhdmUgdG8gYmUgbWFuZGF0b3J5Ljxi
cj4NCjxicj4NCkZpbmFsbHksIHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gZmFpciwgSSBzaG91bGQg
YWxzbyBtZW50aW9uIHRoYXQgSSBteXNlbGYgaXMgYSBjby1mb3VuZGVyIG9mIEF1dGhsZXRlLCBJ
bmMuIHRoYXQgcHJvdmlkZXMgYW4gaW1wbGVtZW50YXRpb24gb2YgT0F1dGggYW5kIE9wZW5JRCBD
b25uZWN0LiBNeSB0aG91Z2h0cyBhYm91dCBpbXBsZW1lbnRhdGlvbnMgb2YgYWNjZXNzIHRva2Vu
cyBhcmUgcHVibGljbHkgZGVzY3JpYmVkIGhlcmU6PGJyPg0KPGJyPg0KT0F1dGggQWNjZXNzIFRv
a2VuIEltcGxlbWVudGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9tZWRpdW0uY29tL0BkYXJ1
dGsvb2F1dGgtYWNjZXNzLXRva2VuLWltcGxlbWVudGF0aW9uLTMwYzJlOGI5MGZmMCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vbWVkaXVtLmNvbS9AZGFydXRrL29hdXRoLWFjY2Vzcy10b2tlbi1p
bXBsZW1lbnRhdGlvbi0zMGMyZThiOTBmZjA8L2E+PGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzLDxi
cj4NClRha2FoaWtvIEthd2FzYWtpPGJyPg0KQXV0aGxldGUsIEluYy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEFwciAyMiwgMjAyMCBh
dCA0OjE5IEFNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVm
PSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1
dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdWNoISBTb3JyeQ0KPHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyODUyMjs8
L3NwYW4+IGZpeGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+
RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh
Y2siPkRvbWluaWNrIEJhaWVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmls
ZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRiYWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0
Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBBcHJpbCAyMSwgMjAyMCBhdCAxMDoyMzxicj4N
CjxiPlRvOiA8L2I+b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDssIFJpZmFhdCBTaGVraC1ZdXNlZiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i
PlJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICZxdW90O0pTT04gV2ViIFRva2VuIChKV1Qp
IFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zJnF1b3Q7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PaCBhbmQgd2hp
bGUgd2UgYXJlIGF0IGl0IC0gY291bGQgeW91IGFsc28gZml4IHRoZSB0eXBvIGluIG15IG5hbWU/
IFRoYW5rcyA7KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPuKAlOKAlOKAlA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5Eb21pbmljayBCYWllcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PbiAyMS4gQXByaWwg
MjAyMCBhdCAwOTo0Mzo0OSwgVml0dG9yaW8gQmVydG9jY2kgKDxhIGhyZWY9Im1haWx0bzp2aXR0
b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5rIj52aXR0b3Jpby5iZXJ0b2Nj
aUBhdXRoMC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIGEgZ3JlYXQgcG9pbnQuIEluIG15
IGhlYWQgSSBqdXN0IGNvbnNpZGVyZWQgdGhlIE9JREMgc2VtYW50aWMgYW5kIHRob3VnaHQgb25s
eSBvZiBoaWdobGlnaHRpbmcgdGhlIGFwcCBpZGVudGl0eSBjYXNlLCBidXQgeW91IGFyZSBhYnNv
bHV0ZWx5IHJpZ2h0IHRoYXQgbm90IG1lbnRpb25pbmcgdGhlDQogdXNlciBjYXNlIGF0IGFsbCBp
cyBjb25mdXNpbmcuIEkgYWRkZWQgdGhlIGxhbmd1YWdlIHlvdSBzdWdnZXN0ZWQgYXQgdGhlIGJl
Z2lubmluZyBvZiB0aGUgc3ViIGRlZmluaXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y
OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj
b2xvcjpibGFjayI+RG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVh
c3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNv
bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgQXByaWwgMjAsIDIwMjAgYXQgMjI6
NTQ8YnI+DQo8Yj5UbzogPC9iPm9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7LCBSaWZhYXQgU2hla2gt
WXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0i
X2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp
bHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpdHRvcmlv
LmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpdHRv
cmlvLmJlcnRvY2NpQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpdHRvcmlvLmJlcnRvY2Np
QGF1dGgwLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBbT0FVVEgtV0ddIFNl
Y29uZCBXR0xDIG9uICZxdW90O0pTT04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRo
IDIuMCBBY2Nlc3MgVG9rZW5zJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+SW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9idGFpbmVkIHRocm91
Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVkLCBzdWNoIGFzIHRo
ZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHRoZSB2YWx1ZSBvZiBzdWIgU0hPVUxEIGNvcnJl
c3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0byBp
bmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWF5YmUgSSBhbSBtaXNz
aW5nIHNvbWV0aGluZywgYnV0IGRvZXMgaXQgc2F5IGFueXdoZXJlIHdoYXQgdG8gZXhwbGljaXRs
eSBkbyBpbiB0aGUgY2FzZSBvZiBhbiBhY2Nlc3MgdG9rZW4gd2hlcmUgYSByZXNvdXJjZSBvd25l
ciBpcyBpbnZvbHZlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRoZXJl4oCZcyBzb21lIGxhbmd1YWdlIHRoYXQgc2VlbXMgdG8gaW1w
bHkgdGhhdCwgZS5nLjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0
eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRlci1ib3g7Ym9yZGVyLXJh
ZGl1czo0cHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7b3ZlcmZsb3c6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90
OyI+YXMgdGhpcyB3b3VsZCBhbGxvdyBtYWxpY2lvdXM8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY2xp
ZW50cyB0byBzZWxlY3QgdGhlIHN1YiBvZiBhIGhpZ2ggcHJpdmlsZWdlIHJlc291cmNlIG93bmVy
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkkgd291bGQgaGF2ZSBleHBlY3RlZCB0byBzZWUgc29tZXRoaW5nIHN0cm9uZ2VyIGxp
a2UgYWJvdmUganVzdCAtJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4gY2FzZSBvZiBhY2Nlc3MgdG9r
ZW5zIG9idGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIGEgcmVzb3VyY2Ugb3duZXIgaXMgaW52
b2x2ZWQsIHN1Y2ggYXMgdGhlIGF1dGhvcmlzYXRpb24gY29kZSBncmFudCwgdGhlIHZhbHVlIG9m
IHN1YiBTSE9VTEQgY29ycmVzcG9uZCB0byB0aGUgc3ViamVjdCBpZGVudGlmaWVyIG9mIHRoZSBy
ZXNvdXJjZSBvd25lci48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHRoaXMgc3BlYyBpcyBhYm91dCBpbnRlcm9wLCBJ
IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGF0IGxlYXN0IGEgcmVjb21tZW5kYXRpb24uLi48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJTigJTigJQNCjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9taW5pY2sgQmFpZXI8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+T24gMjAuIEFwcmlsIDIwMjAgYXQgMDk6NDg6NTEsIDxh
IGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC4uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+DQp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208L2E+ICg8YSBocmVmPSJtYWlsdG86dml0
dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+dml0dG9yaW8uYmVydG9j
Y2lAYXV0aDAuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIERvbWluaWNrIGZvciB5b3VyIGNv
bW1lbnRzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmU8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPiZndDs8L2k+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4gQWxsIG90aGVyIE9BdXRoIHNwZWNz
IG1ha2UgYSB2ZXJ5IGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlcnMgYW5kIGNsaWVudC48
L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZeKA
mXMgYSBudWFuY2Ugd29ydGggaGlnaGxpZ2h0aW5nIGhlcmU6IHN1YiAhPSB1c2VyLiBJbiBwcmV2
aW91cyBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGl0IGhhcyBiZWVuIGJyb3VnaHQgdXAgdGhh
dCB0aGUgSldUIHNwZWMgZGVmaW5lcyBzdWIgYXMgaWRlbnRpZnlpbmcgdGhlIHByaW5jaXBhbCB0
aGF0DQogaXMgdGhlIHN1YmplY3Qgb2YgdGhlIEpXVCwgYW5kIHRoYXTigJlzIG5vdCBuZWNlc3Nh
cmlseSBsaW1pdGVkIHRvIHVzZXJzLiA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5Ib3dldmVyIEkgZ2V0IHRoZSBwb3RlbnRpYWwgY29uZnVzaW9uLCBhbmQgSSBhbSBoYXBw
eSB0byBhZGQgY2xhcmlmeWluZyBsYW5ndWFnZSBpZiB5b3UgaGF2ZSBzcGVjaWZpYyBwYXNzYWdl
cyBpbiB0aGUgc3BhY2UgeW91IGFyZSBwYXJ0aWN1bGFybHkgd29ycmllZCBhYm91dDogaG93ZXZl
ciBJIGZlZWwgdGhlIG1hdHRlciBpcyBhZGRyZXNzZWQgdXBmcm9udCBieSB0aGUgbGFuZ3VhZ2Ug
aW4gU2VjdGlvbiAyLjIuIGluIHRoZSBzdWIgZW50cnksIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+SW4gY2FzZSBvZiBhY2Nlc3MgdG9rZW5zIG9i
dGFpbmVkIHRocm91Z2ggZ3JhbnRzIHdoZXJlIG5vIHJlc291cmNlIG93bmVyIGlzIGludm9sdmVk
LCBzdWNoIGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQsIHRoZSB2YWx1ZSBvZiBzdWIg
U0hPVUxEIGNvcnJlc3BvbmQgdG8gYW4gaWRlbnRpZmllciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIgdXNlcyB0byBpbmRpY2F0ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uLuKAnDwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBhbmQgU2VjdGlvbiA1IGhhcyBhbiBlbnRpcmUgcGFy
YWdyYXBoIGRpc2N1c3NpbmcgdGhpbmdzIHRvIHdhdGNoIG91dCBpbiBhc3NpZ25pbmcgc3ViIHZh
bHVlcyBpbiB0aGUgYXBwIGlkZW50aXR5IGNhc2UuIEZlZWwgZnJlZSB0byBzdWdnZXN0IGFkZGl0
aW9uYWwgbGFuZ3VhZ2UgaWYgeW91IHdhbnQgdG8gY2xhcmlmeSBmdXJ0aGVyLiA8L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jmd0OyBzdWIgaGFzIGEgZGlmZmVyZW50IHNlbWFu
dGljIGhlcmUgYXMgaW4gT0lEQzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlRoZSAmbmJzcDtzcGVjIHJlZmVycyB0byBSRkM3NTE5IGluIHRoZSBzdWIg
ZGVmaW5pdGlvbiBpbiAyLjIsIHJhdGhlciB0aGFuIE9JREMsIHRvIHByZWVtcHQgdGhhdCBjb25j
ZXJuIGFuZCBrZWVwIHRoZSBvcmlnaW5hbCBzdWIgc2VtYW50aWMgYXZhaWxhYmxlLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+Jmd0OzwvaT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiBJIGFtIG5vdCBmdWxseSBjbGVhciB3aHkg
YXVkIGlzIHJlcXVpcmVkLjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkF1ZCBpcyB0aGVyZSBtb3N0bHkgYmVjYXVzZSBvZiB0aHJlZSByZWFzb25zOjxv
OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5LjBwdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+TWFueSBleGlzdGluZyBzcGVjcyBwb3N0dWxhdGUgaXRzIGV4aXN0ZW5jZSBpbiB0
aGUgdG9rZW4uIE5vIG9uZSBkZWNsYXJlcyBpdCBhcyBhIHByb3BlciBNVVNUIChhcGFydCBmcm9t
IHRoZSBCQ1AsIGJ1dCB0aGF04oCZcyBwYXJ0aWFsKSBob3dldmVyIEkgdGhpbmsgaXRzIGltcG9y
dGFuY2UgY29tZXMgYWNyb3NzLi48YnI+DQotQmVhcmVyIHRva2VuIHVzYWdlIFJGQzY3NTAgY2Fs
bHMgaXQgb3V0IChpbiB0aHJlYXQgbWl0aWdhdGlvbikgYXMgdGhlIG1lY2hhbmlzbSB0byBwcmV2
ZW50IHRva2VuIHJlZGlyZWN0IChhbmQgYWRkcyBzY29wZSByZXN0cmljdGlvbiBhcyBhbHNvIGlt
cG9ydGFudCwgaG93ZXZlciBoZXJlIHdlIG1ha2UgaXQgb3B0aW9uYWwgdG8gYWNvY3V0IGZvciBu
b24tZGVsZWdhdGlvbnMgc2NlbmFyaW8pLjxicj4NCi1SZXNvdXJjZSBpbmRpY2F0b3JzIFJGQzg3
MDcgcmVmZXJzIHRvIHRoZSBzYW1lIHNlY3Rpb24gb2YgUkZDNzUxOSBhcyBvbmUgb2YgdGhlIGFz
c3VtcHRpb25zIHRoYXQgbXVzdCBob2xkIHRvIHByZXZlbnQgYmVhcmVyIHRva2VucyBtaXN1c2UN
Cjxicj4NCi1CQ1AyMjUgbWFrZXMgYXVkIG1hbmRhdG9yeSBmb3IgQVMgd2hpY2ggY2FuIGlzc3Vl
IEpXVHMgZm9yIG1vcmUgdGhhbiBvbmUgYXBwPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzkuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5BcGFydCBmcm9tIFBpbmcsIGZv
ciB3aGljaCBzb21lIG9mIGl0cyBleGFtcGxlcyBhcmUgd2l0aG91dCBhdWQgKGJ1dCBhbHNvIHdp
dGhvdXQgaWRlbnRpZnlpbmcgc2NvcGVzLCBnaXZlbiB0aGF0IHRoZSBvbmUgSSByZXRyaWV2ZWQg
aGFkIG9ubHkg4oCcb3Blbmlk4oCdKSwgYWxsIG9mIHRoZSBzYW1wbGUgSldUIEFUcyBJIHJlY2Vp
dmVkIGZyb20gdmVuZG9ycyBhbGwgZmVhdHVyZWQgYW4gYXVkLiBJIGtub3cgb25lIHNob3VsbmTi
gJl0IG92ZXJpbmRleA0KIG9uIHRob3NlIGV4YW1wbGVzLCBidXQgdG9nZXRoZXIgd2l0aCB0aGUg
YWJvdmUgaXQgc2VlbWVkIHRvIHBvaW50IHRvIHNvbWV0aGluZyB1bml2ZXJzYWxseSB1c2VmdWwu
IE9uZSBwb3NzaWJsZSByZWFzb24gaXMgdGhhdCB1c2Ugb2YgYSBmb3JtYXQgZm9yIHRoZSBBVCBp
cyBjb3JyZWxhdGVkIHdpdGggdG9wb2xvZ2llcyB3aGVyZSBBUyBhbmQgUlMgYXJlIHNlcGFyYXRl
ZCBieSBzb21lIGJvdW5kYXJ5IChuZXR3b3JrLCBsb2dpY2FsLCBidXNpbmVzcywNCiBjb2RlIGZh
Y3RvcmluZywgZXRjKSBoZW5jZSBpZGVudGlmeWluZyB0aGUgcmVzb3VyY2Ugc2VlbXMgbGlrZSBh
IG5hdHVyYWwgbmVlZC4gQWdhaW4sIG5vdCBhbiBpcm9uIGNsYWQgbGF3LCBidXQgYW4gaW5kaWNh
dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozOS4wcHQiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOw0KPC9zcGFuPkEgbG90IG9mIHBlb3BsZSByZXB1cnBvc2UgZXhpc3RpbmcgbGlicmFy
aWVzIGZvciB0aGUgSldUIEFUIGNhc2UsIGFuZCBzb21lIHBlb3BsZSBldmVuIHNlbmRzIGlkX3Rv
a2VucyBpbiBsaWV1IG9mIEFUcy4gVGhhdCBkb2VzbuKAmXQgbWVhbiB0aGF0IHdlIHNob3VsZCBj
b25kb25lIGFueSBiYWQgcHJhY3RpY2VzLCBidXQgaW4gdGlzIHBhcnRpY3VsYXIgY2FzZSBpdCBz
dWdnZXN0cyB0aGF0IGxvdHMgb2YgZGV2ZWxvcGVycyBhbHJlYWR5DQogZXhwZWN0L2NhbiBoYW5k
bGUgYW4gYXVkaWVuY2UgaW4gdGhlIEpXVCB1c2VkIHRvIGNhbGwgdGhlaXIgQVBJPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vbmUgb2YgdGhvc2UgYXJlIGEgc2xhbSBk
dW5rIGFyZ3VtZW50IGZvciBtYW5kYXRvcnksIGJ1dCBJIGZpbmQgdGhlbSBjb21wZWxsaW5nIGVu
b3VnaCB0byBzaW1wbGlmeSB2YWxpZGF0aW9uIGFuZCBqdXN0IHJlcXVpcmUgYW4gYXVkIHRvIGJl
IHRoZXJlLCBhcyBvcHBvc2VkIHRvIGludHJvZHVjZSBjb21wbGljYXRpb25zDQogdGhhdCBtYWtl
IGl0IGNvbmRpdGlvbmFsIHRvIHRoZSBwcmVzZW5jZSBvZiBzY29wZXMgb3Igb3RoZXIgZGlzYW1i
aWd1YXRpb24uLiBPbmUgcmVhc29uIEkgZmVlbCBwcmV0dHkgZ29vZCBhYm91dCB0aGF0IGlzIHRo
YXQgYWRkaW5nIGEgZGVmYXVsdCBhdWRpZW5jZSBpc27igJl0IHZlcnkgaGFyZCBpZiBhbnkgb2Yg
dGhlIGFib3ZlIGFzc3VtcHRpb25zIGVuZCB1cCBub3QgYmVpbmcgdHJ1ZSBmb3IgYSBwYXJ0aWN1
bGFyIGNhc2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jmd0OyBXaGF04oCZcyB0aGUg
cmF0aW9uYWxlIGZvciB1c2luZyBpYXQgaW5zdGVhZCBvZiBuYmYuDQo8L3NwYW4+PC9pPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF04oCZcyBqdXN0IHN0cmFpZ2h0
IGZyb20gT0lEQyBJRF90b2tlbnMsIGFuZCB0aGUgY29uc2lkZXJhdGlvbnMgYWJvdXQgcmVwdXJw
b3NpbmcgZXhpc3RpbmcgbG9naWMuIEkgc2VlIHRoZXJl4oCZcyBhIHRocmVhZCBvbiB0aGlzIHNw
ZWNpZmljYWxseSwgbGV0IG1lIGFuc3dlciBmdXJ0aGVyIG9uIHRoYXQgYnJhbmNoLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mZ3Q7IFRoaXMgc3BlYyBmZWVscyBzb21laG93IGluIGJl
dHdlZW4gYSBwcm9maWxlIGFuZCBhIEJDUDwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPllvdSBhcmUgcmlnaHQgdGhhdCB0aGlzIHNwZWMgYXR0ZW1wdHMg
dG8gZ28gYmV5b25kIGp1c3QgZGVjbGFyaW5nIGEgbGF5b3V0LCBhbmQgSSBhZ3JlZSB0aGlzIG1l
YW5zIHRoYXQgdGhpcyBwcm9maWxlIHdpbGwgbm90IGFwcGx5IHRvIGFic29sdXRlbHkgZXZlcnlv
bmUuIFRoZSByZWFzb24gSSB0cmllZCB0aGF0DQogcm91dGUgKGF0IHRoZSBjb3N0IG9mIHdvcmtp
bmcgd2F5IGhhcmRlciBpbiB0aGUgbGFzdCB5ZWFyIGZvciByZWFjaGluZyBjb25zZW5zdXMgdGhh
biBpZiB3ZSB3b3VsZCBoYXZlIGp1c3QgbGlzdGVkIHRoZSBwb3NzaWJsZSBjb250ZW50KSwgaXMg
dGhhdCBJIG9mdGVuIG9ic2VydmUgaW1wbGVtZW50ZXJzIG1ha2UgcXVlc3Rpb25hYmxlIGNob2lj
ZXMgYmVjYXVzZSBvZiB0aGUgbGFyZ2UgbGVld2F5IHNwZWNpZmljYXRpb25zIGFsbG93LiBNeSBo
b3BlDQogd2FzIHRoYXQgdGhlIHNjb3BlIG9mIHRoaXMgcHJvZmlsZSB3YXMgc21hbGwgZW5vdWdo
IHRvIG1ha2UgdGhhdCBleHRyYSBsZXZlbCBvZiBndWlkYW5jZSBhY2hpZXZhYmxlLCB3aGVyZWFz
IHRyeWluZyB0byBkbyB0aGUgc2FtZSB3aXRoIGEgbGFyZ2VyIHNwZWMgd291bGQgaGF2ZSBiZWVu
IHByb2hpYml0aXZlbHkgZXhwZW5zaXZlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkkgYmVsaWV2ZSB0aGluZ3Mgd29ya2VkIG91dCB3ZWxsIHNvIGZhcjogd2UgaGFk
IGxvdHMgb2YgY29uc3RydWN0aXZlIGRpc2N1c3Npb25zLCBhbmQgSSBlbmRlZCB1cCByZWxheGlu
ZyBBIExPVCBvZiB0aGUgY29uc3RyYWludHMgSSB3YXMgb3JpZ2luYWxseSBlbnZpc2lvbmluZy4g
Tm9uZXRoZWxlc3MsIG15DQogaG9wZSBpcyB0aGF0IHdlIGlkZW50aWZpZWQgdGhlIHJpZ2h0IHNl
dCBvZiBndWlkZWxpbmVzIHRoYXQgd2lsbCBoZWxwIHBlb3BsZSBhY3R1YWxseSBpbnRlcm9wZXJh
dGUgb3V0IG9mIHRoZSBib3ggZm9yIHRoZSBtb3N0IGJhc2ljL2NvbW1vbiBzY2VuYXJpb3MsIGFz
IG9wcG9zZWQgdG8gY29tcGx5aW5nIHdpdGggdGhlIGxldHRlciBvZiB0aGUgc3BlYyBidXQgc3Rp
bGwgaGF2aW5nIGEgbG90IHRvIGZpZ3VyZSBvdXQgb3V0IG9mIGJhbmQuDQo8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9t
OjwvYj4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhh
bGYgT2YgPC9iPkRvbWluaWNrIEJhaWVyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJp
bCAxNiwgMjAyMCAxMjoxMCBBTTxicj4NCjxiPlRvOjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZs
dDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+
cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDs7IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICZxdW90O0pT
T04gV2ViIFRva2VuIChKV1QpIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zJnF1
b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+U2luY2Ug
dGhpcyBpcyB0aGUgbGFzdCBjYWxsLCBJIHRob3VnaHQgSSBicmluZyB1cCBzb21lIG9mIHRob3Vn
aHRzIC8gY29uY2VybnMuIFNvbWUgb2YgdGhlbSBoYXZlIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPmNsaWVudF9pZCB2cyBzdWI8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkkgYW0gc3RpbGwgbm90IGVudGlyZWx5IGhh
cHB5IHdpdGggdGhlIOKAnHJlLXB1cnBvc2luZ+KAnSBvZiB0aGUgY2xhaW0gdHlwZXMgYmFzZWQg
b24gZmxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+SWYgdGhlIGludGVudGlvbiBpcywgdGhhdCBzdWIgZXhwcmVzc2VzIHRoZSBlbnRp
dHkgYWdhaW5zdCB3aGljaCB0aGUgcmVzb3VyY2Ugd2lsbCBkbyBhdXRob3Jpc2F0aW9uIChhbmQg
dGhhdCBtaWdodCBiZSBhIGNsaWVudA0KIG9yIGEgdXNlcikgLSBJIGdldCBpdCAoYW5kIG1heWJl
IGl0IHNob3VsZCBiZSBzdGF0ZWQgbGlrZSB0aGF0KSAtIGJ1dDwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj50aGlzIHRoaW5raW5nIHJlbWlu
ZHMgbWUgb2YgdGhlIG9sZCBBRCBkYXlzIHdoZXJlIHRoZXJlIHdhcyBubyBkaXN0aW5jdGlvbiBi
ZXR3ZWVuIHVzZXIgYW5kIHNlcnZpY2UgYWNjb3VudHMgKHNvbWV0aGluZyB0aGF0DQogaGFzIGJl
ZW4gZml4ZWQgSUlSQyBpbiBXaW5kb3dzIFNlcnZlciAyMDEyIFIyKS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkFsbCBvdGhl
ciBPQXV0aCBzcGVjcyBtYWtlIGEgdmVyeSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIHVzZXJz
IGFuZCBjbGllbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj5GdXJ0aGVybW9yZSBpdCBzYXlzPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mcXVvdDtBdXRo
b3JpemF0aW9uIHNlcnZlcnMgc2hvdWxkIHByZXZlbnQgc2NlbmFyaW9zIHdoZXJlIGNsaWVudHMg
Y2FuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPiZuYnNwOyAmbmJzcDthZmZlY3QgdGhlIHZhbHVlIG9mIHRoZSBzdWIgY2xhaW0gaW4gd2F5
cyB0aGF0IGNvdWxkIGNvbmZ1c2UgcmVzb3VyY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7ICZuYnNwO3NlcnZlcnMu4oCdPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj5JZiB3ZSBrZWVwIHRoYXQgZHVhbCBzZW1hbnRpY3Mgb2YgdGhlIHN1YiBjbGFpbSAtIGl0
IG11c3QgYmUgY2xlYXJseSBzdGF0ZWQsIHRoYXQgc3ViamVjdCBJRCBhbmQgY2xpZW50IElEIGFy
ZSBub3cgaW4gdGhlIHNhbWUNCiBjb2xsaXNpb24gZG9tYWluLiBTbyB3aGVuIGFuIEFTIC8gT1Ag
Y3JlYXRlcyB0aGVtLCB0aGV5IG5lZWQgdG8gYmUgdW5pcXVlIGFjcm9zcyB1c2VyIGlkcyBhbmQg
Y2xpZW50IGlkcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPk1heWJlIGl0IHNob3VsZCBiZSBhbHNvIGV4cGxpY2l0bHkgbWVu
dGlvbmVkIHRoYXQgc3ViIGhhcyBhIGRpZmZlcmVudCBzZW1hbnRpYyBoZXJlIGFzIGluIE9JREMg
LSBldmVuIHRob3VnaCBhIG1ham9yaXR5IG9mIHRoZQ0KIHNvZnR3YXJlIGJ1aWx0IHRvZGF5IHdp
bGwgdXNlIHRoZW0gdG9nZXRoZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5hdWRpZW5jZSBjbGFpbTwvc3Bhbj48L2I+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+SSBhbSBu
b3QgZnVsbHkgY2xlYXIgd2h5IGF1ZCBpcyByZXF1aXJlZC4gT0F1dGggaXRzZWxmIGRvZXMgbm90
IGhhdmUgYSBub3Rpb24gb2YgYW4gYXVkaWVuY2UgKGluIHRoZSBKV1Qgc2Vuc2UpIC0gdGhleSBo
YXZlDQogc2NvcGVzICh3aGljaCBpcyB2ZXJ5IHNpbWlsYXIpLiBCdXQgaW4gc2ltcGxlIHNjZW5h
cmlvcyB3aGVyZSByZXNvdXJjZXMgZG9u4oCZdCBleGlzdCwgeW91J2QgbmVlZCB0byBtYWtlIHVw
IGFuIGF1ZGllbmNlIGp1c3QgdG8gZnVsZmlsIHRoaXMgcmVxdWlyZW1lbnQuIEFuZCBpbiBtYW55
IGNhc2UgdGhpcyB3aWxsIGJlIGVpdGhlciBzdGF0aWMgb3IganVzdCByZXBlYXQgdGhlIHNjb3Bl
IHZhbHVlcy4gV2hhdOKAmXMgdGhlIHZhbHVlIG9mIHRoYXQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JZiB0aGUgY29uY2Vw
dCBvZiByZXNvdXJjZXMgYXJlIHVzZWQsIEkgYWJzb2x1dGVseSBhZ3JlZSB0aGF0IGF1ZCBzaG91
bGQgYmUgdXNlZCB0b28uIEJ1dCBJIHdvdWxkbuKAmXQgbWFrZSBpdCByZXF1aXJlZC48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPmlhdCB2cyBuYmY8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPldoYXTigJlzIHRoZSByYXRpb25hbGUgZm9yIHVzaW5nIGlhdCBp
bnN0ZWFkIG9mIG5iZi4gQXJlbuKAmXQgbW9zdCBKV1QgbGlicmFyaWVzIChpbmNsdWRpbmcgZS5n
LiB0aGUgLk5FVCBvbmUpIGxvb2tpbmcgZm9yIG5iZiBieQ0KIGRlZmF1bHQ/PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5H
ZW5lcmFsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhIj5UaGlzIHNwZWMgZmVlbHMgc29tZWhvdyBpbiBiZXR3ZWVuIGEgcHJvZmlsZSBh
bmQgYSBCQ1AuIE9uIG9uZSBoYW5kIHlvdSBkZWZpbmUgc29tZSBjbGFpbXMgYW5kIHRoZWlyIHNl
bWFudGljcyAoZ29vZCkgLSBvbiB0aGUNCiBvdGhlciBoYW5kIHRoZXJlIGlzIHNvbWUgcHJlc2Ny
aXB0aXZlIGd1aWRhbmNlIGFuZCBtYXliZSBvdmVyLXNwZWNpZmljYXRpb24uIE15IGNvbmNlcm4g
aXMsIHRoYXQgaW4gdGhlIGVuZCBuby1vbmUgd2lsbCBmdWxseSBjb21wbHkgd2l0aCBpdCwgYmVj
YXVzZSBpdCBkb2VzbuKAmXQgd29yayBvbmUgd2F5IG9yIHRoZSBvdGhlciBmb3IgdGhlbS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPkkga25vdyB3ZSBqdXN0IHdlbnQgdGhvdWdoIHRoZSBkaXNjdXNzaW9uIHRvIG1ha2UgY2Vy
dGFpbiBjbGFpbXMgcmVxdWlyZWQgYXMgb3Bwb3NlZCB0byBvcHRpb25hbCAtIGJ1dCBtYXliZSBs
ZXNzIGlzIG1vcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj5UYmggLSB0aGUgbW9zdCB2YWx1YWJsZSBwYXJ0IG9mIHRoZSBk
b2MgdG8gbWUgaXMgdGhlIGRlZmluaXRpb24gb2YgdGhlIOKAnGF0JiM0Mztqd3TigJ0gdHlwLiBG
b3IgdGhlIHJlc3QgSeKAmWQgcmF0aGVyIGxpa2UgdG8gc2VlIGp1c3QNCiBzb21lIHN0YW5kYXJk
IGNsYWltcyBhbmQgSUYgdGhleSBhcmUgdXNlZCwgd2hpY2ggc2VtYW50aWNzIHRoZXkgaGF2ZS48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
Y2hlZXJzJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj7igJTigJTigJQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPkRvbWluaWNrIEJhaWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk9uIDE1
LiBBcHJpbCAyMDIwIGF0IDIwOjU5OjMxLCBSaWZhYXQgU2hla2gtWXVzZWYgKDxhIGhyZWY9Im1h
aWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBn
bWFpbC5jb208L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCkhpIGFs
bCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUl
Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVp
Z2h0OjExNSUiPg0KVGhpcyBpcyBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3Ig
JnF1b3Q7SlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4wIEFjY2VzcyBU
b2tlbnMmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1o
ZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bztsaW5lLWhlaWdodDoxMTUlIj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50OjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjExNSUiPg0KPGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRva2VuLWp3
dC0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTE1JSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NClBsZWFzZSBzZW5kIHlv
dXIgY29tbWVudHMgdG8gdGhlIE9BdXRoIG1haWxpbmcgbGlzdCBieSBBcHJpbCAyOSwgMjAyMC48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4N
CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0
OjExNSUiPg0KUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzts
aW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5uZXM8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxMTUlIj4NCiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjxicj4NCk9BdXRoIG1haWxpbmcgbGlzdCA8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT4gPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48
YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MWHPR19MB15011471BBF5E5B337463500AED00MWHPR19MB1501namp_--


From nobody Fri Apr 24 16:34:50 2020
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 81F203A0F57 for ; Fri, 24 Apr 2020 16:34:47 -0700 (PDT)
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 iq5Z_9ptssvU for ; Fri, 24 Apr 2020 16:34:42 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 0A3BB3A0F41 for ; Fri, 24 Apr 2020 16:34:41 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id r2so10926317ilo.6 for ; Fri, 24 Apr 2020 16:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MWsKJsy6/K4LocGLvVZiS6KZ5OXtIMP36fPK6YEDF40=; b=f/BbtFLa9F6S5IeJCo3tLM2cNJ4Ts98cEQ+XV+ghA/JAH5LDIPQATHropJ1m58ncs3 N7K821Yc57D+VB8FfNY42YQG+qebzDyEWvkuqXhCgcMB2pq43EMVuf+5pvRkNwe1e6SK 4E4DPofqQMXMFZASbE/MYTvYB14nB6m8XCdi6epvUihZpnbmu8qvzpB1bDFrMM6g7SBX 63SByRcrRsGOHl+pg7GSOU+FFwjARSOOkUACYGsxHAfE/Lv/uqaAddjchbsA312j8Tms Fi3wTVt99lPXogn07ah+80XgypXeXnqniJ56X3XD0zqY/qSCgXgmvvqEVH0z2RVnDeKm kn7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MWsKJsy6/K4LocGLvVZiS6KZ5OXtIMP36fPK6YEDF40=; b=Y62d7lRKpiqBI1t4dxkukY0bx6vgQBx9lIrscz0Ruu97z/KjtL0ZcGcrC5PXqf4LpG YWRON1rC0Ga7gURwQG2Iw/c+972YrAtr9JOl3mZqtK0WaCZ5le9SvlE0lnBI/8Dh+A1U cX3FnyREHTA5OeYQYORn5BWj0JKPPKb/timZnmg6L++ASp7Wuu+IZFGr6eiKyM9VUWUQ EPzmTSpyliHOwRCyEvT3g91Q2GzfUNUcaC5s7IdSkv1wHOqdoKy5AiE30m2a3I73hUWi v7dHRsCtmdgpjQY8jcpkCBqMiU+xlrhN5nQTUq9RAee8kE2y0G3jrhYdS+U1/2xchQh2 gztA==
X-Gm-Message-State: AGi0PuYGoO3qDLpjVnafrCxLstrFv0pm3GTmAkAvdQG7Xgh9W8OX9yks lry1XZnCjTvE70XPzDTu2lyXLUcNR/6fEOZc/hM=
X-Google-Smtp-Source: APiQypKPpCzn6Dnl6zhuXEDxrsXdf7V3ZY3p56kc6klE2yD+YLoBdI2r0e+AJgUR9lZXcLdwnFLn+CXCIUBvS9wgtWo=
X-Received: by 2002:a92:d3c5:: with SMTP id c5mr11316505ilh.73.1587771281092;  Fri, 24 Apr 2020 16:34:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:fcd:0:0:0:0:0 with HTTP; Fri, 24 Apr 2020 16:34:39 -0700 (PDT)
In-Reply-To: 
References:   <085301d616e8$21029750$6307c5f0$@auth0.com>         
From: Rifaat Shekh-Yusef 
Date: Fri, 24 Apr 2020 19:34:39 -0400
Message-ID: 
To: Vittorio Bertocci 
Cc: Takahiko Kawasaki , oauth 
Content-Type: multipart/alternative; boundary="00000000000031b65e05a411cf6c"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 24 Apr 2020 23:34:48 -0000

--00000000000031b65e05a411cf6c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Vittorio, Takahiko,

Thank you both for your handling of the situation and the quick resolution
of this issue.

Have a great weekend and stay safe!

Regards,
 Rifaat


On Friday, April 24, 2020, Vittorio Bertocci  wrote:

> Dear Takahiko,
>
> Thank you so much for your kind and prompt response, and for having
> deleted the tweets. We all care a lot about doing the right thing, and I
> fully understand how passion can sometimes carry us away. For me this
> resolves the matter 100%.
>
> Thanks again,
>
> V.
>
>
>
> *From: *Takahiko Kawasaki 
> *Date: *Friday, April 24, 2020 at 15:49
> *To: *Vittorio Bertocci 
> *Cc: *oauth , Vittorio Bertocci  40auth0.com@dmarc.ietf.org>
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Dear Vittorio,
>
> I apologize. To me, the requirements on "aud" and "sub" sounded too
> strange and the logic to deny counter proposals sounded unnaturally
> unconvincing, too. They made me suspicious, and unfortunately and
> accidentally, my subsequent observation matched my doubt, and it made me
> feel I should bring it here with a kind of sense of justice, but I was a
> way too stupid. I wanted to discuss the requirements purely technically b=
y
> removing politics, which I thought existed but did not exist actually. Th=
e
> ironic result was that my previous post itself was politics. I stop makin=
g
> comments to the spec.
>
> I'm sorry for my tweets. Because they have been copied to here in an
> unremovable way, allow me to remove them from Twitter to reflect my condu=
ct.
>
> I'm sorry for having cast doubt although I've actually respected you sinc=
e
> long before without your knowing. Hopefully, I want mercy from you and th=
e
> community in spite of my conduct.
>
> Takahiko
>
>
>
> On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci <
> vittorio.bertocci@auth0.com> wrote:
>
> Takahiro,
>
> Before I acknowledge your comments, I would like to clarify some importan=
t
> points.
>
> Your first email, and various tweets you published contextually (
> https://twitter.com/darutk/status/1253375039681884160), suggest that with
> my work on the spec I am driving some hidden agenda for my company, and y=
ou
> are exposing this thanks to some findings you uncovered- and that the WG
> somehow missed.
> This is of course nonsense, insulting to my own professional integrity an=
d
> to the intelligence of the chairs, working group and everyone who
> participated in the discussion. I include the tweets in the discussion
> because you included in them a link to the mailing list archives, hence
> involving the WG in the process.
>
>
>
> Some basic facts:
>
>    - The profile as it exists today does NOT work out of the box with
>    Auth0, there are several things that would need to change in the produ=
ct
>    for that to happen- including adding support for resource indicators w=
hich
>    is currently missing
>    - The layout of the Auth0 token is certainly not a secret, given that
>    it was presented alongside all the other tokens obtained from other ve=
ndors
>    at the OSW2019 in March, in the initial draft pitch at IETF104 as reco=
rded
>    in https://datatracker.ietf.org/meeting/104/materials/slides-
>    104-oauth-sessa-jwt-profile-for-access-token-00
>    ,
>    in the first discussion at IETF105 as shown in
>    https://datatracker.ietf.org/meeting/105/materials/slides-
>    105-oauth-sessa-json-web-token-jwt-profile-for-oauth-
>    20-access-tokens-02-00
>    .
>    The use of resource indicators for client cred flows is certainly not =
a
>    dark ploy to smuggle the Auth0 way, in fact it=E2=80=99s informed more=
 by my work
>    on Azure AD- where I found the transition from pseudo resource indicat=
ors
>    to scopes to be riddled by challenges. Once again, all discussions wer=
e
>    made in full transparency.
>    - The concerns about symmetric algorithms being allowed, which you are
>    oddly bringing up in a tweet rather than on the list, are disconnected=
 from
>    the discussion: people in the working group explicitly asked for symme=
tric
>    to be an option and even to relax the current language to be more
>    permissive, which I gently pushed back against. Again, not an obscure =
ploy.
>
>
>
> I am saddened that you chose to make those statements on twitter. There
> was nothing for you to discover, everything was already out in the open.
>
> You might want to consider retracting your accusations. I am not worried
> about myself, my conscience is perfectly clean and the IETF process recor=
ds
> back me up, but by suggesting lack of transparency you are unfairly
> portraying the IETF, standardization process and the people who do their
> best to check at the door their affiliations and contribute their time an=
d
> expertise for the benefit of the industry as a whole.
>
>
>
> I am adding the tweets here for reference, together with the translation
> Twitter provided.
>
>
>
> Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect
>
> @darutk
>
> =E3=82=82=E3=81=97=E3=82=84=E3=81=A8=E6=80=9D=E3=81=A3=E3=81=A6=E8=AA=BF=
=E3=81=B9=E3=81=A6=E3=81=BF=E3=81=9F=E3=82=89=E3=80=81Auth0=EF=BC=88=E3=82=
=B9=E3=83=9A=E3=83=83=E3=82=AF=E3=83=AA=E3=83=BC=E3=83=89=E3=81=AE=E6=89=80=
=E5=B1=9E=E4=BC=81=E6=A5=AD=EF=BC=89=E3=81=AE client_credentials =E3=83=95=
=E3=83=AD=E3=83=BC=E3=81=AE=E5=AE=9F=E8=A3=85=E3=81=AF audience=EF=BC=88RFC
> 8707 =E3=81=AE resource =E7=9B=B8=E5=BD=93=EF=BC=89=E3=81=8C=E5=BF=85=E9=
=A0=88=E3=81=A7=E3=80=81=E7=94=9F=E6=88=90=E3=81=99=E3=82=8B JWT =E3=82=A2=
=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E3=81=AE su=
b =E3=81=AB=E3=82=AF=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88 ID =E3=82=
=92=E5=9F=8B=E3=82=81=E8=BE=BC=E3=82=80=E3=80=82JWT
> =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=
=E4=BB=95=E6=A7=98=E3=83=89=E3=83=A9=E3=83=95=E3=83=88=E3=81=8C=E6=AD=AA=E3=
=82=93=E3=81=A7=E3=81=84=E3=82=8B=E3=81=AE=E3=81=AF=E3=81=93=E3=82=8C=E3=81=
=8C=E7=90=86=E7=94=B1=E3=81=A0=E3=82=8D=E3=81=86=E3=80=82
>
> Suddenly, I searched and thought, implementation of client_credentials
> flow of Auth0 (company of Spec Lead) requires audience (equivalent to
> resource of RFC 8707), and embed client ID in sub of generated JWT access
> token. This is probably the reason why the JWT access token specification
> draft is distorted.
>
>
>
> =E5=85=83=E3=80=85 Auth0 =E3=81=AE=E7=8F=BE=E5=AE=9F=E8=A3=85=E3=82=92=E6=
=A5=AD=E7=95=8C=E3=81=AB=E8=AA=8D=E3=82=81=E3=81=95=E3=81=9B=E3=82=8B=E3=81=
=9F=E3=82=81=E3=81=AB JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=
=83=BC=E3=82=AF=E3=83=B3=E6=A8=99=E6=BA=96=E4=BB=95=E6=A7=98=E7=AD=96=E5=AE=
=9A=E4=BD=9C=E6=A5=AD=E3=81=8C=E9=96=8B=E5=A7=8B=E3=81=95=E3=82=8C=E3=81=9F=
=E3=81=A8=E5=99=82=E3=81=A7=E3=81=AF=E8=81=9E=E3=81=84=E3=81=A6=E3=81=84=E3=
=81=9F=E3=81=8C=E3=80=81=E5=AE=9F=E9=9A=9B=E3=81=AB=E3=81=9D=E3=81=86=E3=81=
=A0=E3=81=A3=E3=81=9F=E3=81=8B=E3=80=82
> =E6=8A=80=E8=A1=93=E7=9A=84=E3=81=AB=E4=B8=8D=E8=87=AA=E7=84=B6=E3=81=AA=
=E7=82=B9=E3=81=8C=E5=A4=9A=E3=81=84=E3=81=97=E8=A3=8F=E4=BA=8B=E6=83=85=E3=
=81=8C=E3=81=AF=E3=81=A3=E3=81=8D=E3=82=8A=E3=81=97=E3=81=9F=E4=BB=8A=E3=81=
=A8=E3=81=AA=E3=81=A3=E3=81=A6=E3=81=AF=E9=BB=99=E3=81=A3=E3=81=A6=E3=81=84=
=E3=82=8B=E8=A8=B3=E3=81=AB=E3=82=82=E3=81=84=E3=81=8B=E3=81=AA=E3=81=84=E3=
=81=AE=E3=81=A7=E3=80=81=E3=83=A1=E3=83=BC=E3=83=AA=E3=83=B3=E3=82=B0=E3=83=
=AA=E3=82=B9=E3=83=88=E3=81=A7=E6=84=8F=E8=A6=8B=E3=82=92=E8=BF=B0=E3=81=B9=
=E3=81=9F=E3=80=82
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/
>
> I've heard rumors that the JWT Access Token standard specification work
> was started to get the industry to accept the current implementation of
> Auth0, but was that really the case? Since there are many technical
> unnatural points and it is impossible to keep silent now that the
> circumstances are clear, I made an opinion on the mailing list.
>
>
>
> =E3=81=A4=E3=81=84=E3=81=A7=E3=81=AB=E8=A8=80=E3=81=A3=E3=81=A6=E3=81=8A=
=E3=81=8F=E3=81=A8=E3=80=81Auth0 =E3=81=8C=E7=94=9F=E6=88=90=E3=81=99=E3=82=
=8B JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=
=83=B3=E3=81=AE=E7=BD=B2=E5=90=8D=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=
=BA=E3=83=A0=E3=81=A8=E3=81=97=E3=81=A6=E9=81=B8=E6=8A=9E=E3=81=A7=E3=81=8D=
=E3=82=8B=E3=81=AE=E3=81=AF=E3=80=81HS256 =E3=81=A8 RS256
> =E3=81=AE=E3=81=BF=E3=81=AE=E3=82=88=E3=81=86=E3=81=A0=E3=80=82HS256 =E3=
=81=AF=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=
=AA=E3=82=BA=E3=83=A0=E3=80=82=E4=B8=80=E6=96=B9=E3=81=AE RS256 =E3=81=AF=
=E9=9D=9E=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=
=83=AA=E3=82=BA=E3=83=A0=E3=81=A0=E3=81=8C=E3=80=81=E3=82=BB=E3=82=AD=E3=83=
=A5=E3=83=AA=E3=83=86=E3=82=A3=E3=83=BC=E4=B8=8A=E3=81=AE=E7=90=86=E7=94=B1=
=E3=81=A7
> Financial-grade API Part 2 =E3=81=A7=E3=81=AF=E4=BD=BF=E7=94=A8=E7=A6=81=
=E6=AD=A2=E3=81=A8=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E3=80=82
>
> Incidentally, it seems that only HS256 and RS256 can be selected as the
> signature algorithm for the JWT access token generated by Auth0. HS256 is=
 a
> symmetric key algorithm. On the other hand, RS256 is an asymmetric key
> algorithm, but for security reasons, it is prohibited in Financial-grade
> API Part 2.
>
>
>
>
>
> *From: *OAuth  on behalf of Takahiko Kawasaki <
> taka@authlete.com>
> *Date: *Thursday, April 23, 2020 at 18:01
> *To: *oauth 
> *Cc: *Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> I apologize if my previous post has made you all here feel unpleasant,
> especially I'm sorry for the author, the chairs, and people who directly
> joined the discussion about the spec. I could have expressed my
> disagreement on the requirements for "aud" and "sub" in another different
> way. For software specifications and architectures, I'm liable to get
> excited and aggressive. Please forgive me.
>
> Regarding the relationship between "aud" and "scope", the assumption in
> the draft is not necessarily applicable to all possible use cases. For
> example, multiple resources may share the same scopes. What if both
> "/resource1" and "/resource2" recognize "get" scope and "update" scope? I=
n
> this case, it is not appropriate to determine the default resource
> indicator for "aud" from the scopes. It is also impossible to map scopes =
to
> resources and vice versa. The assumption in the current draft is too narr=
ow
> to be included in a standard.. If the current description continues to
> exist, it will impose big restrictions on the design of scopes and
> resources.
>
> If you still think the "aud" claim should always exist, then the
> authorization endpoint and/or the token endpoint (and/or the backchannel
> authentication endpoint and/or the device authorization endpoint) of your
> system can require the "resource" request parameter as mandatory. We don'=
t
> have to put rules to determine the default "aud" value into the spec abou=
t
> JWT access tokens. The "resource" parameter defined in RFC 8707 can work
> regardless of whether the format of access tokens is JWT or not. Therefor=
e,
> it is not appropriate to discuss the necessity of the "aud" claim only in
> the context of "JWT" access tokens.
>
> Regarding the "sub" claim, setting the client ID there, rather, will
> confuse resource servers. If the "sub" claim is set even in the case of t=
he
> client credentials flow, resource servers cannot judge whether the "sub"
> claim represents either the subject of the resource owner or the client I=
D.
> On the other hand, if the "sub" claim is null or absent in the case of th=
e
> client credentials flow, resource servers can always handle the value of
> the "sub" claim as the subject of the resource owner. For resource server=
s,
> this logic is easier. Setting the "sub" claim in every case to make
> resource server implementations simpler is not convincing.
>
> Best Regards,
> Taka
>
>
>
> On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki 
> wrote:
>
> First, to make the discussion fair, I think I should share what I observe=
d
> today. Auth0's client_credentials flow requires an "audience" parameter,
> which is equivalent to the "resource" parameter defined in RFC 8707, and
> embeds the client ID in the generated JWT access token as the value of th=
e
> "sub" claim.
>
> My opinion as a software engineer is as follows.
>
> [aud]
> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> inflexible rules to determine the default value for the "aud" claim based
> on the "scope" parameter.
>
> [sub]
> The "sub" claim should be null or absent when a resource owner is not
> involved in an authorization request. To be concrete, the "sub" claim
> should be null or absent in the client credentials flow. The spec draft
> says in "5. Security Considerations" as follows.
>
> - - - - - - - - - -
> Authorization servers should prevent scenarios where clients can affect
> the value of the sub claim in ways that could confuse resource servers.
> For example: if the authorization server elects to use the client_id as t=
he
> sub value for access tokens issued client credentials grant, the
> authorization server should prevent clients to register an arbitrary
> client_id value, as this would allow malicious clients to select the sub =
of
> a high privilege resource owner and confuse any authorization logic on th=
e
> resource server relying on the sub value.  For more details please refer =
to
> section 4.13 of [OAuth2.Security.BestPractices].
>
> To preventing cross-JWT confusion, authorization servers MUST use a
> distinct identifier as "aud" claim value to uniquely identify access toke=
ns
> issued by the same issuer for distinct resources.
> - - - - - - - - - -
>
> However, the attack vector is brought about merely by introducing the
> following rule defined in "2.2. Data Structure".
>
> - - - - - - - - - -
> In case of access tokens obtained through grants where no resource owner
> is involved, such as the client credentials grant, the value of sub SHOUL=
D
> correspond to an identifier the authorization server uses to indicate the
> client application.
> - - - - - - - - - -
>
> If the rule is not introduced, the attack vector disappears and the "aud"
> claim doesn't have to be mandatory.
>
> Finally, to make the discussion fair, I should also mention that I myself
> is a co-founder of Authlete, Inc. that provides an implementation of OAut=
h
> and OpenID Connect. My thoughts about implementations of access tokens ar=
e
> publicly described here:
>
> OAuth Access Token Implementation
> https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
> On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci  40auth0.com@dmarc.ietf.org> wrote:
>
> Ouch! Sorry =F0=9F=98=8A fixed
>
>
>
> *From: *Dominick Baier 
> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth , Rifaat Shekh-Yusef ,
> Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Oh and while we are at it - could you also fix the typo in my name? Thank=
s
> ;)
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
> vittorio.bertocci@auth0.com) wrote:
>
> This is a great point. In my head I just considered the OIDC semantic and
> thought only of highlighting the app identity case, but you are absolutel=
y
> right that not mentioning the user case at all is confusing. I added the
> language you suggested at the beginning of the sub definition.
>
> Thanks!
>
>
>
> *From: *Dominick Baier 
> *Date: *Monday, April 20, 2020 at 22:54
> *To: *oauth , Rifaat Shekh-Yusef ,
> "vittorio.bertocci@auth0.com" 
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> In case of access tokens obtained through grants where no resource owner =
is involved, such as the client credentials grant, the value of sub SHOULD =
correspond to an identifier the authorization server uses to indicate the c=
lient application.
>
>
>
> Maybe I am missing something, but does it say anywhere what to explicitly
> do in the case of an access token where a resource owner is involved?
>
>
>
> There=E2=80=99s some language that seems to imply that, e.g.:
>
>
>
> as this would allow malicious
>
>    clients to select the sub of a high privilege resource owner
>
> I would have expected to see something stronger like above just -
>
>
>
> In case of access tokens obtained through grants where a resource owner i=
s involved, such as the authorisation code grant, the value of sub SHOULD c=
orrespond to the subject identifier of the resource owner.
>
>
>
> If this spec is about interop, I think this should be at least a
> recommendation...
>
>
>
>
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com
>  (vittorio.bertocci@auth0.com) wrote:
>
> Thanks Dominick for your comments!
>
> Inline
>
>
>
> *>** All other OAuth specs make a very clear distinction between users
> and client.*
>
> There=E2=80=99s a nuance worth highlighting here: sub !=3D user. In previ=
ous
> discussions on this topic it has been brought up that the JWT spec define=
s
> sub as identifying the principal that is the subject of the JWT, and that=
=E2=80=99s
> not necessarily limited to users.
>
> However I get the potential confusion, and I am happy to add clarifying l=
anguage if you have specific passages in the space you are particularly wor=
ried about: however I feel the matter is addressed upfront by the language =
in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtaine=
d through grants where no resource owner is involved, such as the client cr=
edentials grant, the value of sub SHOULD correspond to an identifier the au=
thorization server uses to indicate the client application.=E2=80=9C and Se=
ction 5 has an entire paragraph discussing things to watch out in assigning=
 sub values in the app identity case. Feel free to suggest additional langu=
age if you want to clarify further.
>
>
>
> *> sub has a different semantic here as in OIDC*
>
> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
> OIDC, to preempt that concern and keep the original sub semantic availabl=
e.
>
>
>
> *>** I am not fully clear why aud is required.*
>
> Aud is there mostly because of three reasons:
>
> =C2=B7         Many existing specs postulate its existence in the token. =
No
> one declares it as a proper MUST (apart from the BCP, but that=E2=80=99s =
partial)
> however I think its importance comes across..
> -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
> mechanism to prevent token redirect (and adds scope restriction as also
> important, however here we make it optional to acocut for non-delegations
> scenario).
> -Resource indicators RFC8707 refers to the same section of RFC7519 as one
> of the assumptions that must hold to prevent bearer tokens misuse
> -BCP225 makes aud mandatory for AS which can issue JWTs for more than one
> app
>
> =C2=B7         Apart from Ping, for which some of its examples are withou=
t aud
> (but also without identifying scopes, given that the one I retrieved had
> only =E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from=
 vendors all
> featured an aud. I know one shoulnd=E2=80=99t overindex on those examples=
, but
> together with the above it seemed to point to something universally usefu=
l.
> One possible reason is that use of a format for the AT is correlated with
> topologies where AS and RS are separated by some boundary (network,
> logical, business, code factoring, etc) hence identifying the resource
> seems like a natural need. Again, not an iron clad law, but an indication=
.
>
> =C2=B7         A lot of people repurpose existing libraries for the JWT A=
T
> case, and some people even sends id_tokens in lieu of ATs. That doesn=E2=
=80=99t
> mean that we should condone any bad practices, but in tis particular case
> it suggests that lots of developers already expect/can handle an audience
> in the JWT used to call their API
>
> None of those are a slam dunk argument for mandatory, but I find them
> compelling enough to simplify validation and just require an aud to be
> there, as opposed to introduce complications that make it conditional to
> the presence of scopes or other disambiguation.. One reason I feel pretty
> good about that is that adding a default audience isn=E2=80=99t very hard=
 if any of
> the above assumptions end up not being true for a particular case
>
>
>
> *> What=E2=80=99s the rationale for using iat instead of nbf. *
>
> That=E2=80=99s just straight from OIDC ID_tokens, and the considerations =
about
> repurposing existing logic. I see there=E2=80=99s a thread on this specif=
ically,
> let me answer further on that branch.
>
>
>
> *> This spec feels somehow in between a profile and a BCP*
>
> You are right that this spec attempts to go beyond just declaring a
> layout, and I agree this means that this profile will not apply to
> absolutely everyone. The reason I tried that route (at the cost of workin=
g
> way harder in the last year for reaching consensus than if we would have
> just listed the possible content), is that I often observe implementers
> make questionable choices because of the large leeway specifications allo=
w.
> My hope was that the scope of this profile was small enough to make that
> extra level of guidance achievable, whereas trying to do the same with a
> larger spec would have been prohibitively expensive.
>
> I believe things worked out well so far: we had lots of constructive
> discussions, and I ended up relaxing A LOT of the constraints I was
> originally envisioning. Nonetheless, my hope is that we identified the
> right set of guidelines that will help people actually interoperate out o=
f
> the box for the most basic/common scenarios, as opposed to complying with
> the letter of the spec but still having a lot to figure out out of band.
>
>
>
> *From:* OAuth  *On Behalf Of *Dominick Baier
> *Sent:* Thursday, April 16, 2020 12:10 AM
> *To:* Rifaat Shekh-Yusef ; oauth 
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Since this is the last call, I thought I bring up some of thoughts /
> concerns. Some of them have been discussed before.
>
>
>
> *client_id vs sub*
>
> I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of =
the claim types
> based on flow.
>
> If the intention is, that sub expresses the entity against which the
> resource will do authorisation (and that might be a client or a user) - I
> get it (and maybe it should be stated like that) - but
>
> this thinking reminds me of the old AD days where there was no distinctio=
n
> between user and service accounts (something that has been fixed IIRC in
> Windows Server 2012 R2).
>
>
>
> All other OAuth specs make a very clear distinction between users and
> client.
>
>
>
> Furthermore it says
>
>
>
> "Authorization servers should prevent scenarios where clients can
>
>    affect the value of the sub claim in ways that could confuse resource
>
>    servers.=E2=80=9D
>
>
>
> If we keep that dual semantics of the sub claim - it must be clearly
> stated, that subject ID and client ID are now in the same collision domai=
n.
> So when an AS / OP creates them, they need to be unique across user ids a=
nd
> client ids.
>
>
>
> Maybe it should be also explicitly mentioned that sub has a different
> semantic here as in OIDC - even though a majority of the software built
> today will use them together.
>
>
>
> *audience claim*
>
> I am not fully clear why aud is required. OAuth itself does not have a
> notion of an audience (in the JWT sense) - they have scopes (which is ver=
y
> similar). But in simple scenarios where resources don=E2=80=99t exist, yo=
u'd need
> to make up an audience just to fulfil this requirement. And in many case
> this will be either static or just repeat the scope values. What=E2=80=99=
s the
> value of that?
>
>
>
> If the concept of resources are used, I absolutely agree that aud should
> be used too. But I wouldn=E2=80=99t make it required.
>
>
>
> *iat vs nbf*
>
> What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99t=
 most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?
>
>
>
> *General*
>
> This spec feels somehow in between a profile and a BCP. On one hand you
> define some claims and their semantics (good) - on the other hand there i=
s
> some prescriptive guidance and maybe over-specification. My concern is,
> that in the end no-one will fully comply with it, because it doesn=E2=80=
=99t work
> one way or the other for them.
>
>
>
> I know we just went though the discussion to make certain claims required
> as opposed to optional - but maybe less is more.
>
>
>
> Tbh - the most valuable part of the doc to me is the definition of the
> =E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see=
 just some standard claims
> and IF they are used, which semantics they have.
>
>
>
> cheers
>
> =E2=80=94=E2=80=94=E2=80=94
>
> Dominick Baier
>
>
>
> On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
> wrote:
>
> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profil=
e
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> _______________________________________________
> 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
>
>

--00000000000031b65e05a411cf6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Vittorio, Takahiko,

Thank you both for your handling of =
the situation and the quick resolution of this issue.

<=
div>Have a great weekend and stay safe!

Regards,
=C2=A0Rifaat


On Friday, April 24, 2020, Vittorio=
 Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:











Dear Takahiko,


Thank you so much for your kind and prompt response,=
 and for having deleted the tweets. We all care a lot about doing the right=
 thing, and I fully understand how passion can sometimes carry us away. For=
 me this resolves the matter 100%.


Thanks again,


V. 


=C2=A0




From=
: Takahiko Kawasaki=
 <taka@authlete.c=
om>

Date: Friday, April 24, 2020 at 15:49

To: Vittorio Bertocci <vittorio.bertocci@auth0.com>

Cc: oauth <oa=
uth@ietf.org>, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc=
.ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






Dear Vittorio,



I apologize. To me, the requirements on "aud" and "sub"=
 sounded too strange and the logic to deny counter proposals sounded unnatu=
rally unconvincing, too. They made me suspicious, and unfortunately and acc=
identally, my subsequent observation matched my doubt,
 and it made me feel I should bring it here with a kind of sense of justice=
, but I was a way too stupid. I wanted to discuss the requirements purely t=
echnically by removing politics, which I thought existed but did not exist =
actually. The ironic result was
 that my previous post itself was politics. I stop making comments to the s=
pec.



I'm sorry for my tweets. Because they have been copied to here in an un=
removable way, allow me to remove them from Twitter to reflect my conduct.<=
br>


I'm sorry for having cast doubt although I've actually respected yo=
u since long before without your knowing. Hopefully, I want mercy from you =
and the community in spite of my conduct.



Takahiko




=C2=A0






On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci &l=
t;vittorio=
.bertocci@auth0.com> wrote:










Takahiro,


Before I acknowledge your comments, I would like to =
clarify some important points.


Your first email, and various tweets you published c=
ontextually (https://twitter.com/darutk/status/12533750396818=
84160),
 suggest that with my work on the spec I am driving some hidden agenda for =
my company, and you are exposing this thanks to some findings you uncovered=
- and that the WG somehow missed.

This is of course nonsense, insulting to my own professional integrity and =
to the intelligence of the chairs, working group and everyone who participa=
ted in the discussion. I include the tweets in the discussion because you i=
ncluded in them a link to the mailing
 list archives, hence involving the WG in the process.


=C2=A0


Some basic facts:


    

  • 
The profile as it exists today does NOT work out of the box with Auth0, the=
re are several things that would need to change in the product for that to =
happen- including adding support for resource indicators which is currently=
 missing
  • 
The layout of the Auth0 token is certainly not a secret, given that it was =
presented alongside all the other tokens obtained from other vendors at the=
 OSW2019 in March, in the initial draft pitch at IETF104 as recorded in

https://datatracker.ietf.org/meeting/104/materials/slides-104-oau=
th-sessa-jwt-profile-for-access-token-00, in the first discussion =
at IETF105 as shown in

https://datatracker.ietf.org/meeting/105/materials/slides-105-oau=
th-sessa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02=
-00. The use of resource indicators for client cred flows is certainly =
not a dark ploy to smuggle the Auth0 way, in fact it=E2=80=99s
 informed more by my work on Azure AD- where I found the transition from ps=
eudo resource indicators to scopes to be riddled by challenges. Once again,=
 all discussions were made in full transparency.
  • 
The concerns about symmetric algorithms being allowed, which you are oddly =
bringing up in a tweet rather than on the list, are disconnected from the d=
iscussion: people in the working group explicitly asked for symmetric to be=
 an option and even to relax the
 current language to be more permissive, which I gently pushed back against=
. Again, not an obscure ploy.


=C2=A0


I am saddened that you chose to make those statement=
s on twitter. There was nothing for you to discover, everything was already=
 out in the open.



You might want to consider retracting your accusatio=
ns. I am not worried about myself, my conscience is perfectly clean and the=
 IETF process records back me up, but by suggesting
 lack of transparency you are unfairly portraying the IETF, standardization=
 process and the people who do their best to check at the door their affili=
ations and contribute their time and expertise for the benefit of the indus=
try as a whole.


=C2=A0


I am adding the tweets here for reference, together =
with the translation Twitter provided.


=C2=A0


Taka@Authlete, BaaS for OAuth 2.0 & OpenID Conne=
ct


@darutk


=
=E3=82=82=E3=81=97=E3=82=84=E3=81=A8=E6=80=9D=E3=81=A3=E3=81=A6=E8=AA=BF=E3=
=81=B9=E3=81=A6=E3=81=BF=E3=81=9F=E3=82=89=E3=80=81Auth0=EF=BC=88=E3=82=B9=E3=83=9A=E3=
=83=83=E3=82=AF=E3=83=AA=E3=83=BC=E3=83=89=E3=81=AE=E6=89=80=E5=B1=9E=E4=BC=
=81=E6=A5=AD=EF=BC=89=E3=81=AE client_credentials
=E3=83=95=E3=83=AD=E3=83=
=BC=E3=81=AE=E5=AE=9F=E8=A3=85=E3=81=AF audience=EF=BC=88RFC 8707
=E3=81=AE resource=
 
=E7=9B=B8=E5=BD=93=EF=BC=89=E3=81=8C=E5=BF=85=E9=A0=88=E3=81=A7=E3=80=81=E7=
=94=9F=E6=88=90=E3=81=99=E3=82=8B JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=
=E3=82=AF=E3=83=B3=E3=81=AE sub
=E3=81=AB=E3=82=AF=E3=83=
=A9=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=88 ID 
=E3=82=92=E5=9F=8B=E3=82=81=E8=BE=BC=E3=82=80=E3=80=82JWT =E3=82=A2=E3=82=AF=E3=82=BB=E3=82=
=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E4=BB=95=E6=A7=98=E3=83=89=E3=83=A9=
=E3=83=95=E3=83=88=E3=81=8C=E6=AD=AA=E3=82=93=E3=81=A7=E3=81=84=E3=82=8B=E3=
=81=AE=E3=81=AF=E3=81=93=E3=82=8C=E3=81=8C=E7=90=86=E7=94=B1=E3=81=A0=E3=82=
=8D=E3=81=86=E3=80=82


Suddenly, I searched and thought, implementation of =
client_credentials flow of Auth0 (company of Spec Lead) requires audience (=
equivalent to resource of RFC 8707), and embed client
 ID in sub of generated JWT access token. This is probably the reason why t=
he JWT access token specification draft is distorted.


=C2=A0


=
=E5=85=83=E3=80=85 Auth0
=E3=81=AE=E7=8F=BE=E5=AE=
=9F=E8=A3=85=E3=82=92=E6=A5=AD=E7=95=8C=E3=81=AB=E8=AA=8D=E3=82=81=E3=81=95=
=E3=81=9B=E3=82=8B=E3=81=9F=E3=82=81=E3=81=AB JWT 
=E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E6=
=A8=99=E6=BA=96=E4=BB=95=E6=A7=98=E7=AD=96=E5=AE=9A=E4=BD=9C=E6=A5=AD=E3=81=
=8C=E9=96=8B=E5=A7=8B=E3=81=95=E3=82=8C=E3=81=9F=E3=81=A8=E5=99=82=E3=81=A7=
=E3=81=AF=E8=81=9E=E3=81=84=E3=81=A6=E3=81=84=E3=81=9F=E3=81=8C=E3=80=
=81=E5=AE=9F=E9=9A=9B=E3=81=AB=E3=81=9D=E3=81=86=E3=81=A0=E3=81=A3=E3=81=9F=
=E3=81=8B=E3=80=82=E6=8A=80=E8=A1=93=E7=9A=84=E3=81=AB=E4=B8=8D=E8=87=
=AA=E7=84=B6=E3=81=AA=E7=82=B9=E3=81=8C=E5=A4=9A=E3=81=84=E3=81=97=E8=A3=8F=
=E4=BA=8B=E6=83=85=E3=81=8C=E3=81=AF=E3=81=A3=E3=81=8D=E3=82=8A=E3=81=97=E3=
=81=9F=E4=BB=8A=E3=81=A8=E3=81=AA=E3=81=A3=E3=81=A6=E3=81=AF=E9=BB=99=
=E3=81=A3=E3=81=A6=E3=81=84=E3=82=8B=E8=A8=B3=E3=81=AB=E3=82=82=E3=81=84=E3=
=81=8B=E3=81=AA=E3=81=84=E3=81=AE=E3=81=A7=E3=80=81=E3=83=A1=E3=83=BC=E3=83=
=AA=E3=83=B3=E3=82=B0=E3=83=AA=E3=82=B9=E3=83=88=E3=81=A7=E6=84=8F=E8=A6=8B=
=E3=82=92=E8=BF=B0=E3=81=B9=E3=81=9F=E3=80=82


=C2=A0


https://mailarchive.ietf=
.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/


I've heard rumors that the JWT Access Token stan=
dard specification work was started to get the industry to accept the curre=
nt implementation of Auth0, but was that really the case?
 Since there are many technical unnatural points and it is impossible to ke=
ep silent now that the circumstances are clear, I made an opinion on the ma=
iling list.


=C2=A0


=
=E3=81=A4=E3=81=84=E3=81=A7=E3=81=AB=E8=A8=80=E3=81=A3=E3=81=A6=E3=81=8A=E3=
=81=8F=E3=81=A8=E3=80=81Auth0
=E3=81=8C=E7=94=9F=E6=88=
=90=E3=81=99=E3=82=8B JWT 
=E3=82=A2=E3=82=AF=E3=82=BB=E3=82=B9=E3=83=88=E3=83=BC=E3=82=AF=E3=83=B3=E3=
=81=AE=E7=BD=B2=E5=90=8D=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=BA=E3=83=
=A0=E3=81=A8=E3=81=97=E3=81=A6=E9=81=B8=E6=8A=9E=E3=81=A7=E3=81=8D=E3=82=8B=
=E3=81=AE=E3=81=AF=E3=80=81HS256 =E3=81=A8 RS256
=E3=81=AE=E3=81=BF=E3=81=
=AE=E3=82=88=E3=81=86=E3=81=A0=E3=80=82HS256 
=E3=81=AF=E5=AF=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=
=83=AA=E3=82=BA=E3=83=A0=E3=80=82=E4=B8=80=E6=96=B9=E3=81=AE RS256 <=
span style=3D"font-family:"MS Gothic"">=E3=81=AF=E9=9D=9E=E5=AF=
=BE=E7=A7=B0=E9=8D=B5=E7=B3=BB=E3=82=A2=E3=83=AB=E3=82=B4=E3=83=AA=E3=82=BA=
=E3=83=A0=E3=81=A0=E3=81=8C=E3=80=81=E3=82=BB=E3=82=AD=E3=83=A5=E3=83=AA=E3=
=83=86=E3=82=A3=E3=83=BC=E4=B8=8A=E3=81=AE=E7=90=86=E7=94=B1=E3=81=A7 Financial-grade API Part 2
=E3=81=A7=E3=81=AF=E4=BD=
=BF=E7=94=A8=E7=A6=81=E6=AD=A2=E3=81=A8=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=
=E3=82=8B=E3=80=82


Incidentally, it seems that only HS256 and RS256 can=
 be selected as the signature algorithm for the JWT access token generated =
by Auth0. HS256 is a symmetric key algorithm. On the
 other hand, RS256 is an asymmetric key algorithm, but for security reasons=
, it is prohibited in Financial-grade API Part 2.


=C2=A0


=C2=A0




From=
:
OAuth <oauth-bounces@ietf.org=
> on behalf of Takahiko Kawasaki <taka@authlete.com>

Date: Thursday, April 23, 2020 at 18:01

To: oauth <oa=
uth@ietf.org>

Cc: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






I apologize if my previous post has made you all her=
e feel unpleasant, especially I'm sorry for the author, the chairs, and=
 people who directly joined the discussion about the spec.
 I could have expressed my disagreement on the requirements for "aud&q=
uot; and "sub" in another different way. For software specificati=
ons and architectures, I'm liable to get excited and aggressive. Please=
 forgive me.



Regarding the relationship between "aud" and "scope", t=
he assumption in the draft is not necessarily applicable to all possible us=
e cases. For example, multiple resources may share the same scopes. What if=
 both "/resource1" and "/resource2" recognize "get=
"
 scope and "update" scope? In this case, it is not appropriate to=
 determine the default resource indicator for "aud" from the scop=
es. It is also impossible to map scopes to resources and vice versa. The as=
sumption in the current draft is too narrow to be included
 in a standard.. If the current description continues to exist, it will imp=
ose big restrictions on the design of scopes and resources.



If you still think the "aud" claim should always exist, then the =
authorization endpoint and/or the token endpoint (and/or the backchannel au=
thentication endpoint and/or the device authorization endpoint) of your sys=
tem can require the "resource" request parameter
 as mandatory. We don't have to put rules to determine the default &quo=
t;aud" value into the spec about JWT access tokens. The "resource=
" parameter defined in RFC 8707 can work regardless of whether the for=
mat of access tokens is JWT or not. Therefore, it is not
 appropriate to discuss the necessity of the "aud" claim only in =
the context of "JWT" access tokens.



Regarding the "sub" claim, setting the client ID there, rather, w=
ill confuse resource servers. If the "sub" claim is set even in t=
he case of the client credentials flow, resource servers cannot judge wheth=
er the "sub" claim represents either the subject of
 the resource owner or the client ID. On the other hand, if the "sub&q=
uot; claim is null or absent in the case of the client credentials flow, re=
source servers can always handle the value of the "sub" claim as =
the subject of the resource owner. For resource servers,
 this logic is easier. Setting the "sub" claim in every case to m=
ake resource server implementations simpler is not convincing.




Best Regards,

Taka




=C2=A0









First, to make the discussion fair, I think I should=
 share what I observed today. Auth0's client_credentials flow requires =
an "audience" parameter, which is equivalent to the "resourc=
e"
 parameter defined in RFC 8707, and embeds the client ID in the generated J=
WT access token as the value of the "sub" claim.



My opinion as a software engineer is as follows.



[aud]

The "aud" claim should be null or absent when the "resource&=
quot; parameters are not given in an authorization request. It is not good =
to introduce inflexible rules to determine the default value for the "=
aud" claim based on the "scope" parameter.



[sub]

The "sub" claim should be null or absent when a resource owner is=
 not involved in an authorization request. To be concrete, the "sub&qu=
ot; claim should be null or absent in the client credentials flow. The spec=
 draft says in "5. Security Considerations" as follows.



- - - - - - - - - -

Authorization servers should prevent scenarios where clients can affect the=
 value of the sub claim in ways that could confuse resource servers.=C2=A0 =
For example: if the authorization server elects to use the client_id as the=
 sub value for access tokens issued client
 credentials grant, the authorization server should prevent clients to regi=
ster an arbitrary client_id value, as this would allow malicious clients to=
 select the sub of a high privilege resource owner and confuse any authoriz=
ation logic on the resource server
 relying on the sub value.=C2=A0 For more details please refer to section 4=
.13 of [OAuth2.Security.BestPractices].



To preventing cross-JWT confusion, authorization servers MUST use a distinc=
t identifier as "aud" claim value to uniquely identify access tok=
ens issued by the same issuer for distinct resources.

- - - - - - - - - -



However, the attack vector is brought about merely by introducing the follo=
wing rule defined in "2.2. Data Structure".



- - - - - - - - - -

In case of access tokens obtained through grants where no resource owner is=
 involved, such as the client credentials grant, the value of sub SHOULD co=
rrespond to an identifier the authorization server uses to indicate the cli=
ent application.

- - - - - - - - - -



If the rule is not introduced, the attack vector disappears and the "a=
ud" claim doesn't have to be mandatory.



Finally, to make the discussion fair, I should also mention that I myself i=
s a co-founder of Authlete, Inc. that provides an implementation of OAuth a=
nd OpenID Connect. My thoughts about implementations of access tokens are p=
ublicly described here:



OAuth Access Token Implementation

https://medium.com/@darutk/oauth-access-t=
oken-implementation-30c2e8b90ff0



Best Regards,

Takahiko Kawasaki

Authlete, Inc.




=C2=A0






On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci &l=
t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:









Ouch! Sorry
=F0=9F=98=8A fixed


=C2=A0




From=
:
Dominick Baier <=
dbaier@least=
privilege.com>

Date: Tuesday, April 21, 2020 at 10:23

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertoc=
ci <vit=
torio.bertocci@auth0.com>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






Oh and while we are at it - could you also fix the typo in my name? Than=
ks ;)




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 21. April 2020 at 09:43:49, Vittorio Bertocci (vittorio.bertocci@auth0.com)=
 wrote:










This is a great point. In my head I just considered =
the OIDC semantic and thought only of highlighting the app identity case, b=
ut you are absolutely right that not mentioning the
 user case at all is confusing. I added the language you suggested at the b=
eginning of the sub definition.


Thanks!


=C2=A0




From=
:
Dominick Baier <=
dbaier@least=
privilege.com>

Date: Monday, April 20, 2020 at 22:54

To: oauth <oa=
uth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "vittorio.bertocci=
@auth0.com"
 <vitto=
rio.bertocci@auth0.com>

Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0






In cas=
e of access tokens obtained through grants where no resource owner is invol=
ved, such as the client credentials grant, the value of sub SHOULD correspo=
nd to an identifier the authorization server uses to indicate the client ap=
plication.






=C2=A0






Maybe I am missing something, but does it say anywhe=
re what to explicitly do in the case of an access token where a resource ow=
ner is involved?






=C2=A0






There=E2=80=99s some language that seems to imply th=
at, e.g.:






=C2=A0






as this would all=
ow malicious


=C2=A0=C2=A0 clients to select the sub of a high =
privilege resource owner






I would have expected to see something stronger like=
 above just -=C2=A0






=C2=A0






In case of access tokens obtained thr=
ough grants where a resource owner is involved, such as the authorisation c=
ode grant, the value of sub SHOULD correspond to the subject identifier of =
the resource owner.






=C2=A0






If this spec is about interop, I think this should b=
e at least a recommendation...






=C2=A0




=C2=A0




=E2=80=94=E2=80=94=E2=80=94





Dominick Baier






=C2=A0


On 20. April 2020 at 09:48:51, 
vittorio.bertocci@auth0.com (vittorio.bertocci@auth0.com) wrote:










Thanks Dominick for your comments!


Inline


=C2=A0


> All other OAuth specs make a very clear distinction betwe=
en users and client.


There=E2=80=99s a nuance worth highlighting here: su=
b !=3D user. In previous discussions on this topic it has been brought up t=
hat the JWT spec defines sub as identifying the principal that
 is the subject of the JWT, and that=E2=80=99s not necessarily limited to u=
sers. 


However I get the potential confusion, and I am happy to add clarifyi=
ng language if you have specific passages in the space you are particularly=
 worried about: however I feel the matter is addressed upfront by the langu=
age in Section 2.2. in the sub entry, =E2=80=9CIn case of access tokens obtained through grants wh=
ere no resource owner is involved, such as the client credentials grant, th=
e value of sub SHOULD correspond to an identifier the authorization server =
uses to indicate the client application.=E2=80=9C and S=
ection 5 has an entire paragraph discussing things to watch out in assignin=
g sub values in the app identity case. Feel free to suggest additional lang=
uage if you want to clarify further. 


=C2=A0


> sub has a different semantic here as in OIDC


The =C2=A0spec refers to RFC7519 in the sub definiti=
on in 2.2, rather than OIDC, to preempt that concern and keep the original =
sub semantic available.


=C2=A0


> I am not fully clear why aud is required.


Aud is there mostly because of three reasons:=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Many existing specs postulate its existence in the token. No one dec=
lares it as a proper MUST (apart from the BCP, but that=E2=80=99s partial) =
however I think its importance comes across..

-Bearer token usage RFC6750 calls it out (in threat mitigation) as the mech=
anism to prevent token redirect (and adds scope restriction as also importa=
nt, however here we make it optional to acocut for non-delegations scenario=
).

-Resource indicators RFC8707 refers to the same section of RFC7519 as one o=
f the assumptions that must hold to prevent bearer tokens misuse


-BCP225 makes aud mandatory for AS which can issue JWTs for more than one a=
pp


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Apart from Ping, for which some of its examples are without aud (but=
 also without identifying scopes, given that the one I retrieved had only =
=E2=80=9Copenid=E2=80=9D), all of the sample JWT ATs I received from vendor=
s all featured an aud. I know one shoulnd=E2=80=99t overindex
 on those examples, but together with the above it seemed to point to somet=
hing universally useful. One possible reason is that use of a format for th=
e AT is correlated with topologies where AS and RS are separated by some bo=
undary (network, logical, business,
 code factoring, etc) hence identifying the resource seems like a natural n=
eed. Again, not an iron clad law, but an indication.


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
A lot of people repurpose existing libraries for the JWT AT case, an=
d some people even sends id_tokens in lieu of ATs. That doesn=E2=80=99t mea=
n that we should condone any bad practices, but in tis particular case it s=
uggests that lots of developers already
 expect/can handle an audience in the JWT used to call their API<=
/u>


None of those are a slam dunk argument for mandatory=
, but I find them compelling enough to simplify validation and just require=
 an aud to be there, as opposed to introduce complications
 that make it conditional to the presence of scopes or other disambiguation=
.. One reason I feel pretty good about that is that adding a default audien=
ce isn=E2=80=99t very hard if any of the above assumptions end up not being=
 true for a particular case


=C2=A0


> What=E2=80=99s the rationale for using iat instead of nbf.



That=E2=80=99s just straight from OIDC ID_tokens, an=
d the considerations about repurposing existing logic. I see there=E2=80=99=
s a thread on this specifically, let me answer further on that branch.


=C2=A0


> This spec feels somehow in between a profile and a BCP


You are right that this spec attempts to go beyond j=
ust declaring a layout, and I agree this means that this profile will not a=
pply to absolutely everyone. The reason I tried that
 route (at the cost of working way harder in the last year for reaching con=
sensus than if we would have just listed the possible content), is that I o=
ften observe implementers make questionable choices because of the large le=
eway specifications allow. My hope
 was that the scope of this profile was small enough to make that extra lev=
el of guidance achievable, whereas trying to do the same with a larger spec=
 would have been prohibitively expensive.



I believe things worked out well so far: we had lots=
 of constructive discussions, and I ended up relaxing A LOT of the constrai=
nts I was originally envisioning. Nonetheless, my
 hope is that we identified the right set of guidelines that will help peop=
le actually interoperate out of the box for the most basic/common scenarios=
, as opposed to complying with the letter of the spec but still having a lo=
t to figure out out of band.



=C2=A0






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Dominick Baier

Sent: Thursday, April 16, 2020 12:10 AM

To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






=C2=A0




Since this is the last call, I thought I bring up some of thoughts / con=
cerns. Some of them have been discussed before.






=C2=A0






client_id vs sub






I am still not entirely happy with the =E2=80=9Cre-purposing=E2=80=9D of=
 the claim types based on flow.






If the intention is, that sub expresses the entity against which the res=
ource will do authorisation (and that might be a client
 or a user) - I get it (and maybe it should be stated like that) - but






this thinking reminds me of the old AD days where there was no distincti=
on between user and service accounts (something that
 has been fixed IIRC in Windows Server 2012 R2).






=C2=A0






All other OAuth specs make a very clear distinction between users and cl=
ient.






=C2=A0






Furthermore it says






=C2=A0






"Authorization servers should prevent scenarios where clients can






=C2=A0 =C2=A0affect the value of the sub claim in ways that could confus=
e resource






=C2=A0 =C2=A0servers.=E2=80=9D






=C2=A0






If we keep that dual semantics of the sub claim - it must be clearly sta=
ted, that subject ID and client ID are now in the same
 collision domain. So when an AS / OP creates them, they need to be unique =
across user ids and client ids.






=C2=A0






Maybe it should be also explicitly mentioned that sub has a different se=
mantic here as in OIDC - even though a majority of the
 software built today will use them together.






=C2=A0






audience claim






I am not fully clear why aud is required. OAuth itself does not have a n=
otion of an audience (in the JWT sense) - they have
 scopes (which is very similar). But in simple scenarios where resources do=
n=E2=80=99t exist, you'd need to make up an audience just to fulfil thi=
s requirement. And in many case this will be either static or just repeat t=
he scope values. What=E2=80=99s the value of that?






=C2=A0






If the concept of resources are used, I absolutely agree that aud should=
 be used too. But I wouldn=E2=80=99t make it required.=







=C2=A0






iat vs nbf






What=E2=80=99s the rationale for using iat instead of nbf. Aren=E2=80=99=
t most JWT libraries (including e.g. the .NET one) looking for nbf by
 default?






=C2=A0






General






This spec feels somehow in between a profile and a BCP. On one hand you =
define some claims and their semantics (good) - on the
 other hand there is some prescriptive guidance and maybe over-specificatio=
n. My concern is, that in the end no-one will fully comply with it, because=
 it doesn=E2=80=99t work one way or the other for them.






=C2=A0






I know we just went though the discussion to make certain claims require=
d as opposed to optional - but maybe less is more.






=C2=A0






Tbh - the most valuable part of the doc to me is the definition of the =
=E2=80=9Cat+jwt=E2=80=9D typ. For the rest I=E2=80=99d rather like to see j=
ust
 some standard claims and IF they are used, which semantics they have.






=C2=A0




cheers=C2=A0




=E2=80=94=E2=80=94=E2=80=94




Dominick Baier






=C2=A0


On 15. April 2020=
 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com) wrote:










Hi all,



=C2=A0



This is a second working group last call for "JSON Web Token (JWT) Pro=
file for OAuth 2.0 Access Tokens".



=C2=A0



Here is the document:



https://tools.ietf.org/html/draft-ietf-oauth-acces=
s-token-jwt-06



=C2=A0



Please send your comments to the OAuth mailing list by April 29, 2020.



=C2=A0



Regards,



=C2=A0Rifaat & Hannes



=C2=A0




_______________________________________________


OAuth mailing list 

OAuth@ietf.org 

h=
ttps://www.ietf.org/mailman/listinfo/oauth





























_______________________________________________=


OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth

























--00000000000031b65e05a411cf6c--


From nobody Fri Apr 24 16:49:52 2020
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 34F633A0FDB for ; Fri, 24 Apr 2020 16:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jXub4liCb9k for ; Fri, 24 Apr 2020 16:48:04 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0: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 023F33A0FCF for ; Fri, 24 Apr 2020 16:48:03 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id b18so10955141ilf.2 for ; Fri, 24 Apr 2020 16:48:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yk6UPZy3qFI0VwMIh0pjJKqtabeUJJ1YHZVEQm4hVGg=; b=mima/pKS0dlU/bT24OfNTcEeBqwrHIR9YhHAKxoNbi9R0dcPDsw8O9qyMKRZ7Ozvfb PV743zq2clNV2N7tzgi6qZ87bFz6SSDYcWRoBXDCjCgZyQxre/ExHvpA9SSPqBMe7pTj g5i6O0kKq3+yW/KMaGzVwpA9c1htjUbKo62ohCOMfzHW9DxrvVm+j6cyHmk7etHiCYgy kggVyfDlYwGepKuhdISLyKGrglSsmB2uqKeNBJFo2A6VXuU0SCLj2tFY85pT8NE1X+5i UIVkJwaVTDmUzTUrNyXU82kEiWtY5uf4MENuV/GkzquNnyH2UEvnADQPw4Pj8jlgoOeW DkhQ==
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=Yk6UPZy3qFI0VwMIh0pjJKqtabeUJJ1YHZVEQm4hVGg=; b=pH+GC6KTAqQdssfHV9W8hx4vkLMxPlBkN+52QLuFRSYYQaIXp+nhgI4UMyg4BulTmL XucO1sPYqxVkEpfp3c8grSad2W8nvIi1W/zZ1EfTRoiJIX6p6FZ5o4FZbtDsaWh2f4WT UJz8wzSrClh6im92bMUr0RzttV5hOV8gKZVrp3VbOdDkSKHa0dIR12jNSwhkBXJbCZOQ 6LBW20bkDwSF4S/CHTzRYRwaKSnt3gbODWljvg3EWbxhWV2goJnel39gsuNdSPb0tpG3 KRYPh3yQTZQzlyIspLR+NSuN6JyYFkY2336DJTYHaamE/K4hv3Pj0rKlpD2poryONM81 +DYg==
X-Gm-Message-State: AGi0PuZuTQpBz0F2dJvI5AxtZ47ZyRNrgexrzNf9tnEdZgB2cVCkO0SB xw7+Anaov+YFQFP27S+Ayq6Z3X8g4FE=
X-Google-Smtp-Source: APiQypKNfsqYx+eRQCD/wVO2ZtsGbtkYX6UNBq+1YiBycvdtCcZMQqy57ljPJ3f1kYr0wwdyrVf9nQ==
X-Received: by 2002:a05:6e02:cc4:: with SMTP id c4mr10749478ilj.31.1587772082280;  Fri, 24 Apr 2020 16:48:02 -0700 (PDT)
Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id o89sm2586376ili.72.2020.04.24.16.48.00 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 16:48:01 -0700 (PDT)
Received: by mail-io1-f52.google.com with SMTP id y26so2389890ioj.2 for ; Fri, 24 Apr 2020 16:48:00 -0700 (PDT)
X-Received: by 2002:a6b:7302:: with SMTP id e2mr10198481ioh.98.1587772080340;  Fri, 24 Apr 2020 16:48:00 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 24 Apr 2020 16:47:49 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000d543f405a411fe76"
Archived-At: 
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
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, 24 Apr 2020 23:48:10 -0000

--000000000000d543f405a411fe76
Content-Type: text/plain; charset="UTF-8"

Thanks for the detailed review Brian! I've made many of these edits to the
draft, but there are still a few things that need some discussion on the
list. My notes are inline below.


On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell  wrote:

> Been working on this on and off for a while now (it's not exactly short at
> 80+ pages, various other priorities, etc.) but wanted to share my thoughts
> from an initial review of the OAuth 2.1 draft before the interim next week
> where it is on the agenda
> https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.
> So for better or worse, here's that review:
>
> Abstract:
> "replaces and obsoletes the OAuth 2..0 Authorization Framework described
> in RFC 6749."
> I think "replaces" is probably unnecessary here and, to be pedantic, is
> arguably inaccurate because published RFCs don't ever go away or get
> replaced.
> Probably should also consider using the official "obsoletes" attribute
> marker too for 6749 https://tools.ietf.org/html/rfc7991#section-2.45.8
> and probably also "updates"/"obsoletes" for others based on the scope of
> the rest of the document (not sure how this even works with a BCP or if you
> can or would want to update or obsolete a BCP) if this work proceeds. That
> scope could be better described in the abstract too as discussed somewhat
> in the thead
> https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/
> and also the 1st paragraph of
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12.
> What is and isn't in scope is another larger question that I"m not even
> sure how to ask. What's included vs. what's referenced? Should this doc be
> incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
> antithetical to what a BCP is supposed to be but it's also a bit hard to
> tell how much was used. I mean, what happens if/when the BCP is updated?
> And that kinda begs the question of if it should also incorporate parts of
> or even replace the browser based apps draft? I guess that's a TBD circa
> page 68. There was talk about the device grant being in scope but I'm not
> seeing it (not saying it should or shouldn't be there but it was talked
> about). I dunno exactly but those are some scope questions that come to
> mind.
> Speaking of obsoleting, I do want to ensure that existing extensions and
> profiles of RFC 6749 that use legitimate extension points still present and
> unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
> not sure how that should work in practice but want to be aware of it as/if
> this work progresses.
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1
> "is designed for use with HTTP ([RFC2616])."
> I was momentarily proud of myself for knowing that RFC 2616 is obsolete
> but then remembered that the nits tool can automate the check for other
> obsolete or problematic references
> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-parecki-oauth-v2-1-01.txt
> so take a look at those issues.
> Probably should also check the errata of any documents this one intends to
> update/obsolete or just borrowed a lot of text from to see if anything
> should be applied.
>
>
I've fixed a bunch of these references. It was "fun" to track down where
all the stuff in 2616 ended up as that was split into like 5 RFCs.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.1
> "The interaction between the authorization server and resource server is
> beyond the scope of this specification."
> Don't want to try and change the scope but perhaps a mention that things
> like RFC 7662 Token Introspection and self-contained tokens a la JWT exist
> here (or sec 1.4 or 7 or...) would be worthwhile.
>
>
I'm not sure how best to phrase this here since it's so early on in the
draft, but I'm generally in favor of something like this.


>
> https://tools.ietf..org/html/draft-parecki-oauth-v2-1-01#section-1.5
> 
> "   Steps (3), (4), (5), and (6) are outside the scope of this
>    specification, as described in Section 7."
> But Section 7 incorporates parts of RFC 6750 so being out of scope isn't
> really true.
>
>
Agreed, I dropped that "out of scope" mention.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.8
> Not too sure about this section in this document but seems that it should
> at least reflect the fact that some things like RFC 8414  Authorization
> Server Metadata do now exist.
>
>
This section was a last-minute add to the OAuth 2.0 spec and probably needs
to be entirely rethought for this update.


>
> https://tools.ietf.org/html/rfc6749?#section-1.9
> All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days.
>
>
Fixed.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2
> Mentioning the existence of RFC 7591 Dynamic Client Registration here
> seems appropriate. And I think it's be super useful to say that even when
> RFC 7591 isn't being used directly, it (and registered extensions to it
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata)
> imply a common general data model for clients that's pretty widely used and
> useful even with so called static registration that "typically involve
> end-user interaction with an HTML registration form."
>
>
I've added some text mentioning the optional dynamic client registration.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.2
> "Authorization servers SHOULD NOT allow clients to influence their
>    "client_id" or "sub" value or any other claim if that can cause
>    confusion with a genuine resource owner."
> This text taken from draft-ietf-oauth-security-topic is out of context and
> somewhere between meaningless and confusing here in this document. Removing
> it or maybe something like this might be more appropriate:
>   "Authorization servers SHOULD NOT allow clients to influence their
> "client_id" value in such a way that it might cause confusion with the
> identifier of a genuine resource owner during subsequent protocol
> interactions."
>
>
I like it, I've incorporated this.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.3.1
> "The client MAY omit
>       the [client_secret] parameter if the client secret is an empty
> string."
> Let's remove that sentence. As Michael Peck noted in his review, it
> doesn't even make sense in the context of this section describing
> authentication of confidential clients using a password/client secret. And
> that sentence has been the source of some other problems. More detail is in
> this thread
> https://mailarchive.ietf.org/arch/msg/oauth/D1-FrLrSeWrg9M_ca9dbkYeruc4/
>
>
Agreed.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.3.2
> "Other Authorization Methods" should be "Other *Authentication* Methods"
> It's probably worthwhile to note or reference the other client
> authentication methods that have been specified since this text was written
> in 6749 and/or point to the OAuth Token Endpoint Authentication Methods
> registry
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method
> for them and also maybe mention that, despite the Token Endpoint in the
> name, they are general methods of client auth to the AS when making direct
> requests.
>
>
Sounds reasonable to refer to that registry. I don't know if there is an
"official" way, but I've just mentioned it in the text for now.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1
> "The means through which the client obtains the location of the
>    authorization endpoint are beyond the scope of this specification,
>    but the location is typically provided in the service documentation."
> Maybe add something like "or in the authorization server's metadata
> document [RFC8414]."
>

Sounds good.


> "Request and response parameters
>    MUST NOT be included more than once."
> please clarify that sentence to say:
> "Request and response parameters
> defined by this specification MUST NOT be included more than once."
>

Done.


>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2
> "   The authorization server MUST compare the two URIs using simple
>    string comparison as defined in [RFC3986], Section 6.2.1."
> There's absolutely no context here for understanding what two URIs are
> being compared.
> Mandating full redirect_uri comparison is maybe more appropriate in 4.1.1
> with the redirect_uri parameter somewhere. And 3.1.2.3. and 3.1.2.2 needs
> some attention with respect to this too.
> But also an exception (for the port part) to full redirect_uri comparison
> is needed for loopback redirect_uris on native clients as in
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.6.1 and
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.2 and
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-10.3.3
>
>
This is a good point, but is too much for me to try to tackle right now.
Let's revisit this.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.1
> As Michael Peck noted in his review, it's probably okay now to just
> mandate TLS for HTTP redirect URIs.. Although custom scheme or loopback
> redirect URIs for native apps wouldn't use or require TLS.
>
>
This is probably worth discussing on its own.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.2
> 
> and
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.1.2.3
> Seem to still allow for registration of partial redirection URIs. Which
> isn't gonna work with an exact match requirement.
>
>
After making the edits suggested by Michael Peck, I don't think this
section suggests partial registration anymore.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.2
> "Request and response parameters
>    MUST NOT be included more than once."
> please clarify that sentence to say:
> "Request and response parameters
> defined by this specification MUST NOT be included more than once."
>

Done.


> "   The means through which the client obtains the location of the token
>    endpoint are beyond the scope of this specification, but the location
>    is typically provided in the service documentation."
> Maybe add something like "or in the authorization server's metadata
> document [RFC8414]."
>

Done.



>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.2.1
> "Client authentication is critical
>       when an authorization code is transmitted to the redirection
>       endpoint over an insecure channel or when the redirection URI has
>       not been registered in full."
> Isn't full registration of redirection URI now required (other than maybe
> the port for native apps) by virtue of requiring a full comparison be done
> when validating the authz request?  And other than a native app using the
> loopback, maybe it's time to move to require that redirection URIs be
> accessed via secure channel?
>

I've taken off the "not been registered in full" part for now.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.2
> "Clients are
>    permitted to use "plain" only if they cannot support "S256" for some
>    technical reason and know via out-of-band configuration that the
>    server supports "plain"."
> With code_challenge_methods_supported from Authorization Server Metadata /
> RFC 8414 it doesn't have to be out-of-band anymore.
>

I mentioned RFC8414 here.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.2
>  " Typically, the "code_challenge" and "code_challenge_method" values
>    are stored in encrypted form in the "code" itself but could
>    alternatively "
> 'Typically' - really?
>

Agreed, I rephrased this. Though I am curious to do a proper survey of
implementations to see if anyone is doing this at all.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.3
> "   *  ensure that the "redirect_uri" parameter is present if the
>       "redirect_uri" parameter was included in the initial authorization
>       request as described in Section 4.1.1, and if included ensure that
>       their values are identical."
> The reference should be to 4.1.1.3.
>
> Fixed.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.4
> "   An example successful response:
>    HTTP/1.1 200 OK
>    Content-Type: application/json;charset=UTF-8
>    Cache-Control: no-store
>    Pragma: no-cache"
> Pretty sure application/json shouldn't have a charset (see note at end of
> section https://tools.ietf.org/html/rfc8259#section-11)
> and I've long thought that "Pragma: no-cache" shouldn't be there (see
> https://mailarchive.ietf.org/arch/msg/oauth/9DdkE2P0RrUZMeZAbdf3NrMfy0w/
> )
> Note that these apply to most of the example responses in the draft.
>
>
I've removed the charset from the examples. I'm not sure about no-cache.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.3
> " specifying the grant type
>    using an absolute URI (defined by the authorization server) as the
>    value of the "grant_type" parameter"
> The words in the parenthetical have led to questions in AD review of
> documents making use of the grant type extension point (see
> https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1581) and I think
> "understood by the authorization server" might be better phrasing or even
> removing the parenthetical all together.
> RFC7522 is mentioned here as an example extension grant but maybe worth
> also including mention of others like RFC7523, RFC8628, RFC8693, and maybe
> even non IETF ones.
>

Suggestions welcome here.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6
>  "  *  _Sender-constrained refresh tokens:_ the authorization server
>       cryptographically binds the refresh token to a certain client
>       instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]."
> Given the relative immaturity of ways to do this, maybe something more
> open ended would be appropriate? This reads like token-binding or MTLS are
> the only ways allowed. I'd think wording that would allow for DPoP or some
> yet-to-be-defined method would be better here. Also maybe drop the
> token-binding reference all together (it's long expired and doesn't look
> like that's gonna change).
>

I'm generally supportive of something more open ended here. Would that also
suggest that the corresponding text in the Security BCP be updated as well?



> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-7.4.4
> The SHOULDs/RECOMMENDEDs in this section seem a little overzealous and/or
> too specific.
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.4
> Seems to be a lot of overlap and duplication between 9.4. Access Tokens
> (under 9. Security Considerations) and section 7.4. Access Token Security
> Considerations, which could/should maybe be reconciled.
> "(#pop_tokens)" hints that some text was copied from elsewhere but the
> markdown references weren't fixed/updated
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.5
> "(#refresh_token_protection)" same thing about markdown references not
> fixed/updated
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.6
> "(#insufficient_uri_validation)", "(#mix_up)",
> "(#open_redirector_on_client)","(#csrf_countermeasures)", again
> "(#mix_up)", and "(#redirect_307)"
>

I'm not sure how this happened but it'll take a bit to track these down.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.7
> "Attacker A4 in (#secmodel)"
> "The use of PKCE is RECOMMENDED to this end."
> PKCE is required elsewhere so this doesn't seem quite right. Similar
> comments about text ijn
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14 that
> talks as though PKCE might not be there.
>

I believe this text was included since an extension such as OpenID Connect
can define other methods of authorization code injection. Also note that
this same sentence is in the Security BCP so if we update anything here
they should probably match.


>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.17.1
> "(#redir_uri_open_redir)"
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.20
> "(#client_impersonating)"
>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
> "   *  Redirect URIs must be compared using exact string matching as per
>       Section 4.1.3 of [I-D.ietf-oauth-security-topics]"
> Should that maybe be qualified to cover dynamic ports on ephemeral local
> http servers used for redirect URI with native clients?
> BTW, does [I-D.ietf-oauth-security-topics] need to make a similar
> allowance?
>

Sounds like there are a few things around redirect URIs that need to be
clarified in both documents.


>
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#appendix-C
> "TBD"
> Given the potentially high visibility of an OAuth 2.1 effort, I think it'd
> be worthwhile to list organizational affiliations of individuals here in
> the acknowledgements along with their names. Something like what was done
> in the first part of
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A.
> This can help with visibility and justification of (sometimes not
> insignificant) time spent on the work by non-authors/editors.
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000d543f405a411fe76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the detailed review Brian! I&#=
39;ve made many of these edits to the draft, but there are still a few thin=
gs that need some discussion on the list. My notes are inline below.

On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.i=
etf.org> wrote:
Been working on this on and off for a while no=
w (it's not exactly short at 80+ pages, various other priorities, etc.)=
 but wanted to share my thoughts from an initial review of the OAuth 2.1 dr=
aft before the interim next week where it is on the agenda https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-o=
auth-01/.=C2=A0 So for better or worse, here's that review: 

Abstract:
"replaces and obsoletes the=
 OAuth 2..0 Authorization Framework described in RFC 6749." 
=

I think "replaces" is probably unnecessary here and, to be p=
edantic, is arguably inaccurate because published RFCs don't ever go aw=
ay or get replaced. 
Probably should also consider using the =
official "obsoletes" attribute marker too for 6749 https://=
tools.ietf.org/html/rfc7991#section-2.45.8 and probably also "upda=
tes"/"obsoletes" for others based on the scope of the rest o=
f the document (not sure how this even works with a BCP or if you can or wo=
uld want to update or obsolete a BCP) if this work proceeds. That scope cou=
ld be better described in the abstract too as discussed somewhat in the the=
ad https://mailarchive.ietf.org/arch/msg/oauth/=
Ne4Q9erPP7SpC5051sSy6XnLDv0/ and also the 1st paragraph of https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section=
-12. 
What is and isn't in scope is another larger qu=
estion that I"m not even sure how to ask. What's included vs. what=
's referenced? Should this doc be incorporating bits of BCP 212 - OAuth=
 2.0 for Native Apps? Seems kinda antithetical to what a BCP is supposed to=
 be but it's also a bit hard to tell how much was used. I mean, what ha=
ppens if/when the BCP is updated? And that kinda begs the question of if it=
 should also incorporate parts of or even replace the browser based apps dr=
aft? I guess that's a TBD circa page 68. There was talk about the devic=
e grant being in scope but I'm not seeing it (not saying it should or s=
houldn't be there but it was talked about). I dunno exactly but those a=
re some scope questions that come to mind. 
Speaking of obsol=
eting, I do want to ensure that existing extensions and profiles of RFC 674=
9 that use legitimate extension points still present and unchanged in OAuth=
 2.1 aren't inadvertently impacted by this effort. I'm not sure how=
 that should work in practice but want to be aware of it as/if this work pr=
ogresses. 


"is designed for use with HTTP ([RFC2616])."=C2=A0=C2=
=A0 
I was momentarily proud of myself for knowing that RFC 2=
616 is obsolete but then remembered that the nits tool can automate the che=
ck for other obsolete or problematic references https://tools.ietf.org/idnits?url=3Dhttps://tools.iet=
f.org/id/draft-parecki-oauth-v2-1-01.txt so take a look at those issues=
. 
Probably should also check the errata of any documents thi=
s one intends to update/obsolete or just borrowed a lot of text from to see=
 if anything should be applied. 


I've fixed a bunch of these references. It was &qu=
ot;fun" to track down where all the stuff in 2616 ended up as that was=
 split into like 5 RFCs.
=C2=A0

"The interaction between the authorization se=
rver and resource server is beyond the scope of this specification." <=
br>
Don't want to try and change the scope but perhaps a ment=
ion that things like RFC 7662 Token Introspection and self-contained tokens=
 a la JWT exist here (or sec 1.4 or 7 or...) would be worthwhile. 


I'm not sure how=
 best to phrase this here since it's so early on in the draft, but I=
9;m generally in favor of something like this.
=C2=A0

"=C2=A0=C2=A0 Steps (3=
), (4), (5), and (6) are outside the scope of this
=C2=A0 =C2=A0specific=
ation, as described in Section 7." 
But Section 7 incorp=
orates parts of RFC 6750 so being out of scope isn't really true. 
<=
/div>


Agreed, I droppe=
d that "out of scope" mention.
=C2=A0

=

Not too sure about this section in=
 this document but seems that it should at least reflect the fact that some=
 things like RFC 8414=C2=A0 Authorization Server Metadata do now exist.


This section was a =
last-minute add to the OAuth 2.0 spec and probably needs to be entirely ret=
hought for this update.
=C2=A0

All the cool d=
rafts are doing BCP 14 [RFC2119] [RFC8174] these days. 

<=
/div>

Fixed.
=C2=A0

Mentioning the existence of =
RFC 7591 Dynamic Client Registration here seems appropriate. And I think it=
's be super useful to say that even when RFC 7591 isn't being used =
directly, it (and registered extensions to it https://www.iana.org/assignments/oauth-parameters/oauth-para=
meters.xhtml#client-metadata) imply a common general data model for cli=
ents that's pretty widely used and useful even with so called static re=
gistration that "typically involve end-user interaction with an HTML r=
egistration form."


I've added some text mentioning the optional dynamic client reg=
istration.
=C2=A0

"Authorization servers SHOULD NOT allow clients to influenc=
e their
=C2=A0 =C2=A0"client_id" or "sub" value or a=
ny other claim if that can cause
=C2=A0 =C2=A0confusion with a genuine r=
esource owner."
This text taken from draft-ietf-oauth-securi=
ty-topic is out of context and somewhere between meaningless and confusing =
here in this document. Removing it or maybe something like this might be mo=
re appropriate:
=C2=A0 "Authorization servers SHOULD NOT=
 allow clients to influence their "client_id" value in such a way=
 that it might cause confusion with the identifier of a genuine resource ow=
ner during subsequent protocol interactions."


I like it, I've incorporated this.
=C2=A0

"The client MAY omit
=C2=A0 =C2=A0 =C2=A0 the [client_secret] pa=
rameter if the client secret is an empty string." 
Let&#=
39;s remove that sentence. As Michael Peck noted in his review, it doesn=
9;t even make sense in the context of this section describing authenticatio=
n of confidential clients using a password/client secret. And that sentence=
 has been the source of some other problems. More detail is in this thread =
https://mailarchive.ietf.org/arch/msg/oauth/D1-=
FrLrSeWrg9M_ca9dbkYeruc4/ 

<=
div>
Agreed.
=C2=A0

"Other Authorization Methods" shou=
ld be "Other *Authentication*  Methods"
It's probab=
ly worthwhile to note or reference the other client authentication methods =
that have been specified since this text was written in 6749 and/or point t=
o the OAuth Token Endpoint Authentication Methods registry https://www.iana.org/assignments/oau=
th-parameters/oauth-parameters.xhtml#token-endpoint-auth-method for the=
m and also maybe mention that, despite the Token Endpoint in the name, they=
 are general methods of client auth to the AS when making direct requests. =



Sounds reas=
onable to refer to that registry. I don't know if there is an "off=
icial" way, but I've just mentioned it in the text for now.
<=
div>=C2=A0

"=
;The means through which the client obtains the location of the
=C2=A0 =
=C2=A0authorization endpoint are beyond the scope of this specification,=C2=A0 =C2=A0but the location is typically provided in the service documen=
tation." 
Maybe add something like "or in the autho=
rization server's metadata document [RFC8414]." 

Sounds good.
=C2=A0
&=
quot;Request and response parameters
=C2=A0 =C2=A0MUST NOT be included m=
ore than once."
please clarify that sentence to say:
"Request and response parameters

defined by this specification MUST NOT be included more than once<=
/span>."

Done.
=
=C2=A0


&q=
uot;=C2=A0=C2=A0 The authorization server MUST compare the two URIs using s=
imple
=C2=A0 =C2=A0string comparison as defined in [RFC3986], Section 6.=
2.1."
There's absolutely no context here for understandi=
ng what  two URIs are being compared.=C2=A0
Mandating full redire=
ct_uri comparison is maybe more appropriate in 4.1.1 with the redirect_uri =
parameter somewhere. And 3.1.2.3. and 3.1.2.2 needs some attention with res=
pect to this too. 
But also an exception (for the port part) =
to full redirect_uri comparison is needed for loopback redirect_uris on nat=
ive clients as in https://tools.ietf.org/html/draf=
t-parecki-oauth-v2-1-01#section-9.6.1 and https:=
//tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.2 and https://tools.ietf.org/html/draft-parecki-oauth-v2-1-0=
1#section-10.3.3 


<=
/div>
This is a good point, but is too much for me to try to tackle rig=
ht now. Let's revisit this.
=C2=A0
As Michael Peck noted in his review=
, it's probably okay now to just mandate TLS for HTTP redirect URIs.. A=
lthough custom scheme or loopback redirect URIs for native apps wouldn'=
t use or require TLS. 


=

This is probably worth discussing on its own.
=C2=A0

Seem to still allow for registration of partial redi=
rection URIs. Which isn't gonna work with an exact match requirement. <=
br>


After making=
 the edits suggested by Michael Peck, I don't think this section sugges=
ts partial registration anymore.
=C2=A0
"Request and response parameters=

=C2=A0 =C2=A0MUST NOT be included more than once."
pleas=
e clarify that sentence to say:
"Request and response pa=
rameters

defined by this specification MUST NOT be included more than once<=
/span>."

Done.
=

=C2=A0
"=C2=A0=C2=A0 The means through which the client obtains=
 the location of the token
=C2=A0 =C2=A0endpoint are beyond the scope of=
 this specification, but the location
=C2=A0 =C2=A0is typically provided=
 in the service documentation."
Maybe add something like &qu=
ot;or in the authorization server's metadata document [RFC8414]."=
=C2=A0

Done.=C2=A0
=C2=A0
=


ht=
tps://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-3.2.1
"Client authentication is critical
=C2=A0 =C2=A0 =C2=A0 when=
 an authorization code is transmitted to the redirection
=C2=A0 =C2=A0 =
=C2=A0 endpoint over an insecure channel or when the redirection URI has=C2=A0 =C2=A0 =C2=A0 not been registered in full."
Isn'=
t full registration of redirection URI now required (other than maybe the p=
ort for native apps) by virtue of requiring a full comparison be done when =
validating the authz request?=C2=A0 And other than a native app using the l=
oopback, maybe it's time to move to require that redirection URIs be ac=
cessed via secure channel?

I=
9;ve taken off the "not been registered in full" part for now.
=C2=A0

https=
://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.2
"Clients are
=C2=A0 =C2=A0permitted to use "plain" =
only if they cannot support "S256" for some
=C2=A0 =C2=A0techn=
ical reason and know via out-of-band configuration that the
=C2=A0 =C2=
=A0server supports "plain"." 
With code_challe=
nge_methods_supported from Authorization Server Metadata / RFC 8414 it does=
n't have to be out-of-band anymore.=C2=A0=C2=A0

I mentioned RFC8414 here.=C2=A0
=C2=A0
=


=C2=A0" Typic=
ally, the "code_challenge" and "code_challenge_method" =
values
=C2=A0 =C2=A0are stored in encrypted form in the "code"=
 itself but could
=C2=A0 =C2=A0alternatively " 
'=
Typically' - really?

Agreed=
, I rephrased this. Though I am curious to do a proper survey of implementa=
tions to see if anyone is doing this at all.
=C2=A0
"=C2=A0=C2=A0 * =C2=A0ensure tha=
t the "redirect_uri" parameter is present if the
=C2=A0 =C2=A0=
 =C2=A0 "redirect_uri" parameter was included in the initial auth=
orization
=C2=A0 =C2=A0 =C2=A0 request as described in Section 4.1.1, an=
d if included ensure that
=C2=A0 =C2=A0 =C2=A0 their values are identica=
l."
The reference should be to 4.1.1.3. 

<=
/div>
Fixed.
=C2=A0

"=C2=A0=C2=A0 An example succe=
ssful response:
=C2=A0 =C2=A0HTTP/1.1 200 OK
=C2=A0 =C2=A0Content-Typ=
e: application/json;charset=3DUTF-8
=C2=A0 =C2=A0Cache-Control: no-store=

=C2=A0 =C2=A0Pragma: no-cache"
Pretty sure application/j=
son shouldn't have a charset (see note at end of section https://tool=
s.ietf.org/html/rfc8259#section-11) 
and I've long th=
ought that "Pragma: no-cache" shouldn't be there (see https://mailarchive.ietf.org/arch/msg/oauth/9DdkE2P0Rr=
UZMeZAbdf3NrMfy0w/ ) 
Note that these apply to most of th=
e example responses in the draft. 


I've removed the charset from the examples. I=
9;m not sure about no-cache.
=C2=A0

<=
a href=3D"https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4=
.3" target=3D"_blank">https://tools.ietf.org/html/draft-parecki-oauth-v2-1-=
01#section-4.3
" specifying the grant type
=C2=A0 =C2=
=A0using an absolute URI (defined by the authorization server) as the
=
=C2=A0 =C2=A0value of the "grant_type" parameter"
=
The words in the parenthetical have led to questions in AD review of docume=
nts making use of the grant type extension point (see https:=
//mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1581) and I think &quo=
t;understood by the authorization server" might be better phrasing or =
even removing the parenthetical all together.
RFC7522 is mentione=
d here as an example extension grant but maybe worth also including mention=
 of others like RFC7523, RFC8628, RFC8693, and maybe even non IETF ones.=C2=
=A0

Suggestions welcome here.
=C2=A0
 

https://t=
ools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6
=C2=A0"=
;=C2=A0 * =C2=A0_Sender-constrained refresh tokens:_ the authorization serv=
er
=C2=A0 =C2=A0 =C2=A0 cryptographically binds the refresh token to a c=
ertain client
=C2=A0 =C2=A0 =C2=A0 instance by utilizing [I-D.ietf-oauth=
-token-binding] or [RFC8705]."
Given the relative immaturity=
 of ways to do this, maybe something more open ended would be appropriate? =
This reads like token-binding or MTLS are the only ways allowed. I'd th=
ink wording that would allow for DPoP or some yet-to-be-defined method woul=
d be better here. Also maybe drop the token-binding reference all together =
(it's long expired and doesn't look like that's gonna change). =


I'm generally supporti=
ve of something more open ended here. Would that also suggest that the corr=
esponding text in the Security BCP be updated as well?

=

=C2=A0
The SHOULDs/RECOMMENDE=
Ds in this section seem a little overzealous and/or too specific. 


Seems to be a lot of overlap and duplication between 9.4. Access Tokens (=
under 9. Security Considerations) and section 7.4. Access Token Security Co=
nsiderations, which could/should maybe be reconciled.=C2=A0 
=
"(#pop_tokens)" hints that some text was copied from elsewhere bu=
t the markdown references weren't fixed/updated


"(#refresh_token_protec=
tion)" same thing about markdown references not fixed/updated


"(#=
insufficient_uri_validation)", "(#mix_up)", "(#open_red=
irector_on_client)","(#csrf_countermeasures)", again "(=
#mix_up)", and "(#redirect_307)"=C2=A0

I'm not sure how this happened but it'll tak=
e a bit to track these down.
=C2=A0

<=
a href=3D"https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9=
.7" target=3D"_blank">https://tools.ietf.org/html/draft-parecki-oauth-v2-1-=
01#section-9.7
"Attacker A4 in (#secmodel)" 
"The use of PKCE is RECOMMENDED to this end."
P=
KCE is required elsewhere so this doesn't seem quite right. Similar com=
ments about text ijn https://tools.ietf.org/html/dr=
aft-parecki-oauth-v2-1-01#section-9.14 that talks as though PKCE might =
not be there.=C2=A0=C2=A0

I bel=
ieve this text was included since an extension such as OpenID Connect can d=
efine other methods of authorization code injection. Also note that this sa=
me sentence is in the Security BCP so if we update anything here they shoul=
d probably match.
=C2=A0

"(#redir_uri_open_redir)" 
=



"(#=
client_impersonating)" 


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01=
#section-12
"=C2=A0=C2=A0 * =C2=A0Redirect URIs must be compare=
d using exact string matching as per
=C2=A0 =C2=A0 =C2=A0 Section 4.1.3 =
of [I-D.ietf-oauth-security-topics]"
Should that maybe be qu=
alified to cover dynamic ports on ephemeral local http servers used for red=
irect URI with native clients? 
BTW, does [I-D.ietf-oauth-sec=
urity-topics] need to make a similar allowance?=C2=A0

Sounds like there are a few things around redirect U=
RIs that need to be clarified in both documents.
=C2=A0


"TBD" 
Given the potentially high visibility of an OAuth 2.1 effort, I thin=
k it'd be worthwhile to list organizational affiliations of individuals=
 here in the acknowledgements along with their names. Something like what w=
as done in the first part of https://tools.i=
etf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A. This can =
help with visibility and justification of (sometimes not insignificant) tim=
e spent on the work by non-authors/editors. 

<=
br>






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you._______________________=
________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--000000000000d543f405a411fe76--


From nobody Fri Apr 24 19:02:37 2020
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 BEC7A3A0408 for ; Fri, 24 Apr 2020 19:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17ZSeKKfz_R7 for ; Fri, 24 Apr 2020 19:02:34 -0700 (PDT)
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 32FF63A040A for ; Fri, 24 Apr 2020 19:02:34 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03P22R3S019913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 22:02:29 -0400
Date: Fri, 24 Apr 2020 19:02:27 -0700
From: Benjamin Kaduk 
To: Vittorio Bertocci 
Cc: Mike Jones , oauth , Vittorio Bertocci 
Message-ID: <20200425020227.GE27494@kduck.mit.edu>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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: Sat, 25 Apr 2020 02:02:36 -0000

Just on the xml2rfc bits...

On Wed, Apr 22, 2020 at 07:26:40AM +0000, Vittorio Bertocci wrote:
> 
> > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 of this doc.
> Oh wow. That’s a feature of XML2RFC,… my source simply says by section 4.1.2 of SCIM Core  in a  block, and the processor interpret it as an internal link. I’ll need to dig on how to prevent that from happening for this instance. Good catch!

The short form is "you can't".

You're using the "v2" XML format for xml2rfc, which produces as various
output formats text, pdf, and "htmlized" output.  The "htmlized" output is
called that and not "html" because it's the result of taking the text
output and running a script to turn common constructions in I-Ds and RFCs
into hopefully-useful HTML formatting.  In this case, "Section N" outside
of "Section N of [bracketed-reference]" is assumed to be "Section N of the
current document", and that's all that the htmlization script is going to
give you, since it's not working with the semantic richness of the XML
source.

We do, however, as of fairly recently have a "v3" XML format, which is
capable of producing native HTML output that includes SVG figures and the
other exciting features of "v3 XML".  For an example, see
https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .

I personally haven't done any v2-to-v3 conversions yet (too busy reading to
have time to do much writing), but the FAQ entry for doing so is at
https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
.

Hope that helps,

Ben


From nobody Fri Apr 24 19:05:38 2020
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 A19523A0443 for ; Fri, 24 Apr 2020 19:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiIu-5ql1_0M for ; Fri, 24 Apr 2020 19:05:36 -0700 (PDT)
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 00DD93A043F for ; Fri, 24 Apr 2020 19:05:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03P25RSi020548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 22:05:29 -0400
Date: Fri, 24 Apr 2020 19:05:27 -0700
From: Benjamin Kaduk 
To: Mike Jones 
Cc: Neil Madden , Vladimir Dzhuvinov , "oauth@ietf.org" 
Message-ID: <20200425020527.GF27494@kduck.mit.edu>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth GREASE
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: Sat, 25 Apr 2020 02:05:38 -0000

On Thu, Apr 23, 2020 at 04:52:49PM +0000, Mike Jones wrote:
> 
> I’d personally point out these non-compliant behaviors to the vendors and ask them to fix them.  Their non-compliance makes it harder for clients to interoperate with them, hurting both.  Name names, if that’s what it takes.

My understanding is that David Benjamin (author of TLS GREASE) put a lot of
time into tracking down and persuading vendors of broken implementations to
fix their stuff before GREASE itself could even be widely deployed without
a fallback.  GREASE is the result of wanting to never have to do that again
:)

So yes, someone should start tracking these people down, and I see a pretty
decent case for writing down something about OAuth GREASE as well.

-Ben


From nobody Sat Apr 25 06:55:24 2020
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 A68D43A0FA0; Sat, 25 Apr 2020 06:55:21 -0700 (PDT)
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: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158782292128.14210.4772883516559961122@ietfa.amsl.com>
Date: Sat, 25 Apr 2020 06:55:21 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-09.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: Sat, 25 Apr 2020 13:55:22 -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           : JWT Response for OAuth Token Introspection
        Authors         : Torsten Lodderstedt
                          Vladimir Dzhuvinov
	Filename        : draft-ietf-oauth-jwt-introspection-response-09.txt
	Pages           : 18
	Date            : 2020-04-25

Abstract:
   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-09
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-09


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 Sat Apr 25 06:59:36 2020
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 CEC3A3A0FA4 for ; Sat, 25 Apr 2020 06:59:34 -0700 (PDT)
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=lodderstedt.net
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 zgFwRQJmjdGN for ; Sat, 25 Apr 2020 06:59:33 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 634CB3A0C98 for ; Sat, 25 Apr 2020 06:59:33 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id x25so14313806wmc.0 for ; Sat, 25 Apr 2020 06:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bY34Q3WmgrMcwg02R2aFP0ECvKEUVY5pvh6pnke1d2U=; b=DiDVXNn3Ln8qK8NNbWWBENM0Hsz4JoRdXPDTBTWEm+q3Ba9YFnwHQDxuJejxR683DA dZC67YfkDA5s9ISitKcsVYXGJzKu5pHguPNbCwos8GSoG9AUwMV3IFBB2CxdWnehz192 MaM9f2ru9LzP1+BIZGJpQHDScxAIYzgzWB+v0CBOC2TJIwv7UxqMY0VgckZZPCEDYcl7 UerCdRPVefpC2g6Lmm4Lf6j7ARQvxzbvL92BFHvDxGOVIu+gTSejXrjJZcJgyDKm4NbP 269j7YA2vxOvmOG/VEBF+farj+AfvVxI383l5PwD8nplBizZQ7Bgu+AxY38eeUT9/KiH jIrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bY34Q3WmgrMcwg02R2aFP0ECvKEUVY5pvh6pnke1d2U=; b=OewAQz5WhmzW+hsi1vB6PXhxHAr/aFD9h+0OdD09LItXbi8inyouD17cMZg1cQ6M9C SuvRGz+MO54CenwDfTr+Anvbv217vOnQtqS+TTLwO+d5Z4M88QeE8o1/whtJlKt4ytwM th/KH9KDc7x1YiCo3L/Xj0QAL+i4Ov4Ty7pyDRmZtWBAc/52W23hVDQPjNcuo1pMdrl+ 4sYXtpM6PhpztPy6ui2eshjCnMTrP3TrSE9QAIYcnASATjbJUUCXzT2JmbeLCz0qShcl lM6n4p1Nf5Sic4ecIAsVESyqrKO51umC0/Ezy7cofq31f3XFLDHjYzwi/z96KsoTUa/9 j37Q==
X-Gm-Message-State: AGi0Pua69oBpfKa1EmyV+vYDsJSYcG+LuIX8r7W6L58kotQlElueP3OF 66akIl1FjYoxPULLvpu0swCAeG1xFlc=
X-Google-Smtp-Source: APiQypLiBULvEKDixCqiB+oj0je1FiRgQ9hW1lkA6jL6FbHKkhurOYRT76IPv5bQmXV23Rf2TH8vVQ==
X-Received: by 2002:a7b:ce13:: with SMTP id m19mr15387147wmc.76.1587823171278;  Sat, 25 Apr 2020 06:59:31 -0700 (PDT)
Received: from [192.168.71.111] (p5B0D9376.dip0.t-ipconnect.de. [91.13.147.118]) by smtp.gmail.com with ESMTPSA id q10sm12017805wrv.95.2020.04.25.06.59.30 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 06:59:30 -0700 (PDT)
From: Torsten Lodderstedt 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 25 Apr 2020 15:59:29 +0200
References: <158782292128.14210.4772883516559961122@ietfa.amsl.com>
To: oauth 
In-Reply-To: <158782292128.14210.4772883516559961122@ietfa.amsl.com>
Message-Id: <0B7C4ABE-6B01-437B-B520-442333D6E1F8@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-09.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: Sat, 25 Apr 2020 13:59:35 -0000

Hi all,

the new revision puts the data of the introspected token into a top =
level claim =E2=80=9Ctoken_introspection=E2=80=9D. This allows to =
clearly distinguish the claims of the  JWT serving as representation of =
the introspection response from the actual token claims with same name, =
e.g. =E2=80=9Ciat=E2=80=9D.

The new revision will be presented in the virtual meeting next Monday.=20=


best regards,
Torsten. =20

> On 25. Apr 2020, at 15:55, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        Title           : JWT Response for OAuth Token Introspection
>        Authors         : Torsten Lodderstedt
>                          Vladimir Dzhuvinov
> 	Filename        : =
draft-ietf-oauth-jwt-introspection-response-09.txt
> 	Pages           : 18
> 	Date            : 2020-04-25
>=20
> Abstract:
>   This specification proposes an additional JSON Web Token (JWT)
>   secured response for OAuth 2.0 Token Introspection.
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon=
se/
>=20
> There are also htmlized versions available at:
> =
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-09=

> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-r=
esponse-09
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-introspection-res=
ponse-09
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sun Apr 26 07:57:53 2020
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 8965A3A07F0 for ; Sun, 26 Apr 2020 07:57:51 -0700 (PDT)
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=lodderstedt.net
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 jacpxJcAPXDI for ; Sun, 26 Apr 2020 07:57:49 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 CB0023A07EC for ; Sun, 26 Apr 2020 07:57:48 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id z6so17413734wml.2 for ; Sun, 26 Apr 2020 07:57:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E99585H9FZUFFzbPwRU8Es9IkjIKwmG8b9EwUAdzWbI=; b=rukzd30w8r9Kp8orbqHBMSdETtGG25LYXQwAr+neS1BbOtZRiu+EmuWzvHvB651KCN AeKRH8EcqFHUnLJba4R7IqiTdIC5drFZrFXOvJGPiTnke4KMc6uw6i94njPJhUrbbRLB 3bhZKKTyNJhiiqPgy/DfmfoBSgmRRTDPaXH9HCf7KgdXakQuz2rixPhL29gg+erkRLj5 hALCMPblh1S5GMzQCLTcZaBEs44ENq06JK/BvIkMbiqAm4hEGrmEDP9sxju1LfcI5eHL w9zVrEdb4EUEiW7I+CXM8sVLQ/DIH7sjNJ13Ou7bEz6PqQN48t/PWkuxK3E+7lOOaeeQ MZkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E99585H9FZUFFzbPwRU8Es9IkjIKwmG8b9EwUAdzWbI=; b=j76FgWU6yxIEjFoaHZU2mHnD15NAje/0uA4Ewq7nzuBlWShy9A285MH1S4Yz41WDfc EdbRrxHMk9cIlXeDrtSxYQzxa/dlRBs7z23jj9SaqVfOzBbegjiCzvaZiWuQPEdrxhfg JyieBrC36msrqiL4/5v0q/Kk7Ku37/JocmBe4HS9i0IN89aiAI8sVAEdJ3DJofPQEPo8 S7vz0uxeLfCQlRSnA/rIwq7juRqE5ztaokf1GSQJQ3B4EqcV3reNDjYvIlBUT+fH2TUI DGKmEJ6XbzBg9gKAG2/ec3Te1FFhLF+LDD5eXUYice7E4xXT2HcgOIySV3VYWZaZDsPR CJEA==
X-Gm-Message-State: AGi0PuZxA7h9qORYhCmD5GkViLFgYiRF9WCgh1zJwC7Fophe41brQG5m tO5HRUFI/fIZTFwipk6TMnLLl14phA0=
X-Google-Smtp-Source: APiQypLpTu4e0IuqwCF6dHQoOTulIvztL61Kk5DbmhKHU96Xl1R/f3bufoKjKdxu2KS/1XecJJF0+Q==
X-Received: by 2002:a1c:770e:: with SMTP id t14mr20653601wmi.187.1587913066112;  Sun, 26 Apr 2020 07:57:46 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id h16sm19460302wrw.36.2020.04.26.07.57.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 07:57:45 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
Date: Sun, 26 Apr 2020 16:57:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>  <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>
To: oauth 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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: Sun, 26 Apr 2020 14:57:52 -0000

Hi all,=20

I think this topic has several aspects:=20
- Is the client required to use PAR only? Doesn=E2=80=99t this also mean =
it is required to use request_uri only?
- Is there a need to separate those to questions or shall we treat this =
as the same?=20
- Who decides whether PAR and request_uri are required? The client for =
its instances or the AS for the whole deployment?=20

I=E2=80=99m in favour of coupling enforced PAR use with enforced =
request_uri use even though it means the setting is useful with PAR =
only, not with all JAR-based clients.
I think both the client as well as the AS should be able to declare =
forced PAR. If the AS is able to basically turn of traditional =
authorization requests, it can consequently utilize the changed protocol =
properties in terms of security and robustness in its deployment. This =
means, for example, the AS no longer needs to require pre-registered =
redirect URIs for confidential clients. It also means, the AS can use =
voluminous claims/authorization details objects without worrying about =
fragile long request URLs. =20

So here is my proposal:

1) Add server metadata parameter =
=E2=80=9Cpushed_authorization_requests_only=E2=80=9D of type boolean - =
It requires any client to use PAR, the AS will refuse to process any =
authorization request containing parameters other than request_uri + =
client_id (as required by =
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension =
request parameters need to be passed via PAR.
2) Add client registration parameter =
=E2=80=9Cpushed_authorization_requests_only=E2=80=9D - It requires this =
client to use PAR only. The AS won=E2=80=99t accept any authorization =
request containing more than request_uri + client_id for that particular =
client.=20

What are your thoughts?

best regards,
Torsten.=20

> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov =
 wrote:
>=20
> In a off-list conversation Torsten floated the idea of letting =
confidential PAR-only clients register without a redirect_uris and =
having this "PAR only" parameter will enable that.
>=20
> A "PAR only" parameter will also prevent client developers from =
accidentally making plain authz requests (for clients that rely on PAR =
for the extra security).
>=20
> Vladimir
>=20
> On 16/04/2020 18:39, Brian Campbell wrote:
>>=20
>>=20
>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle =
 wrote:
>> As I think through this, I=E2=80=99m struggling to identify the =
threats this actually helps mitigate.
>>=20
>> A client metadata parameter implies that the value may be different =
for different clients, and that any given client won=E2=80=99t already =
know via other means whether or not it needs to use PAR. That means =
we=E2=80=99re only talking about dynamic clients since statically =
registered clients already have some proprietary out-of-band =
registration mechanism (e.g., a developer console).
>>=20
>> As I tried to articulate in the original email and Filip also =
mentioned in a different fork of this email thread, defining metadata =
can be beneficial even when it's not used dynamically at runtime. So =
we're not only talking about dynamic clients.
>>=20
>> =20
>>=20
>> A client metadata parameter also implies that the AS allows some =
clients to make non-PAR requests (otherwise it would be an AS metadata =
parameter).
>>=20
>> A per client setting seems necessary for existing ASs to roll out PAR =
support over time or just generally in support of diverse client =
capabilities and requirements.=20
>>=20
>> =20
>> If that=E2=80=99s the case then presumably a malicious party could =
register their own client that doesn=E2=80=99t use PAR.
>>=20
>> So it seems to me that the only scenario that this parameter would =
protect against is a malicious party impersonating a dynamically =
registered client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, =
since in that attack the attacker uses its own client.
>>=20
>> This client metadata parameter is meant to be something that would =
prevent a malicious actor from controlling the content of the authz =
request parameters, which could be done by crafting the link and =
tricking a user into following it. I mentioned mix-up as an example =
because the first variant of it desribed at =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.=
4.1 does something along those lines.=20
>>=20
>> =20
>>=20
>> If a client can do PAR, then it can do authorization code grant and =
PKCE, so we=E2=80=99re further limited to scenarios where the attacker =
does not need to be able to redeem the authorization code themselves. =
What threats fall into this category?
>>=20
>> =E2=80=94
>> Annabelle Backman (she/her)
>> AWS Identity
>>=20
>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell =
 wrote:
>>>=20
>>> =EF=BB=BF
>>> CAUTION: This email originated from outside of the organization. Do =
not click links or open attachments unless you can confirm the sender =
and know the content is safe.
>>>=20
>>>=20
>>> I was hoping to get to a rough consensus in support of the idea =
before coming up with a name that everyone will hate :)=20
>>>=20
>>> In the meantime, however, name suggestions are of course welcome.=20
>>>=20
>>>=20
>>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov =
 wrote:
>>> I'm all for that.
>>>=20
>>> I suppose you have already thought of a suitable name? :)
>>>=20
>>> Vladimir
>>>=20
>>> On 14/04/2020 23:08, Brian Campbell wrote:
>>>> Using PAR can facilitate improved security by giving clients a =
(relatively) simple means for sending a confidential, integrity =
protected, and (for confidential clients anyway) authenticated =
authorization request.
>>>>=20
>>>> It seems like some of that improved security could be undermined by =
a malicious actor somehow getting a user to navigate to a URL of a =
regular old parameterized authorization request. One variation of the =
Mix-Up Attack does this =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.=
4.1 for example and email, social media, online forums, etc., are other =
ways a user might be tricked into following a maliciously crafted link.=20=

>>>>=20
>>>> Following from that it seems logical that an authorization server =
might want to restrict some clients from sending a regular parameterized =
authorization request and instead require use of the PAR endpoint to =
initiate an authorization request. Something like this could, of course, =
be implemented as custom policy or configuration in any AS. But I'm =
thinking it might be common enough to warrant adding a client metadata =
parameter to the PAR draft specifically for it. The metadata (and =
registered extensions) defined by Dynamic Client Registration [RFC7591] =
has come to imply a general data model and expected associated behaviors =
for clients that is useful for authorization server implementations, =
even when the Dynamic Client Registration Protocol isn't directly in =
play. This particular situation seems like a good potential candidate =
for a new such client metadata parameter that would indicate that the =
given client can only use a request_uri value obtained from the PAR =
endpoint to initiate an authorization request. And that a regular old =
fashioned authorization request from the given client would result in an =
error.=20
>>>>=20
>>>> Do the folks of this fine WG think something like this would be a =
worthwhile addition to the PAR draft?
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>>=20
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank you.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sun Apr 26 08:09:11 2020
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 B9EDA3A0864 for ; Sun, 26 Apr 2020 08:09:09 -0700 (PDT)
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=lodderstedt.net
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 s03mMocyvU5A for ; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 5CA9B3A0863 for ; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id j2so17454777wrs.9 for ; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=XjbTlymDJssY3JO0ADXwXkq0QEcmC+CmFs0HHBmqPic=; b=X/Khy72qPYg5/l5eTZGg01vqgBOLjgpcrI15Qn9bCINTpIa4CZvutBGpWiMRBF1/Vq qowWRH0fEi1Rue3NxWmIF6xewMiFOJ+5HGh29ncs9ECbiZK58vzR6mPwkZsW8V44V6FW 0kIMY4c2U7zw0tnQyvOW9IuJO06vfuURqYFLYaRsYV4kGjSlCsyM4nGxhcQB9+GAPJvb AYXCAT0i92lmiGL2i8yJy41VIK42weM2pTsf5RAjmt4YxJpYpRXOhfy5ZWBE2tcq7O0J JRCCTAFihc+xr0b378WTqoeW1p7wUtSUgcDaEFaK4+P8tdcHbIyoq1/4ofqsDIeufql4 XjAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=XjbTlymDJssY3JO0ADXwXkq0QEcmC+CmFs0HHBmqPic=; b=Bkevv6eLyUU0qRejl2J1K3v2mxAwNZJAthU2MtjQmqFyEf07vZgPLblS/Z2Wzs9TRr mJUV0MClARHSfziG7H64SYdhmuXBQlTdwaTsgGm6yIQkuks0Y6QeUN8TUmgCUxwmYMSA VGjwq5HREuwk3Vx7CeOt6Tjx9rw1EGcq8TWjI7OHPKg9/ta5h37gsjELel7I0LgwlrWv CI564IH2H2vyzGKe5VuoIPLFNS6QX0k+VdTCms65X69INQ70biHbSeLqhb75VjozoAEk +z2G7mGmlD5dvZj6ZSgbr5f4bJbuVYr/OhuRE9j77nq71a3AVNZXQre7HQxcle4vqVq9 IUyQ==
X-Gm-Message-State: AGi0PubiM0reSbE46TdoL/NO3nxw3M6bQaIumTePBS0EYFkcNKBPIyvV mLGV7Hoz2jiYB1gXxo9HnNrwuJHclGw=
X-Google-Smtp-Source: APiQypJ7bsfwFIEQth1ougbm25IBM/u3xZXouHUX2kn+pgvoOvKSumTvJV08SwbDKserkEFB/JE7Sg==
X-Received: by 2002:adf:dfcd:: with SMTP id q13mr23850583wrn.423.1587913745872;  Sun, 26 Apr 2020 08:09:05 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id p190sm11680344wmp.38.2020.04.26.08.09.05 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 08:09:05 -0700 (PDT)
From: Torsten Lodderstedt 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
Date: Sun, 26 Apr 2020 17:09:04 +0200
To: oauth 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [OAUTH-WG] PAR - Can AS/client require request object?
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: Sun, 26 Apr 2020 15:09:10 -0000

Hi all,=20

this is one of the topics we quickly flipped through in the virtual =
meeting last week.=20

I see the following open questions:
- Can the client require its instances to use request objects only.
- Are there further requirements on the properties of these objects? =
Signed only, Signed and encrypted, algorithms?=20
- Can an AS require ALL clients to use request objects only?=20
- Further requirements here as well?=20
- Is this tied to PAR or relevant for JAR as well?=20

In my opinion, client as well as AS should be able to control enforced =
use of request objects.=20

I could imagine the setting for JAR request objects (=E2=80=9Crequest" =
parameter) and request objects in the PAR context differ, as the first =
case goes through the user=E2=80=99s browser whereas the PAR case goes =
direct from client to AS via a TLS protected channel. I therefore feel =
the settings should be PAR specific.=20

What do you think?

best regards,
Torsten.=20=


From nobody Sun Apr 26 08:16:43 2020
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 97A563A0893 for ; Sun, 26 Apr 2020 08:16:41 -0700 (PDT)
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=lodderstedt.net
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 xrWNyTnoYJ68 for ; Sun, 26 Apr 2020 08:16:39 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 B563E3A08CF for ; Sun, 26 Apr 2020 08:16:38 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id g13so17456689wrb.8 for ; Sun, 26 Apr 2020 08:16:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4C8GwsnItT5srTUSIA1/+33E78DnMce7rWL4jy3Qeu8=; b=ggakthsxaNYW/ZBsMrzkaCkNpwspELmEu4ZX2M/rbdtPmvnsJblLvBmIJHGWcwTPGH QYFyVtjCJ6d1HYIaZdh+PLpIrX0wtdD0IOZPo+swzKu4IjLGAwd4ynPMcyJ4crx1poO7 pKurNWmN6hG2/iB2e4H/J3w6AA6R1OWYpRcylpVdHEgyx08daiAu+mukkBavhYPrGWqE qEJ6+CMWTpLVfKNmIuDZpjAWJDE8GSmP7tefW9DZYzQhSFQsquqW0gbf1a6jf3ZQK/Gf rNFmes8tUqBo0EbWV3Pkqw3yq1DRrxqHZB3I2baENoUDlALrB92sbhhSPPG2Pfu+gDaL a12A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4C8GwsnItT5srTUSIA1/+33E78DnMce7rWL4jy3Qeu8=; b=mq3i0nbzbRlu/mbLdbVEocMeWH7c7ggbR9D/XoVbv7DFICeZ/rNXTsVOiMaLGWga9A hy28+YbVuj1s6R1uzxV5JikF44wNqHRij0/9MmtI86DkPH27olP6nixWFlkcE4JCO759 MnRQ17OQ1g0tTXRXJ6nkWGgisBF9kXTtcniadMD0a0kp6Kgs5UA2s80wuWOst6hk7zNn fU3Bs1cX1//UW7iLjPKEhY5ztx6JmC+tcoDE5FXmgiayUGzQVI039ctJAsz4fVPYiiV8 Wq3C6XoTOc59rlw7fJrAEKpuTWY2IK2hNhnRKz+Djcumti0uhEc9gSdriJWk66cDnKSu RYhA==
X-Gm-Message-State: AGi0PubgoOVadBmW16sK5R0QKbF5LvnuesCvb3aL0wm9+12eXpO7O6i6 syrBKXS4Fxw+koqWgEU2fCGuPQ==
X-Google-Smtp-Source: APiQypJHHzoeRmorlSsTfYa1DhRjPmUgyLtGlcH+Bw8Isy3+hFUfvsGqKI5kani7VS7M9Nr3S4J3OQ==
X-Received: by 2002:a05:6000:10c4:: with SMTP id b4mr23005067wrx.203.1587914197104;  Sun, 26 Apr 2020 08:16:37 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id e13sm7739252wrp.15.2020.04.26.08.16.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 08:16:36 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt 
In-Reply-To: <158732102285.31467.551848692555230905@ietfa.amsl.com>
Date: Sun, 26 Apr 2020 17:16:35 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EADC158-FFB3-465E-84ED-B34254F30F79@lodderstedt.net>
References: <158732102285.31467.551848692555230905@ietfa.amsl.com>
To: Nat Sakimura , John Bradley 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.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: Sun, 26 Apr 2020 15:16:42 -0000

Hi Nat & John,

I tried to find out how signing & encryption algorithms are determined =
in the JAR context.=20

I just found this note in the history for -07: "Stopped talking about =
request_object_signing_alg=E2=80=9D

I assume you assume this is done via client registration parameters =
registered in =
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#c=
lient-metadata? Why doesn=E2=80=99t JAR state so?

What is about algorithms supported by the AS? The respective parameters, =
such as request_object_signing_alg_values_supported are not registered =
yet in =
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#a=
uthorization-server-metadata.

best regards,
Torsten.=20
=20

> On 19. Apr 2020, at 20:30, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        Title           : The OAuth 2.0 Authorization Framework: JWT =
Secured Authorization Request (JAR)
>        Authors         : Nat Sakimura
>                          John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-21.txt
> 	Pages           : 31
> 	Date            : 2020-04-19
>=20
> Abstract:
>   The authorization request in OAuth 2.0 described in RFC 6749 =
utilizes
>   query parameter serialization, which means that Authorization =
Request
>   parameters are encoded in the URI of the request and sent through
>   user agents such as web browsers.  While it is easy to implement, it
>   means that (a) the communication through the user agents are not
>   integrity protected and thus the parameters can be tainted, and (b)
>   the source of the communication is not authenticated.  Because of
>   these weaknesses, several attacks to the protocol have now been put
>   forward.
>=20
>   This document introduces the ability to send request parameters in a
>   JSON Web Token (JWT) instead, which allows the request to be signed
>   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>   (JWE) so that the integrity, source authentication and
>   confidentiality property of the Authorization Request is attained.
>   The request can be sent by value or by reference.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-21
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sun Apr 26 08:20:40 2020
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 15E0C3A08C7 for ; Sun, 26 Apr 2020 08:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 VyNJKL9dhRAc for ; Sun, 26 Apr 2020 08:20:37 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 C57A13A08C0 for ; Sun, 26 Apr 2020 08:20:36 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id f13so17434124wrm.13 for ; Sun, 26 Apr 2020 08:20:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=xfmzdYvpgRzji8jxDY7OflBfOQEPl1G/EsAqnOsJRmA=; b=2OhybUVlG/3MAxocSZ6x1hl4uKnEjMdaiSXqGXgJ6s3aiDHkHh+agkYBIeLxu4ruU6 Y6aBVl6X6t/Orb84OHIcZF884M7yF2Ziyqb6H2DcC/B9EEQus4g85IhvY3jydCc86gfA 6RHuKglmFRm8Qd2QMwfpVUHI3xmS7NHfOaqYAFw4/NOeU8LwHEFOfN16V4P90vgAQRa0 4J9KIAw2VHBS1suM14hzIWkqZPuM6n0tfk3lNspfy+4rrHsr+/+FrwSHKvoJvgOBf+F/ 5dgBkwTYw+KSi9+FL/9hpRWtrgIZVtJGV+VtXHNZkITEs2Ck9dMtJ8s+TY+yU0NEYBBb WBEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=xfmzdYvpgRzji8jxDY7OflBfOQEPl1G/EsAqnOsJRmA=; b=aQuGzbfL1nsnxS0+51LBM9zdWKsYK1VxM61MRt/rdUiuJgEjtaTP0Z7/LYwmx5VNIR 6S5Z1baHwacVY7yWJYU6Im0Mir2HBjtyfK9Pweku2OjwxaXPqcuVcGEPkruBPR5V9WSq w3ScVMXBJ2rDpv5LnaKo8reogWiWGnHAWbaii7WYst7McQqV3twD3bRpsGXIUxF37jfT k51L46EnkLeCWduetYcBNhri155Cc+zw7oRe3bWvt9QFzdMf03bpPRnkMP/onNXtcZgV Rjr4Q1Bx4PgkP9A7a68JzXx/gly0QLxI8bWa8w+ErQz+Jyna2lxjvwB4OFVN9OME6HhR NVyg==
X-Gm-Message-State: AGi0Pub4tQxEisTqi+2nAgMG0MCmKgbcIjUFLL4e/QfO4Y1uwo4q/9ZY kYAhnw70Ph8P+10tJqfer9Br6NuWwRQ=
X-Google-Smtp-Source: APiQypLTlgcuJtV1+ICV3T8q5qbbhP9lWKTPTwGCqbkRBv1E2hGOR3Y9xX2TA3NiYfAbaPTtiun3gQ==
X-Received: by 2002:adf:f5ce:: with SMTP id k14mr24335875wrp.39.1587914434849;  Sun, 26 Apr 2020 08:20:34 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id a24sm11438739wmb.24.2020.04.26.08.20.34 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 08:20:34 -0700 (PDT)
From: Torsten Lodderstedt 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Sun, 26 Apr 2020 17:20:33 +0200
To: oauth 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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: Sun, 26 Apr 2020 15:20:38 -0000

Hi all,=20

another topic from last week=E2=80=99s virtual meeting.=20

Shall there be guidance on the request URI structure?=20

Please state your opinion.=20

thanks in advance,=20
Torsten.=20=


From nobody Sun Apr 26 10:17:18 2020
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 0ADF23A0C00 for ; Sun, 26 Apr 2020 10:17:16 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 DihgFopVuZ7F for ; Sun, 26 Apr 2020 10:17:13 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650124.outbound.protection.outlook.com [40.107.65.124]) (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 3A3D63A0BFB for ; Sun, 26 Apr 2020 10:17:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bo2NlMLI1X+/X/Auqd3nepMucsgCssM/gZUEkh9Ov7gVr3cUfPe7q20o05XvbGATtoF2Q4EFhKgxUkvkz3KCJkFhLwVlXCSCPxga8xWDgunYVLztbPOwxPaUXxY7tyHIXj9eyW23o5mPuB8f4/2GMC7dm/EjOHJuMteLNyzkzsOUOCbPNnSHDPa8IwDAeBcudaVlQhn3bO6DbtKxLkTSNs5eerU7Fh6kZczevl7JJdAwRXUFQf9BKy0skJg+IQD353TK0Vkofr9mGHga3PYZR8Vrh0Jf2iW5pDB3urabtotQ228AKnimnxRpqVky8Qio9gnT7lZ9YIxUNOT//CSpHA==
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=EF41PutRydDcnSMeXRJiR3xvx7rMURP546Va968KXQQ=; b=ZojsJTpODz/GfjX18ZDxZ3n0SE+w/4TGv1k+wQ4DhYx452pNJ9hNujKOSHvxi6UTAZ0cYxGJTWy2y7rnMRsMrGoqphytTX3hl7S822yUqL7IAF+q3vt6hwhCEHemFMgpIVKMzNAz25bo0Qkz7NmdGxdNge9Xsy/Pkdo3Pszlzt48/S2FStO4pcA6/S9j7WjcMGK+mzpoJ8WKoZdZ/y6K05pwYYK82ud4iYDnzpif5AyqIpunWIQOZ2cp8TuB+1Ebttq+qKhpmL+mrtTGm1VVawFTllCr+3AFkRVWGr7yF+0ORw5GMgCcMbbhxqBBuiDajsx9qcRm/ZglYs2S1qLEbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EF41PutRydDcnSMeXRJiR3xvx7rMURP546Va968KXQQ=; b=fZCVNCWdWkRLM/Ws/VjujaWpqf260MDPaAzukdbvtkDsIB0UO8ox1dT61vCRLH5pMS4qxRGLZyQkXlR4E3CbLlkr9rnOfRB2agNhgQxtnsaYk6wafOCyYINB62hR0Se35q0abpsBlhLcZ3xD8WGpEzxljkuHmShB13f6s3p4D2s=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0780.namprd00.prod.outlook.com (2603:10b6:610:6f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2988.0; Sun, 26 Apr 2020 17:17:08 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5c07:f872:b7d:cc68]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::5c07:f872:b7d:cc68%8]) with mapi id 15.20.2988.000; Sun, 26 Apr 2020 17:17:08 +0000
From: Mike Jones 
To: Torsten Lodderstedt , Nat Sakimura , John Bradley 
CC: oauth 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt
Thread-Index: AdYb7ny/PQDH7dVXRBSZpdWvw5uEuw==
Date: Sun, 26 Apr 2020 17:17:08 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d0e155a8-109a-4e0b-8b31-0000a4d4d783; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-26T17:13:47Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fffd8e2d-b17d-4c3f-2d77-08d7ea05a681
x-ms-traffictypediagnostic: CH2PR00MB0780:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 03853D523D
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bkLuaRu4/1kgo0danU+6opwacfXmuMDBNXbJ0rnXBscs0YvHyerzzLe4USBMGtjLNExw9+X5c0JWrB3Ika+crbH9qjMzl2PFghHCyCwN3iuwqNAPhx28daBF0Cp11LXLcv1U1bsgoSJrbjWvT9Cx6S5gBe9hWjyjeWdBRhsRJsCyy4V7UN6t+C1JZDAAHpeVoUHJ4rC7eq862rs+YpW0qLnUOQtmAj1i+IHBO7uEduLuvMUxbJpB9b1dRoxjlZoHF6LJhCCMu704DFJeIsWBJb9GVHtGTukegNNQ2WWCNZY1jSL2ibQ1KbQ8RNbBqbEcUVeP6u/Z/LwG/2ufPQg47zy+qliRxzsk2pTakjAElOsIFFf3LTY5miskvnKjlWzHvyOB6ViYPAmiT78IpPOzq6zeDzzOXR5NM2xtui0t2Phh8vKEmW7swDSp8kx89D+683DriBkqd0n5ecqzvNrcY0J+gBSYDsOQoZ0rmPdhLYOLXa3B9gwxpAGJcLYsIxjV
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(366004)(39860400002)(346002)(136003)(396003)(2906002)(64756008)(52536014)(66946007)(66556008)(76116006)(66446008)(66476007)(4326008)(9686003)(55016002)(7696005)(71200400001)(8990500004)(966005)(5660300002)(478600001)(8676002)(6506007)(53546011)(26005)(33656002)(186003)(10290500003)(66574012)(8936002)(82950400001)(82960400001)(86362001)(316002)(110136005); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: icVUJazot8T2OF/tyNwZCnKZ6H5w67lZa5wSQ4KbhMormiYiYjH6fbZ6u2ucMqoHLJk76JoNO6g1BaUn9u4IYbMV/osL+KX9CrCK7hRyg4wnI/O4VDQOr7LYrSO6VBM4fkiU5CPhpZHHhNZrsE8gQEQ9GzJt4xTkd/EXbGs3NSOi7GN43cR/xkQF2HdFtw19RMdBLl30E+hcWhWXKxwxbM8ESo5aKYEYHTbS6zBXdRd8lX0t7Ergsqu8bPc6JHi3cacEBbgpitMkehCd9GtDDOFX7csDU1sn3nNv/zIx6iySDtUZmuSmyKpRIkfQaCh3ADtJf/DoI+ff/3NWG5yGpNC8gTknToGnsHPkb7MyN4/AyBd/OBMxQ+UwqTNItNyrp1JgEPZeJ9OyhjvPAAc8l0kkEtleZIDR1d7Nv7/4+2WxRUAik7qeFfhzR3/tvdpoZB1EZqo2dtlNcCUAyNPWiH+vAGkCdMbVIvwI5LwLUTgSTGGrCCRHFRb2oxCgVvFG1kFhrVDSChqLm7ff8zI/vjCHh3VwnkzFt6XBUYK7FhMNJ8hxnYUnmL3E1WvbDh2gvDU09dUbguVV8ZsnwkD6wS5NrnP4MnKFfGcyRtrqvN1KOSHqDSffVDqOxQdPt36+zs5gB1HFntdU3WtBE4DqbIs4HvibsoxKJ9RTpeWt+9mlZ7LGdRAcsLwKB+vWcItlBlaSwlyb+JdmxRmudu0//mun32SaZNEsdZb2mpcwXbxArwLnKEjnmgUZ8Rjn6ZUFuWzZ10K+Eo4HWRHqK5NnUWj2TzbZ1ugGHE7O6tK2ptw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fffd8e2d-b17d-4c3f-2d77-08d7ea05a681
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2020 17:17:08.4110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EJ5ZWxlTSj1HIrweeQQICJZrY+3ieqJGLTRch5+FHPOkwi1ds54G90dKiBY6p6VdmVGhPCrMr7RyzELCtJhBcw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0780
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.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: Sun, 26 Apr 2020 17:17:16 -0000

VGhlIG5leHQgZXJyYXRhIHZlcnNpb24gb2YgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5IHdpbGwg
cmVnaXN0ZXIgdGhlIHBhcmFtZXRlciByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ192YWx1ZXNf
c3VwcG9ydGVkIGFuZCBvdGhlciBwYXJhbWV0ZXJzIG5vdCBwcmV2aW91c2x5IHJlZ2lzdGVyZWQu
ICBTZWUgaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0x
XzAtMjkuaHRtbCBmb3IgdGhlIGxhdGVzdCBwdWJsaXNoZWQgZXJyYXRhIGRyYWZ0Lg0KDQpJIGNh
biBtYWtlIGEgcmVxdWVzdCBmb3IgZWFybHkgcmVnaXN0cmF0aW9uIGlmIGl0IHdvdWxkIGJlIHVz
ZWZ1bC4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVG9yc3RlbiBMb2Rk
ZXJzdGVkdA0KU2VudDogU3VuZGF5LCBBcHJpbCAyNiwgMjAyMCA4OjE3IEFNDQpUbzogTmF0IFNh
a2ltdXJhIDxuYXRAc2FraW11cmEub3JnPjsgSm9obiBCcmFkbGV5IDxqYnJhZGxleUB5dWJpY28u
Y29tPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd
IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxLnR4dA0KDQpIaSBOYXQgJiBK
b2huLA0KDQpJIHRyaWVkIHRvIGZpbmQgb3V0IGhvdyBzaWduaW5nICYgZW5jcnlwdGlvbiBhbGdv
cml0aG1zIGFyZSBkZXRlcm1pbmVkIGluIHRoZSBKQVIgY29udGV4dC4gDQoNCkkganVzdCBmb3Vu
ZCB0aGlzIG5vdGUgaW4gdGhlIGhpc3RvcnkgZm9yIC0wNzogIlN0b3BwZWQgdGFsa2luZyBhYm91
dCByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ+KAnQ0KDQpJIGFzc3VtZSB5b3UgYXNzdW1lIHRo
aXMgaXMgZG9uZSB2aWEgY2xpZW50IHJlZ2lzdHJhdGlvbiBwYXJhbWV0ZXJzIHJlZ2lzdGVyZWQg
aW4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0
aC1wYXJhbWV0ZXJzLnhodG1sI2NsaWVudC1tZXRhZGF0YT8gV2h5IGRvZXNu4oCZdCBKQVIgc3Rh
dGUgc28/DQoNCldoYXQgaXMgYWJvdXQgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgYnkgdGhlIEFTPyBU
aGUgcmVzcGVjdGl2ZSBwYXJhbWV0ZXJzLCBzdWNoIGFzIHJlcXVlc3Rfb2JqZWN0X3NpZ25pbmdf
YWxnX3ZhbHVlc19zdXBwb3J0ZWQgYXJlIG5vdCByZWdpc3RlcmVkIHlldCBpbiBodHRwczovL3d3
dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMu
eGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGEuDQoNCmJlc3QgcmVnYXJkcywNClRv
cnN0ZW4uIA0KIA0KDQo+IE9uIDE5LiBBcHIgMjAyMCwgYXQgMjA6MzAsIGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyB3cm90ZToNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp
bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRo
aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29s
IFdHIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFRoZSBPQXV0
aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcms6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24g
UmVxdWVzdCAoSkFSKQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTmF0IFNha2ltdXJhDQo+
ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIEJyYWRsZXkNCj4gCUZpbGVuYW1lICAgICAg
ICA6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDog
MzENCj4gCURhdGUgICAgICAgICAgICA6IDIwMjAtMDQtMTkNCj4gDQo+IEFic3RyYWN0Og0KPiAg
IFRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW4gT0F1dGggMi4wIGRlc2NyaWJlZCBpbiBSRkMg
Njc0OSB1dGlsaXplcw0KPiAgIHF1ZXJ5IHBhcmFtZXRlciBzZXJpYWxpemF0aW9uLCB3aGljaCBt
ZWFucyB0aGF0IEF1dGhvcml6YXRpb24gUmVxdWVzdA0KPiAgIHBhcmFtZXRlcnMgYXJlIGVuY29k
ZWQgaW4gdGhlIFVSSSBvZiB0aGUgcmVxdWVzdCBhbmQgc2VudCB0aHJvdWdoDQo+ICAgdXNlciBh
Z2VudHMgc3VjaCBhcyB3ZWIgYnJvd3NlcnMuICBXaGlsZSBpdCBpcyBlYXN5IHRvIGltcGxlbWVu
dCwgaXQNCj4gICBtZWFucyB0aGF0IChhKSB0aGUgY29tbXVuaWNhdGlvbiB0aHJvdWdoIHRoZSB1
c2VyIGFnZW50cyBhcmUgbm90DQo+ICAgaW50ZWdyaXR5IHByb3RlY3RlZCBhbmQgdGh1cyB0aGUg
cGFyYW1ldGVycyBjYW4gYmUgdGFpbnRlZCwgYW5kIChiKQ0KPiAgIHRoZSBzb3VyY2Ugb2YgdGhl
IGNvbW11bmljYXRpb24gaXMgbm90IGF1dGhlbnRpY2F0ZWQuICBCZWNhdXNlIG9mDQo+ICAgdGhl
c2Ugd2Vha25lc3Nlcywgc2V2ZXJhbCBhdHRhY2tzIHRvIHRoZSBwcm90b2NvbCBoYXZlIG5vdyBi
ZWVuIHB1dA0KPiAgIGZvcndhcmQuDQo+IA0KPiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0
aGUgYWJpbGl0eSB0byBzZW5kIHJlcXVlc3QgcGFyYW1ldGVycyBpbiBhDQo+ICAgSlNPTiBXZWIg
VG9rZW4gKEpXVCkgaW5zdGVhZCwgd2hpY2ggYWxsb3dzIHRoZSByZXF1ZXN0IHRvIGJlIHNpZ25l
ZA0KPiAgIHdpdGggSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIGFuZCBlbmNyeXB0ZWQgd2l0aCBK
U09OIFdlYiBFbmNyeXB0aW9uDQo+ICAgKEpXRSkgc28gdGhhdCB0aGUgaW50ZWdyaXR5LCBzb3Vy
Y2UgYXV0aGVudGljYXRpb24gYW5kDQo+ICAgY29uZmlkZW50aWFsaXR5IHByb3BlcnR5IG9mIHRo
ZSBBdXRob3JpemF0aW9uIFJlcXVlc3QgaXMgYXR0YWluZWQuDQo+ICAgVGhlIHJlcXVlc3QgY2Fu
IGJlIHNlbnQgYnkgdmFsdWUgb3IgYnkgcmVmZXJlbmNlLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRh
dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS8NCj4gDQo+IFRoZXJl
IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxDQo+IGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjENCj4g
DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgtandzcmVx
LTIxDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+
IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5n
IGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K


From nobody Sun Apr 26 14:25:33 2020
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 7E69B3A12A8 for ; Sun, 26 Apr 2020 14:25:29 -0700 (PDT)
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 bmX7NnYvm598 for ; Sun, 26 Apr 2020 14:25:28 -0700 (PDT)
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 B285E3A12A7 for ; Sun, 26 Apr 2020 14:25:27 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id y26so6878575ioj.2 for ; Sun, 26 Apr 2020 14:25:27 -0700 (PDT)
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=8eNuswXNjLAoX7uJpeBewIyauQiMSWYFzuWnXI4gKnM=; b=YeAYaS9ryteCx3NSMCwyTbbFG7BjmBvTuA73i0hPxUXQ5L2ZqApymiIe4NTfK9WsZQ BKJhfkRYQRYbR6/YbbKxStVE4Q6YdECBV50vhI7H3CV5GYQcaRmFzyzovq3fKhLoNSvP ao4TVBwPBZtlcH9calbhdigyTGgcc670UQfcrRrts1bqEn9QH1GFeEI4iNwSkBGBm/Hi WqSgX5KB055lp8tCWGv1047qbioafqWWss/YxGyl+SrktKEKiKWHilYdJYiwFIUZNLYi pdh6ybBK3OIgSIsVS9PQeCdS5081z29ytPtZXxwCsT6qTEbwf+2MmJy/d71iTPcvpNpx LcFw==
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=8eNuswXNjLAoX7uJpeBewIyauQiMSWYFzuWnXI4gKnM=; b=TBcS7ZcyQGEtnYbsh6mr1lNbUTe3Xo81Ozw+CDaKNzgJvZIrRXiVKC2ud4LExFVubu yRVXTkQiSyyNzTHa6ayiO3575/jcAwpp/6kCLuW0ULUM6/JHfJhVCcHYKysNEVOrY/4o Fsh4GdEKUFe4KMwPFNsc8I/5tYVD5YadAMgjvx+gdRt73M6BI3Rulkwd5wFWtyEGZy+p GIUP7I9KsWlc7MCMruRCjwKcjzeW5ywSbRv97Zhw9EVkFY4rzB9oJTAFTnMIhFqx8yxZ Ak1Cb8gdcblSsW2T068rh2jQE1nHu5/a2IzNZkm1sOOkbiX/1lvx+D+GagCbRNdQwgnE obXQ==
X-Gm-Message-State: AGi0PuYu0x+XkqMUQN4U5POUNhHlknJnUdU5A1PrRXUlVxKjSNw0yFHn /9YQKKcZSScdquhBSUKZZWmE+dC4nfwbid0ladtufGuU6I4=
X-Google-Smtp-Source: APiQypLrlIR3oa4nPfIn89pjPGWza5rLOAj/5Db7XDW0bYMoAB8/9MZCy/r+rkB8yLjynH38ggyHWsZEdDfkqqLEkMw=
X-Received: by 2002:a6b:8dc2:: with SMTP id p185mr18513109iod.138.1587936326619;  Sun, 26 Apr 2020 14:25:26 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Sun, 26 Apr 2020 17:25:16 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000ac979305a4383c59"
Archived-At: 
Subject: [OAUTH-WG] April 27th Interim Meeting Material
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: Sun, 26 Apr 2020 21:25:31 -0000

--000000000000ac979305a4383c59
Content-Type: text/plain; charset="UTF-8"

The following link has the meeting material for the April 27th interim
meeting:
https://datatracker.ietf.org/meeting/interim-2020-oauth-06/session/oauth

Will upload the OAuth 2.1 slides when I get them.

Regards,
 Rifaat

--000000000000ac979305a4383c59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The following=C2=A0link has the meeting=C2=A0material for =
the April 27th interim meeting:

<=
div>Will upload the OAuth 2.1 slides when I get them.

<=
div>Regards,
=C2=A0Rifaat
=C2=A0


--000000000000ac979305a4383c59--


From nobody Sun Apr 26 14:31:18 2020
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 81AB83A12BD for ; Sun, 26 Apr 2020 14:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 395dwH4pZn0S for ; Sun, 26 Apr 2020 14:31:15 -0700 (PDT)
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 6B1A83A12BC for ; Sun, 26 Apr 2020 14:31:15 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03QLVA9N013379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Apr 2020 17:31:13 -0400
Date: Sun, 26 Apr 2020 14:31:10 -0700
From: Benjamin Kaduk 
To: Jared Jennings 
Cc: oauth 
Message-ID: <20200426213110.GQ27494@kduck.mit.edu>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] Structured management of working documents
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: Sun, 26 Apr 2020 21:31:18 -0000

Hi Jared,

On Thu, Apr 23, 2020 at 09:55:21PM -0500, Jared Jennings wrote:
> Hi all,
> 
> I know I am super new to the list, so bare with me with my
> observations that I would like share with the group. Probably no one in the
> list knows me, but I am used to online forms, mailing lists and I been
> involved in various open source applications for many years. So, these
> comments do not come from someone that isn't used to mailing lists.

Thanks for being bold and sharing your insight!  It is not often that we
have the benefit of such a fresh perspective.

> With that said, I find it difficult to follow the different
> threads, revisions, suggestions, comments, and topics that we discuss. It
> also seems that the current format makes it very difficult for the
> maintainer of the document.
> 
> As a suggestions or question, is there a reason we are not using a platform
> designed for this type of work? Like Github, bitbucket, etc. A great

The main reason that we continue to involve the IETF mailing list is due to
a longstanding historical IETF requirement for having WG work gain
consensus on the mailing list and be submitted to the IETF datatracker.
The original reasons for this policy (which long predates me, to be clear)
seem twofold: to be as accessible as possible to all (email does not
require significant bandwidth, real-time access, or installing/using
proprietary software), and to ensure compliance with the IETF IPR regimen.
With respect to the latter point, the IETF mailing lists and
datatracker-managed documents are subject to the "Note Well" policies of
BCPs 78 and 79, and the procedures for making other tools subject to the
same requirements are less well-established.

> example is the link that Brian shared. I can see exactly what is going on
> and I could even propose my own patch, which saves the editor loads of work.
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/3/attempt-to-tweak-the-wording-in-jar-so/diff

The above notwithstanding, the IETF has recently approved a pair of
documents that describe procedures for how a WG can choose to use github in
the course of their work.  (They are not RFCs yet, but are with the RFC
Editor in preparation as RFCs; they're linked from
https://datatracker.ietf.org/wg/git/documents/ .)  These procedures focus
on github because it's popular, but aren't intended to limit WGs to just
github as an available external tool; the procedures in question could no
doubt be modified to apply to other tools as well, if there is WG consensus
to do so.

Hope this helps,

Ben


From nobody Mon Apr 27 01:34:23 2020
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 BD26C3A126E for ; Mon, 27 Apr 2020 01:34:20 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeQDpE912Bgq for ; Mon, 27 Apr 2020 01:34:18 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 4F3163A1290 for ; Mon, 27 Apr 2020 01:34:06 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id s10so6758304plr.1 for ; Mon, 27 Apr 2020 01:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=He6KEWWk2AJQYpWVf4ZHOpom4QKTCArUDluFpcNfE/I=; b=cJxwy2Usc0PXV1MNtQrAB7pugnGNkBTYgn71ywIZT3Ll4iwVXQ7i4APVOew55JHi+f ZIlss8qTKxjkOewFrMrRiEE3RVguc4KnmYED2MZF1CkHpymixbxNGZ1A/bJu6tHBg3RO lhqLO6gRD77Bq9m126uXJDbnBcj5b9SV8UuMyXm6b+hcJFC1dXqO1FZurG/MwETQhtOh jrylu+LwYWbg7OwXT5Co6j3+lPxkAhTTbVJpZVRvkXydAvGGUngAfgueT7oFiEbHDVoJ ZYUBIOAfYjKlOX+Igs0mBLakhINRNFsDgs2cIpi2vhBC0fmijYLwoGjv3nvTFhy7bx8m eyug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=He6KEWWk2AJQYpWVf4ZHOpom4QKTCArUDluFpcNfE/I=; b=MyGxUd4V29ugobOv/nQhd1RxM9YktkT7LXCKRghglzEZ1Gb3aNgoQmEJTcUTWevlAb cKa7lLUT9NQ6RRhOyFLq8u+VAJS4ZxvW1CLyc46016TeyPgQ0IooUYFnulR5sAs3ECbA xxFrPOehtrj2m/AlyaaRaunTfJmCG8Lh9xu4vYge7LftEvehjw1f1+Gl8nQD4g76CXDL MIVaXLt10Q4ZGrWmwC51rsd2YTSPNSuNP7xDgYyVXBXCPrFxARDmmIp6zglLv1mjNFqy oIxLM++/18LigmEtsIo/VPoWIGcRKGpbtkR2WLbegi/7bXSrA1eKTubQfyndNuiuAOCq jh+A==
X-Gm-Message-State: AGi0PubKlnJTkse3PcTksZeKesER7JX6DB5vWmsQ/uuLrnTHRGH4y2gP VZ3A5XdF41XmrKMpnPC2BZ5n4A==
X-Google-Smtp-Source: APiQypJJL46I8GKXF8Ad/19FqekqMvtF2YD4CK5xdSCPcXPcVhVQOXhzUUXduVtintTBX3Eao2e1DA==
X-Received: by 2002:a17:902:403:: with SMTP id 3mr22087480ple.102.1587976445273;  Mon, 27 Apr 2020 01:34:05 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id b16sm6798092pft.191.2020.04.27.01.34.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 01:34:04 -0700 (PDT)
From: Vittorio Bertocci 
To: Benjamin Kaduk , Vittorio Bertocci 
CC: Mike Jones , oauth , Vittorio Bertocci 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: ATA3REUwwLM5q/LpIqzgbOsmuIv70TA1OEMxNDI3MjTIpxkuRA==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 27 Apr 2020 08:34:03 +0000
Message-ID: 
References:   <20200425020227.GE27494@kduck.mit.edu>
In-Reply-To: <20200425020227.GE27494@kduck.mit.edu>
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] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 27 Apr 2020 08:34:21 -0000

VGhhbmsgeW91IGZvciBicmluZ2luZyB0aGlzIHVwIEJlbmphbWluLCB5b3Ugc2F2ZWQgbWUgZnJv
bSBhIGxvbmcgd2lsZCBnb29zZSBjaGFzZSENCkl0JyBnb29kIHRvIGtub3cgdGhhdCB0aGVyZSdz
IGEgbmV3IHJmYyBmb3JtYXQgdmVyc2lvbiwgYnV0IEkgYW0gYSBiaXQgd29ycmllZCBhYm91dCB2
ZW50dXJpbmcgdGhlcmUgZ2l2ZW4gdGhhdCBJIGFtIGJhcmVseSBtYW5hZ2luZyB0aGUgdjIgYXMg
aXQgaXMgX18gdjMgc3RpbGwgZmVlbHMgcHJldHR5IGV4cGVyaW1lbnRhbCwgYW5kIG90aGVyIHRo
YW4gdGhpcyBpc3N1ZSwgdGhpcyBzcGVjIGRvZXNuJ3QgZ2l2ZSBhIGxvdCBvZiBvcHBvcnR1bml0
aWVzIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBuZXcgZmVhdHVyZXMgKFNWRyBldGMpLiAgDQpX
b25kZXJpbmcgd2hldGhlciBJIGNhbiBmaW5kIGEgcGVyaXBocmFzZSB0byBleHByZXNzIHRoZSBz
YW1lIG5vdGlvbiB3aXRob3V0IHRyaWdnZXJpbmcgdGhlIHNjcmlwdCwgZS5nLiBvbWl0dGluZyB0
aGUgd29yZCBzZWN0aW9uIG9yIGNoYW5naW5nIHRoZSBvcmRlci4NClRoeA0KVi4NCg0K77u/T24g
NC8yNC8yMCwgMTk6MDIsICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+IHdyb3RlOg0K
DQogICAgSnVzdCBvbiB0aGUgeG1sMnJmYyBiaXRzLi4uDQogICAgDQogICAgT24gV2VkLCBBcHIg
MjIsIDIwMjAgYXQgMDc6MjY6NDBBTSArMDAwMCwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6DQog
ICAgPiANCiAgICA+ID4gTGluayB0byBzZWN0aW9uIDQuMS4yIG9mIFNDSU0gQ29yZSBpcyBhY3R1
YWxseSBsaW5raW5nIHRvIHNlY3Rpb24gNC4xLjIgb2YgdGhpcyBkb2MuDQogICAgPiBPaCB3b3cu
IFRoYXTigJlzIGEgZmVhdHVyZSBvZiBYTUwyUkZDLOKApiBteSBzb3VyY2Ugc2ltcGx5IHNheXMg
Ynkgc2VjdGlvbiA0LjEuMiBvZiBTQ0lNIENvcmUgIGluIGEgPHQ+IGJsb2NrLCBhbmQgdGhlIHBy
b2Nlc3NvciBpbnRlcnByZXQgaXQgYXMgYW4gaW50ZXJuYWwgbGluay4gSeKAmWxsIG5lZWQgdG8g
ZGlnIG9uIGhvdyB0byBwcmV2ZW50IHRoYXQgZnJvbSBoYXBwZW5pbmcgZm9yIHRoaXMgaW5zdGFu
Y2UuIEdvb2QgY2F0Y2ghDQogICAgDQogICAgVGhlIHNob3J0IGZvcm0gaXMgInlvdSBjYW4ndCIu
DQogICAgDQogICAgWW91J3JlIHVzaW5nIHRoZSAidjIiIFhNTCBmb3JtYXQgZm9yIHhtbDJyZmMs
IHdoaWNoIHByb2R1Y2VzIGFzIHZhcmlvdXMNCiAgICBvdXRwdXQgZm9ybWF0cyB0ZXh0LCBwZGYs
IGFuZCAiaHRtbGl6ZWQiIG91dHB1dC4gIFRoZSAiaHRtbGl6ZWQiIG91dHB1dCBpcw0KICAgIGNh
bGxlZCB0aGF0IGFuZCBub3QgImh0bWwiIGJlY2F1c2UgaXQncyB0aGUgcmVzdWx0IG9mIHRha2lu
ZyB0aGUgdGV4dA0KICAgIG91dHB1dCBhbmQgcnVubmluZyBhIHNjcmlwdCB0byB0dXJuIGNvbW1v
biBjb25zdHJ1Y3Rpb25zIGluIEktRHMgYW5kIFJGQ3MNCiAgICBpbnRvIGhvcGVmdWxseS11c2Vm
dWwgSFRNTCBmb3JtYXR0aW5nLiAgSW4gdGhpcyBjYXNlLCAiU2VjdGlvbiBOIiBvdXRzaWRlDQog
ICAgb2YgIlNlY3Rpb24gTiBvZiBbYnJhY2tldGVkLXJlZmVyZW5jZV0iIGlzIGFzc3VtZWQgdG8g
YmUgIlNlY3Rpb24gTiBvZiB0aGUNCiAgICBjdXJyZW50IGRvY3VtZW50IiwgYW5kIHRoYXQncyBh
bGwgdGhhdCB0aGUgaHRtbGl6YXRpb24gc2NyaXB0IGlzIGdvaW5nIHRvDQogICAgZ2l2ZSB5b3Us
IHNpbmNlIGl0J3Mgbm90IHdvcmtpbmcgd2l0aCB0aGUgc2VtYW50aWMgcmljaG5lc3Mgb2YgdGhl
IFhNTA0KICAgIHNvdXJjZS4NCiAgICANCiAgICBXZSBkbywgaG93ZXZlciwgYXMgb2YgZmFpcmx5
IHJlY2VudGx5IGhhdmUgYSAidjMiIFhNTCBmb3JtYXQsIHdoaWNoIGlzDQogICAgY2FwYWJsZSBv
ZiBwcm9kdWNpbmcgbmF0aXZlIEhUTUwgb3V0cHV0IHRoYXQgaW5jbHVkZXMgU1ZHIGZpZ3VyZXMg
YW5kIHRoZQ0KICAgIG90aGVyIGV4Y2l0aW5nIGZlYXR1cmVzIG9mICJ2MyBYTUwiLiAgRm9yIGFu
IGV4YW1wbGUsIHNlZQ0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtdHN2
d2ctZGF0YWdyYW0tcGxwbXR1ZC0xOS5odG1sIC4NCiAgICANCiAgICBJIHBlcnNvbmFsbHkgaGF2
ZW4ndCBkb25lIGFueSB2Mi10by12MyBjb252ZXJzaW9ucyB5ZXQgKHRvbyBidXN5IHJlYWRpbmcg
dG8NCiAgICBoYXZlIHRpbWUgdG8gZG8gbXVjaCB3cml0aW5nKSwgYnV0IHRoZSBGQVEgZW50cnkg
Zm9yIGRvaW5nIHNvIGlzIGF0DQogICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJp
YWxzL0ZBUS14bWwycmZjdjMuaHRtbCNuYW1lLWhvdy1kby1pLWNvbnZlcnQtbXkteG1sLWZpbA0K
ICAgIC4NCiAgICANCiAgICBIb3BlIHRoYXQgaGVscHMsDQogICAgDQogICAgQmVuDQogICAgDQo=


From nobody Mon Apr 27 01:35:22 2020
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 BECB43A1267 for ; Mon, 27 Apr 2020 01:35:21 -0700 (PDT)
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=unavailable 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 J-jof-mi8wHF for ; Mon, 27 Apr 2020 01:35:17 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 17C383A10B5 for ; Mon, 27 Apr 2020 01:35:17 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id l5so9055123ybf.5 for ; Mon, 27 Apr 2020 01:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LY4bLh/QT4GRjkyxazTp2XsI3V+1fiSyKwlh2qie+v8=; b=E1UKa4zTdplceqD8IyUcoWlqgXQnsWVq7UdJK4EEkf1qUcOuGQQ8XIjWgG4BywMlih 11ecv8hPekLn+vi5oZuQ6AEmxq9FA6oKsUecB65szzBWf4I02AzXRi8bMgg6IOnHY9T+ /h0sE5UpGxb9ubtiB1HAsy7GUlMs5ggkIhOziIbK7M9VCkoH2DxJkclaQpg2dgzBphU8 fFfsNLWAMyrY4IXI51//xt1UPGDHLzcfS1QAW0rOkNcN4HBvmvo66Gwnice+7m151PWy BwleXaMp7O14hXY2B7z9C01Z4Zm8vCK/63e6TzlSeH6AfJXjkD9nqG3gNnPRwjR0eytr U3WQ==
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=LY4bLh/QT4GRjkyxazTp2XsI3V+1fiSyKwlh2qie+v8=; b=YWE/vj7G94jQ0AZdUcbYUa62GvN+hA+Kms+BPC5/jb+u3r+H/QDO70It1Ym4jjCm3s 7eIMsOOan6F8RwMStphUgBmydM9m2P+b1xzXhCiRJ5NebBmbIAvrajTO9dEbRMRuSHuj zG9EL91AY52Jv0wDTqDPq1RnBiH/Txi0XzZChgl3BqQ/izP5ZM/RP+QgrKB8tNNXnS7w O7Z/LlGSmTGuzk7peptwlBhEC3rG4VVYNEuvAXst5DoEFNVOjOi/SzNSuOFC6URa3LCl 26jWUnT5CBlqOtT+PTG8aB8SIfkJpbOCETmPv+QleCY7Dh4L7o4q+9I3wkWJjzlpKL+0 TWgQ==
X-Gm-Message-State: AGi0Pubo1qYUGaX5Es/ElosmZHLtoKWFxah+DCRCXNl7cafu1KtWCC+B VcA6o+it9jVX0boIkYIll5ZlhcEQhQl00x8JzOZlOBU=
X-Google-Smtp-Source: APiQypJJ6vMtdezQX7o7J88S4y85FePkN6lxqc4LL11AOjJ0NFJCKxEmz2xl/BO/mFb8iukM38mdAk4N4dBcBhsWwbs=
X-Received: by 2002:a25:e907:: with SMTP id n7mr33168392ybd.85.1587976516037;  Mon, 27 Apr 2020 01:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
In-Reply-To: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
From: Filip Skokan 
Date: Mon, 27 Apr 2020 10:34:37 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000002670eb05a4419816"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
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, 27 Apr 2020 08:35:22 -0000

--0000000000002670eb05a4419816
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Considering there's going to be a setting that forces clients to use PAR
(other mailinglist thread), then we should rely on the existing
`request_object_signing_alg` presence to indicate a Request Object must be
used (as suggested by this upcoming OIDC Core errata
),
regardless of it being PAR or JAR. I don't see the need for a PAR specific
metadata, for one - implementations wouldn't be easily able to re-use of
existing pipelines, two - yes the contexts differ but do you think clients
will be using both channels at the same time? And even if so, the Request
Object is the same therefore its applicable to both channels the same.

Best,
*Filip Skokan*


On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  wrote:

> Hi all,
>
> this is one of the topics we quickly flipped through in the virtual
> meeting last week.
>
> I see the following open questions:
> - Can the client require its instances to use request objects only.
> - Are there further requirements on the properties of these objects?
> Signed only, Signed and encrypted, algorithms?
> - Can an AS require ALL clients to use request objects only?
> - Further requirements here as well?
> - Is this tied to PAR or relevant for JAR as well?
>
> In my opinion, client as well as AS should be able to control enforced us=
e
> of request objects.
>
> I could imagine the setting for JAR request objects (=E2=80=9Crequest" pa=
rameter)
> and request objects in the PAR context differ, as the first case goes
> through the user=E2=80=99s browser whereas the PAR case goes direct from =
client to
> AS via a TLS protected channel. I therefore feel the settings should be P=
AR
> specific.
>
> What do you think?
>
> best regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000002670eb05a4419816
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Considering there's going to be a setting that fo=
rces clients to use PAR (other mailinglist thread), then we should rely on =
the existing `request_object_signing_alg` presence to indicate a Request Ob=
ject must be used (as suggested by this upcoming OIDC Core errata), regardless of it being PAR or JAR. I don't see the=
 need for a PAR specific metadata, for one - implementations wouldn't b=
e easily able to re-use of existing pipelines, two - yes the contexts diffe=
r but do you think clients will be using both channels at the=C2=A0same tim=
e? And even if so, the Request Object is the same therefore its applicable =
to both channels the same.

Best,
Filip=
 Skokan


On Sun, 26 Apr 2020 at 17:09, Torsten Loddersted=
t <torsten=3D40lodde=
rstedt.net@dmarc.ietf.org> wrote:
Hi all, 



this is one of the topics we quickly flipped through in the virtual meeting=
 last week. 



I see the following open questions:

- Can the client require its instances to use request objects only.

- Are there further requirements on the properties of these objects? Signed=
 only, Signed and encrypted, algorithms? 

- Can an AS require ALL clients to use request objects only? 

- Further requirements here as well? 

- Is this tied to PAR or relevant for JAR as well? 



In my opinion, client as well as AS should be able to control enforced use =
of request objects. 



I could imagine the setting for JAR request objects (=E2=80=9Crequest"=
 parameter) and request objects in the PAR context differ, as the first cas=
e goes through the user=E2=80=99s browser whereas the PAR case goes direct =
from client to AS via a TLS protected channel. I therefore feel the setting=
s should be PAR specific. 



What do you think?



best regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000002670eb05a4419816--


From nobody Mon Apr 27 01:42:24 2020
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 9F09C3A126C for ; Mon, 27 Apr 2020 01:42:22 -0700 (PDT)
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 pIEh7jrpxITF for ; Mon, 27 Apr 2020 01:42:21 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 387E73A1060 for ; Mon, 27 Apr 2020 01:42:21 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id o198so9042192ybg.10 for ; Mon, 27 Apr 2020 01:42:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+7y+yWXJTIn/BcrFjSd78aXcXPFRhP/QalHO+Ybu05g=; b=fByJVRZ5Mt1QDOIt1E8gZfbE12NTkwM5CrpBX/7wi1yAY6kQxKKOcFIiGGI/3r1s5E JJ1Zo7TYifqbdovptsmZf0XLxWfUOcrSEzqaAZo+WdnJb0/jZacMXA2vr1OR8UafEJ4C Rup7M4VYzhVWgbDJkCwUZunNHB8MWMhsSwsvOGqWogaRHD36GsKT9sovHUIxcYc9kqQU LFRazl0ULGyQRWMZrToI7D6cfAzVImXOaGpaGuJNwYbUtGjfK73JOdZnoUWlKSYSOIKa ntxZrCBGmJiqpQjpCRnK/JkDOVIDs5NqASlLx26Hc0iQLOj2rjubgkpbGEtnBQ25Jtys XyUA==
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=+7y+yWXJTIn/BcrFjSd78aXcXPFRhP/QalHO+Ybu05g=; b=gerHgo1Hidt6EOBQODlCf66OO9FTQUUCAt1Ff8OzeIF6Q6RRwWJRXWnb/zuZrYdZi2 26oV1rVjwoh/MBNmJMvSdBecxSlxwo4c4V3znBMd94K3BezYEHoeSu86zdFTQF4FNZYM JKFl07g2LcB2t/H1ESraikeNRJXg8hLAv9k1HffT0Wwzs7sKTDQjZo/xydANfwnTSyHj c1StDWxF/+hOrBecC7/wMm2yLM7Aw8/rS81b5frnDbPTV1H7Z/Kq9rLlfZJ3G82WSERa LciMcgyr0rDqGECCsJbSHErSfHpF5oYI4YjwlYsJQJK8H6nBU/BTcVrA9tak3xeBXZGM gMgw==
X-Gm-Message-State: AGi0PuZmjuF6lBXmBNlT6b4FOi2Q/7UP2AhI67tNANq8hBjMZPZDJvyY Km3Nt1TM/zKy69uDWzPxglejbJp9SlYfPkZ/uw==
X-Google-Smtp-Source: APiQypLR0T99oGlCyJkLMdpRG+fWO3dmldyXLohArB30Q1GP/CINtoDi6jbsJp3sfKLuS1IazOTNeK3ItZHW0JhcnV8=
X-Received: by 2002:a25:13c1:: with SMTP id 184mr32161821ybt.259.1587976940428;  Mon, 27 Apr 2020 01:42:20 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Filip Skokan 
Date: Mon, 27 Apr 2020 10:41:42 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000007222c705a441b183"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 27 Apr 2020 08:42:23 -0000

--0000000000007222c705a441b183
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I believe implementers should be free to devise their own URIs and not be
locked down to one by the spec, at the same time,
and RFC6755 subnamespace would be good for guidance.

So, I would suggest it be RECOMMENDED to use e.g.
`urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
that any URN or URL will do if the circumstances call for it.

Best,
*Filip*


On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  wrote:

> Hi all,
>
> another topic from last week=E2=80=99s virtual meeting.
>
> Shall there be guidance on the request URI structure?
>
> Please state your opinion.
>
> thanks in advance,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000007222c705a441b183
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I believe implementers should be free to devise their=
 own URIs and not be locked down to one by the spec, at the same time, and=
=C2=A0RFC6755=C2=A0subnamespace=C2=A0would be good for guidance.
=

So, I would suggest it be RECOMMENDED to use e.g. `urn:ietf:=
params:oauth:request_uri:<random>` (Brian's proposal) but also th=
at any URN or URL will do if the circumstances call for it.

Best,=

Filip


=

On Sun, 26 Apr 2020 at 17:20, Torsten=
 Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all, 



another topic from last week=E2=80=99s virtual meeting. 



Shall there be guidance on the request URI structure? 



Please state your opinion. 



thanks in advance, 

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--0000000000007222c705a441b183--


From nobody Mon Apr 27 06:26:04 2020
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 18F083A0A63 for ; Mon, 27 Apr 2020 06:26:02 -0700 (PDT)
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=pingidentity.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 Q2h2daLKOHyv for ; Mon, 27 Apr 2020 06:25:59 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 861D83A0A5D for ; Mon, 27 Apr 2020 06:25:59 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id m2so13788120lfo.6 for ; Mon, 27 Apr 2020 06:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ry2edcbY+rdF5TdfxGa/Ymc+ewm3wDWAzFMbhdJNPbI=; b=BRVVPoBz6e1k044hodQ4fy3tRJbUR4VkKoVXnfspR+mrnJkGGmVQK4GQVz/5vC0fLz S6XRjpc20G9IaDsvfZVfAUuECid8TNeBGytnwVNZhPoQ/flp6DtLjXwybdlM5B7pz3Lu YX8+PfVZANcvp5iHSDDUlue50L1YGEMbmFzE7zRjouaNwvcsjjc/cbrToo71GEs9dQb2 tr5vpe3zY9vrGVLk98mcmXBoHLiezaojcQq4O0CxN0U4U9J4UFn9lXgu0kPiB8/FC/Fe IyyofbcZO824fNBdaE5Wmb/58Mw5mBiTX9RkRQutUZPDhJvEqlhkmW+dB+iz7R2SbfFE SufA==
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=ry2edcbY+rdF5TdfxGa/Ymc+ewm3wDWAzFMbhdJNPbI=; b=NA23IqUKAHr28GNFNBYywk1vNNt23Bh6YXGQ9kvryGhwQYZLXMmMGYjyoIAplblD2V D9hUKfxpjS3UtO9C8DSCTM5c8DY9YuArPToui8GeQvQDGH7lIx3bADsPCQTK0145VCL/ pD6xD9fNtYKQX3DqLbMc753BLG9MnuiW+D5sdwG0hW28+Cmh1YUdL+1u4VjFLrgXdFQy lwfRCwQJh1mDTminn0slC9vcSbVaXOdinGOIlcAIIyzqVkgTcZDDo49+ELTARRwh/q8w ifeSuDv6KGUWdSNg1DDRNs2bUD+RWk5N/NCAelnOY/lsHc7/7GWTlme1vHNKqg1ZuwtN ulRA==
X-Gm-Message-State: AGi0PuYhwRryfdLmw6LuDzeAXJ6Nh/tBrkeC2SWg1gEKFZFykLAXqul9 qlx/nojh6Z/8oEFMNdGXl2iAjcilejpG8HSaBEycuQkHe3clAE196eImLn8Lrg21rjr7LWFUPhk KCo6FgPqVsyfLEE30z1k=
X-Google-Smtp-Source: APiQypKkBbGCuQjDm1IqOrwOiNtifBxiHJbRAaBHKRK/HJMiICK18o/MGeL6kblMAG7TxxqrJ6WgIOvQVxWIQU5Y8rw=
X-Received: by 2002:ac2:46e5:: with SMTP id q5mr15649776lfo.11.1587993957351;  Mon, 27 Apr 2020 06:25:57 -0700 (PDT)
MIME-Version: 1.0
References:   <20200425020227.GE27494@kduck.mit.edu> 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 27 Apr 2020 07:25:31 -0600
Message-ID: 
To: Vittorio Bertocci 
Cc: Benjamin Kaduk , oauth 
Content-Type: multipart/alternative; boundary="000000000000bc526f05a445a7b5"
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 27 Apr 2020 13:26:02 -0000

--000000000000bc526f05a445a7b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This old thread
https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/
has some discussion of working with/around that particular quirk of the
htmlizing tool.

On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci  wrote:

> Thank you for bringing this up Benjamin, you saved me from a long wild
> goose chase!
> It' good to know that there's a new rfc format version, but I am a bit
> worried about venturing there given that I am barely managing the v2 as i=
t
> is __ v3 still feels pretty experimental, and other than this issue, this
> spec doesn't give a lot of opportunities to take advantage of the new
> features (SVG etc).
> Wondering whether I can find a periphrase to express the same notion
> without triggering the script, e.g. omitting the word section or changing
> the order.
> Thx
> V.
>
> =EF=BB=BFOn 4/24/20, 19:02, "Benjamin Kaduk"  wrote:
>
>     Just on the xml2rfc bits...
>
>     On Wed, Apr 22, 2020 at 07:26:40AM +0000, Vittorio Bertocci wrote:
>     >
>     > > Link to section 4.1.2 of SCIM Core is actually linking to section
> 4.1.2 of this doc.
>     > Oh wow. That=E2=80=99s a feature of XML2RFC,=E2=80=A6 my source sim=
ply says by
> section 4.1.2 of SCIM Core  in a  block, and the processor interpret i=
t
> as an internal link. I=E2=80=99ll need to dig on how to prevent that from=
 happening
> for this instance. Good catch!
>
>     The short form is "you can't".
>
>     You're using the "v2" XML format for xml2rfc, which produces as vario=
us
>     output formats text, pdf, and "htmlized" output.  The "htmlized"
> output is
>     called that and not "html" because it's the result of taking the text
>     output and running a script to turn common constructions in I-Ds and
> RFCs
>     into hopefully-useful HTML formatting.  In this case, "Section N"
> outside
>     of "Section N of [bracketed-reference]" is assumed to be "Section N o=
f
> the
>     current document", and that's all that the htmlization script is goin=
g
> to
>     give you, since it's not working with the semantic richness of the XM=
L
>     source.
>
>     We do, however, as of fairly recently have a "v3" XML format, which i=
s
>     capable of producing native HTML output that includes SVG figures and
> the
>     other exciting features of "v3 XML".  For an example, see
>     https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .
>
>     I personally haven't done any v2-to-v3 conversions yet (too busy
> reading to
>     have time to do much writing), but the FAQ entry for doing so is at
>
> https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-con=
vert-my-xml-fil
>     .
>
>     Hope that helps,
>
>     Ben
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000bc526f05a445a7b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This old thread https://mailarchive.ietf.org/arc=
h/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/ has some discussion of working=
 with/around that particular quirk of the htmlizing tool. 

On Mon, Apr 2=
7, 2020 at 2:34 AM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Thank you for bri=
nging this up Benjamin, you saved me from a long wild goose chase!

It' good to know that there's a new rfc format version, but I am a =
bit worried about venturing there given that I am barely managing the v2 as=
 it is __ v3 still feels pretty experimental, and other than this issue, th=
is spec doesn't give a lot of opportunities to take advantage of the ne=
w features (SVG etc).=C2=A0 

Wondering whether I can find a periphrase to express the same notion withou=
t triggering the script, e.g. omitting the word section or changing the ord=
er.

Thx

V.



=EF=BB=BFOn 4/24/20, 19:02, "Benjamin Kaduk" <kaduk@mit.edu> wrote:



=C2=A0 =C2=A0 Just on the xml2rfc bits...



=C2=A0 =C2=A0 On Wed, Apr 22, 2020 at 07:26:40AM +0000, Vittorio Bertocci w=
rote:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > > Link to section 4.1.2 of SCIM Core is actually link=
ing to section 4.1.2 of this doc.

=C2=A0 =C2=A0 > Oh wow. That=E2=80=99s a feature of XML2RFC,=E2=80=A6 my=
 source simply says by section 4.1.2 of SCIM Core=C2=A0 in a <t> bloc=
k, and the processor interpret it as an internal link. I=E2=80=99ll need to=
 dig on how to prevent that from happening for this instance. Good catch!


=C2=A0 =C2=A0 The short form is "you can't".



=C2=A0 =C2=A0 You're using the "v2" XML format for xml2rfc, w=
hich produces as various

=C2=A0 =C2=A0 output formats text, pdf, and "htmlized" output.=C2=
=A0 The "htmlized" output is

=C2=A0 =C2=A0 called that and not "html" because it's the res=
ult of taking the text

=C2=A0 =C2=A0 output and running a script to turn common constructions in I=
-Ds and RFCs

=C2=A0 =C2=A0 into hopefully-useful HTML formatting.=C2=A0 In this case, &q=
uot;Section N" outside

=C2=A0 =C2=A0 of "Section N of [bracketed-reference]" is assumed =
to be "Section N of the

=C2=A0 =C2=A0 current document", and that's all that the htmlizati=
on script is going to

=C2=A0 =C2=A0 give you, since it's not working with the semantic richne=
ss of the XML

=C2=A0 =C2=A0 source.



=C2=A0 =C2=A0 We do, however, as of fairly recently have a "v3" X=
ML format, which is

=C2=A0 =C2=A0 capable of producing native HTML output that includes SVG fig=
ures and the

=C2=A0 =C2=A0 other exciting features of "v3 XML".=C2=A0 For an e=
xample, see

=C2=A0 =C2=A0 https://www.ietf.org/=
id/draft-ietf-tsvwg-datagram-plpmtud-19.html .



=C2=A0 =C2=A0 I personally haven't done any v2-to-v3 conversions yet (t=
oo busy reading to

=C2=A0 =C2=A0 have time to do much writing), but the FAQ entry for doing so=
 is at

=C2=A0 =C2=A0 https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-con=
vert-my-xml-fil

=C2=A0 =C2=A0 .



=C2=A0 =C2=A0 Hope that helps,



=C2=A0 =C2=A0 Ben



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000bc526f05a445a7b5--


From nobody Mon Apr 27 07:56:50 2020
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 40A263A0C3A for ; Mon, 27 Apr 2020 07:56:46 -0700 (PDT)
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=pingidentity.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 JId0LimLLYCB for ; Mon, 27 Apr 2020 07:56:44 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 1E0F33A0C28 for ; Mon, 27 Apr 2020 07:56:44 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id j3so17865108ljg.8 for ; Mon, 27 Apr 2020 07:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pfGmfNgxzBOIfzneCWMVrMUFKTWrtEUgpLTql/IDjPY=; b=GCMg95zCMyJYWI+Hxfnf7Jp7YoSmRiNDk81Qf5SuRIa17Rv6Q93ta8fUtG3Wr7Kzsw A1Dwyarx2HT57x+3tTRxRJhpw8D3QdatGDceFAU5YhY4DDVNjJ+byUPiHRxxXt4b/08S UxWxLgjSAYJO8wQIcdy6Wh9049exec1ljdE/9zZnYFB7yfMoX8va8Kq/TnrEx7pHhzLb /6ldZs+uEqIfEOff3J+TJBSU90MK5EcO3SOKmjZ2bQpN2m4res9o52c7Abk8qCsCuN80 rBaTuWAWB2CwENCWDkaFk/akLp50m6mVLW/3ccc/BUB14PAQvC+dBdI6bAra43wR2DdB Rh5A==
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=pfGmfNgxzBOIfzneCWMVrMUFKTWrtEUgpLTql/IDjPY=; b=RBXEjWACNUPfl1kQLiL6tcs98u4tKhoNiWJXnL64V8OltUDUf1sBD2xZjr3mWUXWjb NpK/8NqRw9iAA1tIw6rMckaGIwoYI5/rsjD4yevRx9rJkUBLR0skzpNdC24vWv75gxl9 qOd7zhR+2/IM9fTKqnLHhkqG5t8ZuLJ9E/apZbCJWy+/K9l8QfQwR0YevVYJLI/DC5xS AQBZ68PO05p0xGIhyK3t45DBxplhre9Z+qqvNJdTdC5zxFHk7J6ORrD2Guo+Lx7FTcex RP/YRNjIKzUIxD84bSh6G73J6S+jpzWX7rPf4nPyhojqhNG5QJbrfcVugR46Fy/YtiWM DM3A==
X-Gm-Message-State: AGi0Pua3Ztiu52AcuoSjbMa/kthh8Mt5fqo1/Np9aDmhsc4BtJ6xNiD1 qgYRjm3JcEAKnTABt0crS0JMq4ccFtARHyItpUjtrMdUoA+GYaU9iYbYe2B77sL7evPXJBOQfaa Cmf7B8S2a3Eb0CQ==
X-Google-Smtp-Source: APiQypI5KL00/yABV23Se1s1nJSfwsmzS/hkVS552VJLvtfP4CfgMPFqSBNN7UT3EL7ji75F9PBLxNwJnggyAupKB6U=
X-Received: by 2002:a2e:3813:: with SMTP id f19mr14191659lja.216.1587999402052;  Mon, 27 Apr 2020 07:56:42 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 27 Apr 2020 08:56:15 -0600
Message-ID: 
To: Aaron Parecki 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000043700f05a446ec83"
Archived-At: 
Subject: Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01
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, 27 Apr 2020 14:56:48 -0000

--00000000000043700f05a446ec83
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki  wrote:

> Thanks for the detailed review Brian! I've made many of these edits to th=
e
> draft, but there are still a few things that need some discussion on the
> list. My notes are inline below.
>

Thanks Aaron. I realize there was a lot there. I've followed up on just a
couple of the things below that seemed like they needed a response.


>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6
>>  "  *  _Sender-constrained refresh tokens:_ the authorization server
>>       cryptographically binds the refresh token to a certain client
>>       instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705].=
"
>> Given the relative immaturity of ways to do this, maybe something more
>> open ended would be appropriate? This reads like token-binding or MTLS a=
re
>> the only ways allowed. I'd think wording that would allow for DPoP or so=
me
>> yet-to-be-defined method would be better here. Also maybe drop the
>> token-binding reference all together (it's long expired and doesn't look
>> like that's gonna change).
>>
>
> I'm generally supportive of something more open ended here. Would that
> also suggest that the corresponding text in the Security BCP be updated a=
s
> well?
>

For some reason, I'd been thinking that this stuff had been changed in the
Security draft. But I was apparently mistaken.  Anyway, yes, I think it
should be updated there as well.



>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.7
>> 
>> "Attacker A4 in (#secmodel)"
>> "The use of PKCE is RECOMMENDED to this end."
>> PKCE is required elsewhere so this doesn't seem quite right. Similar
>> comments about text ijn
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14
>> that talks as though PKCE might not be there.
>>
>
> I believe this text was included since an extension such as OpenID Connec=
t
> can define other methods of authorization code injection. Also note that
> this same sentence is in the Security BCP so if we update anything here
> they should probably match.
>

I guess my understanding of the intended scope of the two documents was
that they were a little different. Like there's a security profile that
describes a few different ways of achieving something with the tools of
2.0, OIDC and PKCE. While 2.1 is saying PKCE is always required and there
are benefits to that. So the latter doesn't seem to need conditional
language around PKCE or alternatives. Maybe my understanding is flawed
though. Or maybe there's a larger question here about the value/need/cost
of having a lot of duplicative or overlapping content across multiple
documents.

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000043700f05a446ec83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Apr 24, 2020 at 5:48 PM Aaron=
 Parecki <aaron@parecki.com>=
 wrote:
Thanks for the detailed review Brian! I=
've made many of these edits to the draft, but there are still a few th=
ings that need some discussion on the list. My notes are inline below.

Thanks Aaron. I realize there was a=
 lot there. I've followed up on just a couple of the things below that =
seemed like they needed a response. 
=C2=A0
<=
div> 

https://tools.ietf.org/=
html/draft-parecki-oauth-v2-1-01#section-6
=C2=A0"=C2=A0 * =C2=
=A0_Sender-constrained refresh tokens:_ the authorization server
=C2=A0 =
=C2=A0 =C2=A0 cryptographically binds the refresh token to a certain client=

=C2=A0 =C2=A0 =C2=A0 instance by utilizing [I-D.ietf-oauth-token-bindin=
g] or [RFC8705]."
Given the relative immaturity of ways to d=
o this, maybe something more open ended would be appropriate? This reads li=
ke token-binding or MTLS are the only ways allowed. I'd think wording t=
hat would allow for DPoP or some yet-to-be-defined method would be better h=
ere. Also maybe drop the token-binding reference all together (it's lon=
g expired and doesn't look like that's gonna change). 

I'm generally supportive of somethi=
ng more open ended here. Would that also suggest that the corresponding tex=
t in the Security BCP be updated as well?

For some reason, I'd been thinking that this stuff had=
 been changed in the Security draft. But I was apparently mistaken.=C2=A0 A=
nyway, yes, I think it should be updated there as well. 
=C2=
=A0
=C2=A0

"Attacker A4 in (#secmodel)"=
 
"The use of PKCE is RECOMMENDED to this end."
PKCE is required elsewhere so this doesn't seem quite right. Sim=
ilar comments about text ijn https://tools.ietf.org=
/html/draft-parecki-oauth-v2-1-01#section-9.14 that talks as though PKC=
E might not be there.=C2=A0=C2=A0

I believe this text was included since an extension such as OpenID Conne=
ct can define other methods of authorization code injection. Also note that=
 this same sentence is in the Security BCP so if we update anything here th=
ey should probably match.

I guess my understanding of the intended scope of the two documents was th=
at they were a little different. Like there's a security profile that d=
escribes a few different ways of achieving something with the tools of 2.0,=
 OIDC and PKCE. While 2.1 is saying PKCE is always required and there are b=
enefits to that. So the latter doesn't seem to need conditional languag=
e around PKCE or alternatives. Maybe my understanding is flawed though. Or =
maybe there's a larger question here about the value/need/cost of havin=
g a lot of duplicative or overlapping content across multiple documents. 
=C2=A0




<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000043700f05a446ec83--


From nobody Mon Apr 27 07:57:52 2020
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 F28BF3A0C01 for ; Mon, 27 Apr 2020 07:57:50 -0700 (PDT)
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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Yk_RDtS06r7t for ; Mon, 27 Apr 2020 07:57:48 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 2C4C73A0C2B for ; Mon, 27 Apr 2020 07:57:47 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id 188so4952wmc.2 for ; Mon, 27 Apr 2020 07:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dYpxWwYs77L/wrRyDY6NkKLG3sfvC+ne1X8PwWUzbR0=; b=Rj+d4uIOAxwuWl/zqFQ5PbiPt33doqr/O9jlc0AkeLL4tScAHndarZecvxZPAsqxF2 gaBuuoMwr7T0ek+4Fqk6RmghtHU3oytnanBYRrHJeYkRjy7HG6LUOwtQ2H440ioGopjS ws0+TIp1bWvFX8qHSGtcxJmzsbN3R4VROcm3+crz/zGhe7sArshbJDMZKwSoM5FfE8IH aEVs5pT4E5NktJPDpMRbTmBsa0HiF04mFMewKDJJ63Fn+4NzyRa0Rp0XwE4y+hH1EQAI oBVXINqLBgESA6ILljx/DtAf7zv4fqEDGfsrsGxCLPl+Piqb3jcaNDm4LJYUkLhn7jrp 63FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dYpxWwYs77L/wrRyDY6NkKLG3sfvC+ne1X8PwWUzbR0=; b=WXk7V53w+PEKmL4isNjknUGLZlzMZUry8PlQqEQmNT2NjmQ0ZxNykPlAkK9O8yPwil Pc4XCAhfZHVu+EHGyAsKkN//270d4pRZKWi0fme/+y6UQ0s01gM4Rh3oHt22lRS772qi q9fwTw/s3A9SS2FLMMBcn021Fc9UPRDbHoc0rkKIOiJt5WzQba5NxNbL+Lqhl9W6Rfdq TQZ3EVKc6U1bcl+RydayaB/Sh/H/smwOkAU3K1O8rauoDfohfJ7+AeeGQQBCtdhBfw2q 5T7FLPGG1zj1R/ZiXxqBqYxFXQTwMnecOCpsL4u/wA6ZxgOE/Sz2QIXowkF3dcqHEOEf kqMA==
X-Gm-Message-State: AGi0PuYuXl9oawEhek78YM1IPfzrzH+3Gw+p3PINH7rFhIJBV7ve3DrB 2WL7fwhZnISG6DPp1Ys+1Jv15yLw8p6QrgbjHZ4=
X-Google-Smtp-Source: APiQypJVyxsaYZu+VKrCh0LHxxO2P1jNfiCJAN8kjSHhaJfPb2HiBE/j5aCxzTm/fF9npL+1lB61/ry2NCFf0fpvOjM=
X-Received: by 2002:a1c:4d17:: with SMTP id o23mr26170060wmh.120.1587999466430;  Mon, 27 Apr 2020 07:57:46 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Sascha Preibisch 
Date: Mon, 27 Apr 2020 07:57:10 -0700
Message-ID: 
To: Filip Skokan 
Cc: Torsten Lodderstedt , oauth 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 27 Apr 2020 14:57:51 -0000

+1

On Mon, 27 Apr 2020 at 01:42, Filip Skokan  wrote:
>
> I believe implementers should be free to devise their own URIs and not be=
 locked down to one by the spec, at the same time, and RFC6755 subnamespace=
 would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g. `urn:ietf:params:oauth:=
request_uri:` (Brian's proposal) but also that any URN or URL will =
do if the circumstances call for it.
>
> Best,
> Filip
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  wrote:
>>
>> Hi all,
>>
>> another topic from last week=E2=80=99s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> _______________________________________________
>> 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


From nobody Mon Apr 27 09:58:18 2020
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 B3C183A0F70 for ; Mon, 27 Apr 2020 09:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spebw5fd9FI1 for ; Mon, 27 Apr 2020 09:58:14 -0700 (PDT)
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 2303C3A0FAB for ; Mon, 27 Apr 2020 09:58:13 -0700 (PDT)
Received: from [192.168.1.13] (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 03RGw9In000754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 12:58:10 -0400
From: Justin Richer 
Message-Id: <32A77307-BFE4-4A0E-99F6-B9567DF38645@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_76F1507D-3DF0-448D-ACA0-9FE844F9DADF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Apr 2020 12:58:09 -0400
In-Reply-To: 
Cc: Torsten Lodderstedt , oauth 
To: Filip Skokan 
References:  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 27 Apr 2020 16:58:16 -0000

--Apple-Mail=_76F1507D-3DF0-448D-ACA0-9FE844F9DADF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree that any URI could be used but that it MUST be understood by the =
AS to be local to the AS (and not something that can be impersonated by =
an attacker). I wouldn=E2=80=99t even go so far as RECOMMENDED, but =
it=E2=80=99s certainly an option.

 =E2=80=94 Justin

> On Apr 27, 2020, at 4:41 AM, Filip Skokan  wrote:
>=20
> I believe implementers should be free to devise their own URIs and not =
be locked down to one by the spec, at the same time, and RFC6755 =
subnamespace would be good for guidance.
>=20
> So, I would suggest it be RECOMMENDED to use e.g. =
`urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also =
that any URN or URL will do if the circumstances call for it.
>=20
> Best,
> Filip
>=20
>=20
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt =
> wrote:
> Hi all,=20
>=20
> another topic from last week=E2=80=99s virtual meeting.=20
>=20
> Shall there be guidance on the request URI structure?=20
>=20
> Please state your opinion.=20
>=20
> thanks in advance,=20
> Torsten.=20
> _______________________________________________
> 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


--Apple-Mail=_76F1507D-3DF0-448D-ACA0-9FE844F9DADF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
agree that any URI could be used but that it MUST be understood by the =
AS to be local to the AS (and not something that can be impersonated by =
an attacker). I wouldn=E2=80=99t even go so far as RECOMMENDED, but =
it=E2=80=99s certainly an option.

 =E2=80=94 Justin

On Apr =
27, 2020, at 4:41 AM, Filip Skokan <panva.ip@gmail.com> =
wrote:

I believe =
implementers should be free to devise their own URIs and not be locked =
down to one by the spec, at the same time, =
and RFC6755 subnamespace would be good for =
guidance.

So, =
I would suggest it be RECOMMENDED to use e.g. =
`urn:ietf:params:oauth:request_uri:<random>` (Brian's proposal) =
but also that any URN or URL will do if the circumstances call for =
it.

Best,
Filip


On Sun, 26 Apr 2020 at 17:20, Torsten =
Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all, 



another topic from last week=E2=80=99s virtual meeting. 



Shall there be guidance on the request URI structure? 



Please state your opinion. 



thanks in advance, 

Torsten. 

_______________________________________________

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

=

--Apple-Mail=_76F1507D-3DF0-448D-ACA0-9FE844F9DADF--


From nobody Mon Apr 27 10:23:10 2020
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 BCEEE3A1214 for ; Mon, 27 Apr 2020 10:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=afitnerd-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o94mqNi7MwN for ; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 66E0B3A1212 for ; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id z16so18177481uae.11 for ; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=afitnerd-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=h+I2YOBrTK7wRN7zDqkCKHORlSjOop+G31reByF2O9A=; b=W96JCRkt1B1YzpKmbGHN+raSvOh4TjEac/wLbkRDUjvi0a2N/B7k0VANuyfa+2Blmm x1oza+7HCJnL8qa92zNT4M3iJIk0HLLzTe+0dDgIlkCzLrzeKGZwqD4t3abPqKhf00O4 ZBmCr20QWoyVb2YV0FAP0Krp1ataLiRXoAIYkaVMo1spNzTHWSzExcx1dyJpEQfAe+2x nohsrxB7wCR10eP27MaGF4tGi5sxT4Evt5ORG/qpBaDpzn1DU/xLr6A1aEFiBawKx8U5 VlvBl377qn187c5iVlx9sJouw2iwpZo8dLwy/G18V/S3NFgaPzWXyUr9d5PSmCpW+eMD RU2w==
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=h+I2YOBrTK7wRN7zDqkCKHORlSjOop+G31reByF2O9A=; b=A+4NF9KXFxCr4Gl0dKsbvaunmk9FIqzr0EjhXMQrBKLd1yaw8oO1BTwEH4bqRhj2fa uoT7Uwx6D1BA5vhyH1Hb0Jku/wLAulBdwY4dR/2x7knQC8kVJE6sVTLxQbLwXu6Qnu+X 7oHXOE1Gevz+faNqucZWo/PuFkUot7yxcHknpRTvVrmOB04bnSLfXAFX4FMCM7eBls8Z KWaes9JJrKailuvxztfIMKEwo1WkoiOsrdA/R3QfOq5IO3Jz8lPTDNHm0P25KFymizZT 3QG4+U6awCgi3627jt+qkZmeCw0pI1Z1e7MOZG8U3YjZl13Wahv9hi8Cu8n0W8dCI3Xp sEpA==
X-Gm-Message-State: AGi0PubUx5ucc+HCI5MupGwu+dwjATqLO9x/qiJYE9uH5TJKezh8hSEV xlDcZW4HvgomcM4GDfCmwfqhazZG64oHRaslhggxh8uNjSQZ8Q==
X-Google-Smtp-Source: APiQypLDuCtZc5OodF9x5y/Ks+PTPVk8Awauakb4gJJM/1J2ZlkP1/HeFEhRt9ZqBCwyc19NmMFOBcrFDRA8tyZ9RaI=
X-Received: by 2002:a67:3293:: with SMTP id y141mr17814205vsy.54.1588008183641;  Mon, 27 Apr 2020 10:23:03 -0700 (PDT)
MIME-Version: 1.0
From: Micah Silverman 
Date: Mon, 27 Apr 2020 13:22:52 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000afd07f05a448f736"
Archived-At: 
Subject: [OAUTH-WG] draft-parecki-oauth-v2-1-01 - inconsistencies regarding refresh tokens
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, 27 Apr 2020 17:23:08 -0000

--000000000000afd07f05a448f736
Content-Type: text/plain; charset="UTF-8"

In section 1.5, step 8 in the flow says:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token (and, optionally, a new
refresh token).

Also, Figure 2, step 8 says:

Access Token & Optional Refresh Token

Whether or not the refresh token is rotated (as defined in section 6),
doesn't the response always include a refresh token?

Since it seems likely that the more common use-case will be refresh token
rotation, perhaps the wording in section 1.5 should lean that way?

Perhaps 1.5, step 8 should say:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token and a new refresh token (or
uses the same refresh token if certain security requirements are met).

Perhaps Figure 2, step 8 should say:

Access Token & Refresh Token

Best,

Micah

--000000000000afd07f05a448f736
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--000000000000afd07f05a448f736--


From nobody Mon Apr 27 10:50:20 2020
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 1B4953A12C0 for ; Mon, 27 Apr 2020 10:48:27 -0700 (PDT)
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 rdXgTybIrgtQ for ; Mon, 27 Apr 2020 10:48:18 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 BB4D83A12A6 for ; Mon, 27 Apr 2020 10:48:18 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id e6so7738459pjt.4 for ; Mon, 27 Apr 2020 10:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=hUHZmb0DSe3aSbw5D1fVbLP+Q4HSITMs0DUOPdWbhz4=; b=ZK61E2HKE6iubnmNqRdCqWZaG9RgwxDP/+Siyu+gMqwTfs5uprqMjukAvC3m6l5ivN 2hNjQ6LtIqAeasHzVTTyx0E0oV7f04qNBTmh1BlAM2vkkafC8DVmIf1u1XZxCMTFBwxZ nMELjCwlpFxPwyFR4JC4aTT9gNVI9UcT9+yNqYvWsMA3Yk9G/gLyx0L0WB2Kn7reFJ/h c6NLK/XLaz02nQ90OUr7efQxp2BB4OzKknbMQt71vCwCHw3yCX9zRmUIH2so6pLG5bei TEWyV+Wewaxt7QaBylWQJAUaiRsWVlLdjnI0cKlC3O60fLiE3pmUNbMreDpobsVH1YCb r41Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=hUHZmb0DSe3aSbw5D1fVbLP+Q4HSITMs0DUOPdWbhz4=; b=gsWZEWbyFEdUmkdROtOi9Sw/6X7RFdgd+KHAi7TmL8lk2ds+8JA1ZK5WSy98oSylhv uREoh4HU6kmcrQGYCTtuicxh0jxxoJv7k7jYnBdIy8grwWLFw5tc6HMF9uYmHTKL6EiY i76gPacH/HU/tNIhlsahGTHxxV7OCz4P1TtB2E6H5EI2ten5YpI030v1aue6COsdXgdf xLGz5j7p+Awt9O5FzrbPRSmQkEfQNxhpImVYALkcI6buEtA0/FZIB4Cj8JnhFk91np2/ sKZebSmOE9gVE0UEpAVkHiMtNDivmaaTu0Z8GCFiSzOe0X4hcg/zZ6n8VQiZO5rGKKPR H2Vw==
X-Gm-Message-State: AGi0PubAR+HX75B8sXO15ExuQEZG/8T5zVSluDLWgC2jFbG/hugxVfTo /xikRnzTtdCKHoj09zGyS3IbiA==
X-Google-Smtp-Source: APiQypJq2R355nwuZlIKcx7PUljDxOkiX8eLb/2aJRQN2I8W902P+N2/U67HMiqhiV3osEqWl0AOGA==
X-Received: by 2002:a17:902:b495:: with SMTP id y21mr23951831plr.111.1588009697674;  Mon, 27 Apr 2020 10:48:17 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id m4sm12919886pfm.26.2020.04.27.10.48.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 10:48:17 -0700 (PDT)
From: Vittorio Bertocci 
To: Brian Campbell , Vittorio Bertocci 
CC: oauth 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: ATQyNzI0nSApJGzn7Wo3R7pPiiSeHzA5MzIxwlL2p4CAAElpBA==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 27 Apr 2020 17:48:16 +0000
Message-ID: 
References:   <20200425020227.GE27494@kduck.mit.edu>  
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: multipart/alternative; boundary="_000_MWHPR19MB15012AA6CB49DB8818C792B4AEAF0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 27 Apr 2020 17:48:29 -0000

--_000_MWHPR19MB15012AA6CB49DB8818C792B4AEAF0MWHPR19MB1501namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIEJyaWFuLCB0aGF0IGFwcGVhcnMgdG8gaGF2ZSB3b3JrZWQhDQoNCkZyb206IE9BdXRo
IDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQnJpYW4gQ2FtcGJlbGwgPGJj
YW1wYmVsbD00MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBNb25kYXks
IEFwcmlsIDI3LCAyMDIwIGF0IDA2OjI2DQpUbzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlv
LmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IG9hdXRoIDxvYXV0aEBp
ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNlY29uZCBXR0xDIG9uICJKU09OIFdl
YiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyINCg0KVGhp
cyBvbGQgdGhyZWFkIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgv
MWFqRS1kM25WT0ZSR0xid01tUFZpRGhFZHF3LyBoYXMgc29tZSBkaXNjdXNzaW9uIG9mIHdvcmtp
bmcgd2l0aC9hcm91bmQgdGhhdCBwYXJ0aWN1bGFyIHF1aXJrIG9mIHRoZSBodG1saXppbmcgdG9v
bC4NCg0KT24gTW9uLCBBcHIgMjcsIDIwMjAgYXQgMjozNCBBTSBWaXR0b3JpbyBCZXJ0b2NjaSA8
dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0
aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpUaGFuayB5b3UgZm9yIGJyaW5naW5nIHRo
aXMgdXAgQmVuamFtaW4sIHlvdSBzYXZlZCBtZSBmcm9tIGEgbG9uZyB3aWxkIGdvb3NlIGNoYXNl
IQ0KSXQnIGdvb2QgdG8ga25vdyB0aGF0IHRoZXJlJ3MgYSBuZXcgcmZjIGZvcm1hdCB2ZXJzaW9u
LCBidXQgSSBhbSBhIGJpdCB3b3JyaWVkIGFib3V0IHZlbnR1cmluZyB0aGVyZSBnaXZlbiB0aGF0
IEkgYW0gYmFyZWx5IG1hbmFnaW5nIHRoZSB2MiBhcyBpdCBpcyBfXyB2MyBzdGlsbCBmZWVscyBw
cmV0dHkgZXhwZXJpbWVudGFsLCBhbmQgb3RoZXIgdGhhbiB0aGlzIGlzc3VlLCB0aGlzIHNwZWMg
ZG9lc24ndCBnaXZlIGEgbG90IG9mIG9wcG9ydHVuaXRpZXMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Yg
dGhlIG5ldyBmZWF0dXJlcyAoU1ZHIGV0YykuDQpXb25kZXJpbmcgd2hldGhlciBJIGNhbiBmaW5k
IGEgcGVyaXBocmFzZSB0byBleHByZXNzIHRoZSBzYW1lIG5vdGlvbiB3aXRob3V0IHRyaWdnZXJp
bmcgdGhlIHNjcmlwdCwgZS5nLiBvbWl0dGluZyB0aGUgd29yZCBzZWN0aW9uIG9yIGNoYW5naW5n
IHRoZSBvcmRlci4NClRoeA0KVi4NCg0K77u/T24gNC8yNC8yMCwgMTk6MDIsICJCZW5qYW1pbiBL
YWR1ayIgPGthZHVrQG1pdC5lZHU8bWFpbHRvOmthZHVrQG1pdC5lZHU+PiB3cm90ZToNCg0KICAg
IEp1c3Qgb24gdGhlIHhtbDJyZmMgYml0cy4uLg0KDQogICAgT24gV2VkLCBBcHIgMjIsIDIwMjAg
YXQgMDc6MjY6NDBBTSArMDAwMCwgVml0dG9yaW8gQmVydG9jY2kgd3JvdGU6DQogICAgPg0KICAg
ID4gPiBMaW5rIHRvIHNlY3Rpb24gNC4xLjIgb2YgU0NJTSBDb3JlIGlzIGFjdHVhbGx5IGxpbmtp
bmcgdG8gc2VjdGlvbiA0LjEuMiBvZiB0aGlzIGRvYy4NCiAgICA+IE9oIHdvdy4gVGhhdOKAmXMg
YSBmZWF0dXJlIG9mIFhNTDJSRkMs4oCmIG15IHNvdXJjZSBzaW1wbHkgc2F5cyBieSBzZWN0aW9u
IDQuMS4yIG9mIFNDSU0gQ29yZSAgaW4gYSA8dD4gYmxvY2ssIGFuZCB0aGUgcHJvY2Vzc29yIGlu
dGVycHJldCBpdCBhcyBhbiBpbnRlcm5hbCBsaW5rLiBJ4oCZbGwgbmVlZCB0byBkaWcgb24gaG93
IHRvIHByZXZlbnQgdGhhdCBmcm9tIGhhcHBlbmluZyBmb3IgdGhpcyBpbnN0YW5jZS4gR29vZCBj
YXRjaCENCg0KICAgIFRoZSBzaG9ydCBmb3JtIGlzICJ5b3UgY2FuJ3QiLg0KDQogICAgWW91J3Jl
IHVzaW5nIHRoZSAidjIiIFhNTCBmb3JtYXQgZm9yIHhtbDJyZmMsIHdoaWNoIHByb2R1Y2VzIGFz
IHZhcmlvdXMNCiAgICBvdXRwdXQgZm9ybWF0cyB0ZXh0LCBwZGYsIGFuZCAiaHRtbGl6ZWQiIG91
dHB1dC4gIFRoZSAiaHRtbGl6ZWQiIG91dHB1dCBpcw0KICAgIGNhbGxlZCB0aGF0IGFuZCBub3Qg
Imh0bWwiIGJlY2F1c2UgaXQncyB0aGUgcmVzdWx0IG9mIHRha2luZyB0aGUgdGV4dA0KICAgIG91
dHB1dCBhbmQgcnVubmluZyBhIHNjcmlwdCB0byB0dXJuIGNvbW1vbiBjb25zdHJ1Y3Rpb25zIGlu
IEktRHMgYW5kIFJGQ3MNCiAgICBpbnRvIGhvcGVmdWxseS11c2VmdWwgSFRNTCBmb3JtYXR0aW5n
LiAgSW4gdGhpcyBjYXNlLCAiU2VjdGlvbiBOIiBvdXRzaWRlDQogICAgb2YgIlNlY3Rpb24gTiBv
ZiBbYnJhY2tldGVkLXJlZmVyZW5jZV0iIGlzIGFzc3VtZWQgdG8gYmUgIlNlY3Rpb24gTiBvZiB0
aGUNCiAgICBjdXJyZW50IGRvY3VtZW50IiwgYW5kIHRoYXQncyBhbGwgdGhhdCB0aGUgaHRtbGl6
YXRpb24gc2NyaXB0IGlzIGdvaW5nIHRvDQogICAgZ2l2ZSB5b3UsIHNpbmNlIGl0J3Mgbm90IHdv
cmtpbmcgd2l0aCB0aGUgc2VtYW50aWMgcmljaG5lc3Mgb2YgdGhlIFhNTA0KICAgIHNvdXJjZS4N
Cg0KICAgIFdlIGRvLCBob3dldmVyLCBhcyBvZiBmYWlybHkgcmVjZW50bHkgaGF2ZSBhICJ2MyIg
WE1MIGZvcm1hdCwgd2hpY2ggaXMNCiAgICBjYXBhYmxlIG9mIHByb2R1Y2luZyBuYXRpdmUgSFRN
TCBvdXRwdXQgdGhhdCBpbmNsdWRlcyBTVkcgZmlndXJlcyBhbmQgdGhlDQogICAgb3RoZXIgZXhj
aXRpbmcgZmVhdHVyZXMgb2YgInYzIFhNTCIuICBGb3IgYW4gZXhhbXBsZSwgc2VlDQogICAgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10c3Z3Zy1kYXRhZ3JhbS1wbHBtdHVkLTE5
Lmh0bWwgLg0KDQogICAgSSBwZXJzb25hbGx5IGhhdmVuJ3QgZG9uZSBhbnkgdjItdG8tdjMgY29u
dmVyc2lvbnMgeWV0ICh0b28gYnVzeSByZWFkaW5nIHRvDQogICAgaGF2ZSB0aW1lIHRvIGRvIG11
Y2ggd3JpdGluZyksIGJ1dCB0aGUgRkFRIGVudHJ5IGZvciBkb2luZyBzbyBpcyBhdA0KICAgIGh0
dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9GQVEteG1sMnJmY3YzLmh0bWwjbmFt
ZS1ob3ctZG8taS1jb252ZXJ0LW15LXhtbC1maWw8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv
bWF0ZXJpYWxzL0ZBUS14bWwycmZjdjMuLmh0bWwjbmFtZS1ob3ctZG8taS1jb252ZXJ0LW15LXht
bC1maWw+DQogICAgLg0KDQogICAgSG9wZSB0aGF0IGhlbHBzLA0KDQogICAgQmVuDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KQ09ORklERU5USUFMSVRZIE5PVElD
RTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0
ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkg
cmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJp
Y3RseSBwcm9oaWJpdGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv
biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp
bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv
dXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4NCg==

--_000_MWHPR19MB15012AA6CB49DB8818C792B4AEAF0MWHPR19MB1501namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlRoYW5rcyBCcmlhbiwgdGhhdCBhcHBlYXJzIHRvIGhhdmUgd29ya2VkITxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGggJmx0O29hdXRoLWJv
dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBi
ZWxsPTQwcGluZ2lkZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8
L2I+TW9uZGF5LCBBcHJpbCAyNywgMjAyMCBhdCAwNjoyNjxicj4NCjxiPlRvOiA8L2I+Vml0dG9y
aW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYu
b3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4N
CjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBTZWNvbmQgV0dMQyBvbiAmcXVvdDtKU09O
IFdlYiBUb2tlbiAoSldUKSBQcm9maWxlIGZvciBPQXV0aCAyLjAgQWNjZXNzIFRva2VucyZxdW90
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhpcyBvbGQgdGhyZWFkIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v
cmcvYXJjaC9tc2cvb2F1dGgvMWFqRS1kM25WT0ZSR0xid01tUFZpRGhFZHF3LyI+DQpodHRwczov
L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoLzFhakUtZDNuVk9GUkdMYndNbVBW
aURoRWRxdy88L2E+IGhhcyBzb21lIGRpc2N1c3Npb24gb2Ygd29ya2luZyB3aXRoL2Fyb3VuZCB0
aGF0IHBhcnRpY3VsYXIgcXVpcmsgb2YgdGhlIGh0bWxpemluZyB0b29sLg0KPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAyNywgMjAyMCBh
dCAyOjM0IEFNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVm
PSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwYXV0aDAuY29tQGRtYXJjLmll
dGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIGJyaW5naW5nIHRoaXMgdXAgQmVu
amFtaW4sIHlvdSBzYXZlZCBtZSBmcm9tIGEgbG9uZyB3aWxkIGdvb3NlIGNoYXNlITxicj4NCkl0
JyBnb29kIHRvIGtub3cgdGhhdCB0aGVyZSdzIGEgbmV3IHJmYyBmb3JtYXQgdmVyc2lvbiwgYnV0
IEkgYW0gYSBiaXQgd29ycmllZCBhYm91dCB2ZW50dXJpbmcgdGhlcmUgZ2l2ZW4gdGhhdCBJIGFt
IGJhcmVseSBtYW5hZ2luZyB0aGUgdjIgYXMgaXQgaXMgX18gdjMgc3RpbGwgZmVlbHMgcHJldHR5
IGV4cGVyaW1lbnRhbCwgYW5kIG90aGVyIHRoYW4gdGhpcyBpc3N1ZSwgdGhpcyBzcGVjIGRvZXNu
J3QgZ2l2ZSBhIGxvdCBvZiBvcHBvcnR1bml0aWVzDQogdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhl
IG5ldyBmZWF0dXJlcyAoU1ZHIGV0YykuJm5ic3A7IDxicj4NCldvbmRlcmluZyB3aGV0aGVyIEkg
Y2FuIGZpbmQgYSBwZXJpcGhyYXNlIHRvIGV4cHJlc3MgdGhlIHNhbWUgbm90aW9uIHdpdGhvdXQg
dHJpZ2dlcmluZyB0aGUgc2NyaXB0LCBlLmcuIG9taXR0aW5nIHRoZSB3b3JkIHNlY3Rpb24gb3Ig
Y2hhbmdpbmcgdGhlIG9yZGVyLjxicj4NClRoeDxicj4NClYuPGJyPg0KPGJyPg0K77u/T24gNC8y
NC8yMCwgMTk6MDIsICZxdW90O0JlbmphbWluIEthZHVrJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86a2FkdWtAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmthZHVrQG1pdC5lZHU8L2E+Jmd0OyB3
cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEp1c3Qgb24gdGhlIHhtbDJyZmMgYml0cy4u
Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgT24gV2VkLCBBcHIgMjIsIDIwMjAgYXQgMDc6MjY6
NDBBTSAmIzQzOzAwMDAsIFZpdHRvcmlvIEJlcnRvY2NpIHdyb3RlOjxicj4NCiZuYnNwOyAmbmJz
cDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyBMaW5rIHRvIHNlY3Rpb24gNC4x
LjIgb2YgU0NJTSBDb3JlIGlzIGFjdHVhbGx5IGxpbmtpbmcgdG8gc2VjdGlvbiA0LjEuMiBvZiB0
aGlzIGRvYy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgT2ggd293LiBUaGF04oCZcyBhIGZlYXR1
cmUgb2YgWE1MMlJGQyzigKYgbXkgc291cmNlIHNpbXBseSBzYXlzIGJ5IHNlY3Rpb24gNC4xLjIg
b2YgU0NJTSBDb3JlJm5ic3A7IGluIGEgJmx0O3QmZ3Q7IGJsb2NrLCBhbmQgdGhlIHByb2Nlc3Nv
ciBpbnRlcnByZXQgaXQgYXMgYW4gaW50ZXJuYWwgbGluay4gSeKAmWxsIG5lZWQgdG8gZGlnIG9u
IGhvdyB0byBwcmV2ZW50IHRoYXQgZnJvbSBoYXBwZW5pbmcgZm9yIHRoaXMgaW5zdGFuY2UuIEdv
b2QgY2F0Y2ghPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgc2hvcnQgZm9ybSBpcyAmcXVv
dDt5b3UgY2FuJ3QmcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBZb3UncmUgdXNpbmcg
dGhlICZxdW90O3YyJnF1b3Q7IFhNTCBmb3JtYXQgZm9yIHhtbDJyZmMsIHdoaWNoIHByb2R1Y2Vz
IGFzIHZhcmlvdXM8YnI+DQombmJzcDsgJm5ic3A7IG91dHB1dCBmb3JtYXRzIHRleHQsIHBkZiwg
YW5kICZxdW90O2h0bWxpemVkJnF1b3Q7IG91dHB1dC4mbmJzcDsgVGhlICZxdW90O2h0bWxpemVk
JnF1b3Q7IG91dHB1dCBpczxicj4NCiZuYnNwOyAmbmJzcDsgY2FsbGVkIHRoYXQgYW5kIG5vdCAm
cXVvdDtodG1sJnF1b3Q7IGJlY2F1c2UgaXQncyB0aGUgcmVzdWx0IG9mIHRha2luZyB0aGUgdGV4
dDxicj4NCiZuYnNwOyAmbmJzcDsgb3V0cHV0IGFuZCBydW5uaW5nIGEgc2NyaXB0IHRvIHR1cm4g
Y29tbW9uIGNvbnN0cnVjdGlvbnMgaW4gSS1EcyBhbmQgUkZDczxicj4NCiZuYnNwOyAmbmJzcDsg
aW50byBob3BlZnVsbHktdXNlZnVsIEhUTUwgZm9ybWF0dGluZy4mbmJzcDsgSW4gdGhpcyBjYXNl
LCAmcXVvdDtTZWN0aW9uIE4mcXVvdDsgb3V0c2lkZTxicj4NCiZuYnNwOyAmbmJzcDsgb2YgJnF1
b3Q7U2VjdGlvbiBOIG9mIFticmFja2V0ZWQtcmVmZXJlbmNlXSZxdW90OyBpcyBhc3N1bWVkIHRv
IGJlICZxdW90O1NlY3Rpb24gTiBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7IGN1cnJlbnQgZG9j
dW1lbnQmcXVvdDssIGFuZCB0aGF0J3MgYWxsIHRoYXQgdGhlIGh0bWxpemF0aW9uIHNjcmlwdCBp
cyBnb2luZyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgZ2l2ZSB5b3UsIHNpbmNlIGl0J3Mgbm90IHdv
cmtpbmcgd2l0aCB0aGUgc2VtYW50aWMgcmljaG5lc3Mgb2YgdGhlIFhNTDxicj4NCiZuYnNwOyAm
bmJzcDsgc291cmNlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgV2UgZG8sIGhvd2V2ZXIsIGFz
IG9mIGZhaXJseSByZWNlbnRseSBoYXZlIGEgJnF1b3Q7djMmcXVvdDsgWE1MIGZvcm1hdCwgd2hp
Y2ggaXM8YnI+DQombmJzcDsgJm5ic3A7IGNhcGFibGUgb2YgcHJvZHVjaW5nIG5hdGl2ZSBIVE1M
IG91dHB1dCB0aGF0IGluY2x1ZGVzIFNWRyBmaWd1cmVzIGFuZCB0aGU8YnI+DQombmJzcDsgJm5i
c3A7IG90aGVyIGV4Y2l0aW5nIGZlYXR1cmVzIG9mICZxdW90O3YzIFhNTCZxdW90Oy4mbmJzcDsg
Rm9yIGFuIGV4YW1wbGUsIHNlZTxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10c3Z3Zy1kYXRhZ3JhbS1wbHBtdHVkLTE5Lmh0bWwi
IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtdHN2
d2ctZGF0YWdyYW0tcGxwbXR1ZC0xOS5odG1sPC9hPiAuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw
OyBJIHBlcnNvbmFsbHkgaGF2ZW4ndCBkb25lIGFueSB2Mi10by12MyBjb252ZXJzaW9ucyB5ZXQg
KHRvbyBidXN5IHJlYWRpbmcgdG88YnI+DQombmJzcDsgJm5ic3A7IGhhdmUgdGltZSB0byBkbyBt
dWNoIHdyaXRpbmcpLCBidXQgdGhlIEZBUSBlbnRyeSBmb3IgZG9pbmcgc28gaXMgYXQ8YnI+DQom
bmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFs
cy9GQVEteG1sMnJmY3YzLi5odG1sI25hbWUtaG93LWRvLWktY29udmVydC1teS14bWwtZmlsIiB0
YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvRkFR
LXhtbDJyZmN2My5odG1sI25hbWUtaG93LWRvLWktY29udmVydC1teS14bWwtZmlsPC9hPjxicj4N
CiZuYnNwOyAmbmJzcDsgLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSG9wZSB0aGF0IGhlbHBz
LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQmVuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3Bh
ZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWlu
IGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9m
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u
IG9yIGRpc2Nsb3N1cmUNCiBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7
IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBt
ZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5r
IHlvdS48L3NwYW4+PC9pPjwvYj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_MWHPR19MB15012AA6CB49DB8818C792B4AEAF0MWHPR19MB1501namp_--


From nobody Mon Apr 27 11:27:21 2020
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 DF8313A0C3F; Mon, 27 Apr 2020 11:27:19 -0700 (PDT)
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: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <158801203979.26415.5550810597232016504@ietfa.amsl.com>
Date: Mon, 27 Apr 2020 11:27:19 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.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: Mon, 27 Apr 2020 18:27:20 -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-07.txt
	Pages           : 19
	Date            : 2020-04-27

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07


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 Mon Apr 27 11:29:37 2020
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 3B72E3A1693 for ; Mon, 27 Apr 2020 11:29:30 -0700 (PDT)
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 2zEGu6Myv03P for ; Mon, 27 Apr 2020 11:29:28 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 F0F643A0C57 for ; Mon, 27 Apr 2020 11:29:25 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id d17so9076331pgo.0 for ; Mon, 27 Apr 2020 11:29:25 -0700 (PDT)
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=9M7O7QSw0Va+3zwNvH8cog3Yq5Jtc0e8/SJVh6Ej12o=; b=bgopsXpkzDUEuz+2rmMnL2z163dJyk3TwWtX5CeOEL8ErkS+E5Ack31wBOZomKhUgu zEx56Gsje89T+PStQnFDE8GnA0GlmU9gesDlSGxRh1V6jCft/oWZc6GtJATCEmPac/qv Z3STvrJqIXjNeKTNI48OjrfIZBKy93tyMHwnyGFNy3OV9WvGzlkI0bgzofECOolt4l8p uegZQoOm5+TINvLod7vp22ZGJCwc/WB3NvARitWOJBchEsqGyjPTM6wpPfQapiqZeAfK 3uTN25Ucu/Y4uIljohaTnhQ9oMD8fTbS1Z5Zki1B82f4ZYMAXdvQh9j8bTv28UYdA0S+ Zw/w==
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=9M7O7QSw0Va+3zwNvH8cog3Yq5Jtc0e8/SJVh6Ej12o=; b=t6nz5iYq0ykjJ1A1W7/YhphAAmU10cCeB/zBm2q/R8j71Crq+1OApwxOL6q7Y42uI3 s844zD5Vo1gE82YV1lL9GwmhKvVDYcgnV7OCFBA14DiKOW2/hyjKvKRgZSIEl4lf+60a j9YjoFKszXF8pjP5srscQYfI/GLGHSLq7ZBX/k/T6jPrgWEuZ6zPaJfhaO5VOERJ9FOe bX5p/KQvmcIbyfuRQyeswQHp3yBV63CNMBEEcUFgLohAlGfvL4vCM6/wAKKKqnUHGXuY EhjAuE1gLVluTpwkwmtWreYeUqHvfoW1bp1TOOi+pspHgHnxnm4dKJk6EQQc94hr+bj9 bJjg==
X-Gm-Message-State: AGi0PuYSAtmbPeeshjmColrXIrAaq4L0NZPcVreD1YRtY0nAxio6Xcgl iZnj2DdcYBnaedO+03tL1VXhOsxSLNCnGY1Zphc48+q3NVMLthg96yw1GANovTzt5mbbjjGY4Yx bR3Px9ha6xS0mjPlqC8aec7oz26gV6rSAPNoI9j3KF56EWNUiRfneZljx2y33O5VrmQ==
X-Google-Smtp-Source: APiQypJf1gH5d2XoFRe+Cd0A+bYKCJwtnYb7iOJtuWj/MyqPjOnCcYtrqTncHvGluhNltRZtjEGKtw==
X-Received: by 2002:a62:3c5:: with SMTP id 188mr24905450pfd.41.1588012164529;  Mon, 27 Apr 2020 11:29:24 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id a2sm12913348pfg.106.2020.04.27.11.29.24 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 11:29:24 -0700 (PDT)
From: Vittorio Bertocci 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.txt
Thread-Index: ATQzODE5SVVygopWvzbdJoJXmDhTisPTEylj
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 27 Apr 2020 18:29:23 +0000
Message-ID: 
References: <158801203979.26415.5550810597232016504@ietfa.amsl.com>
In-Reply-To: <158801203979.26415.5550810597232016504@ietfa.amsl.com>
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] I-D Action: draft-ietf-oauth-access-token-jwt-07.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: Mon, 27 Apr 2020 18:29:36 -0000

RGVhciBhbGwsDQpUaGFua3MgZm9yIGFsbCB0aGUgZmVlZGJhY2sgYXQgdGhlIGxhc3Qgcm91bmQu
IEhlcmXigJlzIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGluY29ycG9yYXRpbmcgeW91ciBz
dWdnZXN0aW9ucy4gTWFpbiBjaGFuZ2VzOg0KDQotQWRkZWQgdGhlIE5vbmUgcHJvaGliaXRpb24g
aW4gc2VjdGlvbiAyLjEgYXMgd2VsbA0KLUluY29ycG9yYXRlZCBsYW5ndWFnZSBzdWdnZXN0aW9u
cyBmcm9tIERvbWluaWNrIChhbmQgZml4ZWQgdGhlIHNwZWxsaW5nIG9mIGhpcyBsYXN0IG5hbWUg
OykpDQotQ2xhcmlmaWVkIGNhc2VzIGluIHdoaWNoIGlkZW50aXR5IGNsYWltcyBtaWdodCBhcHBl
YXIgaW4gYSBKV1QgQVQNCi1WYXJpb3VzIHR5cG9zLCBmb3JtYXR0aW5nIGlzc3VlcyBmaXhlZA0K
DQoNCg0KDQrvu79PbiA0LzI3LzIwLCAxMToyNywgIk9BdXRoIG9uIGJlaGFsZiBvZiBpbnRlcm5l
dC1kcmFmdHNAaWV0Zi5vcmciIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBp
bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJu
ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp
cmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFdlYiBBdXRo
b3JpemF0aW9uIFByb3RvY29sIFdHIG9mIHRoZSBJRVRGLg0KICAgIA0KICAgICAgICAgICAgVGl0
bGUgICAgICAgICAgIDogSlNPTiBXZWIgVG9rZW4gKEpXVCkgUHJvZmlsZSBmb3IgT0F1dGggMi4w
IEFjY2VzcyBUb2tlbnMNCiAgICAgICAgICAgIEF1dGhvciAgICAgICAgICA6IFZpdHRvcmlvIEJl
cnRvY2NpDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtb2F1dGgtYWNjZXNzLXRv
a2VuLWp3dC0wNy50eHQNCiAgICAJUGFnZXMgICAgICAgICAgIDogMTkNCiAgICAJRGF0ZSAgICAg
ICAgICAgIDogMjAyMC0wNC0yNw0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgc3Bl
Y2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJvZmlsZSBmb3IgaXNzdWluZyBPQXV0aCAyLjAgYWNjZXNz
DQogICAgICAgdG9rZW5zIGluIEpTT04gd2ViIHRva2VuIChKV1QpIGZvcm1hdC4gIEF1dGhvcml6
YXRpb24gc2VydmVycyBhbmQNCiAgICAgICByZXNvdXJjZSBzZXJ2ZXJzIGZyb20gZGlmZmVyZW50
IHZlbmRvcnMgY2FuIGxldmVyYWdlIHRoaXMgcHJvZmlsZSB0bw0KICAgICAgIGlzc3VlIGFuZCBj
b25zdW1lIGFjY2VzcyB0b2tlbnMgaW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIuDQogICAgDQogICAg
DQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6
DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1h
Y2Nlc3MtdG9rZW4tand0Lw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp
b25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTA3DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDcNCiAg
ICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6
DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb2F1dGgt
YWNjZXNzLXRva2VuLWp3dC0wNw0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQg
bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N
CiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0
IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp
bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzLw0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQogICAgT0F1dGggbWFpbGluZyBsaXN0DQogICAgT0F1dGhAaWV0
Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQog
ICAgDQo=


From nobody Mon Apr 27 11:43:29 2020
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 E621B3A0CC6 for ; Mon, 27 Apr 2020 11:42:43 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 0m2qMVgM8v33 for ; Mon, 27 Apr 2020 11:42:38 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 EC7803A116D for ; Mon, 27 Apr 2020 11:42:37 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id 198so14768988lfo.7 for ; Mon, 27 Apr 2020 11:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M6qG7Da2Pcmn1PMAw1x25PjBAVwtdi59316k5uCrLYE=; b=eI3ixH+DYYndUHmxAHoj8GN2PsJlFVInsQlYMgp6116XuIFJcK11r+vZNbeyB2XNbi m9qbk0/sNPJhlu4frOdsvstS/L6VRHrRSP6kMUOC2X3cqTBO7HK/12nHqJ7d+lu3LAIf KoO1QeaqF8V0lMdhttKBIkIt0eU9SBHh+8xort4stv2aLNVak3ZACbfY2z/tKcgtlYN0 1yrZEyJfIGmZzhWUHxsOapSQzl+UIkLy7GAS+J5ZYUrsltX797ProqHwWJNVtfI6NVDN m4bt8W+5ZKucq38Kp9p+/IJ0YwPO/dy6xZux05pAR6+WGmzmuZt6JdK/ZNHHFA4aQz1k kFLA==
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=M6qG7Da2Pcmn1PMAw1x25PjBAVwtdi59316k5uCrLYE=; b=Gsc/iSFf1v/dRrusd3w7Wn8NdGiRuvtO6oqp1sGaWOWvua5IpDjg+wgskCQraRWWfe w5V5adjLZS2Sl+jl9Qnxu9q5KgA+oJ+/BJgcPVeGHiWUqSgZlBGJohLerAFyr1PX1e9P Vp96uja6qoGD9uLcNq256MOPLjxiiC7J6r5eC6STi3YaT1TgTYrEP8huW3FbJQkFPu5H L3KuYAAOq5ZUeVJ0CmlGlqr9E/nZ300KmE93IX51jyst95y8/dhm9I5qxjkoXxqyU2eY gc7ofYISw/gwOhP08wytv7tyHSEpLZGY0vYu892xxZnEdqQm3jnQvVwoOs86rNStYHFm +ccQ==
X-Gm-Message-State: AGi0Puagq0R+jQr9JZMnla1ssvDpgueXqHenvYxP1DytBpHwSkJpNzq5 cVSsbEanEh+r8hH/7sKfPk6NymkDq6M0Y3TuG4Ncz6podGdyDacH47dMCaGXUkftXimlxIYLxYE Rp7lK7A3Nej4iPi+Mruw=
X-Google-Smtp-Source: APiQypIVIivWPZP1BohrnRzL0XahgI+8F2q+L2/hy5MN8fj8iezCvxqW7YMRj9OzWui0EWc3Qh/lOnkDJJoTN8ZcrwM=
X-Received: by 2002:ac2:46e5:: with SMTP id q5mr16524425lfo.11.1588012955114;  Mon, 27 Apr 2020 11:42:35 -0700 (PDT)
MIME-Version: 1.0
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>  <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com> 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 27 Apr 2020 12:42:08 -0600
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000016bbc705a44a14f8"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 27 Apr 2020 18:42:45 -0000

--00000000000016bbc705a44a14f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think your proposal hits the right level of granularity and usefulness.
And I'm thrilled that you went ahead and offered up a name.

On Sun, Apr 26, 2020 at 8:58 AM Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn=E2=80=99t this also mean =
it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this a=
s
> the same?
> - Who decides whether PAR and request_uri are required? The client for it=
s
> instances or the AS for the whole deployment?
>
> I=E2=80=99m in favour of coupling enforced PAR use with enforced request_=
uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare force=
d
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs f=
or
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_o=
nly=E2=80=9D of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter =E2=80=9Cpushed_authorization_reques=
ts_only=E2=80=9D
> - It requires this client to use PAR only. The AS won=E2=80=99t accept an=
y
> authorization request containing more than request_uri + client_id for th=
at
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR fo=
r
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
> >> As I think through this, I=E2=80=99m struggling to identify the threat=
s this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different fo=
r
> different clients, and that any given client won=E2=80=99t already know v=
ia other
> means whether or not it needs to use PAR. That means we=E2=80=99re only t=
alking
> about dynamic clients since statically registered clients already have so=
me
> proprietary out-of-band registration mechanism (e.g., a developer console=
).
> >>
> >> As I tried to articulate in the original email and Filip also mentione=
d
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that=E2=80=99s the case then presumably a malicious party could reg=
ister
> their own client that doesn=E2=80=99t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically register=
ed
> client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha=
t attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz reque=
st
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we=E2=80=99re further limited to scenarios where the attacker do=
es not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> =E2=80=94
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
> >>>
> >>> =EF=BB=BF
> >>> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender and
> know the content is safe.
> >>>
> >>>
> >>> I was hoping to get to a rough consensus in support of the idea befor=
e
> coming up with a name that everyone will hate :)
> >>>
> >>> In the meantime, however, name suggestions are of course welcome.
> >>>
> >>>
> >>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> >>> I'm all for that.
> >>>
> >>> I suppose you have already thought of a suitable name? :)
> >>>
> >>> Vladimir
> >>>
> >>> On 14/04/2020 23:08, Brian Campbell wrote:
> >>>> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected=
,
> and (for confidential clients anyway) authenticated authorization request=
.
> >>>>
> >>>> It seems like some of that improved security could be undermined by =
a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Atta=
ck
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.4.1
> for example and email, social media, online forums, etc., are other ways =
a
> user might be tricked into following a maliciously crafted link.
> >>>>
> >>>> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, =
be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter t=
o
> the PAR draft specifically for it. The metadata (and registered extension=
s)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use=
 a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
> >>>>
> >>>> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000016bbc705a44a14f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think your proposal hits the right level of granularity =
and usefulness. And I'm thrilled that you went ahead and offered up a n=
ame. 

On Sun, Apr 26, 2020 at 8:58 AM Torsten Lodderstedt <torsten=3D=
40lod=
derstedt.net@dmarc.ietf.org> wrote:
Hi all, 



I think this topic has several aspects: 

- Is the client required to use PAR only? Doesn=E2=80=99t this also mean it=
 is required to use request_uri only?

- Is there a need to separate those to questions or shall we treat this as =
the same? 

- Who decides whether PAR and request_uri are required? The client for its =
instances or the AS for the whole deployment? 



I=E2=80=99m in favour of coupling enforced PAR use with enforced request_ur=
i use even though it means the setting is useful with PAR only, not with al=
l JAR-based clients.

I think both the client as well as the AS should be able to declare forced =
PAR. If the AS is able to basically turn of traditional authorization reque=
sts, it can consequently utilize the changed protocol properties in terms o=
f security and robustness in its deployment. This means, for example, the A=
S no longer needs to require pre-registered redirect URIs for confidential =
clients. It also means, the AS can use voluminous claims/authorization deta=
ils objects without worrying about fragile long request URLs.=C2=A0 



So here is my proposal:



1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_onl=
y=E2=80=9D of type boolean - It requires any client to use PAR, the AS will=
 refuse to process any authorization request containing parameters other th=
an request_uri + client_id (as required by htt=
ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension request=
 parameters need to be passed via PAR.

2) Add client registration parameter =E2=80=9Cpushed_authorization_requests=
_only=E2=80=9D - It requires this client to use PAR only. The AS won=E2=80=
=99t accept any authorization request containing more than request_uri + cl=
ient_id for that particular client. 



What are your thoughts?



best regards,

Torsten. 



> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <vladimir@connect2id.com> wr=
ote:

> 

> In a off-list conversation Torsten floated the idea of letting confide=
ntial PAR-only clients register without a redirect_uris and having this &qu=
ot;PAR only" parameter will enable that.

> 

> A "PAR only" parameter will also prevent client developers f=
rom accidentally making plain authz requests (for clients that rely on PAR =
for the extra security).

> 

> Vladimir

> 

> On 16/04/2020 18:39, Brian Campbell wrote:

>> 

>> 

>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle <ric=
hanna=3D40=
amazon.com@dmarc.ietf.org> wrote:

>> As I think through this, I=E2=80=99m struggling to identify the th=
reats this actually helps mitigate.

>> 

>> A client metadata parameter implies that the value may be differen=
t for different clients, and that any given client won=E2=80=99t already kn=
ow via other means whether or not it needs to use PAR. That means we=E2=80=
=99re only talking about dynamic clients since statically registered client=
s already have some proprietary out-of-band registration mechanism (e.g., a=
 developer console).

>> 

>> As I tried to articulate in the original email and Filip also ment=
ioned in a different fork of this email thread, defining metadata can be be=
neficial even when it's not used dynamically at runtime. So we're n=
ot only talking about dynamic clients.

>> 

>>=C2=A0 

>> 

>> A client metadata parameter also implies that the AS allows some c=
lients to make non-PAR requests (otherwise it would be an AS metadata param=
eter).

>> 

>> A per client setting seems necessary for existing ASs to roll out =
PAR support over time or just generally in support of diverse client capabi=
lities and requirements. 

>> 

>>=C2=A0 

>> If that=E2=80=99s the case then presumably a malicious party could=
 register their own client that doesn=E2=80=99t use PAR.

>> 

>> So it seems to me that the only scenario that this parameter would=
 protect against is a malicious party impersonating a dynamically registere=
d client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha=
t attack the attacker uses its own client.

>> 

>> This client metadata parameter is meant to be something that would=
 prevent a malicious actor from controlling the content of the authz reques=
t parameters, which could be done by crafting the link and tricking a user =
into following it. I mentioned mix-up as an example because the first varia=
nt of it desribed at ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 does something along those lines. 

>> 

>>=C2=A0 

>> 

>> If a client can do PAR, then it can do authorization code grant an=
d PKCE, so we=E2=80=99re further limited to scenarios where the attacker do=
es not need to be able to redeem the authorization code themselves. What th=
reats fall into this category?

>> 

>> =E2=80=94

>> Annabelle Backman (she/her)

>> AWS Identity

>> 

>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell <bcampbell=3D40ping=
identity.com@dmarc.ietf.org> wrote:

>>> 

>>> =EF=BB=BF

>>> CAUTION: This email originated from outside of the organizatio=
n. Do not click links or open attachments unless you can confirm the sender=
 and know the content is safe.

>>> 

>>> 

>>> I was hoping to get to a rough consensus in support of the ide=
a before coming up with a name that everyone will hate :) 

>>> 

>>> In the meantime, however, name suggestions are of course welco=
me. 

>>> 

>>> 

>>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <vladimir@connect2id.c=
om> wrote:

>>> I'm all for that.

>>> 

>>> I suppose you have already thought of a suitable name? :)

>>> 

>>> Vladimir

>>> 

>>> On 14/04/2020 23:08, Brian Campbell wrote:

>>>> Using PAR can facilitate improved security by giving clien=
ts a (relatively) simple means for sending a confidential, integrity protec=
ted, and (for confidential clients anyway) authenticated authorization requ=
est.

>>>> 

>>>> It seems like some of that improved security could be unde=
rmined by a malicious actor somehow getting a user to navigate to a URL of =
a regular old parameterized authorization request. One variation of the Mix=
-Up Attack does this ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 for example and email, social media, online forums, etc., are other wa=
ys a user might be tricked into following a maliciously crafted link. 

>>>> 

>>>> Following from that it seems logical that an authorization=
 server might want to restrict some clients from sending a regular paramete=
rized authorization request and instead require use of the PAR endpoint to =
initiate an authorization request. Something like this could, of course, be=
 implemented as custom policy or configuration in any AS. But I'm think=
ing it might be common enough to warrant adding a client metadata parameter=
 to the PAR draft specifically for it. The metadata (and registered extensi=
ons) defined by Dynamic Client Registration [RFC7591] has come to imply a g=
eneral data model and expected associated behaviors for clients that is use=
ful for authorization server implementations, even when the Dynamic Client =
Registration Protocol isn't directly in play. This particular situation=
 seems like a good potential candidate for a new such client metadata param=
eter that would indicate that the given client can only use a request_uri v=
alue obtained from the PAR endpoint to initiate an authorization request. A=
nd that a regular old fashioned authorization request from the given client=
 would result in an error. 

>>>> 

>>>> Do the folks of this fine WG think something like this wou=
ld be a worthwhile addition to the PAR draft?

>>>> 

>>>> 

>>>> 

>>>> 

>>>> 

>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia=
l and privileged material for the sole use of the intended recipient(s). An=
y review, use, distribution or disclosure by others is strictly prohibited.=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you. 

>>>> 

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> 

>>>> OAuth@=
ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oa=
uth

>>> 

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

>>> 

>>> CONFIDENTIALITY NOTICE: This email may contain confidential an=
d privileged material for the sole use of the intended recipient(s). Any re=
view, use, distribution or disclosure by others is strictly prohibited..=C2=
=A0 If you have received this communication in error, please notify the sen=
der immediately by e-mail and delete the message and any file attachments f=
rom your computer. Thank you.

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> 

> _______________________________________________

> 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






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000016bbc705a44a14f8--


From nobody Mon Apr 27 11:57:05 2020
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 BF2263A18BD for ; Mon, 27 Apr 2020 11:57:03 -0700 (PDT)
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=pingidentity.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 XS2w-y_Hd25q for ; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 64E733A18B8 for ; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id u6so18746162ljl.6 for ; Mon, 27 Apr 2020 11:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AElps0yRj1e0kBihiZ0fDAn6ZxYxwT5YS5CbqktpLNA=; b=Hx7FDO1YJDCS8u8pSOZ6bXJyNEQumP0L3cGGhoLM26x03lc6+osDFXWyZfNC0t0DeN kva4S6QNd4jkdKz/LlflLGruUoD+2+wlw3vjtSa8kEKcTRSjyjHvfnsouj5cFJ4fKG4O dqBWeHZwkdrDk+supms/gp25JM1bVOy2JK6UYRE+868NkB2NvHbgk+dkDWBcfwTBr/7S aQPZHQC4+zLW/m775JmP0pCnJ/Me1tn0H25Bp/rNswE0aglcSf9YWt691iGsRpwoAQBu l+jPVZnuk1lFZHT7eCIPjMOFTy6rnRadri0xYPkZGk/ThfPJl/7V76A3yV0tyvHe6XwX F+Dw==
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=AElps0yRj1e0kBihiZ0fDAn6ZxYxwT5YS5CbqktpLNA=; b=PsD2Uk30dixJdDPvMeeS/EHRnpfC+e8O6N5MdRf/zxLPpikYAm9iDnBAV1JHSMvnT2 85HJZTMQ4DlP2ZIKpekN8zMRXo8q3wSahqPmQ7XsP8rM18CnNBZi+5kjjvpxxo5snqH5 ApP0Q34aebnlTfGuRJs4tmTopnEnx3pQ4MwXJUy85J807o778snFmE+quSRBz0TyCkK4 WvFj92USmTk8Nm/+F2IrYCEZM9EXJ2QTICwomtrrX1ncsHLnoFpih8f+bekA8pr70nTL kz5Kxh8zauiceHcHsJ/12wT3RYL+jf/VUXdBouugdVgbWuxx38OJSD6DbBaQ1O3mcCCd f/7Q==
X-Gm-Message-State: AGi0PuZs7gNGffkrb85RKa+F1KMbW2I6b+AqgHcBzLRy4agugpShjQIr t2NNQbUnYZWsG0z4+iVfb52N2ANkBhrlQbp9dWh6xISaS8wVHgai89hzlVihSmdtQOfMNHbx/2F ngUx7KH0VNSwV5w==
X-Google-Smtp-Source: APiQypId/R22VIRRY8n9WYpUirXbdjD0SIxDG8jFMGU6oho8ejWI3hzC0Tn0XwkRvBr/PgJxGG7Ji98wn0n83BioBqw=
X-Received: by 2002:a05:651c:505:: with SMTP id o5mr8864482ljp.0.1588013819423;  Mon, 27 Apr 2020 11:56:59 -0700 (PDT)
MIME-Version: 1.0
References: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net> 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 27 Apr 2020 12:56:33 -0600
Message-ID: 
To: Filip Skokan 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="0000000000009b08a805a44a47c0"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
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, 27 Apr 2020 18:57:04 -0000

--0000000000009b08a805a44a47c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

While there are certainly different permutations and contexts of use that
could be imagine, I tend to agree with Filip here in not seeing a strong
need to define new PAR specific metadata around signing/encryption of the
request object.

On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote:

> Considering there's going to be a setting that forces clients to use PAR
> (other mailinglist thread), then we should rely on the existing
> `request_object_signing_alg` presence to indicate a Request Object must b=
e
> used (as suggested by this upcoming OIDC Core errata
> ),
> regardless of it being PAR or JAR. I don't see the need for a PAR specifi=
c
> metadata, for one - implementations wouldn't be easily able to re-use of
> existing pipelines, two - yes the contexts differ but do you think client=
s
> will be using both channels at the same time? And even if so, the Request
> Object is the same therefore its applicable to both channels the same.
>
> Best,
> *Filip Skokan*
>
>
> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> this is one of the topics we quickly flipped through in the virtual
>> meeting last week.
>>
>> I see the following open questions:
>> - Can the client require its instances to use request objects only.
>> - Are there further requirements on the properties of these objects?
>> Signed only, Signed and encrypted, algorithms?
>> - Can an AS require ALL clients to use request objects only?
>> - Further requirements here as well?
>> - Is this tied to PAR or relevant for JAR as well?
>>
>> In my opinion, client as well as AS should be able to control enforced
>> use of request objects.
>>
>> I could imagine the setting for JAR request objects (=E2=80=9Crequest" p=
arameter)
>> and request objects in the PAR context differ, as the first case goes
>> through the user=E2=80=99s browser whereas the PAR case goes direct from=
 client to
>> AS via a TLS protected channel. I therefore feel the settings should be =
PAR
>> specific.
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>> _______________________________________________
>> 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
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000009b08a805a44a47c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


While there are certainly different permutations and conte=
xts of use that could be imagine, I tend to agree with Filip here in not se=
eing a strong need to define new PAR specific metadata around signing/encry=
ption of the request object. 

On Mon, Apr 27, 2020 at 2:35 AM Filip Skok=
an <panva.ip@gma=
il.com> wrote:
Considering there's going to be a setting t=
hat forces clients to use PAR (other mailinglist thread), then we should re=
ly on the existing `request_object_signing_alg` presence to indicate a Requ=
est Object must be used (as suggested by this upcoming OIDC Core errata), regardless of it being PAR or =
JAR. I don't see the need for a PAR specific metadata, for one - implem=
entations wouldn't be easily able to re-use of existing pipelines, two =
- yes the contexts differ but do you think clients will be using both chann=
els at the=C2=A0same time? And even if so, the Request Object is the same t=
herefore its applicable to both channels the same.

<=
div>
Best,
Filip Skokan


=

On Sun, 26=
 Apr 2020 at 17:09, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ie=
tf.org> wrote:
Hi all, 



this is one of the topics we quickly flipped through in the virtual meeting=
 last week. 



I see the following open questions:

- Can the client require its instances to use request objects only.

- Are there further requirements on the properties of these objects? Signed=
 only, Signed and encrypted, algorithms? 

- Can an AS require ALL clients to use request objects only? 

- Further requirements here as well? 

- Is this tied to PAR or relevant for JAR as well? 



In my opinion, client as well as AS should be able to control enforced use =
of request objects. 



I could imagine the setting for JAR request objects (=E2=80=9Crequest"=
 parameter) and request objects in the PAR context differ, as the first cas=
e goes through the user=E2=80=99s browser whereas the PAR case goes direct =
from client to AS via a TLS protected channel. I therefore feel the setting=
s should be PAR specific. 



What do you think?



best regards,

Torsten. 

_______________________________________________

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





<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000009b08a805a44a47c0--


From nobody Mon Apr 27 11:58:18 2020
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 BE3A03A1932 for ; Mon, 27 Apr 2020 11:58:11 -0700 (PDT)
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 Ni5n738e3SAh for ; Mon, 27 Apr 2020 11:58:08 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 532FB3A1912 for ; Mon, 27 Apr 2020 11:58:07 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id d197so5589077ybh.6 for ; Mon, 27 Apr 2020 11:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D6O8XRJpcPmJGKd6bTSWaemEtzzj/LgjEUIybsWH0eY=; b=Z8pQGfbwbfZMKXfqRBzyH3wjWLj2cZzGKEW6Iw7kEuS80StHnG0NinpUXC0Epll2QG 4oHhpF2GsB2TOJPzP6UZzvhoIeevYmD5sMsVTM99pUj39FYcisSrmog2vY9VgLb4NaKq YDQ0m0TuHy+De20VVHtH3Mw1olWoBCes6gSJLjGPUhsGl3SqX0pkP1vbqh3Io7h57ddz aSuQCs+A4lNVkQ0EmODxs2s54xTI3jwi1i3GJfmP2AQorlTjyTIcnkfwJYKGtSj++2Ba Z1vUzbQzwCGxeCuVpG86+KU2j3mT/SYXJtq6JfUIiD0sW9lJbTZ0F14oHviTRcYfN9El ZJqw==
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=D6O8XRJpcPmJGKd6bTSWaemEtzzj/LgjEUIybsWH0eY=; b=BMhAH2A+Cj+I+qvhdQjGD1A5W56ADbAOmnXIvLHdpZKpmCPVlUHPBgK3AdNyF7BB+Y ELU7uM5XjncP2PP2gGpScLRLRHSTzloRUcK/gSjvGKCYjQVR+siWULm55+NKVl4WMv7T JF6V9dDTXxLBgYYt39yk/YgyW6xCb3Gy061NBMrXy5ibLEHhFaryeEo9GR0NCBBBRsF3 +KCXOG/w7vlsxMaLMpGHU0TuUc08UzMGaQHefCEocKJG0/9KMNw0zBLKodLjFUKwXABh zCmI7taYreewIYydIutQcnpaShJ3Cp2VsZWswASGWYYtfe1+uKGf2c1sBPrSS94d6wCf VZrw==
X-Gm-Message-State: AGi0PuZ7WeOHOs75JgaPVhN8q1ajFQrnebQfjSGtweecUVikFD9iZjWn v2zmKOpARTu7HjtLgXmIy9ujm/z/zlXe5J2bsg==
X-Google-Smtp-Source: APiQypLQBeM4viA+3F0piQrAouoDhe3j0WEmk0cuVcJE4z5TEtusFDeYTE/z7PDHE54t1vj5/Irv8V0gWrjJLy4TQjA=
X-Received: by 2002:a25:13c1:: with SMTP id 184mr35858698ybt.259.1588013886088;  Mon, 27 Apr 2020 11:58:06 -0700 (PDT)
MIME-Version: 1.0
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>  <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com> 
In-Reply-To: 
From: Filip Skokan 
Date: Mon, 27 Apr 2020 20:57:29 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000942a6805a44a4b5a"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 27 Apr 2020 18:58:17 -0000

--000000000000942a6805a44a4b5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Alternatively, `require_pushed_authorization_requests`. Since we already
have the `*require_*request_uri_registration` server and `*require_*
auth_time` client metadata properties.

WDYT?

S pozdravem,
*Filip Skokan*


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn=E2=80=99t this also mean =
it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this a=
s
> the same?
> - Who decides whether PAR and request_uri are required? The client for it=
s
> instances or the AS for the whole deployment?
>
> I=E2=80=99m in favour of coupling enforced PAR use with enforced request_=
uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare force=
d
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs f=
or
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_o=
nly=E2=80=9D of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter =E2=80=9Cpushed_authorization_reques=
ts_only=E2=80=9D
> - It requires this client to use PAR only. The AS won=E2=80=99t accept an=
y
> authorization request containing more than request_uri + client_id for th=
at
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR fo=
r
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon.com@dmarc.ietf.org> wrote:
> >> As I think through this, I=E2=80=99m struggling to identify the threat=
s this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different fo=
r
> different clients, and that any given client won=E2=80=99t already know v=
ia other
> means whether or not it needs to use PAR. That means we=E2=80=99re only t=
alking
> about dynamic clients since statically registered clients already have so=
me
> proprietary out-of-band registration mechanism (e.g., a developer console=
).
> >>
> >> As I tried to articulate in the original email and Filip also mentione=
d
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that=E2=80=99s the case then presumably a malicious party could reg=
ister
> their own client that doesn=E2=80=99t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically register=
ed
> client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha=
t attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz reque=
st
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we=E2=80=99re further limited to scenarios where the attacker do=
es not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> =E2=80=94
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
> >>>
> >>> =EF=BB=BF
> >>> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender and
> know the content is safe.
> >>>
> >>>
> >>> I was hoping to get to a rough consensus in support of the idea befor=
e
> coming up with a name that everyone will hate :)
> >>>
> >>> In the meantime, however, name suggestions are of course welcome.
> >>>
> >>>
> >>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
> >>> I'm all for that.
> >>>
> >>> I suppose you have already thought of a suitable name? :)
> >>>
> >>> Vladimir
> >>>
> >>> On 14/04/2020 23:08, Brian Campbell wrote:
> >>>> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected=
,
> and (for confidential clients anyway) authenticated authorization request=
.
> >>>>
> >>>> It seems like some of that improved security could be undermined by =
a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Atta=
ck
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4=
.4.1
> for example and email, social media, online forums, etc., are other ways =
a
> user might be tricked into following a maliciously crafted link.
> >>>>
> >>>> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, =
be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter t=
o
> the PAR draft specifically for it. The metadata (and registered extension=
s)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use=
 a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
> >>>>
> >>>> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.=
.
> If you have received this communication in error, please notify the sende=
r
> immediately by e-mail and delete the message and any file attachments fro=
m
> your computer. Thank you.
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000942a6805a44a4b5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Alternatively, `require_pushed_authori=
zation_requests`. Since we already have the `require_request_uri_registration` server and `require_auth_time` client metadata propert=
ies.

WDYT?

S pozdravem,
Filip Skokan


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt <tors=
ten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all, 



I think this topic has several aspects: 

- Is the client required to use PAR only? Doesn=E2=80=99t this also mean it=
 is required to use request_uri only?

- Is there a need to separate those to questions or shall we treat this as =
the same? 

- Who decides whether PAR and request_uri are required? The client for its =
instances or the AS for the whole deployment? 



I=E2=80=99m in favour of coupling enforced PAR use with enforced request_ur=
i use even though it means the setting is useful with PAR only, not with al=
l JAR-based clients.

I think both the client as well as the AS should be able to declare forced =
PAR. If the AS is able to basically turn of traditional authorization reque=
sts, it can consequently utilize the changed protocol properties in terms o=
f security and robustness in its deployment. This means, for example, the A=
S no longer needs to require pre-registered redirect URIs for confidential =
clients. It also means, the AS can use voluminous claims/authorization deta=
ils objects without worrying about fragile long request URLs.=C2=A0 



So here is my proposal:



1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_onl=
y=E2=80=9D of type boolean - It requires any client to use PAR, the AS will=
 refuse to process any authorization request containing parameters other th=
an request_uri + client_id (as required by htt=
ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension request=
 parameters need to be passed via PAR.

2) Add client registration parameter =E2=80=9Cpushed_authorization_requests=
_only=E2=80=9D - It requires this client to use PAR only. The AS won=E2=80=
=99t accept any authorization request containing more than request_uri + cl=
ient_id for that particular client. 



What are your thoughts?



best regards,

Torsten. 



> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <vladimir@connect2id.com> wr=
ote:

> 

> In a off-list conversation Torsten floated the idea of letting confide=
ntial PAR-only clients register without a redirect_uris and having this &qu=
ot;PAR only" parameter will enable that.

> 

> A "PAR only" parameter will also prevent client developers f=
rom accidentally making plain authz requests (for clients that rely on PAR =
for the extra security).

> 

> Vladimir

> 

> On 16/04/2020 18:39, Brian Campbell wrote:

>> 

>> 

>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle <ric=
hanna=3D40=
amazon.com@dmarc.ietf.org> wrote:

>> As I think through this, I=E2=80=99m struggling to identify the th=
reats this actually helps mitigate.

>> 

>> A client metadata parameter implies that the value may be differen=
t for different clients, and that any given client won=E2=80=99t already kn=
ow via other means whether or not it needs to use PAR. That means we=E2=80=
=99re only talking about dynamic clients since statically registered client=
s already have some proprietary out-of-band registration mechanism (e.g., a=
 developer console).

>> 

>> As I tried to articulate in the original email and Filip also ment=
ioned in a different fork of this email thread, defining metadata can be be=
neficial even when it's not used dynamically at runtime. So we're n=
ot only talking about dynamic clients.

>> 

>>=C2=A0 

>> 

>> A client metadata parameter also implies that the AS allows some c=
lients to make non-PAR requests (otherwise it would be an AS metadata param=
eter).

>> 

>> A per client setting seems necessary for existing ASs to roll out =
PAR support over time or just generally in support of diverse client capabi=
lities and requirements. 

>> 

>>=C2=A0 

>> If that=E2=80=99s the case then presumably a malicious party could=
 register their own client that doesn=E2=80=99t use PAR.

>> 

>> So it seems to me that the only scenario that this parameter would=
 protect against is a malicious party impersonating a dynamically registere=
d client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha=
t attack the attacker uses its own client.

>> 

>> This client metadata parameter is meant to be something that would=
 prevent a malicious actor from controlling the content of the authz reques=
t parameters, which could be done by crafting the link and tricking a user =
into following it. I mentioned mix-up as an example because the first varia=
nt of it desribed at ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 does something along those lines. 

>> 

>>=C2=A0 

>> 

>> If a client can do PAR, then it can do authorization code grant an=
d PKCE, so we=E2=80=99re further limited to scenarios where the attacker do=
es not need to be able to redeem the authorization code themselves. What th=
reats fall into this category?

>> 

>> =E2=80=94

>> Annabelle Backman (she/her)

>> AWS Identity

>> 

>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell <bcampbell=3D40ping=
identity.com@dmarc.ietf.org> wrote:

>>> 

>>> =EF=BB=BF

>>> CAUTION: This email originated from outside of the organizatio=
n. Do not click links or open attachments unless you can confirm the sender=
 and know the content is safe.

>>> 

>>> 

>>> I was hoping to get to a rough consensus in support of the ide=
a before coming up with a name that everyone will hate :) 

>>> 

>>> In the meantime, however, name suggestions are of course welco=
me. 

>>> 

>>> 

>>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <vladimir@connect2id.c=
om> wrote:

>>> I'm all for that.

>>> 

>>> I suppose you have already thought of a suitable name? :)

>>> 

>>> Vladimir

>>> 

>>> On 14/04/2020 23:08, Brian Campbell wrote:

>>>> Using PAR can facilitate improved security by giving clien=
ts a (relatively) simple means for sending a confidential, integrity protec=
ted, and (for confidential clients anyway) authenticated authorization requ=
est.

>>>> 

>>>> It seems like some of that improved security could be unde=
rmined by a malicious actor somehow getting a user to navigate to a URL of =
a regular old parameterized authorization request. One variation of the Mix=
-Up Attack does this ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 for example and email, social media, online forums, etc., are other wa=
ys a user might be tricked into following a maliciously crafted link. 

>>>> 

>>>> Following from that it seems logical that an authorization=
 server might want to restrict some clients from sending a regular paramete=
rized authorization request and instead require use of the PAR endpoint to =
initiate an authorization request. Something like this could, of course, be=
 implemented as custom policy or configuration in any AS. But I'm think=
ing it might be common enough to warrant adding a client metadata parameter=
 to the PAR draft specifically for it. The metadata (and registered extensi=
ons) defined by Dynamic Client Registration [RFC7591] has come to imply a g=
eneral data model and expected associated behaviors for clients that is use=
ful for authorization server implementations, even when the Dynamic Client =
Registration Protocol isn't directly in play. This particular situation=
 seems like a good potential candidate for a new such client metadata param=
eter that would indicate that the given client can only use a request_uri v=
alue obtained from the PAR endpoint to initiate an authorization request. A=
nd that a regular old fashioned authorization request from the given client=
 would result in an error. 

>>>> 

>>>> Do the folks of this fine WG think something like this wou=
ld be a worthwhile addition to the PAR draft?

>>>> 

>>>> 

>>>> 

>>>> 

>>>> 

>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia=
l and privileged material for the sole use of the intended recipient(s). An=
y review, use, distribution or disclosure by others is strictly prohibited.=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you. 

>>>> 

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> 

>>>> OAuth@=
ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oa=
uth

>>> 

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

>>> 

>>> CONFIDENTIALITY NOTICE: This email may contain confidential an=
d privileged material for the sole use of the intended recipient(s). Any re=
view, use, distribution or disclosure by others is strictly prohibited..=C2=
=A0 If you have received this communication in error, please notify the sen=
der immediately by e-mail and delete the message and any file attachments f=
rom your computer. Thank you.

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> 

> _______________________________________________

> 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




--000000000000942a6805a44a4b5a--


From nobody Mon Apr 27 12:06:48 2020
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 CA1133A19AE for ; Mon, 27 Apr 2020 12:06:45 -0700 (PDT)
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=pingidentity.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 DkEdwhyNt4wJ for ; Mon, 27 Apr 2020 12:06:42 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 1D3CB3A19CD for ; Mon, 27 Apr 2020 12:06:42 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id w20so18837307ljj.0 for ; Mon, 27 Apr 2020 12:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kCxh/iGq8I56n6v61u4XILDZyr7NyrwYeo8WdNtbRB4=; b=aGDgHwPr/YgsoaOE37zVRQchAVbCE4MsGTCCz+Ob3gtGmrm8nNHVtrSLU/dKRFKmR7 RnPwYPDcBNiMbeUXargfgTM/WMzbWTpZ4aHv6LkdS02NCFN3tBnPBpOYouO2YMbu6bJx VcAMPf6lXhLGTSOKx16AtFZWQkKXCc55NkR/1UP00ujiDDKuXk5iwK7kg1Ci1wacz3Ju g0S10/0rcsGJ5bmXgm4gQ0Qilfhu7usmtsFMr2h9i+mQaPaTyP4UKy4WhDRC27axfSE7 oSPBFRqaLCChSLImZ1yxlv0WnBnLtnuaxYy1GixJu4ymL/4bxdylSCKF0tlo+eYtnBpx CcEg==
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=kCxh/iGq8I56n6v61u4XILDZyr7NyrwYeo8WdNtbRB4=; b=Dh1t8Gxr2SpyOSCS5jhil0Es9KIpELOepOc4VhQcNualvSWLGkAOagvXpr/Pt/Eb6c swd8/Z4Hz0WBUz7DwiPMEKImBT5cs8AhaMh4ig1EoMsVLDfe8yxZOyJx+J+tuHpb3RNt XQynwxYiuSKIfkStkId0z6Cfqhw7B7gtPTuxs3qyGw02OAMecmycpx3WRcxMQdpPKQTU qQSDY8MIq886b7t92a5KvjHydEyZg1ZO4GAHOy9q4j7VPOiQ02xPxU84Vcy0o1Ebi+Ob dc7uvE/L1Q9PLzUkx6/GKl7a1cFBCToh9JGJwNmAeuOWgwvzpW8tTiXugpwiDUR9blDH tDkg==
X-Gm-Message-State: AGi0PuayYbILZNX2JirBt/2SwH2cTHQov6YC+2FqC99l9/2EmwZp+FMO Ob1xXUEnmYVdOYUiYCaXFpBA/00JQrBifX7ENe42/Ko+aKo3m2EHsHKvasNPQg7/YUtNo+kMmLK j4+XaZNCTGjVzLEHNVU0=
X-Google-Smtp-Source: APiQypJMuLl6ZirTIKN1ZJfs8Vc2sItWYhX+VX85xZWTbyp85c+rnodinC1lg9p8JA0kYY0T99WK1th65wTUcQ+2uso=
X-Received: by 2002:a2e:3813:: with SMTP id f19mr14799530lja.216.1588014400135;  Mon, 27 Apr 2020 12:06:40 -0700 (PDT)
MIME-Version: 1.0
References: <760B73F1-F31C-4474-8871-28EEBCF45D44@amazon.com>  <2747eeaa-0912-e1b8-e0fa-f9e5177b3e75@connect2id.com>  
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 27 Apr 2020 13:06:13 -0600
Message-ID: 
To: Filip Skokan 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000380ce705a44a6ab3"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR and client metadata
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, 27 Apr 2020 19:06:46 -0000

--000000000000380ce705a44a6ab3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

require_pushed_authorization_requests works for me and is maybe/arguably a
bit better by being more consistent with other names.

On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan  wrote:

> Alternatively, `require_pushed_authorization_requests`. Since we already
> have the `*require_*request_uri_registration` server and `*require_*
> auth_time` client metadata properties.
>
> WDYT?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I think this topic has several aspects:
>> - Is the client required to use PAR only? Doesn=E2=80=99t this also mean=
 it is
>> required to use request_uri only?
>> - Is there a need to separate those to questions or shall we treat this
>> as the same?
>> - Who decides whether PAR and request_uri are required? The client for
>> its instances or the AS for the whole deployment?
>>
>> I=E2=80=99m in favour of coupling enforced PAR use with enforced request=
_uri use
>> even though it means the setting is useful with PAR only, not with all
>> JAR-based clients.
>> I think both the client as well as the AS should be able to declare
>> forced PAR. If the AS is able to basically turn of traditional
>> authorization requests, it can consequently utilize the changed protocol
>> properties in terms of security and robustness in its deployment. This
>> means, for example, the AS no longer needs to require pre-registered
>> redirect URIs for confidential clients. It also means, the AS can use
>> voluminous claims/authorization details objects without worrying about
>> fragile long request URLs.
>>
>> So here is my proposal:
>>
>> 1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_=
only=E2=80=9D of
>> type boolean - It requires any client to use PAR, the AS will refuse to
>> process any authorization request containing parameters other than
>> request_uri + client_id (as required by
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
>> request parameters need to be passed via PAR.
>> 2) Add client registration parameter =E2=80=9Cpushed_authorization_reque=
sts_only=E2=80=9D
>> - It requires this client to use PAR only. The AS won=E2=80=99t accept a=
ny
>> authorization request containing more than request_uri + client_id for t=
hat
>> particular client.
>>
>> What are your thoughts?
>>
>> best regards,
>> Torsten.
>>
>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
>> wrote:
>> >
>> > In a off-list conversation Torsten floated the idea of letting
>> confidential PAR-only clients register without a redirect_uris and havin=
g
>> this "PAR only" parameter will enable that.
>> >
>> > A "PAR only" parameter will also prevent client developers from
>> accidentally making plain authz requests (for clients that rely on PAR f=
or
>> the extra security).
>> >
>> > Vladimir
>> >
>> > On 16/04/2020 18:39, Brian Campbell wrote:
>> >>
>> >>
>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle > 40amazon.com@dmarc.ietf.org> wrote:
>> >> As I think through this, I=E2=80=99m struggling to identify the threa=
ts this
>> actually helps mitigate.
>> >>
>> >> A client metadata parameter implies that the value may be different
>> for different clients, and that any given client won=E2=80=99t already k=
now via
>> other means whether or not it needs to use PAR. That means we=E2=80=99re=
 only
>> talking about dynamic clients since statically registered clients alread=
y
>> have some proprietary out-of-band registration mechanism (e.g., a develo=
per
>> console).
>> >>
>> >> As I tried to articulate in the original email and Filip also
>> mentioned in a different fork of this email thread, defining metadata ca=
n
>> be beneficial even when it's not used dynamically at runtime. So we're n=
ot
>> only talking about dynamic clients.
>> >>
>> >>
>> >>
>> >> A client metadata parameter also implies that the AS allows some
>> clients to make non-PAR requests (otherwise it would be an AS metadata
>> parameter).
>> >>
>> >> A per client setting seems necessary for existing ASs to roll out PAR
>> support over time or just generally in support of diverse client
>> capabilities and requirements.
>> >>
>> >>
>> >> If that=E2=80=99s the case then presumably a malicious party could re=
gister
>> their own client that doesn=E2=80=99t use PAR.
>> >>
>> >> So it seems to me that the only scenario that this parameter would
>> protect against is a malicious party impersonating a dynamically registe=
red
>> client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in th=
at attack
>> the attacker uses its own client.
>> >>
>> >> This client metadata parameter is meant to be something that would
>> prevent a malicious actor from controlling the content of the authz requ=
est
>> parameters, which could be done by crafting the link and tricking a user
>> into following it. I mentioned mix-up as an example because the first
>> variant of it desribed at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
4.4.1
>> does something along those lines.
>> >>
>> >>
>> >>
>> >> If a client can do PAR, then it can do authorization code grant and
>> PKCE, so we=E2=80=99re further limited to scenarios where the attacker d=
oes not
>> need to be able to redeem the authorization code themselves. What threat=
s
>> fall into this category?
>> >>
>> >> =E2=80=94
>> >> Annabelle Backman (she/her)
>> >> AWS Identity
>> >>
>> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote:
>> >>>
>> >>> =EF=BB=BF
>> >>> CAUTION: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender an=
d
>> know the content is safe.
>> >>>
>> >>>
>> >>> I was hoping to get to a rough consensus in support of the idea
>> before coming up with a name that everyone will hate :)
>> >>>
>> >>> In the meantime, however, name suggestions are of course welcome.
>> >>>
>> >>>
>> >>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>> >>> I'm all for that.
>> >>>
>> >>> I suppose you have already thought of a suitable name? :)
>> >>>
>> >>> Vladimir
>> >>>
>> >>> On 14/04/2020 23:08, Brian Campbell wrote:
>> >>>> Using PAR can facilitate improved security by giving clients a
>> (relatively) simple means for sending a confidential, integrity protecte=
d,
>> and (for confidential clients anyway) authenticated authorization reques=
t.
>> >>>>
>> >>>> It seems like some of that improved security could be undermined by
>> a malicious actor somehow getting a user to navigate to a URL of a regul=
ar
>> old parameterized authorization request. One variation of the Mix-Up Att=
ack
>> does this
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-=
4.4.1
>> for example and email, social media, online forums, etc., are other ways=
 a
>> user might be tricked into following a maliciously crafted link.
>> >>>>
>> >>>> Following from that it seems logical that an authorization server
>> might want to restrict some clients from sending a regular parameterized
>> authorization request and instead require use of the PAR endpoint to
>> initiate an authorization request. Something like this could, of course,=
 be
>> implemented as custom policy or configuration in any AS. But I'm thinkin=
g
>> it might be common enough to warrant adding a client metadata parameter =
to
>> the PAR draft specifically for it. The metadata (and registered extensio=
ns)
>> defined by Dynamic Client Registration [RFC7591] has come to imply a
>> general data model and expected associated behaviors for clients that is
>> useful for authorization server implementations, even when the Dynamic
>> Client Registration Protocol isn't directly in play. This particular
>> situation seems like a good potential candidate for a new such client
>> metadata parameter that would indicate that the given client can only us=
e a
>> request_uri value obtained from the PAR endpoint to initiate an
>> authorization request. And that a regular old fashioned authorization
>> request from the given client would result in an error.
>> >>>>
>> >>>> Do the folks of this fine WG think something like this would be a
>> worthwhile addition to the PAR draft?
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any f=
ile
>> attachments from your computer. Thank you.
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >>>
>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited=
..
>> If you have received this communication in error, please notify the send=
er
>> immediately by e-mail and delete the message and any file attachments fr=
om
>> your computer. Thank you.
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> OAuth@ietf..org 
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000380ce705a44a6ab3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


require_pushed_authorization_requests works for me and is =
maybe/arguably a bit better by being more consistent with other names. =C2=
=A0 

On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan <panva.ip@gmail.com> wrote:
Alternatively,=
 `require_=
pushed_authorization_requests`. Since we al=
ready have the `require_request_uri_=
registration` server and `require_au=
th_time` client metadata properties.

WDYT?<=
/div>
S pozdravem,
Filip Skoka=
n


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt <=
torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi all, 



I think this topic has several aspects: 

- Is the client required to use PAR only? Doesn=E2=80=99t this also mean it=
 is required to use request_uri only?

- Is there a need to separate those to questions or shall we treat this as =
the same? 

- Who decides whether PAR and request_uri are required? The client for its =
instances or the AS for the whole deployment? 



I=E2=80=99m in favour of coupling enforced PAR use with enforced request_ur=
i use even though it means the setting is useful with PAR only, not with al=
l JAR-based clients.

I think both the client as well as the AS should be able to declare forced =
PAR. If the AS is able to basically turn of traditional authorization reque=
sts, it can consequently utilize the changed protocol properties in terms o=
f security and robustness in its deployment. This means, for example, the A=
S no longer needs to require pre-registered redirect URIs for confidential =
clients. It also means, the AS can use voluminous claims/authorization deta=
ils objects without worrying about fragile long request URLs.=C2=A0 



So here is my proposal:



1) Add server metadata parameter =E2=80=9Cpushed_authorization_requests_onl=
y=E2=80=9D of type boolean - It requires any client to use PAR, the AS will=
 refuse to process any authorization request containing parameters other th=
an request_uri + client_id (as required by htt=
ps://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension request=
 parameters need to be passed via PAR.

2) Add client registration parameter =E2=80=9Cpushed_authorization_requests=
_only=E2=80=9D - It requires this client to use PAR only. The AS won=E2=80=
=99t accept any authorization request containing more than request_uri + cl=
ient_id for that particular client. 



What are your thoughts?



best regards,

Torsten. 



> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <vladimir@connect2id.com> wr=
ote:

> 

> In a off-list conversation Torsten floated the idea of letting confide=
ntial PAR-only clients register without a redirect_uris and having this &qu=
ot;PAR only" parameter will enable that.

> 

> A "PAR only" parameter will also prevent client developers f=
rom accidentally making plain authz requests (for clients that rely on PAR =
for the extra security).

> 

> Vladimir

> 

> On 16/04/2020 18:39, Brian Campbell wrote:

>> 

>> 

>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle <ric=
hanna=3D40=
amazon.com@dmarc.ietf.org> wrote:

>> As I think through this, I=E2=80=99m struggling to identify the th=
reats this actually helps mitigate.

>> 

>> A client metadata parameter implies that the value may be differen=
t for different clients, and that any given client won=E2=80=99t already kn=
ow via other means whether or not it needs to use PAR. That means we=E2=80=
=99re only talking about dynamic clients since statically registered client=
s already have some proprietary out-of-band registration mechanism (e.g., a=
 developer console).

>> 

>> As I tried to articulate in the original email and Filip also ment=
ioned in a different fork of this email thread, defining metadata can be be=
neficial even when it's not used dynamically at runtime. So we're n=
ot only talking about dynamic clients.

>> 

>>=C2=A0 

>> 

>> A client metadata parameter also implies that the AS allows some c=
lients to make non-PAR requests (otherwise it would be an AS metadata param=
eter).

>> 

>> A per client setting seems necessary for existing ASs to roll out =
PAR support over time or just generally in support of diverse client capabi=
lities and requirements. 

>> 

>>=C2=A0 

>> If that=E2=80=99s the case then presumably a malicious party could=
 register their own client that doesn=E2=80=99t use PAR.

>> 

>> So it seems to me that the only scenario that this parameter would=
 protect against is a malicious party impersonating a dynamically registere=
d client that uses PAR. That wouldn=E2=80=99t apply to Mix-Up, since in tha=
t attack the attacker uses its own client.

>> 

>> This client metadata parameter is meant to be something that would=
 prevent a malicious actor from controlling the content of the authz reques=
t parameters, which could be done by crafting the link and tricking a user =
into following it. I mentioned mix-up as an example because the first varia=
nt of it desribed at ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 does something along those lines. 

>> 

>>=C2=A0 

>> 

>> If a client can do PAR, then it can do authorization code grant an=
d PKCE, so we=E2=80=99re further limited to scenarios where the attacker do=
es not need to be able to redeem the authorization code themselves. What th=
reats fall into this category?

>> 

>> =E2=80=94

>> Annabelle Backman (she/her)

>> AWS Identity

>> 

>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell <bcampbell=3D40ping=
identity.com@dmarc.ietf.org> wrote:

>>> 

>>> =EF=BB=BF

>>> CAUTION: This email originated from outside of the organizatio=
n. Do not click links or open attachments unless you can confirm the sender=
 and know the content is safe.

>>> 

>>> 

>>> I was hoping to get to a rough consensus in support of the ide=
a before coming up with a name that everyone will hate :) 

>>> 

>>> In the meantime, however, name suggestions are of course welco=
me. 

>>> 

>>> 

>>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <vladimir@connect2id.c=
om> wrote:

>>> I'm all for that.

>>> 

>>> I suppose you have already thought of a suitable name? :)

>>> 

>>> Vladimir

>>> 

>>> On 14/04/2020 23:08, Brian Campbell wrote:

>>>> Using PAR can facilitate improved security by giving clien=
ts a (relatively) simple means for sending a confidential, integrity protec=
ted, and (for confidential clients anyway) authenticated authorization requ=
est.

>>>> 

>>>> It seems like some of that improved security could be unde=
rmined by a malicious actor somehow getting a user to navigate to a URL of =
a regular old parameterized authorization request. One variation of the Mix=
-Up Attack does this ht=
tps://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1=
 for example and email, social media, online forums, etc., are other wa=
ys a user might be tricked into following a maliciously crafted link. 

>>>> 

>>>> Following from that it seems logical that an authorization=
 server might want to restrict some clients from sending a regular paramete=
rized authorization request and instead require use of the PAR endpoint to =
initiate an authorization request. Something like this could, of course, be=
 implemented as custom policy or configuration in any AS. But I'm think=
ing it might be common enough to warrant adding a client metadata parameter=
 to the PAR draft specifically for it. The metadata (and registered extensi=
ons) defined by Dynamic Client Registration [RFC7591] has come to imply a g=
eneral data model and expected associated behaviors for clients that is use=
ful for authorization server implementations, even when the Dynamic Client =
Registration Protocol isn't directly in play. This particular situation=
 seems like a good potential candidate for a new such client metadata param=
eter that would indicate that the given client can only use a request_uri v=
alue obtained from the PAR endpoint to initiate an authorization request. A=
nd that a regular old fashioned authorization request from the given client=
 would result in an error. 

>>>> 

>>>> Do the folks of this fine WG think something like this wou=
ld be a worthwhile addition to the PAR draft?

>>>> 

>>>> 

>>>> 

>>>> 

>>>> 

>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia=
l and privileged material for the sole use of the intended recipient(s). An=
y review, use, distribution or disclosure by others is strictly prohibited.=
..=C2=A0 If you have received this communication in error, please notify th=
e sender immediately by e-mail and delete the message and any file attachme=
nts from your computer. Thank you. 

>>>> 

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> 

>>>> OAuth@=
ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oa=
uth

>>> 

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
..org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

>>> 

>>> CONFIDENTIALITY NOTICE: This email may contain confidential an=
d privileged material for the sole use of the intended recipient(s). Any re=
view, use, distribution or disclosure by others is strictly prohibited..=C2=
=A0 If you have received this communication in error, please notify the sen=
der immediately by e-mail and delete the message and any file attachments f=
rom your computer. Thank you.

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
..org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


> https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000380ce705a44a6ab3--


From nobody Mon Apr 27 12:17:44 2020
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 5F47F3A1AD8 for ; Mon, 27 Apr 2020 12:17:10 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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_7aZB9OWAL4 for ; Mon, 27 Apr 2020 12:17:04 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 897543A1AD4 for ; Mon, 27 Apr 2020 12:17:04 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id u6so18813546ljl.6 for ; Mon, 27 Apr 2020 12:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3bPDdojzVzti0SXFm9y4LEiQ7ONI+lJ3I0OEHf7AVQg=; b=RjIQVupqIb2Gll0tYffJ6XwxNbc38O2BKKDo8FlHuHgYHh6/RxL3zFpYZUlJNn0Od+ wzQ4LcBIxDzA9LQml5YzaG6O31nnHxB+njMvapeKUo47T2f3/FH4umJf0MJdX5zq5Zqg M6FHbLdJo8PHJ+utYcbJHFuIupYpZZ3OjrTZTM/rWmFLY4MLsrVfz0ljwPe1S7F4ZCon 8OaRLO0eFtux/f+BqipAn32/JMRC+LluR7/Pl5nq75/lEGwq0/sPHYjpA672f0nmo1sr b/AuPFur5TwpD4sG2/QQFNQTlikcquMMcJ0oioIjR/wmwmRmlbQG42QvgurtgPVKIOHq Xi7w==
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=3bPDdojzVzti0SXFm9y4LEiQ7ONI+lJ3I0OEHf7AVQg=; b=inLt+VjWkbob694fSu0DHyseZ88eYrXb0oDmaRtRm8BWD7Jrkbl5lb+Q2XAjQP5wXd gcuXb9NZTwnKuefCkW3XzM2EwtwElugLl0AyNWWAB2hwIrJHndSFJpxPcNmEjyhNykGB DFjEopyiiPwek6sGsCO3EB7d71YsKoQttMXPXW8SAO6RAzz0UK9nlu4r+3vzJHbSJVbU Wbqglr8q46RdZKIk3UxxV7KRvNukbVKFPx4C2vE8bKelj66lXio4/Vtz13tMgmc0dR6Z 3o7T0pUElwHo4eAzkCUWQx+TZ355+CM6vJBtF4pL/X+y6x7g0waDKrYoLfGuDd4J4rQa +OAA==
X-Gm-Message-State: AGi0PubP7l2NPYevmfbzMTdlfPgGlCsYX6wNGjRqNzUFK9i5DrvAtaNw DruTUjrJoT71HoMGWRrqJFD34aEkYndblKIL+36Ky5g6j+7Qwn22I1oA2XwzC26wZYbwFDd828A 9jfyBqNgxOHPgNiPiJX4=
X-Google-Smtp-Source: APiQypIv5MnAD3mxjFlbvWiDY8BhhHVrNM1QCob1O4kYSNGEeGGvPuSEB2IjhU2GXKLb85jPbRzzcRVROCZRLuInDuU=
X-Received: by 2002:a05:651c:505:: with SMTP id o5mr8913002ljp.0.1588015022344;  Mon, 27 Apr 2020 12:17:02 -0700 (PDT)
MIME-Version: 1.0
References:   <32A77307-BFE4-4A0E-99F6-B9567DF38645@mit.edu>
In-Reply-To: <32A77307-BFE4-4A0E-99F6-B9567DF38645@mit.edu>
From: Brian Campbell 
Date: Mon, 27 Apr 2020 13:16:36 -0600
Message-ID: 
To: Justin Richer 
Cc: Filip Skokan , oauth ,  Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary="0000000000004e1d3405a44a8fab"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 27 Apr 2020 19:17:11 -0000

--0000000000004e1d3405a44a8fab
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah, I hadn't really been thinking of going so far as making it
RECOMMENDED either but more of just providing an easy option for those that
would choose to use it.



On Mon, Apr 27, 2020 at 10:58 AM Justin Richer  wrote:

> I agree that any URI could be used but that it MUST be understood by the
> AS to be local to the AS (and not something that can be impersonated by a=
n
> attacker). I wouldn=E2=80=99t even go so far as RECOMMENDED, but it=E2=80=
=99s certainly an
> option.
>
>  =E2=80=94 Justin
>
> On Apr 27, 2020, at 4:41 AM, Filip Skokan  wrote:
>
> I believe implementers should be free to devise their own URIs and not be
> locked down to one by the spec, at the same time,
> and RFC6755 subnamespace would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g.
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
> that any URN or URL will do if the circumstances call for it.
>
> Best,
> *Filip*
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> another topic from last week=E2=80=99s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000004e1d3405a44a8fab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yeah, I hadn't really been thinking of going so f=
ar as making it RECOMMENDED either but more of just providing an easy optio=
n for those that would choose to use it. 


=


On Mon, Apr 27, 2020 at 10:58 AM Justin Richer <jricher@mit.edu> wrote:
=
I agree that any URI could be used but that it MUST be understood by the AS=
 to be local to the AS (and not something that can be impersonated by an at=
tacker). I wouldn=E2=80=99t even go so far as RECOMMENDED, but it=E2=80=99s=
 certainly an option.

=C2=A0=E2=80=94 Justin
On Apr 27, 2020, at 4:41 AM, Filip Skokan &=
lt;panva.ip@gmail.c=
om> wrote:

I believe implementer=
s should be free to devise their own URIs and not be locked down to one by =
the spec, at the same time, and=C2=A0RFC6755=C2=A0subnamespace=C2=A0would b=
e good for guidance.

So, I would suggest it be REC=
OMMENDED to use e.g. `urn:ietf:params:oauth:request_uri:<random>` (Br=
ian's proposal) but also that any URN or URL will do if the circumstanc=
es call for it.

Best,
=
Filip


On Sun, 26 Apr 2020 at 17:20, Torsten Lod=
derstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
=

Hi all, 



another topic from last week=E2=80=99s virtual meeting. 



Shall there be guidance on the request URI structure? 



Please state your opinion. 



thanks in advance, 

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--0000000000004e1d3405a44a8fab--


From nobody Mon Apr 27 15:25:55 2020
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 612973A0CB8 for ; Mon, 27 Apr 2020 15:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukAP1PNdOKuq for ; Mon, 27 Apr 2020 15:25:45 -0700 (PDT)
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 63D6E3A0D29 for ; Mon, 27 Apr 2020 15:25:36 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RMPTWW023764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 18:25:31 -0400
Date: Mon, 27 Apr 2020 15:25:28 -0700
From: Benjamin Kaduk 
To: Justin Richer 
Cc: Filip Skokan , oauth , Torsten Lodderstedt 
Message-ID: <20200427222528.GG27494@kduck.mit.edu>
References:   <32A77307-BFE4-4A0E-99F6-B9567DF38645@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <32A77307-BFE4-4A0E-99F6-B9567DF38645@mit.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 27 Apr 2020 22:25:54 -0000

On Mon, Apr 27, 2020 at 12:58:09PM -0400, Justin Richer wrote:
> I agree that any URI could be used but that it MUST be understood by the AS to be local to the AS (and not something that can be impersonated by an attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an option.

IIUC BCP 190 has similar thoughts on the matter...

-Ben


From nobody Mon Apr 27 23:03:00 2020
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 8DD353A0B59 for ; Mon, 27 Apr 2020 23:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
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 Aj0-8uQCXpTw for ; Mon, 27 Apr 2020 23:02:55 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 1B1243A0B37 for ; Mon, 27 Apr 2020 23:02:54 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id e26so30749366otr.2 for ; Mon, 27 Apr 2020 23:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HURr68Hgx7wBPF0K7c+xXX5qtiVzqv0maziP/prEu4=; b=I1R3qJf03XEFTm2KnCGdN322aXfVeT1c+MqyCmTGGkNYq+GrAbKQxJ5RpnsyeT5Qf6 UgJ5WUZcQYuku6rTIziDJec9m1fkf+WydC+cdI9od4dBJ6f/WmPuuL0FRJH3nCe8Zcfy bizGYfWLrY8kva9s61EE83kp3lTakEYNtZ+y8=
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=0HURr68Hgx7wBPF0K7c+xXX5qtiVzqv0maziP/prEu4=; b=jedMqWUDHn9pYG8O5HIn2u1iIAuD3P7aqpflU5yngh1BpuP6ik0XS9GgU07A2SbVES E10hJGR0/X+yAn02Aw9nBmlAiwPMsfow1+amJ4fMCNCVC/1KOyKMqLtMNvzdLyQ0a7nl gKILRqVieFpfn+Rt7RU7eLXnc6upNVGUwc5yzjW6JLJcd8rxj8MgvnpoxV85aBf0iigw tUa9hjQNsZQJOtMzTAFmFs4UZbVNrTn0q8b8dkurmEd2yqTPOhi7L2KSo6Tcxzc0E4e4 YNKnpG61nWB+8TK7LFNGhfxwkYEZ9IHB2noNwbxbuCeTzoOewQjIrEqNl05I/xNn5pvM JbYw==
X-Gm-Message-State: AGi0PuYa84IefhcFiaT3zgc1yBJ65b+GwjZVNnMkgKgCQ8nmvkPq4egw 2qJAup21+SiZHT8a5v8x65vdpPnzx5HiyJPuJhq7l3hudMyOqA==
X-Google-Smtp-Source: APiQypKymEa5m8yIIgyQGOstTKIRgouS1mbopOhy4tgEKds4WmTexN/n7SAwLlkLcIX/AtZ1/ww21zmIZTepi7eorr4=
X-Received: by 2002:aca:5014:: with SMTP id e20mr1904378oib.34.1588053774075;  Mon, 27 Apr 2020 23:02:54 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dave Tonge 
Date: Tue, 28 Apr 2020 08:02:42 +0200
Message-ID: 
To: Filip Skokan 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="00000000000016a2ba05a453951a"
Archived-At: 
Subject: Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?
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, 28 Apr 2020 06:02:58 -0000

--00000000000016a2ba05a453951a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 to Filip's suggestion

On Mon, 27 Apr 2020 at 10:42, Filip Skokan  wrote:

> I believe implementers should be free to devise their own URIs and not be
> locked down to one by the spec, at the same time,
> and RFC6755 subnamespace would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g.
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
> that any URN or URL will do if the circumstances call for it.
>
> Best,
> *Filip*
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt  40lodderstedt.net@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> another topic from last week=E2=80=99s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> _______________________________________________
>> 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
Dave Tonge
CTO
[image: Moneyhub Enterprise]

Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 =C2=A9

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

--00000000000016a2ba05a453951a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1 to Filip's suggestion

On Mon, 27 Apr 2020 =
at 10:42, Filip Skokan <panva.ip@g=
mail.com> wrote:
I believe implementers should be free to devi=
se their own URIs and not be locked down to one by the spec, at the same ti=
me, and=C2=A0RFC6755=C2=A0subnamespace=C2=A0would be good for guidance.

So, I would suggest it be RECOMMENDED to use e.g. `ur=
n:ietf:params:oauth:request_uri:<random>` (Brian's proposal) but =
also that any URN or URL will do if the circumstances call for it.

Best,
Filip
=


On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt <torsten=3D<=
a href=3D"mailto:40lodderstedt.net@dmarc.ietf.org" target=3D"_blank">40lodd=
erstedt.net@dmarc.ietf.org> wrote:
Hi all, 



another topic from last week=E2=80=99s virtual meeting. 



Shall there be guidance on the request URI structure? 



Please state your opinion. 



thanks in advance, 

Torsten. 

_______________________________________________

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




-- 
Da=
ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl=
oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512=
0

Moneyhub =
Enterprise is a trading style of Moneyhub Financial Technology Limited whic=
h is authorised and regulated by the Financial Conduct Authority ("FCA=
").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser=
vices Register=C2=A0(FRN=C2=A0809360) at fca.=
org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &=
; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<=
/span>
Moneyhub=C2=A0Financial Technology L=
imited 2018=C2=A0=C2=A9<=
/div>

DISCLAIMER: This email (including any attachments) is subject to co=
pyright, and the information in it is confidential. Use of this email or of=
 any information in it other than by the addressee is unauthorised and unla=
wful. Whilst reasonable efforts are made to ensure that any attachments are=
 virus-free, it is the recipient's sole responsibility to scan all atta=
chments for viruses. All calls and emails to and from this company may be m=
onitored and recorded for legitimate purposes relating to this company'=
s business. Any opinions expressed in this email (or in any attachments) ar=
e those of the author and do not necessarily represent the opinions of Mone=
yhub Financial Technology Limited or of any other group company.
<=
/div>


--00000000000016a2ba05a453951a--


From nobody Tue Apr 28 16:38:23 2020
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 4651B3A0980 for ; Tue, 28 Apr 2020 16:38:22 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 ZRDQBaRZO9mO for ; Tue, 28 Apr 2020 16:38:20 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650130.outbound.protection.outlook.com [40.107.65.130]) (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 A87EC3A0975 for ; Tue, 28 Apr 2020 16:38:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eZSi+OLzBx2iNRV0hsbj+uUK4TaCL38tr21Ydbfr70dPyhRRi3iJrkuB8VpBJLgzUieKHcjs7CvbZ/VEGRpx9gREgKL1quG8l8+6jdQMmmUYzRgwjvWxsrl9it62a6GbwtfWom7QGHOiURzTKQ581SKggyIy/RCboGuqM+jC9ALPumIGP7o+5gkCg0MIAPfFf3/SdyokyYBgR2Z8lE2GuHP2gRqDFQ8pi2hr0LLo/AwW70Govj4k1Kf5NVHLD5r3XNY/xkNq3KffKUIYi+kBrmLX4URZ/iRwYkzpn/iVLI00DurWGYMbXVOl9x0fBj87aw/PxJpINw3fAEvM4ELJeA==
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=Eh5LR3UnfD+HgoPx+ANEDccC6m4T84QmWb1IUvQ98ms=; b=isr8JHBceKFTmnDZSQeEee7DXer9RFreSxEs7kMKqLrZ0mQsUaHZy4DnkiOiO4I2/YFW1lVUnHWUZU7xxLOLZSp8zyPPfBLSl9rKDsZeI+YBTPkhgweOrtxVPWzGRyt1aTvRF2pLeCPSrDqIl8NbacYD5jB3uOXrxLtnT63KwgS4vgs6Hm5Blw1eVlzC+UVyvXhBmcDVHG5Pgd9Y1xo2lOWfrGp+GlVTYguH1HmA1RPq2Og8U8P834sLpXJPdcxcYAmxXNM0xnDXbL2+E7LhvedpXXzgRlyweVjULVvm+D9sZ6LGLyHrku4ePpf4pT+Ua2/01lkQK+vXdL3+EDpBbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Eh5LR3UnfD+HgoPx+ANEDccC6m4T84QmWb1IUvQ98ms=; b=KfMlc9xmsKWTTbImTgDxOwIfjYF6I8bA//rRoys3rXQLWsrvpM+ZADHxvZAjF1pAYbBUadUDGaiNYH3h0CzpEUOuYweFtG1n3Fd9QiSqih/5r3jW/nshpXQmkWF63J+4PhyKhB4avoK/6I5miIWunbrdRpNnrH3oUkRdjitcec0=
Received: from BY5PR00MB0676.namprd00.prod.outlook.com (2603:10b6:a03:20c::15) by BYAPR00MB0454.namprd00.prod.outlook.com (2603:10b6:a03:d9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2988.0; Tue, 28 Apr 2020 23:38:16 +0000
Received: from BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::2c69:97fa:f3be:7b60]) by BY5PR00MB0676.namprd00.prod.outlook.com ([fe80::2c69:97fa:f3be:7b60%7]) with mapi id 15.20.2996.000; Tue, 28 Apr 2020 23:38:16 +0000
From: Mike Jones 
To: Nat Sakimura , Torsten Lodderstedt , John Bradley 
CC: oauth 
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt
Thread-Index: AdYb7ny/PQDH7dVXRBSZpdWvw5uEuwAAbaAAAHFtauA=
Date: Tue, 28 Apr 2020 23:38:15 +0000
Message-ID: 
References:  <88d7c433-bd4b-456a-bc04-d30ed988fe9f@Spark>
In-Reply-To: <88d7c433-bd4b-456a-bc04-d30ed988fe9f@Spark>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f3a7090f-b4a1-4b7c-9f9b-00007213443f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-28T23:36:59Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: sakimura.org; dkim=none (message not signed) header.d=none; sakimura.org; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5c1685e1-af46-4002-25cd-08d7ebcd3999
x-ms-traffictypediagnostic: BYAPR00MB0454:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0387D64A71
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wNdUsA+7g3Hsr4jSNQRxl6iKjmsYNIPwt7zVzYpHq34A+o6cKm1WhuBynrHZ2zOUyQ3Pqhd0uAxKixU1d2RicWmo+moArDBx69vKcl/SJq+Q7U2snZm5zUvtsubyQkQk7WzUxk/qNfNGDs5dzmLFAZcAVRXg516OdIcpvA2zc4+4J1Y0BuL/tXRp3QteOP26QNmLH6IPCbm67CWv6xYf+6ByiEhFjScMuF5m8YoayI20PJdkx9k6JZHR4rkCT73xYfN1Z196QzOyEv4mPFkjeK1scgckzLPa5lrabXh75jWTq0FpHaXHsjY0ToFLh6zIWOPm8OOJip4x0JrR9vZhUfQ1WRc+YLPSNLuICvanEF3DpcoJHSbYiW9wnW8wvFe4y5BzNoSrbf6CQ17hiJpBhl7NGYAeriBRU0fU5Li61hdi5Yd2fDHvhVSaXhw6Sp2g48Dd31ENYtzCp2WmsAMk+GJbCRLHsLA+rHfknwYaZpLPmFDbWmMoA6AJGXKcOSps
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY5PR00MB0676.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(346002)(396003)(39860400002)(366004)(136003)(9686003)(26005)(21615005)(66574012)(55016002)(316002)(53546011)(71200400001)(8676002)(5660300002)(110136005)(8990500004)(6506007)(86362001)(8936002)(186003)(4326008)(478600001)(52536014)(2906002)(10290500003)(7696005)(966005)(66946007)(82950400001)(66476007)(66446008)(66556008)(33656002)(76116006)(64756008)(82960400001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: HnuFKsQXRkb7lvpdZ2YCUHaOD4LDBz7OAfCcjcgX8RSigYNwci3WcQLyrBPeSe0Y+vd7y5dbKsEL/Qr5XHWlARbvgT+yqoprDcqGyHzTZaR5depczzI/1b7DWJEy1zuKhp8DN3lz68JLF2CAkxRrQhk/MIxovPPZUUXo7TceGD32T+OtWpYc3o7sfs4q20sXHBwBb39X8R3u57FxXiPhJLG9wKkAlimWQo/s+LdoBKJ8lhvEH1ddllbSwzhR5TiA5n1IsMBCR6iColyabtVi9ZNeKg+R5VIrGYoF5F6w16kI/SX4PVd4LZw1chzB4jm3tpA/xkttekUhtMOakRl8i1MmE+wm5FxdLFFky0yBQFEzZeU+u+n2hwbupd+TRqV5ZWRIF2FOY6JTTChxGeNIEx0evO3ZKTHJPyIyysI/5RlP8mqweyrRv/BoM98dDrffuuzKRDKDLKEGBue8kFO1Bm7f+cOIxLQuT6tnmDXMdz3QVa5VAUP9tB7n8KK/wOIThchrU3TJOokAw3jgxNn/klq7DR7qQDbFCRAcZ4sbDOBw6I82JMmx5vp3ViEdu04cU9msmI/+wwtSJfhMMHbrpqrbpLZgeJ2DCUNEvvUWRd+iy7wY4R3PalwtNN1v7vV7LmRDuPxgYmkuCXee4laQ3ZnrD/53pQ6GRbBDqghR43yP/cNKcRY4eNhVza1dOVR6Ee9jGUHtqDWfMaftjHOEfh4sW+8P2gJylr9dScOhOei5BZZjerBBgkzG+18FCf1eQmF4YnGxC2aJKG2t0tAgQ+0Lf2HN+NdrODLiujuzNoc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR00MB0676CBF29BE43390EBB459C4F5AC0BY5PR00MB0676namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0676.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c1685e1-af46-4002-25cd-08d7ebcd3999
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 23:38:16.1045 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EdK8RQNYP2M0o8+bXHlEV8Z3Jqf4uYrl4abn9o2UdfU7awPYbIv7GAt6VsjmU+n1YyaUvvgxENm/3QtKevkOKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0454
Archived-At: 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: I-D Action: draft-ietf-oauth-jwsreq-21.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: Tue, 28 Apr 2020 23:38:22 -0000

--_000_BY5PR00MB0676CBF29BE43390EBB459C4F5AC0BY5PR00MB0676namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

4oCccmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZOKAnSBhbmQgb3Ro
ZXIgQVMgTWV0YWRhdGEgdmFsdWVzIGRlZmluZWQgYnkgT3BlbklEIENvbm5lY3QgRGlzY292ZXJ5
IGFyZSBub3cgcmVnaXN0ZXJlZCBhdCBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9v
YXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2
ZXItbWV0YWRhdGEuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IG5hdD1zYWtpbXVyYS5vcmdAbWcuc2Fr
aW11cmEub3JnIDxuYXQ9c2FraW11cmEub3JnQG1nLnNha2ltdXJhLm9yZz4gT24gQmVoYWxmIE9m
IE5hdCBTYWtpbXVyYQ0KU2VudDogU3VuZGF5LCBBcHJpbCAyNiwgMjAyMCAxMDoyOSBBTQ0KVG86
IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0
Zi5vcmc+OyBKb2huIEJyYWRsZXkgPGpicmFkbGV5QHl1Ymljby5jb20+OyBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0K
U3ViamVjdDogW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm
LW9hdXRoLWp3c3JlcS0yMS50eHQNCg0KVGhhbmtzIE1pa2UuDQoNClJpZ2h0IGluIGFzIG11Y2gg
YXMgSSBuZXZlciBleHBlY3RlZCBKQVIgdG8gdGFrZSB0aGlzIGxvbmcsIEkgd2FzIGV4cGVjdGlu
ZyB0aGUgZXJyYXRhIHRvIGJlIHB1Ymxpc2hlZCBhbmQgdGhlc2UgcGFyYW1zIHRvIGJlIHJlZ2lz
dGVyZWQgbG9uZyBiZWZvcmUgYXMgd2VsbCA6LSkgQnV0IGl0IG1heSBiZSBhIGdvb2Qgc2lnbiB0
aGF0IHdlIElkZW50aXRlcmF0aSBhcmUgYWxsIHNvIGJ1c3kgdGhlc2UgZGF5cy4NCg0KTmF0IFNh
a2ltdXJhDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHBzOi8vbmF0LnNha2ltdXJh
Lm9yZw0KMjAyMOW5tDTmnIgyN+aXpSAyOjE3ICswOTAw44CBTWlrZSBKb25lcyA8TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiDj
ga7jg6Hjg7zjg6s6DQoNClRoZSBuZXh0IGVycmF0YSB2ZXJzaW9uIG9mIE9wZW5JRCBDb25uZWN0
IERpc2NvdmVyeSB3aWxsIHJlZ2lzdGVyIHRoZSBwYXJhbWV0ZXIgcmVxdWVzdF9vYmplY3Rfc2ln
bmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCBhbmQgb3RoZXIgcGFyYW1ldGVycyBub3QgcHJldmlv
dXNseSByZWdpc3RlcmVkLiBTZWUgaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25u
ZWN0LWRpc2NvdmVyeS0xXzAtMjkuaHRtbCBmb3IgdGhlIGxhdGVzdCBwdWJsaXNoZWQgZXJyYXRh
IGRyYWZ0Lg0KDQpJIGNhbiBtYWtlIGEgcmVxdWVzdCBmb3IgZWFybHkgcmVnaXN0cmF0aW9uIGlm
IGl0IHdvdWxkIGJlIHVzZWZ1bC4NCg0KLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0KU2VudDog
U3VuZGF5LCBBcHJpbCAyNiwgMjAyMCA4OjE3IEFNDQpUbzogTmF0IFNha2ltdXJhIDxuYXRAc2Fr
aW11cmEub3JnPG1haWx0bzpuYXRAc2FraW11cmEub3JnPj47IEpvaG4gQnJhZGxleSA8amJyYWRs
ZXlAeXViaWNvLmNvbTxtYWlsdG86amJyYWRsZXlAeXViaWNvLmNvbT4+DQpDYzogb2F1dGggPG9h
dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMS50eHQNCg0KSGkgTmF0
ICYgSm9obiwNCg0KSSB0cmllZCB0byBmaW5kIG91dCBob3cgc2lnbmluZyAmIGVuY3J5cHRpb24g
YWxnb3JpdGhtcyBhcmUgZGV0ZXJtaW5lZCBpbiB0aGUgSkFSIGNvbnRleHQuDQoNCkkganVzdCBm
b3VuZCB0aGlzIG5vdGUgaW4gdGhlIGhpc3RvcnkgZm9yIC0wNzogIlN0b3BwZWQgdGFsa2luZyBh
Ym91dCByZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ+KAnQ0KDQpJIGFzc3VtZSB5b3UgYXNzdW1l
IHRoaXMgaXMgZG9uZSB2aWEgY2xpZW50IHJlZ2lzdHJhdGlvbiBwYXJhbWV0ZXJzIHJlZ2lzdGVy
ZWQgaW4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9v
YXV0aC1wYXJhbWV0ZXJzLnhodG1sI2NsaWVudC1tZXRhZGF0YT8gV2h5IGRvZXNu4oCZdCBKQVIg
c3RhdGUgc28/DQoNCldoYXQgaXMgYWJvdXQgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgYnkgdGhlIEFT
PyBUaGUgcmVzcGVjdGl2ZSBwYXJhbWV0ZXJzLCBzdWNoIGFzIHJlcXVlc3Rfb2JqZWN0X3NpZ25p
bmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWQgYXJlIG5vdCByZWdpc3RlcmVkIHlldCBpbiBodHRwczov
L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRl
cnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGEuDQoNCmJlc3QgcmVnYXJkcywN
ClRvcnN0ZW4uDQoNCg0KDQpPbiAxOS4gQXByIDIwMjAsIGF0IDIwOjMwLCBpbnRlcm5ldC1kcmFm
dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0K
QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu
ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg
V2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cgb2YgdGhlIElFVEYuDQoNClRpdGxlIDogVGhl
IE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yazogSldUIFNlY3VyZWQgQXV0aG9yaXph
dGlvbiBSZXF1ZXN0IChKQVIpDQpBdXRob3JzIDogTmF0IFNha2ltdXJhDQpKb2huIEJyYWRsZXkN
CkZpbGVuYW1lIDogZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjEudHh0DQpQYWdlcyA6IDMxDQpE
YXRlIDogMjAyMC0wNC0xOQ0KDQpBYnN0cmFjdDoNClRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qg
aW4gT0F1dGggMi4wIGRlc2NyaWJlZCBpbiBSRkMgNjc0OSB1dGlsaXplcw0KcXVlcnkgcGFyYW1l
dGVyIHNlcmlhbGl6YXRpb24sIHdoaWNoIG1lYW5zIHRoYXQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0
DQpwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGluIHRoZSBVUkkgb2YgdGhlIHJlcXVlc3QgYW5kIHNl
bnQgdGhyb3VnaA0KdXNlciBhZ2VudHMgc3VjaCBhcyB3ZWIgYnJvd3NlcnMuIFdoaWxlIGl0IGlz
IGVhc3kgdG8gaW1wbGVtZW50LCBpdA0KbWVhbnMgdGhhdCAoYSkgdGhlIGNvbW11bmljYXRpb24g
dGhyb3VnaCB0aGUgdXNlciBhZ2VudHMgYXJlIG5vdA0KaW50ZWdyaXR5IHByb3RlY3RlZCBhbmQg
dGh1cyB0aGUgcGFyYW1ldGVycyBjYW4gYmUgdGFpbnRlZCwgYW5kIChiKQ0KdGhlIHNvdXJjZSBv
ZiB0aGUgY29tbXVuaWNhdGlvbiBpcyBub3QgYXV0aGVudGljYXRlZC4gQmVjYXVzZSBvZg0KdGhl
c2Ugd2Vha25lc3Nlcywgc2V2ZXJhbCBhdHRhY2tzIHRvIHRoZSBwcm90b2NvbCBoYXZlIG5vdyBi
ZWVuIHB1dA0KZm9yd2FyZC4NCg0KVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBhYmlsaXR5
IHRvIHNlbmQgcmVxdWVzdCBwYXJhbWV0ZXJzIGluIGENCkpTT04gV2ViIFRva2VuIChKV1QpIGlu
c3RlYWQsIHdoaWNoIGFsbG93cyB0aGUgcmVxdWVzdCB0byBiZSBzaWduZWQNCndpdGggSlNPTiBX
ZWIgU2lnbmF0dXJlIChKV1MpIGFuZCBlbmNyeXB0ZWQgd2l0aCBKU09OIFdlYiBFbmNyeXB0aW9u
DQooSldFKSBzbyB0aGF0IHRoZSBpbnRlZ3JpdHksIHNvdXJjZSBhdXRoZW50aWNhdGlvbiBhbmQN
CmNvbmZpZGVudGlhbGl0eSBwcm9wZXJ0eSBvZiB0aGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGlz
IGF0dGFpbmVkLg0KVGhlIHJlcXVlc3QgY2FuIGJlIHNlbnQgYnkgdmFsdWUgb3IgYnkgcmVmZXJl
bmNlLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0
IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1q
d3NyZXEvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoN
Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMQ0K
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3
c3JlcS0yMQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg
YXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC1q
d3NyZXEtMjENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p
bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0Kc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5l
dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9m
dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_BY5PR00MB0676CBF29BE43390EBB459C4F5AC0BY5PR00MB0676namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs
aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu
IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0
aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V
UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7i
gJxyZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVk4oCdIGFuZCBvdGhl
ciBBUyBNZXRhZGF0YSB2YWx1ZXMgZGVmaW5lZCBieSBPcGVuSUQgQ29ubmVjdCBEaXNjb3Zlcnkg
YXJlIG5vdyByZWdpc3RlcmVkIGF0DQo8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3Np
Z25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXph
dGlvbi1zZXJ2ZXItbWV0YWRhdGEiPg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv
b2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhodG1sI2F1dGhvcml6YXRpb24tc2Vy
dmVyLW1ldGFkYXRhPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt
LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t
OjwvYj4gbmF0PXNha2ltdXJhLm9yZ0BtZy5zYWtpbXVyYS5vcmcgJmx0O25hdD1zYWtpbXVyYS5v
cmdAbWcuc2FraW11cmEub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5OYXQgU2FraW11cmE8
YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBBcHJpbCAyNiwgMjAyMCAxMDoyOSBBTTxicj4NCjxi
PlRvOjwvYj4gVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5l
dEBkbWFyYy5pZXRmLm9yZyZndDs7IEpvaG4gQnJhZGxleSAmbHQ7amJyYWRsZXlAeXViaWNvLmNv
bSZndDs7IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+
DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gW0VYVEVSTkFMXSBSZTogW09BVVRILVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9h
dXRoLWp3c3JlcS0yMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgbmFtZT0ibWVzc2FnZUJv
ZHlTZWN0aW9uIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgTWlrZS4mbmJz
cDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodCBp
biBhcyBtdWNoIGFzIEkgbmV2ZXIgZXhwZWN0ZWQgSkFSIHRvIHRha2UgdGhpcyBsb25nLCBJIHdh
cyBleHBlY3RpbmcgdGhlIGVycmF0YSB0byBiZSBwdWJsaXNoZWQgYW5kIHRoZXNlIHBhcmFtcyB0
byBiZSByZWdpc3RlcmVkIGxvbmcgYmVmb3JlIGFzIHdlbGwgOi0pIEJ1dCBpdCBtYXkgYmUgYSBn
b29kIHNpZ24gdGhhdCB3ZSBJZGVudGl0ZXJhdGkgYXJlIGFsbCBzbyBidXN5IHRoZXNlIGRheXMu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IG5hbWU9
Im1lc3NhZ2VTaWduYXR1cmVTZWN0aW9uIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQgU2Fr
aW11cmEmbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hdC5zYWtpbXVy
YS5vcmciPmh0dHBzOi8vbmF0LnNha2ltdXJhLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAyMDxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuW5tDwvc3Bhbj40PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPjI3
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pelPC9zcGFu
PiAyOjE3ICYjNDM7MDkwMDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm
cXVvdDsiPuOAgTwvc3Bhbj5NaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ow0K
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+44Gu44Oh44O8
44OrPC9zcGFuPjo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoZSBuZXh0IGVycmF0YSB2ZXJzaW9uIG9mIE9wZW5JRCBDb25uZWN0IERpc2NvdmVyeSB3
aWxsIHJlZ2lzdGVyIHRoZSBwYXJhbWV0ZXIgcmVxdWVzdF9vYmplY3Rfc2lnbmluZ19hbGdfdmFs
dWVzX3N1cHBvcnRlZCBhbmQgb3RoZXIgcGFyYW1ldGVycyBub3QgcHJldmlvdXNseSByZWdpc3Rl
cmVkLiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVj
dC1kaXNjb3ZlcnktMV8wLTI5Lmh0bWwiPmh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt
Y29ubmVjdC1kaXNjb3ZlcnktMV8wLTI5Lmh0bWw8L2E+IGZvciB0aGUgbGF0ZXN0IHB1Ymxpc2hl
ZCBlcnJhdGEgZHJhZnQuPGJyPg0KPGJyPg0KSSBjYW4gbWFrZSBhIHJlcXVlc3QgZm9yIGVhcmx5
IHJlZ2lzdHJhdGlvbiBpZiBpdCB3b3VsZCBiZSB1c2VmdWwuPGJyPg0KPGJyPg0KLS0gTWlrZTxi
cj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogT0F1dGggJmx0
OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGll
dGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnI+DQpTZW50
OiBTdW5kYXksIEFwcmlsIDI2LCAyMDIwIDg6MTcgQU08YnI+DQpUbzogTmF0IFNha2ltdXJhICZs
dDs8YSBocmVmPSJtYWlsdG86bmF0QHNha2ltdXJhLm9yZyI+bmF0QHNha2ltdXJhLm9yZzwvYT4m
Z3Q7OyBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYnJhZGxleUB5dWJpY28uY29t
Ij5qYnJhZGxleUB5dWJpY28uY29tPC9hPiZndDs8YnI+DQpDYzogb2F1dGggJmx0OzxhIGhyZWY9
Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1Ympl
Y3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIx
LnR4dDxicj4NCjxicj4NCkhpIE5hdCAmYW1wOyBKb2huLDxicj4NCjxicj4NCkkgdHJpZWQgdG8g
ZmluZCBvdXQgaG93IHNpZ25pbmcgJmFtcDsgZW5jcnlwdGlvbiBhbGdvcml0aG1zIGFyZSBkZXRl
cm1pbmVkIGluIHRoZSBKQVIgY29udGV4dC48YnI+DQo8YnI+DQpJIGp1c3QgZm91bmQgdGhpcyBu
b3RlIGluIHRoZSBoaXN0b3J5IGZvciAtMDc6ICZxdW90O1N0b3BwZWQgdGFsa2luZyBhYm91dCBy
ZXF1ZXN0X29iamVjdF9zaWduaW5nX2FsZ+KAnTxicj4NCjxicj4NCkkgYXNzdW1lIHlvdSBhc3N1
bWUgdGhpcyBpcyBkb25lIHZpYSBjbGllbnQgcmVnaXN0cmF0aW9uIHBhcmFtZXRlcnMgcmVnaXN0
ZXJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgt
cGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhodG1sI2NsaWVudC1tZXRhZGF0YSI+DQpodHRw
czovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFt
ZXRlcnMueGh0bWwjY2xpZW50LW1ldGFkYXRhPC9hPj8gV2h5IGRvZXNu4oCZdCBKQVIgc3RhdGUg
c28/PGJyPg0KPGJyPg0KV2hhdCBpcyBhYm91dCBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSB0aGUg
QVM/IFRoZSByZXNwZWN0aXZlIHBhcmFtZXRlcnMsIHN1Y2ggYXMgcmVxdWVzdF9vYmplY3Rfc2ln
bmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCBhcmUgbm90IHJlZ2lzdGVyZWQgeWV0IGluDQo8YSBo
cmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29h
dXRoLXBhcmFtZXRlcnMueGh0bWwjYXV0aG9yaXphdGlvbi1zZXJ2ZXItbWV0YWRhdGEiPg0KaHR0
cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJh
bWV0ZXJzLnhodG1sI2F1dGhvcml6YXRpb24tc2VydmVyLW1ldGFkYXRhPC9hPi48YnI+DQo8YnI+
DQpiZXN0IHJlZ2FyZHMsPGJyPg0KVG9yc3Rlbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjRTY3RTIyIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxlZnQ6
My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1yaWdodDozLjc1cHQ7bWFyZ2luLWJvdHRv
bTozLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTkuIEFwciAyMDIwLCBhdCAyMDoz
MCwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmc8L2E+IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0
LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl
Y3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBXZWIgQXV0aG9y
aXphdGlvbiBQcm90b2NvbCBXRyBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQpUaXRsZSA6IFRoZSBP
QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcms6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRp
b24gUmVxdWVzdCAoSkFSKTxicj4NCkF1dGhvcnMgOiBOYXQgU2FraW11cmE8YnI+DQpKb2huIEJy
YWRsZXk8YnI+DQpGaWxlbmFtZSA6IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxLnR4dDxicj4N
ClBhZ2VzIDogMzE8YnI+DQpEYXRlIDogMjAyMC0wNC0xOTxicj4NCjxicj4NCkFic3RyYWN0Ojxi
cj4NClRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW4gT0F1dGggMi4wIGRlc2NyaWJlZCBpbiBS
RkMgNjc0OSB1dGlsaXplczxicj4NCnF1ZXJ5IHBhcmFtZXRlciBzZXJpYWxpemF0aW9uLCB3aGlj
aCBtZWFucyB0aGF0IEF1dGhvcml6YXRpb24gUmVxdWVzdDxicj4NCnBhcmFtZXRlcnMgYXJlIGVu
Y29kZWQgaW4gdGhlIFVSSSBvZiB0aGUgcmVxdWVzdCBhbmQgc2VudCB0aHJvdWdoPGJyPg0KdXNl
ciBhZ2VudHMgc3VjaCBhcyB3ZWIgYnJvd3NlcnMuIFdoaWxlIGl0IGlzIGVhc3kgdG8gaW1wbGVt
ZW50LCBpdDxicj4NCm1lYW5zIHRoYXQgKGEpIHRoZSBjb21tdW5pY2F0aW9uIHRocm91Z2ggdGhl
IHVzZXIgYWdlbnRzIGFyZSBub3Q8YnI+DQppbnRlZ3JpdHkgcHJvdGVjdGVkIGFuZCB0aHVzIHRo
ZSBwYXJhbWV0ZXJzIGNhbiBiZSB0YWludGVkLCBhbmQgKGIpPGJyPg0KdGhlIHNvdXJjZSBvZiB0
aGUgY29tbXVuaWNhdGlvbiBpcyBub3QgYXV0aGVudGljYXRlZC4gQmVjYXVzZSBvZjxicj4NCnRo
ZXNlIHdlYWtuZXNzZXMsIHNldmVyYWwgYXR0YWNrcyB0byB0aGUgcHJvdG9jb2wgaGF2ZSBub3cg
YmVlbiBwdXQ8YnI+DQpmb3J3YXJkLjxicj4NCjxicj4NClRoaXMgZG9jdW1lbnQgaW50cm9kdWNl
cyB0aGUgYWJpbGl0eSB0byBzZW5kIHJlcXVlc3QgcGFyYW1ldGVycyBpbiBhPGJyPg0KSlNPTiBX
ZWIgVG9rZW4gKEpXVCkgaW5zdGVhZCwgd2hpY2ggYWxsb3dzIHRoZSByZXF1ZXN0IHRvIGJlIHNp
Z25lZDxicj4NCndpdGggSlNPTiBXZWIgU2lnbmF0dXJlIChKV1MpIGFuZCBlbmNyeXB0ZWQgd2l0
aCBKU09OIFdlYiBFbmNyeXB0aW9uPGJyPg0KKEpXRSkgc28gdGhhdCB0aGUgaW50ZWdyaXR5LCBz
b3VyY2UgYXV0aGVudGljYXRpb24gYW5kPGJyPg0KY29uZmlkZW50aWFsaXR5IHByb3BlcnR5IG9m
IHRoZSBBdXRob3JpemF0aW9uIFJlcXVlc3QgaXMgYXR0YWluZWQuPGJyPg0KVGhlIHJlcXVlc3Qg
Y2FuIGJlIHNlbnQgYnkgdmFsdWUgb3IgYnkgcmVmZXJlbmNlLjxicj4NCjxicj4NCjxicj4NClRo
ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgt
andzcmVxLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0
aC1qd3NyZXEvPC9hPjxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25z
IGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMTwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIxIj5odHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVx
LTIxPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2
YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy
bDI9ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjEiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMTwvYT48YnI+DQo8YnI+DQo8YnI+DQpQ
bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg
dGltZSBvZjxicj4NCnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpJbnRlcm5ldC1E
cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJl
Zj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9y
Zy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY5PR00MB0676CBF29BE43390EBB459C4F5AC0BY5PR00MB0676namp_--


From nobody Tue Apr 28 19:14:14 2020
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 E00F63A0BCE for ; Tue, 28 Apr 2020 19:14:11 -0700 (PDT)
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, 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 qJZ3EssFTfS7 for ; Tue, 28 Apr 2020 19:14:10 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5470F3A0BCB for ; Tue, 28 Apr 2020 19:14:10 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id z17so425496oto.4 for ; Tue, 28 Apr 2020 19:14:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=PWAsq8ftuQEPBUl7GuJJ3MFYHI5jwgBp37Ejrtdft+U=; b=hODqzzju7JMucQ3q3e58OtMfjOYgfkzemjc4185Hhh3pVPvDWQR30r/ak0S0DpeQvx qM7c1bO4DqLvLY1LnZnlAV1H729hAsAmBKQxcklliQqYBJHll7qF9V8o9ymRDBnSqB29 AYFDsHTyx8QYqXm0Hk3L4eMF0SLgSumm174GxStipfBmUfGppxnWa8Apqb+ppbYI0ZxX 1Ncp8ow1pP+guLEe/NZWbbrvuzOIGJVBsMs2nPfuTexDRvyVjkT+GgRtY55Ro5hodacF 6HRoA84NXhoLuYrR3cipxN+NZc6i/8WVetFUPz4FhKeilT8aCzyM/Tp+xCo42kVzL1P1 KOHQ==
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:cc; bh=PWAsq8ftuQEPBUl7GuJJ3MFYHI5jwgBp37Ejrtdft+U=; b=HSwukcCcaKrid8e0CXgTOfeFSekOtALNAqvx0ckcwauwQTOdP0INl6VE9GzdpOXtG5 AsEcWjOaqeY3K73rYlsVg3NM1sKKxGpopwInUXk9kIVM7/9VqP0nsqXyh1EzpIymOmRA 2BvFtn2cxDJ6tFHTMY+cKNWrlxz+TEM9SY+KNDkALUIDB1kNXDxSOyIssqpyp19jbScr 3UVUz/YtaLfNpQqH8myPZxLUHH7mKdIDva+skIl3DIqY79aY0gh+JTC8yyguK3p4Hkk4 kmyQ/l2LcGvMqlI2t3+8nyfGPA5/unn1UWOnw5+r4JEdTXhH8cK8BBIcb7hmOhIYfYwE yBzw==
X-Gm-Message-State: AGi0PuY//O3oVqsEA2/HOjt/2Ej0Yj163JUJtURpYVh2KrOtQZw7Ofxd 4R7HP6Tbxw+LHY5dnsIIQkqmwXV9oEgooyFiRqILQxKd
X-Google-Smtp-Source: APiQypIsUjsmdheraQX/5/6fHHsyQ6G41CximnyB6r9ytsriKMvSb1u85Gx7OHrvHjeYM96CkuTxVfCic6mZSBwXFuo=
X-Received: by 2002:a05:6830:1181:: with SMTP id u1mr13270233otq.200.1588126449229;  Tue, 28 Apr 2020 19:14:09 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Migault 
Date: Tue, 28 Apr 2020 22:13:58 -0400
Message-ID: 
To: oauth@ietf.org
Cc: Michael Richardson 
Content-Type: multipart/alternative; boundary="000000000000dd64db05a4648093"
Archived-At: 
Subject: [OAUTH-WG] carrying oauth authorisation without HTTP
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, 29 Apr 2020 02:14:12 -0000

--000000000000dd64db05a4648093
Content-Type: text/plain; charset="UTF-8"

Hi,

I am completely new to oauth and would like to solicit the WG for advice.

We are working on the Home Router outsourcing a service in the homenet WG
and we are wondering how oauth could be used to improve automation.

Our scenario is represented in the figure below:

1.  The end user connected to the web interface of the Home Router
2. The Home Router redirects the End User to the service provider where the
end user register for that service ( AS ).
3. The AS providing an authorisation token carried to the RS via the Home
Router to the RS.

The session between the Home router and the RS in our case is not using
HTTP but is using TLS. We are wondering if there is a way to carry an
authorisation token over a non HTTP session and if RFC8705 "OAuth 2.0
Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" heads
in to this direction.

I am happy to hear any feed back or comments!

Yours,
Daniel


      HTTPS            +-----------+
   +------------------>|    AS     |<--------------+
   |                   |           |               |
   v                   +-----------+               v
+-------------+ HTTPS  +-----------+    TLS    +---------+
| User        |<------>|Home Router|<--------->|   RS    |
|(Web Browser)|        |           |           |         |
+-------------+        +-----------+           +---------+

-- 
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC   H4P 2N2
Canada

Phone: +1 514-452-2160

--000000000000dd64db05a4648093
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I am completely new to oauth and would l=
ike to solicit the WG for advice.

We are working on the Home Router =
outsourcing a service in the homenet WG and we are wondering how oauth coul=
d be used to improve automation.

Our scenario is represented in the =
figure below:

1.=C2=A0 The end user connected to the web interface o=
f the Home Router =C2=A0
2. The Home Router redirects the End User to th=
e service provider where the end user register for that service ( AS ).
=
3. The AS providing an authorisation token carried to the RS via the Home R=
outer to the RS.

The session between the Home router and the RS in o=
ur case is not using HTTP but is using TLS. We are wondering if there is a =
way to carry an authorisation token over a non HTTP session and if RFC8705 =
"OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Acce=
ss Tokens" heads in to this direction.

I am happy to hear any f=
eed back or comments!

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 HTTPS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
+-----------+
=C2=A0 =C2=A0+------------------>| =C2=A0 =C2=A0AS =C2=
=A0 =C2=A0 |<--------------+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0v =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
+-------------+ HTTPS=
 =C2=A0+-----------+ =C2=A0 =C2=A0TLS =C2=A0 =C2=A0+---------+
| User =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|<------>|Home Router|<--------->| =
=C2=A0 RS =C2=A0 =C2=A0|
|(Web Browser)| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0+-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+

-- 
Daniel Migault
Ericsson
8400 boulevard Decarie
M=
ontreal, QC=C2=A0=C2=A0 H4P 2N2
Canada

Phone: +1 514-452-2160
=



--000000000000dd64db05a4648093--


From nobody Wed Apr 29 09:12:14 2020
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 A95893A13D4 for ; Wed, 29 Apr 2020 09:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.405
X-Spam-Level: 
X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.82, 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 9t7YD3x6pQX9 for ; Wed, 29 Apr 2020 09:11:53 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79663A13D6 for ; Wed, 29 Apr 2020 09:10:32 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d14 with ME id YgAS2200s4FMSmm03gATRE; Wed, 29 Apr 2020 18:10:28 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 29 Apr 2020 18:10:28 +0200
X-ME-IP: 86.238.65.197
To: oauth@ietf.org
References: 
From: Denis 
Message-ID: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>
Date: Wed, 29 Apr 2020 18:10:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1BDD8CF2A5A52B589A4DD3C0"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 29 Apr 2020 16:11:56 -0000

This is a multi-part message in MIME format.
--------------1BDD8CF2A5A52B589A4DD3C0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

You will find four comments numbered 1) to 4).

*1) *The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. *However, the 
header at the top of the page omits to mention it.

Currently, it is :

Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

Internet-Draft       OAuth *2.0* Access Token JWT Profile           
April 2020

*2)* The following text is within section 6.

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.
Nonetheless, authorization servers should
not assume that clients will comply with the above.

It is of a primary importance that clients MAY be able to inspect tokens 
before transmitting them.
The "MUST NOT" is not acceptable.

The above text should be replaced with:

Reading the access token content may be useful for the user to verify that
the access token content matches with its expectations.However,
the authorization server and the resource server might decide to change the
token format at any time.Thus, the client should not expect to always be
in a position to read the access token content.

The remaining of the text about this topic is fine.


*3) *The next topic is about the sub claim.

The text states:

Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

 1. How can authorization servers choose how to assign sub values
    according to the level of privacy required "by each situation" ?
 2. How can authorization servers know the level of privacy required "by
    each situation" ?
 3. How can the users be informed of the level of privacy required "by
    each situation" ?
 4. How can the users *consent* with the level of privacy required "by
    each situation" ?

Currently, the request MUST include either a resource parameter or an 
aud claim parameter, while it MAY include a scope parameter.

The syntax of the scope parameter is a list of space-delimited, 
case-sensitive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being 
returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub 
claim to contain :

  * a global unique identifier for all ASs ("globally unique"),
  * a unique identifier for each AS ("locally unique in the context of
    the issuer"),
  * a different pseudonym for each RS, or
  * a different pseudonym for each authorization token request.

The only variable parameter that it can use for this purpose in the 
token request is the scope parameter.

RFC 7519 states is section 4.1.2:

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

It is quite hard to recognize that the sub claim is able to carry a 
different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for 
case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

For instance: if a solution requires preventing 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.

Since it addresses case (c).

and also about the following text:

4.b) Similarly: if a solution requires preventing 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.

Since it addresses case (d).

This means that the current text placed in the privacy considerations 
section was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows to 
correlate principal activities across multiple resource servers, while 
in addition,
this globally unique identifier may also allow to correlate the 
principal activities on servers where no access has been performed by 
the principals
to these servers but where the same globally unique identifiers are 
being used by these servers.

When the sub claim contains a locally unique identifier in the context 
of the issuer, this also allows the tracking of principal activities 
across multiple resource servers.

The scope request parameter is the only way to influence on the content 
of the sub claim parameter. Its meaning is subject to a private agreement
between the client and the AS, which means that the use of the scope 
parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary importance 
that the returned scope matches with the expectations of the client 
before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able to 
choose whether it wishes the sub claim to contain :
- a different pseudonym for each RS so that different resource servers 
will be unable to correlate its activities, or
- a different pseudonym for each authorization token request, so that 
the same resource server cannot correlate its activities performed at 
different instant of time.

Considering the semantics of the sub claim, these two cases cannot be 
currently supported.


*4) *The next topic is about the targeting of access tokens

Text had been proposed before the last conference call. Then, the topic 
has been presented at the very end of the last conference call, but no 
text has been included
in the next draft.

Here is a revised text be included in the privacy considerations section:

For security reasons, some clients may be willing to target their access 
tokens but, for privacy reasons, may be unwilling to disclose to 
Authorization Servers
an identification of the Resource Servers they are going to access, so 
that Authorization Servers will be unable to know which resources 
servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization 
Servers to list all the Resource Servers being access by all its users 
and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users 
accesses to Resource Servers performed through a given Authorization 
Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis

> Hi all,
>
> This is a second working group last call for "JSON Web Token (JWT) 
> Profile for OAuth 2.0 Access Tokens".
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
> Regards,
>
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------1BDD8CF2A5A52B589A4DD3C0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
You will find four comments numbered 1)
      to 4). 

    

    

      
1) The
          title of this spec. is:

          

        JSON
          Web Token (JWT)
          Profile for OAuth 2.0 Access Tokens

          

          So, this spec. is supposed to be targeted to OAuth 2.0.  However, the header at the
          top of the page
          omits to mention it. 

          

          Currently, it is : 

      

        Internet-Draft       OAuth Access Token
          JWT Profile           April
          2020

        

      
It should rather be:

        

      
Internet-Draft       OAuth 2.0
          Access Token JWT
          Profile           April 2020

          

        2)
          The following text is within section 6.

          

        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.

          Nonetheless, authorization servers should

          not assume that clients will comply with the above.

        

      
It is of a primary importance that clients MAY be
          able to inspect tokens before transmitting them.

          The "MUST NOT" is not acceptable. 

        

      

         The above text
            should be replaced with:

          

        Reading the access token content may be
          useful for the user to verify
          that 

          the access token content matches with its expectations.  However, 

          the authorization server and the resource server might decide
          to change the 

          token format at any time.  Thus,
          the
          client should not expect to always be 

          in a position to read the access token content.

        

          The remaining of the text about this topic is fine.

          

          

          3) The next topic is about the sub claim.

          

          The text states:

          

        Although the ability to correlate requests
          might be required by

          design in many scenarios, there are scenarios where the
          authorization

          server might want to prevent correlation to preserve the
          desired

          level of privacy. Authorization servers should choose how to
          assign

          sub values according to the level of privacy required by each

          situation.

          

          I have a set of questions: 

        

      
    
        
  1. 
            How can authorization servers choose how to
            assign sub values according to the
            level of privacy required "by each situation" ?
    2. 
        
  2. How can authorization
            servers know the level
            of privacy required "by each situation" ? 
    3. 
        
  3. 
            How can the users be informed of the level of privacy
            required "by each
            situation" ?
    4. 
        
  4. 
            How can the users consent with the level of privacy
            required "by
            each situation" ?
    5. 
      

      

          Currently, the request MUST include either a resource
          parameter or an aud claim
          parameter, while it MAY include a scope parameter.

        

      
The syntax of the scope parameter is a list of
          space-delimited, case-sensitive
          strings (RFC 6749). It is thus subject to private agreements 

          between clients
          and Authorization
          Servers. Since the scope is being returned, it is a primary
          importance that the
          returned scope matches 

          with its expectations before transmitting the token to a
        Resource
          Server.

          

          In theory, a client should be able to choose whether it wishes
          the sub claim to
          contain :

        

      
    
        
  • 
            a global unique identifier for all ASs ("globally unique"),
    • 
        
  • 
            a unique identifier for each AS ("locally unique
            in the context of the
            issuer"),
    • 
        
  • 
            a different pseudonym for each RS, or 
    • 
        
  • 
            a different pseudonym for each authorization token request.
    • 
      

      

          The only variable parameter that it can use for this purpose
          in the token request is
          the scope parameter.

          

        RFC
          7519 states is
          section 4.1.2:

          

        The subject value MUST either be scoped to
          be locally unique in the
          context of the issuer 

          or be globally unique.

        

          It is quite hard to recognize that the sub claim is able to
          carry a
          different pseudonym for each RS, i.e. for case (c), or 

          a different pseudonym
          for each authorization
          token request, i.e. for case (d), which has nothing to do with
          uniqueness 

          since the value
          changes for every generated token.

          

        This has implications about the following
          text:

          

        For
          instance: if a
          solution requires preventing 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.

          

        Since it addresses case (c).

          

          and also about the following text:

          

        4.b)
          Similarly: if a
          solution requires preventing 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.

          

          Since it addresses case (d).

          

          This means that the current text placed in the privacy
          considerations section
          was a good attempt to address the case, 

          but that the text needs to be revised.

          

          Proposed text replacement for all the previously quoted
          sentences:

          

        
          According to RFC 7519
          (4.1.2): The subject value MUST either be scoped to be locally
          unique in the
          context of the issuer or be globally unique.

        
        

        
          When the sub claim contains a globally unique identifier, this allows to
        correlate principal
          activities across multiple resource servers, while in
          addition, 

          this globally unique identifier may also allow
          to correlate the
          principal activities on
          servers where no access has been performed by the principals 

          to these servers
          but where the same globally
          unique identifiers are being used by these servers. 

        
        

        
          When the sub claim contains a locally unique identifier in the context
          of the issuer, this also allows
          the tracking of principal activities across
          multiple resource servers.

        
        

        
          The scope request parameter is the only way to influence on
          the content of the
          sub claim parameter. Its meaning is subject to a private
          agreement 

          between the
          client and the AS, which means that the use of the scope
          parameter is the only
          way to choose between a locally
          unique identifier 

          in the context of the issuer or a globally unique
          identifier.

        
        

        
        Since the scope parameter is being
          returned, it is a primary importance
          that the returned scope matches with the expectations of the
          client before
          transmitting 

          the token to a Resource Server.

        
        

        
          However, there are other cases where the client would like to
          be able to choose
          whether it wishes the sub claim to contain : 

           
          - a different pseudonym for each RS so that different resource
          servers will be
          unable to correlate its activities, or

           
          - a different pseudonym for each authorization token request,
          so that the same
          resource server cannot correlate its activities performed at
          different instant
          of time. 

        
        

        
          Considering the semantics of the sub claim, these two cases
          cannot be currently
          supported.

        

          

          4) The next topic is about the targeting of access
          tokens

      
Text had been proposed before the last
            conference call. Then, the topic has been presented
          at the very end of the last conference call, but no text has
          been included 

          in the next draft. 

        

      
Here is a revised text be included in the privacy
          considerations section:

        

      

        For
          security reasons,
          some clients may be willing to target their access tokens but,
          for privacy
          reasons, may be unwilling to disclose to Authorization Servers
          

          an
          identification of the Resource Servers they are going to
          access, so that
          Authorization Servers will be unable to know which resources
          servers are being
          accessed. 

          The disclosure of the Resource
            Servers names allows the Authorization Servers to
          list all the Resource Servers being access by all its users
          and in addition to
          list pairs 

          of (Principal, Resource Servers) which allow to trace all the
          users
          accesses to Resource Servers performed through a
          given Authorization Server. When a token is
          targeted, 

          this profile does not contain provisions to address these two
          threats.

        
          

          Denis

    

    

      
      

        
Hi
          all,

        
 

        
This
          is a
          second working group last call for "JSON Web Token (JWT)
          Profile for OAuth
          2.0 Access Tokens".

        
 

        
Here
          is the
          document:

        
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

        
 

        
Please
          send
          your comments to the OAuth mailing list by April 29, 2020.

        
 

        
Regards,

        
 Rifaat
          & Hannes

        
 

      

      

      

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


    

    


    

  


--------------1BDD8CF2A5A52B589A4DD3C0--


From nobody Wed Apr 29 09:45:39 2020
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 BCB6A3A1415 for ; Wed, 29 Apr 2020 09:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gPcpcAh3jqxH for ; Wed, 29 Apr 2020 09:45:36 -0700 (PDT)
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 C7C423A1416 for ; Wed, 29 Apr 2020 09:45:35 -0700 (PDT)
Received: from [192.168.1.13] (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 03TGjViI027784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Apr 2020 12:45:31 -0400
From: Justin Richer 
Message-Id: <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5D183B4D-8F32-4D8B-B516-0E6C86EFE37F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 29 Apr 2020 12:45:31 -0400
In-Reply-To: 
Cc: oauth@ietf.org, Michael Richardson 
To: Daniel Migault 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [OAUTH-WG] carrying oauth authorisation without HTTP
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, 29 Apr 2020 16:45:38 -0000

--Apple-Mail=_5D183B4D-8F32-4D8B-B516-0E6C86EFE37F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It depends on what protocol you=E2=80=99re using on the socket =
connection between the client (the home router) and the RS/AS. You=E2=80=99=
ll need :someplace: to put the access token. RFC6750 and RFC8705 are =
explicitly about HTTP so you can=E2=80=99t use them directly, but other =
work (like that done in the ACE group with OSCORE) map the OAuth =
concepts to different underlying protocols.

 =E2=80=94 Justin

> On Apr 28, 2020, at 10:13 PM, Daniel Migault  =
wrote:
>=20
> Hi,
>=20
> I am completely new to oauth and would like to solicit the WG for =
advice.
>=20
> We are working on the Home Router outsourcing a service in the homenet =
WG and we are wondering how oauth could be used to improve automation.
>=20
> Our scenario is represented in the figure below:
>=20
> 1.  The end user connected to the web interface of the Home Router =20
> 2. The Home Router redirects the End User to the service provider =
where the end user register for that service ( AS ).
> 3. The AS providing an authorisation token carried to the RS via the =
Home Router to the RS.
>=20
> The session between the Home router and the RS in our case is not =
using HTTP but is using TLS. We are wondering if there is a way to carry =
an authorisation token over a non HTTP session and if RFC8705 "OAuth 2.0 =
Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" =
heads in to this direction.
>=20
> I am happy to hear any feed back or comments!
>=20
> Yours,
> Daniel
>=20
>=20
>       HTTPS            +-----------+
>    +------------------>|    AS     |<--------------+
>    |                   |           |               |
>    v                   +-----------+               v
> +-------------+ HTTPS  +-----------+    TLS    +---------+
> | User        |<------>|Home Router|<--------->|   RS    |
> |(Web Browser)|        |           |           |         |
> +-------------+        +-----------+           +---------+
>=20
> --=20
> Daniel Migault
> Ericsson
> 8400 boulevard Decarie
> Montreal, QC   H4P 2N2
> Canada
>=20
> Phone: +1 514-452-2160
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_5D183B4D-8F32-4D8B-B516-0E6C86EFE37F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It =
depends on what protocol you=E2=80=99re using on the socket connection =
between the client (the home router) and the RS/AS. You=E2=80=99ll need =
:someplace: to put the access token. RFC6750 and RFC8705 are explicitly =
about HTTP so you can=E2=80=99t use them directly, but other work (like =
that done in the ACE group with OSCORE) map the OAuth concepts to =
different underlying protocols.

 =E2=80=94 Justin

On Apr =
28, 2020, at 10:13 PM, Daniel Migault <mglt.biz@gmail.com> =
wrote:

Hi,

I am completely new to oauth and would like to solicit the WG =
for advice.

We are working on the Home =
Router outsourcing a service in the homenet WG and we are wondering how =
oauth could be used to improve automation.

Our scenario is represented in the figure below:

1.  The end user connected to the web =
interface of the Home Router  
2. The Home Router =
redirects the End User to the service provider where the end user =
register for that service ( AS ).
3. The AS providing an =
authorisation token carried to the RS via the Home Router to the RS.

The session between the Home router and the RS =
in our case is not using HTTP but is using TLS. We are wondering if =
there is a way to carry an authorisation token over a non HTTP session =
and if RFC8705 "OAuth 2.0 Mutual-TLS Client Authentication and =
Certificate-Bound Access Tokens" heads in to this direction.

I am happy to hear any feed back or =
comments!

Yours,
Daniel


      HTTPS           =
 +-----------+
   +------------------>| =
   AS     |<--------------+
  =
 |                   | =
          |           =
    |
   v         =
          +-----------+       =
        v
+-------------+ HTTPS =
 +-----------+    TLS    +---------+
| User        |<------>|Home =
Router|<--------->|   RS    |
|(Web =
Browser)|        |         =
  |           |       =
  |
+-------------+       =
 +-----------+           =
+---------+

-- 
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC   =
H4P 2N2
Canada

Phone: +1 =
514-452-2160


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

=

--Apple-Mail=_5D183B4D-8F32-4D8B-B516-0E6C86EFE37F--


From nobody Wed Apr 29 09:54:28 2020
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 895F33A1437 for ; Wed, 29 Apr 2020 09:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 N3c02A2q7BXn for ; Wed, 29 Apr 2020 09:54:24 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 9B6A23A1432 for ; Wed, 29 Apr 2020 09:54:18 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id i10so3383419wrv.10 for ; Wed, 29 Apr 2020 09:54:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ZXb/500ybxLAovffzh0DKWJPCC92Itq+l8DgwRGIISc=; b=CeEXyEOL71vc3kqyS2+Od3hL1PLbs7s3kzqekZBP4PrS4iVzIUhJEPHudb5WRC5AJ6 r//hJET1XQZAm2SI9c2vke4/60qHBCmPUrCve1nR384Dbgj7gXrP6wG/pJVFlvCNehfX FWsWpvYtb5YIFipee+E1FaloiXSrMWwTzEILI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ZXb/500ybxLAovffzh0DKWJPCC92Itq+l8DgwRGIISc=; b=FCE9SXh2HzUjLdN+Ln1Pa4FBhAEYFAodipfybLw5VrnLcxiD3uJpfR72NcHLO2fytQ yU8M3iYWJzIqJOMAEEJU2PxRQcNQNn3cIWJuryHCJjLj3ORqiQlBOKvvh/FwP8pp76ly rIPh378ZuJpc5mtyu0H78tbhkHI6KiPXzTejUtg+HV5jYy/IneK+mTSzl6s2TYbB/UCS w8G7AM0LwfizS6nkgJ7TzFqZ5A/gOQbLuGNwvCwiYa/n9ERsWaD7zU6nMhxbt+L1HN3S ZPyh6k3HRf9LVCvTifnF+h/FIbJ6br1C2UoxEC3JMyPO6PzAafmj+5ARZlBRVhuhvsHy aShw==
X-Gm-Message-State: AGi0PuZZISfrgAq4xCj6sgzJ/Buu1hlPJ9i0bXO0svqtOnmecjSs+swt mbMJ9sEbM9zMIKGS7j7LDYwj1w==
X-Google-Smtp-Source: APiQypLbl6TFfyIMKnlekHZD7UXFMR5v3W6XyLmZanIl9WSojyal9ka4bQovCdcsaqFV9NI7pgxf1A==
X-Received: by 2002:a5d:4dcb:: with SMTP id f11mr39510034wru.174.1588179256858;  Wed, 29 Apr 2020 09:54:16 -0700 (PDT)
Received: from [10.0.0.3] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id a1sm31341106wrn.80.2020.04.29.09.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2020 09:54:16 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-82CD2DA4-E836-472B-A7EB-453F6E99EC99
Content-Transfer-Encoding: 7bit
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Wed, 29 Apr 2020 17:54:14 +0100
Message-Id: 
References: <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu>
Cc: Daniel Migault , oauth@ietf.org, Michael Richardson 
In-Reply-To: <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu>
To: Justin Richer 
X-Mailer: iPhone Mail (17D50)
Archived-At: 
Subject: Re: [OAUTH-WG] carrying oauth authorisation without HTTP
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, 29 Apr 2020 16:54:27 -0000

--Apple-Mail-82CD2DA4-E836-472B-A7EB-453F6E99EC99
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

There is also https://tools.ietf.org/html/rfc7628

> On 29 Apr 2020, at 17:45, Justin Richer  wrote:
>=20
> =EF=BB=BFIt depends on what protocol you=E2=80=99re using on the socket co=
nnection between the client (the home router) and the RS/AS. You=E2=80=99ll n=
eed :someplace: to put the access token. RFC6750 and RFC8705 are explicitly a=
bout HTTP so you can=E2=80=99t use them directly, but other work (like that d=
one in the ACE group with OSCORE) map the OAuth concepts to different underl=
ying protocols.
>=20
>  =E2=80=94 Justin
>=20
>> On Apr 28, 2020, at 10:13 PM, Daniel Migault  wrote:
>>=20
>> Hi,
>>=20
>> I am completely new to oauth and would like to solicit the WG for advice.=

>>=20
>> We are working on the Home Router outsourcing a service in the homenet WG=
 and we are wondering how oauth could be used to improve automation.
>>=20
>> Our scenario is represented in the figure below:
>>=20
>> 1.  The end user connected to the web interface of the Home Router =20
>> 2. The Home Router redirects the End User to the service provider where t=
he end user register for that service ( AS ).
>> 3. The AS providing an authorisation token carried to the RS via the Home=
 Router to the RS.
>>=20
>> The session between the Home router and the RS in our case is not using H=
TTP but is using TLS. We are wondering if there is a way to carry an authori=
sation token over a non HTTP session and if RFC8705 "OAuth 2.0 Mutual-TLS Cl=
ient Authentication and Certificate-Bound Access Tokens" heads in to this di=
rection.
>>=20
>> I am happy to hear any feed back or comments!
>>=20
>> Yours,
>> Daniel
>>=20
>>=20
>>       HTTPS            +-----------+
>>    +------------------>|    AS     |<--------------+
>>    |                   |           |               |
>>    v                   +-----------+               v
>> +-------------+ HTTPS  +-----------+    TLS    +---------+
>> | User        |<------>|Home Router|<--------->|   RS    |
>> |(Web Browser)|        |           |           |         |
>> +-------------+        +-----------+           +---------+
>>=20
>> --=20
>> Daniel Migault
>> Ericsson
>> 8400 boulevard Decarie
>> Montreal, QC   H4P 2N2
>> Canada
>>=20
>> Phone: +1 514-452-2160
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-82CD2DA4-E836-472B-A7EB-453F6E99EC99
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 29 Apr 2020, at 1=
7:45, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFIt depends on what protoco=
l you=E2=80=99re using on the socket connection between the client (the home=
 router) and the RS/AS. You=E2=80=99ll need :someplace: to put the access to=
ken. RFC6750 and RFC8705 are explicitly about HTTP so you can=E2=80=99t use t=
hem directly, but other work (like that done in the ACE group with OSCORE) m=
ap the OAuth concepts to different underlying protocols.

 =E2=80=94 Justin
On Apr 28,=
 2020, at 10:13 PM, Daniel Migault <mglt.biz@gmail.com> wrote:

Hi,

I am completely new to oauth and would like t=
o solicit the WG for advice.

We are working on t=
he Home Router outsourcing a service in the homenet WG and we are wondering h=
ow oauth could be used to improve automation.

O=
ur scenario is represented in the figure below:

1.  The end user connected to the web interface of the Home Router &nb=
sp;
2. The Home Router redirects the End User to the service p=
rovider where the end user register for that service ( AS ).
3=
. The AS providing an authorisation token carried to the RS via the Home Rou=
ter to the RS.

The session between the Home rou=
ter and the RS in our case is not using HTTP but is using TLS. We are wonder=
ing if there is a way to carry an authorisation token over a non HTTP sessio=
n and if RFC8705 "OAuth 2.0 Mutual-TLS Client Authentication and Certificate=
-Bound Access Tokens" heads in to this direction.

I am happy to hear any feed back or comments!

Yours,
Daniel


      HTTPS     &=
nbsp;      +-----------+
   +--------=
---------->|    AS     |<--------------+
   |                 &n=
bsp; |           |         &nbs=
p;     |
   v         &=
nbsp;         +-----------+         &=
nbsp;     v
+-------------+ HTTPS  +-----------=
+    TLS    +---------+
| User   &nbs=
p;    |<------>|Home Router|<--------->|   RS &nb=
sp;  |
|(Web Browser)|        |  =
;         |           |   &=
nbsp;     |
+-------------+       &nb=
sp;+-----------+           +---------+

-- 
=

Daniel Migault
Ericsson<=
br class=3D"">8400 boulevard Decarie
Montreal, QC   H=
4P 2N2
Canada

Phone: +1 514-452-2=
160


_______________________________________________
OAuth mailing l=
ist
OAuth@ietf.or=
g
https://www.ietf.org/mailman/listinfo/oauth

______________________=
_________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/span>
=

--Apple-Mail-82CD2DA4-E836-472B-A7EB-453F6E99EC99--


From nobody Wed Apr 29 10:40:31 2020
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 387BB3A14BC for ; Wed, 29 Apr 2020 10:40:29 -0700 (PDT)
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 iSXEGqcyU9HY for ; Wed, 29 Apr 2020 10:40:26 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 E5FA63A14BD for ; Wed, 29 Apr 2020 10:40:25 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id e22so1957430vsa.12 for ; Wed, 29 Apr 2020 10:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=laOID5qgKnZFu0QSXqnthqxcZMs1FXNFsCgG/6P/Hzg=; b=rVvphk2iS8Neh3wZTXawRn1AlF6nIX475Ur0h4eYyJTg5AKJI5cS1+mQaZKvXPi7Lk LwJOo1rsX5qyy9vTBl0toUr7AxmM2v96rTih+PjV25brzp5HA870ScrDaw0F4ZqiOvA6 Zy5BvDyvYzhtso+ydmIatUMP8/n0vtMm7kkuQmUa2b7IKCUeN5f76MDq9daKEHg2OaSt VOz2+mkbP87HNC0rZwAcp0cvwK/8GZVCNQU6b4cCReoQIoRcLl0N+DgIK0oBT7sWaP6o OBvmP/O2nktt7uwoWMi4C80J7zSU7ffk6REfquVj0TkvqXhK7ZKDoVuIYw2GOll94Lk7 Goig==
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=laOID5qgKnZFu0QSXqnthqxcZMs1FXNFsCgG/6P/Hzg=; b=oltVhtai9wU0W/VZoQk2hvn8zXbsVqlr7FQ0wd73BabEgUkx1tA3Rz9MfQcMhy0yJd DBNURYznYqi4cSriOJ+2FyOO42uzqm3+xr7K4FFvPJC6N4a690bg53oUjQGlRI8bgXvv EAcCZBuHaYeF+biASowDF/q61fhSgyG9jJToCnWqoFEpN3iXCXLwxsxXrD60Vdnok3Jm vfLGji8VMr7K6z4TybobrV/MWAxgT1kGvea6AkdctokpzXqRcGKRsQF0DZqS5iMn49Ff PZEdn9xn+boXd+Hx/4THvnasQYuG6yWZRcTHdn04vb/pKqg9oWbiRMx+A+RyUDT6FSJZ XohA==
X-Gm-Message-State: AGi0PuagZYoktD2XrU30fpkaBDrjs8GtqTIhg+T2jRnHUP+B8+QjkAwh lCj+PTMilaje6x2VeHf7wLsy+JSnlLFYHKXPXPU=
X-Google-Smtp-Source: APiQypI6t05x5z1C5KDdyh4uidlwXhEAKueKhuO2Fy4NqvX8YEoteyMTU+1o1sJHYbpojSKJnczVsjKUdpnodgdNd1s=
X-Received: by 2002:a05:6102:208f:: with SMTP id h15mr2727119vsr.69.1588182024918;  Wed, 29 Apr 2020 10:40:24 -0700 (PDT)
MIME-Version: 1.0
References:  <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu>
In-Reply-To: <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu>
From: Daniel Migault 
Date: Wed, 29 Apr 2020 13:40:13 -0400
Message-ID: 
To: Justin Richer 
Cc: Daniel Migault , oauth@ietf.org,  Michael Richardson 
Content-Type: multipart/alternative; boundary="0000000000006f1e2605a47171b8"
Archived-At: 
Subject: Re: [OAUTH-WG] carrying oauth authorisation without HTTP
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, 29 Apr 2020 17:40:29 -0000

--0000000000006f1e2605a47171b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the feed back. So in our case the communication between the Home
router and the RS is DNS over TLS, so no HTTP, CoAP. We do not have hard
constraint over the protocol being used between the Home Router and the AS.
Currently there is no such communication.

One possible solution would be to have the Home Router using a mutual TLS
authentication to provide its certificate which is then passed to the RS.

Yours,
Daniel

On Wed, Apr 29, 2020 at 12:45 PM Justin Richer  wrote:

> It depends on what protocol you=E2=80=99re using on the socket connection=
 between
> the client (the home router) and the RS/AS. You=E2=80=99ll need :someplac=
e: to put
> the access token. RFC6750 and RFC8705 are explicitly about HTTP so you
> can=E2=80=99t use them directly, but other work (like that done in the AC=
E group
> with OSCORE) map the OAuth concepts to different underlying protocols.
>
>  =E2=80=94 Justin
>
> On Apr 28, 2020, at 10:13 PM, Daniel Migault  wrote:
>
> Hi,
>
> I am completely new to oauth and would like to solicit the WG for advice.
>
> We are working on the Home Router outsourcing a service in the homenet WG
> and we are wondering how oauth could be used to improve automation.
>
> Our scenario is represented in the figure below:
>
> 1.  The end user connected to the web interface of the Home Router
> 2. The Home Router redirects the End User to the service provider where
> the end user register for that service ( AS ).
> 3. The AS providing an authorisation token carried to the RS via the Home
> Router to the RS.
>
> The session between the Home router and the RS in our case is not using
> HTTP but is using TLS. We are wondering if there is a way to carry an
> authorisation token over a non HTTP session and if RFC8705 "OAuth 2.0
> Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" hea=
ds
> in to this direction.
>
> I am happy to hear any feed back or comments!
>
> Yours,
> Daniel
>
>
>       HTTPS            +-----------+
>    +------------------>|    AS     |<--------------+
>    |                   |           |               |
>    v                   +-----------+               v
> +-------------+ HTTPS  +-----------+    TLS    +---------+
> | User        |<------>|Home Router|<--------->|   RS    |
> |(Web Browser)|        |           |           |         |
> +-------------+        +-----------+           +---------+
>
> --
> Daniel Migault
> Ericsson
> 8400 boulevard Decarie
> Montreal, QC   H4P 2N2
> Canada
>
> Phone: +1 514-452-2160
>
> _______________________________________________
> 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
Daniel Migault
Ericsson

--0000000000006f1e2605a47171b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the feed back. So in our case the communication=
 between the Home router and the RS is DNS over TLS, so no HTTP, CoAP. We d=
o not have hard constraint over the protocol being used between the Home Ro=
uter and the AS. Currently=C2=A0there is no such communication.
=C2=A0<=
div>One possible solution would=C2=A0be to have the Home Router using a mut=
ual TLS authentication to provide its certificate which is then passed to t=
he RS.=C2=A0

Yours,=C2=A0
Daniel=C2=A0=C2=A0

On Wed, Apr 29, 2020 at 12:45 PM Justin Richer <jricher@mit.edu> wrote:
On Apr 28, 2020, at 10:13 PM, Daniel Migault <<=
a href=3D"mailto:mglt.biz@gmail.com" target=3D"_blank">mglt.biz@gmail.com> wrote:

Hi,

I am complet=
ely new to oauth and would like to solicit the WG for advice.

We are=
 working on the Home Router outsourcing a service in the homenet WG and we =
are wondering how oauth could be used to improve automation.

Our sce=
nario is represented in the figure below:

1.=C2=A0 The end user conn=
ected to the web interface of the Home Router =C2=A0
2. The Home Router =
redirects the End User to the service provider where the end user register =
for that service ( AS ).
3. The AS providing an authorisation token carr=
ied to the RS via the Home Router to the RS.

The session between the=
 Home router and the RS in our case is not using HTTP but is using TLS. We =
are wondering if there is a way to carry an authorisation token over a non =
HTTP session and if RFC8705 "OAuth 2.0 Mutual-TLS Client Authenticatio=
n and Certificate-Bound Access Tokens" heads in to this direction.
=

I am happy to hear any feed back or comments!

Yours,
Daniel

=C2=A0 =C2=A0 =C2=A0 HTTPS =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+
=C2=A0 =C2=A0+----------------=
-->| =C2=A0 =C2=A0AS =C2=A0 =C2=A0 |<--------------+
=C2=A0 =C2=A0=
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |
=C2=A0 =C2=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 +-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 v
+-------------+ HTTPS =C2=A0+-----------+ =C2=A0 =C2=A0TLS =C2=A0 =
=C2=A0+---------+
| User =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------>|Home=
 Router|<--------->| =C2=A0 RS =C2=A0 =C2=A0|
|(Web Browser)| =C2=
=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------+=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 +---------+

-- 
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC=C2=A0=C2=A0 H4P 2N2Canada

Phone: +1 514-452-2160

=


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




-- 
Daniel Migault
Ericsson


--0000000000006f1e2605a47171b8--


From nobody Wed Apr 29 10:57:44 2020
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 9E6143A0872 for ; Wed, 29 Apr 2020 10:57:41 -0700 (PDT)
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 LZwtwr9mb9z8 for ; Wed, 29 Apr 2020 10:57:39 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 5E9903A150B for ; Wed, 29 Apr 2020 10:57:11 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id s11so1995549vsq.13 for ; Wed, 29 Apr 2020 10:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dAsSx2FK6KtnBwTwyD0ld7URaKWH/Go7PG/swwxlbJs=; b=lydoq5a5tBONfwQxRP5uCbtw3hvyEY+Q8c/lCf2i56pK9+Cb5pMp9v/TtyN4XPaQqU r6Yv45jAzSPserluZBdq3ZH9WbZj/0cNStbq0cbS3evX+DBx5qLTgJe36jcfZV8dxYee RlWiJn1atJVm3Jrx8bIfx/qI0XeOBXDfuiVfWZeOABGryjCrCHyd7NuIeN5WP6GJhDBS llyxZ8Jqf03xNOXsGRuWhRcmjGYbPEYAXtwchKFK0swSUVgwEegQb6hT+YqOP1jOe4Tm WEwPkeZLzcQSsXf+ui/opBBsSZeqOZh/QBB03Fdphc73DkroNYAsvKI+yK+Ab6Z04LzS JyKQ==
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=dAsSx2FK6KtnBwTwyD0ld7URaKWH/Go7PG/swwxlbJs=; b=b27dln2XwCCCU4VGySwze4PHkWmIQmt/EwwesTW4DaC3sE1JRKkc6YZYVUvh5WLUHL R/4BoF29PE5SvfLyUDUPswp6KQ0T9UfJ+pZlDwtAb+kE7CFUaCdrmZs52m4RCAB72Rix 7NLUesKJ2ZsbnfbsTKzaTvuRjOOQ/Hp4b+CamURapT0qPpbTKDtMGM3RqsDKrj5Wb+7u OLwvSp/XMNy7DsKSuxbDSFVMBVAh9c+wt95CN/5UYWHBeLa8WOmf9m1zeAhlJiOyNZW1 rpzOQw4WGanG7vf6+HRB+oQz8gszGRvPyQcLnFl9cTf9ijd78nUDQeLj3yyldqxZDeIg OnfQ==
X-Gm-Message-State: AGi0PubJnc/q/NbdY8Y30n8vKP9POonN1M3/54bRy48Xc2HNpbpeANYJ qxbscmTtn8+nJmPMK/zjQVhsrxYTgKCpGGRJZ9g=
X-Google-Smtp-Source: APiQypJF2yqc70trseJeqt5br8iBLBeISGn+D+ULzkJbqBRup0CDvG+x4jP/pJ6zE62OLcPY7/qP+mEDqX6quKBYNsI=
X-Received: by 2002:a67:fc46:: with SMTP id p6mr28630723vsq.169.1588183030384;  Wed, 29 Apr 2020 10:57:10 -0700 (PDT)
MIME-Version: 1.0
References: <4EC0BF76-4745-40AC-BF22-3BA29B3DD3DC@mit.edu> 
In-Reply-To: 
From: Daniel Migault 
Date: Wed, 29 Apr 2020 13:56:59 -0400
Message-ID: 
To: Neil Madden 
Cc: Justin Richer , oauth@ietf.org, Michael Richardson 
Content-Type: multipart/alternative; boundary="0000000000005d49b905a471ade6"
Archived-At: 
Subject: Re: [OAUTH-WG] carrying oauth authorisation without HTTP
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, 29 Apr 2020 17:57:42 -0000

--0000000000005d49b905a471ade6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the feed back. I have the impression that in our case, SASL
might not be viable as our primary communication is DNS over TLS. But that
is good to know anyway.

Yours,
Daniel

On Wed, Apr 29, 2020 at 12:54 PM Neil Madden 
wrote:

> There is also https://tools.ietf.org/html/rfc7628
>
> On 29 Apr 2020, at 17:45, Justin Richer  wrote:
>
> =EF=BB=BFIt depends on what protocol you=E2=80=99re using on the socket c=
onnection between
> the client (the home router) and the RS/AS. You=E2=80=99ll need :someplac=
e: to put
> the access token. RFC6750 and RFC8705 are explicitly about HTTP so you
> can=E2=80=99t use them directly, but other work (like that done in the AC=
E group
> with OSCORE) map the OAuth concepts to different underlying protocols.
>
>  =E2=80=94 Justin
>
> On Apr 28, 2020, at 10:13 PM, Daniel Migault  wrote:
>
> Hi,
>
> I am completely new to oauth and would like to solicit the WG for advice.
>
> We are working on the Home Router outsourcing a service in the homenet WG
> and we are wondering how oauth could be used to improve automation.
>
> Our scenario is represented in the figure below:
>
> 1.  The end user connected to the web interface of the Home Router
> 2. The Home Router redirects the End User to the service provider where
> the end user register for that service ( AS ).
> 3.. The AS providing an authorisation token carried to the RS via the Hom=
e
> Router to the RS.
>
> The session between the Home router and the RS in our case is not using
> HTTP but is using TLS. We are wondering if there is a way to carry an
> authorisation token over a non HTTP session and if RFC8705 "OAuth 2.0
> Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" hea=
ds
> in to this direction.
>
> I am happy to hear any feed back or comments!
>
> Yours,
> Daniel
>
>
>       HTTPS            +-----------+
>    +------------------>|    AS     |<--------------+
>    |                   |           |               |
>    v                   +-----------+               v
> +-------------+ HTTPS  +-----------+    TLS    +---------+
> | User        |<------>|Home Router|<--------->|   RS    |
> |(Web Browser)|        |           |           |         |
> +-------------+        +-----------+           +---------+
>
> --
> Daniel Migault
> Ericsson
> 8400 boulevard Decarie
> Montreal, QC   H4P 2N2
> Canada
>
> Phone: +1 514-452-2160
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Daniel Migault
Ericsson

--0000000000005d49b905a471ade6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the feed back. I have the impression that in ou=
r case, SASL might not be viable as our primary communication is DNS over T=
LS. But that is good to know anyway.

Yours,=C2=A0
Da=
niel=C2=A0

On Wed, Apr 29, 2020 at 12:54 PM Neil Madden <neil.madden@forgerock.com> =
wrote:
=EF=BB=BFIt depends on what protocol you=E2=80=
=99re using on the socket connection between the client (the home router) a=
nd the RS/AS. You=E2=80=99ll need :someplace: to put the access token. RFC6=
750 and RFC8705 are explicitly about HTTP so you can=E2=80=99t use them dir=
ectly, but other work (like that done in the ACE group with OSCORE) map the=
 OAuth concepts to different underlying protocols.

=C2=
=A0=E2=80=94 Justin

On Apr 28, 2=
020, at 10:13 PM, Daniel Migault <mglt.biz@gmail.com> wrote:

Hi,

I am completely new to oauth and would like to s=
olicit the WG for advice.

We are working on the Home Router outsourc=
ing a service in the homenet WG and we are wondering how oauth could be use=
d to improve automation.

Our scenario is represented in the figure b=
elow:

1.=C2=A0 The end user connected to the web interface of the Ho=
me Router =C2=A0
2. The Home Router redirects the End User to the servic=
e provider where the end user register for that service ( AS ).
3.. The =
AS providing an authorisation token carried to the RS via the Home Router t=
o the RS.

The session between the Home router and the RS in our case=
 is not using HTTP but is using TLS. We are wondering if there is a way to =
carry an authorisation token over a non HTTP session and if RFC8705 "O=
Auth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Toke=
ns" heads in to this direction.

I am happy to hear any feed bac=
k or comments!

Yours,
Daniel


=
=C2=A0 =C2=A0 =C2=A0 HTTPS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------=
-----+
=C2=A0 =C2=A0+------------------>| =C2=A0 =C2=A0AS =C2=A0 =C2=
=A0 |<--------------+
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0v =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+ =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
+-------------+ HTTPS =
=C2=A0+-----------+ =C2=A0 =C2=A0TLS =C2=A0 =C2=A0+---------+
| User =C2=
=A0 =C2=A0 =C2=A0 =C2=A0|<------>|Home Router|<--------->| =C2=
=A0 RS =C2=A0 =C2=A0|
|(Web Browser)| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+-=
----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+

-- 
Daniel Migault
Ericsson
8400 boulevard De=
carie
Montreal, QC=C2=A0=C2=A0 H4P 2N2
Canada

Phone: +1 514-45=
2-2160


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma=
n/listinfo/oauth
___________________=
____________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




-- 
Daniel Migault
Ericsson


--0000000000005d49b905a471ade6--


From nobody Wed Apr 29 10:57:53 2020
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 820BE3A153A for ; Wed, 29 Apr 2020 10:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.063
X-Spam-Level: 
X-Spam-Status: No, score=-0.063 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, LONGWORDS=2.035, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wxdWp5xFqXNR for ; Wed, 29 Apr 2020 10:57:43 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 7F1793A1518 for ; Wed, 29 Apr 2020 10:57:36 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id a5so1083537pjh.2 for ; Wed, 29 Apr 2020 10:57:36 -0700 (PDT)
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 :mime-version; bh=fPCJFD3ZozBJLDPh58gK/a9yPRLal/F6f+eArmivx34=; b=U+RjS7c9lTRveJ3BAdN3pD9i5PN6SlifEXgLr/W+4IQ/Bgorc1Wl/hU5qVa1uO34dZ FANJu0JPqBbhwLJd2BeIXuW7aK//g57o0xRSfOVIwTdqciExoWh4P4aUC+pGxkVT5D12 ufF2hxXUSs5h+qiMUvDFP6El3LZs0OyIe1pn5rQ9FqjCNxBpsDshfqlF981CVI72isWk NYGJwVPqQIsbJLh9PxLW7OJ79xecAHM2bd/b73IWg4QQ9tnYpFCXK5D9vUrNSTgAYcfe EvG5S/l7Hn3aQVQGZVfhAJhl4DbhkcQvhUnBmmZkIcdl9wDrHIvL3hD3CPhTGKSv+7Yj VoJw==
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 :mime-version; bh=fPCJFD3ZozBJLDPh58gK/a9yPRLal/F6f+eArmivx34=; b=XRWK8L2SjAyiDFVfHfXdR0KvI1hROYP7d9UAN3kmzu7fhuJIRxAPxc3Xjubryn8TYo HcbtZFGIdUH2zCi3hvjn10WzSchGKIfgC+xYxeAZRpsOkCYUFNfZ9nC5M9yqvjb7blmN Lfl4cMOYNLfS+PGTMhLd7Sl+lL0WC+8G6zcUWuRMt7RV/8inrgc4J1xLQ5ygK09MWMx3 O1LflMSGADwM9IG9ZxG6jAp/3eCYHVOPMN8ggx6qJkaoN2DO/hMRle4wiQmsfm+YBxAC ZHur0K/CNYysx+QmbOxbWREVwWQJWzwZXXRK5ZZDkkLgu+2v/v/mnXvClk0rh9IE/BLe yGUg==
X-Gm-Message-State: AGi0PuZot6YjJARa2vXdTReazXvydhcIUG1ZXyseLe+pQT2/tQ/lsDzB KUt2yNHaBy+VEsQXnssD0JjHGg==
X-Google-Smtp-Source: APiQypJCn74VZk7S/awkhtxUL3a1X0LWOrHplFhBtTWZCHGmZRTWdwMGrJwuyG4ji5gFvk2Wrjrfpw==
X-Received: by 2002:a17:90a:e2c1:: with SMTP id fr1mr4569536pjb.124.1588183055187;  Wed, 29 Apr 2020 10:57:35 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id h14sm4897405pjc.46.2020.04.29.10.57.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 10:57:33 -0700 (PDT)
From: Vittorio Bertocci 
To: Denis , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AUFRa29UzLyu7kLPs7J/StHwRJR9eGVjNzMzpm6ur9s=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 29 Apr 2020 17:57:26 +0000
Message-ID: 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>
In-Reply-To: <125f32d3-dd3b-3add-1172-391acd831cde@free.fr>
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_MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 29 Apr 2020 17:57:51 -0000

--_000_MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0MWHPR19MB1501namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks Denis for the thorough commentary.

> The title of this spec.
Fixed, thanks!

> The client MUST NOT inspect the content of the access token
This is really a sticky point. I really want to acknowledge your PoV on thi=
s, but at the same time I found this to be one of the biggest sources of is=
sues in the use of JWT for access tokens hence I feel we really need to giv=
e solid guidance here. Let me expand further on the reasoning behind it, an=
d perhaps we can get to language that satisfies both PoVs.
To me the key point is that clients should not write code that inspects acc=
ess tokens. Taking a dependency on the ability to do so is ignoring fundame=
ntal information about the architecture and relationships between OAuth rol=
es, and suggests an ability of the client to understand the semantic of the=
 content that cannot be assumed in the general case. I expanded on the deta=
ils in my former reply to you on this topic, I would recommend referring to=
 it. Clients violating this simple principle has been one of the most commo=
n sources of production issues I had to deal with in the past few years, an=
d one of the hardest to remediate given that clients are hard to update and=
 sometimes the things they relied on were irremediably lost. This is why I =
am inclined to put in here strong language.
That said: I have nothing against client developers examining a network tra=
ce and drawing conclusions based on the content of what they see. That does=
n=92t create any hard dependencies and has no implications in respect to ch=
anges in the solution behavior. However I am not sure how to phrase that in=
 the specification, given that referring to the client inevitably refers to=
 its code. I am open to suggestions.

>  3)=85
I have a pretty hard time following the chain of reasoning in this section.=
 Let me attempt to tackle it to the best of my understanding.
I think the key might be
> a client should be able to choose whether it wishes the sub claim to cont=
ain [..]
I don=92t think that should be a choice left to the client. In business sys=
tems, my experience is that the type of identifiers to be used (when the Id=
P gives any choice at all)  is established at resource provisioning time. I=
 am not aware of mechanisms thru which a client signals the nature of the i=
dentifier to be used, nor that would be fully feasible (the resource knows =
what it needs to perform its function).
Furthermore:
> which has nothing to do with uniqueness since the value changes for every=
 generated token.
Again, this is something that was touched on in my former reply to your mes=
sage. As long as an identifier identifies one resource only, it satisfies u=
niqueness. It doesn=92t have to be a singleton.
Finally, the scope is optional (for good reasons: 1st party and non delegat=
ion scenarios don=92t require it) hence it cannot be relied upon for proper=
ties that should hold in every scenario.
In summary: per the preceding thread on this topic, the consensus was that =
varying the sub content was a satisfactory way of protecting against correl=
ation. I don=92t a gree that clients should have a mechanism to request dif=
ferent sub flavors, as that decision should be done out of band by the AS a=
nd RS; and the scope isn=92t always available anyway.
> targeting of access tokens
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the effect of =
letting the AS track when the client accesses a particular resource, but at=
 the same time that=92s completely mainstream and very much by design in a =
very large number of cases. As such, I find the language you are suggesting=
 to be potentially confusing, as it positions this as an exception vs a pri=
vacy protecting mainstream that is in fact not common, and ascribes to the =
client more latitude than I believe is legitimate to expect or grant.
I=92ll try to come up with concise language that clarifies to the reader th=
at the current mechanism does allow AS tracking.

From: OAuth  on behalf of Denis 
Date: Wednesday, April 29, 2020 at 09:12
To: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OA=
uth 2.0 Access Tokens"

You will find four comments numbered 1) to 4).
1) The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

So, this spec. is supposed to be targeted to OAuth 2.0.  However, the heade=
r at the top of the page omits to mention it.

Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           April 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           April 202=
0

2) The following text is within section 6.

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.
Nonetheless, authorization servers should
not assume that clients will comply with the above.
It is of a primary importance that clients MAY be able to inspect tokens be=
fore transmitting them.
The "MUST NOT" is not acceptable.
The above text should be replaced with:

Reading the access token content may be useful for the user to verify that
the access token content matches with its expectations.  However,
the authorization server and the resource server might decide to change the
token format at any time.  Thus, the client should not expect to always be
in a position to read the access token content.

The remaining of the text about this topic is fine.


3) The next topic is about the sub claim.

The text states:

Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

  1.  How can authorization servers choose how to assign sub values accordi=
ng to the level of privacy required "by each situation" ?
  2.  How can authorization servers know the level of privacy required "by =
each situation" ?
  3.  How can the users be informed of the level of privacy required "by ea=
ch situation" ?
  4.  How can the users consent with the level of privacy required "by each=
 situation" ?
Currently, the request MUST include either a resource parameter or an aud c=
laim parameter, while it MAY include a scope parameter.
The syntax of the scope parameter is a list of space-delimited, case-sensit=
ive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being returne=
d, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub clai=
m to contain :

  *   a global unique identifier for all ASs ("globally unique"),
  *   a unique identifier for each AS ("locally unique in the context of th=
e issuer"),
  *   a different pseudonym for each RS, or
  *   a different pseudonym for each authorization token request.
The only variable parameter that it can use for this purpose in the token r=
equest is the scope parameter.

RFC 7519 states is section 4.1.2:

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

It is quite hard to recognize that the sub claim is able to carry a differe=
nt pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for case (=
d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

For instance: if a solution requires preventing 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.

Since it addresses case (c).

and also about the following text:

4.b) Similarly: if a solution requires preventing a resource server from
correlating the principal=92s activity within the resource itself, the
authorization server should assign different sub values for every JWT
access token issued.

Since it addresses case (d).

This means that the current text placed in the privacy considerations secti=
on was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped to b=
e locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows to co=
rrelate principal activities across multiple resource servers, while in add=
ition,
this globally unique identifier may also allow to correlate the principal a=
ctivities on servers where no access has been performed by the principals
to these servers but where the same globally unique identifiers are being u=
sed by these servers.

When the sub claim contains a locally unique identifier in the context of t=
he issuer, this also allows the tracking of principal activities across mul=
tiple resource servers.

The scope request parameter is the only way to influence on the content of =
the sub claim parameter. Its meaning is subject to a private agreement
between the client and the AS, which means that the use of the scope parame=
ter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary importance tha=
t the returned scope matches with the expectations of the client before tra=
nsmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able to ch=
oose whether it wishes the sub claim to contain :
    - a different pseudonym for each RS so that different resource servers =
will be unable to correlate its activities, or
    - a different pseudonym for each authorization token request, so that t=
he same resource server cannot correlate its activities performed at differ=
ent instant of time.

Considering the semantics of the sub claim, these two cases cannot be curre=
ntly supported.


4) The next topic is about the targeting of access tokens
Text had been proposed before the last conference call. Then, the topic has=
 been presented at the very end of the last conference call, but no text ha=
s been included
in the next draft.
Here is a revised text be included in the privacy considerations section:
For security reasons, some clients may be willing to target their access to=
kens but, for privacy reasons, may be unwilling to disclose to Authorizatio=
n Servers
an identification of the Resource Servers they are going to access, so that=
 Authorization Servers will be unable to know which resources servers are b=
eing accessed.
The disclosure of the Resource Servers names allows the Authorization Serve=
rs to list all the Resource Servers being access by all its users and in ad=
dition to list pairs
of (Principal, Resource Servers) which allow to trace all the users accesse=
s to Resource Servers performed through a given Authorization Server. When =
a token is targeted,
this profile does not contain provisions to address these two threats.

Denis
Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile =
for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



--_000_MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0MWHPR19MB1501namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Thanks Denis for the thorough commentary.=



 


> The title of this spec.


Fixed, thanks!


 


> The client MUST NOT inspect the content of t=
he access token


This is really a sticky point. I really want to ackn=
owledge your PoV on this, but at the same time I found this to be one of th=
e biggest sources of issues in the use of JWT for access tokens hence I fee=
l we really need to give solid guidance
 here. Let me expand further on the reasoning behind it, and perhaps we can=
 get to language that satisfies both PoVs.


To me the key point is that clients should not write=
 code that inspects access tokens. Taking a dependency on the abilit=
y to do so is ignoring fundamental information about the architecture and r=
elationships between OAuth roles,
 and suggests an ability of the client to understand the semantic of the co=
ntent that cannot be assumed in the general case. I expanded on the details=
 in my former reply to you on this topic, I would recommend referring to it=
. Clients violating this simple
 principle has been one of the most common sources of production issues I h=
ad to deal with in the past few years, and one of the hardest to remediate =
given that clients are hard to update and sometimes the things they relied =
on were irremediably lost. This
 is why I am inclined to put in here strong language.


That said: I have nothing against client developers =
examining a network trace and drawing conclusions based on the content of w=
hat they see. That doesn=92t create any hard dependencies and has no implic=
ations in respect to changes in the
 solution behavior. However I am not sure how to phrase that in the specifi=
cation, given that referring to the client inevitably refers to its code. I=
 am open to suggestions.


 


>  3)=85


I have a pretty hard time following the chain of rea=
soning in this section. Let me attempt to tackle it to the best of my under=
standing.


I think the key might be   


> a client should be able to choose whether it=
 wishes the sub claim to contain [..]


I don=92t think that should be a choice left to the =
client. In business systems, my experience is that the type of identifiers =
to be used (when the IdP gives any choice at all)  is established at r=
esource provisioning time. I am not aware
 of mechanisms thru which a client signals the nature of the identifier to =
be used, nor that would be fully feasible (the resource knows what it needs=
 to perform its function).


Furthermore:


> which has nothing to do with uniqueness sinc=
e the value changes for every generated token.


Again, this is something that was touched on in my f=
ormer reply to your message. As long as an identifier identifies one resour=
ce only, it satisfies uniqueness. It doesn=92t have to be a singleton.



Finally, the scope is optional (for good reasons: 1<=
sup>st party and non delegation scenarios don=92t require it) hence i=
t cannot be relied upon for properties that should hold in every scenario.<=
o:p>


In summary: per the preceding thread on this topic, =
the consensus was that varying the sub content was a satisfactory way of pr=
otecting against correlation. I don=92t a gree that clients should have a m=
echanism to request different sub flavors,
 as that decision should be done out of band by the AS and RS; and the scop=
e isn=92t always available anyway.




> targeting of access tokens

Let me think about that a bit longer. 

I acknowledge that the decision of including an audi=
ence has the effect of letting the AS track when the client accesses a part=
icular resource, but at the same time that=92s completely mainstream and ve=
ry much by design in a very large number
 of cases. As such, I find the language you are suggesting to be potentiall=
y confusing, as it positions this as an exception vs a privacy protecting m=
ainstream that is in fact not common, and ascribes to the client more latit=
ude than I believe is legitimate
 to expect or grant.


I=92ll try to come up with concise language that cla=
rifies to the reader that the current mechanism does allow AS tracking. &nb=
sp; 


 




From=
: OAuth <oauth-b=
ounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>

Date: Wednesday, April 29, 2020 at 09:12

To: "oauth@ietf.org" <oauth@ietf.org>

Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Pr=
ofile for OAuth 2.0 Access Tokens"






 






You will find four comments numbered 1) to 4). =







1)
The title of this spec. is:



JSON Web Token (JWT) P=
rofile for OAuth
2.0 Access Tokens



So, this spec. is supposed to be targeted to OAuth 2.0.  Howeve=
r, the header at the top of the page omits to mention it.




Currently, it is : 


Internet-Draft       OAuth Access To=
ken JWT Profile          =
 April 2020


It should rather be:


Internet-Draft       OAuth
2.0 Access Token JWT Profile      &nbs=
p;    April 2020



2) The following text is within section 6.



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.

Nonetheless, authorization servers should

not assume that clients will comply with the above.


It is of a primary importance that clients MAY be able to inspect =
tokens before transmitting them.

The "MUST NOT" is not acceptable. 


The above text should be replaced with:



Reading the access token content may be useful for the user to verify that =


the access token content matches with its expectations.  However, 

the authorization server and the resource server might decide to change the=
 

token format at any time.  Thus, the client should not expect to alway=
s be 

in a position to read the access token content.



The remaining of the text about this topic is fine.





3) The next topic is about the sub claim.



The text states:



Although the ability t=
o correlate requests might be required by

design in many scenarios, there are scenarios where the authorization

server might want to prevent correlation to preserve the desired

level of privacy. Authorization servers should choose how to assign

sub values according to the level of privacy required by each

situation.



I have a set of questions: 


    

  1. 
How can authorization servers choose how to assign sub values according to =
the level of privacy required "by each situation" ?
  2. 
How can authorization servers know the level of privacy required "by e=
ach situation" ?

  3. 
How can the users be informed of the level of privacy required "by eac=
h situation" ?
  4. 
How can the users consent with the level of privacy required "b=
y each situation" ?


Currently, the request MUST include either a resource parameter or=
 an aud claim parameter, while it MAY include a scope parameter.=



The syntax of the scope parameter is a list of space-delimited, ca=
se-sensitive strings (RFC 6749). It is thus subject to private agreements


between clients and Authorization Servers. Since the scope is being returne=
d, it is a primary importance that the returned scope matches


with its expectations before transmitting the token to a Resource Server.


In theory, a client should be able to choose whether it wishes the sub clai=
m to contain :


    

  • 
a global unique identifier for all ASs ("globally unique"),<=
/o:p>
  • 
a unique identifier for each AS ("locally unique in the context of the=
 issuer"),
  • 
a different pseudonym for each RS, or 
  • 
a different pseudonym for each authorization token request.
    • =



The only variable parameter that it can use for this purpose in th=
e token request is the scope parameter.



RFC 7519 states is section 4.1.2:



The subject value MUST =
either be scoped to be locally unique in the context of the issuer


or be globally unique.



It is quite hard to recognize that the sub claim is able to carry a differe=
nt pseudonym for each RS, i.e. for case (c), or


a different pseudonym for each authorization token request, i.e. for case (=
d), which has nothing to do with uniqueness


since the value changes for every generated token.



This has implications about the following text:



For instance: if a sol=
ution requires preventing 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.



Since it addresses case (c).



and also about the following text:



4.b) Similarly: if a s=
olution requires preventing a resource server from


correlating the principal=92s activity within the resource itself, the 

authorization server should assign different sub values for every JWT 

access token issued.



Since it addresses case (d).



This means that the current text placed in the privacy considerations secti=
on was a good attempt to address the case,


but that the text needs to be revised.



Proposed text replacement for all the previously quoted sentences:



According to RFC 7519 (4.1.2): The subject value MUST either be scoped to b=
e locally unique in the context of the issuer or be globally unique.



When the sub claim contains a globally unique identifier, this allows to co=
rrelate principal activities across multiple resource servers, while in add=
ition,


this globally unique identifier may also allow to correlate the principal a=
ctivities on servers where no access has been performed by the principals


to these servers but where the same globally unique identifiers are being u=
sed by these servers.




When the sub claim contains a locally unique identifier in the context of t=
he issuer, this also allows the tracking of principal activities across mul=
tiple resource servers.



The scope request parameter is the only way to influence on the content of =
the sub claim parameter. Its meaning is subject to a private agreement


between the client and the AS, which means that the use of the scope parame=
ter is the only way to choose between a locally unique identifier


in the context of the issuer or a globally unique identifier.



Since the scope parameter is being returned, it is a primary importance tha=
t the returned scope matches with the expectations of the client before tra=
nsmitting


the token to a Resource Server.



However, there are other cases where the client would like to be able to ch=
oose whether it wishes the sub claim to contain :


    - a different pseudonym for each RS so that different re=
source servers will be unable to correlate its activities, or

    - a different pseudonym for each authorization token req=
uest, so that the same resource server cannot correlate its activities perf=
ormed at different instant of time.




Considering the semantics of the sub claim, these two cases cannot be curre=
ntly supported.





4) The next topic is about the targeting of access tokens=



Text had been proposed before the last conference call. Then, the =
topic has been presented at the very end of the last conference call, but n=
o text has been included


in the next draft. 


Here is a revised text be included in the privacy considerations s=
ection:


For security reasons, some clients may be willing to target their =
access tokens but, for privacy reasons, may be unwilling to disclose to Aut=
horization Servers


an identification of the Resource Servers they are going to access, so that=
 Authorization Servers will be unable to know which resources servers are b=
eing accessed.


The disclosure of the Resource Servers names allows the Authorization Serve=
rs to list all the Resource Servers being access by all its users and in ad=
dition to list pairs


of (Principal, Resource Servers) which allow to trace all the users accesse=
s to Resource Servers performed through a given Authorization Server. When =
a token is targeted,


this profile does not contain provisions to address these two threats.



Denis








Hi all,


 


This is a second working =
group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access=
 Tokens".


 


Here is the document:


https://tools.ietf.org/=
html/draft-ietf-oauth-access-token-jwt-06


 


Please send your comments=
 to the OAuth mailing list by April 29, 2020.


 


Regards,


 Rifaat & Hannes=



 











_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 






--_000_MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0MWHPR19MB1501namp_--


From nobody Thu Apr 30 02:50:19 2020
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 CE0473A0407 for ; Thu, 30 Apr 2020 02:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.405
X-Spam-Level: 
X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, LONGWORDS=2.035, RCVD_IN_MSPIKE_H2=-0.82, 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 Lk-JCDL_GPgd for ; Thu, 30 Apr 2020 02:50:09 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7103A0400 for ; Thu, 30 Apr 2020 02:50:08 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d71 with ME id Yxq52200M4FMSmm03xq58j; Thu, 30 Apr 2020 11:50:06 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 30 Apr 2020 11:50:06 +0200
X-ME-IP: 86.238.65.197
To: Vittorio Bertocci , "oauth@ietf.org" 
References:  <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> 
From: Denis 
Message-ID: <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr>
Date: Thu, 30 Apr 2020 11:50:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------75092AAADD3F5E7886AED52C"
Content-Language: en-GB
Archived-At: 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 30 Apr 2020 09:50:16 -0000

This is a multi-part message in MIME format.
--------------75092AAADD3F5E7886AED52C
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hello Vittorio,

Your reply was amazingly fast. Responses are between the lines.

> Thanks Denis for the thorough commentary.
>
> /> The title of this spec./
>
> Fixed, thanks!
>

> /> The client MUST NOT inspect the content of the access token/
>
>
> This is really a sticky point. I really want to acknowledge your PoV 
> on this, but at the same time I found this to be one of the biggest 
> sources of issues
> in the use of JWT for access tokens hence I feel we really need to 
> give solid guidance here. Let me expand further on the reasoning 
> behind it,
> and perhaps we can get to language that satisfies both PoVs.
>
>
> To me the key point is that clients should not write /code/ that 
> inspects access tokens. Taking a dependency on the ability to do so is 
> ignoring fundamental information
> about the architecture and relationships between OAuth roles, and 
> suggests an ability of the client to understand the semantic of the 
> content that cannot be assumed
> in the general case. I expanded on the details in my former reply to 
> you on this topic, I would recommend referring to it.
>
> Clients violating this simple principle has been one of the most 
> common sources of production issues I had to deal with in the past few 
> years, and one of the hardest
> to remediate given that clients are hard to update and sometimes the 
> things they relied on were irremediably lost. This is why I am 
> inclined to put in here strong language.
>
> That said: I have nothing against client developers examining a 
> network trace and drawing conclusions based on the content of what 
> they see. That doesnt create any hard
> dependencies and has no implications in respect to changes in the 
> solution behavior. However I am not sure how to phrase that in the 
> specification, given that referring
> to the client inevitably refers to its code. I am open to suggestions.
>
First of all, a "*MUST NOT* "should not be placed in a privacy 
considerations section, but in the main body of the document.
The goal of a privacy considerations section is to provide explanations, 
but not to introduce additional requirements.

Then after, since this section is about privacy considerations, it is 
important to refer to an ISO standard that has been published 9 years ago.

It is ISO 29100 (Information technology  Security techniques  Privacy 
framework). Most of the ISO standards need to be bought.
However, there are a few exceptions and this standard can be freely 
downloaded from the ISO web site, if you accept some conditions,
using this URL:

    https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ISO 29100, even if it is outdated on some aspects (it only deals with 
two entities), identifies ten principles (See Table 3).

    1. Consent and choice

    2. Purpose legitimacy and specification

    3. Collection limitation

    4. Data minimization

    5. Use, retention and disclosure limitation

    6. Accuracy and quality

    7. Openness, transparency and notice

    8. Individual participation and access

    9. Accountability

    10. Information security

    11. Privacy compliance

If the client is unable to inspect the token, then openness and 
transparency do not exist any more.

Since there is no formal protocol in OAuth 2.0 for "consent and 
choice", the only way for a client for denying its consent is to inspect 
the token
and to stop its transmission if the content of the token is not 
considered to be adequate for it.

Since you are open to suggestions, would you please reconsider the text 
I proposed: it simply states that if the client wants to inspect the token,
it will not necessarily be in a position to do it. It is simply a 
warning, but this warning does not prevent the client to attempt to 
inspect the token .

I will go one step further: if the client wants to inspect the token and 
if the format of the token is unknown to the client, then the client 
will simply
stop its further transmission. For some clients, preserving their 
privacy may be more important than performing an access to a RS.

> > 3)
>
> I have a pretty hard time following the chain of reasoning in this 
> section. Let me attempt to tackle it to the best of my understanding.
>
> I think the key might be
>
> /> a client should be able to choose whether it wishes the sub claim 
> to contain [..]
>
> /
>
> I dont think that should be a choice left to the client. In business 
> systems, my experience is that the type of identifiers to be used 
> (when the IdP gives any choice at all)
> is established at resource provisioning time. I am not aware of 
> mechanisms thru which a client signals the nature of the identifier to 
> be used, nor that would be fully
> feasible (the resource knows what it needs to perform its function).
>
Consent and choice is the first of the ten privacy principles. Since 
OAuth has not been constructed taking into considerations this privacy 
principle,
it is quite "normal" that you don't observe protocols able to do it at 
the present time.

> Furthermore:
>
> /> which has nothing to do with uniqueness since the value changes for 
> every generated token.
>
> /
>
> Again, this is something that was touched on in my former reply to 
> your message. As long as an identifier identifies one resource only, 
> it satisfies uniqueness. It doesnt have to be a singleton.
>
It is a matter of interpretation. I stick to the definition given in RFC 
7519 (section 4.1.2):

*T**he subject value MUST either be scoped to be locally unique in the 
context of the issuer or be globally unique.*

However, the "context of the issuer" is left undefined.

> Finally, the scope is optional (for good reasons: 1^st party and non 
> delegation scenarios dont require it) hence it cannot be relied upon 
> for properties that should hold in every scenario.
>
I would not say that the scope request parameter is a nice way to choose 
which attributes should be placed in a JWT. However, considering the 
limitations placed
in this document, it is the ONLY way to do. In my email sent before the 
virtual meeting, I wrote: "Allowing a client to only specify a scope and 
a resource is very restrictive".

Clause 2.2.2 (second paragraph) states:

***This profile does not introduce any mechanism for a client to**
******directly request the presence of specific claims in JWT access**
******tokens*, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Currently, the client has no control of the claims that will be placed 
in a JWT and further more the current wording of privacy consideration 
section
prevents the client to have any inspection of the attributes that have 
been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
fulfilled.

There are more implications. If, in the future, a mechanism is defined 
to allow the client to choose the type of the attributes that should be 
placed in a JWT,
then the "sub" claim is insufficient. Taking into consideration my 
previous email, four types of attributes types would need to be specified:

The client should be able to choose whether it wishes a claim that contains:

  *   a global unique identifier for all ASs ("globally unique"),
  *   a unique identifier for each AS ("locally unique in the context
    of the issuer"),
  *   a different pseudonym for each RS, or
  *   a different pseudonym for each authorization token request.

Clause 2.2.2 states:

* the authorization server can determine what additional**
******claims are required by a particular resource server* by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

I don't believe this is true in general. Considering its privacy 
preferences, only the client may know what is appropriate: not the AS, 
neither the RS.

> In summary: per the preceding thread on this topic, the consensus was 
> that varying the sub content was a satisfactory way of protecting 
> against correlation.
>
"/if all you have is a hammer, everything looks like a nail/".

When the only parameter that can be used is the "sub" claim, then the 
only solution is to place everything into it.

> I dont a gree that clients should have a mechanism to request 
> different sub flavors, as that decision should be done out of band by 
> the AS and RS; and the scope isnt always available anyway.
>
While it would be nice to have such a mechanism, we are not going to 
define such a mechanism during a second WGLC.

The privacy considerations section should only inform the readers about 
the limitations of the protocol in terms of privacy.
I have proposed text to address the point. If you would prefer a 
different wording to address this point, please make another proposal.

> /> targeting of access tokens/
>
> Let me think about that a bit longer.
>
> I acknowledge that the decision of including an audience has the 
> effect of letting the AS track when the client accesses a particular 
> resource,
> but at the same time thats completely mainstream and very much by 
> design in a very large number of cases. As such, I find the language
> you are suggesting to be potentially confusing, as it positions this 
> as an exception vs a privacy protecting mainstream that is in fact not 
> common,
> and ascribes to the client more latitude than I believe is legitimate 
> to expect or grant.
>
> Ill try to come up with concise language that clarifies to the reader 
> that the current mechanism does allow AS tracking.
>
Please do so.

Denis

> *From: *OAuth  on behalf of Denis 
> 
> *Date: *Wednesday, April 29, 2020 at 09:12
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> for OAuth 2.0 Access Tokens"
>
> You will find four comments numbered 1) to 4).
>
> *1) *The title of this spec. is:
>
> JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>
> So, this spec. is supposed to be targeted to OAuth *2.0. *However, 
> the header at the top of the page omits to mention it.
>
> Currently, it is :
>
> Internet-Draft OAuth Access Token JWT Profile April 2020
>
> It should rather be:
>
> Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020
>
> *2)* The following text is within section 6.
>
> 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.
> Nonetheless, authorization servers should
> not assume that clients will comply with the above.
>
> It is of a primary importance that clients MAY be able to inspect 
> tokens before transmitting them.
> The "MUST NOT" is not acceptable.
>
> The above text should be replaced with:
>
> Reading the access token content may be useful for the user to verify 
> that
> the access token content matches with its expectations. However,
> the authorization server and the resource server might decide to 
> change the
> token format at any time. Thus, the client should not expect to 
> always be
> in a position to read the access token content.
>
> The remaining of the text about this topic is fine.
>
>
> *3) *The next topic is about the sub claim.
>
> The text states:
>
> Although the ability to correlate requests might be required by
> design in many scenarios, there are scenarios where the authorization
> server might want to prevent correlation to preserve the desired
> level of privacy. Authorization servers should choose how to assign
> sub values according to the level of privacy required by each
> situation.
>
> I have a set of questions:
>
>  1. How can authorization servers choose how to assign sub values
>     according to the level of privacy required "by each situation" ?
>  2. How can authorization servers know the level of privacy required
>     "by each situation" ?
>  3. How can the users be informed of the level of privacy required "by
>     each situation" ?
>  4. How can the users *consent* with the level of privacy required "by
>     each situation" ?
>
> Currently, the request MUST include either a resource parameter or an 
> aud claim parameter, while it MAY include a scope parameter.
>
> The syntax of the scope parameter is a list of space-delimited, 
> case-sensitive strings (RFC 6749). It is thus subject to private 
> agreements
> between clients and Authorization Servers. Since the scope is being 
> returned, it is a primary importance that the returned scope matches
> with its expectations before transmitting the token to a Resource Server.
>
> In theory, a client should be able to choose whether it wishes the sub 
> claim to contain :
>
>   * a global unique identifier for all ASs ("globally unique"),
>   * a unique identifier for each AS ("locally unique in the context of
>     the issuer"),
>   * a different pseudonym for each RS, or
>   * a different pseudonym for each authorization token request.
>
> The only variable parameter that it can use for this purpose in the 
> token request is the scope parameter.
>
> RFC 7519 states is section 4.1.2:
>
> The subject value MUST either be scoped to be locally unique in the 
> context of the issuer
> or be globally unique.
>
> It is quite hard to recognize that the sub claim is able to carry a 
> different pseudonym for each RS, i.e. for case (c), or
> a different pseudonym for each authorization token request, i.e. for 
> case (d), which has nothing to do with uniqueness
> since the value changes for every generated token.
>
> This has implications about the following text:
>
> For instance: if a solution requires preventing 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.
>
> Since it addresses case (c).
>
> and also about the following text:
>
> 4.b) Similarly: if a solution requires preventing a resource server from
> correlating the principals activity within the resource itself, the
> authorization server should assign different sub values for every JWT
> access token issued.
>
> Since it addresses case (d).
>
> This means that the current text placed in the privacy considerations 
> section was a good attempt to address the case,
> but that the text needs to be revised.
>
> Proposed text replacement for all the previously quoted sentences:
>
> According to RFC 7519 (4.1.2): The subject value MUST either be scoped 
> to be locally unique in the context of the issuer or be globally unique.
>
> When the sub claim contains a globally unique identifier, this allows 
> to correlate principal activities across multiple resource servers, 
> while in addition,
> this globally unique identifier may also allow to correlate the 
> principal activities on servers where no access has been performed by 
> the principals
> to these servers but where the same globally unique identifiers are 
> being used by these servers.
>
> When the sub claim contains a locally unique identifier in the context 
> of the issuer, this also allows the tracking of principal activities 
> across multiple resource servers.
>
> The scope request parameter is the only way to influence on the 
> content of the sub claim parameter. Its meaning is subject to a 
> private agreement
> between the client and the AS, which means that the use of the scope 
> parameter is the only way to choose between a locally unique identifier
> in the context of the issuer or a globally unique identifier.
>
> Since the scope parameter is being returned, it is a primary 
> importance that the returned scope matches with the expectations of 
> the client before transmitting
> the token to a Resource Server.
>
> However, there are other cases where the client would like to be able 
> to choose whether it wishes the sub claim to contain :
>  - a different pseudonym for each RS so that different resource 
> servers will be unable to correlate its activities, or
>  - a different pseudonym for each authorization token request, so 
> that the same resource server cannot correlate its activities 
> performed at different instant of time.
>
> Considering the semantics of the sub claim, these two cases cannot be 
> currently supported.
>
>
> *4) *The next topic is about the targeting of access tokens
>
> Text had been proposed before the last conference call. Then, the 
> topic has been presented at the very end of the last conference call, 
> but no text has been included
> in the next draft.
>
> Here is a revised text be included in the privacy considerations section:
>
> For security reasons, some clients may be willing to target their 
> access tokens but, for privacy reasons, may be unwilling to disclose 
> to Authorization Servers
> an identification of the Resource Servers they are going to access, so 
> that Authorization Servers will be unable to know which resources 
> servers are being accessed.
> The disclosure of the Resource Servers names allows the Authorization 
> Servers to list all the Resource Servers being access by all its users 
> and in addition to list pairs
> of (Principal, Resource Servers) which allow to trace all the users 
> accesses to Resource Servers performed through a given Authorization 
> Server. When a token is targeted,
> this profile does not contain provisions to address these two threats.
>
> Denis
>
>     Hi all,
>
>     This is a second working group last call for "JSON Web Token (JWT)
>     Profile for OAuth 2.0 Access Tokens".
>
>     Here is the document:
>
>     https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>     Please send your comments to the OAuth mailing list by April 29, 2020.
>
>     Regards,
>
>     Rifaat & Hannes
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/oauth
>


--------------75092AAADD3F5E7886AED52C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Vittorio,

    


    

    
Your reply was amazingly fast.
      Responses are between the lines.

      

    

    

      
      
      
      

        
Thanks Denis for the thorough commentary.

        

        
> The title of this spec.

        
Fixed, thanks! 

          

      

    

    

    

      

        
> The client MUST NOT inspect the
            content of the access token

        


          This is really a sticky point. I really want to acknowledge
          your PoV on this, but at the same time I found this to be one
          of the biggest sources of issues 

          in the use of JWT for access tokens hence I feel we really
          need to give solid guidance here. Let me expand further on the
          reasoning behind it, 

          and perhaps we can get to language that satisfies both PoVs.

        


          To me the key point is that clients should not write code
          that inspects access tokens. Taking a dependency on the
          ability to do so is ignoring fundamental information 

          about the architecture and relationships between OAuth roles,
          and suggests an ability of the client to understand the
          semantic of the content that cannot be assumed 

          in the general case. I expanded on the details in my former
          reply to you on this topic, I would recommend referring to it.
          

          

          Clients violating this simple principle has been one of the
          most common sources of production issues I had to deal with in
          the past few years, and one of the hardest 

          to remediate given that clients are hard to update and
          sometimes the things they relied on were irremediably lost.
          This is why I am inclined to put in here strong language.

          

          

        
That said: I have nothing against client
          developers examining a network trace and drawing conclusions
          based on the content of what they see. That doesnt create any
          hard 

          dependencies and has no implications in respect to changes in
          the solution behavior. However I am not sure how to phrase
          that in the specification, given that referring 

          to the client inevitably refers to its code. I am open to
          suggestions.

      

    

    
First of all, a "MUST NOT "should not be placed in a
      privacy considerations section, but in the main body of the
      document.

      The goal of a privacy considerations section is to provide
      explanations, but not to introduce additional requirements.

    
Then after, since this section is about privacy considerations,
      it is important to refer to an ISO standard that has been
      published 9 years ago.

    
It is ISO 29100 (Information technology  Security techniques 
      Privacy framework). Most of the ISO standards need to be bought.

      However, there are a few exceptions and this standard can be
      freely downloaded from the ISO web site, if you accept some
      conditions, 

      using this URL:

    

    

      
https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

      

    

    
ISO 29100, even if it is outdated on some aspects (it only deals
      with two entities), identifies ten principles (See Table 3).

    

    

    

      
1. Consent
            and choice 

      
2. Purpose legitimacy and
          specification 

      
3. Collection
            limitation 

      
4. Data
            minimization 

      
5. Use, retention and
          disclosure limitation 

      
6. Accuracy and quality 

      
7. Openness,
            transparency and notice 

      
8. Individual participation
          and access 

      
9. Accountability 

      
10. Information security 

      
11. Privacy compliance

    

    

    
If the client is unable to inspect the token, then openness and
      transparency do not exist any more.

    
Since there is no formal protocol in OAuth 2.0 for "consent and
      choice", the only way for a client for denying its consent is to
      inspect the token 

      and to stop its transmission if the content of the token is not
      considered to be adequate for it.

    
 Since you are open to suggestions, would you please reconsider
      the text I proposed: it simply states that if the client wants to
      inspect the token, 

      it will not necessarily be in a position to do it. It is simply a
      warning, but this warning does not prevent the client to attempt
      to inspect the token .

    
I will go one step further: if the client wants to inspect the
      token and if the format of the token is unknown to the client,
      then the client will simply 

      stop its further transmission. For some clients, preserving their
      privacy may be more important than performing an access to a RS.

    

    

      

        
> 3)

        
I have a pretty hard time following the
          chain of reasoning in this section. Let me attempt to tackle
          it to the best of my understanding.

        
I think the key might be 

        
> a client should be able to choose
            whether it wishes the sub claim to contain [..]

            

            

        
I dont think that should be a choice left
          to the client. In business systems, my experience is that the
          type of identifiers to be used (when the IdP gives any choice
          at all) 

          is established at resource provisioning time. I am not aware
          of mechanisms thru which a client signals the nature of the
          identifier to be used, nor that would be fully 

          feasible (the resource knows what it needs to perform its
          function).

      

    

    
Consent
        and choice is the first of the ten privacy principles.
      Since OAuth has not been constructed taking into considerations
      this privacy principle, 

      it is quite "normal" that you don't observe protocols able to do
      it at the present time.

    

      

        
Furthermore:

        
> which has nothing to do with
            uniqueness since the value changes for every generated
            token.

            

            

        
Again, this is something that was touched
          on in my former reply to your message. As long as an
          identifier identifies one resource only, it satisfies
          uniqueness. It doesnt have to be a singleton.
          

        

      

    

    
It is a matter of interpretation. I stick to the definition given
      in RFC 7519 (section 4.1.2):

      

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

    
However, the "context of the issuer" is left undefined.

    

      

        
Finally, the scope is optional (for good
          reasons: 1st party and non delegation scenarios
          dont require it) hence it cannot be relied upon for
          properties that should hold in every scenario.

        

      

    

    
I would not say that the scope request parameter is a nice way to
      choose which attributes should be placed in a JWT. However,
      considering the limitations placed 

      in this document, it is the ONLY way to do. In my email sent
      before the virtual meeting, I wrote: "Allowing
        a client to only specify a scope and a resource is very
        restrictive".

    
Clause 2.2.2 (second paragraph) states:

        

         This
          profile does not introduce any mechanism for a client to

          directly
          request the presence of specific claims in JWT access

          tokens,
        as the authorization server can determine what additional

         claims are required
        by a particular resource server by taking in

         consideration the
        client_id of the client, the scope and the resource

         parameters included
        in the request.

    
Currently, the client has no control of the claims that will be
      placed in a JWT and further more the current wording of privacy
      consideration section 

      prevents the client to have any inspection of the attributes that
      have been placed in a JWT. Privacy principles 1 and 7 from ISO
      29100 are not fulfilled. 

    

    
 There are more implications. If, in the future, a mechanism is
      defined to allow the client to choose the type of the attributes
      that should be placed in a JWT, 

      then the "sub" claim is insufficient. Taking into consideration my
      previous email, four types of attributes types would need to be
      specified:

    
 The client should be able to choose whether it wishes a claim
      that contains:

    
    
      
  •  a global unique identifier for all ASs ("globally
        unique"),
    • 
      
  •  a unique identifier for each AS ("locally unique in the
        context of the issuer"),
    • 
      
  •  a different pseudonym for each RS, or
    • 
      
  •  a different pseudonym for each authorization token
        request.
    • 
    

    
Clause 2.2.2 states:

    
 the authorization server can determine what
          additional

          claims
          are required by a particular resource server by taking in

         consideration the
        client_id of the client, the scope and the resource

         parameters included
        in the request.

    
I don't believe this is true in general. Considering its privacy
      preferences, only the client may know what is appropriate: not the
      AS, neither the RS.

    

    

      

        
In summary: per the preceding thread on
          this topic, the consensus was that varying the sub content was
          a satisfactory way of protecting against correlation. 

      

    

    
"if all you have is a hammer, everything looks like a nail".

    

    
When the only parameter that can be used is the "sub" claim, then
      the only solution is to place everything into it.

    

      

        
I dont a gree that clients should have a
          mechanism to request different sub flavors, as that decision
          should be done out of band by the AS and RS; and the scope
          isnt always available anyway.

      

    

    
While it would be nice to have such a mechanism, we are not going
      to define such a mechanism during a second WGLC.

    
The privacy considerations section should only inform the readers
      about the limitations of the protocol in terms of privacy.

      I have proposed text to address the point. If you would prefer a
      different wording to address this point, please make another
      proposal.

    

      

        

        

        
> targeting of access tokens

        
Let me think about that a bit longer. 

          

          

        
I acknowledge that the decision of
          including an audience has the effect of letting the AS track
          when the client accesses a particular resource, 

          but at the same time thats completely mainstream and very
          much by design in a very large number of cases. As such, I
          find the language

          you are suggesting to be potentially confusing, as it
          positions this as an exception vs a privacy protecting
          mainstream that is in fact not common, 

          and ascribes to the client more latitude than I believe is
          legitimate to expect or grant.

        
Ill try to come up with concise language
          that clarifies to the reader that the current mechanism does
          allow AS tracking.  

        

      

    

    
Please do so.

    
Denis

    

      

        

        

        

          
From: OAuth
              <oauth-bounces@ietf.org> on behalf of Denis
              <denis.ietf@free.fr>

              Date: Wednesday, April 29, 2020 at 09:12

              To: "oauth@ietf.org" <oauth@ietf.org>

              Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web
              Token (JWT) Profile for OAuth 2.0 Access Tokens"

        

        

          

        

        

          
You will find four comments numbered 1)
            to 4). 

        

        

          
1)
            The title of this spec. is:

            

            JSON Web
              Token (JWT) Profile for OAuth
              2.0 Access Tokens

            

            So, this spec. is supposed to be targeted to OAuth 2.0.
            However, the header at the top of the page omits to
            mention it.
            

            

            Currently, it is :

          
Internet-Draft
            OAuth Access Token JWT Profile April 2020

          
It
            should rather be:

          
Internet-Draft
            OAuth
            2.0 Access Token JWT Profile April 2020

            

            2) The following text is within section 6.

            

            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.

            Nonetheless, authorization servers should

            not assume that clients will comply with the above.

          
It
            is of a primary importance that clients MAY be able to
            inspect tokens before transmitting them.

            The "MUST NOT" is not acceptable. 

          
The
            above text should be replaced with:

            

            Reading the access token content may be useful for the user
            to verify that 

            the access token content matches with its expectations.
            However, 

            the authorization server and the resource server might
            decide to change the 

            token format at any time. Thus, the client should not
            expect to always be 

            in a position to read the access token content.

            

            The remaining of the text about this topic is fine.

            

            

            3) The next topic is about the sub claim.

            

            The text states:

            

            Although
              the ability to correlate requests might be required by

              design in many scenarios, there are scenarios where the
              authorization

              server might want to prevent correlation to preserve the
              desired

              level of privacy. Authorization servers should choose how
              to assign

              sub values according to the level of privacy required by
              each

              situation.

            

            I have a set of questions: 

          
    
            
  1. 
              How can authorization servers choose how to assign sub
              values according to the level of privacy required "by each
              situation" ?
    2. 
            
  2. 
              How can authorization servers know the level of privacy
              required "by each situation" ?
              
    3. 
            
  3. 
              How can the users be informed of the level of privacy
              required "by each situation" ?
    4. 
            
  4. 
              How can the users consent with the level of
              privacy required "by each situation" ?
    5. 
          

          
Currently,
            the request MUST include either a resource parameter or an
            aud claim parameter, while it MAY include a scope parameter.

          
The
            syntax of the scope parameter is a list of space-delimited,
            case-sensitive strings (RFC 6749). It is thus subject to
            private agreements
            

            between clients and Authorization Servers. Since the scope
            is being returned, it is a primary importance that the
            returned scope matches
            

            with its expectations before transmitting the token to a
            Resource Server.

            

            In theory, a client should be able to choose whether it
            wishes the sub claim to contain :

          
    
            
  • 
              a global unique identifier for all ASs ("globally
              unique"),
    • 
            
  • 
              a unique identifier for each AS ("locally unique in the
              context of the issuer"),
    • 
            
  • 
              a different pseudonym for each RS, or 
    • 
            
  • 
              a different pseudonym for each authorization token
              request.
    • 
          

          
The
            only variable parameter that it can use for this purpose in
            the token request is the scope parameter.

            

            RFC 7519 states is section 4.1.2:

            

            The
              subject value MUST either be scoped to be locally unique
              in the context of the issuer
              

              or be globally unique.

            

            It is quite hard to recognize that the sub claim is able to
            carry a different pseudonym for each RS, i.e. for case (c),
            or
            

            a different pseudonym for each authorization token request,
            i.e. for case (d), which has nothing to do with uniqueness
            

            since the value changes for every generated token.

            

            This has implications about the following text:

            

            For
              instance: if a solution requires preventing 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.

              

            Since it addresses case (c).

            

            and also about the following text:

            

            4.b)
              Similarly: if a solution requires preventing a resource
              server from
              

              correlating the principals activity within the resource
              itself, the 

              authorization server should assign different sub values
              for every JWT 

              access token issued.

            

            Since it addresses case (d).

            

            This means that the current text placed in the privacy
            considerations section was a good attempt to address the
            case,
            

            but that the text needs to be revised.

            

            Proposed text replacement for all the previously quoted
            sentences:

            

            According to RFC 7519 (4.1.2): The subject value MUST either
            be scoped to be locally unique in the context of the issuer
            or be globally unique.

            

            When the sub claim contains a globally unique identifier,
            this allows to correlate principal activities across
            multiple resource servers, while in addition,
            

            this globally unique identifier may also allow to correlate
            the principal activities on servers where no access has been
            performed by the principals
            

            to these servers but where the same globally unique
            identifiers are being used by these servers.
            

            

            When the sub claim contains a locally unique identifier in
            the context of the issuer, this also allows the tracking of
            principal activities across multiple resource servers.

            

            The scope request parameter is the only way to influence on
            the content of the sub claim parameter. Its meaning is
            subject to a private agreement
            

            between the client and the AS, which means that the use of
            the scope parameter is the only way to choose between a
            locally unique identifier
            

            in the context of the issuer or a globally unique
            identifier.

            

            Since the scope parameter is being returned, it is a primary
            importance that the returned scope matches with the
            expectations of the client before transmitting
            

            the token to a Resource Server.

            

            However, there are other cases where the client would like
            to be able to choose whether it wishes the sub claim to
            contain :
            

             - a different pseudonym for each RS so that different
            resource servers will be unable to correlate its activities,
            or

             - a different pseudonym for each authorization token
            request, so that the same resource server cannot correlate
            its activities performed at different instant of time.
            

            

            Considering the semantics of the sub claim, these two cases
            cannot be currently supported.

            

            

            4) The next topic is about the targeting of access
            tokens

          
Text
            had been proposed before the last conference call. Then, the
            topic has been presented at the very end of the last
            conference call, but no text has been included
            

            in the next draft. 

          
Here
            is a revised text be included in the privacy considerations
            section:

          
For
            security reasons, some clients may be willing to target
            their access tokens but, for privacy reasons, may be
            unwilling to disclose to Authorization Servers
            

            an identification of the Resource Servers they are going to
            access, so that Authorization Servers will be unable to know
            which resources servers are being accessed.
            

            The disclosure of the Resource Servers names allows the
            Authorization Servers to list all the Resource Servers being
            access by all its users and in addition to list pairs
            

            of (Principal, Resource Servers) which allow to trace all
            the users accesses to Resource Servers performed through a
            given Authorization Server. When a token is targeted,
            

            this profile does not contain provisions to address these
            two threats.

            

            Denis

        

        

          

            
Hi all,

            

            
This is a
              second working group last call for "JSON Web Token (JWT)
              Profile for OAuth 2.0 Access Tokens".

            

            
Here is the
              document:

            
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

            

            
Please send
              your comments to the OAuth mailing list by April 29, 2020.

            

            
Regards,

            
Rifaat &
              Hannes

            

          

          


            

            

          
_______________________________________________

          
OAuth mailing list

          
OAuth@ietf.org

          
https://www.ietf.org/mailman/listinfo/oauth

        

        

      

    

    


    

  


--------------75092AAADD3F5E7886AED52C--


From nobody Thu Apr 30 09:40:24 2020
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 231663A0C08 for ; Thu, 30 Apr 2020 09:40:23 -0700 (PDT)
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 hA4hrxdkPrKs for ; Thu, 30 Apr 2020 09:40:21 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 A7FFA3A0C09 for ; Thu, 30 Apr 2020 09:40:20 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id s10so1949546iln.11 for ; Thu, 30 Apr 2020 09:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=WInGle156ltKcUbB2sxac1e9k1OXySCSYIWW8TsSIZ4=; b=end29eQBvpoKXl6qbhss2tbwnHHWuYwp4wJvwuoRbdLZhsWNPbrr+/caZ1tLF62Bx6 W5pdyrmdO9lXUxmRhZ1taZhOznJqoL46k0IeRG4BQelfX7O/GM3wvxBYB6GxUJTTQ3Uc 6kLWBoXd/KpnI6SnWCJFfi/ghypdBHqGOU5H8snfv3BXP+69J5OCA9AGVSx8esLIHCDL 5zz4C5uumWFPIhzsgnb4MOB9KGFc5FkMZtT8CDHdiLP/xXupcB+8gH5Nlgy5TqTlXpv4 JUiTF6iGOKCvzms2gvYpvCW55+iJwdXUaw67PldqysRxG/PvXgntVhh3OmEFQ/NMemRy LBpA==
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=WInGle156ltKcUbB2sxac1e9k1OXySCSYIWW8TsSIZ4=; b=iwbvxlBCPA8FbLt7vyfsPXDLApqDO+OBT5xeaKDTZK0C5y1uqcbNHSe5l4qvIXw9cC g6OQBeggudWxymxcM9mszTqLbm2mgOY8h7NprPIcBmNLT8sM0i+v1LzZ7dYdnVIC+T1C i0bzP4uX1KiGpsLPp3J/d+Sxk/gKB6z9FD2OqYRqWZVNGGU9P3xei5Dzef+VouLp9xZ+ +NfUCYXUAQyAlnPslIEBCRyom+Zg5afhxsEqD0oqw/iQBD5wHxM+QgA2W6GeHqNfbTAG pZbEOXq0xB2dUVcTuE+dNxMhLTXwAjsXYIeJT8bhlhvmVjy03H5Xrrw/6SKIKETrpSEt SozQ==
X-Gm-Message-State: AGi0PuZPxvPdLjVpzxhA06VCU0xUpE3ifs+KlMSYXoiEVdfHLDBBbMkN r01D6fTP6XxBXZfJ6amP1vCG/66rIVer6hnV+m8uAv7sw5Q=
X-Google-Smtp-Source: APiQypJEzScvVUDCwPV0aMrzHUY8kGFlNshAIrld2yP7xxjxn1PvZousBIHky9crNaAUulN4s0fnIi81MgJxoeHO1WY=
X-Received: by 2002:a92:91d7:: with SMTP id e84mr2994007ill.255.1588264819693;  Thu, 30 Apr 2020 09:40:19 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Thu, 30 Apr 2020 12:40:10 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000631c7f05a484b835"
Archived-At: 
Subject: Re: [OAUTH-WG] April 27th Interim Meeting Material
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, 30 Apr 2020 16:40:23 -0000

--000000000000631c7f05a484b835
Content-Type: text/plain; charset="UTF-8"

All,

You can find this meeting minutes at the following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-06/materials/minutes-interim-2020-oauth-06-202004271200

Thanks to *Jared Jennings *for taking these notes.

Regards,
 Rifaat & Hannes

On Sun, Apr 26, 2020 at 5:25 PM Rifaat Shekh-Yusef 
wrote:

> The following link has the meeting material for the April 27th interim
> meeting:
> https://datatracker.ietf.org/meeting/interim-2020-oauth-06/session/oauth
>
> Will upload the OAuth 2.1 slides when I get them.
>
> Regards,
>  Rifaat
>
>

--000000000000631c7f05a484b835
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

You can find this meeti=
ng minutes at the following link:
Thanks to=C2=A0Jared Jennings=C2=A0for taking these not=
es.

Regards,
=C2=A0Rifaat & Hannes

On Sun, Apr 26, 2020 at 5:25 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
The followin=
g=C2=A0link has the meeting=C2=A0material for the April 27th interim meetin=
g:

Will up=
load the OAuth 2.1 slides when I get them.

Regards=
,
=C2=A0Rifaat
=C2=A0




--000000000000631c7f05a484b835--


From nobody Thu Apr 30 17:26:53 2020
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 186113A170F for ; Thu, 30 Apr 2020 17:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.317
X-Spam-Level: 
X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, BODY_SINGLE_WORD=0.131, 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=no 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 lWdWBlq5d5pA for ; Thu, 30 Apr 2020 17:26:50 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 CF0343A170E for ; Thu, 30 Apr 2020 17:26:49 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id i10so9664412wrv.10 for ; Thu, 30 Apr 2020 17:26:49 -0700 (PDT)
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=GhtZbXKiBYNX0YZBGqkZIwnva2CG33YhHM0s7INtY8s=; b=F+GWdSozlbc+VR4QFIogwPHEzIdyyIL1XLGRP/aeajIVRcv/V8MDs8LJig/YouirDB 4Vlkwmi3HjGMLzfVSWfil9nDoKB/OLTmrijf8aFuBu83I7O0oUxSSmwqo8AAKdO4pFiT 9F32JTKWNRNX/CtDZpDMmSURTwKbKVDXQDFdy4colNnloqR/qjzNAn+2cwjqM+yrG7kF BT1eVaOQ9izcCsTUV500ZZ9IffLbklhYta5wRSvXquMFMkU1hj9j/LPqIMhm/K3cF6SC VAS6+Jh2i+8kS4qS1I4Hi4SS6xBgjBkQTVoEwLtstoxCJPdvX+PcysMg3blgshDqvHtf cwXg==
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=GhtZbXKiBYNX0YZBGqkZIwnva2CG33YhHM0s7INtY8s=; b=gukUmz8HpirHXlurA10dwAbYS2MQwW/9xJuPFKzAHeOu3YxuJC6AG2aGtgpVRg9nOl 7+zESxpDEXPuTIpNVmK/v6RbPOk5Zt/nNtCGtw4/XDGXtH+QGCKmscm2p8RmYiQDCQaP hleRA5X8MYv+KJfzxr97gLwdE3lNBm0TM2T40lK0+YTPXhFGQamtnLvBzCQy/CGKbzfM NVKAO8IEu9O3Be6oZ73RzDUDETPgySM4QJUjY2eO0THDQJzzXTrcNLT9ipSf63vxyf2n 46va7PqVs3RlkGL2AjqHYxSR0LXUs8AYo59ilEqyslNXgkB/H34k1SbZyZyrMga07xMV hnAg==
X-Gm-Message-State: AGi0PubL+17Ym96oya145TbDfdsQgxDGz8oegcIhH5cpoCFJNBrxWc+G UOiAA2Ia0zm1qlwjQBF63EYwG6I9ABNQduWLM19c6A==
X-Google-Smtp-Source: APiQypK9xNSqX9Sa2c7pKQViKTX+Hdh1e//MctwgBzKsUTacDfAxTMBs1oY0SBzYFNhMdsEZUBFim2u1nWBo1tBxgfI=
X-Received: by 2002:adf:9f11:: with SMTP id l17mr1237467wrf.202.1588292807893;  Thu, 30 Apr 2020 17:26:47 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?B?TcWMSMSATcSARCDEgEzEqkYgxKpNUsSATiBCxKpOIE3FqlNUxIBQSMSA?= 
Date: Fri, 1 May 2020 08:26:35 +0800
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009d25bf05a48b3c65"
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: Fri, 01 May 2020 00:26:51 -0000

--0000000000009d25bf05a48b3c65
Content-Type: text/plain; charset="UTF-8"

Yes

--0000000000009d25bf05a48b3c65
Content-Type: text/html; charset="UTF-8"


Yes


--0000000000009d25bf05a48b3c65--


From nobody Thu Apr 30 19:29:16 2020
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 060E53A0966 for ; Thu, 30 Apr 2020 19:29:15 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 RC_FJ59rZnL6 for ; Thu, 30 Apr 2020 19:29:12 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640102.outbound.protection.outlook.com [40.107.64.102]) (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 585173A0965 for ; Thu, 30 Apr 2020 19:29:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k1w80ytdYhgCCk8hZ+hpuGZ5AbFYP4ZxZBQMwaka8OQqDVJWpvH6OSptNOO9VJADUj4vJUab4rEif68iU6yLrtk4QC2DaEyMQG3fRA6UzIx3TqrB2yXnqtY4MTeEbc5CAcNbg2o4+cpI4NdFfp/oCu6QPpnz0zaQm5ZO8Sc9lgIIXPNUm7JndA663ka/l7R/NHxuxTxTa/G0NkcABJnLSPE/Qybi06w05iPAYH4KjmmVfQcqqOyvVB65LsF9pBFGOHsNbbkNS20V2xsCJPykAvWWaOjztD7Ln3d4uXzXdhIhfRulWCTA0eUvagxTvylh1xr8vMQ6RxBy7HCh6TwlnA==
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=PpUcBpviF5oVdoMvv4nELBEv9QPp+UxaFMzeHvCoOp0=; b=kBN3yZYeeI9ux/NOL6y921pg7FGHLiEf4MqI3VQUBQ9PXrF1wcMcrUqb9W95RRsHPvGGvaooGwEhiAzZ9it26DAEl8gEiNaQwhusAiiN8juWb2flbPS5sRRd+aCLZR9jiG7ggzpbFMQLhjJpppmxR/ULyNn8l2Ni0OURgJ+uv95F/GO6cnlw4/hYQ7nE2Gf+7k0ZYq9gXk9NApvkZOnDhg5FRIoRxUtv7QrjvG4ZvDJSuKeOpFnibmTGchm386DGVR+xnIBCcs3m7qbkAgSN3m2Mwc5JgtpJrTCFQm7+XZQRc2h6fPyMyFZlrxSsnQis+bIzOfqo8suMz8ucycgHLQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpUcBpviF5oVdoMvv4nELBEv9QPp+UxaFMzeHvCoOp0=; b=jKzz4cZI1dCkaUZKP7H2y4gytCK4m5ljQxXFFeJPd5cIm5qok6LhGkOWfef40hYIkf29msh+I2L60uNl7FAoCsCwHFQxTKEMB38pdV1VGcYitvT4O+c54rI+GJgEeMqc6GFXQG6mve0RjmtroGxzK8gyj1PJ0omxmCzb46PujiI=
Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0717.namprd00.prod.outlook.com (2603:10b6:208:1df::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3003.0; Fri, 1 May 2020 02:29:03 +0000
Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::40e9:d9bf:410:3971]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::40e9:d9bf:410:3971%6]) with mapi id 15.20.3003.000; Fri, 1 May 2020 02:29:03 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
CC: Dmitri Zagidulin 
Thread-Topic: Microsoft feedback on DPoP during April 2020 IIW session
Thread-Index: AdYfX/8GEMZtSZuLRhqv1yhDrQL0jA==
Date: Fri, 1 May 2020 02:29:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2701754c-70fd-45a1-a7f6-0000e2a50e78; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-01T00:21:08Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5e511b52-635b-435c-d551-08d7ed7769fc
x-ms-traffictypediagnostic: MN2PR00MB0717:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0390DB4BDA
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OEsk3GyvpK3S7SXZ8qpyfOqEKRtpsHnJ5k99+NUlGBbQ5cR7PnAy+cjKhDoS/ssg1cS8Di+9508Dkh0pPMCDi9kTSP93DA/9ee5rFBrA43/DSohtNAlGV0fsddeTJ2q6A766vVMq/qcHGqBH0L1su2ye97+NX3wyK5Pflnd5ydOi+jNKZDfrkn3nn0nM7izKft9eYP3w6zWHKLv+LMcWliiPUNhuoq7rRv8JIktHJH5+I8UaUmZPJrupjjnctfFasMW2cYl1iSOrIgmuJPon2lmiYSobI8hH4CGDezSbgfHK+bZehGfJP1XoMqP1EdK+aaoBxCm1+xsni4CkGQPNlwjdsDFzZVeqkvFD55gvCHSNie4xqKo3xWxFdxY9jMOJgGIsdUZqtokhZAfq9N7LTHGD+9J0cS3cNxhVHA5jP7il4pZ+4fvTgcIt47DOM27jJzJGyJqOVBYJEDSwFFern5ckQpFM/WQfroNvQ194Zw3Xcw01oHsAXUUhAl/LtobTuhUYx/tqI2W/lt0wzbgm7A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39860400002)(47530400004)(52536014)(66946007)(66476007)(64756008)(6916009)(66556008)(66446008)(4326008)(71200400001)(8676002)(8936002)(2906002)(6506007)(8990500004)(7696005)(9686003)(55016002)(186003)(26005)(316002)(82960400001)(82950400001)(86362001)(76116006)(10290500003)(478600001)(5660300002)(33656002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: mx1WkhtHbUATBZEf9Odsv7zSCkA7nEB9TRpMZgvs2ccDli0J84uTKWAM9U+yE7J7o7ydHGZanGBh9zjqRdRfUt3CiCD4IFleGEmmbumVCGxrYqRx/kaVIvj2IZCajm9FQiGmbQKz8Obcc+VQBdbAUXPjZwm8eOB6XJWLq4bS4YfjULRvJU57n4k0+8fOMGC7neBoH7CzaNnh7G/5evMPAFYRme5gRNIYMokaMY2ST1UBzCc77h7bjAaRMO5vFUSOMdKnzwxfEcawfedlMkjSQ/197FG0C1jgYgulxuIMWp+MPakfwEvO7xPrETIdCi2TnpdYxBlQa8G6YHip8mf1c2TMw7ZBUYsLxQapD87v2ubkzlUHpFBZ7NWl35awsyYtstZR4IFyJpKC95U51TVc6jj93KVvX9+8QNM7/yIbzo0gCwy0N02zEsorwzy8Lil/yRYdB8Y7tcUureHdBYQSM6qti2rUTVbCHxqRJpHcitaYj3CcBId497JqSo5Pwl9gflGKAqtioqTZBKReqTQkrvLHKgKDc5nWKsCHl8hTh/S25Xj1NV1Dbw6hDr3xsih4t4G3dGE2xxJptWZ/F5bAky4as0rDwbH97q3psBDIcAjNO3cpa6TqxFyTRIX/epVhxBe8agwSGNs8hokIyBH1/2srMsH1t+ec16kxdWWooz484OFuGKwpy4ImOs1f+0cm8HDXuudy3WnFpWltS4F4IvkllgxjFjRzBaVwEEhdWtnL54qA8hsRmhcCoMtS4g4ukLyFUVHCGZQTKCUiaCQlyE7ftIctJBJPTrkvYvWA2Ss=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0MN2PR00MB0686namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e511b52-635b-435c-d551-08d7ed7769fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2020 02:29:02.9461 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: i4Otq/tClsduuJ6pSjh2eRUbFgnSQCsqY4wgaT4zam8vAnPUMpzs/ZQU57LGALLZ9g4A4yPrx41kL7qa9GKNZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0717
Archived-At: 
Subject: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session
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, 01 May 2020 02:29:16 -0000

--_000_MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0MN2PR00MB0686namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0 Demons=
tration of Proof-of-Possession at the Application Layer (DPoP) at the virtualized IIW this week.  Attendees also included Vittorio B=
ertocci, Justin Richer, Dmitri Zagidulin, and Tim Cappalli.

After Daniel and DW finished doing their overview of DPoP, I used some of t=
he time to discuss feedback on DPoP from Microsoft Azure Active Directory (=
AAD) engineers.  We discussed:

  *   How do we know if the resource server supports DPoP?  One suggestion =
was to use a 401 WWW-Authenticate response from the RS.  We learned at IIW =
that some are already doing this.  People opposed trying to do Resource Met=
adata for this purpose alone.  However, they were supportive of defining AS=
 Metadata to declare support for DPoP and Registration Metadata to declare =
support for DPoP.  This might declare the supported token_type values.
  *   How do we know what DPoP signing algorithms are supported?  This coul=
d be done via AS Metadata and possibly Registration Metadata.  People were =
also in favor of having a default algorithm - probably ES256.  Knowing this=
 is important to preventing downgrade attacks.
  *   Can we have server nonces?  A server nonce is a value provided by the=
 server (RS or AS) to be signed as part of the PoP proof.  People agreed th=
at having a server nonce would add additional security.  It turns out that =
Dmitri is already doing this, providing the nonce as a WWW-Authenticate cha=
llenge value.
  *   Difficulties with jti at scale.  Trying to prevent replay with jti is=
 problematic for large-scale deployments.  Doing duplicate detection across=
 replicas requires ACID consistency, which is too expensive to be cost-effe=
ctive.  Instead, large-scale implementations often use short timeouts to li=
mit replay, rather performing reliable duplicate detection.
  *   Is the DPoP signature really needed when requesting a bound token?  I=
t seems like the worst that could happen would be to create a token bound t=
o a key you don't control, which you couldn't use.  Daniel expressed concer=
n about this enabling substitution attacks.
  *   It seems like the spec requires the same token_type for both access t=
okens and refresh tokens.  Whereas it would be useful to be able to have DP=
oP refresh tokens and Bearer access tokens as a transition step.  Justin po=
inted out that the OAuth 2 protocol only has one token_type value - not sep=
arate ones for the refresh token and access token.  People agreed that this=
 deserves consideration.
  *   Symmetric keys are significantly more efficient than asymmetric keys.=
  In discussions between John Bradley, Brian Campbell, and Mike Jones at IE=
TF 106, John worked out how to deliver the symmetric key to the Token Endpo=
int without an extra round trip, however it would likely be more complicate=
d to deliver it to the resource without an extra round trip.  At past IETFs=
, both Amazon and Okta have also advocated for symmetric key support.
  *   What are the problems resulting from PoP key reuse?  The spec assumes=
 that a client will use the same PoP key for singing multiple token request=
s, both for access token and refresh token requests.  Is this a security is=
sue?  Daniel responded that key reuse is typically only a problem when the =
same key is used for different algorithms or in different application conte=
xts, when this reuse enables substitution attacks.  It's also the case that=
 clients can choose to use different PoP keys whenever they choose to.
  *   Could access tokens be signed?  Having the DPoP key hash in the acces=
s token is equivalent if the access token is integrity protected.  But peop=
le said that many deployments don't use structured access tokens in which t=
he key hash can be included.  For instance, Ping Identity uses access token=
s that are just database indexes.  Would access token signing be needed the=
n?
  *   Why aren't query parameters signed?  Daniel said that canonicalizatio=
n of query parameters that use different URL escape syntaxes for representa=
tions of the same characters would likely result in interop problems.  Peop=
le said that while SOAP deployments might have many logical endpoints diffe=
rentiated only by query parameters, that's no longer the normal pattern for=
 REST systems.

Thanks for the great discussion!

                                                       -- Mike


--_000_MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0MN2PR00MB0686namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Daniel Fett and David Waite (DW) hosted a great sess=
ion on 
OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DP=
oP) at the virtualized
IIW this week.  =
Attendees also included Vittorio Bertocci, Justin Richer, Dmitri Zagidulin,=
 and Tim Cappalli.


 


After Daniel and DW finished doing their overview of=
 DPoP, I used some of the time to discuss feedback on DPoP from Microsoft A=
zure Active Directory (AAD) engineers.  We discussed:


    

  • How do we know if the resource server supports DPoP?  One=
 suggestion was to use a 401
WWW-Authenticate=
 response from the RS.  We learned at IIW that some are already doing =
this.  People opposed trying to do Resource Metadata for this purpose =
alone.  However, they were supportive of defining AS Metadata
 to declare support for DPoP and Registration Metadata to declare support f=
or DPoP.  This might declare the supported
token_type value=
s.
  • How do we know what DPoP signing algorithms are =
supported?  This could be done via AS Metadata and possibly Regist=
ration Metadata.  People were also in favor of having a default
 algorithm – probably ES256.  Knowing this is important to preventing downgrade =
attacks.
  • Can we have server nonces?
 A server nonce is a value provided by the server (RS or AS) to be=
 signed as part of the PoP proof.  People agreed that having a server =
nonce would add additional security.  It turns out that Dmitri is alre=
ady doing this, providing the nonce as a
WWW-Authenticate=
 challenge value.
  • Difficulties with
jti at sc=
ale.  Trying to prevent replay with
jti is problemat=
ic for large-scale deployments.  Doing duplicate detection across repl=
icas requires ACID consistency, which is too expensive to be cost-effective=
.  Instead, large-scale implementations often use
 short timeouts to limit replay, rather performing reliable duplicate detec=
tion.
  • Is the DPoP signature really needed when requ=
esting a bound token?  It seems like the worst that could happen w=
ould be to create a token bound to a key you don’t control, which
 you couldn’t use.  Daniel expressed concern about this enabling=
 substitution attacks.
  • It seems like the spe=
c requires the same
token_type for both access tokens and refresh tokens.  Whereas it would be =
useful to be able to have DPoP refresh tokens and Bearer access tokens as a=
 transition step.  Justin pointed out that the OAuth
 2 protocol only has one Symmetric keys are significantly more efficient =
than asymmetric keys.  In discussions between John Bradley, Brian =
Campbell, and Mike Jones at IETF 106, John worked out how to
 deliver the symmetric key to the Token Endpoint without an extra round tri=
p, however it would likely be more complicated to deliver it to the resourc=
e without an extra round trip.  At past IETFs, both Amazon and Okta ha=
ve also advocated for symmetric key support.
  • What are the problems resulting from PoP key reuse?  The spec ass=
umes that a client will use the same PoP key for singing multiple token req=
uests, both for access token and
 refresh token requests.  Is this a security issue?  Daniel respo=
nded that key reuse is typically only a problem when the same key is used f=
or different algorithms or in different application contexts, when this reu=
se enables substitution attacks.  It’s also
 the case that clients can choose to use different PoP keys whenever they c=
hoose to.
  • Could access tokens be signed?=
  Having the DPoP key hash in the access token is equivalent if the ac=
cess token is integrity protected.  But people said that many deployme=
nts
 don’t use structured access tokens in which the key hash can be incl=
uded.  For instance, Ping Identity uses access tokens that are just da=
tabase indexes.  Would access token signing be needed then?
  • Why aren’t query parameters signed?  Da=
niel said that canonicalization of query parameters that use different URL =
escape syntaxes for representations of the same characters
 would likely result in interop problems.  People said that while SOAP=
 deployments might have many logical endpoints differentiated only by query=
 parameters, that’s no longer the normal pattern for REST systems.=



 


Thanks for the great discussion!


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;        -- Mike


 






--_000_MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0MN2PR00MB0686namp_--


From nobody Thu Apr 30 20:57:21 2020
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 1CE673A0437 for ; Thu, 30 Apr 2020 20:57:20 -0700 (PDT)
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alkaline-solutions.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 Ioko1-UKNlxy for ; Thu, 30 Apr 2020 20:57:17 -0700 (PDT)
Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5436D3A041A for ; Thu, 30 Apr 2020 20:57:16 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 481ED3856D0; Fri,  1 May 2020 03:57:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1588305434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AnKDd86Et0K1UvyAnO3sZfIfbXnxg/PLgQCqO4fTktY=; b=L2blAQoyGnUBeyFGVBgXAbFtYuL1BXmPG6abxXs/5WVTkZoWSJh9PAfytqPZHWC/CWwkZT nIg7lzUP8oy9CGAccG7EvK/+KW9iuM1R8luzSLR4V+LLUc4iLWkiI0Dv3sNX06dPCug/kB j5rjqfSLitG3+Uxd3WUWQlf7TX3UQP0=
From: David Waite 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B05F55FA-442D-4199-B8F0-B9B37802FE47"
Mime-Version: 1.0
Date: Thu, 30 Apr 2020 21:57:12 -0600
In-Reply-To: 
Cc: "oauth@ietf.org" , Dmitri Zagidulin 
To: Mike Jones 
References: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1588305435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AnKDd86Et0K1UvyAnO3sZfIfbXnxg/PLgQCqO4fTktY=; b=j8IEW9Hd2FU+0lIkPlJ3d0yDzqmvPRcg6v3lI/eiQgOeBhf+lqXgiscCVfkA2nrGkIifRN 328f18F4VuS0pAHRHSDuSze4YjPeo2ukrFO5+MmXT5JTlDwqcdJ3JJFu79VpXqzgmSOIR8 NRfIVTuxQOMkK5VcelArLfH8BMYTSZY=
ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1588305435; a=rsa-sha256; cv=none; b=Oeab19V4Lxq39zSuFi0KWN1P5R/PszWSNJD3J/js/1flfOYPhWE0iQMfmGIzI/fT/yUQ7Z aQzXRvxtFu9wp9mLZPtlVe6lcpXJMx0smfoeemfFBs8VsLjlOJmrR4ZdxwRb0hmA/PP0it h1US2aszpzKvPUIYDm42piGersgQhjM=
ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session
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, 01 May 2020 03:57:20 -0000

--Apple-Mail=_B05F55FA-442D-4199-B8F0-B9B37802FE47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

To add: there was discussion was whether the =E2=80=9Chtu" parameter =
should contain scheme/host/port/path, or just scheme/host/port. Dmitri =
indicated that it would aid their implementation to have the path =
eliminated.=20

During JTI scale discussions, it was pointed out that some =
implementations may have individual protected resources at different =
paths behind a reverse proxy - attempting to implement one-time-use =
semantics would either require coordination between the path-bound =
protected resources, or for DPoP processing to be added as a function of =
the reverse proxy. One possible option proposed was separating out the =
scheme/host/port and the path to two parameters, so that they could have =
different recommendations around enforcement.

It was also alluded to that if there is eventually a round trip to =
negotiate a symmetric key with a resource, it is possible that system =
could leverage the secret to scope the token for JTI enforcement. I also =
wonder if the cryptographic requirement to use a different IV per =
message could be enforced by the recipient in lieu of a separate JTI as =
well (but admittedly I did not articulate this as well as I would have =
liked during the session)

-DW

> On Apr 30, 2020, at 20:29, Mike Jones =
 wrote:
>=20
> Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0 =
Demonstration of Proof-of-Possession at the Application Layer (DPoP) =
 at the =
virtualized IIW  this week.  =
Attendees also included Vittorio Bertocci, Justin Richer, Dmitri =
Zagidulin, and Tim Cappalli.
> =20
> After Daniel and DW finished doing their overview of DPoP, I used some =
of the time to discuss feedback on DPoP from Microsoft Azure Active =
Directory (AAD) engineers.  We discussed:
> How do we know if the resource server supports DPoP?  One suggestion =
was to use a 401 WWW-Authenticate response from the RS.  We learned at =
IIW that some are already doing this.  People opposed trying to do =
Resource Metadata for this purpose alone.  However, they were supportive =
of defining AS Metadata to declare support for DPoP and Registration =
Metadata to declare support for DPoP.  This might declare the supported =
token_type values.
> How do we know what DPoP signing algorithms are supported?  This could =
be done via AS Metadata and possibly Registration Metadata.  People were =
also in favor of having a default algorithm =E2=80=93 probably ES256.  =
Knowing this is important to preventing downgrade attacks.
> Can we have server nonces?  A server nonce is a value provided by the =
server (RS or AS) to be signed as part of the PoP proof.  People agreed =
that having a server nonce would add additional security.  It turns out =
that Dmitri is already doing this, providing the nonce as a =
WWW-Authenticate challenge value.
> Difficulties with jti at scale.  Trying to prevent replay with jti is =
problematic for large-scale deployments.  Doing duplicate detection =
across replicas requires ACID consistency, which is too expensive to be =
cost-effective..  Instead, large-scale implementations often use short =
timeouts to limit replay, rather performing reliable duplicate =
detection.
> Is the DPoP signature really needed when requesting a bound token?  It =
seems like the worst that could happen would be to create a token bound =
to a key you don=E2=80=99t control, which you couldn=E2=80=99t use.  =
Daniel expressed concern about this enabling substitution attacks.
> It seems like the spec requires the same token_type for both access =
tokens and refresh tokens.  Whereas it would be useful to be able to =
have DPoP refresh tokens and Bearer access tokens as a transition step.  =
Justin pointed out that the OAuth 2 protocol only has one token_type =
value =E2=80=93 not separate ones for the refresh token and access =
token.  People agreed that this deserves consideration.
> Symmetric keys are significantly more efficient than asymmetric keys.  =
In discussions between John Bradley, Brian Campbell, and Mike Jones at =
IETF 106, John worked out how to deliver the symmetric key to the Token =
Endpoint without an extra round trip, however it would likely be more =
complicated to deliver it to the resource without an extra round trip.  =
At past IETFs, both Amazon and Okta have also advocated for symmetric =
key support.
> What are the problems resulting from PoP key reuse?  The spec assumes =
that a client will use the same PoP key for singing multiple token =
requests, both for access token and refresh token requests.  Is this a =
security issue?  Daniel responded that key reuse is typically only a =
problem when the same key is used for different algorithms or in =
different application contexts, when this reuse enables substitution =
attacks.  It=E2=80=99s also the case that clients can choose to use =
different PoP keys whenever they choose to.
> Could access tokens be signed?  Having the DPoP key hash in the access =
token is equivalent if the access token is integrity protected.  But =
people said that many deployments don=E2=80=99t use structured access =
tokens in which the key hash can be included.  For instance, Ping =
Identity uses access tokens that are just database indexes.  Would =
access token signing be needed then?
> Why aren=E2=80=99t query parameters signed?  Daniel said that =
canonicalization of query parameters that use different URL escape =
syntaxes for representations of the same characters would likely result =
in interop problems.  People said that while SOAP deployments might have =
many logical endpoints differentiated only by query parameters, that=E2=80=
=99s no longer the normal pattern for REST systems.
> =20
> Thanks for the great discussion!
> =20
>                                                        -- Mike
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_B05F55FA-442D-4199-B8F0-B9B37802FE47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

To =
add: there was discussion was whether the =E2=80=9Chtu" parameter should =
contain scheme/host/port/path, or just scheme/host/port. Dmitri =
indicated that it would aid their implementation to have the path =
eliminated. 

During JTI scale discussions, it was pointed out that some =
implementations may have individual protected resources at different =
paths behind a reverse proxy - attempting to implement one-time-use =
semantics would either require coordination between the path-bound =
protected resources, or for DPoP processing to be added as a function of =
the reverse proxy. One possible option proposed was separating out the =
scheme/host/port and the path to two parameters, so that they could have =
different recommendations around enforcement.

It was also alluded to that if there is eventually =
a round trip to negotiate a symmetric key with a resource, it is =
possible that system could leverage the secret to scope the token for =
JTI enforcement. I also wonder if the cryptographic requirement to use a =
different IV per message could be enforced by the recipient in lieu of a =
separate JTI as well (but admittedly I did not articulate this as well =
as I would have liked during the session)

-DW

On Apr 30, 2020, at 20:29, Mike =
Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:

Daniel =
Fett and David Waite (DW) hosted a great session on OAuth 2.0 Demonstration of Proof-of-Possession at the =
Application Layer (DPoP) at the virtualized IIW this week.  Attendees =
also included Vittorio Bertocci, Justin Richer, Dmitri Zagidulin, and =
Tim Cappalli.
 
After Daniel and DW finished doing their overview of DPoP, I =
used some of the time to discuss feedback on DPoP from Microsoft Azure =
Active Directory (AAD) engineers.  We discussed:
  • How do we know if the resource =
server supports DPoP?  One suggestion was to use a 401 WWW-Authenticate response from the RS.  =
We learned at IIW that some are already doing this.  People opposed =
trying to do Resource Metadata for this purpose alone.  However, =
they were supportive of defining AS Metadata to declare support for DPoP =
and Registration Metadata to declare support for DPoP.  This might =
declare the supported token_type values.
  • How do we know what DPoP signing algorithms are =
supported?  This could be done via AS Metadata and possibly =
Registration Metadata.  People were also in favor of having a =
default algorithm =E2=80=93 probably ES256.  Knowing this is =
important to preventing downgrade attacks.
  • Can we have =
server nonces?  A server nonce is =
a value provided by the server (RS or AS) to be signed as part of the =
PoP proof.  People agreed that having a server nonce would add =
additional security.  It turns out that Dmitri is already doing =
this, providing the nonce as a WWW-Authenticate challenge value.
  • Difficulties with jti at scale.  Trying =
to prevent replay with jti is problematic for =
large-scale deployments.  Doing duplicate detection across replicas =
requires ACID consistency, which is too expensive to be =
cost-effective..  Instead, large-scale implementations often use =
short timeouts to limit replay, rather performing reliable duplicate =
detection.
  • Is the DPoP signature really needed =
when requesting a bound token?  It seems like the worst that =
could happen would be to create a token bound to a key you don=E2=80=99t =
control, which you couldn=E2=80=99t use.  Daniel expressed concern =
about this enabling substitution attacks.
  • It seems like the spec requires the same token_type for both access tokens and =
refresh tokens.  Whereas it would be useful to be able to have =
DPoP refresh tokens and Bearer access tokens as a transition step.  =
Justin pointed out that the OAuth 2 protocol only has one token_type value =E2=80=93 not =
separate ones for the refresh token and access token.  People =
agreed that this deserves consideration.
  • Symmetric keys are significantly more efficient than =
asymmetric keys.  In discussions between John Bradley, Brian =
Campbell, and Mike Jones at IETF 106, John worked out how to deliver the =
symmetric key to the Token Endpoint without an extra round trip, however =
it would likely be more complicated to deliver it to the resource =
without an extra round trip.  At past IETFs, both Amazon and Okta =
have also advocated for symmetric key support.
  • What are the problems resulting from PoP key reuse?  The spec assumes that =
a client will use the same PoP key for singing multiple token requests, =
both for access token and refresh token requests.  Is this a =
security issue?  Daniel responded that key reuse is typically only =
a problem when the same key is used for different algorithms or in =
different application contexts, when this reuse enables substitution =
attacks.  It=E2=80=99s also the case that clients can choose to use =
different PoP keys whenever they choose to.
  • Could access tokens be signed?  Having the DPoP key =
hash in the access token is equivalent if the access token is integrity =
protected.  But people said that many deployments don=E2=80=99t use =
structured access tokens in which the key hash can be included.  =
For instance, Ping Identity uses access tokens that are just database =
indexes.  Would access token signing be needed then?
  • Why aren=E2=80=99t query parameters =
signed?  Daniel said that canonicalization of query parameters =
that use different URL escape syntaxes for representations of the same =
characters would likely result in interop problems.  People said =
that while SOAP deployments might have many logical endpoints =
differentiated only by query parameters, that=E2=80=99s no longer the =
normal pattern for REST systems.
 
Thanks =
for the great discussion!
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_B05F55FA-442D-4199-B8F0-B9B37802FE47--


In section 1.5, step 8 in=
 the flow says:

The authorization server authenticates the cli=
ent and validates the refresh token, and if valid, issues a new access toke=
n (and, optionally, a new refresh token).

Also, Figure 2, step 8 says:

Access Token & Optional =
Refresh Token

=

Whether or not the refr=
esh token is rotated (as defined in section 6), doesn't the response al=
ways include a refresh token?=C2=A0

Since it seems =
likely that the more common use-case will be refresh token rotation, perhap=
s the wording in section 1.5 should lean that way?

Perhaps 1.5, step 8 should say:

The=
 authorization server authenticates the client and validates the refresh to=
ken, and if valid, issues a new access token and a new refresh token (or us=
es the same refresh token if certain security requirements are met).=


Perhaps Figure 2, step=
 8 should say:

Access T=
oken & Refresh Token

Best,

Micah