From nobody Mon Apr 1 04:33:47 2019 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 3267512002F for ; Mon, 1 Apr 2019 04:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 AzbIcjYbjMvh for ; Mon, 1 Apr 2019 04:33:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150070.outbound.protection.outlook.com [40.107.15.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E14F1200F4 for ; Mon, 1 Apr 2019 04:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bcq5LuuxGFRtGEufjmnbf792DNt5YqyTmoUUisigzlw=; b=fh4CY5Xmaii/HQQzJFbkzcQnznx+YoG1QI7LY/5xn7ybPig4xf06gG5K0ZKRIeyVM3+3+jNzojDRrj7Bt2W/lqvJeTSBe4pnnB8HODKrUS68WTBaZMlMstRfe/djoZLaV4cVRoYjChfHsXKJ8k+HcbUxGpMlQhKMQtL65sCl4EY= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3493.eurprd08.prod.outlook.com (20.177.114.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.22; Mon, 1 Apr 2019 11:33:39 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 11:33:39 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Early IANA registration for Token Exchange Draft Thread-Index: AdTofjcF436OdpU1SKqM5sEqrI5QxQ== Date: Mon, 1 Apr 2019 11:33:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [88.214.162.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2a17339-ed94-49ba-a202-08d6b695e317 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR08MB3493; x-ms-traffictypediagnostic: AM6PR08MB3493: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39860400002)(40434004)(199004)(189003)(53754006)(54896002)(97736004)(2906002)(33656002)(5024004)(14444005)(256004)(66066001)(72206003)(102836004)(6506007)(68736007)(14454004)(6916009)(6116002)(3846002)(6436002)(790700001)(4744005)(478600001)(71190400001)(71200400001)(25786009)(9686003)(7696005)(2351001)(105586002)(106356001)(53936002)(476003)(74316002)(486006)(86362001)(2501003)(8676002)(1730700003)(186003)(26005)(316002)(52536014)(55016002)(81156014)(7736002)(5660300002)(81166006)(99286004)(5640700003)(8936002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3493; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5+vpvl1OzlWI8ypQFftVDQOaNEPMHXYYSpxW97oDHmPPQfgNTEQJ1wmkfi4hn02dQ600nfL9yIAzEBV48F0PH4MQ32Xqi/fHvyCUyw0INW1P1vOsMivXB3OF0isSrYYrOeRDiqJIYjszZG3C/mEnWdnrZEKnHyZOtxPyDCCZEsjlxxcrN3AoSN0HsbXXVF04WKejF0RCcm6i48hyZWSzrieh8sbw7Ficsvr9maQ0lV69NpQS5DsCWjCO/wQp9cuxWbBnhVijSh7xtd6Ptu3kh5xbPNH7PuF1nxUDq6Lk1PyYAFz6HNBRYqEZCq3X7VAGpxnohVFsfEf2105pvUIG5msN/jmZdEPDPCF9NxJR6hYQ7joGQ7EJ6O40CCwUVH5a1jdd5KondMnXzqrQfhZhzuu+BnaKoaocWN+cCrl2QJM= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686C69BC942E942BDC50EB2FA550AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2a17339-ed94-49ba-a202-08d6b695e317 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 11:33:39.5352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3493 Archived-At: Subject: [OAUTH-WG] Early IANA registration for Token Exchange Draft 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, 01 Apr 2019 11:33:45 -0000 --_000_AM6PR08MB3686C69BC942E942BDC50EB2FA550AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all The authors of the token exchange draft asked IANA for an early registratio= n of URIs and parameters, token types, claims, etc. IANA asked me for review and I unfortunately do not know (or remember) why = this early registration is needed. Any reason to do this early registration? Ciao Hannes 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_AM6PR08MB3686C69BC942E942BDC50EB2FA550AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

The authors of the token exchan= ge draft asked IANA for an early registration of URIs and parameters, token= types, claims, etc.

 

IANA asked me for review and I = unfortunately do not know (or remember) why this early registration is need= ed.

 

Any reason to do this early reg= istration?

 

Ciao

Hannes

 

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_AM6PR08MB3686C69BC942E942BDC50EB2FA550AM6PR08MB3686eurp_-- From nobody Mon Apr 1 08:12:48 2019 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 0EA78120273 for ; Mon, 1 Apr 2019 08:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 BZQSU4MVLYSZ for ; Mon, 1 Apr 2019 08:12:38 -0700 (PDT) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 D91C812025A for ; Mon, 1 Apr 2019 08:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554131524; bh=QSKV8/yAbGDCHcIfb9k2NiimsstfwCpeCNvnMkio7PI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=OoOQTqPQZ1mbk3GLhMBu/XNTybjYgATWPp1b+UlGx2KEeoDsO+MUeiDmVc3d7uVplyxm7u9XZMkLBPWe2TXFXIdccumlURuD+UA+0uFKqNkPh1gLRPPXZHSzjfDQAMGyUliUDLsaBtvcFbZ9Og2b8EvLvt68oj4ITEW9obCKo0L/aYuPHqQVrPcBV8+7rIYjCbBTZpVeDuQ8PcEv/zDPL3gFFel3d2Sj5nPPPG5Be1wWci7TMhoGBGf9I3EMlWAjrqp1y+4DPeFQ+Qeyo01pfJIfO/siMuEUVMqu78rHpid8SS6hApWKie74lfJYsWMGgqTPePYbzc5dlXTGSztCUQ== X-YMail-OSG: zfHFtegVM1mdhKAYz2.O8nO2n.HRI6ORg.w3lbhoV0IsOFE0o4fP.wDJBBpiH0O rKfqhOF_Px7Q96k26z_2HR_c1SAKVVulJLBmy6qBGtHWGlH1abbBPcknUP1T6I9wB42VFfJKiHkm jQ2g0jQnqATfOLDRCbRYQeWp.hYwLXlWexrE9DJbKkZll.amaNMaQ1lLq56Krjx6kAGEr1r9JV6u Ur.hCF5153G8vjItwmxlEOs8YbivGKo0DLju8JU3pTIIvwYVDnV7_mdABuiJc7lFVcd9R4_QfudQ ukccEqxZh6u4auR22NYMs8vbUujO7iHoGlSNdCgrngP_Sf6xH6ahwL6xR4AR1KUarsFvdvbicB8s Zik0_s1G9D6tBDO.XjiTFuR94bA3ev73YVB0mH2psBxeadFb7eaSfu2_nXbh9TdsPIOfZkbwpupY DGXtSfwbUpo21SICnLvCc5VBTsywo.uk9cBng.nSpV7IZb9DHVhyemf5M.5U4nvOr3vUbeRvm4LG 8_N.96EbSW1am7GLVvUwYSmd98xNF9CDhpRevmhBk0EKDeI2C_SYaFu00IsLa7PpIYjBLebHO9Yf VIkdWDV22v8tddGqdazh0YiO4Qn2.Yb1omyc5ngtD_TzzMUyZVlF83zfDQaTb8AV2K3EBthUbAhK 1xliHkvg039jJvqktiLMjQ0rw5u2gvQL0mLtb70fubgf3onsVvgdL9zQ6qIJiG249iqHbQqm2Q8I R.6YsFcsV..laKRz9tc8H.6YMSkYMfZuU3EZuVTF2liKWHs9HbXJUPhSnZ29kmaTDIsf2vipg0qf IuQGE_hEzfwH.EyuLnZvMdbi3tdN5adsZahGIFKyhkpq3NM6rUvNCsE2KchyurjJHGDp2fgE48wO mvrOXCqtucMSorQq1eMGE5qT_hGcOWlJSLLLmRAHM4tJFzPSoKCTEhP.rsDaDTCpVuVy56QEEG0T oeGOnlqv_3.l1UBcgJ15k.U_Q1YGyR0Yf_ZMUO34Ygq1xvU2RZguidbXeDHcbEpOeK2HYrT4M.W1 DnmtpYRjdOWeVSOyC_xo9y93FEwSmU3XMuPdZIuCGC2weO4YM8WKcQUUDS1MfP2VL Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Mon, 1 Apr 2019 15:12:04 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 98946fadc4f8d133735a28b394727279; Mon, 01 Apr 2019 15:12:02 +0000 (UTC) To: Vittorio@auth0.com, IETF oauth WG References: From: George Fletcher Organization: AOL LLC Message-ID: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> Date: Mon, 1 Apr 2019 11:12:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------509EE0F3FFD7A96855C76C89" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 01 Apr 2019 15:12:42 -0000 This is a multi-part message in MIME format. --------------509EE0F3FFD7A96855C76C89 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for writing this up. One comment on auth_time... auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. Important: as this claim represents the time at which the end user authenticated, its value will remain the same for all the JWT access tokens issued within that session. For example: all the JWT access tokens obtained with a given refresh token will all have the same value of auth_time, corresponding to the instant in which the user first authenticated to obtain the refresh token. During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=login or max_age=NNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated. If we need a timestamp for when the "session" started, then there could be a session_start_time claim. Thanks, George On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this > doc came to be. The trajectory it followed is somewhat unusual. > > * Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using > JWT for their access token. The intent and scenarios addressed by > those solutions are mostly the same across vendors, but the syntax > and interpretations in the implementations are different enough to > prevent developers from reusing code and skills when moving from > product to product. > * I asked several individuals from key products and services to > share with me concrete examples of their JWT access tokens (THANK > YOU Dominick Baier (IdentityServer), Brian Campbell > (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) > for the tokens and explanations!). > I studied and compared all those instances, identifying > commonalities and differences. > * I put together a presentation summarizing my findings and > suggesting a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > * The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop > feedback and incorporate new ideas. John Bradley, Brian Campbell > Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes > Tschofenig were all there and contributed generously to the > discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a > note and I'll make things right at the next update. > * On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. > Rifaat, Hannes and above all Brian were all super helpful in > negotiating the mysterious syntax of the RFC format and submission > process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the > process. This is an amazing community. > V. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------509EE0F3FFD7A96855C76C89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=login or max_age=NNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.

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

--------------509EE0F3FFD7A96855C76C89-- From nobody Mon Apr 1 12:02:36 2019 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 2F0E11204E8 for ; Mon, 1 Apr 2019 12:02:27 -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, HTML_MESSAGE=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 8cTtFpMElfIt for ; Mon, 1 Apr 2019 12:02:23 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id BB42012004C for ; Mon, 1 Apr 2019 12:02:23 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:1f3:1570:3349:8b27] (unknown [IPv6:2601:282:202:b210:1f3:1570:3349:8b27]) by alkaline-solutions.com (Postfix) with ESMTPSA id 09A6331625; Mon, 1 Apr 2019 19:02:21 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AE3592FB-A2E8-4F9F-B2C0-CE78F7077A9F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 1 Apr 2019 13:02:20 -0600 In-Reply-To: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> Cc: Vittorio@auth0.com, IETF oauth WG To: George Fletcher References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 01 Apr 2019 19:02:34 -0000 --Apple-Mail=_AE3592FB-A2E8-4F9F-B2C0-CE78F7077A9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Do we know if there is a justifying use case for auth_time, acr, and amr = to be available in OAuth JWT access tokens? These are meant to be = messages about the client, either directly (in the case of client = credentials) or about its delegated authorization of the user. Embedding attributes about the user (such as group membership and roles) = can be used for the resource to make finer-grained decisions than = scopes, but normally I would expect say acr limitations enforced by a = resource to instead be controlled by the AS requiring a higher quality = authentication to release certain scopes. Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99t = provide these values, just that they might better be defined by those = extensions. -DW > On Apr 1, 2019, at 9:12 AM, George Fletcher = wrote: >=20 > Thanks for writing this up. One comment on auth_time... >=20 > auth_time OPTIONAL - as defined in section 2 of [OpenID.Core = ]. > Important: as this claim represents the time at which the end = user > authenticated, its value will remain the same for all the JWT > access tokens issued within that session. For example: all the > JWT access tokens obtained with a given refresh token will all > have the same value of auth_time, corresponding to the instant = in > which the user first authenticated to obtain the refresh token. >=20 > During a current session a user can be challenged for additional = credentials or required to re-authenticate due to a number of different = reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this = context, I'd assume that the auth_time value should be updated to the = latest time at which the user authenticated.=20 >=20 > If we need a timestamp for when the "session" started, then there = could be a session_start_time claim. >=20 > Thanks, > George >=20 > On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= >> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>=20 >> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >> Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >> I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).=20 >> I studied and compared all those instances, identifying commonalities = and differences.=20 >> I put together a presentation summarizing my findings and suggesting = a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! >> The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >> On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. >> I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 >> V. >>=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=_AE3592FB-A2E8-4F9F-B2C0-CE78F7077A9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Do = we know if there is a justifying use case for auth_time, acr, and amr to = be available in OAuth JWT access tokens? These are meant to be messages = about the client, either directly (in the case of client credentials) or = about its delegated authorization of the user.

Embedding = attributes about the user (such as group membership and roles) can be = used for the resource to make finer-grained decisions than scopes, but = normally I would expect say acr limitations enforced by a resource to = instead be controlled by the AS requiring a higher quality = authentication to release certain scopes.

Thats of course not to say extensions to OAuth = such as OIDC can=E2=80=99t provide these values, just that they might = better be defined by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, = George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20
Thanks for = writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined in =
section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a = current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume = that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT = profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.
I have a slot to discuss this tomorrow at = IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you = are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific = format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key = products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing = my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/berto= cci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 = hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all = there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to = incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, = involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.

_______________________________________________
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=_AE3592FB-A2E8-4F9F-B2C0-CE78F7077A9F-- From nobody Tue Apr 2 08:35:47 2019 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 E3A27120248 for ; Tue, 2 Apr 2019 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 I34Qx5MyNwev for ; Tue, 2 Apr 2019 08:35:37 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 E8D1012022B for ; Tue, 2 Apr 2019 08:35:36 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id a190so4313390ite.4 for ; Tue, 02 Apr 2019 08:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kD35J5bJopYrWsyvBkVajz152NgiThDRrwFDXq7Rqng=; b=g2IVJ3Akv753NXf8S7yxgKjIo7vnoQ1+TLWQiTFZdq6BNL23xsqIJp32gszXaXQ3yl 7wTv+7zOJV35CV7Gj7k/iHC2ugHpX80mllO/Jwolz8Et7T5GbwHrwnbxaH0z+mmNhJsg JhbK26Qn+zD6ovlUXPslJ+j5XBC0Qo52d9Luo= 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=kD35J5bJopYrWsyvBkVajz152NgiThDRrwFDXq7Rqng=; b=jYUljN4PY7vgIeDDLD07bM0Iq658L92n8i/5sk4DcnQazdnK19CE/zGresgS8X0J0d Bdg3goFY3EhDC0HMQ+eCOWYkXB/gPs9uHCeLpZ+QNvjx+JJWnkn57GA+CM0+N1XDg28C npT3yhnRg38EK8LZgV7tB6jTBtWfktgknftKuG1/uagYNIDmi6u6r0207dB3kfzbKXEX P3hXhfl2GX+u1gwprANudemlpwWGvYBJzup6ZSLoYhXFir8fDjvTiPlVGXodEnPLV94l K3v1jmq4xrqfOPWPSaSVTCum1fynmaILGL6oi96CliDmUj2yNMs0OsHZ8fkiJ2vJm0+R C3+A== X-Gm-Message-State: APjAAAX2mu4dpU5Fh8zYBrA981JmEbLHOQYRSfSpzGdq62vmcxiK+MFJ YouvsXdMpQEGbtNsmerVlYopLBt34nWjvxqPraJ7ngxXga2duQ4jQoOsUcf82N1oj6XXjJZOf14 seSTX+p5YVUKz9Q== X-Google-Smtp-Source: APXvYqynT7mOeyxeExfTcn2lOjcqRQZJI7QiEpCZhcvc3xUb4juyoC8qRk/WYqNFx5K8UxM5/JxlI0zwGpq4NRLeCt4= X-Received: by 2002:a24:d9d0:: with SMTP id p199mr4784389itg.104.1554219336138; Tue, 02 Apr 2019 08:35:36 -0700 (PDT) MIME-Version: 1.0 References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <22f70452-ae33-17a8-317e-1efbfc44d508@ri.se> In-Reply-To: From: Brian Campbell Date: Tue, 2 Apr 2019 10:35:06 -0500 Message-ID: To: Mike Jones Cc: Ludwig Seitz , oauth Content-Type: multipart/alternative; boundary="0000000000006f1e7805858de35c" Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 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, 02 Apr 2019 15:35:46 -0000 --0000000000006f1e7805858de35c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Except that the jwk header is more appropriate in the given context https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key that corresponds to the key used to digitally sign the JWS. Which is what it is. On Thu, Mar 28, 2019, 6:32 AM Mike Jones wrote: > Good observation, Ludwig. We should do that. > > -- Mike > > -----Original Message----- > From: OAuth On Behalf Of Ludwig Seitz > Sent: Thursday, March 28, 2019 12:05 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 > > On 28/03/2019 11:17, Daniel Fett wrote: > > Hi all, > > > > I published the first version of the DPoP draft at > > https://tools.ietf.org/html/draft-fett-oauth-dpop-00 > > > > Abstract > > > > This document defines a sender-constraint mechanism for OAuth 2.0 > > access tokens and refresh tokens utilizing an application-level > > proof-of-possession mechanism based on public/private key pairs. > > > > > > Thanks for the feedback I received so far from John, Mike, Torsten, > > and others during today's session or before! > > > > If you find any errors I would welcome if you open an issue in the > > GitHub repository at https://github.com/webhamster/draft-dpop > > > > - Daniel > > > > > > A quick nit: > > in figure 3 you seem to be using the "jwk" claim to include the pop-key i= n > the token. Any reason for not using the "cnf" claim from RFC 7800? > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > 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._ --0000000000006f1e7805858de35c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Except that the jwk header is more appropriate in th= e given context=C2=A0https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is=C2=A0= the public key that=C2=A0corresponds to the key used to digitally sign the = JWS.=C2=A0 Which is what it is.=C2=A0



On Thu, Mar = 28, 2019, 6:32 AM Mike Jones <Michael.Jones=3D40microsoft.co= m@dmarc.ietf.org> wrote:
Goo= d observation, Ludwig.=C2=A0 We should do that.

=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 -- Mike

-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf Of = Ludwig Seitz
Sent: Thursday, March 28, 2019 12:05 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00

On 28/03/2019 11:17, Daniel Fett wrote:
> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.= org/html/draft-fett-oauth-dpop-00
>
> Abstract
>
>=C2=A0 =C2=A0 =C2=A0This document defines a sender-constraint mechanism= for OAuth 2.0
>=C2=A0 =C2=A0 =C2=A0access tokens and refresh tokens utilizing an appli= cation-level
>=C2=A0 =C2=A0 =C2=A0proof-of-possession mechanism based on public/priva= te key pairs.
>
>
> Thanks for the feedback I received so far from John, Mike, Torsten, > and others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the > GitHub repository at https://gith= ub.com/webhamster/draft-dpop
>
> - Daniel
>
>

A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the p= op-key in the token. Any reason for not using the "cnf" claim fro= m RFC 7800?

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/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. --0000000000006f1e7805858de35c-- From nobody Tue Apr 2 09:00:43 2019 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 164141203A3 for ; Tue, 2 Apr 2019 09:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HxkcE-l6cJ57 for ; Tue, 2 Apr 2019 09:00:27 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 180B11202FA for ; Tue, 2 Apr 2019 08:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554220377; bh=xxWI3rqmIbIpDrqbbhCE/cffr/Tb+IZpSRmtf5isRCo=; h=To:From:Subject:Date:From:Subject; b=ETmz1OG0QO9khNYPQCRFHz+dslkXcziXP/Vj3Mapg+if5PiGtVDkqWROMHV+t9XBdzZ1RJKpbKuWiueWwo20jibxhc8G/QsyxSm35ZI6y4kcqNejBRVNhVjUrwWoKI1I3+0J/lG0Cumu8rtkeiJX1Zt+lXlHR79AEAgptLgFt+6Kq5So/oiuZceiDRgmm6nn3WB5x+wU6MiSvyqahxiE3YzkE4gEqrlFt6AX9o8FI/Qmz9qJuNheabakZGklXWkqZhCGCdoqKAghSCQi0ZgjUkkO/zHvqb4Ytmelovutnr9mCh9Gid1uW7c/z4whQ2H8RJku5gInL8gwVPqZ3no9ig== X-YMail-OSG: Y2d40tMVM1mBO17mphphrDtmkK0NiAPnUsgtuzmvK_T.eoFE2cg91KnAGwsE.Nz 6wmo_YCUR_psUXAwKfqSwjS7JFkwiyI9SfvwH3yrWj0vVi7F4AF5Ehydj41oIJaSyWKWOj4.Cmnh Jg25q0sMkzqRq.uqzYc55f2qMSg39ZRQco5opNUepSrCyBpMYo_oBHuuvY9bCtBYxR2lgB7YNuRy gEBppRlYQwlUovgJec0MIAfqkYCmS.AeLCu37cSGalzpVRAztXBWzQSv9.R1OA9EnVv.dAQA0n13 xaa1i4hM6I0rxccwya233F1XCY632F29cgzLTZzRQhPtkx1BsKrqNt.W9GWph4QP5mWdqQoVn2mg 5MYXxi6LYeI7lU5qM3oyLbfRACuuQbFbidhjqCRlbEFBcU6FQalC2LK4lcjZbs.Yw3UGOWrJQ.R5 y1VhExaI2z3ST0lOXKM_fx3wO3lSNUxFojpZbZUSL8i.Xnr6CyQBJqrBzDrhFuqUjwohJZpTZTCI BQ4_3CTKIcj05mKndDyjAoX0rXrDJHG7YaSeWX1XtIqlVnuL6REeobQtcJWsjTisUbF4eYKfjL6f 5Y1J9uZrAANgn6psx2.2tVuf6g3.5OOIOhRe0clWAwoTuyb6AqLlsx8gwLlm7WkUO_ErwonqglYy sey3bjs2Nt9tRKqB6Qo0lPyS.W5AAOhT9OvGe0aCTDDx1DirGH.ccytFwBZoV1VI0_uQIdHhgeE2 6c1QRzljJSKDvXaM0ScjQIvLQOgR0BXglH5mKCaU0LKEpvy.fP0y7aUZAmhjuuHB5_7sJ42..NWg GNRSw0c7L12csaJUpGz_M1ITkB5Cust0m165mOC_0_GssGwtLmhxeuoKe8pSs3qO7E1kDZZ94NNx 2FYvNf4.SAadeaiNxob0RK_OLQ5ZNQ5hIMUAa5zB.Zm7LRClw9g8EzQZxv5_KDpP6eFiAdccTw_r bCLgJ0xv4Wkc3Y8eexfbssG.62tDKPIrem08d14E6XupK7daetcmVPTJ2qnAYHaOIMRzqiMDZH3R x1VwrwBAiA.R2buto1XUpjiM54n0kiSsOuB4khbHNxYKOEf3Qge7ThQwURsUc_kPt Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Tue, 2 Apr 2019 15:52:57 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fb15d0a0cf54bbcb20c150751493cc24; Tue, 02 Apr 2019 15:52:53 +0000 (UTC) To: Aaron Parecki , David Waite , "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 2 Apr 2019 11:52:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4DBE538A243C8ECCC9560638" Content-Language: en-US Archived-At: Subject: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 02 Apr 2019 16:00:37 -0000 This is a multi-part message in MIME format. --------------4DBE538A243C8ECCC9560638 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, In section 6.2 the following statement is made... In this scenario, the backend component may be a confidential client which is issued its own client secret. Despite this, there are still some ways in which this application is effectively a public client, as the end result is the application's code is still running in the browser and visible to the user. I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client's code is "visible" to externals or not, but rather whether the client can protect the secret. In that sense I don't believe this deployment model is "effectively a public client". A hybrid model description is fine, and I don't disagree that some authorization servers may want to treat these clients in a different way. Thanks, George --------------4DBE538A243C8ECCC9560638 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.

I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client's code is "visible" to externals or not, but rather whether the client can protect the secret.

In that sense I don't believe this deployment model is "effectively a public client". A hybrid model description is fine, and I don't disagree that some authorization servers may want to treat these clients in a different way.

Thanks,
George
--------------4DBE538A243C8ECCC9560638-- From nobody Tue Apr 2 09:01:31 2019 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 394C612057B for ; Tue, 2 Apr 2019 09:01:16 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lc2Rot3O4NUW for ; Tue, 2 Apr 2019 09:01:12 -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 1C7F7120253 for ; Tue, 2 Apr 2019 08:57:38 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id b9so11314139iot.13 for ; Tue, 02 Apr 2019 08:57:38 -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=dZ1Og3WVklPXxy4A5Fn4Oed9CEsr7tp25pAjJ651KxQ=; b=GcT2EczyvZsLw1mC+81AllsLbm068xzQhqwgWbs+Kck2gZGR9Q8c1Z7s3m1Q5ebtjs dNVd/Ze78AhodmBx9SG9YaZWt3CxYeDxrMiIkOw0I8VWQgMdfQyoDkpYPuBCuskp9kXs QEUe6LDwrc+v1JZRAsbhlPFCixw8jAaHZfc3H/gzbWQDMl4grx9DQQeS5ASQ7DDAwHuF xXXQ7HQU9jMhcEHA3Dm0Ylu//egdrSrUTEgdA2u5vobdKgFmBn9aizt6qWIOtmLuMywB ynhBKhDg/qQcNMfdbRcy7NBA8kyVglggugYXs+m6Y5ZCMRKFEl5DqOnOb8KKXvBdRwCH g4lw== 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=dZ1Og3WVklPXxy4A5Fn4Oed9CEsr7tp25pAjJ651KxQ=; b=PQMJypcjPQ2RRfeDNBCYQeH/2w2l3xU1y51KyBeqlI4RfqvyRFAgFL06jPOBCa0/uC 75y+8nK+XzrvqebJFyzQVr1r0KHX+iMeQE9sAnxtizpYN5qLh+l0MDKXc2XdMX286EU7 kaziPt5uSBbNP5Ml/6xqoNgqvezBgn/7+XM8Es3JGJw3JXH+sfDy66NkvAiHmCccKHNP +IkQAKvTt6HQDPT9+YMW1Fudpmvn1OcYh9ItXsGZQHfGZBI9bOEcWDCjCGbel1eXPnJW yOQPUrtdDo71gcdGa7kz+NTNas+usu8gYfp1SHi99PF2Rq1DiH0/jDkAhej/eQVrICfJ yBAg== X-Gm-Message-State: APjAAAXxIG8NwB1IkzlbVh80N+6c85MISHF3gPjqGD3JaqjbeBzku88K eI4zygjXjN0FV2yoE8Q3zzlPAflNUpE= X-Google-Smtp-Source: APXvYqywlcmlKg9yP4Bgqsagi0T/VjvnWW20dwHJmp0VgZ8Qpzy8ViXn+Cc/J6W8HrkfEk4QI5VqLg== X-Received: by 2002:a5e:df07:: with SMTP id f7mr42068506ioq.166.1554220657151; Tue, 02 Apr 2019 08:57:37 -0700 (PDT) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id s1sm5692145ioe.18.2019.04.02.08.57.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 08:57:36 -0700 (PDT) Received: by mail-it1-f169.google.com with SMTP id y10so6123199itc.1 for ; Tue, 02 Apr 2019 08:57:36 -0700 (PDT) X-Received: by 2002:a24:4d85:: with SMTP id l127mr4496236itb.53.1554220656174; Tue, 02 Apr 2019 08:57:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 2 Apr 2019 08:57:24 -0700 X-Gmail-Original-Message-ID: Message-ID: To: George Fletcher Cc: David Waite , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001d342305858e32c3" Archived-At: Subject: Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 02 Apr 2019 16:01:23 -0000 --0000000000001d342305858e32c3 Content-Type: text/plain; charset="UTF-8" Thanks, this is a good question. I was talking with someone about this draft the other day and had the same question myself. Re-reading RFC6749, "public client" does describe only the limitation of the client protecting its own credentials, so I think you're right that this paragraph is misleading. However I suspect that some ASs will still want to treat clients where the access token ends up in the browser differently. Is that a fair assessment? I think the fix to this paragraph would be a slight rewording to just remove the mention of public clients. Aaron On Tue, Apr 2, 2019 at 8:53 AM George Fletcher wrote: > Hi, > > In section 6.2 the following statement is made... > > In this scenario, the backend component may be a confidential client > which is issued its own client secret. Despite this, there are still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user. > > > I'm curious as to how this model is different from many existing resource > server deployments acting as confidential clients. While the application > code is running in the browser, only the access token is exposed to the > browser as is the case for many RS deployments where the RS returns the > access token to the browser after the authorization flow completes. My > interpretation of "confidential client" does not include whether the > client's code is "visible" to externals or not, but rather whether the > client can protect the secret. > > In that sense I don't believe this deployment model is "effectively a > public client". A hybrid model description is fine, and I don't disagree > that some authorization servers may want to treat these clients in a > different way. > > Thanks, > George > -- ---- Aaron Parecki aaronparecki.com @aaronpk --0000000000001d342305858e32c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, this is a good question. I was talking with = someone about this draft the other day and had the same question myself. Re= -reading RFC6749, "public client" does describe only the limitati= on of the client protecting its own credentials, so I think you're righ= t that this paragraph is misleading. However I suspect that some ASs will s= till want to treat clients where the access token ends up in the browser di= fferently. Is that a fair assessment? I think the fix to this paragraph wou= ld be a slight rewording to just remove the mention of public clients.=C2= =A0

Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <= gffletch@aol.com> wrote:
=20 =20 =20
Hi,

In section 6.2 the following statement is made...

   In this scenario, the ba=
ckend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.

I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client'= ;s code is "visible" to externals or not, but rather whether the client = can protect the secret.

In that sense I don't believe this deployment model is "effect= ively a public client". A hybrid model description is fine, and I don= 9;t disagree that some authorization servers may want to treat these clients in a different way.

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

--0000000000001d342305858e32c3-- From nobody Tue Apr 2 09:10:19 2019 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 6FDE2120110 for ; Tue, 2 Apr 2019 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 00BO2AeFAcHT for ; Tue, 2 Apr 2019 09:10:14 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 4E5C7120115 for ; Tue, 2 Apr 2019 09:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554221410; bh=tQcJF6IWlXAYBC3qLQm4ZlMJfo6JVu6AZIHgC+r+2/E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hMXerOfRlzw9K3y/qKGGWyIBB3+PwKu/GBKNfRQfdNXj/9WyREc1HzCc0JwFGQUkYZfkWFHuD7qwwp3TPQ1CvFH+NXU7t+ZAESEZMppbpNHxfOUhzCnwudB4rwZ2NuOMlz2f+ZQksFdFa8c1upOPp/5xyzX947TOclXm2PZCLbR9ZAOcAjWmia3evCQwghKbogySvIw6PhZ/oqc3W0Tp+tWQ5iXdlKH0mnOMWffk1g1/hn90ZDJfVn1xH/4xAJyCVYEMiFdLB3jt4JTJi2w1xovhfX1I5k8/6HIF7wKP3nkdT4ZzaUR46BmruE/GjPhKT1l3J3x2KUtCT68fsGXvBw== X-YMail-OSG: aLXSRUsVM1mghgQhHxilhhJk_lpDfbp63o2wvNV2Tt7EbNv..xkvwOiVYuwtPwj o27514xe8EsA0hWk5hcO2tOajE9MQDc067_sTJcd3eMNdEGjSuNSM9Rz3jqP.3poW1V0.iwfI0My Fwd7bStmR4YvRaJkUpPYDhmMR7qQzqUbRYQ_1WHg2OP49NsrBxjqjCjZS0mwPhiEMj96FNHY0e8T 3J.sBGYV0n2vyJad4VOt.ItkEPezwkOiCGTepiVoWcEidfnEsoCNp4eh_EMAnFXqXlmGf2xQi0Pu rFAGXSBf4QxoO5Kva_aqLUMa5Cxz9rPEbFFrNB5UF8QQfKafvhJ5WHsGN7FB_i7cX4RTpBwSMhtJ QWn8DiRKGKig1xc7ql2INezamwZj5Cm9aloJsp6GsO8gcB_EjkZGybq35fibxDUP0mTF8zVaNuFE b3zdw2uORVYiYKZ9KLms.W3lpalqkFGGKbdgmgAdBFGIuBWeNF._n7xY4AXBFfZx8.Pmn91pvkqX rq1wiMjGS0nX9YvYF5dCPNKY2AtIFX4tNxqM6szNoqUeRVUfHLWRz9jMoJqb_aXzieKz0WnoW.YS DEuyCkjACr89gpu_qgB6QU0r4aqRua8CvlGm.nFzAj6zbchB2gPdo3Et9EJSSDRW0nYREQREiE6p DS8WvyBjas8msdAkwEvMgaIZZ7Xlwxa979LO6w3vldNup_zYfRlkXUe0kt3Ghphuq8qKCSTHIqUy uRSqbc_XAFkekPDYLyn_Sf1UGeR.5DJCH1cAQOpNEkHhGBRMxkde6sZgD08gVAqmS9xn_udHj7iy wTmlD_MuTBvqSZFQ6J5NCetdlaQJZNCUByYopNF.3jtdrK8eknqnLRonwsegHsKY5iiRWtLMUdcq s9LMPqS09r.bzm9AEhTfw0InLToNYaaQBNzK0X5IgVOZpT2r.Nr1GYEwYK9g06aRf5NwQNrup_Nv IXjNbI_.cHCZrOpOxWqyRGvHTPNRy4VU8kbxT4_dULrYtIVtjynhHVSq6ncODgqCdseaGM2TSbMI OSfuSqEjcr3B8dzS4IovMvWhCJ57a5wM6zBDyXEBPlptaXGmHgB8dyA8RH8E0_Uk9GgU2bYDxp9T VF8xhx3c34kM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 2 Apr 2019 16:10:10 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID be35d5a18eb5c9cdc1d0b863fd8ffff1; Tue, 02 Apr 2019 16:10:07 +0000 (UTC) To: Aaron Parecki Cc: David Waite , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Tue, 2 Apr 2019 12:10:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2CEDBE0AFE650E795033099D" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 02 Apr 2019 16:10:17 -0000 This is a multi-part message in MIME format. --------------2CEDBE0AFE650E795033099D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think it's fair to call it out (either in the paragraph here or in the security considerations). The issue is that the security aspect of the access token ending up in the browser is probably true in many contexts other than SPAs:) What about something like... In this scenario, the backend component is likely a confidential client which is issued it's own client secret. Note that in this model, the access_token obtained by the backend component will be delivered to the browser for use by the SPA so is more exposed than in the classic confidential client model. Some Authorization Servers may wish to limit the capabilities of these clients due to risk considerations. ... or something like that. On 4/2/19 11:57 AM, Aaron Parecki wrote: > Thanks, this is a good question. I was talking with someone about this > draft the other day and had the same question myself. Re-reading > RFC6749, "public client" does describe only the limitation of the > client protecting its own credentials, so I think you're right that > this paragraph is misleading. However I suspect that some ASs will > still want to treat clients where the access token ends up in the > browser differently. Is that a fair assessment? I think the fix to > this paragraph would be a slight rewording to just remove the mention > of public clients. > > Aaron > > > On Tue, Apr 2, 2019 at 8:53 AM George Fletcher > wrote: > > Hi, > > In section 6.2 the following statement is made... > > In this scenario, the backend component may be a confidential client > which is issued its own client secret. Despite this, there are still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user. > > > I'm curious as to how this model is different from many existing > resource server deployments acting as confidential clients. While > the application code is running in the browser, only the access > token is exposed to the browser as is the case for many RS > deployments where the RS returns the access token to the browser > after the authorization flow completes. My interpretation of > "confidential client" does not include whether the client's code > is "visible" to externals or not, but rather whether the client > can protect the secret. > > In that sense I don't believe this deployment model is > "effectively a public client". A hybrid model description is fine, > and I don't disagree that some authorization servers may want to > treat these clients in a different way. > > Thanks, > George > > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > --------------2CEDBE0AFE650E795033099D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think it's fair to call it out (either in the paragraph here or in the security considerations). The issue is that the security aspect of the access token ending up in the browser is probably true in many contexts other than SPAs:)

What about something like...

In this scenario, the backend component is likely a confidential client which is issued it's own client secret. Note that in this model, the access_token obtained by the backend component will be delivered to the browser for use by the SPA so is more exposed than in the classic confidential client model. Some Authorization Servers may wish to limit the capabilities of these clients due to risk considerations.

... or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:
Thanks, this is a good question. I was talking with someone about this draft the other day and had the same question myself. Re-reading RFC6749, "public client" does describe only the limitation of the client protecting its own credentials, so I think you're right that this paragraph is misleading. However I suspect that some ASs will still want to treat clients where the access token ends up in the browser differently. Is that a fair assessment? I think the fix to this paragraph would be a slight rewording to just remove the mention of public clients. 

Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <gffletch@aol.com> wrote:
Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.

I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client's code is "visible" to externals or not, but rather whether the client can protect the secret.

In that sense I don't believe this deployment model is "effectively a public client". A hybrid model description is fine, and I don't disagree that some authorization servers may want to treat these clients in a different way.

Thanks,
George
--
----
Aaron Parecki


--------------2CEDBE0AFE650E795033099D-- From nobody Tue Apr 2 23:28:37 2019 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 E30E8120494 for ; Tue, 2 Apr 2019 23:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=risecloud.onmicrosoft.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 pF-QJoO6PF_x for ; Tue, 2 Apr 2019 23:28:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140085.outbound.protection.outlook.com [40.107.14.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF89120059 for ; Tue, 2 Apr 2019 23:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3mRoYef7JiWiD8ZxwYkLtX0C0GbohNs2dH+JG55A/+k=; b=TnCCHrGiExfVgu9s5uDTtBwA484ULrCTW/7/4qetOccPOhOE+wg1WnC7eLRhCw2l3V2Zp6yYnPYpzcEY2I0g3Mn3J2m10jZEgkHsEJQDxGU3M3DtruuQrpLzMOuIo/WEYEhklqlQQ/zo+5hx3YZ0Nr9VMWX/cOiTD3nhNvlN8Nc= Received: from VI1P189CA0031.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::44) by HE1P18901MB0106.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:9b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Wed, 3 Apr 2019 06:28:26 +0000 Received: from AM5EUR02FT056.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::203) by VI1P189CA0031.outlook.office365.com (2603:10a6:802:2a::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17 via Frontend Transport; Wed, 3 Apr 2019 06:28:25 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT056.mail.protection.outlook.com (10.152.9.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Wed, 3 Apr 2019 06:28:25 +0000 Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 3 Apr 2019 08:28:24 +0200 To: Brian Campbell , Mike Jones CC: oauth References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <22f70452-ae33-17a8-317e-1efbfc44d508@ri.se> From: Ludwig Seitz Message-ID: <4563969a-e4b9-2092-ea73-d3342db65e27@ri.se> Date: Wed, 3 Apr 2019 08:28:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050609090508020504070504" X-Originating-IP: [10.100.0.158] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(189003)(199004)(11346002)(7736002)(64126003)(126002)(44832011)(106002)(58126008)(305945005)(93886005)(486006)(478600001)(31686004)(5660300002)(6666004)(966005)(16576012)(97736004)(110136005)(5024004)(14444005)(74482002)(6306002)(6246003)(16586007)(6116002)(235185007)(3846002)(69596002)(568964002)(68736007)(356004)(65806001)(53546011)(336012)(104016004)(53936002)(8936002)(186003)(26005)(5000100001)(2906002)(4326008)(16526019)(22746008)(81156014)(40036005)(229853002)(22756006)(476003)(386003)(2616005)(33964004)(86362001)(316002)(76176011)(106466001)(8676002)(31696002)(65826007)(65956001)(446003)(84326002)(77096007)(36756003)(81166006)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0106; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2b2e23c8-4343-4d95-ed16-08d6b7fd93c8 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1P18901MB0106; X-MS-TrafficTypeDiagnostic: HE1P18901MB0106: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0996D1900D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: NlOJ2S09A235OgEosROGzq0S9+dXwiYVvAeNlMvxNs7zyEsVR9U7/m8fLDzkFTg0SnXQzBJRwB1q00X7wW0VkDyKxvoytgIDVW+bBV/6sgykweTQrvzWSmG6zqW/ufM7PrbtO+paZbfRgbYT6tbeA6UWcpXNZ357CvyQ44Y55TqXij4vHzseZfhxipZnBqUaoVW9GBOGTlmTb8Qa2NNwUzAYcv/6lHX0D4XwFc71H4vfJEz8SRUsJ8gILGmnBw549pRj0RydEJfgFEH9/LlLK1W72nhLJFU1Ar3Daw9thhg2hz9GQ7epkglHUue8ZUCMLr4K7fxgc83gbRcK2WaEJbm2/CmTcM0jZwlrtULv5wQhLmrAppgwRLK6fSRmltuU1fqsdh/Me0l4chtrwidfpyeo9hntUPsNQcDqmkfqpaU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2019 06:28:25.2370 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2b2e23c8-4343-4d95-ed16-08d6b7fd93c8 X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0106 Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 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, 03 Apr 2019 06:28:35 -0000 --------------ms050609090508020504070504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 02/04/2019 17:35, Brian Campbell wrote: > Except that the jwk header is more appropriate in the given context=20 > https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is=C2=A0the publ= ic key=20 > that=C2=A0corresponds to the key used to digitally sign the JWS.=C2=A0 = Which is=20 > what it is. >=20 >=20 > A quick nit: >=20 > in figure 3 you seem to be using the "jwk" claim to include the > pop-key in the token. Any reason for not using the "cnf" claim from= > RFC 7800? >=20 > /Ludwig >=20 My bad, figure 3 is not a token (although it looks like one) it's the=20 token request (encapsulated in a JWS). /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms050609090508020504070504 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 DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQwMzA2 MjgxMlowLwYJKoZIhvcNAQkEMSIEIEIBU4oyxhXtZNJb6KohxWS+ImjmEPq36qtN8LW3kvAW MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAF+1JJv+pJGX8tat12i0pWmB4vvUfNtMt0CDZR5zO0Tlq BXbc/lfDNzckClSux3Bk7nSMYvicI2i+LwO+2k7r2OxpNTC6VFNpmJYaKnd47tgJKIgDK9lg 23WSsZj98uCuRnhyVh83o3XFoUqsFNYIh4euXmSATCicoLdxbGSbw2BoRNJp8NJJNqyfnFLY 1InzsT0uAdghIHFutQlzsRr+he0JkmLg6qA/A9BXE8F3wd1hGIH6GCYVlvguCO3vIkyqiehA owbLfMgSRU5YvH39kjFBY7yL39CCUYTiAxDZfgWrn6xT+L6BSElmKu2PNO6ZQoOGJ/4RkKBv gUtjWdrs2QAAAAAAAA== --------------ms050609090508020504070504-- From nobody Wed Apr 3 05:12:37 2019 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 383ED120111 for ; Wed, 3 Apr 2019 05:12:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zl0HF8Vozgc3 for ; Wed, 3 Apr 2019 05:12:33 -0700 (PDT) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 2EA251200D6 for ; Wed, 3 Apr 2019 05:12:32 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id n4so9817574vsm.3 for ; Wed, 03 Apr 2019 05:12:32 -0700 (PDT) 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=BrzaZgm1+7ZWmsCkSo3tbCshVhc6YE8Fw6IzLVmdXDM=; b=M3QHLBJuKJ8VjIRKe9xpkWqq6u2YK6fv7gy7glJOV9c70ciGUmBkGTT+8L/VsfC8HY xnwrPGyxhtScxlahHCAlGfasIwQR01+9AsSm3G2b+noeILyABUnQ97LOJoIWnsmnIKPC ZBK0cjh81ExJILq6wrI6zqsxZqWYR4kMC0MbcqjpPcCflu+EH758vH+VKdUyOuekMs4Z 9IlFrpXddyDO9ByPvAanGKCccl8VIf+jqjexry6wofsX6So7PyU2ZI6sNpRdHCYNp87P snO1TZH78v6NGUQtY9vXIW5hbM9MeDCopFL3AqJvn9phJnNsqu2Tom2qnqQ4fC96Y1oq gwCA== X-Gm-Message-State: APjAAAXRgMvXTWQqK6hgfIFa6YwzFMhoGrzKw52Pu+Z5T9vkN53B6c+j CLOJPTr+F7R/FMX4nn477o838Xhlh3OtdDQpLB+sVA== X-Google-Smtp-Source: APXvYqz/LLaW419HUFJTCaDdoUNOsmeg7jlM6TnNlApTRTHWAOyfnC1gcKS7LJaYBOj48tC57p1fbho8YCUDiOV6eoA= X-Received: by 2002:a67:e889:: with SMTP id x9mr2082691vsn.29.1554293551374; Wed, 03 Apr 2019 05:12:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pedro Igor Silva Date: Wed, 3 Apr 2019 09:12:20 -0300 Message-ID: To: George Fletcher Cc: Aaron Parecki , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000001b83705859f2b82" Archived-At: Subject: Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 03 Apr 2019 12:12:36 -0000 --00000000000001b83705859f2b82 Content-Type: text/plain; charset="UTF-8" Hi, I've seem some implementations where the token is not directly delivered to the browser by the backend, but some temporary UUID that later the SPA can exchange for an access token. Do you think this is a good approach to the recommendation you are discussing? In addition to that, could you clarify more what would be the limitations that ASes may wish to impose to these clients? Regards. Pedro Igor On Tue, Apr 2, 2019 at 1:10 PM George Fletcher wrote: > I think it's fair to call it out (either in the paragraph here or in the > security considerations). The issue is that the security aspect of the > access token ending up in the browser is probably true in many contexts > other than SPAs:) > > What about something like... > > In this scenario, the backend component is likely a confidential client > which is issued it's own client secret. Note that in this model, the > access_token obtained by the backend component will be delivered to the > browser for use by the SPA so is more exposed than in the classic > confidential client model. Some Authorization Servers may wish to limit the > capabilities of these clients due to risk considerations. > > ... or something like that. > > On 4/2/19 11:57 AM, Aaron Parecki wrote: > > Thanks, this is a good question. I was talking with someone about this > draft the other day and had the same question myself. Re-reading RFC6749, > "public client" does describe only the limitation of the client protecting > its own credentials, so I think you're right that this paragraph is > misleading. However I suspect that some ASs will still want to treat > clients where the access token ends up in the browser differently. Is that > a fair assessment? I think the fix to this paragraph would be a slight > rewording to just remove the mention of public clients. > > Aaron > > > On Tue, Apr 2, 2019 at 8:53 AM George Fletcher wrote: > >> Hi, >> >> In section 6.2 the following statement is made... >> >> In this scenario, the backend component may be a confidential client >> which is issued its own client secret. Despite this, there are still >> some ways in which this application is effectively a public client, >> as the end result is the application's code is still running in the >> browser and visible to the user. >> >> >> I'm curious as to how this model is different from many existing resource >> server deployments acting as confidential clients. While the application >> code is running in the browser, only the access token is exposed to the >> browser as is the case for many RS deployments where the RS returns the >> access token to the browser after the authorization flow completes. My >> interpretation of "confidential client" does not include whether the >> client's code is "visible" to externals or not, but rather whether the >> client can protect the secret. >> >> In that sense I don't believe this deployment model is "effectively a >> public client". A hybrid model description is fine, and I don't disagree >> that some authorization servers may want to treat these clients in a >> different way. >> >> Thanks, >> George >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000001b83705859f2b82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I've seem some imple= mentations where the token is not directly delivered to the browser by the = backend,=C2=A0but some temporary UUID that later the SPA can exchange for a= n access token.

Do you think this is a good approa= ch to the recommendation you are discussing?

In ad= dition to that, could you clarify more what would be the limitations that A= Ses may wish to impose to these clients?

Regards.<= /div>
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher <gffl= etch=3D40aol.com@dmarc.ietf.org= > wrote:
=20 =20 =20
I think it's fair to ca= ll it out (either in the paragraph here or in the security considerations).= The issue is that the security aspect of the access token ending up in the= browser is probably true in many contexts other than SPAs:)

What about something like...

In this scenario, the backend component is likely a confidential = client which is issued it's own client secret. Note that in this model,= the access_token obtained by the backend component will be delivered to th= e browser for use by the SPA so is more exposed than in the classic confide= ntial client model. Some Authorization Servers may wish to limit the capabi= lities of these clients due to risk considerations.

... or something like that.

On 4/2/19 11:= 57 AM, Aaron Parecki wrote:
=20
Thanks, this is a good question. I was talking wi= th someone about this draft the other day and had the same question myself.= Re-reading RFC6749, "public client" does describe only the limit= ation of the client protecting its own credentials, so I think you're r= ight that this paragraph is misleading. However I suspect that some ASs wil= l still want to treat clients where the access token ends up in the browser= differently. Is that a fair assessment? I think the fix to this paragraph = would be a slight rewording to just remove the mention of public clients.= =C2=A0

Aaron


On Tue, Apr 2, 2019 at 8:53= AM George Fletcher <gffletch@aol.com> wrote:
Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential =
client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.

I'm curious as to how thi= s model is different from many existing resource server deployments acting = as confidential clients. While the application code is running in the brows= er, only the access token is exposed to the browser as is the case for many= RS deployments where the RS returns the access token to the browser after = the authorization flow completes. My interpretation of "confidential c= lient" does not include whether the client's code is "visible= " to externals or not, but rather whether the client can protect the s= ecret.

In that sense I don't believe this deployment model i= s "effectively a public client". A hybrid model description is fi= ne, and I don't disagree that some authorization servers may want to tr= eat these clients in a different way.

Thanks,
George
--
----
Aaron Parecki


_______________________________________________
OAuth mailing li= st
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000001b83705859f2b82-- From nobody Wed Apr 3 08:28:32 2019 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 390301200DB for ; Wed, 3 Apr 2019 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fNfP5r84jtBK for ; Wed, 3 Apr 2019 08:28:22 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (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 0B1C9120104 for ; Wed, 3 Apr 2019 08:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554305300; bh=QI3rv2qL3sNEZw9vvLty0V5As0kGnP+T+hTTSeQfWrk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=YGFNCogRP1u7rDhUA+MODPcORxtEuJ0m//OW9nl45t1s5N6Um8Eyy2BEhdFbKRlLxJnFC7s/NCBIVxz5BUupSgyoPTG7du8XGXFC3hFIXdgpJGIgGv0sp6lok2lIO59da1iigIEky1WVepmkDFGe6VlflBjvxTi41gyOz2UaKdJu+n9EnccMBjgPJZzrwl3SCOntIKHJ3aFBHLz8Lgy13MNFL/AaJyPX6Xg9aedg6nzBDmSio1a0ZfNC8EKXdonDV9fqSwqjOiBNtXV3xfEb223/z6BHzayondOZaQC4MwS3/x+pQl7ZoO0AfgJIifKSn4cSLnt45CbPnOsnAjwjtw== X-YMail-OSG: eGBb0zwVM1leByeKTSZWpz3.rPNWpnRp6j_RYByoUYfG9EtZUJD2p4AObsrUgbI LWFSU24daHAhtGglMpJBGlxrm0A8UQmGCCwBem3_w2t7EoHbeoIIKxSyNTNmtKgqjXenmMnGvXc_ eujG4cAHh2r8tziwVP5swGRTVFU7bFdogfqnQHjSl4FXyZL3y59tP1coxpDoDZ6AbPsvBizmn.w_ QQj_nQnNtmy4XKDxkmbYtyBhUGUn2SfgnLiqbUJDEucNk2QOXUn7BKDawwVS.uXICF2JBanLk7lf PEp1Otf8rjqp_MJn1RW9Nn_sQhyjm1psmrCCSstawonnLAU2stLAzobc6qYjAkua0agE.iwyk001 KIvxeoP8uaZT388lCTsXZZOpSzjnTE1Qk85zC8aHJJrDn11k1l0zKg05nbePvFQV6aF4.zitu0MQ BzIYgX6BlwSQ_pLNfWhGD0tAMcjbx9xvv9V5Dl2IXWg3CqYnsONc2YpuJ8UI9cgZ4aZJLCuxrRw1 iomsYfMF5na.WCCcblsDUFj1d5jSdvSWgDrbyAuujsLW_RB.DMyh0H.F6wpmPJb7KL8qZKyGxQIF _vkUhn6gzV.yQhAAFNRRc5OwAHp7KjRfa2jz4VMRT_Sv9I63NhM191Y3kFXg9mBk7CECwZRbWEC0 C9CxDPQtuboj158G9pV9u6iVsppm0IL3MZaLVH5tCELeUjVIWm0sEB6mXgW_RzmbdSiljQ2Ed5vH O_4GNGrxjVoW9vbUxHBr.eXy2i2YSMRrgd5K7ow3RUxw9QYDZVSViuomD2Cs7QAR.p1QP8M1vENr plv8wSp2ekznb0FtcozTRdaKYNFDL2yZafjx2CRB1oV8asKs8dUUs3j2kABCRwemDSfktC48CU9s yTHg9VNo2qCzUUHhysB5MGXB_BqPfBfXoj8sn_O2rCeCncPYlD65hXcE69sMR9gTIsnEosT6AB12 GziPCRPE78V3GBLriHqhLpBuClGeBAd06xwKwd0OV98evtantTBKDrgqGAkzNJbsE708497G2VRV LdVtVti_byGuSkenWpYaTg67Bd9t7bK6wAidMwYUMnJZupGkDmHZrxPBCSwc8EKgOQQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Apr 2019 15:28:20 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp407.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e324e3d5e224d2e6e9aaf17afb4073d1; Wed, 03 Apr 2019 15:28:19 +0000 (UTC) To: Daniel Fett , oauth@ietf.org References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> From: George Fletcher Organization: AOL LLC Message-ID: <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> Date: Wed, 3 Apr 2019 11:28:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> Content-Type: multipart/alternative; boundary="------------13073A55B3AD32E2E9377863" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 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, 03 Apr 2019 15:28:24 -0000 This is a multi-part message in MIME format. --------------13073A55B3AD32E2E9377863 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A quick question regarding... o "http_uri": The HTTP URI used for the request, without query and fragment parts (REQUIRED). Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :) On 3/28/19 6:17 AM, Daniel Fett wrote: > > Hi all, > > I published the first version of the DPoP draft at > https://tools.ietf.org/html/draft-fett-oauth-dpop-00 > > Abstract > > This document defines a sender-constraint mechanism for OAuth 2.0 > access tokens and refresh tokens utilizing an application-level > proof-of-possession mechanism based on public/private key pairs. > > Thanks for the feedback I received so far from John, Mike, Torsten, > and others during today's session or before! > > If you find any errors I would welcome if you open an issue in the > GitHub repository at https://github.com/webhamster/draft-dpop > > - Daniel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------13073A55B3AD32E2E9377863 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
      fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :)

On 3/28/19 6:17 AM, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop

- Daniel    


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

--------------13073A55B3AD32E2E9377863-- From nobody Wed Apr 3 08:36:37 2019 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 3AE4912008B for ; Wed, 3 Apr 2019 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7G38pzKVZJSU for ; Wed, 3 Apr 2019 08:36:33 -0700 (PDT) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 34A7712011D for ; Wed, 3 Apr 2019 08:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554305792; bh=sN+iY2JFXGEB/rHpKz1NbUppms7c2TOoaP05guwweO8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ue6FSoan2KKLE70F3cyEAGcujSLY8GHQODGmGsegQO2yUW5vG7oJMlFN3bb3y9PPV4PlTrnT/WExYUdVpNmid4XwghmmUGkgsv6yeyd3w0WAcn8B08z9vraCpSdhkW53euRgNJKl1O+1/E6qoXXEkDvBx2JTFkRk68AYeA0cVEoglw+x+KoFoXYe5uGNSBMLANj7L1MSbfDxVJn9aom/n1AbsNtuRoNMgccg9pgqtFg8wt+Ik23YmFpyPdnpJm1tZgGk7SWP3uZifr07cLVuWCpM61uPIVJC7D/d2IBodEnrAewtuPJ9G38GL4KMWLkBcQw+USu9yEnl7UPQxYHauQ== X-YMail-OSG: bRMWkJoVM1lnebeGCoNPax1bk_.GySNIouaqGkWwkWj4Czj3TpjXzfu2wCX6cOv fUBoIAbcp1Q9E447pezFvbriZwXMQNYUiRZZwajeanVVje9QVNSW2.dX3mNwl12eOa60w97V0Pyc UnsNho8Iu9sTbk7i6nJPyaT9RRnckskqS_GPUZrinFPbsqVV9U5MMIlYzMkHjjkdV0zQr2T8JIhN UZoi3hY1sS88yzzQrr_MfK44hrqUXdwSPgzQZeAAoa9bCBOLbhEKeIp4AbXmWPuvQDVSJpvBpVh8 nJLHyq4ezjydfjT84wRpfYgj_hPFDCgOR8hXNhXFEAU4mO4qDhCCXIoL91gA3KR2jFOugtJRDXj. TreINGvWaXcMME7HMjiIEod1u3xwJe5UlRAdWxBhC0lJeUs4GljsblOkMio0CKWJ0bZ_T9qVv6xU Y33a037HnJwZP.nqhHJ2cGIqkm3.xk4lHoUJZ02MKIKLsiLPJdQAjofeXTTU3XoFOMm2aXWfKusi Rre4qvOqRXkNe3tgVo4ZgxnL1rg7XEkB1OC1dg5dBoE6HMS4t3Mho_ftZW8S3KtbWTRKvtK.ID7f zWjm5MnetSjzSh1B7MotH18Y4g8c_rNgaqLYAindTr09CtaqEqnPfAOrmQYA1kyrE4AuVlG583Ya FDB9Nv4XJlcsqhSSKgKfWOf1yKIP7DO6SPGvXCChVgLdPZHfVHR8S96o3BZ6V1zqczzV7uKnUSOP q9zGsZBevnn5KSer0NQnzgBW2A3SQ7RTr_Rr6KQpmT0OtoJJmctnTWYvjws0.7vWf6AyKVzyF.z. 82XZ0ztvd.wwyHLq3PTqA87rSy6UNjPk4hoIeHGv68vQTeKgN8C1kEqe_IjoSrjpNQRN4EI8UV1X K2P_g4X3B_LzQLeFe90Dpo7jeSWw7qovoArcrNYtZ3gXnNy0T34JA7196rRAkAOCYNp_xF.ZNfNz 9dh7TXKihxHHzNU3CvXCCUyxTVi59PyWM_j8KQ7RSQIiKrBw1axbcyhu1KsFUGBOfrtvrP5SWcPQ pJ9LQFyqLAiR9B3_yT5D_X5VNAv70D_MpeZedkqthvi9NbsrTwEmfgrd0gZLLasJAR2_QGayISyi sFpYlV0GvDHU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Apr 2019 15:36:32 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a3d325a46fd5203fd5cd54e916520774; Wed, 03 Apr 2019 15:36:29 +0000 (UTC) To: Pedro Igor Silva Cc: Aaron Parecki , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <6dfbd6c7-2649-50c3-2fcb-6792a92e0239@aol.com> Date: Wed, 3 Apr 2019 11:36:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------87EEAE7A0C96C71FEA324D6B" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 03 Apr 2019 15:36:36 -0000 This is a multi-part message in MIME format. --------------87EEAE7A0C96C71FEA324D6B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit From a security perspective, I think that using a UUID (or session cookie) which allows the SPA to retrieve the access_token is effectively the same as the confidential client directly returning the AT to the browser. Basically, it's the different between whether the browser has a copy of the access_token or not. As to recommendations the AS might want to take, probably depends on a lot of factors. The factor that the browser has access to the access_token is just one of many affecting the overall risk to the Resource Server and the overall ecosystem. The risk of the browser having the access token is that there are more vectors for the token to be compromised and if the token is a bearer token then the risk is higher that the access token could be replayed by a malicious actor. So, it's possible the AS might want to limit the ability of actions associated with those access tokens based on the risk of the actions enabled within the ecosystem by the RS. I'm not sure there are definite recommendations that can be provided. On 4/3/19 8:12 AM, Pedro Igor Silva wrote: > Hi, > > I've seem some implementations where the token is not directly > delivered to the browser by the backend, but some temporary UUID that > later the SPA can exchange for an access token. > > Do you think this is a good approach to the recommendation you are > discussing? > > In addition to that, could you clarify more what would be the > limitations that ASes may wish to impose to these clients? > > Regards. > Pedro Igor > > On Tue, Apr 2, 2019 at 1:10 PM George Fletcher > > > wrote: > > I think it's fair to call it out (either in the paragraph here or > in the security considerations). The issue is that the security > aspect of the access token ending up in the browser is probably > true in many contexts other than SPAs:) > > What about something like... > > In this scenario, the backend component is likely a confidential > client which is issued it's own client secret. Note that in this > model, the access_token obtained by the backend component will be > delivered to the browser for use by the SPA so is more exposed > than in the classic confidential client model. Some Authorization > Servers may wish to limit the capabilities of these clients due to > risk considerations. > > ... or something like that. > > On 4/2/19 11:57 AM, Aaron Parecki wrote: >> Thanks, this is a good question. I was talking with someone about >> this draft the other day and had the same question myself. >> Re-reading RFC6749, "public client" does describe only the >> limitation of the client protecting its own credentials, so I >> think you're right that this paragraph is misleading. However I >> suspect that some ASs will still want to treat clients where the >> access token ends up in the browser differently. Is that a fair >> assessment? I think the fix to this paragraph would be a slight >> rewording to just remove the mention of public clients. >> >> Aaron >> >> >> On Tue, Apr 2, 2019 at 8:53 AM George Fletcher > > wrote: >> >> Hi, >> >> In section 6.2 the following statement is made... >> >> In this scenario, the backend component may be a confidential client >> which is issued its own client secret. Despite this, there are still >> some ways in which this application is effectively a public client, >> as the end result is the application's code is still running in the >> browser and visible to the user. >> >> >> I'm curious as to how this model is different from many >> existing resource server deployments acting as confidential >> clients. While the application code is running in the >> browser, only the access token is exposed to the browser as >> is the case for many RS deployments where the RS returns the >> access token to the browser after the authorization flow >> completes. My interpretation of "confidential client" does >> not include whether the client's code is "visible" to >> externals or not, but rather whether the client can protect >> the secret. >> >> In that sense I don't believe this deployment model is >> "effectively a public client". A hybrid model description is >> fine, and I don't disagree that some authorization servers >> may want to treat these clients in a different way. >> >> Thanks, >> George >> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------87EEAE7A0C96C71FEA324D6B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit From a security perspective, I think that using a UUID (or session cookie) which allows the SPA to retrieve the access_token is effectively the same as the confidential client directly returning the AT to the browser. Basically, it's the different between whether the browser has a copy of the access_token or not.

As to recommendations the AS might want to take, probably depends on a lot of factors. The factor that the browser has access to the access_token is just one of many affecting the overall risk to the Resource Server and the overall ecosystem. The risk of the browser having the access token is that there are more vectors for the token to be compromised and if the token is a bearer token then the risk is higher that the access token could be replayed by a malicious actor.

So, it's possible the AS might want to limit the ability of actions associated with those access tokens based on the risk of the actions enabled within the ecosystem by the RS.

I'm not sure there are definite recommendations that can be provided.

On 4/3/19 8:12 AM, Pedro Igor Silva wrote:
Hi,

I've seem some implementations where the token is not directly delivered to the browser by the backend, but some temporary UUID that later the SPA can exchange for an access token.

Do you think this is a good approach to the recommendation you are discussing?

In addition to that, could you clarify more what would be the limitations that ASes may wish to impose to these clients?

Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
I think it's fair to call it out (either in the paragraph here or in the security considerations). The issue is that the security aspect of the access token ending up in the browser is probably true in many contexts other than SPAs:)

What about something like...

In this scenario, the backend component is likely a confidential client which is issued it's own client secret. Note that in this model, the access_token obtained by the backend component will be delivered to the browser for use by the SPA so is more exposed than in the classic confidential client model. Some Authorization Servers may wish to limit the capabilities of these clients due to risk considerations.

... or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:
Thanks, this is a good question. I was talking with someone about this draft the other day and had the same question myself. Re-reading RFC6749, "public client" does describe only the limitation of the client protecting its own credentials, so I think you're right that this paragraph is misleading. However I suspect that some ASs will still want to treat clients where the access token ends up in the browser differently. Is that a fair assessment? I think the fix to this paragraph would be a slight rewording to just remove the mention of public clients. 

Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <gffletch@aol.com> wrote:
Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.

I'm curious as to how this model is different from many existing resource server deployments acting as confidential clients. While the application code is running in the browser, only the access token is exposed to the browser as is the case for many RS deployments where the RS returns the access token to the browser after the authorization flow completes. My interpretation of "confidential client" does not include whether the client's code is "visible" to externals or not, but rather whether the client can protect the secret.

In that sense I don't believe this deployment model is "effectively a public client". A hybrid model description is fine, and I don't disagree that some authorization servers may want to treat these clients in a different way.

Thanks,
George
--
----
Aaron Parecki


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

--------------87EEAE7A0C96C71FEA324D6B-- From nobody Wed Apr 3 08:39:54 2019 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 CC44612010F for ; Wed, 3 Apr 2019 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yes.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 ANLPIInGGfyg for ; Wed, 3 Apr 2019 08:39:50 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF80120112 for ; Wed, 3 Apr 2019 08:39:50 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id q16so7920181wmj.3 for ; Wed, 03 Apr 2019 08:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=z4dQb439ZK4+5kvv0Y0gpiS0rhs9Par+tljLV+IYapM=; b=mi0V3h/bPyopQybnDplryoAY2s27lh6B8PJKtDnbTIu28c7MzehHz8c/K2aUcxGIcr 1kaSlgkJYC7hn/rPzLdQJCgA3Bw8abUEs7v1fYvBw1X/pwMX0VzWrGy4S/d3EK+7yj4P 5th1CsEdh6mnvkfdUDoX3DuUvZnCyY10HNSnyV91ct0PIwIiqKajvw7zG00aY/sdOoVx +b7mXSe1XTX3k5C19ofXGeBYRiI4bFjSoSwIFjxMK/6faIg9yXUxPpQTidgvxMR2uJRs AMuoR+RqV+nvb1O85lauydY2dqE5R7+NJ/p19Gm6VBjLCuLT9rAEvMD53/ly8M5sVMf2 dtaQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=z4dQb439ZK4+5kvv0Y0gpiS0rhs9Par+tljLV+IYapM=; b=MmIVGUy9R9tnNenthP7xMVsr0yYiTFqAnok4ze3IId4SM8j79Fw2XtlAOgez5Nb22C XI2rKa+QtL5Nj9tTRcDF+JHX82oTRnJiWwIc2G2KXJ+2RO60O+KB9qrrc7UQO4Dzk2el EqnOY6swx6CxYlo5HNOJrryYF/ar5FWTcaLfX4OF62+TqGqJAlsSw3rmEM8V4vxP6cEQ DX18MWDqdpILEgs5Qw0DWjhT3YN8dWQaXLQcCAeQjQUk/QEW+nP2cbJ0xJMO4wOfbG+S rI2qpZQ/lXJLP5xPgUCoalOz30wFulN3W3siLgI8eGo1CyiLyHTUiiQOLyDQp/OMdou3 1TMA== X-Gm-Message-State: APjAAAUjgCeyQNB8+0+BsUjygf3Qk8PHu8th3CLz3clZOE1X5QZfvchw 9L3pORaDFYN84lJIDPwefQ8bhjCdbsE= X-Google-Smtp-Source: APXvYqzP6HGtrXAZsMxw5o8J/4pNiUm2j299k+8ev98+cri5oKuLTEQo0sUHFM2gQ6BIzxuvmcXstg== X-Received: by 2002:a1c:c8:: with SMTP id 191mr522893wma.44.1554305988655; Wed, 03 Apr 2019 08:39:48 -0700 (PDT) Received: from ?IPv6:2003:c1:4f3d:8900:8469:f3c7:4155:524a? (p200300C14F3D89008469F3C74155524A.dip0.t-ipconnect.de. [2003:c1:4f3d:8900:8469:f3c7:4155:524a]) by smtp.gmail.com with ESMTPSA id o10sm20472987wru.54.2019.04.03.08.39.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 08:39:47 -0700 (PDT) To: George Fletcher , oauth@ietf.org References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> From: Daniel Fett Message-ID: <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> Date: Wed, 3 Apr 2019 17:39:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> Content-Type: multipart/alternative; boundary="------------E01E819BEDE30B3CE1720001" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 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, 03 Apr 2019 15:39:53 -0000 This is a multi-part message in MIME format. --------------E01E819BEDE30B3CE1720001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is fixed in -01: https://tools.ietf.org/html/draft-fett-oauth-dpop-01 -Daniel Am 03.04.19 um 17:28 schrieb George Fletcher: > A quick question regarding... > > o "http_uri": The HTTP URI used for the request, without query and > fragment parts (REQUIRED). > > Is 'without' supposed to be 'with' ? The example shows the http_uri > *with* the query parameters :) > > On 3/28/19 6:17 AM, Daniel Fett wrote: >> >> Hi all, >> >> I published the first version of the DPoP draft at >> https://tools.ietf.org/html/draft-fett-oauth-dpop-00 >> >> Abstract >> >> This document defines a sender-constraint mechanism for OAuth 2.0 >> access tokens and refresh tokens utilizing an application-level >> proof-of-possession mechanism based on public/private key pairs. >> >> Thanks for the feedback I received so far from John, Mike, Torsten, >> and others during today's session or before! >> >> If you find any errors I would welcome if you open an issue in the >> GitHub repository at https://github.com/webhamster/draft-dpop >> >> - Daniel    >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------E01E819BEDE30B3CE1720001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
      fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :)

On 3/28/19 6:17 AM, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop

- Daniel    


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


--------------E01E819BEDE30B3CE1720001-- From nobody Wed Apr 3 09:01:45 2019 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 6DD1C120104 for ; Wed, 3 Apr 2019 09:01:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KIkyooofx1Ji for ; Wed, 3 Apr 2019 09:01:41 -0700 (PDT) Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 4A6D91200F7 for ; Wed, 3 Apr 2019 09:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554307297; bh=JtjKVEl9NOH4dm+GCXm1BWhPgPnTgKGXVTqN7Ue6hgw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Tp1CbdfrzFvHQDi8k7j1jTOddUhkOJ6O4wRB0wPfIQPr19HFS7ESDQgV0tBMTX8Jb+49RDPsQKnWkQgns8fLBSY1801pqEay85wzF3+efnVODPg/rUzZZz7/D5SqYWuAQSLqwUu5ldUik6OiP2LcWixpPcsZhApMYIBESH8fl1hylrBbguZ/6EO0RWYOplbJUl2KNC65u+8peu/zAxpeDCbr9LTiY3DNQNiPKT9ymcXA4Np+pQUzo+NkcQuJ863vxaKzFvhAaSxGDznTa5PhfMDub9+1BNuagW8Cr8Pn46T1ZmETX4vIGrwSYqLCZHuYWQ09LJ/ogId6vX/QYwzmxg== X-YMail-OSG: eMhI1iYVM1kp7SRgd7_joPNhUlXWcKd9hKd4Qcz9dlq.6IfWR994x17.A.c962T D9M5fiWLZ7ogDnbGdFqfu3MsYFlSz6tTQvD10DmeVTN6NY7r6eFPeaRM3DUei3nHDdJmRf6sdigX OIyHkt5Inp1e5PjBjEJ3V7RsorZ24gSEleHOsorpHleec5Qi_rTaH4YjFWC00jwFtaHOfLakw3n1 BnDq135j1l8mhqJTLeSp_pJXCgIOa1epVjW3y1TakYyBzskmk3iXvp35OIGZILXHYqa_C7bfLDpg BYdigefPsBR77t82DUs1Il1EqXa2iYI.fDfgIpO0AiIG.9CCuH0EyOfdragpVUiw85sEELsOIWWm pLqP1ZsHP0EKoZSy.UbW6xgzbUxVhX5HkUAN.64N3zjkyZDtJoMIvh3TuMKamkbLE7LsvA..F6Vk 573BK8fb.uXlQctQFp8GKmiIVjSF1ULH4fYptJOpwvUcnrhuAM528j.zata6MuAKqX.rnq04oGgX tOftu08mCe0p9mjLwUpi.bOKd3LNRTwmeHd0IWL9Hy7hA4j792n4KXx8lR8nh_pRPSMNqCrJTVWQ TyaGtG5jHuVdL3pdkqmCgodLrX4W6_atirHjBIAjRE7dumDCUOAas0lQ6sYZD_8UqZDG1mfTyR67 znmhh9C.0s.eYYNrI7D0TsdGPwlqoSYZUqxKJuYR.tSXYgXJi5jIa0E5h7qGzxfGaR6v0LBMfURC NvV2bUpV_1PKVzVWIKbJH1caVEVq7gn1mkLRthHwNVJViASJWKewgsCkWFhCiZ0tXRuV9PVplJFd a9VeAXkCY1KDxYZdfV16A4_ACEu2zxKRyrkL6DN3Lw4OfsUQus0HTUojUuHt8yh0ZVL43L6f7k99 zv43fDcQjM_mYTTvipzJj3mFKe3rLQXcI.eZ1y1Q1SUDsirKtBaGKBxpFN3RzIbHNeJ_vP5EQ5gW JCbli6U_yWNJs94YqMTbTu9bHYTWWUEbUO2jJLoVGO79owGCgGVDTpyTWUT2D7okcIK3bF1epbyf 7myPe0RQR9Sw2qDBPaiWKrgHzekiTs7dJUbd._C8XwaOZj4AGCCNdi1DhSZ6U3DPzHKZ673m8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Apr 2019 16:01:37 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9751ee5ac67215621c039d8808e3a857; Wed, 03 Apr 2019 16:01:35 +0000 (UTC) To: Daniel Fett , oauth@ietf.org References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> From: George Fletcher Organization: AOL LLC Message-ID: <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> Date: Wed, 3 Apr 2019 12:01:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> Content-Type: multipart/alternative; boundary="------------ED3268A93F0B083521760516" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 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, 03 Apr 2019 16:01:43 -0000 This is a multi-part message in MIME format. --------------ED3268A93F0B083521760516 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Perfect! Thank you! A couple comments on version 01... POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded;charset=UTF-8 DPoP-Binding: eyJhbGciOiJSU0ExXzUi ... grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb (remainder of JWK omitted for brevity) I believe the "(remainder of JWK..." should be moved to the DPoP-Binding header... Also, there is no discussion of the DPoP-Binding header outside of the token request, but I suspect that is the desired way to communicate the DPoP-Proof to the RS. Possibly an example in the session for presenting the token to the RS would help. Thanks, George On 4/3/19 11:39 AM, Daniel Fett wrote: > This is fixed in -01: > > https://tools.ietf.org/html/draft-fett-oauth-dpop-01 > > -Daniel > > Am 03.04.19 um 17:28 schrieb George Fletcher: >> A quick question regarding... >> >> o "http_uri": The HTTP URI used for the request, without query and >> fragment parts (REQUIRED). >> >> Is 'without' supposed to be 'with' ? The example shows the http_uri >> *with* the query parameters :) >> >> On 3/28/19 6:17 AM, Daniel Fett wrote: >>> >>> Hi all, >>> >>> I published the first version of the DPoP draft at >>> https://tools.ietf.org/html/draft-fett-oauth-dpop-00 >>> >>> Abstract >>> >>> This document defines a sender-constraint mechanism for OAuth 2.0 >>> access tokens and refresh tokens utilizing an application-level >>> proof-of-possession mechanism based on public/private key pairs. >>> >>> Thanks for the feedback I received so far from John, Mike, Torsten, >>> and others during today's session or before! >>> >>> If you find any errors I would welcome if you open an issue in the >>> GitHub repository at https://github.com/webhamster/draft-dpop >>> >>> - Daniel >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > --------------ED3268A93F0B083521760516 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Perfect! Thank you! A couple comments on version 01...

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   &code=SplxlOBeZQQYbYS6WxSbIA
   &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)

I believe the "(remainder of JWK..." should be moved to the DPoP-Binding header...

Also, there is no discussion of the DPoP-Binding header outside of the token request, but I suspect that is the desired way to communicate the DPoP-Proof to the RS.

Possibly an example in the session for presenting the token to the RS would help.

Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:
This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:
A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
      fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :)

On 3/28/19 6:17 AM, Daniel Fett wrote:

Hi all,

I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop

- Daniel    


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



--------------ED3268A93F0B083521760516-- From nobody Wed Apr 3 10:24:24 2019 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 1296A120140 for ; Wed, 3 Apr 2019 10:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 bvCRaQjTFo_1 for ; Wed, 3 Apr 2019 10:24:20 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0: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 4DD8612013B for ; Wed, 3 Apr 2019 10:24:20 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id z126so12330061itd.5 for ; Wed, 03 Apr 2019 10:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xIfXPS3Ll6jnahnFu0WfDXGaK0DrwnnGQm5H5E/QBsw=; b=gyahhJtfsd+n+oDCTsxIeIdMiuVqx3KWlrT/aUX7SmXwrgFgqbXQX/nwKRpK+rAAfG ST/3pcVPnriqAQtXa6xf8iKzSJ8ycJLT+ay7QuPCwny73uakj3O557IoM/dceq6pVkf0 0NgbwZPHZcORpT8Rm2MLV0CaHSkq7MnlxSfWs= 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=xIfXPS3Ll6jnahnFu0WfDXGaK0DrwnnGQm5H5E/QBsw=; b=CIxWGLtTTtJxVvQ0HrDKF90BXO/icMlYoiVVGPsLo+vZPkZyDFvO3jF43MpK7qYU78 97aadQlfT0muTeCr3CiiKJETMBslE3oFciaTQhjKEuLHXwk2tyaBZ3EHbSIbW8k62wqG Zuk+oWqdu6VO3h0LdHmQ7YJAF1q7m6oBMDC2s24/LhSQJKhV8SYo6JZsfGYiQkbD3+Lb rhznQj2VmTrTZEP16InZ7u+VEhNqG874vIOyNKTwdxP2UD3FahLQQFpAU5rcxGmTnH2b jRgXTfRdmAJVyQ15YJ5oqvrivAheXxGSMXiOcjfZ2CyZSqeoaz3fCnJf0tEorUryea3t xs6Q== X-Gm-Message-State: APjAAAUK6Kn5bunyMddwSx8LzzhsAq6w8VAFZIEMBRaFvPXXsdhbg0fc XoFDjZRp18tWPaQBv8Az4ka/B9BJtabzatdpibQ7l6d/J4IgbZVfZn6V55UKQMF0Nb7GcYVxGx8 8K5F9jJG3aOtk5Q== X-Google-Smtp-Source: APXvYqzPtpzQT9/1b0DVxGlz2ighECHCR+LFy0irW+Hl6Fv9JUmAHruPh1pygmMaVD+mACjx7RmqutSbbsj1AM+M8G4= X-Received: by 2002:a05:660c:685:: with SMTP id n5mr1027491itk.57.1554312259359; Wed, 03 Apr 2019 10:24:19 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Brian Campbell Date: Wed, 3 Apr 2019 11:23:52 -0600 Message-ID: To: David Waite Cc: George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000016f0630585a3863b" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 03 Apr 2019 17:24:23 -0000 --00000000000016f0630585a3863b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to David's question here. I'd like to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use in an access token will lead to misuse and/or confusion. On Mon, Apr 1, 2019 at 1:03 PM David Waite wrote: > Do we know if there is a justifying use case for auth_time, acr, and amr > to be available in OAuth JWT access tokens? These are meant to be message= s > about the client, either directly (in the case of client credentials) or > about its delegated authorization of the user. > > Embedding attributes about the user (such as group membership and roles) > can be used for the resource to make finer-grained decisions than scopes, > but normally I would expect say acr limitations enforced by a resource to > instead be controlled by the AS requiring a higher quality authentication > to release certain scopes. > > Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99t= provide > these values, just that they might better be defined by those extensions. > > -DW > > On Apr 1, 2019, at 9:12 AM, George Fletcher < > gffletch=3D40aol.com@dmarc.ietf.org> wrote: > > Thanks for writing this up. One comment on auth_time... > > auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. > Important: as this claim represents the time at which the end user > authenticated, its value will remain the same for all the JWT > access tokens issued within that session. For example: all the > JWT access tokens obtained with a given refresh token will all > have the same value of auth_time, corresponding to the instant in > which the user first authenticated to obtain the refresh token. > > > During a current session a user can be challenged for additional > credentials or required to re-authenticate due to a number of different > reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this conte= xt, > I'd assume that the auth_time value should be updated to the latest time = at > which the user authenticated. > > If we need a timestamp for when the "session" started, then there could b= e > a session_start_time claim. > > Thanks, > George > > On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a= _jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > V. > > _______________________________________________ > 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 > > > _______________________________________________ > 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._ --00000000000016f0630585a3863b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to David's question here. I'd = like to see justifying use cases (beyond just the fact that some people are= already doing it) for auth_time, acr, and amr to be available in OAuth JWT= access tokens. Those claims are defined for, and in the context of, an ID = Token and I fear that codifying their use in an access token will lead to m= isuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Wait= e <david@alkaline-soluti= ons.com> wrote:
Do we know if there is a j= ustifying use case for auth_time, acr, and amr to be available in OAuth JWT= access tokens? These are meant to be messages about the client, either dir= ectly (in the case of client credentials) or about its delegated authorizat= ion of the user.

Embedding attributes about th= e user (such as group membership and roles) can be used for the resource to= make finer-grained decisions than scopes, but normally I would expect say = acr limitations enforced by a resource to instead be controlled by the AS r= equiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such as OI= DC can=E2=80=99t provide these values, just that they might better be defin= ed by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, George Fletcher <gfflet= ch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20 =20
Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONA=
L - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume= that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then= there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:= 29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,= =C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

<= /fieldset> 
_____________=
__________________________________
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. --00000000000016f0630585a3863b-- From nobody Wed Apr 3 12:38:49 2019 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 7663D120179 for ; Wed, 3 Apr 2019 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 e_vKgAOE3hLV for ; Wed, 3 Apr 2019 12:38:44 -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 81591120178 for ; Wed, 3 Apr 2019 12:38:43 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id a28so12577416lfo.7 for ; Wed, 03 Apr 2019 12:38:43 -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=rq+8ThzKF71UKUQs89DxPdXQq8IaKNKx7e8NIxcC7KM=; b=CrIUheSt4vl41U+1ss8pj3ucUdjBAqSd903zmJNwIFyU63b3elnVZCvcFb/B1tQugZ Is/tMJybW9hMXO8FXGxsZNkhK4e5Cz9mG8qvQi6hJu53qow3vZXtzPnkJ2/lX47zzUDF JEtkfFlyz8Jp6uYzWY82pLvFp7EOg6yRaxJalQEA9K7wceHUX7tc/e+OfEqocfQo4brL 4/cJ9FRzs8Bs0HPQHBp4z0eT3q9OvxY2N6mfdwCNvDAr2DVt+b4lgbLVnLX63k3g8hNe 8KAF4yYj9bHrgKsX1ZaeYwOBg7XpvzCd71kv3SjulpVA4B7gvN7Cn57BTZXzVjbxBv/u DYew== 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=rq+8ThzKF71UKUQs89DxPdXQq8IaKNKx7e8NIxcC7KM=; b=IgprS7tKL5C/6q5OCyGqbTiUDQ+iPZ2fd9Ql5+lebKfrtHrA/v+3ZXJP0WSdlesLO/ HnFpWzLyGvAFz8FCsVq4hZ1ufSGv+pxgUymSEANps7QTd1JzDEKDpw9XrpDyrUvWg35S 3Z/Ri00373Qa7cVEbX+sPsrVyOY28mbao5xTy1fQUBlRLcEORRLlAEp2yAsrGFtklYOf mABu97x9cMieOHtjZuZ6Yj9hbczBN2KYVBWUzpgBskl09zvG5JFnwSWVQM30qyN1dwVh Rk+bEX/foW7yr0j3CE/Pr7XUFCIIheGkZyuabsgHMY4A04lgc9R7nQWl+/VJzPv/GXWF 8aug== X-Gm-Message-State: APjAAAUn5bgIDXPAFOCO4GPRndZ8wYk9xqtbZqp6cwNJgakTpM1YiXZ2 ebqltfv0sZqjzOoUoE7UFwqyJoYB9SAcQ/pLGEFY1uFqyKw= X-Google-Smtp-Source: APXvYqzVUFI8PSwYB4q43auns2cI5QncMA5Wrq0lGieQS2rOG1t1b5+baXfMqOt9FQdG2rAXs2QVizWNotH3B6wDOHM= X-Received: by 2002:a19:ef19:: with SMTP id n25mr842981lfh.0.1554320321461; Wed, 03 Apr 2019 12:38:41 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Vittorio Bertocci Date: Wed, 3 Apr 2019 12:38:30 -0700 Message-ID: To: Brian Campbell Cc: David Waite , George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a0ec840585a5666f" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 03 Apr 2019 19:38:48 -0000 --000000000000a0ec840585a5666f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks guys for the comment, sorry for the delay in addressing them. I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south. However I think it's important that the information on say, whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API). Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers. In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access). I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW. But I am completely open to change it of course, especially for cases like the one identified by George. WDYT? On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell wrote: > +1 to David's question here. I'd like to see justifying use cases (beyond > just the fact that some people are already doing it) for auth_time, acr, > and amr to be available in OAuth JWT access tokens. Those claims are > defined for, and in the context of, an ID Token and I fear that codifying > their use in an access token will lead to misuse and/or confusion. > > On Mon, Apr 1, 2019 at 1:03 PM David Waite > wrote: > >> Do we know if there is a justifying use case for auth_time, acr, and amr >> to be available in OAuth JWT access tokens? These are meant to be messag= es >> about the client, either directly (in the case of client credentials) or >> about its delegated authorization of the user. >> >> Embedding attributes about the user (such as group membership and roles) >> can be used for the resource to make finer-grained decisions than scopes= , >> but normally I would expect say acr limitations enforced by a resource t= o >> instead be controlled by the AS requiring a higher quality authenticatio= n >> to release certain scopes. >> >> Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99= t provide >> these values, just that they might better be defined by those extensions= . >> >> -DW >> >> On Apr 1, 2019, at 9:12 AM, George Fletcher < >> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >> >> Thanks for writing this up. One comment on auth_time... >> >> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >> Important: as this claim represents the time at which the end user >> authenticated, its value will remain the same for all the JWT >> access tokens issued within that session. For example: all the >> JWT access tokens obtained with a given refresh token will all >> have the same value of auth_time, corresponding to the instant in >> which the user first authenticated to obtain the refresh token. >> >> >> During a current session a user can be challenged for additional >> credentials or required to re-authenticate due to a number of different >> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this cont= ext, >> I'd assume that the auth_time value should be updated to the latest time= at >> which the user authenticated. >> >> If we need a timestamp for when the "session" started, then there could >> be a session_start_time claim. >> >> Thanks, >> George >> >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >> >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions!). >> >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> V. >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > --000000000000a0ec840585a5666f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks guys for the comment, sorry for the delay in addres= sing them.
I am not married to the claim types used in here, so if you = think that reusing the ones in the id_token can cause confusion we should e= xpand on the specific ways in which you think might go south.
How= ever I think it's important that the information on say, whether the cu= rrent token was obtained using MFA or a specific authentication factor is s= omething that API developers can legitimately latch to when doing authoriza= tion decisions. From the perspective of a developer modeling a solution, wh= ether functionality is delivered as a route in a postback based web app (he= nce receiving an id_token or derived) or as an API consumed by a native app= , the business requirement gating access to that functionality doesn't = change. If the admin managing that resource establishes that access should = be performed only via MFA, the developer should be equipped to enforce that= regardless of the stack used to expose functionality (web app, API).=C2=A0=
Although it is true that triggering the desired behavior might b= e achieved by the resource setting and contract with the AS, along the line= s of what David said, it's actually not uncommon for those policies to = be assigned on the resource AFTER the current session was established and/o= r the corresponding AT was obtained and cached. Furthermore, the requiremen= t might be more granular than an AS policy can tolerate (an API might requi= res MFA only for certain routes, hence hard to express in a static policy) = and triggered in form of challenges. So the situation in which you have an = AT with the right issuer, audience, etc but was obtained with a policy now = obsolete/unacceptable to the RP is strong. Requesting to support revocation= just for this seems overkill, especially given that the scenario in which = the same logical app is exposed as both web app and native client+API, the = code consuming those claims is already in place. It just makes intuitive se= nse for developers.=C2=A0 =C2=A0
In summary, one can take steps t= o push as much of the MFA requirements to the AS settings for a particular = request, but ultimately the desire of the API developer to enforce that it = actually happened=C2=A0is a requirement I encountered often in practice. An= ything providing extra context to refine decisions about it (like auth_time= , which might inform decisions about whether to accept an MFA check occurre= d N minutes ago or refuse access).

I thought that = reusing the existing names for the same concepts just made sense (dev exist= ing skills, existing codebases, etc etc) and especially in the case in whic= h the values are exactly the same, and the idea seemed to receive good supp= ort during OSW. But I am completely open to change it of course, especially= for cases like the one identified by George.
WDYT?
On Wed, = Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:
+1 to David's question here. I'd like to = see justifying use cases (beyond just the fact that some people are already= doing it) for auth_time, acr, and amr to be available in OAuth JWT access = tokens. Those claims are defined for, and in the context of, an ID Token an= d I fear that codifying their use in an access token will lead to misuse an= d/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkal= ine-solutions.com> wrote:
Do we know if there is a justifying use case for auth= _time, acr, and amr to be available in OAuth JWT access tokens? These are m= eant to be messages about the client, either directly (in the case of clien= t credentials) or about its delegated authorization of the user.

Embedding attributes about the user (such as group membe= rship and roles) can be used for the resource to make finer-grained decisio= ns than scopes, but normally I would expect say acr limitations enforced by= a resource to instead be controlled by the AS requiring a higher quality a= uthentication to release certain scopes.

Thats of = course not to say extensions to OAuth such as OIDC can=E2=80=99t provide th= ese values, just that they might better be defined by those extensions.

-DW

On A= pr 1, 2019, at 9:12 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.o= rg> wrote:

=20 =20 =20
Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined in section 2 of [OpenI=
D.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume= that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then= there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,= =C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

_______________________________________________
OAuth mailing list
OAuth@iet=
f.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 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
--000000000000a0ec840585a5666f-- From nobody Wed Apr 3 13:48:51 2019 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 CC5AC120256 for ; Wed, 3 Apr 2019 13:48:49 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ioql8f4KFkNT for ; Wed, 3 Apr 2019 13:48:45 -0700 (PDT) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 6A921120158 for ; Wed, 3 Apr 2019 13:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554324523; bh=UwsVwuMA8q7HfeQHdrRWUduhNVdCIB9D6l8N/x+trSQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=j6FU04dVZF26ZN0TtFIvzYfcjN6acf6gavwLw/2LdfNw0OED1fjN/1622hvxSO8pLgDBQ0XiCC6ZJdWG4lFm1BSdgtfbRp2DXO+BK2St5KH1IRJuMQ/+52NlH03EKiSpiBK3Nq8YqjSSN+Y37Zw+DiGxIiWLk62GVmc9fDx2n7jxOUX5NhVoPF7UXSxi8ZNY/0nFpDFswytVR2Tq7mzdF6KoCEVZJvF26CJa+aP/tImyRos9buaHsUPLANa1xnjGMTpI1GPZeYIqmFBGx7Hx7PPm/fZkoR2OCHfw9E5BvS56fGsQvEj2cxyogg975B4G+D1Tc8R4d0uen0Lii7+xIg== X-YMail-OSG: O_CTEwMVM1nhLPC8KuMvMASxy3hAPAeQJNRa6IWjzPTswzpENogDgsKXLIPumaU f00Ha0SAF0j2FL2EtRF0XDO3xGi3uBTHcWcuWW.OmzhlUX9JJkANWbX3xr37JRpaXFyCob10cJdb iwuKp6V2SAhnx78OrlU1pw4wGVNxBQ_Ob2u4rpV7UoJe6wfeVWcvMLaH4MopgUxVq473Hf6TknD8 BxcZfQgrOdQNBlx0LiIHyPldXumJMawT.UxOiCcda1kWwOc6DRE799IMIfIEibruPCi0MnfRq_3f GuBAk13iIyVOIECs2.I5UbaYi7SV3xwbeXVjQoc3PQAVtKbF7CEas4rw1um4BAP6MSMKAhGdQLT3 dsKFmHJqV1GeW0wdXVMaqW5jNUmzifstdV3sj535DeoSdMjG4VxORqeoTh9t0L2xIZHLOn_sYMJx zEg1ET7q8qsgSAPoYI_2konDOoXY.l3PMx12fP1i.h6GH_wj9vD8U9.2bnZMAGi84c5Jg24gW5Pw LwQ80e537urUo_lnS0ZfhENjVvqX4YhjIoE.jUTgsVzYPSQnuiWQPCMdIok6Y6aKxO4QvtIZX2j9 qzhpEQx0p6T..A8N8.imXh0RaWtQXALNh16xfX8ZnRxTgIWwPhjqz7F1DA9PJTy8iYLPluRtzixx LaSvKIcY_jZc.zDa3ELQKlupxa5m5k6cD4r4kQKBOPAFvVgRd3rQMZhUkhrEiwuL0drw.IuhLcqw Jxs2VfB53VeCnMTZ1PsQBICUOKKebXIXwLsneREQNSHZYGHjXvWbDJZ4DyX9NYbU.vJriqcWlNSR aA5_dY90ekoa6C7Ehy9OyDXwJ.2.v.HehVEET2a7D6qN02LNGuMqntsHo64KbPQ389VpzJ.kASe2 BC17lCed286DLIi85Mk5_8KQ3mU44spiRb.P92R5ZnKxuFEzhAMr6ZDYixy7BbysoN90D2HZuxOb .KD_73V3Q6POSueNP8fIN7KezqFv3TthpO.8BcNCiggbd4EkP4BjOyZ3qGO5ara4jCtFnXl5ozal O4nHyWC924p5qxsQycXDWcOhQL.rmV2XEZKyQwuhHSRGbpo1sv0X8LA5ub9L86f8.cb.ypB9UuA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 3 Apr 2019 20:48:43 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d02b6ee8df68cd41fc185a7532de8bd7; Wed, 03 Apr 2019 20:48:42 +0000 (UTC) To: Hans Zandbelt , Vittorio Bertocci Cc: IETF oauth WG References: From: George Fletcher Organization: AOL LLC Message-ID: Date: Wed, 3 Apr 2019 16:48:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------00269959D36A2B2110045E16" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 03 Apr 2019 20:48:50 -0000 This is a multi-part message in MIME format. --------------00269959D36A2B2110045E16 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :) On 3/26/19 12:56 PM, Hans Zandbelt wrote: > great summary! this will hurt quite a few existing m2m deployments but > I do like the rigidness of it all: it is very explicit, cannot > misinterpreted and thus prevents failure (which is really what > Dominick is after); I'm on board > > Hans. > > On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci > > wrote: > > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, > Nov, Bertrand recommend using sub only for users. Martin would > like to have the sub for app only flows as well. Hans is neutral. > That does sound like the sub as user has more consensus, tho > before changing it I'd wait for the people currently at IETF104 to > have more time to comment as well. > Clarification. If the goal is to be able to apply the logic "if > there's a sub, it's a user flow", we have to explicitly disallow > (MUST NOT) the use of sub when that's not the case. Are all OK > with it? > > Dave, the suggestion of having explicit typing for app only vs > user only is interesting! For the purpose of putting together an > interoperable profile, tho, I would suggest we table it for v1 in > the interest of getting to something easy to adopt (hence with > small delta vs existing implementations) faster. > > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem > wrote: > > Hi Vittorio, we (the national federation-gateway for the > health services in norway - "HelseID")  think his is a really > valuable initiative! > We also agree with Dominick concerning definition of the "sub" > claim. > > Steinar > > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier > >: > > From an access token consumer (aka API) developer point of > view, I prefer this logic > > "If sub is present - client acts on behalf of a user, if > not - not." > > Anything more complicated has a potential of going wrong. > > > On 26. March 2019 at 01:34:53, Nov Matake > (matake@gmail.com ) wrote: > >> Hi Vittorio, >> >> Yeah, I’m concerning user & client ids collision. >> I haven’t seen such implementations, but user-select >> username as sub, or incremental integer as sub & >> client_id will be easily collide. >> >> If you can enforce collision resistant IDs between user & >> client instances, it’ll works fine. I feel its overkill >> though. >> >> Sent from my iPhone >> >> On Mar 26, 2019, at 8:51, Vittorio Bertocci >> > wrote: >> >>> Hey Nov, Dominick, Hans- >>> thanks for the comments. That was an area I was >>> expecting to cause more discussion, and I am glad we are >>> having this opportunity to clarify. >>> The current language in the draft traces the etymology >>> of sub to OpenID Connect core, hence Dominick >>> observation is on point. However in the description I >>> express something in line with 7519, which was in fact >>> my intent. >>> >>> The idea was to provide an identifier of the calling >>> subject that is guaranteed to be present in all cases- >>> this would allow an SDK developer to use the same code >>> for things like lookups and membership checks regardless >>> of the nature of the caller (user in a delegated case, >>> app in app-only grants). The information to discriminate >>> between user and app callers is always available in the >>> token (say, the caller is a user if sub!=client_id, >>> where client_id is always guaranteed to be present as >>> well) hence there's no loss in expressive power, should >>> that difference be relevant for the resource server. >>> >>> Dominick, Hans- I probably missed the security issue you >>> guys are thinking of in this case. Of course, if this >>> would introduce a risk I completely agree it should be >>> changed- I'd just like to understand better the problem. >>> Could you expand it in a scenario/use case to clarify >>> the risk? >>> Nov- playing this back: is the concern that a user and a >>> client might have the same identifier within an IDP? >>> When using collision resistant IDs, as it is usually the >>> case, that seems to be a remote possibility- did you >>> stumble in such scenario in production? >>> >>> Thanks >>> V. >>> >>> >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt >>> >> > wrote: >>> >>> I believe there are plenty of OAuth 2.0 only use >>> cases out there... but nevertheless I agree with the >>> potential confusion and thus security problems >>> arising from that (though one may argue the >>> semantics are the same). >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier >>> >> > wrote: >>> >>> Yes I know - and I think in hindsight it was a >>> mistake to use the same claim type for multiple >>> semantics. >>> >>> All the “this is OIDC not OAuth” arguments are >>> making things more complicated than they need to >>> be - in my experience almost no-one (that I >>> know) does OIDC only - nor OAuth only. They >>> always combine it. >>> >>> In reality this leads to potential security >>> problems - this spec has the potential to >>> rectify the situation. >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt >>> (hans.zandbelt@zmartzone.eu >>> ) wrote: >>> >>>> Without agreeing or disagreeing: OIDC does not >>>> apply here since it is not OAuth and an access >>>> token is not an id_token. >>>> The JWT spec says in >>>> https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>> >>>> "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" >>>> >>>> which kind of spells "client" in case of the >>>> client credentials grant but I also do worry >>>> about Resource Servers thinking/acting only in >>>> terms of users >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier >>>> >>> > wrote: >>>> >>>> IMHO the sub claim should always refer to >>>> the user - and nothing else. >>>> >>>> OIDC says: >>>> >>>> "Subject - Identifier for the End-User at >>>> the Issuer." >>>> >>>> client_id should be used to identify clients. >>>> >>>> cheers >>>> Dominick >>>> >>>> On 25.. March 2019 at 05:13:03, Nov Matake >>>> (matake@gmail.com >>>> ) wrote: >>>> >>>>> Hi Vittorio, >>>>> >>>>> Thanks for the good starting point of >>>>> standardizing JWT-ized AT. >>>>> >>>>> One feedback. >>>>> The “sub” claim can include 2 types of >>>>> identifier, end-user and client, in this spec. >>>>> It requires those 2 types of identifiers >>>>> to be unique each other in the IdP context. >>>>> >>>>> I prefer omitting “sub” claim in 2-legged >>>>> context, so that no such constraint needed. >>>>> >>>>> thanks >>>>> >>>>> nov >>>>> >>>>>> On Mar 25, 2019, at 8:29, Vittorio >>>>>> Bertocci >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Dear all, >>>>>> I just submitted a draft describing a JWT >>>>>> profile for OAuth 2.0 access tokens. You >>>>>> can find it in >>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>>>> I have a slot to discuss this tomorrow at >>>>>> IETF 104 (I'll be presenting remotely). I >>>>>> look forward for your comments! >>>>>> >>>>>> Here's just a bit of backstory, in case >>>>>> you are interested in how this doc came >>>>>> to be. The trajectory it followed is >>>>>> somewhat unusual. >>>>>> >>>>>> * Despite OAuth2 not requiring any >>>>>> specific format for ATs, through the >>>>>> years I have come across multiple >>>>>> proprietary solution using JWT for >>>>>> their access token. The intent and >>>>>> scenarios addressed by those >>>>>> solutions are mostly the same across >>>>>> vendors, but the syntax and >>>>>> interpretations in the >>>>>> implementations are different enough >>>>>> to prevent developers from reusing >>>>>> code and skills when moving from >>>>>> product to product. >>>>>> * I asked several individuals from key >>>>>> products and services to share with >>>>>> me concrete examples of their JWT >>>>>> access tokens (THANK YOU Dominick >>>>>> Baier (IdentityServer), Brian >>>>>> Campbell (PingIdentity), Daniel >>>>>> Dobalian (Microsoft), Karl Guinness >>>>>> (Okta) for the tokens and explanations!). >>>>>> I studied and compared all those >>>>>> instances, identifying commonalities >>>>>> and differences. >>>>>> * I put together a presentation >>>>>> summarizing my findings and >>>>>> suggesting a rough interoperable >>>>>> profile (slides: >>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>>>>> >>>>>> ) - got early feedback from Filip >>>>>> Skokan on it. Thx Filip! >>>>>> * The presentation was followed up by >>>>>> 1.5 hours of unconference discussion, >>>>>> which was incredibly valuable to get >>>>>> tight-loop feedback and incorporate >>>>>> new ideas. John Bradley, Brian >>>>>> Campbell Vladimir Dzhuvinov, Torsten >>>>>> Lodderstedt, Nat Sakimura, Hannes >>>>>> Tschofenig were all there and >>>>>> contributed generously to the >>>>>> discussion. Thank you!!! >>>>>> Note: if you were at OSW2019, >>>>>> participated in the discussion and >>>>>> didn't get credited in the draft, my >>>>>> apologies: please send me a note and >>>>>> I'll make things right at the next >>>>>> update. >>>>>> * On my flight back I did my best to >>>>>> incorporate all the ideas and >>>>>> feedback in a draft, which will be >>>>>> discussed at IETF104 tomorrow. >>>>>> Rifaat, Hannes and above all Brian >>>>>> were all super helpful in negotiating >>>>>> the mysterious syntax of the RFC >>>>>> format and submission process. >>>>>> >>>>>> I was blown away by the availability, >>>>>> involvement and willingness to invest >>>>>> time to get things right that everyone >>>>>> demonstrated in the process. This is an >>>>>> amazing community. >>>>>> V. >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> >>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> >>> ZmartZone IAM - www.zmartzone.eu >>> >>> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > | steinar@udelt.no  | hei@udelt.no >   | +47 955 21 620 | www.udelt.no >  | > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------00269959D36A2B2110045E16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.
Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.     

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

<mvh>Steinar</mvh>

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
From an access token consumer (aka API) developer point of view, I prefer this logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

Thanks
V. 


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

Hans.

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
"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"

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

thanks

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.
_______________________________________________
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


--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
_______________________________________________
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

--------------00269959D36A2B2110045E16-- From nobody Wed Apr 3 13:57:10 2019 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 762D712026D for ; Wed, 3 Apr 2019 13:57:08 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zmartzone-eu.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 1sTD3sBJfu8c for ; Wed, 3 Apr 2019 13:57:03 -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 AB3BF12026C for ; Wed, 3 Apr 2019 13:57:02 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id n68so330311qka.1 for ; Wed, 03 Apr 2019 13:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fuOdKiYvZGlwJoXhq4pJT1DnZq3xsP/sIms87V4TDH4=; b=D6fZywNm0/+LUereTEiJQNqUSfIRrg/3+BTPW8b06OGTd9qdsvyFzmK0G5e/qmLgCn VM78+6iNBhh9x3krKeLYMLuwWeRzAxASLMBAdPxg453I3F9a+YXu0ToA6Ud04WN8DCxz g0xiTN6HodjVZw22yptwdWM0arRiIxaZwjeD6fyknLEDYhfeykecK9tmjn7L5YHvum4X ncWTGzxfYM2b/kwOxoP2yffp01i5jEs8hi4U3wjPwB7M62wT1VH4K89WIneNw6ZewRyZ bFXWWQvpDwTZMCwxtI0hIOwJ+8HWg+yO2Nlgc3bWLL5snkem750fSJ2JxCfzm066xP4w V95g== 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=fuOdKiYvZGlwJoXhq4pJT1DnZq3xsP/sIms87V4TDH4=; b=qKMPTGPORQOBjXJy3hd9yVKOhvNsh4DblVCv4Lz8VF+KTBGSwNGyz2jPmogRGUoGhz j729L/bMYEPPYSXjUb7O/kFgbVi743/osMFx6+clfeP9K7rrGCbjTU4G9fnfxQkIQzIn GBhdeb9rOv/fAO/qkZyyEgvVN39R0y7AIgtawXcGoXsPn94osNijHlkzl4YtNns4o75Z r40pfZ6JNtuDiJOK0CfvdDd8x5cB7j53xBViSmk82S1YC7gRKwGVbQsiv8RwY54ULy9h 1Mr4fRjFPs6pCAfJOZYH3s/S3OotwbF+dchCBd2UysQ5X0AO5iKjn6r1di0tH8V8B4BY 40NA== X-Gm-Message-State: APjAAAXu8mv2lpnqkLP5J3LST7G6lMP+rFTJ8f/kSQ5aF0nNabfo4udf EgULfJdEFn9rvNfA+A5zKIc54sY8Lf77mnhZs/iN7HGA X-Google-Smtp-Source: APXvYqxuVBIr6CP46JMgcGZaWlFVLeY3WFtzU4/DZZMAMlLsq2c3boQE5kyGIUruSz4vMiB5Kbspe1CABYhF1OlkDPo= X-Received: by 2002:ae9:ebcf:: with SMTP id b198mr1878799qkg.129.1554325021369; Wed, 03 Apr 2019 13:57:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Wed, 3 Apr 2019 22:56:49 +0200 Message-ID: To: George Fletcher Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000c3b8fd0585a67e1e" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 03 Apr 2019 20:57:09 -0000 --000000000000c3b8fd0585a67e1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that= . Hans. On Wed, Apr 3, 2019 at 10:48 PM George Fletcher wrote: > I agree that this will break a lot of existing flows... especially those > using any form of the client_credentials flow. In that sense I'm not > completely on board yet :) > > On 3/26/19 12:56 PM, Hans Zandbelt wrote: > > great summary! this will hurt quite a few existing m2m deployments but I > do like the rigidness of it all: it is very explicit, cannot misinterpret= ed > and thus prevents failure (which is really what Dominick is after); I'm o= n > board > > Hans. > > On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> thank you Steinar and everyone else for the comments on this! >> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >> Bertrand recommend using sub only for users. Martin would like to have t= he >> sub for app only flows as well. Hans is neutral. >> That does sound like the sub as user has more consensus, tho before >> changing it I'd wait for the people currently at IETF104 to have more ti= me >> to comment as well. >> Clarification. If the goal is to be able to apply the logic "if there's = a >> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the us= e >> of sub when that's not the case. Are all OK with it? >> >> Dave, the suggestion of having explicit typing for app only vs user only >> is interesting! For the purpose of putting together an interoperable >> profile, tho, I would suggest we table it for v1 in the interest of gett= ing >> to something easy to adopt (hence with small delta vs existing >> implementations) faster. >> >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: >> >>> Hi Vittorio, we (the national federation-gateway for the health >>> services in norway - "HelseID") think his is a really valuable initiat= ive! >>> We also agree with Dominick concerning definition of the "sub" claim. >>> >>> Steinar >>> >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >>> dbaier@leastprivilege.com>: >>> >>>> From an access token consumer (aka API) developer point of view, I >>>> prefer this logic >>>> >>>> "If sub is present - client acts on behalf of a user, if not - not." >>>> >>>> Anything more complicated has a potential of going wrong. >>>> >>>> >>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>> I haven=E2=80=99t seen such implementations, but user-select username = as sub, >>>> or incremental integer as sub & client_id will be easily collide. >>>> >>>> If you can enforce collision resistant IDs between user & client >>>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>>> >>>> Sent from my iPhone >>>> >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote= : >>>> >>>> Hey Nov, Dominick, Hans- >>>> thanks for the comments. That was an area I was expecting to cause mor= e >>>> discussion, and I am glad we are having this opportunity to clarify. >>>> The current language in the draft traces the etymology of sub to OpenI= D >>>> Connect core, hence Dominick observation is on point. However in the >>>> description I express something in line with 7519, which was in fact m= y >>>> intent. >>>> >>>> The idea was to provide an identifier of the calling subject that is >>>> guaranteed to be present in all cases- this would allow an SDK develop= er to >>>> use the same code for things like lookups and membership checks regard= less >>>> of the nature of the caller (user in a delegated case, app in app-only >>>> grants). The information to discriminate between user and app callers = is >>>> always available in the token (say, the caller is a user if sub!=3Dcli= ent_id, >>>> where client_id is always guaranteed to be present as well) hence ther= e's >>>> no loss in expressive power, should that difference be relevant for th= e >>>> resource server. >>>> >>>> Dominick, Hans- I probably missed the security issue you guys are >>>> thinking of in this case. Of course, if this would introduce a risk I >>>> completely agree it should be changed- I'd just like to understand bet= ter >>>> the problem. Could you expand it in a scenario/use case to clarify the= risk? >>>> Nov- playing this back: is the concern that a user and a client might >>>> have the same identifier within an IDP? When using collision resistant= IDs, >>>> as it is usually the case, that seems to be a remote possibility- did = you >>>> stumble in such scenario in production? >>>> >>>> Thanks >>>> V. >>>> >>>> >>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>>> hans.zandbelt@zmartzone.eu> wrote: >>>> >>>>> I believe there are plenty of OAuth 2.0 only use cases out there... >>>>> but nevertheless I agree with the potential confusion and thus securi= ty >>>>> problems arising from that (though one may argue the semantics are th= e >>>>> same). >>>>> >>>>> Hans. >>>>> >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>>>> dbaier@leastprivilege.com> wrote: >>>>> >>>>>> Yes I know - and I think in hindsight it was a mistake to use the >>>>>> same claim type for multiple semantics. >>>>>> >>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are makin= g things more >>>>>> complicated than they need to be - in my experience almost no-one (t= hat I >>>>>> know) does OIDC only - nor OAuth only. They always combine it. >>>>>> >>>>>> In reality this leads to potential security problems - this spec has >>>>>> the potential to rectify the situation. >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>>>> hans.zandbelt@zmartzone.eu) wrote: >>>>>> >>>>>> Without agreeing or disagreeing: OIDC does not apply here since it i= s >>>>>> not OAuth and an access token is not an id_token. >>>>>> The JWT spec says in >>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>>>> >>>>>> "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" >>>>>> >>>>>> which kind of spells "client" in case of the client credentials gran= t >>>>>> but I also do worry about Resource Servers thinking/acting only in t= erms of >>>>>> users >>>>>> >>>>>> Hans. >>>>>> >>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>>>> dbaier@leastprivilege.com> wrote: >>>>>> >>>>>>> IMHO the sub claim should always refer to the user - and nothing >>>>>>> else. >>>>>>> >>>>>>> OIDC says: >>>>>>> >>>>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>>> >>>>>>> client_id should be used to identify clients. >>>>>>> >>>>>>> cheers >>>>>>> Dominick >>>>>>> >>>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote= : >>>>>>> >>>>>>> Hi Vittorio, >>>>>>> >>>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>>> >>>>>>> One feedback. >>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and >>>>>>> client, in this spec. >>>>>>> It requires those 2 types of identifiers to be unique each other in >>>>>>> the IdP context. >>>>>>> >>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such >>>>>>> constraint needed. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> nov >>>>>>> >>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 >>>>>>> access tokens. You can find it in >>>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-= jwt/ >>>>>>> . >>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be >>>>>>> presenting remotely). I look forward for your comments! >>>>>>> >>>>>>> Here's just a bit of backstory, in case you are interested in how >>>>>>> this doc came to be. The trajectory it followed is somewhat unusual= . >>>>>>> >>>>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>>>> through the years I have come across multiple proprietary soluti= on using >>>>>>> JWT for their access token. The intent and scenarios addressed b= y those >>>>>>> solutions are mostly the same across vendors, but the syntax and >>>>>>> interpretations in the implementations are different enough to p= revent >>>>>>> developers from reusing code and skills when moving from product= to product. >>>>>>> - I asked several individuals from key products and services to >>>>>>> share with me concrete examples of their JWT access tokens (THAN= K YOU >>>>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens= and >>>>>>> explanations!). >>>>>>> I studied and compared all those instances, identifying >>>>>>> commonalities and differences. >>>>>>> - I put together a presentation summarizing my findings and >>>>>>> suggesting a rough interoperable profile (slides: >>>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertoc= ci_-_a_jwt_profile_for_ats.pptx >>>>>>> >>>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>>> - The presentation was followed up by 1.5 hours of unconference >>>>>>> discussion, which was incredibly valuable to get tight-loop feed= back and >>>>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzh= uvinov, >>>>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>>>> there and contributed generously to the discussion. Thank you!!! >>>>>>> Note: if you were at OSW2019, participated in the discussion and >>>>>>> didn't get credited in the draft, my apologies: please send me a= note and >>>>>>> I'll make things right at the next update. >>>>>>> - On my flight back I did my best to incorporate all the ideas >>>>>>> and feedback in a draft, which will be discussed at IETF104 tomo= rrow. >>>>>>> Rifaat, Hannes and above all Brian were all super helpful in neg= otiating >>>>>>> the mysterious syntax of the RFC format and submission process. >>>>>>> >>>>>>> I was blown away by the availability, involvement and willingness t= o >>>>>>> invest time to get things right that everyone demonstrated in the p= rocess. >>>>>>> This is an amazing community. >>>>>>> V. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> hans.zandbelt@zmartzone.eu >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>> >>>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> -- >>> Vennlig hilsen >>> >>> Steinar Noem >>> Partner Udelt AS >>> Systemutvikler >>> >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 >>> | www.udelt.no | >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000c3b8fd0585a67e1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I will argue that in a way such deployments are already br= oken e.g. in the typical use case of onboarding client accounts in the same= directory/OU/namespace as user accounts and we don't need to cater for= that.

Hans.

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 3, 2019 at 10:48 PM George= Fletcher <gffletch@aol.com> = wrote:
=20 =20 =20
I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 1= 2:56 PM, Hans Zandbelt wrote:
=20
great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'= m on board

Hans.

On Tue, Mar 26, 2019 at 5:4= 9 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.
Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow"= ;, we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "HelseID")=C2=A0 think his= is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

<mvh>Steinar</mvh>

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>= ;:
From an access token consumer (aka API) developer point of view, I prefer this logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.

On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Yeah, I=E2=80=99m concerning user &= ; client ids collision.
I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fin= e. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

Thanks
V.=C2=A0


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.= eu> wrote:
I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

Hans.

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivil= ege.com> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

All the =E2=80=9Cthis is OIDC= not OAuth=E2=80=9D argume= nts are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzon= e.eu) wrote:

= Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.<= /div>
=
"= The "sub" (subject) claim identifies the principal that is the
=C2=A0 =C2=A0subject of the JWT.=C2=A0 Th= e claims in a JWT are normally statements=
=C2=A0 =C2=A0about the subject.=C2=A0 Th= e subject value MUST either be scoped to be
=C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
=C2=A0 =C2=A0The processing of this claim is generally application specific"

which kind of spells "client"= ; in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.<= /span>
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com= > wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."=

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.<= /div>
The =E2=80=9Csub=E2= =80=9D claim can include 2 types of identifier, end-user and client, in this spec.=
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80= =9Csub=E2=80=9D claim in 2-legged context, so that no such constraint needed.

thanks=

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
= Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-= access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'l= l be presenting remotely). I look forward for your comments!

Here&#= 39;s just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2= =A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_= media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig= =C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0<= /div>
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

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


--


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


--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler=
=C2=A0
|=C2=A0steinar= @udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0<= a>+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth


--

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



--
--000000000000c3b8fd0585a67e1e-- From nobody Wed Apr 3 18:34:27 2019 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 CEDB01201B1 for ; Wed, 3 Apr 2019 18:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b4UgAceGq8S2 for ; Wed, 3 Apr 2019 18:34:22 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640111.outbound.protection.outlook.com [40.107.64.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353B712017B for ; Wed, 3 Apr 2019 18:34:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=ROMxRqOt+crIORk+7kfbrsoUk4T1QvbFZkMdq616kA/7LuDdxn/RRqAI7efGK9BBKmCNPFwMz7GsV4nu+YqkU7ZvAK7l3R9DWBQgWiOn5kW6QD4USwLgW6N+mQz1Z3/cQgCfpyp4uwdiVNKZPAppAw9PjAEP/dt9qrQspxSm690= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7fMfT648ZwgJfSRh6SmWaDeJIF4oD+W0cNGwi6/oa8=; b=WEY9O622rE6Tm4+cR2NtzBEt85KJpTecWYMUFY7ubLVm/aomKLgS1GCx/+zwNLiB8ezFLZUI3YA2/agYERLjI4rpaLrvKejHPp1TPUKsoutS9BKFcWC/Gx6UrXHkGBRJnh5ZDnEIby19S28ZFMGKIy7/CizkQTCHARnwwJVsMhY= ARC-Authentication-Results: i=1; test.office365.com 1;dmarc=none action=none header.from=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q7fMfT648ZwgJfSRh6SmWaDeJIF4oD+W0cNGwi6/oa8=; b=cV6jAHM15PgfObJ3b9o0JlxzTTRMjtKlIPtk4SMLwgGO5o84I7lSfF5sTxYXrjzaVR9nza+rd91NrGvF8DeNzmNrIWYCY/qvtr4mvTnImUTG8umehp/1YjoXqHp7qhwgzFrR5njtbFvTGNhAENbejTUhb81Z4Z15lEH3Tx4cWrg= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0346.namprd00.prod.outlook.com (52.132.148.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1811.0; Thu, 4 Apr 2019 01:34:19 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::bda6:ce40:bdf4:3612]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::bda6:ce40:bdf4:3612%4]) with mapi id 15.20.1811.000; Thu, 4 Apr 2019 01:34:19 +0000 From: Mike Jones To: "oauth@ietf.org" CC: Daniel Fett , Filip Skokan Thread-Topic: DPoP blog post Thread-Index: AdTqhkBmCsvUWQlaTmKq4FeonM3DqQ== Date: Thu, 4 Apr 2019 01:34:19 +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=08778b18-27e9-46c3-a20f-0000ce3608a2; 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=2019-04-04T01:32:12-0800; 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.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3e7f96f-3ba4-4429-5ff3-08d6b89da8a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0346; x-ms-traffictypediagnostic: MW2PR00MB0346: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(136003)(366004)(209900001)(189003)(199004)(14454004)(6436002)(5660300002)(33656002)(2501003)(10290500003)(5640700003)(478600001)(55016002)(74316002)(97736004)(52536014)(72206003)(68736007)(1730700003)(558084003)(4326008)(81166006)(6916009)(8676002)(8936002)(81156014)(25786009)(606006)(3480700005)(71190400001)(71200400001)(86362001)(256004)(7116003)(53376002)(7696005)(86612001)(476003)(186003)(3846002)(790700001)(486006)(966005)(6116002)(8990500004)(10090500001)(53936002)(7736002)(54896002)(236005)(66066001)(9686003)(54906003)(6306002)(6506007)(102836004)(316002)(22452003)(2906002)(99286004)(106356001)(26005)(2351001)(105586002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0346; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: T/POB+ukyagbez5cyiejkTrsBSRYdHEtp4EUr7FX4Oytm5AoLAqR+VrdL25SFibMlsfpuDUfEJ+TIsBtT0Uy75CstXc7L9UVsz0CijbY4ReKUFJYvZ+Q3IYjkN3nw16MxY+pNr4gBsz+7kNr6af4Liqc+n17GXxRMNt+S1iUkpIXBWo4tA4C5fzGAKwCHWniDSS+qSpo5RqH+wIFAFz7XM08KArz/mWO0gNJWqZHTkxRn96PDQGf/DTUaNIQPlGo/MZfcLSbxTZwCEqfp+S7pzWn3oCn8rbv8/lFIEyz44fVqWV5iVu1wO1iPbvJVgmw7Tw8Po7W6/SIdWo+IRGEh3ZvKrwKtqNaS3LQlgWngmSr8D67CDUnNXLcAWxPvJxWlgf60ipxCuWUw0282T5nrDoTHoZ2gR/ifdvhaa0nJ50= Content-Type: multipart/alternative; boundary="_000_MW2PR00MB02982FB2D421428065520440F5500MW2PR00MB0298namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3e7f96f-3ba4-4429-5ff3-08d6b89da8a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 01:34:19.6619 (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-Transport-CrossTenantHeadersStamped: MW2PR00MB0346 Archived-At: Subject: [OAUTH-WG] DPoP blog post 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, 04 Apr 2019 01:34:26 -0000 --_000_MW2PR00MB02982FB2D421428065520440F5500MW2PR00MB0298namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I posted about the new DPoP draft at http://self-issued.info/?p=3D1967= and as @selfissued, asking people to have = a look and provide feedback. -- Mike --_000_MW2PR00MB02982FB2D421428065520440F5500MW2PR00MB0298namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, I posted about the new DPoP draft at http://self-issued.info/?p=3D1967 and as @selfissued, asking people to have a look and provide feedback.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

 

--_000_MW2PR00MB02982FB2D421428065520440F5500MW2PR00MB0298namp_-- From nobody Wed Apr 3 21:47:48 2019 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 C16791201CE for ; Wed, 3 Apr 2019 21:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hwMoZluhNAiF for ; Wed, 3 Apr 2019 21:47:44 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 982991200E6 for ; Wed, 3 Apr 2019 21:47:44 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:c812:83f5:89e3:d54e] (unknown [IPv6:2601:282:202:b210:c812:83f5:89e3:d54e]) by alkaline-solutions.com (Postfix) with ESMTPSA id 44881315A4; Thu, 4 Apr 2019 04:47:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: David Waite In-Reply-To: Date: Wed, 3 Apr 2019 22:47:42 -0600 Cc: Aaron Parecki , "oauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <254ACA13-D8DA-4E2A-A68F-DDE4B1C0C53E@alkaline-solutions.com> References: To: George Fletcher X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00 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, 04 Apr 2019 04:47:47 -0000 Multiple concepts often get tacked onto a particular term, which both = aids and hinders communication. =46rom RFC 6749, a public client is defined as: "Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.=E2=80=9D RFC 6749 also defines a user-agent-based application: " A user-agent-based application is a public client in which the client code is downloaded from a web server and executes within a user-agent (e.g., web browser) on the device used by the resource owner. Protocol data and credentials are easily accessible (and often visible) to the resource owner. Since such applications reside within the user-agent, they can make seamless use of the user-agent capabilities when requesting authorization.=E2=80=9D These have over time been conflated. So when people speak of public = clients, they may mean a client which has some subset of the following = aspects: - A client which is also a user agent (I personally consider native = applications to also be a user agent, but that=E2=80=99s neither here = nor there) - A client that cannot keep a secret and thus cannot be issued a secret - A lack of guarantee that the client represents a particular agent = (that it is unmodified 1st or 3rd party code) - A client that cannot keep access tokens and traffic confidential (even = if that is from a creative resource owner) The ability to keep a secret is perhaps the least meaningful part of = this list. The secret serves a purpose to identify the client, and thus = =E2=80=9Cknow=E2=80=9D access tokens are being requested by that client. = It isn=E2=80=99t that public clients cannot hold a secret that matters - = it is that they cannot be reliably identified or assumed authentic. In the confidential client case, the client is expected to represent = particular business goals and possibly a particular organizational = relationship. The access token is confidential, the communication with = the resources is confidential - driven by business logic which is meant = to be fixed to represent those business goals. In a public client, the security model can try to defend against = malicious third parties like web attackers and malicious parties acting = as other clients, authorization servers, or protected resources - but = you can=E2=80=99t defend against a compromised platform or a = sufficiently motivated end user.=20 Since a hybrid sharing of tokens between the two is not defined by any = specification, we can only assume things like: - either the backend gives the front-end an access token, another token = which acts equivalent to the access token, or sets a cookie value which = when applied to resources acts equivalent to an access token - this means while the backend can keep a secret, it is meaningless in = that the access token rights gained from that secret are not = confidential - since the frontend initiates the protocol traffic and has this new = credential, the protocol data and which actions are performed are not = secured Now if this backend exposes its own reduced resource server and its own = tokens, then this is different - but then I would argue either that: - conceptually the backend is now the new AS and resource server for my = frontend, which is still a public client (but perhaps no longer a public = client in the eyes of the original AS) - or that this is no longer OAuth -DW > On Apr 2, 2019, at 9:52 AM, George Fletcher wrote: >=20 > Hi, >=20 > In section 6.2 the following statement is made... >=20 > In this scenario, the backend component may be a confidential = client > which is issued its own client secret. Despite this, there are = still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user. >=20 > I'm curious as to how this model is different from many existing = resource server deployments acting as confidential clients. While the = application code is running in the browser, only the access token is = exposed to the browser as is the case for many RS deployments where the = RS returns the access token to the browser after the authorization flow = completes. My interpretation of "confidential client" does not include = whether the client's code is "visible" to externals or not, but rather = whether the client can protect the secret. >=20 > In that sense I don't believe this deployment model is "effectively a = public client". A hybrid model description is fine, and I don't disagree = that some authorization servers may want to treat these clients in a = different way. >=20 > Thanks, > George From nobody Wed Apr 3 23:12:29 2019 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 A9B741203A5 for ; Wed, 3 Apr 2019 23:12:26 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8h55DqsT0ME0 for ; Wed, 3 Apr 2019 23:12:23 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 B68921201C7 for ; Wed, 3 Apr 2019 23:12:22 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id c189so943706qke.6 for ; Wed, 03 Apr 2019 23:12:22 -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=wCPXZNO3tv/3Rkq6fLSeyRHYhixkU0rMsmyDFgOgcn0=; b=p9uq10ytKb0+l5Wtr02Gxi7L0IYMXff7gHfy7V/8b7hP1qOT+IGSvXKByXhCyjQDvS 9omMaXopGGIo1VIJ39g1d2Ijxy7PP9mpsSdawgv0uyI71BB2BVOgrhLTzDVTEFmWvbQE bQtQHt9n1Bsk4oEzMPWCKOkaYYXVg521/LkIxps8qkJgQe6bm80jJWZ/FhV5x9Y2vTYP 4kXQ+lGvS+ji1IYw5pec+Xlj5kU8YoLENBmY+Amxr9ZA0HbNl7ZXDk0dTZus7mKS/EQy KS0MImr0iPDskCTk5PP0zHdr6OVFVCcjOcjX14eRbrZJJpqJZdIsRLqmX0LBbXLCXs9c 6cfQ== 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=wCPXZNO3tv/3Rkq6fLSeyRHYhixkU0rMsmyDFgOgcn0=; b=nPVwtT0J2xRzQheZuht7baHZCO/i97sNS6HCKYQmUNp6SHNzx88jjOd5ETMhGAqy9o 1N5H05J5N2EWJkqn87PNOKh0rIG2yYNOmTyndSRH/TEAfiq60fuiSA6runH8qUkKGdX1 hGY1gFH49MRzc3m8jwfgmB/nZ0pxWYFr859d/uEuJdDXvpS/gTmqtHcID2/qm00udn6B 7GQxc68gdzIFejAW2LPjj7E4wIi5GzUFTryBKgnZLQD/3zjdHkaZoqrhR4lo60YHMW9L wioYc6EYRieFqfRbgGPk3ebKiWPcdQlvojfBsYbfXBHJFRiimIO+QYm4/XUIm5ZB1V4N qmEw== X-Gm-Message-State: APjAAAWixrOpRei1X6uzaDA8ljMarNJcyVNmMAfw++AgD017hxwBMXFB jk2upplCdLlQe5PseuK+ghfP4QlMCiggxHBkSxTP X-Google-Smtp-Source: APXvYqwo18AsTXfbQO+DmW+p6XpPANZq61kLIu7eP5r7vEA/Ln5/AKGTxS44YETJUCGLQ1Y+nwTQdbX+ftRtm+w57uM= X-Received: by 2002:a37:8d06:: with SMTP id p6mr3429172qkd.120.1554358341743; Wed, 03 Apr 2019 23:12:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 3 Apr 2019 23:12:21 -0700 From: Dominick Baier In-Reply-To: References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> MIME-Version: 1.0 Date: Wed, 3 Apr 2019 23:12:21 -0700 Message-ID: To: Vittorio Bertocci , Brian Campbell Cc: George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000d04b560585ae4061" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 06:12:27 -0000 --000000000000d04b560585ae4061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My experience: When building modern applications, we use OIDC and OAuth together for authentication, session management and API access. Only the combination makes sense (to me) here. Hence it also makes sense (for me) to share claims types going forward. IdentityServer is a framework that is typically used when building new applications (or modernising them) so we have the luxury of a lot of =E2=80=9CGreenfield-ish=E2=80=9D scenarios - I acknowledge that this might = not apply to everyone on this list. Maybe we need a =E2=80=9Cbase profile=E2=80=9D + =E2=80=9Cend-user identity= =E2=80=9D extensions... =E2=80=94=E2=80=94=E2=80=94 Dominick On 3. April 2019 at 21:38:55, Vittorio Bertocci ( vittorio=3D40auth0.com@dmarc.ietf.org) wrote: Thanks guys for the comment, sorry for the delay in addressing them. I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south. However I think it's important that the information on say, whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API). Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers. In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access). I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW. But I am completely open to change it of course, especially for cases like the one identified by George. WDYT? On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell wrote: > +1 to David's question here. I'd like to see justifying use cases (beyond > just the fact that some people are already doing it) for auth_time, acr, > and amr to be available in OAuth JWT access tokens. Those claims are > defined for, and in the context of, an ID Token and I fear that codifying > their use in an access token will lead to misuse and/or confusion. > > On Mon, Apr 1, 2019 at 1:03 PM David Waite > wrote: > >> Do we know if there is a justifying use case for auth_time, acr, and amr >> to be available in OAuth JWT access tokens? These are meant to be messag= es >> about the client, either directly (in the case of client credentials) or >> about its delegated authorization of the user. >> >> Embedding attributes about the user (such as group membership and roles) >> can be used for the resource to make finer-grained decisions than scopes= , >> but normally I would expect say acr limitations enforced by a resource t= o >> instead be controlled by the AS requiring a higher quality authenticatio= n >> to release certain scopes. >> >> Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99= t provide >> these values, just that they might better be defined by those extensions= . >> >> -DW >> >> On Apr 1, 2019, at 9:12 AM, George Fletcher < >> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >> >> Thanks for writing this up. One comment on auth_time... >> >> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >> Important: as this claim represents the time at which the end user >> authenticated, its value will remain the same for all the JWT >> access tokens issued within that session. For example: all the >> JWT access tokens obtained with a given refresh token will all >> have the same value of auth_time, corresponding to the instant in >> which the user first authenticated to obtain the refresh token. >> >> >> During a current session a user can be challenged for additional >> credentials or required to re-authenticate due to a number of different >> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this cont= ext, >> I'd assume that the auth_time value should be updated to the latest time= at >> which the user authenticated. >> >> If we need a timestamp for when the "session" started, then there could >> be a session_start_time claim. >> >> Thanks, >> George >> >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >> >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions! >> ). >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> V. >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 fi= le > 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 --000000000000d04b560585ae4061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
My e= xperience:
<= br>
When bui= lding modern applications, we use OIDC and OAuth together for authenticatio= n, session management and API access. Only the combination makes sense (to = me) here. Hence it also makes sense (for me) to share claims types going fo= rward.

<= /div>
IdentityServ= er is a framework that is typically used when building new applications (or= modernising them) so we have the luxury of a lot of =E2=80=9CGreenfield-is= h=E2=80=9D scenarios - I acknowledge that this might not apply to everyone = on this list.

Maybe= we need a =E2=80=9Cbase profile=E2=80=9D + =E2=80=9Cend-user identity=E2= =80=9D extensions...

=E2=80=94=E2=80=94=E2=80= =94
Dominick

On 3. April 2019 a= t 21:38:55, Vittorio Bertocci (vittorio=3D40auth0.com@dmarc.ietf.org) wrote:

Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south.
However I think it's important that the information on say, whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API).=C2=A0
Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers.=C2=A0 =C2=A0
In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened=C2=A0is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access).

I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW. But I am completely open to change it of course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
+1 to David's question here. I'd like to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com> wrote:
Do we know if there is a justifying use case for auth_time, acr, and amr to be available in OAuth JWT access tokens? These are meant to be messages about the client, either directly (in the case of client credentials) or about its delegated authorization of the user.

Embedding attributes about the user (such as group membership and roles) can be used for the resource to make finer-grained decisions than scopes, but normally I would expect say acr limitations enforced by a resource to instead be controlled by the AS requiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99t provide these values, just that they might better be defined by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=3D40aol.com@dma= rc.ietf.org> wrote:

Thanks= for writing this up. One comment on auth_time...

auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core<=
/a>].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https= ://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw20= 19/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

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

_______________________________________________
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 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--000000000000d04b560585ae4061-- From nobody Thu Apr 4 07:07:09 2019 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 53FD21206AA for ; Thu, 4 Apr 2019 07:07:07 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EnfEQ-VIyKCk for ; Thu, 4 Apr 2019 07:07:03 -0700 (PDT) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 D34E21206A8 for ; Thu, 4 Apr 2019 07:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554386821; bh=gOh2ao8kMXJ9Dsdkud67LMCgkVuF20J74kBvEIyl6B0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=MytFvgIgrgstX63UbfbBCbgzTWZyChgXWh95ceBj6BtPoaksEaLhJqjTJMFgiBPf/8PRnTZwxTlgDzHIHBA/U8g/K2mKPackv9WJJWSS2hgY/z0TQ0/mqYd6Bj5KsvgVVw26XewsQ9WFzEpD8H8vM6qgScK74UzRp8y7tL8Kfo6HeeJU0u8/QVgJGDJpI38qTdk5YqpR5Uvtj3XtlgWbZq3od8ilVLGs5SElbuwZccgHVFalHJP7EY589CTtLbmyNNGkHDFkkRDQjfD2vGwHg5a6twczTk+ETDaAiRs7ANxR625J82XUidDV7sjVb51akB8at8bHWPndYseUYzEVyA== X-YMail-OSG: .GW.qhMVM1mnR_u6Ytxl.BUfSIYmkrZehYfePXxQhb3Yu6piPwcP1aZTAC7cIIF 8bFPVsuulhOD0HkBgKiAfEDjforUhK_8qjO2Jiv7a_XZ1gao_5Sqdyh1FAE2VPVJaGLCqa6S76lC Ko3cSc09AICCvLt2mvROxChhPiy8COGkZwJ7reVMllHHf77aWm4i_XF_YbUmJ3dcO0j3lsXLoSJz u8MzqLMmkDkVTPvOmwQKoKoSnebCKCMxdCKvdhzeY1KuYN6Wud1dHNjv3Kx7k00L1QvpKONgjZBd yRmsuge26bY98M7DsU2Wwil4JJzUppiAEVI9GVdvbx0KOfd96yvZviw12KiaHx.0O_grjLLCR53X UHIYSY5998MFqixI760yaBCdo2abWQclFXS4IkBlZvOf4Z2KVcIiBgCOxmdLVRoBujMy8xNvl6M8 i1aQH.Kzfw2vRsZVxPDo.DzIrbKD4Sv5iRNjX64sKp6pQC7DzK1cjl222icDD.wzCqeQ9ZP9BQWg 4hojRRjivfMr6Wo2z_umiCHjqwiS6i08cRZlFmDEEM4wJ6vLNcv6iMWYDhk9ss5Y9V6kxOa2yyRy NQDpKw7U5qhZQlNVysdfBqQ6mW.FfegIkTbl7cYnKgV3yzqSIMBN_kxfHAACMaTS9Xj6CWSFX5X0 Fu4AVie08j64UEbh9UPyTLma19JWijIYWugdb1Wqr05R71SHOT5HzeBKBRp9VJh9q69UcG1S.YXj iQ0rh5C9soKtte9.3HlON.sIEW_f_aRdKfN5Uybo9smjlw64I63TP2QL7hUKgBU27GsmCYvxeOql g8mg04OqJz4mJ5wjEk_k9K3O3mXn0E2zGxUq0V.Khjv8Sl834VGoyUOjslLiH9fS3tDXsGY61WR8 hadUQCwXMHoqCrYPpTvR3E6s2mzisXO5x48FU0yzjIePYKi8H0b9AyL2527PQ6WNCG.6fSU4XOQX GPPuh0ObDeyD55olzro_kBajZ7mcYdl8wAUJVDyd28xMQhu8pNSrxPChUuBoyj0QWgC_URFfFG4V nrRF6IwJtvxU3ReOoPXJe5nJiMJGqEQcOni4HKPlYJ69vPbUXdIGSbexSHBgCvU08BA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 14:07:01 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 15a591e38e1277f0b5bf80a37b3d1e58; Thu, 04 Apr 2019 14:06:58 +0000 (UTC) To: Vittorio@auth0.com, IETF oauth WG References: From: George Fletcher Organization: AOL LLC Message-ID: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> Date: Thu, 4 Apr 2019 10:06:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0F187D3EACDFE3DE4DCF446C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 14:07:07 -0000 This is a multi-part message in MIME format. --------------0F187D3EACDFE3DE4DCF446C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Another comment... aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See Section 3 for indications on how an authorization server should determine the value of aud depending on the request. [Note: some vendors seem to rely on resource aliases. If we believe this to be a valuable feature, here's some proposed language: The aud claim MAY include a list of individual resource indicators if they are all aliases referring to the same requested resource known by the authorization server. ] I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the 'aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the resource service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective). Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not. Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance... If the request does not include a resource parameter, the authorization server MUST use in the aud claim a default resource indicator. If a scope parameter is present in the request, the authorization server SHOULD use it to infer the value of the default resource indicator to be used in the aud claim. I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure. On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this > doc came to be. The trajectory it followed is somewhat unusual. > > * Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using > JWT for their access token. The intent and scenarios addressed by > those solutions are mostly the same across vendors, but the syntax > and interpretations in the implementations are different enough to > prevent developers from reusing code and skills when moving from > product to product. > * I asked several individuals from key products and services to > share with me concrete examples of their JWT access tokens (THANK > YOU Dominick Baier (IdentityServer), Brian Campbell > (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) > for the tokens and explanations!). > I studied and compared all those instances, identifying > commonalities and differences. > * I put together a presentation summarizing my findings and > suggesting a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > * The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop > feedback and incorporate new ideas. John Bradley, Brian Campbell > Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes > Tschofenig were all there and contributed generously to the > discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a > note and I'll make things right at the next update. > * On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. > Rifaat, Hannes and above all Brian were all super helpful in > negotiating the mysterious syntax of the RFC format and submission > process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the > process. This is an amazing community. > V. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------0F187D3EACDFE3DE4DCF446C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Another comment...

   aud  REQUIRED - as defined in section 2 of [OpenID.Core].  See
      Section 3 for indications on how an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the 'aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the resource service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request does not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.

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

--------------0F187D3EACDFE3DE4DCF446C-- From nobody Thu Apr 4 07:14:10 2019 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 AE702120678 for ; Thu, 4 Apr 2019 07:14:08 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K_jPP3j5Ld4i for ; Thu, 4 Apr 2019 07:14:04 -0700 (PDT) Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (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 2D58B1200EC for ; Thu, 4 Apr 2019 07:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554387243; bh=3edl0LrvusMNk51tYWE9BF8Ad03bQNRHdZk9S/GEa5I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=Ne551wHwOrg0O25862BH6uO+29+5RM2rW4DWUy6aEw+TO7lLtIbhbejOfp6NvmueMtCu8A8OtdOigab4TtxMJVMowBaB2GHuNkZF5nU3YOixCn4cwKa4HKB8KNlPsF8fhn1xxJFwaJv3PDgMw4LwCIt8fHos4JUtthToLtv8iiNB2WviNbiEtuUHZZS60v8STfhAPfSnT1IP3SnOChFraylxdwvS7M5GKRIoexAENMVcEPK61VW4nsCqFbX0ilWnHSLaVlAqvu2fa1FXlOR9WXLNH6ZOD3X7zB5uSrGiooamtMNnSvFxuKHln7FEGh05vrT0Sm3Uj0y7dQvkG4ez2Q== X-YMail-OSG: MmJJkSQVM1ml1tpGCgwYTdAMucDqS1wUet7M8riJLSzlTPm16rbyH3ShEyrNoZs D8gGlvGupHTVrxsYWzs48wFyowkv2NZ_5s8KtG5qal9.XteU_8ilg78MQZMFxBuBON5O4isOGc0A 1foWHJq8siZJZ4l4obmu21WhHNRJYrA9e75KONweeWGE9K1NYeqV1y0GwgXf3JUUnn4ct7vPhgdw eA9eevidhzB2IowHrtqCo6lAOR2qrcFpNGVaDvCPAsjfsJfvUSs7aOeCIA_r4seXlcXLbV9JFS.r McTrQafPG3V64DsjxgGwbnHpedQGb0RDPDcerwBdJUyJCM5QjvACDDzzKQ6n6mx4Az8O3YsAq9lC 5WHmQ4wwFW09p66NUS7kbh7SLrsEwj5pyF4ZJdOWSaqo7sRe_Qa8X2JhrLiYYx0i5VTCTIotVVo_ w0wiFoB6RZxcFiXJweTZkDh1ZiSiKQ4jtlrVlxcnQImYyr7kD.uOjQ3u.XVUo_pA4c4D.CciIrkL yGCIvlOS1Bmj0nJmlpvsqcVgy1mn7PheX_W8dSWm0RlGv_VpD1VIj7vlKyRFI_V5iF3dppTL8._Y s2Ch_rHSJ.qJxivdkH_OT1Eu6UcojT4Bhni7mrD56AczaIpDVHunqP.m9KuBn_K35zan62ElFp1S WjAin_NJIhE_wbMwGrpv7dto.3iApsuoG7uHq67sJeMd4CleFEhl7oenXwcdISW9BBlQ_iADQ.8c eP9ilB6sjNWG1LComOCWCsjFAHECwhmR.TpE9khCeYnu4anFfIcWHcA094mSE1UQDkq4Ye.41IcD AcLgux9inzr7q758p6XWp8Su9hTqDS2NVJR8SnDFQSyidMXiA1rbYOsu.jIT5uFF5bYzfMEhh8AS Ff1Is0anP5l0jJysE_b.Zw4zHYlMjCCEqak7fURSZHJt_QwJsWk1xFuFzFcTUYt0nEdT.K2fKbHo OLtq8YtHqb88SFE05yKlDbhesczxwbTVzBRdRCOFTP4LT3Tf1VsBkPxC1SpJ3pzFEVRcRHerj4BJ ND2W1FDKPddwCHTVPt0Dy1QATwLffLPNnOj1xFViRT2fZXRLgIgL6oZoIWVktYS0Ox.LIF8C3QxF dvhnLMA9oZGphfAwltM5quhrExZ48gMKkb6X1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 14:14:03 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1b9112a718319920336df2b50afbc6ad; Thu, 04 Apr 2019 14:14:01 +0000 (UTC) To: Vittorio Bertocci , Brian Campbell Cc: David Waite , IETF oauth WG References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 4 Apr 2019 10:14:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84029669242BA5F0633FA575" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 14:14:09 -0000 This is a multi-part message in MIME format. --------------84029669242BA5F0633FA575 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Comments inline... On 4/3/19 3:38 PM, Vittorio Bertocci wrote: > Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim types used in here, so if you think that > reusing the ones in the id_token can cause confusion we should expand > on the specific ways in which you think might go south. I'm fine with re-using claims... we just need to make sure if we reuse a claim it keeps the same semantic. > However I think it's important that the information on say, whether > the current token was obtained using MFA or a specific authentication > factor is something that API developers can legitimately latch to when > doing authorization decisions. From the perspective of a developer > modeling a solution, whether functionality is delivered as a route in > a postback based web app (hence receiving an id_token or derived) or > as an API consumed by a native app, the business requirement gating > access to that functionality doesn't change. If the admin managing > that resource establishes that access should be performed only via > MFA, the developer should be equipped to enforce that regardless of > the stack used to expose functionality (web app, API). > Although it is true that triggering the desired behavior might be > achieved by the resource setting and contract with the AS, along the > lines of what David said, it's actually not uncommon for those > policies to be assigned on the resource AFTER the current session was > established and/or the corresponding AT was obtained and cached. > Furthermore, the requirement might be more granular than an AS policy > can tolerate (an API might requires MFA only for certain routes, hence > hard to express in a static policy) and triggered in form of > challenges. So the situation in which you have an AT with the right > issuer, audience, etc but was obtained with a policy now > obsolete/unacceptable to the RP is strong. Requesting to support > revocation just for this seems overkill, especially given that the > scenario in which the same logical app is exposed as both web app and > native client+API, the code consuming those claims is already in > place. It just makes intuitive sense for developers. > In summary, one can take steps to push as much of the MFA requirements > to the AS settings for a particular request, but ultimately the desire > of the API developer to enforce that it actually happened is a > requirement I encountered often in practice. Anything providing extra > context to refine decisions about it (like auth_time, which might > inform decisions about whether to accept an MFA check occurred N > minutes ago or refuse access). As an aside, I worry about trying to put all information needed to make a dynamic policy decision into an access token. For cases where the policy can change over time including the lifetime of the access_token then I prefer the User Managed Access (UMA) approach as it inherently allows for dynamic policy change. > > I thought that reusing the existing names for the same concepts just > made sense (dev existing skills, existing codebases, etc etc) and > especially in the case in which the values are exactly the same, and > the idea seemed to receive good support during OSW. But I am > completely open to change it of course, especially for cases like the > one identified by George. > WDYT? > > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell > > wrote: > > +1 to David's question here. I'd like to see justifying use cases > (beyond just the fact that some people are already doing it) for > auth_time, acr, and amr to be available in OAuth JWT access > tokens. Those claims are defined for, and in the context of, an ID > Token and I fear that codifying their use in an access token will > lead to misuse and/or confusion. > > On Mon, Apr 1, 2019 at 1:03 PM David Waite > > wrote: > > Do we know if there is a justifying use case for auth_time, > acr, and amr to be available in OAuth JWT access tokens? These > are meant to be messages about the client, either directly (in > the case of client credentials) or about its delegated > authorization of the user. > > Embedding attributes about the user (such as group membership > and roles) can be used for the resource to make finer-grained > decisions than scopes, but normally I would expect say acr > limitations enforced by a resource to instead be controlled by > the AS requiring a higher quality authentication to release > certain scopes. > > Thats of course not to say extensions to OAuth such as OIDC > can’t provide these values, just that they might better be > defined by those extensions. > > -DW > >> On Apr 1, 2019, at 9:12 AM, George Fletcher >> > > wrote: >> >> Thanks for writing this up. One comment on auth_time... >> >> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >> Important: as this claim represents the time at which the end user >> authenticated, its value will remain the same for all the JWT >> access tokens issued within that session. For example: all the >> JWT access tokens obtained with a given refresh token will all >> have the same value of auth_time, corresponding to the instant in >> which the user first authenticated to obtain the refresh token. >> >> During a current session a user can be challenged for >> additional credentials or required to re-authenticate due to >> a number of different reasons. For example, OIDC prompt=login >> or max_age=NNN. In this context, I'd assume that the >> auth_time value should be updated to the latest time at which >> the user authenticated. >> >> If we need a timestamp for when the "session" started, then >> there could be a session_start_time claim. >> >> Thanks, >> George >> >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth >>> 2.0 access tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be >>> presenting remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested >>> in how this doc came to be. The trajectory it followed is >>> somewhat unusual. >>> >>> * Despite OAuth2 not requiring any specific format for >>> ATs, through the years I have come across multiple >>> proprietary solution using JWT for their access token. >>> The intent and scenarios addressed by those solutions >>> are mostly the same across vendors, but the syntax and >>> interpretations in the implementations are different >>> enough to prevent developers from reusing code and >>> skills when moving from product to product. >>> * I asked several individuals from key products and >>> services to share with me concrete examples of their JWT >>> access tokens (THANK YOU Dominick Baier >>> (IdentityServer), Brian Campbell (PingIdentity), Daniel >>> Dobalian (Microsoft), Karl Guinness (Okta) for the >>> tokens and explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> * I put together a presentation summarizing my findings >>> and suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> * The presentation was followed up by 1.5 hours of >>> unconference discussion, which was incredibly valuable >>> to get tight-loop feedback and incorporate new ideas. >>> John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten >>> Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>> there and contributed generously to the discussion. >>> Thank you!!! >>> Note: if you were at OSW2019, participated in the >>> discussion and didn't get credited in the draft, my >>> apologies: please send me a note and I'll make things >>> right at the next update. >>> * On my flight back I did my best to incorporate all the >>> ideas and feedback in a draft, which will be discussed >>> at IETF104 tomorrow. Rifaat, Hannes and above all Brian >>> were all super helpful in negotiating the mysterious >>> syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and >>> willingness to invest time to get things right that everyone >>> demonstrated in the process. This is an amazing community. >>> V. >>> >>> _______________________________________________ >>> 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 > > > /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 > --------------84029669242BA5F0633FA575 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Comments inline...

On 4/3/19 3:38 PM, Vittorio Bertocci wrote:
Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south.
I'm fine with re-using claims... we just need to make sure if we reuse a claim it keeps the same semantic.
However I think it's important that the information on say, whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API). 
Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers.   
In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access).
As an aside, I worry about trying to put all information needed to make a dynamic policy decision into an access token. For cases where the policy can change over time including the lifetime of the access_token then I prefer the User Managed Access (UMA) approach as it inherently allows for dynamic policy change.

I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW. But I am completely open to change it of course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
+1 to David's question here. I'd like to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com> wrote:
Do we know if there is a justifying use case for auth_time, acr, and amr to be available in OAuth JWT access tokens? These are meant to be messages about the client, either directly (in the case of client credentials) or about its delegated authorization of the user.

Embedding attributes about the user (such as group membership and roles) can be used for the resource to make finer-grained decisions than scopes, but normally I would expect say acr limitations enforced by a resource to instead be controlled by the AS requiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such as OIDC can’t provide these values, just that they might better be defined by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=login or max_age=NNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.

_______________________________________________
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

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

--------------84029669242BA5F0633FA575-- From nobody Thu Apr 4 08:22:06 2019 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 C5A2F1205D1 for ; Thu, 4 Apr 2019 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 w5whB2VBbBM0 for ; Thu, 4 Apr 2019 08:22:01 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 259541205CC for ; Thu, 4 Apr 2019 08:22:01 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id 139so4291294ita.4 for ; Thu, 04 Apr 2019 08:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rdOELC5neYgahn3sll9JZ1vT4rK7PoCK+e8pUlFUU3k=; b=kvXwl7yg6eM98V0AkQ5pD4eUPO3hSVZnl9i1EeiRqDu1eQM5t/gL50sNrIgTnEDKJf B2NKtXHF4dvU/lAZNDvG+Wmeoe+YNjvTzoJ0mUbcSm0nrYAPpgcK0Fz9duahEbpNQv5w DkXbclVkUm47iFIFsmSeGhubv/zvsuOxWLh3s= 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=rdOELC5neYgahn3sll9JZ1vT4rK7PoCK+e8pUlFUU3k=; b=So90J17kuqCtNbW+9+Nh3oc0Tfb6kmYduznolTLSD7NUAMXzyEOG20bvEfGJa9frHs e+RT5tLrPoeIRd5yGLJU4o7d/YdfryTTABO09+AV2YB3UIOlQJVtoPICtczPCUybr9mh t+yvvY0er785cJ/wDVyLNvugAtpsSl7qgYazxUHHO5fIXyEeA8zqr629mnqbNY/AYYXP 3JQW2NMaX6OzIM/OauxCSTv3JYN+oAogiCxrQCRFOuYsCkkTJoU4P5qNtYDrAhPqZISF bm+G6E1Hd9/Sw0uxUi+11ubB+ISjgf7FbXa++IOyKxuyXwW4frgCyQMVoT/H0xU0T3S2 QIVw== X-Gm-Message-State: APjAAAVzrEqRf87ryujAlFqRmekDIalRY/3bWZyzhqx2ojpl5a/EVIjs cMr356UI90tYtsmsrv6PTgE5GqjL7hblNQcXuK7Fra/NNfTcC26i1YLB+DcuMARHrRX9pUVvJ56 1WeUq5kUatVlJ4g== X-Google-Smtp-Source: APXvYqzIfgQnwQ2VMBgVHiYfDKc4UumcsYi0Z4HrkMeUV5K+8DkXdXpjdhVdaZJ67yYkT033gafRPrlUzFVMWsQwS1o= X-Received: by 2002:a24:d9d0:: with SMTP id p199mr5418317itg.104.1554391320186; Thu, 04 Apr 2019 08:22:00 -0700 (PDT) MIME-Version: 1.0 References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> In-Reply-To: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> From: Brian Campbell Date: Thu, 4 Apr 2019 09:21:33 -0600 Message-ID: To: George Fletcher Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000007b6cd80585b5ee0a" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:22:05 -0000 --0000000000007b6cd80585b5ee0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, OpenID.Core isn't the right reference for `aud`. https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of `aud` which should be the reference and this document can provide additional specifics for the given application. On Thu, Apr 4, 2019 at 8:07 AM George Fletcher wrote: > Another comment... > > aud REQUIRED - as defined in section 2 of [OpenID.Core ]. = See > Section 3 for indications on how an authorization server shou= ld > determine the value of aud depending on the request. [Note: some > vendors seem to rely on resource aliases. If we believe this to > be a valuable feature, here's some proposed language: The aud > claim MAY include a list of individual resource indicators if they > are all aliases referring to the same requested resource known by > the authorization server. ] > > > > I don't think OpenID.Core Section 3 is the correct reference for > determining the 'aud' value. The issue here is that the 'aud' of the > id_token is the recipient of the id_token (i.e. the client). However, for > access_tokens the 'aud' value should be the resource service that will > receive the access_token. There is no existing guidance for this and we > should provide such guidance as this is "kind of new" for OAuth2 (from an > explicit specification perspective). > > Also, there is the concept of 'azp' from the id_token which amounts to > "who's allowed to present this token" which might be interesting from the > case where one entity obtains the token, and gives it to another entity t= o > present. Not sure if we want to include this concept or not. > > Finally, I think we may need some best practice around how the concept of > audience and resource should be managed. For instance... > > If the request does not include a resource parameter, the > authorization server MUST use in the aud claim a default resource > indicator. If a scope parameter is present in the request, the > authorization server SHOULD use it to infer the value of the default > resource indicator to be used in the aud claim. > > > I think for most implementations this would amount to... define an > audience that covers all the resource services where the access token can > be returned and set that as the audience (e.g. urn:x-mydomain:apis). Whic= h > is perfectly legal but maybe not in the spirit of the spec:) I am receivi= ng > feedback from developers that binding access tokens narrowly to the > resource where they will be presented is concerning from a chattiness > perspective (latency issues) and general load on the deployed AS > infrastructure. > > On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a= _jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > V. > > _______________________________________________ > 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._ --0000000000007b6cd80585b5ee0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, OpenID.Core isn't the right reference for `aud`. https://tools.ietf.o= rg/html/rfc7519#section-4.1.3 is the definition of `aud` which should b= e the reference and this document can provide additional specifics for the = given application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletche= r <gffletch=3D40aol.com@dmar= c.ietf.org> wrote:
=20 =20 =20
Another comment...

   aud  REQUIRED - as=
 defined in section 2 of [OpenID.Core].  See
      Section 3 for indications on ho=
w an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the '= aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the reso= urce service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which = might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request doe=
s not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:= 29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

<= /fieldset> 
_____________=
__________________________________
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. --0000000000007b6cd80585b5ee0a-- From nobody Thu Apr 4 08:26:44 2019 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 50DA81205D1 for ; Thu, 4 Apr 2019 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 BQp9zxMb3PS0 for ; Thu, 4 Apr 2019 08:26:39 -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 08795120443 for ; Thu, 4 Apr 2019 08:26:39 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id s7so2287212iom.12 for ; Thu, 04 Apr 2019 08:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cDlgRjcwgjyGg5q8518JB33bX7iTIhqgdOz4s5eFzr8=; b=QyS6aeXQOhSvUYfV7OdQE70EmQypN27rxMblGWwnwP2sS+2Hae9vvr2lER+hHxrAoL vaCtl8xuHzOMXCdIi4BjQTYtxgpokK7ABAJRV0dQqElg9BVI/DXLGNleLYPYhO/H/zM/ PrVGfNVErqX/R8f08jTDDyHtzqHlWUe//pEc8= 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=cDlgRjcwgjyGg5q8518JB33bX7iTIhqgdOz4s5eFzr8=; b=FowdRjSSkqwQw2UqpopTzqzAtNMb2pmjJUY5ab4baRXRRv3Ad+kmu7vpBLhN71+Pkw YoSW/9HwbSVNit5hKAzEGKz+EqhJhV1lgS5l/F88+DKhOmjGXSYlYgn2266hz/SG5VWX S/vQw9OiE7t7PFuUJYGz97PoM95wvHRQCYdF9FiVj3/7kafK0O1IWfFM78nlo+N/Wve1 YymiILTVsPPuoQhBpYdyvpW+vGOs82+iFVsiuKmfzTOK063BNRuilMOlYgMrtpRWuRmy Fmo7b/n6HjofTJiyo4V+IqtfyNfNWIyXHj2lfNGVqG8y5scf/oFBjyt6HusHHbAYaton aPxA== X-Gm-Message-State: APjAAAVmDrW2X8B2+P0TZf0avftLu/kFJ/AER+x4mmqDOI3EIrzJJWuA EV0cHIm+VBmiE3J6DoWky8rD8JTXcH5bx3OcppueYl9nBBnrRqSgpArJHohn2fJl2I1PotUDnzN EbrG+nAv0A9I3wg== X-Google-Smtp-Source: APXvYqyPHqCmbBt5njVBo48ocSH/5U5r2qi2uQ6AXmfnx/OoTYyDIIgnz8yMg16wXdqlCBlNb/tNXxdcQIY1tGfgRhc= X-Received: by 2002:a5d:81c2:: with SMTP id t2mr1607697iol.183.1554391598184; Thu, 04 Apr 2019 08:26:38 -0700 (PDT) MIME-Version: 1.0 References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> In-Reply-To: From: Brian Campbell Date: Thu, 4 Apr 2019 09:26:11 -0600 Message-ID: To: George Fletcher Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000000d59b10585b5ff58" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:26:42 -0000 --0000000000000d59b10585b5ff58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The same is true for most of the other main claims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC. On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell wrote: > Yeah, OpenID.Core isn't the right reference for `aud`. > https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of > `aud` which should be the reference and this document can provide > additional specifics for the given application. > > On Thu, Apr 4, 2019 at 8:07 AM George Fletcher 40aol.com@dmarc.ietf.org> wrote: > >> Another comment... >> >> aud REQUIRED - as defined in section 2 of [OpenID.Core ].= See >> Section 3 for indications on how an authorization server sho= uld >> determine the value of aud depending on the request. [Note: some >> vendors seem to rely on resource aliases. If we believe this to >> be a valuable feature, here's some proposed language: The aud >> claim MAY include a list of individual resource indicators if they >> are all aliases referring to the same requested resource known by >> the authorization server. ] >> >> >> >> I don't think OpenID.Core Section 3 is the correct reference for >> determining the 'aud' value. The issue here is that the 'aud' of the >> id_token is the recipient of the id_token (i.e. the client). However, fo= r >> access_tokens the 'aud' value should be the resource service that will >> receive the access_token. There is no existing guidance for this and we >> should provide such guidance as this is "kind of new" for OAuth2 (from a= n >> explicit specification perspective). >> >> Also, there is the concept of 'azp' from the id_token which amounts to >> "who's allowed to present this token" which might be interesting from th= e >> case where one entity obtains the token, and gives it to another entity = to >> present. Not sure if we want to include this concept or not. >> >> Finally, I think we may need some best practice around how the concept o= f >> audience and resource should be managed. For instance... >> >> If the request does not include a resource parameter, the >> authorization server MUST use in the aud claim a default resource >> indicator. If a scope parameter is present in the request, the >> authorization server SHOULD use it to infer the value of the default >> resource indicator to be used in the aud claim. >> >> >> I think for most implementations this would amount to... define an >> audience that covers all the resource services where the access token ca= n >> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Whi= ch >> is perfectly legal but maybe not in the spirit of the spec:) I am receiv= ing >> feedback from developers that binding access tokens narrowly to the >> resource where they will be presented is concerning from a chattiness >> perspective (latency issues) and general load on the deployed AS >> infrastructure. >> >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >> >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions!). >> >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> V. >> >> _______________________________________________ >> 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 >> > --=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._ --0000000000000d59b10585b5ff58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The same is true for most of the other ma= in claims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519= not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell <bcampbell@pingidentity.com>= ; wrote:
Yeah, OpenID.Core isn't the right reference for `aud`. https://to= ols.ietf.org/html/rfc7519#section-4.1.3 is the definition of `aud` whic= h should be the reference and this document can provide additional specific= s for the given application.

On Thu, Apr 4, 2019 at 8:07 AM Geor= ge Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Another comment...

   aud  REQUIRED - as defined in section 2 of [OpenID.Core=
].  See
      Section 3 for indications on ho=
w an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the '= aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the reso= urce service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which = might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request does not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

_______________________________________________
OAuth mailing list
OAuth@iet=
f.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. --0000000000000d59b10585b5ff58-- From nobody Thu Apr 4 08:39:17 2019 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 EDC1D1206E8 for ; Thu, 4 Apr 2019 08:39:12 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zmartzone-eu.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 oZvl83xRmfZI for ; Thu, 4 Apr 2019 08:39:10 -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 2C4421206C7 for ; Thu, 4 Apr 2019 08:39:07 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id d13so3758086qth.5 for ; Thu, 04 Apr 2019 08:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xw5BCH7aW7ombTcPgm3fqwSrJQRUsvdOjamFhB3dCWU=; b=YnSIZNJUP7N3JbzzBqn5A2PFPtIAlJqQycpwqDroD2brfeiIQrz9S09Ahb3zPWRVW/ h4EiN7zU7h0f3MEwEiS20W1YTzKAvZl+6x0h6Fu24esrj6crjDq/5sL4WkSeqN9V2HGX t7J3rBiY6W8iN9sZeOAgm6boqQRV9ylXNfdEx+VX0ggU+UAsW7jEHplW9p45GEHiSKlM qcWpKp+SZYd7J9L4WHoi9RGR4Xfk943iXezwgZfiXSSPqUv0VxLxf/hoe+vA7luwGuBC 6Iv7/x14nPrBAvEMn7D0g6bzA/wB0EoKjy1jpTaUVgd8n5H8+TAxJJajMx8wFMJ3rzEN z1Gg== 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=Xw5BCH7aW7ombTcPgm3fqwSrJQRUsvdOjamFhB3dCWU=; b=JxeSSGEwo+IGUYlbO/qIQDyx3h+7ip8CCAa2K5O2JOO+VpIWJYMkywsjeLTWee8ovU hp6a1y3QBBfgPLisLbpBKLktTY8cn28xvBhpwbuE+S5rJnEDPLybDJD0q+t96JleYsQN KtPwz3dR7yNrM7EI3cPSC/i3gn9+kSPjTdgPfkXPGslUCxTNeDQQfyO5v3dxyEV+qK8U SK9aUyV22h4axqx2rJZCSMtGG2tr+12it9WCLiCXaTaHKeaCOe9MxAXOf7Al/0rsimMD GjB9YI90N02mU18obAVa82iVB7yiLUdCszBXP7MAdyYzNQ8z8YUOnjuZq46+Vg6TYSoA AaIA== X-Gm-Message-State: APjAAAWvSGKRZctYolW5ctgK+dieeQBcrnqTmSyMMWfqwJ0eHQxMyeXX /F/fJdOF0zOUhKyn5x2dbXqxMA8avuE/8cCpUpymhIal X-Google-Smtp-Source: APXvYqynzei6JE/qfuvhCQT8czlW1U5dMftMBvRUlLhoRQp7A7azEEAZY/lmI/V8iSHG234y43AeyrS4QIw4hS7+BZE= X-Received: by 2002:aed:2307:: with SMTP id h7mr5796322qtc.87.1554392346058; Thu, 04 Apr 2019 08:39:06 -0700 (PDT) MIME-Version: 1.0 References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> In-Reply-To: From: Hans Zandbelt Date: Thu, 4 Apr 2019 17:38:54 +0200 Message-ID: To: Brian Campbell Cc: George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a0f5a50585b62b10" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:39:16 -0000 --000000000000a0f5a50585b62b10 Content-Type: text/plain; charset="UTF-8" agreed but it (i.e. "sub") also brings us back to where we started Hans. On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell wrote: > The same is true for most of the other main claims too - iss, exp, aud, > sub, iat, etc.. They are defined in RFC 7519 not OIDC. > > On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell > wrote: > >> Yeah, OpenID.Core isn't the right reference for `aud`. >> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of >> `aud` which should be the reference and this document can provide >> additional specifics for the given application. >> >> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher > 40aol.com@dmarc.ietf.org> wrote: >> >>> Another comment... >>> >>> aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See >>> Section 3 for indications on how an authorization server should >>> determine the value of aud depending on the request. [Note: some >>> vendors seem to rely on resource aliases. If we believe this to >>> be a valuable feature, here's some proposed language: The aud >>> claim MAY include a list of individual resource indicators if they >>> are all aliases referring to the same requested resource known by >>> the authorization server. ] >>> >>> >>> >>> I don't think OpenID.Core Section 3 is the correct reference for >>> determining the 'aud' value. The issue here is that the 'aud' of the >>> id_token is the recipient of the id_token (i.e. the client). However, for >>> access_tokens the 'aud' value should be the resource service that will >>> receive the access_token. There is no existing guidance for this and we >>> should provide such guidance as this is "kind of new" for OAuth2 (from an >>> explicit specification perspective). >>> >>> Also, there is the concept of 'azp' from the id_token which amounts to >>> "who's allowed to present this token" which might be interesting from the >>> case where one entity obtains the token, and gives it to another entity to >>> present. Not sure if we want to include this concept or not. >>> >>> Finally, I think we may need some best practice around how the concept >>> of audience and resource should be managed. For instance... >>> >>> If the request does not include a resource parameter, the >>> authorization server MUST use in the aud claim a default resource >>> indicator. If a scope parameter is present in the request, the >>> authorization server SHOULD use it to infer the value of the default >>> resource indicator to be used in the aud claim. >>> >>> >>> I think for most implementations this would amount to... define an >>> audience that covers all the resource services where the access token can >>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which >>> is perfectly legal but maybe not in the spirit of the spec:) I am receiving >>> feedback from developers that binding access tokens narrowly to the >>> resource where they will be presented is concerning from a chattiness >>> perspective (latency issues) and general load on the deployed AS >>> infrastructure. >>> >>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>> >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT for >>> their access token. The intent and scenarios addressed by those solutions >>> are mostly the same across vendors, but the syntax and interpretations in >>> the implementations are different enough to prevent developers from reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YOU >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a note and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the process. >>> This is an amazing community. >>> V. >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://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.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000a0f5a50585b62b10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
agreed but it (i.e. "sub") also brings us b= ack to where we started

Hans.

On Thu, Apr 4, 2019 = at 5:27 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
The same is true for most of the other main claims too - iss, e= xp, aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.
<= /div>
O= n Thu, Apr 4, 2019 at 9:21 AM Brian Campbell <bcampbell@pingidentity.com> wr= ote:
Yeah, OpenID.Core isn't the right reference for `aud`. https://tools.= ietf.org/html/rfc7519#section-4.1.3 is the definition of `aud` which sh= ould be the reference and this document can provide additional specifics fo= r the given application.

On Thu, Apr 4, 2019 at 8:07 AM George F= letcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Another comment...

   aud  REQUIRED - as defined in section 2=
 of [OpenID.Core].  See
      Section 3 for indications on ho=
w an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the '= aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the reso= urce service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which = might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request does not include a resou=
rce parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:29 PM, Vittorio Berto= cci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

__________________________________=
_____________
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 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


--
--000000000000a0f5a50585b62b10-- From nobody Thu Apr 4 08:46:40 2019 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 1D6551200A0 for ; Thu, 4 Apr 2019 08:46:38 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fb6ytEXGMp2c for ; Thu, 4 Apr 2019 08:46:34 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 6920612007A for ; Thu, 4 Apr 2019 08:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554392793; bh=ePPihOvoDvd28LQeoJmUBFQmd2t6yZffMk0+xdf7xbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qJKN2wpPGaXdzgv5H3jHm7qxj/fa6X7D3fNJKuWej2pKjEsWQkr6vjA5iG8ZHPVq+yYqwjZUuM9OJtGwJMBgvtc8IpnjapDPjNSmgQLBkqwui3u0Mo24Q95TFtUAy6tn1x4ziQuX7wF8pwZjK1f+xJl2Ll4bbF1vqMX+fWXacKBMICXDjxV56f7Dew4ZjWKmLNPVdKuCRfquaaZzzuPlZAyJyzIC3/7tiNw1+KuZYLDzwxvpOojcU11DwChEvASa3WZzzSDB16HfE8Ku4bfumrcrKX4DibFIBhMDpklRyT2quAIjxNPyQY3AevfxGnxAUbHBtWVReYFRt3WZ4QlvSA== X-YMail-OSG: 4wnY5WcVM1mChTd5_n_HcIup.znIEQXIpXHsU0ETiDxKtCqsSQ8frA47EU0GlmT K6GG1v3chSiEoYxT2DYe1eZ77u2NaA0e0ACrG1U0rrqmtorGDN.gmvwlAVdFqw46dG206ZeU4nYu nmmcC.mZdW7pqWxEeYV_RTD7KUvOCiozM.X1_90V2R4yK_yLaVv1V.qBLK_g5lTnQIJUFdwU8knD 3Xbksb1J3u14dlpDdcE43jG9C0giBvwT1cJ4qFO3e1E9WwdcquJ5VkRZf.WePPl1n3LkyXF_jHwd i1BUbgmPupjWsdmlM70OEGGGUxCjbBF3GIGshNiiqOmfn5gu1P21Abk1w2lX8o9s50gsU8p4t05u b6DJ9jx2zsJE0GTUrz_mqBHbKXBCI7Cts0XIC0mEaDPpt6rxfe1_qmCn.ssW5TXKsFidQV8I9F6_ 0Iba3x9sNbGOcCYSEzn08nMVdWSYkSmD2P6bpX14gt7vEIg.NYdJiGjCTeTVC3jfzUcKZ.cdCgdy AUTbC3.PHvFZmHtP2OQe4E2dvZaXcjG6FTM0v8dU675fPMKPNTuojOQrIYvFZZcC72IQhjlbx8Hk rYpsq44TH5FEgIkXOhrD0mU2IScEicsUL9bOSJmZskVC9P4MX9hWbahPY90j2mpPrg96UoCYpX1M G1rMYrFiVmF1I3Lj5mnB7aEAVjLNQ9Y8TW11sxDNC93cqw01lV57kivdsoBWH3DcQdWg4rf1PM2o OiqStbPNe32Z2Z_IBrnY15XeJGIHuUjThd5rIBkN740uC4b9UzQ_I1D04U64r3wUfwNL9eEHoqX4 lRUn7fzQRCprXF2hnynaKTAcANqo40qIxIKQHPcOZ.lyJ5JiJeWcqtMX7Zm5mO74bppviCmNqHqe 3boEBnQ2_V_k0jND8pc2xbAZjPAbfQRn5otlhg4JADma4dKrz8DskmLZuCB92.YQ_kIumDoo4e4q ccqTqu6D7N3pzAu59uvyPzSEADF1hZBS8XsvB.y_.pDbn97L2EPr57h65EvaoT4a7_jxhhHAb0.s nv5dGYkSViyEbOdCaugrPBsIn5mMvQAotLR6yxEfu6pbl8wr.3ACCq9Inczs3iZeFyV.Qd7pzECk - Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 15:46:33 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ff060856b63be485e8bbf865c0ef0668; Thu, 04 Apr 2019 15:46:30 +0000 (UTC) To: Hans Zandbelt , Brian Campbell Cc: IETF oauth WG References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 4 Apr 2019 11:46:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFB07131BBF6F4E1F5AECEF5" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:46:38 -0000 This is a multi-part message in MIME format. --------------EFB07131BBF6F4E1F5AECEF5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit :) The more I think about 'sub' the more I don't think is should mean "user". What about an IoT device? To me it feels like 'sub' should be what 7519 states, the subject or principal of the token. In some cases, that is quite legitimately the "client" or "machine". Changing that semantic seems bad. If a developer needs to know whether this JWT is about a "human" or not, that's something else entirely and could have it's own claim. On 4/4/19 11:38 AM, Hans Zandbelt wrote: > agreed but it (i.e. "sub") also brings us back to where we started > > Hans. > > On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell > > wrote: > > The same is true for most of the other main claims too - iss, exp, > aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC. > > On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell > > > wrote: > > Yeah, OpenID.Core isn't the right reference for `aud`. > https://tools.ietf.org/html/rfc7519#section-4.1.3 is the > definition of `aud` which should be the reference and this > document can provide additional specifics for the given > application. > > On Thu, Apr 4, 2019 at 8:07 AM George Fletcher > > wrote: > > Another comment... > > aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See > Section 3 for indications on how an authorization server should > determine the value of aud depending on the request. [Note: some > vendors seem to rely on resource aliases. If we believe this to > be a valuable feature, here's some proposed language: The aud > claim MAY include a list of individual resource indicators if they > are all aliases referring to the same requested resource known by > the authorization server. ] > > > > I don't think OpenID.Core Section 3 is the correct > reference for determining the 'aud' value. The issue here > is that the 'aud' of the id_token is the recipient of the > id_token (i.e. the client). However, for access_tokens the > 'aud' value should be the resource service that will > receive the access_token. There is no existing guidance > for this and we should provide such guidance as this is > "kind of new" for OAuth2 (from an explicit specification > perspective). > > Also, there is the concept of 'azp' from the id_token > which amounts to "who's allowed to present this token" > which might be interesting from the case where one entity > obtains the token, and gives it to another entity to > present. Not sure if we want to include this concept or not. > > Finally, I think we may need some best practice around how > the concept of audience and resource should be managed. > For instance... > > If the request does not include a resource parameter, the > authorization server MUST use in the aud claim a default resource > indicator. If a scope parameter is present in the request, the > authorization server SHOULD use it to infer the value of the default > resource indicator to be used in the aud claim. > > I think for most implementations this would amount to... > define an audience that covers all the resource services > where the access token can be returned and set that as the > audience (e.g. urn:x-mydomain:apis). Which is perfectly > legal but maybe not in the spirit of the spec:) I am > receiving feedback from developers that binding access > tokens narrowly to the resource where they will be > presented is concerning from a chattiness perspective > (latency issues) and general load on the deployed AS > infrastructure. > > On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >> Dear all, >> I just submitted a draft describing a JWT profile for >> OAuth 2.0 access tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll >> be presenting remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are >> interested in how this doc came to be. The trajectory it >> followed is somewhat unusual. >> >> * Despite OAuth2 not requiring any specific format for >> ATs, through the years I have come across multiple >> proprietary solution using JWT for their access >> token. The intent and scenarios addressed by those >> solutions are mostly the same across vendors, but the >> syntax and interpretations in the implementations are >> different enough to prevent developers from reusing >> code and skills when moving from product to product. >> * I asked several individuals from key products and >> services to share with me concrete examples of their >> JWT access tokens (THANK YOU Dominick Baier >> (IdentityServer), Brian Campbell (PingIdentity), >> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for >> the tokens and explanations!). >> I studied and compared all those instances, >> identifying commonalities and differences. >> * I put together a presentation summarizing my findings >> and suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx >> Filip! >> * The presentation was followed up by 1.5 hours of >> unconference discussion, which was incredibly >> valuable to get tight-loop feedback and incorporate >> new ideas. John Bradley, Brian Campbell Vladimir >> Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes >> Tschofenig were all there and contributed generously >> to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the >> discussion and didn't get credited in the draft, my >> apologies: please send me a note and I'll make things >> right at the next update. >> * On my flight back I did my best to incorporate all >> the ideas and feedback in a draft, which will be >> discussed at IETF104 tomorrow. Rifaat, Hannes and >> above all Brian were all super helpful in negotiating >> the mysterious syntax of the RFC format and >> submission process. >> >> I was blown away by the availability, involvement and >> willingness to invest time to get things right that >> everyone demonstrated in the process. This is an amazing >> community. >> V. >> >> _______________________________________________ >> 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./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu --------------EFB07131BBF6F4E1F5AECEF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit :)

The more I think about 'sub' the more I don't think is should mean "user". What about an IoT device? To me it feels like 'sub' should be what 7519 states, the subject or principal of the token. In some cases, that is quite legitimately the "client" or "machine". Changing that semantic seems bad. If a developer needs to know whether this JWT is about a "human" or not, that's something else entirely and could have it's own claim.
On 4/4/19 11:38 AM, Hans Zandbelt wrote:
agreed but it (i.e. "sub") also brings us back to where we started

Hans.

On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
The same is true for most of the other main claims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
Yeah, OpenID.Core isn't the right reference for `aud`. https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of `aud` which should be the reference and this document can provide additional specifics for the given application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:
Another comment...

   aud  REQUIRED - as defined in section 2 of [OpenID.Core].  See
      Section 3 for indications on how an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the 'aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the resource service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request does not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.

_______________________________________________
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._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--

--------------EFB07131BBF6F4E1F5AECEF5-- From nobody Thu Apr 4 08:47:27 2019 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 3F8531200A0 for ; Thu, 4 Apr 2019 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 fK6rZxS8S0Nv for ; Thu, 4 Apr 2019 08:47:22 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-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 178AA12007A for ; Thu, 4 Apr 2019 08:47:22 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id f22so4463819ita.3 for ; Thu, 04 Apr 2019 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9/Z93dXcuH+mVbTNw+z/C8OWyvUod9ncrOfV7KGxIGM=; b=hbk6YMLqI9PSQCnO4jlnoiR8gPxpu63VUXgHoMKoOI6g3UQmdCyHPXBPZuZSm/aj9s J9fQ/OVIgys7p+TR/YM62dU4hGYWfCIqgNT8CoyqKuYOxWVeXjhBBfDRARHN1g1tJyVt 0e1wtZ7kstmlparsmDtfOPpS7qAn4Pg6/ciXs= 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=9/Z93dXcuH+mVbTNw+z/C8OWyvUod9ncrOfV7KGxIGM=; b=jZMmlFmS7V11U4SNB1i4AVWFr0u6GHmkhKC2aDOsOOklksuR60IOZkK+kr1Xr+xa8x DqDCNOjx8Y4xTvgXOeMLWdozkSNj9GtTyWCbK03c6nOjE6r+nlc3Bwj0xG9vqLRvsWXz XrhX0vpTGvGs8hIYMe7XUc8eAMmyvjlhhVpooZdsoedx/KtWQFqG3peD64G78DgXhRWx sTO9XVwjKMxz0DHuvcy0RBBMep7+hkQsMzYA3y5e1uCghHqL05CsP6YLZPmUgMYvptQT 2WbTiIKXNxvGoEROAPJClvzHGCvailekgfPHRFxuWl/1/Zx4728X0YUovpbg+yRwEdg2 2Mjw== X-Gm-Message-State: APjAAAXFabK3K+aJ/yT4uIa2B6tuD23tD+M0FFLHkxEVvMsVxZs/m/aK lh6kOFeuwAKSNxjAmUVU7HWsDq2k6beiKjv1pfmRYNBTkkLQ+lEiwMBBcjU4NmEOUNP7p2WqUBj QSTMZEDO0AgKZJQ== X-Google-Smtp-Source: APXvYqwgKoRwVARR1KiXrt+hyaXiItGf5cwZhYS6T9TUFHAjn/Y6emGYku4VsWmW5FrBgl3oLjhn7GrQVxxpD8ni7iI= X-Received: by 2002:a05:6638:25a:: with SMTP id w26mr5478737jaq.112.1554392841174; Thu, 04 Apr 2019 08:47:21 -0700 (PDT) MIME-Version: 1.0 References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> In-Reply-To: From: Brian Campbell Date: Thu, 4 Apr 2019 09:46:54 -0600 Message-ID: To: Hans Zandbelt Cc: George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000023df150585b64905" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:47:25 -0000 --00000000000023df150585b64905 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure I understand what you mean but this document would reference the RFC 7519 claims and, if needed, futher profile their usage for access tokens. On Thu, Apr 4, 2019 at 9:39 AM Hans Zandbelt wrote: > agreed but it (i.e. "sub") also brings us back to where we started > > Hans. > > On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> The same is true for most of the other main claims too - iss, exp, aud, >> sub, iat, etc.. They are defined in RFC 7519 not OIDC. >> >> On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell >> wrote: >> >>> Yeah, OpenID.Core isn't the right reference for `aud`. >>> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of >>> `aud` which should be the reference and this document can provide >>> additional specifics for the given application. >>> >>> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher >> 40aol.com@dmarc.ietf.org> wrote: >>> >>>> Another comment... >>>> >>>> aud REQUIRED - as defined in section 2 of [OpenID.Core = ]. See >>>> Section 3 for indications on how an authorization server s= hould >>>> determine the value of aud depending on the request. [Note: som= e >>>> vendors seem to rely on resource aliases. If we believe this to >>>> be a valuable feature, here's some proposed language: The aud >>>> claim MAY include a list of individual resource indicators if th= ey >>>> are all aliases referring to the same requested resource known b= y >>>> the authorization server. ] >>>> >>>> >>>> >>>> I don't think OpenID.Core Section 3 is the correct reference for >>>> determining the 'aud' value. The issue here is that the 'aud' of the >>>> id_token is the recipient of the id_token (i.e. the client). However, = for >>>> access_tokens the 'aud' value should be the resource service that will >>>> receive the access_token. There is no existing guidance for this and w= e >>>> should provide such guidance as this is "kind of new" for OAuth2 (from= an >>>> explicit specification perspective). >>>> >>>> Also, there is the concept of 'azp' from the id_token which amounts to >>>> "who's allowed to present this token" which might be interesting from = the >>>> case where one entity obtains the token, and gives it to another entit= y to >>>> present. Not sure if we want to include this concept or not. >>>> >>>> Finally, I think we may need some best practice around how the concept >>>> of audience and resource should be managed. For instance... >>>> >>>> If the request does not include a resource parameter, the >>>> authorization server MUST use in the aud claim a default resource >>>> indicator. If a scope parameter is present in the request, the >>>> authorization server SHOULD use it to infer the value of the defaul= t >>>> resource indicator to be used in the aud claim. >>>> >>>> >>>> I think for most implementations this would amount to... define an >>>> audience that covers all the resource services where the access token = can >>>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). W= hich >>>> is perfectly legal but maybe not in the spirit of the spec:) I am rece= iving >>>> feedback from developers that binding access tokens narrowly to the >>>> resource where they will be presented is concerning from a chattiness >>>> perspective (latency issues) and general load on the deployed AS >>>> infrastructure. >>>> >>>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>>> >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt= / >>>> . >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JW= T for >>>> their access token. The intent and scenarios addressed by those sol= utions >>>> are mostly the same across vendors, but the syntax and interpretati= ons in >>>> the implementations are different enough to prevent developers from= reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK Y= OU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens an= d >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_= -_a_jwt_profile_for_ats.pptx >>>> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedbac= k and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvi= nov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a no= te and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. R= ifaat, >>>> Hannes and above all Brian were all super helpful in negotiating th= e >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the proc= ess. >>>> This is an amazing community. >>>> V. >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://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 f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --=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._ --00000000000023df150585b64905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure I understand what you mean but this docum= ent would reference the RFC 7519 claims and, if needed, futher profile thei= r usage for access tokens.

On Thu, Apr 4, 2019 at 9:39 AM Hans Zandbelt = <hans.zandbelt@zmartzone.e= u> wrote:
agreed but it (i.e. "sub") also brings us = back to where we started

Hans.

On Thu, Apr 4, 2019 = at 5:27 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= > wrote:
The same is true for most of the other main c= laims too - iss, exp, aud, sub, iat, etc.. They are defined in RFC 7519 not= OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell <bcampbell@pingiden= tity.com> wrote:
Yeah, OpenID.Core isn't the right reference for `aud`. = https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definitio= n of `aud` which should be the reference and this document can provide addi= tional specifics for the given application.

On Thu, Apr 4, 2019 = at 8:07 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Another comment...

   aud  REQUIR=
ED - as defined in section 2 of [OpenID.Core].  See
      Section 3 for indications on ho=
w an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the '= aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the reso= urce service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which = might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the requ=
est does not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/2= 4/19 7:29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

______=
_________________________________________
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 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. --00000000000023df150585b64905-- From nobody Thu Apr 4 08:51:01 2019 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 E73D8120118 for ; Thu, 4 Apr 2019 08:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 vxllWwo1dNDi for ; Thu, 4 Apr 2019 08:50:54 -0700 (PDT) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 779FA12007A for ; Thu, 4 Apr 2019 08:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554393053; bh=Fuxka0SlO1tuZMxb0Pmu673Lujemo4c3gGounXaVLNg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ZfU03DvknaYmKdkS60tq2JiA3a1Fe7t6IRJi1JnCVEW2wmMsaWJw7TUkOr9jUvcCvtIw2QJJ47Xef1+BrpmGLRcx4BH3d7oFPJj9k6mR+U8wfGNHarAte9tQxdS0xPg0tC0bH3/USL8kSHkqsptbO/mAlSz0ZH+0mzN1+wgP36IYX84GRKz6dSakipNdfiH6qFK0Po56geI3o0P15v6xBcqNALpaMDZtxQkhj8CpOwvvdOQ4bVcWnhSsFHO4N26dlccZpbkYVEy8GonDIkAVZUXkwEvYFj9ejqNknqdzdDxaGWUAmVtuWcqfIaZ49QEp548I5pLos9Kc7O893qemqA== X-YMail-OSG: 306pqM4VM1lj9pF22KaErZdcO2qMSmxcG6uA.Av_lP4YbqN4rajHyEFmJrqWvhh LghR66VGjSURAsf5z8hYsWYanKasSHf2rkctHtjZpxsxryEJ0e2VIbs.xoeO2fFlY_0OnIkAxckO 7t5B1akGtZRBI63W4DhIIEFuS.PZceoSpftJ_L9iyNEwkgUCmmsZBRam2tMUx2b7yutUB2geS9LK zHR.wkNo0SKqR6yBLDpVrF2VtZuzPHD7RgQkoTFK9I9iDGGCeXFnQTxLfkO_Ily6wu.kgPQewegq vYxuGVk3oh87IwlKWpeEYj0ziGFHLe.ftxzxiKxSxf_nYu7C_UaNjEZWNExx6NCS5VaCUevbo8vM 62vIA1XQ3CrXFocF1vEeWQ45tcHMXv9jxoW_lpKNerSQFU07TT8Gy8V3LrM4PbryoZH8BRuFy5uj SGdnpuqq6JD8wIViT5gu7wXwDAyjUbpBAiIvHkNOa_KyCsookG0kEC48wDStRSGTZrR5f08O2yxt tS5updaTCv9DxnuEC.fJlT5Y_abnb4Lxt45sd4ec_bQxDiu5UAggE2w7UzN4oyzNhV7tmyCKdp7u MqvXznBDvRa7vQRcCjMMx4XRBHIbk4QB8XqIUI8bfxWh64O3Dx2qAgGIPsTLLT53GPsGOOZ5wHea NV8GRQDUrLaSC83MruJ.AOigIOzzcGevKNx2QFXZUqPh666.AI1RKQdgIbqPMkG02PrIWCK5FInq uTkvwlJkSbxWKjGC.MyrpkWtSPuUfN.GAz7957S1Lx7N56F0ozoPGI51sRQDibaO0VPl1UGX7zIx ovYVPCAneGaeV2XwQgNoHufrAPu6122rqqlQhWveVPgmVFJVhipsB1Q9ihznKB0fmupUSyduMO2h _Y5513OwrS28QVZDMd_.4YOcigbTY7TXi9.vdn5fP8QSDV_ede1e76UleB.xIbaiotH6FO7BP5z0 Mc3Xz5KdclwkulCN3.uNRcZ.EC0DXDBvXrx2Otd0zoSuhcphxgi1p3wRxs_Gpteed4ddv4IwViP. Az3vAoCf6KtxO0SOVKS9us0jWmJ8lYVWwlwOa1KJ4f9esuFaXWE_SXRX6XMymyNcrvfoHNxiSzLN XE.RC5gjJeGIwbg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 15:50:53 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3ed5fa5f13e7aed81dd2f93f7809e1af; Thu, 04 Apr 2019 15:50:50 +0000 (UTC) To: Hans Zandbelt Cc: Vittorio Bertocci , IETF oauth WG References: From: George Fletcher Organization: AOL LLC Message-ID: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> Date: Thu, 4 Apr 2019 11:50:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E2773D1219BE218656E16BC9" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:50:59 -0000 This is a multi-part message in MIME format. --------------E2773D1219BE218656E16BC9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The more I think about this the more I land in the "No" camp. The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required. Thanks, George On 4/3/19 4:56 PM, Hans Zandbelt wrote: > I will argue that in a way such deployments are already broken e.g. in > the typical use case of onboarding client accounts in the same > directory/OU/namespace as user accounts and we don't need to cater for > that. > > Hans. > > On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: > > I agree that this will break a lot of existing flows... especially > those using any form of the client_credentials flow. In that sense > I'm not completely on board yet :) > > On 3/26/19 12:56 PM, Hans Zandbelt wrote: >> great summary! this will hurt quite a few existing m2m >> deployments but I do like the rigidness of it all: it is very >> explicit, cannot misinterpreted and thus prevents failure (which >> is really what Dominick is after); I'm on board >> >> Hans. >> >> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci >> > > wrote: >> >> thank you Steinar and everyone else for the comments on this! >> To summarize the situation so far: Dominick, Steinar, Rob, >> David, Nov, Bertrand recommend using sub only for users. >> Martin would like to have the sub for app only flows as well. >> Hans is neutral. >> That does sound like the sub as user has more consensus, tho >> before changing it I'd wait for the people currently at >> IETF104 to have more time to comment as well. >> Clarification. If the goal is to be able to apply the logic >> "if there's a sub, it's a user flow", we have to explicitly >> disallow (MUST NOT) the use of sub when that's not the case. >> Are all OK with it? >> >> Dave, the suggestion of having explicit typing for app only >> vs user only is interesting! For the purpose of putting >> together an interoperable profile, tho, I would suggest we >> table it for v1 in the interest of getting to something easy >> to adopt (hence with small delta vs existing implementations) >> faster. >> >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem >> > wrote: >> >> Hi Vittorio, we  (the national federation-gateway for the >> health services in norway - "HelseID")  think his is a >> really valuable initiative! >> We also agree with Dominick concerning definition of the >> "sub" claim. >> >> Steinar >> >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier >> > >: >> >> From an access token consumer (aka API) developer >> point of view, I prefer this logic >> >> "If sub is present - client acts on behalf of a user, >> if not - not." >> >> Anything more complicated has a potential of going wrong. >> >> >> On 26. March 2019 at 01:34:53, Nov Matake >> (matake@gmail.com ) wrote: >> >>> Hi Vittorio, >>> >>> Yeah, I’m concerning user & client ids collision. >>> I haven’t seen such implementations, but user-select >>> username as sub, or incremental integer as sub & >>> client_id will be easily collide. >>> >>> If you can enforce collision resistant IDs between >>> user & client instances, it’ll works fine. I feel >>> its overkill though. >>> >>> Sent from my iPhone >>> >>> On Mar 26, 2019, at 8:51, Vittorio Bertocci >>> > wrote: >>> >>>> Hey Nov, Dominick, Hans- >>>> thanks for the comments. That was an area I was >>>> expecting to cause more discussion, and I am glad >>>> we are having this opportunity to clarify. >>>> The current language in the draft traces the >>>> etymology of sub to OpenID Connect core, hence >>>> Dominick observation is on point. However in the >>>> description I express something in line with 7519, >>>> which was in fact my intent. >>>> >>>> The idea was to provide an identifier of the >>>> calling subject that is guaranteed to be present in >>>> all cases- this would allow an SDK developer to use >>>> the same code for things like lookups and >>>> membership checks regardless of the nature of the >>>> caller (user in a delegated case, app in app-only >>>> grants). The information to discriminate between >>>> user and app callers is always available in the >>>> token (say, the caller is a user if sub!=client_id, >>>> where client_id is always guaranteed to be present >>>> as well) hence there's no loss in expressive power, >>>> should that difference be relevant for the resource >>>> server. >>>> >>>> Dominick, Hans- I probably missed the security >>>> issue you guys are thinking of in this case. Of >>>> course, if this would introduce a risk I completely >>>> agree it should be changed- I'd just like to >>>> understand better the problem. Could you expand it >>>> in a scenario/use case to clarify the risk? >>>> Nov- playing this back: is the concern that a user >>>> and a client might have the same identifier within >>>> an IDP? When using collision resistant IDs, as it >>>> is usually the case, that seems to be a remote >>>> possibility- did you stumble in such scenario in >>>> production? >>>> >>>> Thanks >>>> V. >>>> >>>> >>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt >>>> >>> > wrote: >>>> >>>> I believe there are plenty of OAuth 2.0 only >>>> use cases out there... but nevertheless I agree >>>> with the potential confusion and thus security >>>> problems arising from that (though one may >>>> argue the semantics are the same). >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier >>>> >>> > wrote: >>>> >>>> Yes I know - and I think in hindsight it >>>> was a mistake to use the same claim type >>>> for multiple semantics. >>>> >>>> All the “this is OIDC not OAuth” arguments >>>> are making things more complicated than >>>> they need to be - in my experience almost >>>> no-one (that I know) does OIDC only - nor >>>> OAuth only. They always combine it. >>>> >>>> In reality this leads to potential security >>>> problems - this spec has the potential to >>>> rectify the situation. >>>> >>>> Dominick >>>> >>>> On 25. March 2019 at 14:58:56, Hans >>>> Zandbelt (hans.zandbelt@zmartzone.eu >>>> ) wrote: >>>> >>>>> Without agreeing or disagreeing: OIDC does >>>>> not apply here since it is not OAuth and >>>>> an access token is not an id_token. >>>>> The JWT spec says in >>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>>> >>>>> "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" >>>>> >>>>> which kind of spells "client" in case of >>>>> the client credentials grant but I also do >>>>> worry about Resource Servers >>>>> thinking/acting only in terms of users >>>>> >>>>> Hans. >>>>> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick >>>>> Baier >>>> > wrote: >>>>> >>>>> IMHO the sub claim should always refer >>>>> to the user - and nothing else. >>>>> >>>>> OIDC says: >>>>> >>>>> "Subject - Identifier for the End-User >>>>> at the Issuer." >>>>> >>>>> client_id should be used to identify >>>>> clients. >>>>> >>>>> cheers >>>>> Dominick >>>>> >>>>> On 25.. March 2019 at 05:13:03, Nov >>>>> Matake (matake@gmail.com >>>>> ) wrote: >>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> Thanks for the good starting point of >>>>>> standardizing JWT-ized AT. >>>>>> >>>>>> One feedback. >>>>>> The “sub” claim can include 2 types >>>>>> of identifier, end-user and client, >>>>>> in this spec. >>>>>> It requires those 2 types of >>>>>> identifiers to be unique each other >>>>>> in the IdP context. >>>>>> >>>>>> I prefer omitting “sub” claim in >>>>>> 2-legged context, so that no such >>>>>> constraint needed. >>>>>> >>>>>> thanks >>>>>> >>>>>> nov >>>>>> >>>>>>> On Mar 25, 2019, at 8:29, Vittorio >>>>>>> Bertocci >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> I just submitted a draft describing >>>>>>> a JWT profile for OAuth 2.0 access >>>>>>> tokens. You can find it in >>>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>>>>> I have a slot to discuss this >>>>>>> tomorrow at IETF 104 (I'll be >>>>>>> presenting remotely). I look forward >>>>>>> for your comments! >>>>>>> >>>>>>> Here's just a bit of backstory, in >>>>>>> case you are interested in how this >>>>>>> doc came to be. The trajectory it >>>>>>> followed is somewhat unusual. >>>>>>> >>>>>>> * Despite OAuth2 not requiring any >>>>>>> specific format for ATs, through >>>>>>> the years I have come across >>>>>>> multiple proprietary solution >>>>>>> using JWT for their access >>>>>>> token. The intent and scenarios >>>>>>> addressed by those solutions are >>>>>>> mostly the same across vendors, >>>>>>> but the syntax and >>>>>>> interpretations in the >>>>>>> implementations are different >>>>>>> enough to prevent developers >>>>>>> from reusing code and skills >>>>>>> when moving from product to product. >>>>>>> * I asked several individuals from >>>>>>> key products and services to >>>>>>> share with me concrete examples >>>>>>> of their JWT access tokens >>>>>>> (THANK YOU Dominick Baier >>>>>>> (IdentityServer), Brian Campbell >>>>>>> (PingIdentity), Daniel Dobalian >>>>>>> (Microsoft), Karl Guinness >>>>>>> (Okta) for the tokens and >>>>>>> explanations!). >>>>>>> I studied and compared all those >>>>>>> instances, identifying >>>>>>> commonalities and differences. >>>>>>> * I put together a presentation >>>>>>> summarizing my findings and >>>>>>> suggesting a rough interoperable >>>>>>> profile (slides: >>>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>>>>>> >>>>>>> ) - got early feedback from >>>>>>> Filip Skokan on it. Thx Filip! >>>>>>> * The presentation was followed up >>>>>>> by 1.5 hours of unconference >>>>>>> discussion, which was incredibly >>>>>>> valuable to get tight-loop >>>>>>> feedback and incorporate new >>>>>>> ideas. John Bradley, Brian >>>>>>> Campbell Vladimir Dzhuvinov, >>>>>>> Torsten Lodderstedt, Nat >>>>>>> Sakimura, Hannes Tschofenig were >>>>>>> all there and contributed >>>>>>> generously to the discussion. >>>>>>> Thank you!!! >>>>>>> Note: if you were at OSW2019, >>>>>>> participated in the discussion >>>>>>> and didn't get credited in the >>>>>>> draft, my apologies: please send >>>>>>> me a note and I'll make things >>>>>>> right at the next update. >>>>>>> * On my flight back I did my best >>>>>>> to incorporate all the ideas and >>>>>>> feedback in a draft, which will >>>>>>> be discussed at IETF104 >>>>>>> tomorrow. Rifaat, Hannes and >>>>>>> above all Brian were all super >>>>>>> helpful in negotiating the >>>>>>> mysterious syntax of the RFC >>>>>>> format and submission process. >>>>>>> >>>>>>> I was blown away by the >>>>>>> availability, involvement and >>>>>>> willingness to invest time to get >>>>>>> things right that everyone >>>>>>> demonstrated in the process. This is >>>>>>> an amazing community. >>>>>>> V. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>> >>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> | steinar@udelt.no  | >> hei@udelt.no   | +47 955 21 620 | >> www.udelt.no  | >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu --------------E2773D1219BE218656E16BC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com> wrote:
I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org> wrote:
thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.
Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.     

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

<mvh>Steinar</mvh>

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
From an access token consumer (aka API) developer point of view, I prefer this logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

Thanks
V. 


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

Hans.

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
"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"

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.
On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

thanks

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences. 
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
V.
_______________________________________________
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


--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
_______________________________________________
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



--

--------------E2773D1219BE218656E16BC9-- From nobody Thu Apr 4 08:58:49 2019 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 9324A12013C for ; Thu, 4 Apr 2019 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mXOq1ia530Uv for ; Thu, 4 Apr 2019 08:58:38 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 DADC4120118 for ; Thu, 4 Apr 2019 08:58:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FJAgARKaZc/xoBYJlbBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWcqaHESJwqEBGKCaIUxjCQlfoFlhlWPH4FCJQsFGA0JgQKCdkY?= =?us-ascii?q?ChU4iOBIBAQMBAQkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAggMHxE?= =?us-ascii?q?SAQEYAQEBAQIBAQEhJiUDCAULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQc?= =?us-ascii?q?BD64XgS+DdFFBgwINghAPgTCBSoMShleBWD6BEScME4FOSTU+ghpHAQECAQG?= =?us-ascii?q?BJQ0PBghGBoJMMYImA4p2hltQkxM2AwQCAoEng0uCEnqEHIQag0QaggWGFIM?= =?us-ascii?q?xhhyCaYxnhQSBQ4hIg3GBZiIxgSVxRQoFJQFVHYEmKQmCDReBAQEOgm9Og3A?= =?us-ascii?q?jhT8/AQExAQGPR4EfAQE?= X-IPAS-Result: =?us-ascii?q?A2FJAgARKaZc/xoBYJlbBAYcAQEBBAEBBwQBAYFlgWcqa?= =?us-ascii?q?HESJwqEBGKCaIUxjCQlfoFlhlWPH4FCJQsFGA0JgQKCdkYChU4iOBIBAQMBA?= =?us-ascii?q?QkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAggMHxESAQEYAQEBAQIBA?= =?us-ascii?q?QEhJiUDCAULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQcBD64XgS+DdFFBg?= =?us-ascii?q?wINghAPgTCBSoMShleBWD6BEScME4FOSTU+ghpHAQECAQGBJQ0PBghGBoJMM?= =?us-ascii?q?YImA4p2hltQkxM2AwQCAoEng0uCEnqEHIQag0QaggWGFIMxhhyCaYxnhQSBQ?= =?us-ascii?q?4hIg3GBZiIxgSVxRQoFJQFVHYEmKQmCDReBAQEOgm9Og3AjhT8/AQExAQGPR?= =?us-ascii?q?4EfAQE?= X-IronPort-AV: E=Sophos;i="5.60,308,1549926000"; d="asc'?scan'208";a="24249517" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 17:58:33 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlBADQKKZcfRBhWMBbBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWeBEoEDJwqEBGKIGYwkJX6BZYZVjx+BZwsFGA2EAUYChW84EgE?= =?us-ascii?q?BAwEBCQEDAhQBARY6IwyFSgEBAQECAQEBISYlAwgFCwIBCBgqAgIhBgslAgQ?= =?us-ascii?q?OBQ4GB4MHAYFdAw0ID64XgS+ERUGDAg2CEA+BMIFKgxKILz6BEScME4FOSTU?= =?us-ascii?q?+ghpHAQECAQGBJQ0PBghGBoJMMYImA4p2hltQkxM2AwQCAoEng0uCEnqEHIQ?= =?us-ascii?q?ag0QaggWGFIMxhhyCaYxnhQSBQ4w5gWYgMoElcUUKBSUBVR2BJikJgg0XgQE?= =?us-ascii?q?BDoJvToNwI4U/PwECMAEBj0eBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,308,1549926000"; d="asc'?scan'208";a="39624004" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/AES256-SHA; 04 Apr 2019 17:58:31 +0200 Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP11EXC.ads.fraunhofer.de ([10.80.232.42]) with mapi id 14.03.0435.000; Thu, 4 Apr 2019 17:58:30 +0200 From: "Schanzenbach, Martin" To: George Fletcher CC: Hans Zandbelt , Vittorio Bertocci , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU42Wr/thS5xrVIYxSuUg+/ebS0aYc/+GAgABhiACAACYMAIAAiF0AgAACU4CADMLFgIAAAkaAgAE81oCAAAIkgA== Date: Thu, 4 Apr 2019 15:58:29 +0000 Message-ID: <5E94E4DD-4390-47A1-9C3C-44462E354A98@aisec.fraunhofer.de> References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> In-Reply-To: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.80.233.50] x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24526.004 x-tm-as-result: No--41.529100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_6E59DD72-349C-408E-BFD3-8E4A10A247C9"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 15:58:47 -0000 --Apple-Mail=_6E59DD72-349C-408E-BFD3-8E4A10A247C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think what needs to be clarified is whether the "sub" claim should = denote the caller (=3Dclient) or the RO in the case of an JWT AT. RFC 7519 only defines "sub" to be the principal which is the subject of = all claims in the JWT. This means that the AT can contain either claims regarding the client OR = the RO, but not both. (I prefer to use RO instead of user as I think = this a term better used in OIDC). Now, the question is what does an RS need to make an authorisation = decision? Claims about the client or claims about the RO? Since OIDC already has ID Tokens as JWT which have the RO as "sub", = maybe it makes sense to have the client as sub for the AT? If the RS needs claims about the RO in order to do authorization = decisions, maybe it needs to be presented with an ID Token (which would = imply that it is issued with the RS in its aud claim). > On 4. Apr 2019, at 17:50, George Fletcher = wrote: >=20 > The more I think about this the more I land in the "No" camp. >=20 > The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. >=20 > Thanks, > George >=20 > On 4/3/19 4:56 PM, Hans Zandbelt wrote: >> I will argue that in a way such deployments are already broken e.g. = in the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. >>=20 >> Hans. >>=20 >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher = wrote: >> I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) >>=20 >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>> great summary! this will hurt quite a few existing m2m deployments = but I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board >>>=20 >>> Hans. >>>=20 >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = wrote: >>> thank you Steinar and everyone else for the comments on this! >>> To summarize the situation so far: Dominick, Steinar, Rob, David, = Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral. >>> That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. >>> Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >>>=20 >>> Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. >>>=20 >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem = wrote: >>> Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! >>> We also agree with Dominick concerning definition of the "sub" = claim. >>>=20 >>> Steinar >>>=20 >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = : >>> =46rom an access token consumer (aka API) developer point of view, I = prefer this logic >>>=20 >>> "If sub is present - client acts on behalf of a user, if not - not." >>>=20 >>> Anything more complicated has a potential of going wrong. >>>=20 >>>=20 >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>>=20 >>>> Hi Vittorio, >>>>=20 >>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>> I haven=E2=80=99t seen such implementations, but user-select = username as sub, or incremental integer as sub & client_id will be = easily collide. >>>>=20 >>>> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci = wrote: >>>>=20 >>>>> Hey Nov, Dominick, Hans- >>>>> thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >>>>> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >>>>>=20 >>>>> The idea was to provide an identifier of the calling subject that = is guaranteed to be present in all cases- this would allow an SDK = developer to use the same code for things like lookups and membership = checks regardless of the nature of the caller (user in a delegated case, = app in app-only grants). The information to discriminate between user = and app callers is always available in the token (say, the caller is a = user if sub!=3Dclient_id, where client_id is always guaranteed to be = present as well) hence there's no loss in expressive power, should that = difference be relevant for the resource server. >>>>>=20 >>>>> Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >>>>> Nov- playing this back: is the concern that a user and a client = might have the same identifier within an IDP? When using collision = resistant IDs, as it is usually the case, that seems to be a remote = possibility- did you stumble in such scenario in production? >>>>>=20 >>>>> Thanks >>>>> V. >>>>>=20 >>>>>=20 >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = wrote: >>>>> I believe there are plenty of OAuth 2.0 only use cases out = there... but nevertheless I agree with the potential confusion and thus = security problems arising from that (though one may argue the semantics = are the same). >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = wrote: >>>>> Yes I know - and I think in hindsight it was a mistake to use the = same claim type for multiple semantics. >>>>>=20 >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are = making things more complicated than they need to be - in my experience = almost no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >>>>>=20 >>>>> In reality this leads to potential security problems - this spec = has the potential to rectify the situation. >>>>>=20 >>>>> Dominick >>>>>=20 >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu) wrote: >>>>>=20 >>>>>> Without agreeing or disagreeing: OIDC does not apply here since = it is not OAuth and an access token is not an id_token. >>>>>> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>>>>=20 >>>>>> "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" >>>>>>=20 >>>>>> which kind of spells "client" in case of the client credentials = grant but I also do worry about Resource Servers thinking/acting only in = terms of users >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = wrote: >>>>>> IMHO the sub claim should always refer to the user - and nothing = else. >>>>>>=20 >>>>>> OIDC says: >>>>>>=20 >>>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>>=20 >>>>>> client_id should be used to identify clients. >>>>>>=20 >>>>>> cheers >>>>>> Dominick >>>>>>=20 >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) = wrote: >>>>>>=20 >>>>>>> Hi Vittorio, >>>>>>>=20 >>>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>>>=20 >>>>>>> One feedback. >>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of = identifier, end-user and client, in this spec. >>>>>>> It requires those 2 types of identifiers to be unique each other = in the IdP context. >>>>>>>=20 >>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged = context, so that no such constraint needed. >>>>>>>=20 >>>>>>> thanks >>>>>>>=20 >>>>>>> nov >>>>>>>=20 >>>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci = wrote: >>>>>>>>=20 >>>>>>>> Dear all, >>>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>>>>>>>=20 >>>>>>>> Here's just a bit of backstory, in case you are interested in = how this doc came to be. The trajectory it followed is somewhat = unusual. >>>>>>>> =E2=80=A2 Despite OAuth2 not requiring any specific = format for ATs, through the years I have come across multiple = proprietary solution using JWT for their access token. The intent and = scenarios addressed by those solutions are mostly the same across = vendors, but the syntax and interpretations in the implementations are = different enough to prevent developers from reusing code and skills when = moving from product to product. >>>>>>>> =E2=80=A2 I asked several individuals from key products = and services to share with me concrete examples of their JWT access = tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!). >>>>>>>> I studied and compared all those instances, identifying = commonalities and differences. >>>>>>>> =E2=80=A2 I put together a presentation summarizing my = findings and suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. = Thx Filip! >>>>>>>> =E2=80=A2 The presentation was followed up by 1.5 hours = of unconference discussion, which was incredibly valuable to get = tight-loop feedback and incorporate new ideas. John Bradley, Brian = Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes = Tschofenig were all there and contributed generously to the discussion. = Thank you!!! >>>>>>>> Note: if you were at OSW2019, participated in the discussion = and didn't get credited in the draft, my apologies: please send me a = note and I'll make things right at the next update. >>>>>>>> =E2=80=A2 On my flight back I did my best to incorporate = all the ideas and feedback in a draft, which will be discussed at = IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super = helpful in negotiating the mysterious syntax of the RFC format and = submission process. >>>>>>>> I was blown away by the availability, involvement and = willingness to invest time to get things right that everyone = demonstrated in the process. This is an amazing community. >>>>>>>> V. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> hans.zandbelt@zmartzone.eu >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>=20 >>>>>=20 >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> -- >>> Vennlig hilsen >>>=20 >>> Steinar Noem >>> Partner Udelt AS >>> Systemutvikler >>>=20 >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>>=20 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenbach@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 --Apple-Mail=_6E59DD72-349C-408E-BFD3-8E4A10A247C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlymKaUACgkQhDNRMeo9 q/DrfQ//R6rFi3kA1s72aRE9dHL/v36WT2kaFdT6oHhglhy3R+ys257bpdHxQ3vT FaZejcma3ERDrvG8Iug7NNLBR/cnolyjKl79vwBeuOU0bwUJB0HinG1NpsgwWOqW hYYh/It1++twq/yfitNxXzkvLiVViXPXSbh+DDIdW2opNFtVUQh4+qIiU3mFWr8u fGyZVXNXjXmsYVEK+vmRVAieLmybEtIb+zK9xpk6fAicsXhPLOzBIBSzMsN5lbwo 64Bdn5LUNIhaQiO/grF4MDTr6JgZpjVXqGwVO3x18XnA2XFbbnEHRH8V7yKHy99B OTIDaFe+7VZ+HbAKXMw68WujMzVASS7+++X9Txqjleyw09aqN59zqbZ5XLq3Rt6L pEJHZLsBh8S6T6W2oA9LiLXDp1J0bWdm90rypOzdKuXzQ96XTxQW9zDP5aVLCbym 6VUmIcTlF0WNGo3yfxmkyDfEmwmjddaboIONGQ1MgikkwJeqhBAssjtiFolKdS8v UECitVYC2sZLKAa+pOAt+C3p2Y0q6s2xyatCqXoh9DCnd6FEhPDAJkpfhK1nYMxv 7Rn6m+kB5mOtQukEneanQH9h8so2IJ/WG9U4Ord6/u+QC1b2ZiEuMdyUb6JqcW22 sUTr6KjEONxzdsMtby9WmXfiyfm9TKM7qB0i340sFh7Sjbqgj0g= =/fkL -----END PGP SIGNATURE----- --Apple-Mail=_6E59DD72-349C-408E-BFD3-8E4A10A247C9-- From nobody Thu Apr 4 09:30:05 2019 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 8B302120089 for ; Thu, 4 Apr 2019 09:30:04 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zmartzone-eu.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 W9udg4eK327U for ; Thu, 4 Apr 2019 09:30:01 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 75285120117 for ; Thu, 4 Apr 2019 09:29:59 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id g1so2023449qki.5 for ; Thu, 04 Apr 2019 09:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DbnwDr2v6VZh9fSNvVIxIs9JsOx59RdGabp0ckeC1XQ=; b=Z9EeUox5tKCdEsQ/ktxswz1Ag3zh1+83hN1Y4VhPZIAYs4X0fxJojfuOvc+WIynUSa 0E8k0iIXw8z2kOFLm6uSTSg8jAM+O7PeQUuOmVBpMh9tx2OG4/Kq8Ea50tXER0pL0BvV dDa0EThEctHjZ63D4fkm/cVtv7gMb6mrSFw8xEMtsmu1TwO3CRZt5NmC+KlWapEfdWUw ZJx2lVYFinARPLhE1hQPUCv1RtWGb7QsD9xSptvCIeVkaQ2qNyYmPPjEjmuX+ojIZfuD 5jxL21oRAqCrXxnJaFM0XoY1De99yv5poOuQY224+JTrDmw4NgLu1jtIpb28yNzAPeam Glmg== 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=DbnwDr2v6VZh9fSNvVIxIs9JsOx59RdGabp0ckeC1XQ=; b=jOpxj+aDbPsybT62NScHjaCD0hKtPcmPr7N+Sl0eFzTeozI/5d9z93/HHCquJ2zyyu SpYn9lnzn+pq6pwQSIAVotLwWKk2PdtFXtWo7j0AORqz63ud5v6VoYjC0almDvw+ZGGB hLjKB0IIXH39zO74imaPztpwmwJcLJ+PJjSMvesBha8PO+yoVfAXGHcoh14GOnvBPxQn Pyz70RVjfq3vplqBnBmQg56r8I/RSiXvd5Jufft3mn4iL+WAtwTP0nxCQu3zrCo55szw iVBqpUqEc7YPCa+KiJvy/kUTKuCuDmtZ6xf0jtv9srg20HuqjrmTMGJMqqDfCVwwzh0i vlZQ== X-Gm-Message-State: APjAAAUQqp2PnfcdADIPevFGSQzlK9tWJneGk9E1VACGRJoh/Yb7K+20 8JS/Kq//ELziqRtA7f2q6jowJRjELZYYVNWLdTAZrc3P X-Google-Smtp-Source: APXvYqzv/DWWpujURIEntKNsCm/+vQdExC1duIIlxUIeGL7wbNW/o1Phtw1FSH04YuFFRKpqTMVHAHumQILnX01JVXs= X-Received: by 2002:ae9:ebcf:: with SMTP id b198mr5758428qkg.129.1554395398149; Thu, 04 Apr 2019 09:29:58 -0700 (PDT) MIME-Version: 1.0 References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <5E94E4DD-4390-47A1-9C3C-44462E354A98@aisec.fraunhofer.de> In-Reply-To: <5E94E4DD-4390-47A1-9C3C-44462E354A98@aisec.fraunhofer.de> From: Hans Zandbelt Date: Thu, 4 Apr 2019 18:29:43 +0200 Message-ID: To: "Schanzenbach, Martin" Cc: George Fletcher , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000008c2fd80585b6e154" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 16:30:05 -0000 --0000000000008c2fd80585b6e154 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the root problem is that we're trying to unify across tokens that are issued for different use cases (auth vs. authz), different subjects and different audiences. The JWT spec allows us to cover those use cases nicely within its own semantics but the profile specific use case semantics are really different at heart. This problem becomes even more apparent in SPAs that share both the id_token and the access_token across frontend and backend: the RS then needs to flip back and forth between the use cases and their specific semantics. It seems were stuck between a rock and a hard place: I don't think there's a way to make things explicit and clear across use cases whilst sticking with JWT semantics only (as clear as the semantics may be in their own RFC7519 context). I also don't think there's a way to make things explicit and clear without breaking existing deployments and existing spec text which is as awkward. Hans. On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin < martin.schanzenbach@aisec.fraunhofer.de> wrote: > I think what needs to be clarified is whether the "sub" claim should > denote the caller (=3Dclient) or the RO in the case of an JWT AT. > RFC 7519 only defines "sub" to be the principal which is the subject of > all claims in the JWT. > This means that the AT can contain either claims regarding the client OR > the RO, but not both. (I prefer to use RO instead of user as I think this= a > term better used in OIDC). > > Now, the question is what does an RS need to make an authorisation > decision? Claims about the client or claims about the RO? > Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe > it makes sense to have the client as sub for the AT? > If the RS needs claims about the RO in order to do authorization > decisions, maybe it needs to be presented with an ID Token (which would > imply that it is issued with the RS in its aud claim). > > > On 4. Apr 2019, at 17:50, George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > > > The more I think about this the more I land in the "No" camp. > > > > The subject of a token should be the principal of that token. It > shouldn't matter whether that is a machine, a user, or a device. Trying t= o > separate out "humans" as a special class will just make things more > complicated. If we need a claim to identify the subject is a "human" then > why not just add that. This doesn't break anything and makes it easy for > people to detect this case in those use cases where it's required. > > > > Thanks, > > George > > > > On 4/3/19 4:56 PM, Hans Zandbelt wrote: > >> I will argue that in a way such deployments are already broken e.g. in > the typical use case of onboarding client accounts in the same > directory/OU/namespace as user accounts and we don't need to cater for th= at. > >> > >> Hans. > >> > >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher > wrote: > >> I agree that this will break a lot of existing flows... especially > those using any form of the client_credentials flow. In that sense I'm no= t > completely on board yet :) > >> > >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: > >>> great summary! this will hurt quite a few existing m2m deployments bu= t > I do like the rigidness of it all: it is very explicit, cannot > misinterpreted and thus prevents failure (which is really what Dominick i= s > after); I'm on board > >>> > >>> Hans. > >>> > >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >>> thank you Steinar and everyone else for the comments on this! > >>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov= , > Bertrand recommend using sub only for users. Martin would like to have th= e > sub for app only flows as well. Hans is neutral. > >>> That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have more tim= e > to comment as well. > >>> Clarification. If the goal is to be able to apply the logic "if > there's a sub, it's a user flow", we have to explicitly disallow (MUST NO= T) > the use of sub when that's not the case. Are all OK with it? > >>> > >>> Dave, the suggestion of having explicit typing for app only vs user > only is interesting! For the purpose of putting together an interoperable > profile, tho, I would suggest we table it for v1 in the interest of getti= ng > to something easy to adopt (hence with small delta vs existing > implementations) faster. > >>> > >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote= : > >>> Hi Vittorio, we (the national federation-gateway for the health > services in norway - "HelseID") think his is a really valuable initiativ= e! > >>> We also agree with Dominick concerning definition of the "sub" claim. > >>> > >>> Steinar > >>> > >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < > dbaier@leastprivilege.com>: > >>> From an access token consumer (aka API) developer point of view, I > prefer this logic > >>> > >>> "If sub is present - client acts on behalf of a user, if not - not." > >>> > >>> Anything more complicated has a potential of going wrong. > >>> > >>> > >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: > >>> > >>>> Hi Vittorio, > >>>> > >>>> Yeah, I=E2=80=99m concerning user & client ids collision. > >>>> I haven=E2=80=99t seen such implementations, but user-select usernam= e as sub, > or incremental integer as sub & client_id will be easily collide. > >>>> > >>>> If you can enforce collision resistant IDs between user & client > instances, it=E2=80=99ll works fine. I feel its overkill though. > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci > wrote: > >>>> > >>>>> Hey Nov, Dominick, Hans- > >>>>> thanks for the comments. That was an area I was expecting to cause > more discussion, and I am glad we are having this opportunity to clarify. > >>>>> The current language in the draft traces the etymology of sub to > OpenID Connect core, hence Dominick observation is on point. However in t= he > description I express something in line with 7519, which was in fact my > intent. > >>>>> > >>>>> The idea was to provide an identifier of the calling subject that i= s > guaranteed to be present in all cases- this would allow an SDK developer = to > use the same code for things like lookups and membership checks regardles= s > of the nature of the caller (user in a delegated case, app in app-only > grants). The information to discriminate between user and app callers is > always available in the token (say, the caller is a user if sub!=3Dclient= _id, > where client_id is always guaranteed to be present as well) hence there's > no loss in expressive power, should that difference be relevant for the > resource server. > >>>>> > >>>>> Dominick, Hans- I probably missed the security issue you guys are > thinking of in this case. Of course, if this would introduce a risk I > completely agree it should be changed- I'd just like to understand better > the problem. Could you expand it in a scenario/use case to clarify the ri= sk? > >>>>> Nov- playing this back: is the concern that a user and a client > might have the same identifier within an IDP? When using collision > resistant IDs, as it is usually the case, that seems to be a remote > possibility- did you stumble in such scenario in production? > >>>>> > >>>>> Thanks > >>>>> V. > >>>>> > >>>>> > >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >>>>> I believe there are plenty of OAuth 2.0 only use cases out there... > but nevertheless I agree with the potential confusion and thus security > problems arising from that (though one may argue the semantics are the > same). > >>>>> > >>>>> Hans. > >>>>> > >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < > dbaier@leastprivilege.com> wrote: > >>>>> Yes I know - and I think in hindsight it was a mistake to use the > same claim type for multiple semantics. > >>>>> > >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are maki= ng things more > complicated than they need to be - in my experience almost no-one (that I > know) does OIDC only - nor OAuth only. They always combine it. > >>>>> > >>>>> In reality this leads to potential security problems - this spec ha= s > the potential to rectify the situation. > >>>>> > >>>>> Dominick > >>>>> > >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( > hans.zandbelt@zmartzone.eu) wrote: > >>>>> > >>>>>> Without agreeing or disagreeing: OIDC does not apply here since it > is not OAuth and an access token is not an id_token. > >>>>>> The JWT spec says in > https://tools.ietf.org/html/rfc7519#section-4.1.2: > >>>>>> > >>>>>> "The "sub" (subject) claim identifies the principal that is the > >>>>>> subject of the JWT. The claims in a JWT are normally statement= s > >>>>>> 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" > >>>>>> > >>>>>> which kind of spells "client" in case of the client credentials > grant but I also do worry about Resource Servers thinking/acting only in > terms of users > >>>>>> > >>>>>> Hans. > >>>>>> > >>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < > dbaier@leastprivilege.com> wrote: > >>>>>> IMHO the sub claim should always refer to the user - and nothing > else. > >>>>>> > >>>>>> OIDC says: > >>>>>> > >>>>>> "Subject - Identifier for the End-User at the Issuer." > >>>>>> > >>>>>> client_id should be used to identify clients. > >>>>>> > >>>>>> cheers > >>>>>> Dominick > >>>>>> > >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) > wrote: > >>>>>> > >>>>>>> Hi Vittorio, > >>>>>>> > >>>>>>> Thanks for the good starting point of standardizing JWT-ized AT. > >>>>>>> > >>>>>>> One feedback. > >>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier= , end-user and > client, in this spec. > >>>>>>> It requires those 2 types of identifiers to be unique each other > in the IdP context. > >>>>>>> > >>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context= , so that no such > constraint needed. > >>>>>>> > >>>>>>> thanks > >>>>>>> > >>>>>>> nov > >>>>>>> > >>>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >>>>>>>> > >>>>>>>> Dear all, > >>>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 > access tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > >>>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be > presenting remotely). I look forward for your comments! > >>>>>>>> > >>>>>>>> Here's just a bit of backstory, in case you are interested in ho= w > this doc came to be. The trajectory it followed is somewhat > unusual. > >>>>>>>> =E2=80=A2 Despite OAuth2 not requiring any specific forma= t for > ATs, through the years I have come across multiple proprietary solution > using JWT for their access token. The intent and scenarios addressed by > those solutions are mostly the same across vendors, but the syntax and > interpretations in the implementations are different enough to prevent > developers from reusing code and skills when moving from product to produ= ct. > >>>>>>>> =E2=80=A2 I asked several individuals from key products a= nd > services to share with me concrete examples of their JWT access tokens > (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity)= , > Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and > explanations!). > >>>>>>>> I studied and compared all those instances, identifying > commonalities and differences. > >>>>>>>> =E2=80=A2 I put together a presentation summarizing my fi= ndings > and suggesting a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw= t_profile_for_ats.pptx > ) - got early feedback from Filip Skokan on it. Thx Filip! > >>>>>>>> =E2=80=A2 The presentation was followed up by 1.5 hours o= f > unconference discussion, which was incredibly valuable to get tight-loop > feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir > Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all > there and contributed generously to the discussion. Thank you!!! > >>>>>>>> Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note and > I'll make things right at the next update. > >>>>>>>> =E2=80=A2 On my flight back I did my best to incorporate = all the > ideas and feedback in a draft, which will be discussed at IETF104 tomorro= w. > Rifaat, Hannes and above all Brian were all super helpful in negotiating > the mysterious syntax of the RFC format and submission process. > >>>>>>>> I was blown away by the availability, involvement and willingnes= s > to invest time to get things right that everyone demonstrated in the > process. This is an amazing community. > >>>>>>>> V. > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> hans.zandbelt@zmartzone.eu > >>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>> > >>>>> > >>>>> -- > >>>>> hans.zandbelt@zmartzone.eu > >>>>> ZmartZone IAM - www.zmartzone.eu > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> -- > >>> Vennlig hilsen > >>> > >>> Steinar Noem > >>> Partner Udelt AS > >>> Systemutvikler > >>> > >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> -- > >>> hans.zandbelt@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> -- > >> hans.zandbelt@zmartzone.eu > >> ZmartZone IAM - www.zmartzone.eu > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > Martin Schanzenbach > Fraunhofer AISEC > Department Service & Application Security > Parkring 4, 85748 Garching near Munich (Germany) > Tel: +49 89 3229986-193 > martin.schanzenbach@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 > > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000008c2fd80585b6e154 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the root problem is that we're trying t= o unify across tokens that are issued for different use cases (auth vs. aut= hz), different subjects and different audiences. The JWT spec allows us to = cover those use cases nicely within its own semantics but the profile speci= fic use case semantics are really different at heart. This problem becomes = even more apparent in SPAs that share both the id_token and the access_toke= n across frontend and backend: the RS then needs to flip back and forth bet= ween the use cases and their specific semantics.

I= t seems were stuck between a rock and a hard place: I don't think there= 's a way to make things explicit and clear across use cases whilst stic= king with JWT semantics only (as clear as the semantics may be in their own= RFC7519 context). I also don't think there's a way to make things = explicit and clear without breaking existing deployments and existing spec = text which is as awkward.

Hans.

On Thu, Apr 4, 2019= at 5:58 PM Schanzenbach, Martin <martin.schanzenbach@aisec.fraunhofer.de> wrote:=
I think what ne= eds to be clarified is whether the "sub" claim should denote the = caller (=3Dclient) or the RO in the case of an JWT AT.
RFC 7519 only defines "sub" to be the principal which is the subj= ect of all claims in the JWT.
This means that the AT can contain either claims regarding the client OR th= e RO, but not both. (I prefer to use RO instead of user as I think this a t= erm better used in OIDC).

Now, the question is what does an RS need to make an authorisation decision= ? Claims about the client or claims about the RO?
Since OIDC already has ID Tokens as JWT which have the RO as "sub"= ;, maybe it makes sense to have the client as sub for the AT?
If the RS needs claims about the RO in order to do authorization decisions,= maybe it needs to be presented with an ID Token (which would imply that it= is issued with the RS in its aud claim).

> On 4. Apr 2019, at 17:50, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
>
> The more I think about this the more I land in the "No" camp= .
>
> The subject of a token should be the principal of that token. It shoul= dn't matter whether that is a machine, a user, or a device. Trying to s= eparate out "humans" as a special class will just make things mor= e complicated. If we need a claim to identify the subject is a "human&= quot; then why not just add that. This doesn't break anything and makes= it easy for people to detect this case in those use cases where it's r= equired.
>
> Thanks,
> George
>
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>> I will argue that in a way such deployments are already broken e.g= . in the typical use case of onboarding client accounts in the same directo= ry/OU/namespace as user accounts and we don't need to cater for that. >>
>> Hans.
>>
>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com> wrote:
>> I agree that this will break a lot of existing flows... especially= those using any form of the client_credentials flow. In that sense I'm= not completely on board yet :)
>>
>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>>> great summary! this will hurt quite a few existing m2m deploym= ents but I do like the rigidness of it all: it is very explicit, cannot mis= interpreted and thus prevents failure (which is really what Dominick is aft= er); I'm on board
>>>
>>> Hans.
>>>
>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio= =3D40auth0.= com@dmarc.ietf.org> wrote:
>>> thank you Steinar and everyone else for the comments on this!<= br> >>> To summarize the situation so far: Dominick, Steinar, Rob, Dav= id, Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral.
>>> That does sound like the sub as user has more consensus, tho b= efore changing it I'd wait for the people currently at IETF104 to have = more time to comment as well.
>>> Clarification. If the goal is to be able to apply the logic &q= uot;if there's a sub, it's a user flow", we have to explicitly= disallow (MUST NOT) the use of sub when that's not the case. Are all O= K with it?
>>>
>>> Dave, the suggestion of having explicit typing for app only vs= user only is interesting! For the purpose of putting together an interoper= able profile, tho, I would suggest we table it for v1 in the interest of ge= tting to something easy to adopt (hence with small delta vs existing implem= entations) faster.
>>>
>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote: >>> Hi Vittorio, we=C2=A0 (the national federation-gateway for the= health services in norway - "HelseID")=C2=A0 think his is a real= ly valuable initiative!
>>> We also agree with Dominick concerning definition of the "= ;sub" claim.
>>>
>>> <mvh>Steinar</mvh>
>>>
>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivile= ge.com>:
>>> From an access token consumer (aka API) developer point of vie= w, I prefer this logic
>>>
>>> "If sub is present - client acts on behalf of a user, if = not - not."
>>>
>>> Anything more complicated has a potential of going wrong.
>>>
>>>
>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:
>>>
>>>> Hi Vittorio,
>>>>
>>>> Yeah, I=E2=80=99m concerning user & client ids collisi= on.
>>>> I haven=E2=80=99t seen such implementations, but user-sele= ct username as sub, or incremental integer as sub & client_id will be e= asily collide.
>>>>
>>>> If you can enforce collision resistant IDs between user &a= mp; client instances, it=E2=80=99ll works fine. I feel its overkill though.=
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wr= ote:
>>>>
>>>>> Hey Nov, Dominick, Hans-
>>>>> thanks for the comments. That was an area I was expect= ing to cause more discussion, and I am glad we are having this opportunity = to clarify.
>>>>> The current language in the draft traces the etymology= of sub to OpenID Connect core, hence Dominick observation is on point. How= ever in the description I express something in line with 7519, which was in= fact my intent.
>>>>>
>>>>> The idea was to provide an identifier of the calling s= ubject that is guaranteed to be present in all cases- this would allow an S= DK developer to use the same code for things like lookups and membership ch= ecks regardless of the nature of the caller (user in a delegated case, app = in app-only grants). The information to discriminate between user and app c= allers is always available in the token (say, the caller is a user if sub!= =3Dclient_id, where client_id is always guaranteed to be present as well) h= ence there's no loss in expressive power, should that difference be rel= evant for the resource server.
>>>>>
>>>>> Dominick, Hans- I probably missed the security issue y= ou guys are thinking of in this case. Of course, if this would introduce a = risk I completely agree it should be changed- I'd just like to understa= nd better the problem. Could you expand it in a scenario/use case to clarif= y the risk?
>>>>> Nov- playing this back: is the concern that a user and= a client might have the same identifier within an IDP? When using collisio= n resistant IDs, as it is usually the case, that seems to be a remote possi= bility- did you stumble in such scenario in production?
>>>>>
>>>>> Thanks
>>>>> V.
>>>>>
>>>>>
>>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@z= martzone.eu> wrote:
>>>>> I believe there are plenty of OAuth 2.0 only use cases= out there... but nevertheless I agree with the potential confusion and thu= s security problems arising from that (though one may argue the semantics a= re the same).
>>>>>
>>>>> Hans.
>>>>>
>>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastpri= vilege.com> wrote:
>>>>> Yes I know - and I think in hindsight it was a mistake= to use the same claim type for multiple semantics.
>>>>>
>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D argum= ents are making things more complicated than they need to be - in my experi= ence almost no-one (that I know) does OIDC only - nor OAuth only. They alwa= ys combine it.
>>>>>
>>>>> In reality this leads to potential security problems -= this spec has the potential to rectify the situation.
>>>>>
>>>>> Dominick
>>>>>
>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmar= tzone.eu) wrote:
>>>>>
>>>>>> Without agreeing or disagreeing: OIDC does not app= ly here since it is not OAuth and an access token is not an id_token.
>>>>>> The JWT spec says in https= ://tools.ietf.org/html/rfc7519#section-4.1.2:
>>>>>>
>>>>>> "The "sub" (subject) claim identifi= es the principal that is the
>>>>>>=C2=A0 =C2=A0 subject of the JWT.=C2=A0 The claims = in a JWT are normally statements
>>>>>>=C2=A0 =C2=A0 about the subject.=C2=A0 The subject = value MUST either be scoped to be
>>>>>>=C2=A0 =C2=A0 locally unique in the context of the = issuer or be globally unique.
>>>>>>=C2=A0 =C2=A0 The processing of this claim is gener= ally application specific"
>>>>>>
>>>>>> which kind of spells "client" in case of= the client credentials grant but I also do worry about Resource Servers th= inking/acting only in terms of users
>>>>>>
>>>>>> Hans.
>>>>>>
>>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <= ;dbaier@leas= tprivilege.com> wrote:
>>>>>> IMHO the sub claim should always refer to the user= - and nothing else.
>>>>>>
>>>>>> OIDC says:
>>>>>>
>>>>>> "Subject - Identifier for the End-User at the= Issuer."
>>>>>>
>>>>>> client_id should be used to identify clients.
>>>>>>
>>>>>> cheers
>>>>>> Dominick
>>>>>>
>>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote= :
>>>>>>
>>>>>>> Hi Vittorio,
>>>>>>>
>>>>>>> Thanks for the good starting point of standard= izing JWT-ized AT.
>>>>>>>
>>>>>>> One feedback.
>>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 = types of identifier, end-user and client, in this spec.
>>>>>>> It requires those 2 types of identifiers to be= unique each other in the IdP context.
>>>>>>>
>>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim = in 2-legged context, so that no such constraint needed.
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> nov
>>>>>>>
>>>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocc= i <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
>>>>>>>>
>>>>>>>> Dear all,
>>>>>>>> I just submitted a draft describing a JWT = profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-= oauth-access-token-jwt/.
>>>>>>>> I have a slot to discuss this tomorrow at = IETF 104 (I'll be presenting remotely). I look forward for your comment= s!
>>>>>>>>
>>>>>>>> Here's just a bit of backstory, in cas= e you are interested in how this doc came to be. The trajectory it followed= is somewhat=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 =C2=A0 =C2=A0 =C2=A0un= usual.
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Despi= te OAuth2 not requiring any specific format for ATs, through the years I ha= ve come across multiple proprietary solution using JWT for their access tok= en. The intent and scenarios addressed by those solutions are mostly the sa= me across vendors, but the syntax and interpretations in the implementation= s are different enough to prevent developers from reusing code and skills w= hen moving from product to product.
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 I ask= ed several individuals from key products and services to share with me conc= rete examples of their JWT access tokens (THANK YOU Dominick Baier (Identit= yServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl = Guinness (Okta) for the tokens and explanations!).
>>>>>>>> I studied and compared all those instances= , identifying commonalities and differences.
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 I put= together a presentation summarizing my findings and suggesting a rough int= eroperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/s= lides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from= Filip Skokan on it. Thx Filip!
>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 The p= resentation was followed up by 1.5 hours of unconference discussion, which = was incredibly valuable to get tight-loop feedback and incorporate new idea= s. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Na= t Sakimura, Hannes Tschofenig were all there and contributed generously to = the discussion. Thank you!!!
>>>>>>>> Note: if you were at OSW2019, participated= in the discussion and didn't get credited in the draft, my apologies: = please send me a note and I'll make things right at the next update. >>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 On my= flight back I did my best to incorporate all the ideas and feedback in a d= raft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above= all Brian were all super helpful in negotiating the mysterious syntax of t= he RFC format and submission process.
>>>>>>>> I was blown away by the availability, invo= lvement and willingness to invest time to get things right that everyone de= monstrated in the process. This is an amazing community.
>>>>>>>> V.
>>>>>>>> __________________________________________= _____
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mai= lman/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/lis= tinfo/oauth
>>>>>>
>>>>>>
>>>>>> --
>>>>>> hans.zandbelt@zmartzone.eu
>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>
>>>>>
>>>>> --
>>>>> hans.zandbelt@zmartzone.eu
>>>>> ZmartZone IAM - www.zmartzone.eu
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>>
>>>
>>> --
>>> Vennlig hilsen
>>>
>>> Steinar Noem
>>> Partner Udelt AS
>>> Systemutvikler
>>>
>>> | steina= r@udelt.no | hei@udel= t.no=C2=A0 | +47 955 21 620 | www.udelt.no |
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>>
>>>
>>> --
>>> hans.zandbelt@zmartzone.eu
>>> ZmartZone IAM - www.zmartzone.eu
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>>
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>>
>>
>>
>> --
>> ha= ns.zandbelt@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


Martin Schanzenbach
Fraunhofer AISEC
Department Service & Application Security
Parkring 4, 85748 Garching near Munich (Germany)
Tel: +49 89 3229986-193
martin.schanzenbach@aisec.fraunhofer.de
GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0



--
--0000000000008c2fd80585b6e154-- From nobody Thu Apr 4 09:32:47 2019 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 9749312010D for ; Thu, 4 Apr 2019 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 wH6PLtZcULgH for ; Thu, 4 Apr 2019 09:32:42 -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 DE03712007A for ; Thu, 4 Apr 2019 09:32:41 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id x7so2533179ioh.4 for ; Thu, 04 Apr 2019 09:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6GCcamdnyjs5rNzGWsVJsj9T3CdH+K/mYafH7ZZ5DB8=; b=lpQxSihaYJxAX6Rxe8/d7CIguD4Xmd54MA2v1RMMoiexDvwsAY9W4+VAAjw/+rW/3r T7l/ZOAPVD4mqO+iniMCmBHInYXUN2vQ7pUti2mq1a9vOwwttnMK2HkIkYTrCL2HeAto 6sxfsB9M0LxLxUcwmd+mdlwuVEGc2qJNuOaBs= 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=6GCcamdnyjs5rNzGWsVJsj9T3CdH+K/mYafH7ZZ5DB8=; b=CD/VLbsUvMPGSJJ4o/trRlWw7UQH7X59DLm/TAmK+/HHOU6vI2rU4MN6CqIAgcK83Q O3r2FINbjIG0K+HSpwpPSBOaPvVR/+ZbtlP5s/e5ibhNS3FCa7Q7ejztzsKr1bQHERN+ ouMi6iTMIxbKhAeIIHG3lWj4YHypih52sfqrO63oIbSEu7jf31Zi+uRabFNZmX6hl5NN RtMtdag3nTwAU0YaAKfXapCRJQ3+rX81A8HK+MimHGXjnYjn1qMggOQR2DODCwmYQ4gc 9uw+dwJWtA4Kqn94Bhxla+ysZsOQVnTnaVex1xXdNNdZXphUswn3gWS/8S1w3ifgr51u n82w== X-Gm-Message-State: APjAAAWzMSYBwjQC0YT+HDiWuHDhobbzonanyhk6wnxa3urtUJ7wWceo pwBKOJb/UZc/K++VkvIEM53OejbLZ3YybfRbsVpAQL2oYl4oMfP97Y/u2v0eVEuoJKcxX3rNYrt XUT+hwzPUxAzvcg== X-Google-Smtp-Source: APXvYqycqb8U+6c6AtIhYzR+FY4fUtBMuq8i2NHRRkWjNyX1/ro2BZx/GvZo4RgL1LL2T+A2RASHdJbt4KBa00EgGgU= X-Received: by 2002:a5d:81c2:: with SMTP id t2mr1905094iol.183.1554395560835; Thu, 04 Apr 2019 09:32:40 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Brian Campbell Date: Thu, 4 Apr 2019 10:32:13 -0600 Message-ID: To: Vittorio Bertocci Cc: David Waite , George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000003e9c800585b6eb0e" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 16:32:46 -0000 --0000000000003e9c800585b6eb0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A few remarks/responses inline below this time... On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci wrote: > Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim types used in here, so if you think that > reusing the ones in the id_token can cause confusion we should expand on > the specific ways in which you think might go south. > My concern isn't with reusing the names/types of the claims per se. But more generally that codifying the use of certain authentication-centric claims in the context of an access token furthers the potential confusion around authentication vs. authorization that has been a nagging problem for OAuth (i.e. the https://oauth.net/articles/authentication/ article). However I think it's important that the information on say, whether the > current token was obtained using MFA or a specific authentication factor = is > something that API developers can legitimately latch to when doing > authorization decisions. From the perspective of a developer modeling a > solution, whether functionality is delivered as a route in a postback bas= ed > web app (hence receiving an id_token or derived) or as an API consumed by= a > native app, the business requirement gating access to that functionality > doesn't change. If the admin managing that resource establishes that acce= ss > should be performed only via MFA, the developer should be equipped to > enforce that regardless of the stack used to expose functionality (web ap= p, > API). > Although it is true that triggering the desired behavior might be achieve= d > by the resource setting and contract with the AS, along the lines of what > David said, it's actually not uncommon for those policies to be assigned = on > the resource AFTER the current session was established and/or the > corresponding AT was obtained and cached. Furthermore, the requirement > might be more granular than an AS policy can tolerate (an API might > requires MFA only for certain routes, hence hard to express in a static > policy) and triggered in form of challenges. So the situation in which yo= u > have an AT with the right issuer, audience, etc but was obtained with a > policy now obsolete/unacceptable to the RP is strong. Requesting to suppo= rt > revocation just for this seems overkill, especially given that the scenar= io > in which the same logical app is exposed as both web app and native > client+API, the code consuming those claims is already in place. It just > makes intuitive sense for developers. > In summary, one can take steps to push as much of the MFA requirements to > the AS settings for a particular request, but ultimately the desire of th= e > API developer to enforce that it actually happened is a requirement I > encountered often in practice. Anything providing extra context to refine > decisions about it (like auth_time, which might inform decisions about > whether to accept an MFA check occurred N minutes ago or refuse access). > I understand what you are saying but but personally do not find it sufficiently compelling. But that's just my opinion and not a hill I want to die on (at the present time anyway). > I thought that reusing the existing names for the same concepts just made > sense (dev existing skills, existing codebases, etc etc) and especially i= n > the case in which the values are exactly the same, and the idea seemed to > receive good support during OSW. > Our recollection of OSW differs somewhat. As I recall there was support for pointing to identity claims from OIDC for additional end-user info. But there was some grumbling (from John and myself at least) at first mention of acr/amr and auth_time. By the time it came up again near the end of the last unconference session, I wasn't wanting to prolong things because I was kinda worn out for the day and wanting to get to Frankfurt that evening before sunset ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ). > But I am completely open to change it of course, especially for cases lik= e > the one identified by George. > FWIW, to me, George's suggestion "assume[ing] that the auth_time value should be updated to the latest time at which the user authenticated" though some unspecified and in many cases non-existent link between the AT and a current user session at the AS is an example of how authentication-centric claims in an access token can be confusing. > WDYT? > > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> +1 to David's question here. I'd like to see justifying use cases (beyon= d >> just the fact that some people are already doing it) for auth_time, acr, >> and amr to be available in OAuth JWT access tokens. Those claims are >> defined for, and in the context of, an ID Token and I fear that codifyin= g >> their use in an access token will lead to misuse and/or confusion. >> >> On Mon, Apr 1, 2019 at 1:03 PM David Waite >> wrote: >> >>> Do we know if there is a justifying use case for auth_time, acr, and am= r >>> to be available in OAuth JWT access tokens? These are meant to be messa= ges >>> about the client, either directly (in the case of client credentials) o= r >>> about its delegated authorization of the user. >>> >>> Embedding attributes about the user (such as group membership and roles= ) >>> can be used for the resource to make finer-grained decisions than scope= s, >>> but normally I would expect say acr limitations enforced by a resource = to >>> instead be controlled by the AS requiring a higher quality authenticati= on >>> to release certain scopes. >>> >>> Thats of course not to say extensions to OAuth such as OIDC can=E2=80= =99t >>> provide these values, just that they might better be defined by those >>> extensions. >>> >>> -DW >>> >>> On Apr 1, 2019, at 9:12 AM, George Fletcher < >>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>> >>> Thanks for writing this up. One comment on auth_time... >>> >>> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >>> Important: as this claim represents the time at which the end use= r >>> authenticated, its value will remain the same for all the JWT >>> access tokens issued within that session. For example: all the >>> JWT access tokens obtained with a given refresh token will all >>> have the same value of auth_time, corresponding to the instant in >>> which the user first authenticated to obtain the refresh token. >>> >>> >>> During a current session a user can be challenged for additional >>> credentials or required to re-authenticate due to a number of different >>> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this con= text, >>> I'd assume that the auth_time value should be updated to the latest tim= e at >>> which the user authenticated. >>> >>> If we need a timestamp for when the "session" started, then there could >>> be a session_start_time claim. >>> >>> Thanks, >>> George >>> >>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>> >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= . >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT= for >>> their access token. The intent and scenarios addressed by those solu= tions >>> are mostly the same across vendors, but the syntax and interpretatio= ns in >>> the implementations are different enough to prevent developers from = reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YO= U >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-= _a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback= and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvin= ov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a not= e and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Ri= faat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the proce= ss. >>> This is an amazing community. >>> V. >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> _______________________________________________ >>> 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 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._ --0000000000003e9c800585b6eb0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few remarks/responses in= line below this time...

On Wed, Apr 3, 2019 at 1:38 PM Vittorio Berto= cci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Thanks guys for the comm= ent, sorry for the delay in addressing them.
I am not married to the cl= aim types used in here, so if you think that reusing the ones in the id_tok= en can cause confusion we should expand on the specific ways in which you t= hink might go south.

My concern= isn't with reusing the names/types of the claims per se.=C2=A0 But mor= e generally that codifying the use of certain authentication-centric claims= in the context of an access token furthers the potential confusion around = authentication vs. authorization that has been a nagging problem for OAuth = (i.e. the https://oauth.net/articles/authentication/ article).
=
=C2=A0

However I think it's important that the in= formation on say, whether the current token was obtained using MFA or a spe= cific authentication factor is something that API developers can legitimate= ly latch to when doing authorization decisions. From the perspective of a d= eveloper modeling a solution, whether functionality is delivered as a route= in a postback based web app (hence receiving an id_token or derived) or as= an API consumed by a native app, the business requirement gating access to= that functionality doesn't change. If the admin managing that resource= establishes that access should be performed only via MFA, the developer sh= ould be equipped to enforce that regardless of the stack used to expose fun= ctionality (web app, API).=C2=A0
Although it is true that trigger= ing the desired behavior might be achieved by the resource setting and cont= ract with the AS, along the lines of what David said, it's actually not= uncommon for those policies to be assigned on the resource AFTER the curre= nt session was established and/or the corresponding AT was obtained and cac= hed. Furthermore, the requirement might be more granular than an AS policy = can tolerate (an API might requires MFA only for certain routes, hence hard= to express in a static policy) and triggered in form of challenges. So the= situation in which you have an AT with the right issuer, audience, etc but= was obtained with a policy now obsolete/unacceptable to the RP is strong. = Requesting to support revocation just for this seems overkill, especially g= iven that the scenario in which the same logical app is exposed as both web= app and native client+API, the code consuming those claims is already in p= lace. It just makes intuitive sense for developers.=C2=A0 =C2=A0
= In summary, one can take steps to push as much of the MFA requirements to t= he AS settings for a particular request, but ultimately the desire of the A= PI developer to enforce that it actually happened=C2=A0is a requirement I e= ncountered often in practice. Anything providing extra context to refine de= cisions about it (like auth_time, which might inform decisions about whethe= r to accept an MFA check occurred N minutes ago or refuse access).

I understand what you are saying but bu= t personally do not find it sufficiently compelling.=C2=A0 But that's j= ust my opinion and not a hill I want to die on (at the present time anyway)= .
=C2=A0


I thought that reus= ing the existing names for the same concepts just made sense (dev existing = skills, existing codebases, etc etc) and especially in the case in which th= e values are exactly the same, and the idea seemed to receive good support = during OSW.

Our recollection of= OSW differs somewhat. As I recall there was support for pointing to identi= ty claims from OIDC for additional end-user info. But there was some grumbl= ing (from John and myself at least) at first mention of acr/amr and auth_ti= me. By the time it came up again near the end of the last unconference sess= ion, I wasn't wanting to prolong things because I was kinda worn out fo= r the day and wanting to get to Frankfurt that evening before sunset ('= cause I like to do stuff like this: h= ttps://flic.kr/p/2fiAaPe :) ).

=C2=A0
B= ut I am completely open to change it of course, especially for cases like t= he one identified by George.

FW= IW, to me, George's suggestion "assume[ing] that the auth_time val= ue should be updated to the latest time at which the user authenticated&quo= t; though some unspecified and in many cases non-existent link between the = AT and a current user session at the AS is an example of how authentication= -centric claims in an access token can be confusing.


=C2=A0
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM= Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote= :
+1 to David's question here. I'd like to see ju= stifying use cases (beyond just the fact that some people are already doing= it) for auth_time, acr, and amr to be available in OAuth JWT access tokens= . Those claims are defined for, and in the context of, an ID Token and I fe= ar that codifying their use in an access token will lead to misuse and/or c= onfusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-s= olutions.com> wrote:
Do we know if there is a justifying use case for auth_time= , acr, and amr to be available in OAuth JWT access tokens? These are meant = to be messages about the client, either directly (in the case of client cre= dentials) or about its delegated authorization of the user.

<= div>
Embedding attributes about the user (such as group membership= and roles) can be used for the resource to make finer-grained decisions th= an scopes, but normally I would expect say acr limitations enforced by a re= source to instead be controlled by the AS requiring a higher quality authen= tication to release certain scopes.

Thats of cours= e not to say extensions to OAuth such as OIDC can=E2=80=99t provide these v= alues, just that they might better be defined by those extensions.

-DW

On Apr 1,= 2019, at 9:12 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20 =20
Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume= that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then= there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,= =C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

_______________________________________________
OAuth mailing list
OAu=
th@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

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. --0000000000003e9c800585b6eb0e-- From nobody Thu Apr 4 10:04:57 2019 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 885DD1203EC for ; Thu, 4 Apr 2019 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9pZhDpAmnYU6 for ; Thu, 4 Apr 2019 10:04:51 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 1644512068F for ; Thu, 4 Apr 2019 10:04:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FJAgBmOKZc/xmnZsBbBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWcqaHESJwqEBGKCaIUxjCQlfoFlhlWPH4FCJQsFGA0JgQKCdkY?= =?us-ascii?q?ChU4iOBIBAQMBAQkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAggMHxE?= =?us-ascii?q?SAQEYAQEBAQIBAQEhJiUDCAULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQg?= =?us-ascii?q?PrjaBL4N0UUGDAQ2CEA+BMIFKgxKGV4FYPoERJwwTgU5JNT6CGkcBAQIBAYE?= =?us-ascii?q?lDQ8GCEYGgkwxgiYDinaGW1CTEzYDBAICgSeDS4ISeoQchBqDRBqCBYYUgzG?= =?us-ascii?q?GHIJpjGeFBIFDiEiDcYFmIjGBJXFFCgUlAVUdgSYpCYINF4EBAQ6Cb06DcCO?= =?us-ascii?q?FPz8BATEBAY9HgR8BAQ?= X-IPAS-Result: =?us-ascii?q?A2FJAgBmOKZc/xmnZsBbBAYcAQEBBAEBBwQBAYFlgWcqa?= =?us-ascii?q?HESJwqEBGKCaIUxjCQlfoFlhlWPH4FCJQsFGA0JgQKCdkYChU4iOBIBAQMBA?= =?us-ascii?q?QkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAggMHxESAQEYAQEBAQIBA?= =?us-ascii?q?QEhJiUDCAULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQgPrjaBL4N0UUGDA?= =?us-ascii?q?Q2CEA+BMIFKgxKGV4FYPoERJwwTgU5JNT6CGkcBAQIBAYElDQ8GCEYGgkwxg?= =?us-ascii?q?iYDinaGW1CTEzYDBAICgSeDS4ISeoQchBqDRBqCBYYUgzGGHIJpjGeFBIFDi?= =?us-ascii?q?EiDcYFmIjGBJXFFCgUlAVUdgSYpCYINF4EBAQ6Cb06DcCOFPz8BATEBAY9Hg?= =?us-ascii?q?R8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="asc'?scan'208";a="14347847" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 19:04:37 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlBADZOKZcfRBhWMBbBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWeBEoEDJwqEBGKIGYwkJX6BZYZVjx+BZwsFGA2EAUYChW84EgE?= =?us-ascii?q?BAwEBCQEDAhQBARY6IwyFSgEBAQECAQEBISYlAwgFCwIBCBgqAgIhBgslAgQ?= =?us-ascii?q?OBQ4GB4MHAYFdAw0ID64zgS+ERUGDAQ2CEA+BMIFKgxKILz6BEScME4FOSTU?= =?us-ascii?q?+ghpHAQECAQGBJQ0PBghGBoJMMYImA4p2hltQkxM2AwQCAoEng0uCEnqEHIQ?= =?us-ascii?q?ag0QaggWGFIMxhhyCaYxnhQSBQ4w5gWYgMoElcUUKBSUBVR2BJikJgg0XgQE?= =?us-ascii?q?BDoJvToNwI4U/PwECMAEBj0eBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="asc'?scan'208";a="41221598" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/AES256-SHA; 04 Apr 2019 19:04:05 +0200 Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP11EXC.ads.fraunhofer.de ([10.80.232.42]) with mapi id 14.03.0435.000; Thu, 4 Apr 2019 19:04:05 +0200 From: "Schanzenbach, Martin" To: Hans Zandbelt CC: George Fletcher , Vittorio Bertocci , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU42Wr/thS5xrVIYxSuUg+/ebS0aYc/+GAgABhiACAACYMAIAAiF0AgAACU4CADMLFgIAAAkaAgAE81oCAAAIkgIAACLqAgAAJmQA= Date: Thu, 4 Apr 2019 17:04:04 +0000 Message-ID: References: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <5E94E4DD-4390-47A1-9C3C-44462E354A98@aisec.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.80.233.50] x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24526.004 x-tm-as-result: No--43.922600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_C06A53EB-36F0-4D5C-B134-D0787961ED42"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:04:56 -0000 --Apple-Mail=_C06A53EB-36F0-4D5C-B134-D0787961ED42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree. Maybe RFC 7519 is actually as good as it gets wrt claim = specifications? At least for OAuth. Use case specific profiles can/must then use their = own definitions (see OIDC) for (JWT) ATs. I mean, at least for OIDC, an AT which is the result of a client = credential grant isn't even a thing which really simplifies the = specification of a JWT AT in OIDC. So maybe just reference / rely on RFC 7519 for the basic claims and = clarify usage of this JWT using the typ? > On 4. Apr 2019, at 18:29, Hans Zandbelt = wrote: >=20 > I believe the root problem is that we're trying to unify across tokens = that are issued for different use cases (auth vs. authz), different = subjects and different audiences. The JWT spec allows us to cover those = use cases nicely within its own semantics but the profile specific use = case semantics are really different at heart. This problem becomes even = more apparent in SPAs that share both the id_token and the access_token = across frontend and backend: the RS then needs to flip back and forth = between the use cases and their specific semantics. >=20 > It seems were stuck between a rock and a hard place: I don't think = there's a way to make things explicit and clear across use cases whilst = sticking with JWT semantics only (as clear as the semantics may be in = their own RFC7519 context). I also don't think there's a way to make = things explicit and clear without breaking existing deployments and = existing spec text which is as awkward. >=20 > Hans. >=20 > On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin = wrote: > I think what needs to be clarified is whether the "sub" claim should = denote the caller (=3Dclient) or the RO in the case of an JWT AT. > RFC 7519 only defines "sub" to be the principal which is the subject = of all claims in the JWT. > This means that the AT can contain either claims regarding the client = OR the RO, but not both. (I prefer to use RO instead of user as I think = this a term better used in OIDC). >=20 > Now, the question is what does an RS need to make an authorisation = decision? Claims about the client or claims about the RO? > Since OIDC already has ID Tokens as JWT which have the RO as "sub", = maybe it makes sense to have the client as sub for the AT? > If the RS needs claims about the RO in order to do authorization = decisions, maybe it needs to be presented with an ID Token (which would = imply that it is issued with the RS in its aud claim). >=20 > > On 4. Apr 2019, at 17:50, George Fletcher = wrote: > > > > The more I think about this the more I land in the "No" camp. > > > > The subject of a token should be the principal of that token. It = shouldn't matter whether that is a machine, a user, or a device. Trying = to separate out "humans" as a special class will just make things more = complicated. If we need a claim to identify the subject is a "human" = then why not just add that. This doesn't break anything and makes it = easy for people to detect this case in those use cases where it's = required. > > > > Thanks, > > George > > > > On 4/3/19 4:56 PM, Hans Zandbelt wrote: > >> I will argue that in a way such deployments are already broken e.g. = in the typical use case of onboarding client accounts in the same = directory/OU/namespace as user accounts and we don't need to cater for = that. > >> > >> Hans. > >> > >> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher = wrote: > >> I agree that this will break a lot of existing flows... especially = those using any form of the client_credentials flow. In that sense I'm = not completely on board yet :) > >> > >> On 3/26/19 12:56 PM, Hans Zandbelt wrote: > >>> great summary! this will hurt quite a few existing m2m deployments = but I do like the rigidness of it all: it is very explicit, cannot = misinterpreted and thus prevents failure (which is really what Dominick = is after); I'm on board > >>> > >>> Hans. > >>> > >>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci = wrote: > >>> thank you Steinar and everyone else for the comments on this! > >>> To summarize the situation so far: Dominick, Steinar, Rob, David, = Nov, Bertrand recommend using sub only for users. Martin would like to = have the sub for app only flows as well. Hans is neutral. > >>> That does sound like the sub as user has more consensus, tho = before changing it I'd wait for the people currently at IETF104 to have = more time to comment as well. > >>> Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? > >>> > >>> Dave, the suggestion of having explicit typing for app only vs = user only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. > >>> > >>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem = wrote: > >>> Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! > >>> We also agree with Dominick concerning definition of the "sub" = claim. > >>> > >>> Steinar > >>> > >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = : > >>> =46rom an access token consumer (aka API) developer point of view, = I prefer this logic > >>> > >>> "If sub is present - client acts on behalf of a user, if not - = not." > >>> > >>> Anything more complicated has a potential of going wrong. > >>> > >>> > >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) = wrote: > >>> > >>>> Hi Vittorio, > >>>> > >>>> Yeah, I=E2=80=99m concerning user & client ids collision. > >>>> I haven=E2=80=99t seen such implementations, but user-select = username as sub, or incremental integer as sub & client_id will be = easily collide. > >>>> > >>>> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci = wrote: > >>>> > >>>>> Hey Nov, Dominick, Hans- > >>>>> thanks for the comments. That was an area I was expecting to = cause more discussion, and I am glad we are having this opportunity to = clarify. > >>>>> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. > >>>>> > >>>>> The idea was to provide an identifier of the calling subject = that is guaranteed to be present in all cases- this would allow an SDK = developer to use the same code for things like lookups and membership = checks regardless of the nature of the caller (user in a delegated case, = app in app-only grants). The information to discriminate between user = and app callers is always available in the token (say, the caller is a = user if sub!=3Dclient_id, where client_id is always guaranteed to be = present as well) hence there's no loss in expressive power, should that = difference be relevant for the resource server. > >>>>> > >>>>> Dominick, Hans- I probably missed the security issue you guys = are thinking of in this case. Of course, if this would introduce a risk = I completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? > >>>>> Nov- playing this back: is the concern that a user and a client = might have the same identifier within an IDP? When using collision = resistant IDs, as it is usually the case, that seems to be a remote = possibility- did you stumble in such scenario in production? > >>>>> > >>>>> Thanks > >>>>> V. > >>>>> > >>>>> > >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = wrote: > >>>>> I believe there are plenty of OAuth 2.0 only use cases out = there... but nevertheless I agree with the potential confusion and thus = security problems arising from that (though one may argue the semantics = are the same). > >>>>> > >>>>> Hans. > >>>>> > >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = wrote: > >>>>> Yes I know - and I think in hindsight it was a mistake to use = the same claim type for multiple semantics. > >>>>> > >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are = making things more complicated than they need to be - in my experience = almost no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. > >>>>> > >>>>> In reality this leads to potential security problems - this spec = has the potential to rectify the situation. > >>>>> > >>>>> Dominick > >>>>> > >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu) wrote: > >>>>> > >>>>>> Without agreeing or disagreeing: OIDC does not apply here since = it is not OAuth and an access token is not an id_token. > >>>>>> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2: > >>>>>> > >>>>>> "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" > >>>>>> > >>>>>> which kind of spells "client" in case of the client credentials = grant but I also do worry about Resource Servers thinking/acting only in = terms of users > >>>>>> > >>>>>> Hans. > >>>>>> > >>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = wrote: > >>>>>> IMHO the sub claim should always refer to the user - and = nothing else. > >>>>>> > >>>>>> OIDC says: > >>>>>> > >>>>>> "Subject - Identifier for the End-User at the Issuer." > >>>>>> > >>>>>> client_id should be used to identify clients. > >>>>>> > >>>>>> cheers > >>>>>> Dominick > >>>>>> > >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) = wrote: > >>>>>> > >>>>>>> Hi Vittorio, > >>>>>>> > >>>>>>> Thanks for the good starting point of standardizing JWT-ized = AT. > >>>>>>> > >>>>>>> One feedback. > >>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of = identifier, end-user and client, in this spec. > >>>>>>> It requires those 2 types of identifiers to be unique each = other in the IdP context. > >>>>>>> > >>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged = context, so that no such constraint needed. > >>>>>>> > >>>>>>> thanks > >>>>>>> > >>>>>>> nov > >>>>>>> > >>>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci = wrote: > >>>>>>>> > >>>>>>>> Dear all, > >>>>>>>> I just submitted a draft describing a JWT profile for OAuth = 2.0 access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > >>>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! > >>>>>>>> > >>>>>>>> Here's just a bit of backstory, in case you are interested in = how this doc came to be. The trajectory it followed is somewhat = unusual. > >>>>>>>> =E2=80=A2 Despite OAuth2 not requiring any specific = format for ATs, through the years I have come across multiple = proprietary solution using JWT for their access token. The intent and = scenarios addressed by those solutions are mostly the same across = vendors, but the syntax and interpretations in the implementations are = different enough to prevent developers from reusing code and skills when = moving from product to product. > >>>>>>>> =E2=80=A2 I asked several individuals from key = products and services to share with me concrete examples of their JWT = access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!). > >>>>>>>> I studied and compared all those instances, identifying = commonalities and differences. > >>>>>>>> =E2=80=A2 I put together a presentation summarizing my = findings and suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. = Thx Filip! > >>>>>>>> =E2=80=A2 The presentation was followed up by 1.5 = hours of unconference discussion, which was incredibly valuable to get = tight-loop feedback and incorporate new ideas. John Bradley, Brian = Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes = Tschofenig were all there and contributed generously to the discussion. = Thank you!!! > >>>>>>>> Note: if you were at OSW2019, participated in the discussion = and didn't get credited in the draft, my apologies: please send me a = note and I'll make things right at the next update. > >>>>>>>> =E2=80=A2 On my flight back I did my best to = incorporate all the ideas and feedback in a draft, which will be = discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were = all super helpful in negotiating the mysterious syntax of the RFC format = and submission process. > >>>>>>>> I was blown away by the availability, involvement and = willingness to invest time to get things right that everyone = demonstrated in the process. This is an amazing community. > >>>>>>>> V. > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> hans.zandbelt@zmartzone.eu > >>>>>> ZmartZone IAM - www.zmartzone.eu > >>>>> > >>>>> > >>>>> -- > >>>>> hans.zandbelt@zmartzone.eu > >>>>> ZmartZone IAM - www.zmartzone.eu > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> -- > >>> Vennlig hilsen > >>> > >>> Steinar Noem > >>> Partner Udelt AS > >>> Systemutvikler > >>> > >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no = | > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> -- > >>> hans.zandbelt@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> -- > >> hans.zandbelt@zmartzone.eu > >> ZmartZone IAM - www.zmartzone.eu > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Martin Schanzenbach > Fraunhofer AISEC > Department Service & Application Security > Parkring 4, 85748 Garching near Munich (Germany) > Tel: +49 89 3229986-193 > martin.schanzenbach@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 >=20 >=20 >=20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenbach@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 --Apple-Mail=_C06A53EB-36F0-4D5C-B134-D0787961ED42 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlymOQQACgkQhDNRMeo9 q/Bq2xAAqtYZ90J9h5VM/CTOgHgIqKtlTLrjS9SZrtHeD0dOwPaZR4vHFc7zIrxm SSaxdOGPA1WYZGcknmQfGViFrw1sCO1LMKY3nm8r886nL7WgF880k2FK0CEIMxOp +RhBYjbWPNJ80OFnJ0282dQN2ED6axkv7Bbzec2ro6JPvm7CU6iQF8ddde959L2Z BZg2fe/n7xt3jDSeFwAMSZRX9QMWTulI3R/L/WRWaqEHiK2viO++XyC4vDPGQiDm OFAb5zkBDs7XgAwh9ehZJBDsP31xRcS0J3dCfLhtkDvQxgU/9ZBVOwAAXY9o7AAR rgJiZSlycBDu1ikshzC2msffY5mtCHhrPPEJEW0rHKPp0YggnFiWNVW0G75aEMDt 8kRpOKWyo19rJ7YM1YmmcYjBtbw+VPaf2vRNfNJSVJY/9Qk5uj+cxoQwbkkVgZJ6 x6lAWV38xm5N4CzkqggMBLFE5suNZXIG1YeZBGF42RrPhFj0odiQvW56LH26Q9Vv 95Y86sbQ/mMQq/PkwqLlKhXV3ituWxZp/2Q30pQFBkGFuAkJyvAJnq22UDHYavZN IwJFjBCOWUHugiQKDu0kI1VQAoSUv1zJQaGlDJeYrxW2+OC3laRhiA8tZP9lIcYK XNKYuu4nxKbICqqn0lMPfSXXyBBsJWOrc8xNuOeDeqBQV2EoLfU= =zo8M -----END PGP SIGNATURE----- --Apple-Mail=_C06A53EB-36F0-4D5C-B134-D0787961ED42-- From nobody Thu Apr 4 10:20:11 2019 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 7FE5112000F for ; Thu, 4 Apr 2019 10:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 afjl1oorCkLV for ; Thu, 4 Apr 2019 10:20:06 -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 9008F12009E for ; Thu, 4 Apr 2019 10:20:05 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id y6so2770457ljd.12 for ; Thu, 04 Apr 2019 10:20:05 -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=wzCdx7x9ri8OZPy830w4qJCmlZ4wzF+vZGCxpCRowrE=; b=pMFhrlfjRKJ8jv2iAcCEljk7zYH6hFWE195D3ho6TXCasnEgvD0k4eLOVxkfJhjIX0 olKvR9dMIlEtgHG74UVatZjiJzqBht8OZl6hrbdekkg3F/Vg2GCTnRW3r92JoXEmF9LO 0Wdqu2eXphZ9os+9SFjmOzrdfzttWYu0xqbvIvBVoWN3fDQBFLvGHSuZfy0mAVYiPKpd pZf97R9WWH74Ofzqr+xSKHikCksihDyNjNmhiyyYkRbuXNymylpssHX6/hal6VCFZBX5 XX8UrYHCvYRQZn32IMkloAGWW+EYgRlCEPKovx5BrBbYnXb8oh/e62KN8MCQfl/qvwKn q76Q== 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=wzCdx7x9ri8OZPy830w4qJCmlZ4wzF+vZGCxpCRowrE=; b=hImzrStbYo/VIk87ryIpwoJxtgxPzQg/sxuzPMRksVZU5EKZbwEkgNqHyUeQnNQphd 55/xrnnoqGm/p/W7TJb617TwFpo1it3YqTmfZqJVpHT8qittMnDbsfGOM/YbJ3wczy2/ DMAeLh8s2cCkTC+3lwHnvCwH6O5w9SgG/g1fePlbadlrJPyehgE4SSyXHIzFubKKuVlx 9jT3GGbP0tQxaHgFfsVjqUElzU+yJ7BMKbDbjs8KStuyM6XOBB6M5f/S2WchFbJ2H3Nn MXQiO7ZFzwZEg9e3kNEMT8hYI45YEthkEU8vNO63yy4B8TrUlKLsPzxhFlPJ1dcaSiOB taaQ== X-Gm-Message-State: APjAAAWNxq+zGIh+Oabugs+2PLjClqP5rQoI4Vyc90i5GLRd8172rT/9 N3o9aN7OOtbBV2I+/2/T2sAyagy9Ibiui63l8PLPHQ== X-Google-Smtp-Source: APXvYqwI6jjIpSGj6ZJpJI+Bujebz6eILjS2C+NcQyDDDRjx+XUXFnVnW1ezKclK80YLJlAHA02bUJ06Np5+A8e6IPg= X-Received: by 2002:a2e:950:: with SMTP id 77mr4131464ljj.113.1554398403470; Thu, 04 Apr 2019 10:20:03 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Vittorio Bertocci Date: Thu, 4 Apr 2019 10:19:51 -0700 Message-ID: To: Brian Campbell Cc: David Waite , George Fletcher , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000adc67d0585b79401" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:20:10 -0000 --000000000000adc67d0585b79401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But before I get in the details, let me make an uber-point. I am acutely aware of the potential for confusion and abuse in the context of OAuth and sign in, the article you pointed to quotes my own articles on the matter extensively. But there are concrete aspects that need to be considered about what developers are trying to achieve in practice. OAuth2 is the de facto mechanism to secure API calls nowadays. That includes scenarios not directly addressed by the spec, such as first party APIs. People do that for 1st party APIs as well because they can leverage a well supported mechanism for driving authentication experiences and outsource authentication to products and services. Forgetting for a second about the fact that 3rd party APIs can use identity and authentication levels info as well, let me focus for a second on 1st party APIs. From the functionality perspective, delivering an app as a web site or as a native client+API combination doesn't change the business requirements and the information a backend needs to do its job. Given that we tell people NOT to use ID tokens for calling APIs: if a developer chooses to deliver their app as a native client+API instead of a web site, the only artifact they have available is the access token. So either we embed the info in the access token, and we do what we can to prevent abuse and the most likely pitfalls/privacy challenges/etc in the guidance, or we find a way for 1st party APIs to consume ID tokens (which is problematic- I discussed this with John and Nat at OSW and the place we got stuck on was that we can; safely use sender constrain in that scenario). And to pre-empt comments on userinfo, that's asking for a lot of extra moving parts- the only outcome will be that people will keep embedding the info they need in the AT, but will do so in non-interoperable way, and without the guidance and warnings that would at least contain some of the damage. That said, inline. My concern isn't with reusing the names/types of the claims per se. But > more generally that codifying the use of certain authentication-centric > claims in the context of an access token furthers the potential confusion > around authentication vs. authorization that has been a nagging problem f= or > OAuth (i.e. the https://oauth.net/articles/authentication/ article). see preamble. I understand what you are saying but but personally do not find it > sufficiently compelling. But that's just my opinion and not a hill I wan= t > to die on (at the present time anyway).. Noted :) does the fact that in some scenarios the AT might be the *only* artifact a backend will receive change the stance? By the time it came up again near the end of the last unconference > session, I wasn't wanting to prolong things because I was kinda worn out > for the day and wanting to get to Frankfurt that evening before sunset > ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ). Sorry for having tired you out :) at the time I echoed back what was suggested (to reflect the original values in the session) precisely to make sure everyone had a chance to push back, and I got lots of nods (including from John who was in the first row). I misinterpreted your silence as assent, given that during that session you did chime in on other matters.. but I was expecting the discussion to keep going on the ML anyway, so it's all according to plan :) FWIW, to me, George's suggestion "assume[ing] that the auth_time value > should be updated to the latest time at which the user authenticated" > though some unspecified and in many cases non-existent link between the A= T > and a current user session at the AS is an example of how > authentication-centric claims in an access token can be confusing. I agree it can be confusing, but to me that makes the need to provide guidance on it more compelling, not less. There are important scenarios where access decisions are made on the basis of that information, and implementations WILL find a way to get the info they are interested into. To me that's all the more reasons to provide guidance on how to do so being aware of pitfalls and with whatever protections we can put in place, as opposed to leave developers to their own device. On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell wrote: > A few remarks/responses inline below this time... > > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> Thanks guys for the comment, sorry for the delay in addressing them. >> I am not married to the claim types used in here, so if you think that >> reusing the ones in the id_token can cause confusion we should expand on >> the specific ways in which you think might go south. >> > > My concern isn't with reusing the names/types of the claims per se. But > more generally that codifying the use of certain authentication-centric > claims in the context of an access token furthers the potential confusion > around authentication vs. authorization that has been a nagging problem f= or > OAuth (i.e. the https://oauth.net/articles/authentication/ article). > > > However I think it's important that the information on say, whether the >> current token was obtained using MFA or a specific authentication factor= is >> something that API developers can legitimately latch to when doing >> authorization decisions. From the perspective of a developer modeling a >> solution, whether functionality is delivered as a route in a postback ba= sed >> web app (hence receiving an id_token or derived) or as an API consumed b= y a >> native app, the business requirement gating access to that functionality >> doesn't change. If the admin managing that resource establishes that acc= ess >> should be performed only via MFA, the developer should be equipped to >> enforce that regardless of the stack used to expose functionality (web a= pp, >> API). >> Although it is true that triggering the desired behavior might be >> achieved by the resource setting and contract with the AS, along the lin= es >> of what David said, it's actually not uncommon for those policies to be >> assigned on the resource AFTER the current session was established and/o= r >> the corresponding AT was obtained and cached. Furthermore, the requireme= nt >> might be more granular than an AS policy can tolerate (an API might >> requires MFA only for certain routes, hence hard to express in a static >> policy) and triggered in form of challenges. So the situation in which y= ou >> have an AT with the right issuer, audience, etc but was obtained with a >> policy now obsolete/unacceptable to the RP is strong. Requesting to supp= ort >> revocation just for this seems overkill, especially given that the scena= rio >> in which the same logical app is exposed as both web app and native >> client+API, the code consuming those claims is already in place. It just >> makes intuitive sense for developers. >> In summary, one can take steps to push as much of the MFA requirements t= o >> the AS settings for a particular request, but ultimately the desire of t= he >> API developer to enforce that it actually happened is a requirement I >> encountered often in practice. Anything providing extra context to refin= e >> decisions about it (like auth_time, which might inform decisions about >> whether to accept an MFA check occurred N minutes ago or refuse access). >> > > I understand what you are saying but but personally do not find it > sufficiently compelling. But that's just my opinion and not a hill I wan= t > to die on (at the present time anyway).. > > > >> I thought that reusing the existing names for the same concepts just mad= e >> sense (dev existing skills, existing codebases, etc etc) and especially = in >> the case in which the values are exactly the same, and the idea seemed t= o >> receive good support during OSW. >> > > Our recollection of OSW differs somewhat. As I recall there was support > for pointing to identity claims from OIDC for additional end-user info. B= ut > there was some grumbling (from John and myself at least) at first mention > of acr/amr and auth_time. By the time it came up again near the end of th= e > last unconference session, I wasn't wanting to prolong things because I w= as > kinda worn out for the day and wanting to get to Frankfurt that evening > before sunset ('cause I like to do stuff like this: > https://flic.kr/p/2fiAaPe :) ). > > > >> But I am completely open to change it of course, especially for cases >> like the one identified by George. >> > > FWIW, to me, George's suggestion "assume[ing] that the auth_time value > should be updated to the latest time at which the user authenticated" > though some unspecified and in many cases non-existent link between the A= T > and a current user session at the AS is an example of how > authentication-centric claims in an access token can be confusing. > > > > >> WDYT? >> >> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> +1 to David's question here. I'd like to see justifying use cases >>> (beyond just the fact that some people are already doing it) for auth_t= ime, >>> acr, and amr to be available in OAuth JWT access tokens.. Those claims = are >>> defined for, and in the context of, an ID Token and I fear that codifyi= ng >>> their use in an access token will lead to misuse and/or confusion. >>> >>> On Mon, Apr 1, 2019 at 1:03 PM David Waite >>> wrote: >>> >>>> Do we know if there is a justifying use case for auth_time, acr, and >>>> amr to be available in OAuth JWT access tokens? These are meant to be >>>> messages about the client, either directly (in the case of client >>>> credentials) or about its delegated authorization of the user. >>>> >>>> Embedding attributes about the user (such as group membership and >>>> roles) can be used for the resource to make finer-grained decisions th= an >>>> scopes, but normally I would expect say acr limitations enforced by a >>>> resource to instead be controlled by the AS requiring a higher quality >>>> authentication to release certain scopes. >>>> >>>> Thats of course not to say extensions to OAuth such as OIDC can=E2=80= =99t >>>> provide these values, just that they might better be defined by those >>>> extensions. >>>> >>>> -DW >>>> >>>> On Apr 1, 2019, at 9:12 AM, George Fletcher < >>>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>>> >>>> Thanks for writing this up. One comment on auth_time... >>>> >>>> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >>>> Important: as this claim represents the time at which the end us= er >>>> authenticated, its value will remain the same for all the JWT >>>> access tokens issued within that session. For example: all the >>>> JWT access tokens obtained with a given refresh token will all >>>> have the same value of auth_time, corresponding to the instant i= n >>>> which the user first authenticated to obtain the refresh token. >>>> >>>> >>>> During a current session a user can be challenged for additional >>>> credentials or required to re-authenticate due to a number of differen= t >>>> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this co= ntext, >>>> I'd assume that the auth_time value should be updated to the latest ti= me at >>>> which the user authenticated. >>>> >>>> If we need a timestamp for when the "session" started, then there coul= d >>>> be a session_start_time claim. >>>> >>>> Thanks, >>>> George >>>> >>>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>>> >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt= / >>>> . >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JW= T for >>>> their access token. The intent and scenarios addressed by those sol= utions >>>> are mostly the same across vendors, but the syntax and interpretati= ons in >>>> the implementations are different enough to prevent developers from= reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK Y= OU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens an= d >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_= -_a_jwt_profile_for_ats.pptx >>>> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedbac= k and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvi= nov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a no= te and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. R= ifaat, >>>> Hannes and above all Brian were all super helpful in negotiating th= e >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the proc= ess. >>>> This is an amazing community. >>>> V. >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://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 >>>> >>> >>> *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 >>> >> > *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.* --000000000000adc67d0585b79401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But before I get in the details, let me make an uber-point= .=C2=A0
I am acutely aware of the potential for confusion and abuse in = the context of OAuth and sign in, the article you pointed to quotes my own = articles on the matter extensively. But there are concrete aspects that nee= d to be considered about what developers are trying to achieve in practice.=
OAuth2 is the de facto mechanism to secure API calls nowadays. That in= cludes scenarios not directly addressed by the spec, such as first party AP= Is. People do that for 1st party APIs as well because they can leverage a w= ell supported mechanism for driving authentication experiences and outsourc= e authentication to products and services.=C2=A0
Forgetting= for a second about the fact that 3rd party APIs can use identity and authe= ntication levels info as well, let me focus for a second on 1st party APIs.= From the functionality perspective, delivering an app as a web site or as = a native client+API combination doesn't change the business requirement= s and the information a backend needs to do its job.=C2=A0
Given = that we tell people NOT to use ID tokens for calling APIs: if a developer c= hooses to deliver their app as a native client+API instead of a web site, t= he only artifact they have available is the access token. So either we embe= d the info in the access token, and we do what we can to prevent abuse and = the most likely pitfalls/privacy challenges/etc in the guidance, or we find= a way for 1st party APIs to consume ID tokens (which is problematic- I dis= cussed this with John and Nat at OSW and the place we got stuck on was that= we can; safely use sender constrain in that scenario). And to pre-empt com= ments on userinfo, that's asking for a lot of extra moving parts- the o= nly outcome will be that people will keep embedding the info they need in t= he AT, but will do so in non-interoperable way, and without the guidance an= d warnings that would at least contain some of the damage.

That said, inline.

My concern isn't with reusing the names/types = of the claims per se.=C2=A0 But more generally that codifying the use of ce= rtain authentication-centric claims in the context of an access token furth= ers the potential confusion around authentication vs. authorization that ha= s been a nagging problem for OAuth (i.e. the=C2=A0https://oauth.net/articles/authentication/=C2=A0article= ).=C2=A0
see preamble.<= /span>

=C2=A0understand what you are saying but but person= ally do not find it sufficiently compelling.=C2=A0 But that's just my o= pinion and not a hill I want to die on (at the present time anyway)..= =C2=A0
Noted :) does the fact that in some s= cenarios the AT might be the *only* artifact a backend will receive change = the stance?

=C2=A0By the time it came up again near the end of the last unconf= erence session, I wasn't wanting to prolong things because I was kinda = worn out for the day and wanting to get to Frankfurt that evening before su= nset ('cause I like to do stuff like this:=C2=A0https://flic.kr/= p/2fiAaPe=C2=A0:) ).
Sorry for h= aving tired you out :) at the time I echoed back what was suggested (to ref= lect the original values in the session) precisely to make sure everyone ha= d a chance to push back, and I got lots of nods (including from John who wa= s in the first row). I misinterpreted your silence as assent, given that du= ring that session you did chime in on other matters.. but I was expecting t= he discussion to keep going on the ML anyway, so it's all according to = plan :)

=C2=A0FWIW, to me, George's suggestion "assume[ing] that the = auth_time value should be updated to the latest time at which the user auth= enticated" though some unspecified and in many cases non-existent link= between the AT and a current user session at the AS is an example of how a= uthentication-centric claims in an access token can be confusing.=C2= =A0
=C2=A0I agree it can be confusing, but t= o me that makes the need to provide guidance on it more compelling, not les= s. There are important scenarios where access decisions are made on the bas= is of that information, and implementations WILL find a way to get the info= they are interested into. To me that's all the more reasons to provide= guidance on how to do so being aware of pitfalls and with whatever protect= ions we can put in place, as opposed to leave developers to their own devic= e.=C2=A0

On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <bcampbell= =3D40pingidentity.com@= dmarc.ietf.org> wrote:
A few rema= rks/responses inline below this time...

On Wed, Apr 3, 2019 at 1:38 PM = Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Thanks guy= s for the comment, sorry for the delay in addressing them.
I am not mar= ried to the claim types used in here, so if you think that reusing the ones= in the id_token can cause confusion we should expand on the specific ways = in which you think might go south.

<= div>My concern isn't with reusing the names/types of the claims per se.= =C2=A0 But more generally that codifying the use of certain authentication-= centric claims in the context of an access token furthers the potential con= fusion around authentication vs. authorization that has been a nagging prob= lem for OAuth (i.e. the https://oauth.net/articles/authentication/ articl= e).
=C2=A0

However I think it's importa= nt that the information on say, whether the current token was obtained usin= g MFA or a specific authentication factor is something that API developers = can legitimately latch to when doing authorization decisions. From the pers= pective of a developer modeling a solution, whether functionality is delive= red as a route in a postback based web app (hence receiving an id_token or = derived) or as an API consumed by a native app, the business requirement ga= ting access to that functionality doesn't change. If the admin managing= that resource establishes that access should be performed only via MFA, th= e developer should be equipped to enforce that regardless of the stack used= to expose functionality (web app, API).=C2=A0
Although it is tru= e that triggering the desired behavior might be achieved by the resource se= tting and contract with the AS, along the lines of what David said, it'= s actually not uncommon for those policies to be assigned on the resource A= FTER the current session was established and/or the corresponding AT was ob= tained and cached. Furthermore, the requirement might be more granular than= an AS policy can tolerate (an API might requires MFA only for certain rout= es, hence hard to express in a static policy) and triggered in form of chal= lenges. So the situation in which you have an AT with the right issuer, aud= ience, etc but was obtained with a policy now obsolete/unacceptable to the = RP is strong. Requesting to support revocation just for this seems overkill= , especially given that the scenario in which the same logical app is expos= ed as both web app and native client+API, the code consuming those claims i= s already in place. It just makes intuitive sense for developers.=C2=A0 =C2= =A0
In summary, one can take steps to push as much of the MFA req= uirements to the AS settings for a particular request, but ultimately the d= esire of the API developer to enforce that it actually happened=C2=A0is a r= equirement I encountered often in practice. Anything providing extra contex= t to refine decisions about it (like auth_time, which might inform decision= s about whether to accept an MFA check occurred N minutes ago or refuse acc= ess).

I understand what you are= saying but but personally do not find it sufficiently compelling.=C2=A0 Bu= t that's just my opinion and not a hill I want to die on (at the presen= t time anyway)..
=C2=A0


I th= ought that reusing the existing names for the same concepts just made sense= (dev existing skills, existing codebases, etc etc) and especially in the c= ase in which the values are exactly the same, and the idea seemed to receiv= e good support during OSW.

Our = recollection of OSW differs somewhat. As I recall there was support for poi= nting to identity claims from OIDC for additional end-user info. But there = was some grumbling (from John and myself at least) at first mention of acr/= amr and auth_time. By the time it came up again near the end of the last un= conference session, I wasn't wanting to prolong things because I was ki= nda worn out for the day and wanting to get to Frankfurt that evening befor= e sunset ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).

=C2=A0
But I am completely open to change it of = course, especially for cases like the one identified by George.
=

FWIW, to me, George's suggestion "= ;assume[ing] that the auth_time value should be updated to the latest time = at which the user authenticated" though some unspecified and in many c= ases non-existent link between the AT and a current user session at the AS = is an example of how authentication-centric claims in an access token can b= e confusing.


=C2=A0
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
+1 to David's q= uestion here. I'd like to see justifying use cases (beyond just the fac= t that some people are already doing it) for auth_time, acr, and amr to be = available in OAuth JWT access tokens.. Those claims are defined for, and in= the context of, an ID Token and I fear that codifying their use in an acce= ss token will lead to misuse and/or confusion.

On Mon, Apr 1, 201= 9 at 1:03 PM David Waite <david@alkaline-solutions.com> wrote:
Do we know if there is= a justifying use case for auth_time, acr, and amr to be available in OAuth= JWT access tokens? These are meant to be messages about the client, either= directly (in the case of client credentials) or about its delegated author= ization of the user.

Embedding attributes abou= t the user (such as group membership and roles) can be used for the resourc= e to make finer-grained decisions than scopes, but normally I would expect = say acr limitations enforced by a resource to instead be controlled by the = AS requiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such a= s OIDC can=E2=80=99t provide these values, just that they might better be d= efined by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, George Fletcher <= gf= fletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20 =20
Thanks for writing this up. One comment on auth_time...

   auth_time  OPTIONAL - as defined =
in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume= that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then= there could be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio= Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,= =C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

____________________________=
___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/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

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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you. --000000000000adc67d0585b79401-- From nobody Thu Apr 4 10:35:14 2019 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 EE0AF1201CF for ; Thu, 4 Apr 2019 10:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 pH7fnmWfWZWe for ; Thu, 4 Apr 2019 10:35:09 -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 00DD6120115 for ; Thu, 4 Apr 2019 10:35:08 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id a28so2394534lfo.7 for ; Thu, 04 Apr 2019 10:35:08 -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=YgZ28ChMjQRq9No0Zx/Qs7GrzM0NtLnf+EAbSq0gWig=; b=MykCBnjx2CCkPA4i/zpDSxG+HxuiCLSsNCuzx5vP+BRgtavliEZxkubjb8ouU4mDrH 69gDl0CbohRUdcap0b22NIgsCJa9wso6+JnvmEitzelWfueFbLxrQRNVv2+MJYa0Wqvg 278rQZ8kLN4Asm9stJTBqI0kpzDHBgjMldxZf6erRt6LrgTIngJqsOHIz5hkLCg2AzkB hNZtBGfOmv/Ze83iALJsBHA7FGEDf7t8WRU+T5XhDRtYNdtjkUa93yCi4XQ2ngOUHmm3 JUJtwYcl8RL85aG92FdhtaiP9Z4wf4riqhZa/Ud/lK4cwGCZjqoCQY/ybNHYIA9CHckr SaeA== 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=YgZ28ChMjQRq9No0Zx/Qs7GrzM0NtLnf+EAbSq0gWig=; b=jSxBh6M7xUhy0RgXJ6jkrLUbiMaqW309gRDsAwkzwG3RFs4FcThTbjGOdtfJczMVl+ XGP1EH14qfn07uHGqe1oxmn7Zl/RfELTsjItmoU4TuS6kuu+P21NZXDHoVvNpkcCtLzJ Wh3Dp78svh+i898pl6th+FlHHmhvm+M/qVTIFDx83xqQyisqNpj2P7J2HKnA+wUBEzhT DfMnRIE1GvcJH7AJDI9Rs4QxG/uNtV/majn6Bv98zbcPzy45rF+w0bj57pUsP5Kh1A1y s3qEsyGdaJ19z07i3b1HRutOzMb51c/crSjtSK76/Pw7YJ6zgC3Bq2d4sORDIbZSTNSI IrxA== X-Gm-Message-State: APjAAAXCHf+iusa8hWn07l10blMY28vpzK0ftwHVd7HSpk9If1oyoHGH kTbxy6THAeN0jgmCNFpFMmRR2uUIonht2NPE0H6tnQ== X-Google-Smtp-Source: APXvYqx3iiNMePkYJRMwMF4KY02XrQUKt81HScCBIdokGndCp5raQCYq4V9lXlWqWxKzYTirOzXnT8WKp6xaU5l7TQg= X-Received: by 2002:a19:4f44:: with SMTP id a4mr3978987lfk.72.1554399306902; Thu, 04 Apr 2019 10:35:06 -0700 (PDT) MIME-Version: 1.0 References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> In-Reply-To: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> From: Vittorio Bertocci Date: Thu, 4 Apr 2019 10:34:54 -0700 Message-ID: To: George Fletcher Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000008705480585b7ca55" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:35:13 -0000 --0000000000008705480585b7ca55 Content-Type: text/plain; charset="UTF-8" Hey George! Thanks for the comments. nline The issue here is that the 'aud' of the id_token is the recipient of the > id_token (i.e. the client). However, for access_tokens the 'aud' value > should be the resource service that will receive the access_token. There is > no existing guidance for this and we should provide such guidance as this > is "kind of new" for OAuth2 (from an explicit specification perspective). Fair enough. We do provide more specific guidance on the use of audience for API, the language you quote later on being an example of that. Also, there is the concept of 'azp' from the id_token which amounts to > "who's allowed to present this token" which might be interesting from the > case where one entity obtains the token, and gives it to another entity to > present. Not sure if we want to include this concept or not. We embedded that in the client_id claim. I originally had azp but got strong pushback, given the debacle it caused in the past (see https://bitbucket.org/openid/connect/issues/1009/contradictory-statements-about-id-token?fbclid=IwAR2iPZcEStXGXB-9SW0889Ky1cpKbK8h1WdjyQX2PKMly4nN6050Na4KfYw , https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and?fbclid=IwAR0IN6JT_jPqukOzsbegJLY2MXl1xnplURjXoxSyhd3kvgfw6Nj6LsPLU5M ). I think for most implementations this would amount to... define an audience > that covers all the resource services where the access token can be > returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is > perfectly legal but maybe not in the spirit of the spec:) I am receiving > feedback from developers that binding access tokens narrowly to the > resource where they will be presented is concerning from a chattiness > perspective (latency issues) and general load on the deployed AS > infrastructure. This is an interesting point. In my experience, the main boundary used to define a resource is either reflecting an underlying, *actual* resource that exists independently of the API facade slapped on top of it (say a VM) or it is the context within a certains et of scopes makes sense (say an API facading access to a bunch of documents). Some of that criterion is reflected in the rationale for sigle value audiences. Do you think it should be made more explicit? Perhaps in a dedicated section? On Thu, Apr 4, 2019 at 7:07 AM George Fletcher wrote: > Another comment... > > aud REQUIRED - as defined in section 2 of [OpenID.Core ]. See > Section 3 for indications on how an authorization server should > determine the value of aud depending on the request. [Note: some > vendors seem to rely on resource aliases. If we believe this to > be a valuable feature, here's some proposed language: The aud > claim MAY include a list of individual resource indicators if they > are all aliases referring to the same requested resource known by > the authorization server. ] > > > > I don't think OpenID.Core Section 3 is the correct reference for > determining the 'aud' value. The issue here is that the 'aud' of the > id_token is the recipient of the id_token (i.e. the client). However, for > access_tokens the 'aud' value should be the resource service that will > receive the access_token. There is no existing guidance for this and we > should provide such guidance as this is "kind of new" for OAuth2 (from an > explicit specification perspective). > > Also, there is the concept of 'azp' from the id_token which amounts to > "who's allowed to present this token" which might be interesting from the > case where one entity obtains the token, and gives it to another entity to > present. Not sure if we want to include this concept or not. > > Finally, I think we may need some best practice around how the concept of > audience and resource should be managed. For instance... > > If the request does not include a resource parameter, the > authorization server MUST use in the aud claim a default resource > indicator. If a scope parameter is present in the request, the > authorization server SHOULD use it to infer the value of the default > resource indicator to be used in the aud claim. > > > I think for most implementations this would amount to... define an > audience that covers all the resource services where the access token can > be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which > is perfectly legal but maybe not in the spirit of the spec:) I am receiving > feedback from developers that binding access tokens narrowly to the > resource where they will be presented is concerning from a chattiness > perspective (latency issues) and general load on the deployed AS > infrastructure. > > On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this doc > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT for > their access token. The intent and scenarios addressed by those solutions > are mostly the same across vendors, but the syntax and interpretations in > the implementations are different enough to prevent developers from reusing > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Dominick > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback and > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process. > This is an amazing community. > V. > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --0000000000008705480585b7ca55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey George! Thanks for t= he comments. nline

The issue he= re is that the 'aud' of the id_token is the recipient of the id_tok= en (i.e. the client). However, for access_tokens the 'aud' value sh= ould be the resource service that will receive the access_token. There is n= o existing guidance for this and we should provide such guidance as this is= "kind of new" for OAuth2 (from an explicit specification perspec= tive).
Fair enough. We do provide more specific gui= dance on the use of audience for API, the language you quote later on being= an example of that.

=C2=A0Also, there is the concept of 'azp' from the id_token which amoun= ts to "who's allowed to present this token" which might be in= teresting from the case where one entity obtains the token, and gives it to= another entity to present. Not sure if we want to include this concept or = not.

I think for most implementations this would amount to... define an = audience that covers all the resource services where the access token can b= e returned and set that as the audience (e.g. urn:x-mydomain:apis). Which i= s perfectly legal but maybe not in the spirit of the spec:) I am receiving = feedback from developers that binding access tokens narrowly to the resourc= e where they will be presented is concerning from a chattiness perspective = (latency issues) and general load on the deployed AS infrastructure.=
Th= is is an interesting point. In my experience, the main boundary used to def= ine a resource is either reflecting an underlying, *actual* resource that e= xists independently of the API facade slapped on top of it (say a VM) or it= is the context within a certains et of scopes makes sense (say an API faca= ding access to a bunch of documents).
Some of that criterion is reflected in t= he rationale for sigle value audiences. Do you think it should be made more= explicit? Perhaps in a dedicated section?
On Thu, = Apr 4, 2019 at 7:07 AM George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
Another comment...

   aud  REQUIRED - as=
 defined in section 2 of [OpenID.Core].  See
      Section 3 for indications on ho=
w an authorization server should
      determine the value of aud depending on the request.  [Note: some
      vendors seem to rely on resource aliases.  If we believe this to
      be a valuable feature, here's some proposed language: The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server. ]


I don't think OpenID.Core Section 3 is the correct reference for determining the 'aud' value. The issue here is that the '= aud' of the id_token is the recipient of the id_token (i.e. the client). However, for access_tokens the 'aud' value should be the reso= urce service that will receive the access_token. There is no existing guidance for this and we should provide such guidance as this is "kind of new" for OAuth2 (from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to "who's allowed to present this token" which = might be interesting from the case where one entity obtains the token, and gives it to another entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept of audience and resource should be managed. For instance...
   If the request doe=
s not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
On 3/24/19 7:= 29 PM, Vittorio Bertocci wrote:
=20
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access= -token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_= jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.

<= /fieldset> 
_____________=
__________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth

--0000000000008705480585b7ca55-- From nobody Thu Apr 4 10:40:28 2019 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 09497120113 for ; Thu, 4 Apr 2019 10:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 avIso8y9FXny for ; Thu, 4 Apr 2019 10:40:21 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 983731204D6 for ; Thu, 4 Apr 2019 10:40:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HDAQClQKZc/xwBYJlcAwYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWIFKmhxEicKhARigmiFMYxJfpdZgUIlCwUYDQmDeEYChU4iOBI?= =?us-ascii?q?BAQMBAQkBAwICAmkcDIJ4MRw+AQEBAQEBAQEBIwEBAQEBAQEjAg0HEh4SAQE?= =?us-ascii?q?YAQEBAQIBAQEhSwsFCwIBCBgWARMCAicLJQIEDgUOBgeDBwGBbQcBD646gS+?= =?us-ascii?q?DdD0BE0FAhF8KBYEwgUqISoEfgVg+JmsnH4FOLhs1PoJhAQECAQGBIQQFAQg?= =?us-ascii?q?KAQoHFSUMEAKCQDGCJgOKOgoyhyuSZ2IDBAICgSeDS4ISeoEmgjWEBBOECBq?= =?us-ascii?q?CBSqFaoMxiQWMZ4Q7SY18gWYiMTRxcUUKBSUBVR2BJimCFheBAQECgnuCcIE?= =?us-ascii?q?2O4U/PwEBMQGOHA0XgQiBHwEB?= X-IPAS-Result: =?us-ascii?q?A2HDAQClQKZc/xwBYJlcAwYcAQEBBAEBBwQBAYFlgWIFK?= =?us-ascii?q?mhxEicKhARigmiFMYxJfpdZgUIlCwUYDQmDeEYChU4iOBIBAQMBAQkBAwICA?= =?us-ascii?q?mkcDIJ4MRw+AQEBAQEBAQEBIwEBAQEBAQEjAg0HEh4SAQEYAQEBAQIBAQEhS?= =?us-ascii?q?wsFCwIBCBgWARMCAicLJQIEDgUOBgeDBwGBbQcBD646gS+DdD0BE0FAhF8KB?= =?us-ascii?q?YEwgUqISoEfgVg+JmsnH4FOLhs1PoJhAQECAQGBIQQFAQgKAQoHFSUMEAKCQ?= =?us-ascii?q?DGCJgOKOgoyhyuSZ2IDBAICgSeDS4ISeoEmgjWEBBOECBqCBSqFaoMxiQWMZ?= =?us-ascii?q?4Q7SY18gWYiMTRxcUUKBSUBVR2BJimCFheBAQECgnuCcIE2O4U/PwEBMQGOH?= =?us-ascii?q?A0XgQiBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="asc'?scan'208";a="14348503" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 19:40:02 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiBAClQKZcfRBhWMBcAwYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWIFgRKBAycKhARiiBmMSX6XWYFnCwUYDYQBRgKFbzgSAQEDAQE?= =?us-ascii?q?JAQMCFAEBFjojDIVKAQEBAQIBAQEhSwsFCwIBCBgWARMCAicLJQIEDgUOBge?= =?us-ascii?q?DBwGBbQgPrjqBL4QxARNBQIRfCgWBMIFKiEqCdz4maycfgU4uGzU+gmEBAQI?= =?us-ascii?q?BAYEhBAUBCAoBCgcVJQwQAoJAMYImA4o6CjKHK5JnYgMEAgKBJ4NLghJ6gSa?= =?us-ascii?q?CNYQEE4QIGoIFKoVqgzGJBYxnhDtJjXyBZiAyNHFxRQoFJQFVHYEmKYIWF4E?= =?us-ascii?q?BAQKCe4JwgTY7hT8/AQIwAY4cDReBCIEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="asc'?scan'208";a="19681674" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/AES256-SHA; 04 Apr 2019 19:40:00 +0200 Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP11EXC.ads.fraunhofer.de ([10.80.232.42]) with mapi id 14.03.0435.000; Thu, 4 Apr 2019 19:39:57 +0200 From: "Schanzenbach, Martin" To: Vittorio Bertocci CC: Brian Campbell , "IETF oauth WG" Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU6J1B/thS5xrVIYxSuUg+/ebS0aYniBsAgAMJJwCAACWdAIABXkmAgAANT4CAAAWdAA== Date: Thu, 4 Apr 2019 17:39:56 +0000 Message-ID: References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.80.233.50] x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24526.004 x-tm-as-result: No--9.298700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_905A86E1-3730-44BD-B1C4-D3433E2CC783"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:40:25 -0000 --Apple-Mail=_905A86E1-3730-44BD-B1C4-D3433E2CC783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vittorio, > On 4. Apr 2019, at 19:19, Vittorio Bertocci = wrote: >=20 > But before I get in the details, let me make an uber-point.. > I am acutely aware of the potential for confusion and abuse in the = context of OAuth and sign in, the article you pointed to quotes my own = articles on the matter extensively. But there are concrete aspects that = need to be considered about what developers are trying to achieve in = practice. > OAuth2 is the de facto mechanism to secure API calls nowadays. That = includes scenarios not directly addressed by the spec, such as first = party APIs. People do that for 1st party APIs as well because they can = leverage a well supported mechanism for driving authentication = experiences and outsource authentication to products and services. > Forgetting for a second about the fact that 3rd party APIs can use = identity and authentication levels info as well, let me focus for a = second on 1st party APIs. =46rom the functionality perspective, = delivering an app as a web site or as a native client+API combination = doesn't change the business requirements and the information a backend = needs to do its job. > Given that we tell people NOT to use ID tokens for calling APIs: if a = developer chooses to deliver their app as a native client+API instead of = a web site, the only artifact they have available is the access token. = So either we embed the info in the access token, and we do what we can = to prevent abuse and the most likely pitfalls/privacy challenges/etc in = the guidance, or we find a way for 1st party APIs to consume ID tokens = (which is problematic- I discussed this with John and Nat at OSW and the = place we got stuck on was that we can; safely use sender constrain in = that scenario). > And to pre-empt comments on userinfo, that's asking for a lot of extra = moving parts- the only outcome will be that people will keep embedding = the info they need in the AT, but will do so in non-interoperable way, = and without the guidance and warnings that would at least contain some = of the damage. Userinfo is OIDC. Do you mean rfc7662? So you say that the use of a token introspection endpoint like rfc7662 = is not always viable, right? I kind of agree that you might want to have this information in the = token, if possible. You can save a lot of round trips over time (at the = expense of revocation). But then, we should simply take that (rfc7662) as a boilerplate for the = JWT, not OIDC. An introspection response also contains scopes, username and optional = additional claims (e.g. OIDC / authN specific claims). I think an access token JWT should not convey more / other information = than a token introspection endpoint. BR >=20 > That said, inline. >=20 > My concern isn't with reusing the names/types of the claims per se. = But more generally that codifying the use of certain = authentication-centric claims in the context of an access token furthers = the potential confusion around authentication vs. authorization that has = been a nagging problem for OAuth (i.e. the = https://oauth.net/articles/authentication/ article). > see preamble. >=20 > I understand what you are saying but but personally do not find it = sufficiently compelling. But that's just my opinion and not a hill I = want to die on (at the present time anyway).. > Noted :) does the fact that in some scenarios the AT might be the = *only* artifact a backend will receive change the stance? >=20 > By the time it came up again near the end of the last unconference = session, I wasn't wanting to prolong things because I was kinda worn out = for the day and wanting to get to Frankfurt that evening before sunset = ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ). > Sorry for having tired you out :) at the time I echoed back what was = suggested (to reflect the original values in the session) precisely to = make sure everyone had a chance to push back, and I got lots of nods = (including from John who was in the first row). I misinterpreted your = silence as assent, given that during that session you did chime in on = other matters.. but I was expecting the discussion to keep going on the = ML anyway, so it's all according to plan :) >=20 > FWIW, to me, George's suggestion "assume[ing] that the auth_time = value should be updated to the latest time at which the user = authenticated" though some unspecified and in many cases non-existent = link between the AT and a current user session at the AS is an example = of how authentication-centric claims in an access token can be = confusing. > I agree it can be confusing, but to me that makes the need to provide = guidance on it more compelling, not less. There are important scenarios = where access decisions are made on the basis of that information, and = implementations WILL find a way to get the info they are interested = into. To me that's all the more reasons to provide guidance on how to do = so being aware of pitfalls and with whatever protections we can put in = place, as opposed to leave developers to their own device. >=20 > On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell = wrote: > A few remarks/responses inline below this time... >=20 > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci = wrote: > Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim types used in here, so if you think that = reusing the ones in the id_token can cause confusion we should expand on = the specific ways in which you think might go south. >=20 > My concern isn't with reusing the names/types of the claims per se. = But more generally that codifying the use of certain = authentication-centric claims in the context of an access token furthers = the potential confusion around authentication vs. authorization that has = been a nagging problem for OAuth (i.e. the = https://oauth.net/articles/authentication/ article). >=20 >=20 > However I think it's important that the information on say, whether = the current token was obtained using MFA or a specific authentication = factor is something that API developers can legitimately latch to when = doing authorization decisions. =46rom the perspective of a developer = modeling a solution, whether functionality is delivered as a route in a = postback based web app (hence receiving an id_token or derived) or as an = API consumed by a native app, the business requirement gating access to = that functionality doesn't change. If the admin managing that resource = establishes that access should be performed only via MFA, the developer = should be equipped to enforce that regardless of the stack used to = expose functionality (web app, API). > Although it is true that triggering the desired behavior might be = achieved by the resource setting and contract with the AS, along the = lines of what David said, it's actually not uncommon for those policies = to be assigned on the resource AFTER the current session was established = and/or the corresponding AT was obtained and cached. Furthermore, the = requirement might be more granular than an AS policy can tolerate (an = API might requires MFA only for certain routes, hence hard to express in = a static policy) and triggered in form of challenges. So the situation = in which you have an AT with the right issuer, audience, etc but was = obtained with a policy now obsolete/unacceptable to the RP is strong. = Requesting to support revocation just for this seems overkill, = especially given that the scenario in which the same logical app is = exposed as both web app and native client+API, the code consuming those = claims is already in place. It just makes intuitive sense for = developers. > In summary, one can take steps to push as much of the MFA requirements = to the AS settings for a particular request, but ultimately the desire = of the API developer to enforce that it actually happened is a = requirement I encountered often in practice. Anything providing extra = context to refine decisions about it (like auth_time, which might inform = decisions about whether to accept an MFA check occurred N minutes ago or = refuse access). >=20 > I understand what you are saying but but personally do not find it = sufficiently compelling. But that's just my opinion and not a hill I = want to die on (at the present time anyway).. >=20 >=20 >=20 > I thought that reusing the existing names for the same concepts just = made sense (dev existing skills, existing codebases, etc etc) and = especially in the case in which the values are exactly the same, and the = idea seemed to receive good support during OSW. >=20 > Our recollection of OSW differs somewhat. As I recall there was = support for pointing to identity claims from OIDC for additional = end-user info. But there was some grumbling (from John and myself at = least) at first mention of acr/amr and auth_time. By the time it came up = again near the end of the last unconference session, I wasn't wanting to = prolong things because I was kinda worn out for the day and wanting to = get to Frankfurt that evening before sunset ('cause I like to do stuff = like this: https://flic.kr/p/2fiAaPe :) ). >=20 >=20 > But I am completely open to change it of course, especially for cases = like the one identified by George. >=20 > FWIW, to me, George's suggestion "assume[ing] that the auth_time value = should be updated to the latest time at which the user authenticated" = though some unspecified and in many cases non-existent link between the = AT and a current user session at the AS is an example of how = authentication-centric claims in an access token can be confusing. >=20 >=20 >=20 > WDYT? >=20 > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell = wrote: > +1 to David's question here. I'd like to see justifying use cases = (beyond just the fact that some people are already doing it) for = auth_time, acr, and amr to be available in OAuth JWT access tokens.. = Those claims are defined for, and in the context of, an ID Token and I = fear that codifying their use in an access token will lead to misuse = and/or confusion. >=20 > On Mon, Apr 1, 2019 at 1:03 PM David Waite = wrote: > Do we know if there is a justifying use case for auth_time, acr, and = amr to be available in OAuth JWT access tokens? These are meant to be = messages about the client, either directly (in the case of client = credentials) or about its delegated authorization of the user. >=20 > Embedding attributes about the user (such as group membership and = roles) can be used for the resource to make finer-grained decisions than = scopes, but normally I would expect say acr limitations enforced by a = resource to instead be controlled by the AS requiring a higher quality = authentication to release certain scopes. >=20 > Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99= t provide these values, just that they might better be defined by those = extensions. >=20 > -DW >=20 >> On Apr 1, 2019, at 9:12 AM, George Fletcher = wrote: >>=20 >> Thanks for writing this up. One comment on auth_time... >>=20 >> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core >> ]. >> Important: as this claim represents the time at which the end = user >> authenticated, its value will remain the same for all the JWT >> access tokens issued within that session. For example: all the >> JWT access tokens obtained with a given refresh token will all >> have the same value of auth_time, corresponding to the instant = in >> which the user first authenticated to obtain the refresh token. >>=20 >>=20 >> During a current session a user can be challenged for additional = credentials or required to re-authenticate due to a number of different = reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this = context, I'd assume that the auth_time value should be updated to the = latest time at which the user authenticated. >>=20 >> If we need a timestamp for when the "session" started, then there = could be a session_start_time claim. >>=20 >> Thanks, >> George >>=20 >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>>=20 >>> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>> =E2=80=A2 Despite OAuth2 not requiring any specific format for = ATs, through the years I have come across multiple proprietary solution = using JWT for their access token. The intent and scenarios addressed by = those solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >>> =E2=80=A2 I asked several individuals from key products and = services to share with me concrete examples of their JWT access tokens = (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!). >>> I studied and compared all those instances, identifying = commonalities and differences. >>> =E2=80=A2 I put together a presentation summarizing my findings = and suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. = Thx Filip! >>> =E2=80=A2 The presentation was followed up by 1.5 hours of = unconference discussion, which was incredibly valuable to get tight-loop = feedback and incorporate new ideas. John Bradley, Brian Campbell = Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig = were all there and contributed generously to the discussion. Thank = you!!! >>> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >>> =E2=80=A2 On my flight back I did my best to incorporate all the = ideas and feedback in a draft, which will be discussed at IETF104 = tomorrow. Rifaat, Hannes and above all Brian were all super helpful in = negotiating the mysterious syntax of the RFC format and submission = process. >>> I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community. >>> V. >>>=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 > _______________________________________________ > 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 > 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 Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenbach@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 --Apple-Mail=_905A86E1-3730-44BD-B1C4-D3433E2CC783 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlymQWwACgkQhDNRMeo9 q/B/9A/+K/r5Ym242fwXz6uWjSrdD5rjUFlmr7j+iVFJlXY1pgVzC6lbEYMxgV5J QMEw8gjy4IewY+SQzZ7RdodjhDL6ujGvjmcLhTyRwTmxBjFQWdFGVZ6HmMsEUCvV 4Yj6cP9Cb2Pj/JUTPK2n0h4kk3gZPH3rpk+orVjk89UZfa1vmUQfZ++8e47fJ7N5 g4tAnCywRAqCJCi7WF7L+cWfPiqHHKj2FK7AfYpCcEZ7HPCRPvo3BPC9AauQcoxf zevBCXQVFFhALVG7+sM/s5QbxXBvBuLov64TucyQERBDaA2GYFyW8L+RLsSwlhqg TRWojkiHlsrR8qKG0CGyJDBnZUfOXcE3oYLL5ZtduKIc0uVzBnmcVihNEelKjSLr 1/K14pHpUVStT3v8czraG81iMdfulUmtph/FcoUkgQ1p+6Lig2maX3565aZZZfZh /Un3+LsqzNdnHvrt59qAupop4DV/Sx0xM65On1UaFHRo9DOoH5Z7zPb/JPfZvgNb ywxL8/iasw0KOf/Mq8HNx9jz1B7y6Ryk0YzfRBLtg4qxBU7PSjE9pX+DCZc9b7Sl IpBifDaKLEg3LePUBE257FX49cKVL5kV3QGXooQwmePYIeuwNJu60BFjfrI48f4A ame0b2HaKKwz6v5KkpmXwwnz7w1o5BLeZ2kX6RlMRU6cEBgsHHQ= =q1jY -----END PGP SIGNATURE----- --Apple-Mail=_905A86E1-3730-44BD-B1C4-D3433E2CC783-- From nobody Thu Apr 4 10:41:09 2019 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 A400A12011B for ; Thu, 4 Apr 2019 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 lAj8qRU_ShGA for ; Thu, 4 Apr 2019 10:41:03 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 E1908120113 for ; Thu, 4 Apr 2019 10:40:56 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id l7so2849070ljg.6 for ; Thu, 04 Apr 2019 10:40:56 -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=rpmppDWBpq3sjRhdDoSAu4bZkGiBE2NTU+T/0NJ/OuE=; b=Gg47v73jBp505Uv6KJK6ooyzGCvO3E9w3fta1UT2O3e3ScsXM4EuS8/SW0JWfkgis+ xMiV73grSdhTH1YZAHlcKb+mgT0qKCFObQmULVtsda6/gc73H9oAGmWBiijCHz2Rvs3J /whgTW47x0YGK2NZ8etPxBap8dLsCciDxdTKy0BqKrDCXMjqepgJF4RPzDo1U5EFHdjW yCj5BxX7i7I5RoqfTtrtFHLwf3t+LcsgTKowIGV8+QwM1RXKz+A0COB4WcDIFluNnr51 xkVCGQgxiWRdnSOj+J1dwipAWSIqbFhMvB0/+nVJ+703Qwpwejjv2T8jDZrngKY9LoIc TqGA== 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=rpmppDWBpq3sjRhdDoSAu4bZkGiBE2NTU+T/0NJ/OuE=; b=X4pisd5AkaQ9Ky9FqawbgK0e8GSx5KS1QzmmOtiXyx+rNKsvQTafP0iZ/iekk7MUUP FgtXd/SsvnIv+Thljv3mIO37J47vq1YpzLh/Tdf2+tCyRAQyZP4w+n99ZOGsiUTtWzgZ uHv4j0VLaIA/RFOLQDeZTi13xEkMDQ8kjt7+queTo8cvtJBQZj85y2NC+PS2aCkB7eyR yhaMqs5cLj6NxO3ar3qvxs0KyF1o1PfiyGUIcOv/xhrabXxmwfD69/1BFupAHBtJUSQI HftmrtYtFQyvDri7jcZd2x4yw4A6gq7wKtK6S9wp12oWFOMIju2QvKgbxNw9Un91amJL iDkQ== X-Gm-Message-State: APjAAAXd0OinVPfP6Bnz8ZVQqQvGhjWlmYIjdvfSAYXbOS7ZkcyKqoBQ mJfj+de+X5ay19WWWfC30DKBtX4smt42WD2P7lKbUg== X-Google-Smtp-Source: APXvYqzn2ywLO/pOfV0ccMJcnOafjo0hXMIeK4MtqYskED9pZucFlOyKKWDM5rhA8QlFI3KbmY6/y77K2o5BEkYdjbo= X-Received: by 2002:a2e:8508:: with SMTP id j8mr4155260lji.26.1554399654873; Thu, 04 Apr 2019 10:40:54 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Vittorio Bertocci Date: Thu, 4 Apr 2019 10:40:43 -0700 Message-ID: To: George Fletcher Cc: Brian Campbell , David Waite , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000044b40e0585b7df02" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:41:08 -0000 --00000000000044b40e0585b7df02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > As an aside, I worry about trying to put all information needed to make a > dynamic policy decision into an access token. I am not suggesting any of this would be exhaustive. The intent is to give guidance on the most commonly used elements, stuff we already know is being considered. Besides achieving some level of interop, this can help educate readers on what are the things one typically watch out for- and could lead to better decisions even for other attributes they choose to add outside of the scope of this profile. > For cases where the policy can change over time including the lifetime of > the access_token then I prefer the User Managed Access (UMA) approach as = it > inherently allows for dynamic policy change I think simplicity is key here. Having the info available allows developers to be confident they can enforce their requirements transparently, using off the shelf software components. On Thu, Apr 4, 2019 at 7:14 AM George Fletcher wrote: > Comments inline... > > On 4/3/19 3:38 PM, Vittorio Bertocci wrote: > > Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim types used in here, so if you think that > reusing the ones in the id_token can cause confusion we should expand on > the specific ways in which you think might go south. > > I'm fine with re-using claims... we just need to make sure if we reuse a > claim it keeps the same semantic. > > However I think it's important that the information on say, whether the > current token was obtained using MFA or a specific authentication factor = is > something that API developers can legitimately latch to when doing > authorization decisions. From the perspective of a developer modeling a > solution, whether functionality is delivered as a route in a postback bas= ed > web app (hence receiving an id_token or derived) or as an API consumed by= a > native app, the business requirement gating access to that functionality > doesn't change. If the admin managing that resource establishes that acce= ss > should be performed only via MFA, the developer should be equipped to > enforce that regardless of the stack used to expose functionality (web ap= p, > API). > Although it is true that triggering the desired behavior might be achieve= d > by the resource setting and contract with the AS, along the lines of what > David said, it's actually not uncommon for those policies to be assigned = on > the resource AFTER the current session was established and/or the > corresponding AT was obtained and cached. Furthermore, the requirement > might be more granular than an AS policy can tolerate (an API might > requires MFA only for certain routes, hence hard to express in a static > policy) and triggered in form of challenges. So the situation in which yo= u > have an AT with the right issuer, audience, etc but was obtained with a > policy now obsolete/unacceptable to the RP is strong. Requesting to suppo= rt > revocation just for this seems overkill, especially given that the scenar= io > in which the same logical app is exposed as both web app and native > client+API, the code consuming those claims is already in place. It just > makes intuitive sense for developers. > In summary, one can take steps to push as much of the MFA requirements to > the AS settings for a particular request, but ultimately the desire of th= e > API developer to enforce that it actually happened is a requirement I > encountered often in practice. Anything providing extra context to refine > decisions about it (like auth_time, which might inform decisions about > whether to accept an MFA check occurred N minutes ago or refuse access). > > As an aside, I worry about trying to put all information needed to make a > dynamic policy decision into an access token. For cases where the policy > can change over time including the lifetime of the access_token then I > prefer the User Managed Access (UMA) approach as it inherently allows for > dynamic policy change. > > > I thought that reusing the existing names for the same concepts just made > sense (dev existing skills, existing codebases, etc etc) and especially i= n > the case in which the values are exactly the same, and the idea seemed to > receive good support during OSW. But I am completely open to change it of > course, especially for cases like the one identified by George. > WDYT? > > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> +1 to David's question here. I'd like to see justifying use cases (beyon= d >> just the fact that some people are already doing it) for auth_time, acr, >> and amr to be available in OAuth JWT access tokens. Those claims are >> defined for, and in the context of, an ID Token and I fear that codifyin= g >> their use in an access token will lead to misuse and/or confusion. >> >> On Mon, Apr 1, 2019 at 1:03 PM David Waite >> wrote: >> >>> Do we know if there is a justifying use case for auth_time, acr, and am= r >>> to be available in OAuth JWT access tokens? These are meant to be messa= ges >>> about the client, either directly (in the case of client credentials) o= r >>> about its delegated authorization of the user. >>> >>> Embedding attributes about the user (such as group membership and roles= ) >>> can be used for the resource to make finer-grained decisions than scope= s, >>> but normally I would expect say acr limitations enforced by a resource = to >>> instead be controlled by the AS requiring a higher quality authenticati= on >>> to release certain scopes. >>> >>> Thats of course not to say extensions to OAuth such as OIDC can=E2=80= =99t >>> provide these values, just that they might better be defined by those >>> extensions. >>> >>> -DW >>> >>> On Apr 1, 2019, at 9:12 AM, George Fletcher < >>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>> >>> Thanks for writing this up. One comment on auth_time... >>> >>> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core ]. >>> Important: as this claim represents the time at which the end use= r >>> authenticated, its value will remain the same for all the JWT >>> access tokens issued within that session. For example: all the >>> JWT access tokens obtained with a given refresh token will all >>> have the same value of auth_time, corresponding to the instant in >>> which the user first authenticated to obtain the refresh token. >>> >>> >>> During a current session a user can be challenged for additional >>> credentials or required to re-authenticate due to a number of different >>> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this con= text, >>> I'd assume that the auth_time value should be updated to the latest tim= e at >>> which the user authenticated. >>> >>> If we need a timestamp for when the "session" started, then there could >>> be a session_start_time claim. >>> >>> Thanks, >>> George >>> >>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: >>> >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= . >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT= for >>> their access token. The intent and scenarios addressed by those solu= tions >>> are mostly the same across vendors, but the syntax and interpretatio= ns in >>> the implementations are different enough to prevent developers from = reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YO= U >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-= _a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback= and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvin= ov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a not= e and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Ri= faat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the proce= ss. >>> This is an amazing community. >>> V. >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> _______________________________________________ >>> 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 f= ile >> attachments from your computer. Thank you.* >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --00000000000044b40e0585b7df02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an as= ide, I worry about trying to put all information needed to make a dynamic p= olicy decision into an access token.
I am not suggesting a= ny of this would be exhaustive. The intent is to give guidance on the most = commonly used elements, stuff we already know is being considered. Besides = achieving some level of interop, this can help educate readers on what are = the things one typically watch out for- and could lead to better decisions = even for other attributes they choose to add outside of the scope of this p= rofile.=C2=A0
=C2=A0
For cases where the policy can change over time including th= e lifetime of the access_token then I prefer the User Managed Access (UMA) = approach as it inherently allows for dynamic policy change
I think simplicity is key here. Having the info available allows developer= s to be confident they can enforce their requirements transparently, using = off the shelf software components.=C2=A0=C2=A0

On Thu, Apr 4, 2019 at = 7:14 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Comments inline...
On 4/3/19 3:= 38 PM, Vittorio Bertocci wrote:
=20
Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south.
I'm fine with re-using claims... we just need to make sure if we reuse a claim it keeps the same semantic.
However I think it's important that the information on say= , whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API).=C2=A0
Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers.=C2=A0 =C2=A0
In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened=C2=A0is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access).
As an aside, I worry about trying to put all information needed to make a dynamic policy decision into an access token. For cases where the policy can change over time including the lifetime of the access_token then I prefer the User Managed Access (UMA) approach as it inherently allows for dynamic policy change.

I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW. But I am completely open to change it of course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
+1 to David's question here. I'd like = to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com> wrote:
Do we know if there is a justifying use case for auth_time, acr, and amr to be available in OAuth JWT access tokens? These are meant to be messages about the client, either directly (in the case of client credentials) or about its delegated authorization of the user.

Embedding attributes about the user (such as group membership and roles) can be used for the resource to make finer-grained decisions than scopes, but normally I would expect say acr limitations enforced by a resource to instead be controlled by the AS requiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such as OIDC can=E2=80=99t provide these values, just= that they might better be defined by those extensions.

-DW

On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

Thanks for writing this up. One comment on auth_time...

   auth_time  OPT=
IONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.
Dur= ing a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated.

If we need a timestamp for when the "session" started, then there could= be a session_start_time claim.

Thanks,
George
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0ht= tps://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.<= /div>
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory= , in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!= ).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2= 019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in th= e draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0=
V.

_________=
______________________________________
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@iet= f.org
https://www.ietf.org/mailman/listinfo/oau= th

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.or= g
https://www.ietf.org/mailman/listinfo/oauth=

--00000000000044b40e0585b7df02-- From nobody Thu Apr 4 10:49:40 2019 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 2C5B4120118 for ; Thu, 4 Apr 2019 10:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 EYX7wofpu5b7 for ; Thu, 4 Apr 2019 10:49:36 -0700 (PDT) Received: from mail-it1-x12a.google.com (mail-it1-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 AAF101200C5 for ; Thu, 4 Apr 2019 10:49:36 -0700 (PDT) Received: by mail-it1-x12a.google.com with SMTP id y10so5141424itc.1 for ; Thu, 04 Apr 2019 10:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LlaU2izB3fmySAfp1mAqoc98/lvkUFb+13deQMdBJQ0=; b=irsKsMtp/dR3ZJI1IwrX2H/ZV+L+WSY+eop3JxZOYG8fH3kqfnRywQotIjw69s/Ln1 5ba0laIaIT3x7ftqsrklHdmaqXsfFjT7jwx11jmLoxk+BeDtpKAM3/SaKMx4dtoIlMZ1 G+/mOyZs0lfSzRWqLsoqkAU0gbrJ6GJuJVznQ= 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=LlaU2izB3fmySAfp1mAqoc98/lvkUFb+13deQMdBJQ0=; b=NzIDXdcGNtpmRnBCiFjRiLYL+y3ROluEffZbrAlFyhfolpBElKE6UkYYito+8uOvua nVhvyoy443i181t3wqo1kgaSZmsZ+ol7UFWEDdQFPZB0hGOQ5MwPWd6SO+579A0mzR86 jEHft+nUI6X8oLlcYiNzF0X/JWfm0OZ3zj4sskWfmFOsu9x6lc0BlJOZ+wN05HbqcU8c G9ihOiP83IvIeVzkxwP8vKpPNT93sf2Hg3FTkOULSJdgazngG8zPEBuGfEgRgUBlKL74 ejU0QIzzzX1KCuiGEvxFgilGLpVGv/mXc9YF6gjK5bdvLaLZbyOIBevPblsO3XYby5XK JeZw== X-Gm-Message-State: APjAAAWUOToCDVRoP5Vkdkv5i/NUznC4ACRAchmb+8m26wvk1i1jpwM5 myQ3rUxIev13v0FGcYhqbyj7ymKNHzxahQWiS2MUuW21q7YlutQqxyN/MokqwbwQFju4lI5sQGC nWJqWr0ZQa85pBw== X-Google-Smtp-Source: APXvYqzs9U4Dkdb7Y/Q3nQXuwbnEZMkkhE+tUWjw/PwJs6+HL49bgXqCnkW55Wm1IIP+sd/Q0yotFZ5cKuZwNxTNub4= X-Received: by 2002:a24:108b:: with SMTP id 133mr5333987ity.15.1554400175846; Thu, 04 Apr 2019 10:49:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 4 Apr 2019 11:49:09 -0600 Message-ID: To: Hannes Tschofenig Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005214f60585b7fedb" Archived-At: Subject: Re: [OAUTH-WG] Early IANA registration for Token Exchange Draft 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, 04 Apr 2019 17:49:39 -0000 --0000000000005214f60585b7fedb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The request originated from Ben Kaduk's Discuss ballot on the draft and suggestion that the URI values be registered. Some of the relevant messages in the thread: https://mailarchive.ietf.org/arch/msg/oauth/QiA5PDBsKlApNZIRy3QOttd-JDM https://mailarchive.ietf.org/arch/msg/oauth/E2eOLE576c_Zw6MK0ysouEbmrrw https://mailarchive.ietf.org/arch/msg/oauth/GKh_vAtvD3bAcuBJ7OXxquVcrmM https://mailarchive.ietf.org/arch/msg/oauth/f4tBwgOO2NlhOJobUKNdw2wCPAU On Mon, Apr 1, 2019 at 5:33 AM Hannes Tschofenig wrote: > Hi all > > > > The authors of the token exchange draft asked IANA for an early > registration of URIs and parameters, token types, claims, etc. > > > > IANA asked me for review and I unfortunately do not know (or remember) wh= y > this early registration is needed. > > > > Any reason to do this early registration? > > > > Ciao > > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. 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._ --0000000000005214f60585b7fedb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Apr 1, 201= 9 at 5:33 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all

=C2=A0

The authors of the token exchan= ge draft asked IANA for an early registration of URIs and parameters, token= types, claims, etc.

=C2=A0

IANA asked me for review and I = unfortunately do not know (or remember) why this early registration is need= ed.

=C2=A0

Any reason to do this early reg= istration?

=C2=A0

Ciao

Hannes

=C2=A0

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.
_______________________________________________
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. --0000000000005214f60585b7fedb-- From nobody Thu Apr 4 10:51:37 2019 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 B3551120495 for ; Thu, 4 Apr 2019 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 McQetjWtIVuD for ; Thu, 4 Apr 2019 10:51:28 -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 ECF3512011D for ; Thu, 4 Apr 2019 10:51:27 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id v71so2406298lfa.11 for ; Thu, 04 Apr 2019 10:51:27 -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=2U5WpQC7zF5fjkYxSrx+hfszVGM8Q7syFqMSSPZxySs=; b=r7PGAXIsPQ5kwg8p5/su59WN7o+d7De5M9C4LIF2HxgCUTS4YIXD9Cw80Yz79cHLZ3 xATurRamU7z750BEVteLKuxdqo4JgXOZ0uyfnjEsMxunDIZ9qumPNHnfWSufAwRPZ3qo Vbgr2YkTer6AT8ojkrMTL+exHGuag9QlwAicjZkJXY4rFkjAEW4JH+orSgL7Y7j4/pp6 NB3+1p87/cKAl2lWc7l2YhZIQK8ZWugQ9rX1Mq7PEcKGH4tQdlr4FxZuWqPh9PkPdYcE CeHGibLIm3hYyE8mhUlEh+Fg1Cjqda/KlBlOdPnXZRxXy9YmZVMJbVlm4bBzGmOI2npA /v/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=2U5WpQC7zF5fjkYxSrx+hfszVGM8Q7syFqMSSPZxySs=; b=j7jQmrHxt1tao2tNh1+/qy68tr4RbEVUPltGR+B0F2IO1NKJhb0ScGCWRzRf9M2Ibg uUUuA/LdNAe5ON07MpXpidE8835A2lAzcz0zrd2x3t47DUfU7oBMX8PgEZh1pQ6RY2yc 1Rid1l0HXSmD5kZ0Q4UdFs4i+J5pYLFTW9zrnceTnyGGMBiab/BC5bXk97oPbMpMCsVf QUYh32Q2vGfz76Hh3DmUrKjkl9CITd4KYc13PyYi7N8vLTSaHouZKLsZ24B3fzHcm48A JS2eZNcE3Pgs5dgsxQHa0d2sVqWdAYGBo74OiEcQS21v4vVS68fbdCQ6lLVF5r/e9srw OAOQ== X-Gm-Message-State: APjAAAWgyOf/VA4jpMdXSVWwxQPXk3loM2EuLdXsvB3RH2+SOFR/PrbY 4Ewn0nhwHgIbSDgLyHlFA7x74941iqXdgdxyVvY+rg== X-Google-Smtp-Source: APXvYqyPiT+gOvFc/uKuSVM9s9jSJANxHYUauScZbx3KiBXUgIb2twriJVdStkUGKj1+icjir69yzVkFKNbTBw2Usbc= X-Received: by 2002:a19:40c8:: with SMTP id n191mr4026164lfa.22.1554400285815; Thu, 04 Apr 2019 10:51:25 -0700 (PDT) MIME-Version: 1.0 References: <2a523e40-470b-4727-4e38-7a60552a285a@aol.com> In-Reply-To: From: Vittorio Bertocci Date: Thu, 4 Apr 2019 10:51:14 -0700 Message-ID: To: "Schanzenbach, Martin" Cc: Brian Campbell , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000e00f240585b8041c" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 17:51:35 -0000 --000000000000e00f240585b8041c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Martin. Inline I kind of agree that you might want to have this information in the token, > if possible. You can save a lot of round trips over time (at the expense = of > revocation). Yep, this entire profile idea emerged as acknowledgement that a large number of services and products choose to use format driven validation. But then, we should simply take that (rfc7662) as a boilerplate for the > JWT, not OIDC. > An introspection response also contains scopes, username and optional > additional claims (e.g. OIDC / authN specific claims) > Ultimately all I care about is that we give guidance to developers on on how to transport in JWT encoded ATs the info their API need. In the initial formulation I referred to OIDC because in my experience most of the existing software being used to consume JWT ATs is largely "jury-rigged" middleware either meant to be used for id_tokens or reusing infrastructure meant for OIDC (discovery, etc). As long as the expressive power is the same, I am happy to switch all the references from OIDC to rfc7662. Developers won't care either ways as long as they can get the job done. > I think an access token JWT should not convey more / other information > than a token introspection endpoint. Could you expand on this? Could you make a concrete example of a claim you can get through OIDC that you would not want included in an AT, and why? I am especially interested in this from the PoV of the 1st party API scenario I described earlier: if an AT is all you are getting , it seems you should be able to get any info you could have gotten otherwise. On Thu, Apr 4, 2019 at 10:40 AM Schanzenbach, Martin < martin.schanzenbach@aisec.fraunhofer.de> wrote: > Hi Vittorio, > > > On 4. Apr 2019, at 19:19, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > > But before I get in the details, let me make an uber-point.. > > I am acutely aware of the potential for confusion and abuse in the > context of OAuth and sign in, the article you pointed to quotes my own > articles on the matter extensively. But there are concrete aspects that > need to be considered about what developers are trying to achieve in > practice. > > OAuth2 is the de facto mechanism to secure API calls nowadays. That > includes scenarios not directly addressed by the spec, such as first part= y > APIs. People do that for 1st party APIs as well because they can leverage= a > well supported mechanism for driving authentication experiences and > outsource authentication to products and services. > > Forgetting for a second about the fact that 3rd party APIs can use > identity and authentication levels info as well, let me focus for a secon= d > on 1st party APIs. From the functionality perspective, delivering an app = as > a web site or as a native client+API combination doesn't change the > business requirements and the information a backend needs to do its job. > > Given that we tell people NOT to use ID tokens for calling APIs: if a > developer chooses to deliver their app as a native client+API instead of = a > web site, the only artifact they have available is the access token. So > either we embed the info in the access token, and we do what we can to > prevent abuse and the most likely pitfalls/privacy challenges/etc in the > guidance, or we find a way for 1st party APIs to consume ID tokens (which > is problematic- I discussed this with John and Nat at OSW and the place w= e > got stuck on was that we can; safely use sender constrain in that scenari= o). > > And to pre-empt comments on userinfo, that's asking for a lot of extra > moving parts- the only outcome will be that people will keep embedding th= e > info they need in the AT, but will do so in non-interoperable way, and > without the guidance and warnings that would at least contain some of the > damage. > > Userinfo is OIDC. Do you mean rfc7662? > So you say that the use of a token introspection endpoint like rfc7662 is > not always viable, right? > I kind of agree that you might want to have this information in the token= , > if possible. You can save a lot of round trips over time (at the expense = of > revocation). > But then, we should simply take that (rfc7662) as a boilerplate for the > JWT, not OIDC. > An introspection response also contains scopes, username and optional > additional claims (e.g. OIDC / authN specific claims). > I think an access token JWT should not convey more / other information > than a token introspection endpoint. > > BR > > > > > That said, inline. > > > > My concern isn't with reusing the names/types of the claims per se. Bu= t > more generally that codifying the use of certain authentication-centric > claims in the context of an access token furthers the potential confusion > around authentication vs. authorization that has been a nagging problem f= or > OAuth (i.e. the https://oauth.net/articles/authentication/ article). > > see preamble. > > > > I understand what you are saying but but personally do not find it > sufficiently compelling. But that's just my opinion and not a hill I wan= t > to die on (at the present time anyway).. > > Noted :) does the fact that in some scenarios the AT might be the *only= * > artifact a backend will receive change the stance? > > > > By the time it came up again near the end of the last unconference > session, I wasn't wanting to prolong things because I was kinda worn out > for the day and wanting to get to Frankfurt that evening before sunset > ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ). > > Sorry for having tired you out :) at the time I echoed back what was > suggested (to reflect the original values in the session) precisely to ma= ke > sure everyone had a chance to push back, and I got lots of nods (includin= g > from John who was in the first row). I misinterpreted your silence as > assent, given that during that session you did chime in on other matters.= . > but I was expecting the discussion to keep going on the ML anyway, so it'= s > all according to plan :) > > > > FWIW, to me, George's suggestion "assume[ing] that the auth_time value > should be updated to the latest time at which the user authenticated" > though some unspecified and in many cases non-existent link between the A= T > and a current user session at the AS is an example of how > authentication-centric claims in an access token can be confusing. > > I agree it can be confusing, but to me that makes the need to provide > guidance on it more compelling, not less. There are important scenarios > where access decisions are made on the basis of that information, and > implementations WILL find a way to get the info they are interested into. > To me that's all the more reasons to provide guidance on how to do so bei= ng > aware of pitfalls and with whatever protections we can put in place, as > opposed to leave developers to their own device. > > > > On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > A few remarks/responses inline below this time... > > > > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > Thanks guys for the comment, sorry for the delay in addressing them. > > I am not married to the claim types used in here, so if you think that > reusing the ones in the id_token can cause confusion we should expand on > the specific ways in which you think might go south. > > > > My concern isn't with reusing the names/types of the claims per se. Bu= t > more generally that codifying the use of certain authentication-centric > claims in the context of an access token furthers the potential confusion > around authentication vs. authorization that has been a nagging problem f= or > OAuth (i.e. the https://oauth.net/articles/authentication/ article). > > > > > > However I think it's important that the information on say, whether the > current token was obtained using MFA or a specific authentication factor = is > something that API developers can legitimately latch to when doing > authorization decisions. From the perspective of a developer modeling a > solution, whether functionality is delivered as a route in a postback bas= ed > web app (hence receiving an id_token or derived) or as an API consumed by= a > native app, the business requirement gating access to that functionality > doesn't change. If the admin managing that resource establishes that acce= ss > should be performed only via MFA, the developer should be equipped to > enforce that regardless of the stack used to expose functionality (web ap= p, > API). > > Although it is true that triggering the desired behavior might be > achieved by the resource setting and contract with the AS, along the line= s > of what David said, it's actually not uncommon for those policies to be > assigned on the resource AFTER the current session was established and/or > the corresponding AT was obtained and cached. Furthermore, the requiremen= t > might be more granular than an AS policy can tolerate (an API might > requires MFA only for certain routes, hence hard to express in a static > policy) and triggered in form of challenges. So the situation in which yo= u > have an AT with the right issuer, audience, etc but was obtained with a > policy now obsolete/unacceptable to the RP is strong. Requesting to suppo= rt > revocation just for this seems overkill, especially given that the scenar= io > in which the same logical app is exposed as both web app and native > client+API, the code consuming those claims is already in place. It just > makes intuitive sense for developers. > > In summary, one can take steps to push as much of the MFA requirements > to the AS settings for a particular request, but ultimately the desire of > the API developer to enforce that it actually happened is a requirement I > encountered often in practice. Anything providing extra context to refine > decisions about it (like auth_time, which might inform decisions about > whether to accept an MFA check occurred N minutes ago or refuse access). > > > > I understand what you are saying but but personally do not find it > sufficiently compelling. But that's just my opinion and not a hill I wan= t > to die on (at the present time anyway).. > > > > > > > > I thought that reusing the existing names for the same concepts just > made sense (dev existing skills, existing codebases, etc etc) and > especially in the case in which the values are exactly the same, and the > idea seemed to receive good support during OSW. > > > > Our recollection of OSW differs somewhat. As I recall there was support > for pointing to identity claims from OIDC for additional end-user info. B= ut > there was some grumbling (from John and myself at least) at first mention > of acr/amr and auth_time. By the time it came up again near the end of th= e > last unconference session, I wasn't wanting to prolong things because I w= as > kinda worn out for the day and wanting to get to Frankfurt that evening > before sunset ('cause I like to do stuff like this: > https://flic.kr/p/2fiAaPe :) ). > > > > > > But I am completely open to change it of course, especially for cases > like the one identified by George. > > > > FWIW, to me, George's suggestion "assume[ing] that the auth_time value > should be updated to the latest time at which the user authenticated" > though some unspecified and in many cases non-existent link between the A= T > and a current user session at the AS is an example of how > authentication-centric claims in an access token can be confusing. > > > > > > > > WDYT? > > > > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > +1 to David's question here. I'd like to see justifying use cases > (beyond just the fact that some people are already doing it) for auth_tim= e, > acr, and amr to be available in OAuth JWT access tokens.. Those claims ar= e > defined for, and in the context of, an ID Token and I fear that codifying > their use in an access token will lead to misuse and/or confusion. > > > > On Mon, Apr 1, 2019 at 1:03 PM David Waite > wrote: > > Do we know if there is a justifying use case for auth_time, acr, and am= r > to be available in OAuth JWT access tokens? These are meant to be message= s > about the client, either directly (in the case of client credentials) or > about its delegated authorization of the user. > > > > Embedding attributes about the user (such as group membership and roles= ) > can be used for the resource to make finer-grained decisions than scopes, > but normally I would expect say acr limitations enforced by a resource to > instead be controlled by the AS requiring a higher quality authentication > to release certain scopes. > > > > Thats of course not to say extensions to OAuth such as OIDC can=E2=80= =99t > provide these values, just that they might better be defined by those > extensions. > > > > -DW > > > >> On Apr 1, 2019, at 9:12 AM, George Fletcher 40aol.com@dmarc.ietf.org> wrote: > >> > >> Thanks for writing this up. One comment on auth_time... > >> > >> auth_time OPTIONAL - as defined in section 2 of [OpenID.Core > >> ]. > >> Important: as this claim represents the time at which the end us= er > >> authenticated, its value will remain the same for all the JWT > >> access tokens issued within that session. For example: all the > >> JWT access tokens obtained with a given refresh token will all > >> have the same value of auth_time, corresponding to the instant i= n > >> which the user first authenticated to obtain the refresh token. > >> > >> > >> During a current session a user can be challenged for additional > credentials or required to re-authenticate due to a number of different > reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this conte= xt, > I'd assume that the auth_time value should be updated to the latest time = at > which the user authenticated. > >> > >> If we need a timestamp for when the "session" started, then there coul= d > be a session_start_time claim. > >> > >> Thanks, > >> George > >> > >> On 3/24/19 7:29 PM, Vittorio Bertocci wrote: > >>> Dear all, > >>> I just submitted a draft describing a JWT profile for OAuth 2.0 acces= s > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presentin= g > remotely). I look forward for your comments! > >>> > >>> Here's just a bit of backstory, in case you are interested in how thi= s > doc came to be. The trajectory it followed is somewhat unusual. > >>> =E2=80=A2 Despite OAuth2 not requiring any specific format for AT= s, > through the years I have come across multiple proprietary solution using > JWT for their access token. The intent and scenarios addressed by those > solutions are mostly the same across vendors, but the syntax and > interpretations in the implementations are different enough to prevent > developers from reusing code and skills when moving from product to produ= ct. > >>> =E2=80=A2 I asked several individuals from key products and servi= ces to > share with me concrete examples of their JWT access tokens (THANK YOU > Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel > Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and > explanations!). > >>> I studied and compared all those instances, identifying commonalities > and differences. > >>> =E2=80=A2 I put together a presentation summarizing my findings a= nd > suggesting a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw= t_profile_for_ats.pptx > ) - got early feedback from Filip Skokan on it. Thx Filip! > >>> =E2=80=A2 The presentation was followed up by 1.5 hours of unconf= erence > discussion, which was incredibly valuable to get tight-loop feedback and > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and > contributed generously to the discussion. Thank you!!! > >>> Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note and > I'll make things right at the next update. > >>> =E2=80=A2 On my flight back I did my best to incorporate all the = ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > >>> I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > >>> V. > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > 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 fi= le > attachments from your computer. Thank > you._______________________________________________ > > 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 fi= le > attachments from your computer. Thank you. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > Martin Schanzenbach > Fraunhofer AISEC > Department Service & Application Security > Parkring 4, 85748 Garching near Munich (Germany) > Tel: +49 89 3229986-193 > martin.schanzenbach@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 > > --000000000000e00f240585b8041c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Martin. Inline

I kind of agree that you might want to have thi= s information in the token, if possible. You can save a lot of round trips = over time (at the expense of revocation).
Yep, this entire= profile idea emerged as acknowledgement that a large number of services an= d products choose to use format driven validation.

=C2=A0But then, we should sim= ply take that (rfc7662) as a boilerplate for the JWT, not OIDC.
An intro= spection response also contains scopes, username and optional additional cl= aims (e.g. OIDC / authN specific claims)
Ultimately al= l I care about is that we give guidance to developers on on how to transpor= t in JWT encoded ATs the info their API need. In the initial formulation I = referred to OIDC because in my experience most of the existing software bei= ng used to consume JWT ATs is largely "jury-rigged" middleware ei= ther meant to be used for id_tokens or reusing infrastructure meant for OID= C (discovery, etc).
As long as the expressive power is the same, = I am happy to switch all the references from OIDC to rfc7662. Developers wo= n't care either ways as long as they can get the job done.
= =C2=A0 =C2=A0
I thin= k an access token JWT should not convey more / other information than a tok= en introspection endpoint.
Could you expand on this? Could= you make a concrete example of a claim you can get through OIDC that you w= ould not want included in an AT, and why? I am especially interested in thi= s from the PoV of the 1st party API scenario I described earlier: if an AT = is all you are getting , it seems you should be able to get any info you co= uld have gotten otherwise.

On Thu, Apr 4, 2019 at 10:40 AM Schanzenbac= h, Martin <ma= rtin.schanzenbach@aisec.fraunhofer.de> wrote:
Hi Vittorio,

> On 4. Apr 2019, at 19:19, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf= .org> wrote:
>
> But before I get in the details, let me make an uber-point..
> I am acutely aware of the potential for confusion and abuse in the con= text of OAuth and sign in, the article you pointed to quotes my own article= s on the matter extensively. But there are concrete aspects that need to be= considered about what developers are trying to achieve in practice.
> OAuth2 is the de facto mechanism to secure API calls nowadays. That in= cludes scenarios not directly addressed by the spec, such as first party AP= Is. People do that for 1st party APIs as well because they can leverage a w= ell supported mechanism for driving authentication experiences and outsourc= e authentication to products and services.
> Forgetting for a second about the fact that 3rd party APIs can use ide= ntity and authentication levels info as well, let me focus for a second on = 1st party APIs. From the functionality perspective, delivering an app as a = web site or as a native client+API combination doesn't change the busin= ess requirements and the information a backend needs to do its job.
> Given that we tell people NOT to use ID tokens for calling APIs: if a = developer chooses to deliver their app as a native client+API instead of a = web site, the only artifact they have available is the access token. So eit= her we embed the info in the access token, and we do what we can to prevent= abuse and the most likely pitfalls/privacy challenges/etc in the guidance,= or we find a way for 1st party APIs to consume ID tokens (which is problem= atic- I discussed this with John and Nat at OSW and the place we got stuck = on was that we can; safely use sender constrain in that scenario).
> And to pre-empt comments on userinfo, that's asking for a lot of e= xtra moving parts- the only outcome will be that people will keep embedding= the info they need in the AT, but will do so in non-interoperable way, and= without the guidance and warnings that would at least contain some of the = damage.

Userinfo is OIDC. Do you mean rfc7662?
So you say that the use of a token introspection endpoint like rfc7662 is n= ot always viable, right?
I kind of agree that you might want to have this information in the token, = if possible. You can save a lot of round trips over time (at the expense of= revocation).
But then, we should simply take that (rfc7662) as a boilerplate for the JWT= , not OIDC.
An introspection response also contains scopes, username and optional addit= ional claims (e.g. OIDC / authN specific claims).
I think an access token JWT should not convey more / other information than= a token introspection endpoint.

BR

>
> That said, inline.
>
> My concern isn't with reusing the names/types of the claims per se= .=C2=A0 But more generally that codifying the use of certain authentication= -centric claims in the context of an access token furthers the potential co= nfusion around authentication vs. authorization that has been a nagging pro= blem for OAuth (i.e. the https://oauth.net/articles/authen= tication/ article).
> see preamble.
>
> I=C2=A0 understand what you are saying but but personally do not find = it sufficiently compelling.=C2=A0 But that's just my opinion and not a = hill I want to die on (at the present time anyway)..
> Noted :) does the fact that in some scenarios the AT might be the *onl= y* artifact a backend will receive change the stance?
>
>=C2=A0 By the time it came up again near the end of the last unconferen= ce session, I wasn't wanting to prolong things because I was kinda worn= out for the day and wanting to get to Frankfurt that evening before sunset= ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :)= ).
> Sorry for having tired you out :) at the time I echoed back what was s= uggested (to reflect the original values in the session) precisely to make = sure everyone had a chance to push back, and I got lots of nods (including = from John who was in the first row). I misinterpreted your silence as assen= t, given that during that session you did chime in on other matters.. but I= was expecting the discussion to keep going on the ML anyway, so it's a= ll according to plan :)
>
>=C2=A0 FWIW, to me, George's suggestion "assume[ing] that the = auth_time value should be updated to the latest time at which the user auth= enticated" though some unspecified and in many cases non-existent link= between the AT and a current user session at the AS is an example of how a= uthentication-centric claims in an access token can be confusing.
>=C2=A0 I agree it can be confusing, but to me that makes the need to pr= ovide guidance on it more compelling, not less. There are important scenari= os where access decisions are made on the basis of that information, and im= plementations WILL find a way to get the info they are interested into. To = me that's all the more reasons to provide guidance on how to do so bein= g aware of pitfalls and with whatever protections we can put in place, as o= pposed to leave developers to their own device.
>
> On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
> A few remarks/responses inline below this time...
>
> On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc= .ietf.org> wrote:
> Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim types used in here, so if you think that= reusing the ones in the id_token can cause confusion we should expand on t= he specific ways in which you think might go south.
>
> My concern isn't with reusing the names/types of the claims per se= .=C2=A0 But more generally that codifying the use of certain authentication= -centric claims in the context of an access token furthers the potential co= nfusion around authentication vs. authorization that has been a nagging pro= blem for OAuth (i.e. the https://oauth.net/articles/authen= tication/ article).
>
>
> However I think it's important that the information on say, whethe= r the current token was obtained using MFA or a specific authentication fac= tor is something that API developers can legitimately latch to when doing a= uthorization decisions. From the perspective of a developer modeling a solu= tion, whether functionality is delivered as a route in a postback based web= app (hence receiving an id_token or derived) or as an API consumed by a na= tive app, the business requirement gating access to that functionality does= n't change. If the admin managing that resource establishes that access= should be performed only via MFA, the developer should be equipped to enfo= rce that regardless of the stack used to expose functionality (web app, API= ).
> Although it is true that triggering the desired behavior might be achi= eved by the resource setting and contract with the AS, along the lines of w= hat David said, it's actually not uncommon for those policies to be ass= igned on the resource AFTER the current session was established and/or the = corresponding AT was obtained and cached. Furthermore, the requirement migh= t be more granular than an AS policy can tolerate (an API might requires MF= A only for certain routes, hence hard to express in a static policy) and tr= iggered in form of challenges. So the situation in which you have an AT wit= h the right issuer, audience, etc but was obtained with a policy now obsole= te/unacceptable to the RP is strong. Requesting to support revocation just = for this seems overkill, especially given that the scenario in which the sa= me logical app is exposed as both web app and native client+API, the code c= onsuming those claims is already in place. It just makes intuitive sense fo= r developers.
> In summary, one can take steps to push as much of the MFA requirements= to the AS settings for a particular request, but ultimately the desire of = the API developer to enforce that it actually happened is a requirement I e= ncountered often in practice. Anything providing extra context to refine de= cisions about it (like auth_time, which might inform decisions about whethe= r to accept an MFA check occurred N minutes ago or refuse access).
>
> I understand what you are saying but but personally do not find it suf= ficiently compelling.=C2=A0 But that's just my opinion and not a hill I= want to die on (at the present time anyway)..
>
>
>
> I thought that reusing the existing names for the same concepts just m= ade sense (dev existing skills, existing codebases, etc etc) and especially= in the case in which the values are exactly the same, and the idea seemed = to receive good support during OSW.
>
> Our recollection of OSW differs somewhat. As I recall there was suppor= t for pointing to identity claims from OIDC for additional end-user info. B= ut there was some grumbling (from John and myself at least) at first mentio= n of acr/amr and auth_time. By the time it came up again near the end of th= e last unconference session, I wasn't wanting to prolong things because= I was kinda worn out for the day and wanting to get to Frankfurt that even= ing before sunset ('cause I like to do stuff like this: https://flic.kr= /p/2fiAaPe :) ).
>
>
> But I am completely open to change it of course, especially for cases = like the one identified by George.
>
> FWIW, to me, George's suggestion "assume[ing] that the auth_t= ime value should be updated to the latest time at which the user authentica= ted" though some unspecified and in many cases non-existent link betwe= en the AT and a current user session at the AS is an example of how authent= ication-centric claims in an access token can be confusing.
>
>
>
> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
> +1 to David's question here. I'd like to see justifying use ca= ses (beyond just the fact that some people are already doing it) for auth_t= ime, acr, and amr to be available in OAuth JWT access tokens.. Those claims= are defined for, and in the context of, an ID Token and I fear that codify= ing their use in an access token will lead to misuse and/or confusion.
>
> On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com= > wrote:
> Do we know if there is a justifying use case for auth_time, acr, and a= mr to be available in OAuth JWT access tokens? These are meant to be messag= es about the client, either directly (in the case of client credentials) or= about its delegated authorization of the user.
>
> Embedding attributes about the user (such as group membership and role= s) can be used for the resource to make finer-grained decisions than scopes= , but normally I would expect say acr limitations enforced by a resource to= instead be controlled by the AS requiring a higher quality authentication = to release certain scopes.
>
> Thats of course not to say extensions to OAuth such as OIDC can=E2=80= =99t provide these values, just that they might better be defined by those = extensions.
>
> -DW
>
>> On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf= .org> wrote:
>>
>> Thanks for writing this up. One comment on auth_time...
>>
>>=C2=A0 =C2=A0 auth_time=C2=A0 OPTIONAL - as defined in section 2 of= [OpenID.Core
>> ].
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Important: as this claim represents the = time at which the end user
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0authenticated, its value will remain the= same for all the JWT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0access tokens issued within that session= .=C2=A0 For example: all the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0JWT access tokens obtained with a given = refresh token will all
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0have the same value of auth_time, corres= ponding to the instant in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0which the user first authenticated to ob= tain the refresh token.
>>
>>
>> During a current session a user can be challenged for additional c= redentials or required to re-authenticate due to a number of different reas= ons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I&= #39;d assume that the auth_time value should be updated to the latest time = at which the user authenticated.
>>
>> If we need a timestamp for when the "session" started, t= hen there could be a session_start_time claim.
>>
>> Thanks,
>> George
>>
>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>> Dear all,
>>> I just submitted a draft describing a JWT profile for OAuth 2.= 0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-j= wt/.
>>> I have a slot to discuss this tomorrow at IETF 104 (I'll b= e presenting remotely). I look forward for your comments!
>>>
>>> Here's just a bit of backstory, in case you are interested= in how this doc came to be. The trajectory it followed is somewhat unusual= .
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 Despite OAuth2 not requiring any = specific format for ATs, through the years I have come across multiple prop= rietary solution using JWT for their access token. The intent and scenarios= addressed by those solutions are mostly the same across vendors, but the s= yntax and interpretations in the implementations are different enough to pr= event developers from reusing code and skills when moving from product to p= roduct.
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 I asked several individuals from = key products and services to share with me concrete examples of their JWT a= ccess tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (Pi= ngIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the toke= ns and explanations!).
>>> I studied and compared all those instances, identifying common= alities and differences.
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 I put together a presentation sum= marizing my findings and suggesting a rough interoperable profile (slides: = https= ://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profi= le_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Fil= ip!
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 The presentation was followed up = by 1.5 hours of unconference discussion, which was incredibly valuable to g= et tight-loop feedback and incorporate new ideas. John Bradley, Brian Campb= ell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofeni= g were all there and contributed generously to the discussion. Thank you!!!=
>>> Note: if you were at OSW2019, participated in the discussion a= nd didn't get credited in the draft, my apologies: please send me a not= e and I'll make things right at the next update.
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 On my flight back I did my best t= o incorporate all the ideas and feedback in a draft, which will be discusse= d at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super he= lpful in negotiating the mysterious syntax of the RFC format and submission= process.
>>> I was blown away by the availability, involvement and willingn= ess to invest time to get things right that everyone demonstrated in the pr= ocess. This is an amazing community.
>>> V.
>>>
>>>
>>> _______________________________________________
>>> 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<= br> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited...=C2=A0 If = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited...=C2=A0 If = you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from you= r computer. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


Martin Schanzenbach
Fraunhofer AISEC
Department Service & Application Security
Parkring 4, 85748 Garching near Munich (Germany)
Tel: +49 89 3229986-193
martin.schanzenbach@aisec.fraunhofer.de
GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0

--000000000000e00f240585b8041c-- From nobody Thu Apr 4 12:17:36 2019 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 61E6A120151 for ; Thu, 4 Apr 2019 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 CEoYgaFvYojC for ; Thu, 4 Apr 2019 12:17:31 -0700 (PDT) Received: from sonic315-14.consmr.mail.bf2.yahoo.com (sonic315-14.consmr.mail.bf2.yahoo.com [74.6.134.124]) (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 27DA3120126 for ; Thu, 4 Apr 2019 12:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554405449; bh=6MtPVj8LLfX3ghkMUMUhfftrBA8EjyMKrib7C7UXAFg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=IiATmqwXN/EHfp/nc7qPqt8KixE/mBBhqZmHtSgdqLXKiwtn16gcRxpPMFtCR3h/KPS83LjLEshl1q3xA04rhocFR5SbakHPCJuUlyMbQSR4l5XveWAQ5ipn5eoBgCrn8Zt4+fD7K0OsjCIVSm9Cwxm5QwoZpqgCQO6CTChS+d+WLH2I+kXP+FDKFvi9zk+LP35csdNUeID+n4Yi+LM8uOvQPbbyTY60R5jf65d0KMcMMb/5Ky1J3mcvZBC+yYOlcAjSC6BTDVAhiI8ojyLskhDk4UUKq1TROwbvnc6PEx01PjmbyoVbOrnZWrSXvRvzfa+DhDNh2DBi1DrdZ+X8qQ== X-YMail-OSG: 0n9hQn0VM1lMrZflrBrzw7UNEzJe.5mdAUO627jxZ645dMi_U4Bx7TtMI5Mv5DN 5S6iTqIo6ZL5_Tq6yCFH.ZVzjKBq4SWe0t.6BoRfxo.E9DnCMdsX1XWcPH1.MylqlfFdun5kzINa HSMjdeeh_d2aZDxjK3_2Ra.hiGSchrPi3wlnqN1NCrhoLKPyLJB69DOjAl3cXmDgnPSivzsO1SaK 6DLIX40tO8sX9fCgEmijTPjCuYrmiYEj3kh2jkj.TRUTxB..lqKvYHBCcANA8mhfQ5WSWLDCwwNI PBg7SAXfVyHLXDCwcfL8.PUQWuX4eFgwcHkJJ26i2_4g68ZwhkEcV7Bd5ma0yVYLYhHTptJRXmcn Fbt6uMfwYckkgKwfwHmUiq_JnC5D_kBcxlpzr7ujm_868uySdYdQwer1GUHY1navPozNnWvv6aqE J8zgSIbo.bCxEYSkTS5pj4O9n3wblToAa11247MUBFYXzKufjDRUrp6j52Mpr8m3K3DAcQlC_YZC GbHwaMi20ecY_j4OTkBeZ8nBL31PksrF2oemxPLR.kN4RMc1y0gRdf6I6C3QDOC6M4tc1vA7QjfH rKlEda8pbAz14b84QSv6sT_NuZOBQ.fo0jXbL2od7NCTKVJAiLkc5dhrEmjXN97wVuB4VkTiZlJ_ TT01He8XRLDwonfUR57PpocmAdpbaMqJYhWIcGqZO5arUAZxDKlFLuGVV8EFPycd4L558hubjtzh LAf42c4OJD1OST42ApdIZLUMpiylXg7gZ8v5pye6_IhkjQaFwPiHLeuHfLJmSZyZ.aRVKSYllfVo vpGRPiG.pfFKetG.q1O6iRVO.OSNgERyTyQ77D3HcrgGpIs5wZXywe6SbFr.2t3YKNconyENYdk2 vu6nuL2a3x6DPf.uVQWoqswST2lT_gEK73fw6DXjp70kETmW4yi2u9ex6HSsXK3ZVxWEPdfO1ja2 sziPWWIpKY9iAinl8FrmbjrTFiIsV1Q1lWv5Ha9QNuFP_fn6y5x9cw1Owej9I52prBJ9lXnaLhqj GQLOxn.klWWrtbroJVebeZFyZ2qrbtmkft2tOucrjot.c0N.Ci.awcAhKnTBmcF9OGfuqdAw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 19:17:29 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ddf554ab16ab89152fe76dc55583239f; Thu, 04 Apr 2019 19:17:27 +0000 (UTC) To: Vittorio Bertocci Cc: IETF oauth WG References: <62e62afb-891d-f7d8-8b39-793254dadf7b@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 4 Apr 2019 15:17:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7E1BA5F47718B01A0AA3000D" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 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, 04 Apr 2019 19:17:34 -0000 This is a multi-part message in MIME format. --------------7E1BA5F47718B01A0AA3000D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I get your 1st party use case and if you think about a company that might have multiple endpoints on different domains that provide API services all invoked by a mobile app... requiring the mobile app to effectively downscope (or resource indicator bind) tokens means a lot of chatter between the mobile app to the AS to obtain appropriate tokens. And all this over a connection that does have latency issues. That said, having a single token that is authorized to access all those services has it's own risks. I'm not sure about a structure like...    https://user.example.com       scope: profile    https://mail.example.com       scope: mail-write    https://cal.example.com       scope: calendar-write User Managed Access (UMA) [1] explicitly defines this structure but it's not embedded in the UMA access token. [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint I suppose a need to support multiple audiences within a given access token kind of necessitates the need to bind the scopes with the audience/resource. On 4/4/19 1:34 PM, Vittorio Bertocci wrote: > > I think for most implementations this would amount to... define an > audience that covers all the resource services where the access > token can be returned and set that as the audience (e.g. > urn:x-mydomain:apis). Which is perfectly legal but maybe not in > the spirit of the spec:) I am receiving feedback from developers > that binding access tokens narrowly to the resource where they > will be presented is concerning from a chattiness perspective > (latency issues) and general load on the deployed AS infrastructure. > > This is an interesting point. In my experience, the main boundary used > to define a resource is either reflecting an underlying, *actual* > resource that exists independently of the API facade slapped on top of > it (say a VM) or it is the context within a certains et of scopes > makes sense (say an API facading access to a bunch of documents). > Some of that criterion is reflected in the rationale for sigle value > audiences. Do you think it should be made more explicit? Perhaps in a > dedicated section? [rest of thread snipped] --------------7E1BA5F47718B01A0AA3000D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I get your 1st party use case and if you think about a company that might have multiple endpoints on different domains that provide API services all invoked by a mobile app... requiring the mobile app to effectively downscope (or resource indicator bind) tokens means a lot of chatter between the mobile app to the AS to obtain appropriate tokens. And all this over a connection that does have latency issues.

That said, having a single token that is authorized to access all those services has it's own risks.

I'm not sure about a structure like...
   https://user.example.com
      scope: profile
   https://mail.example.com
      scope: mail-write
   https://cal.example.com
      scope: calendar-write

User Managed Access (UMA) [1] explicitly defines this structure but it's not embedded in the UMA access token.

[1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint

I suppose a need to support multiple audiences within a given access token kind of necessitates the need to bind the scopes with the audience/resource.

On 4/4/19 1:34 PM, Vittorio Bertocci wrote:
I think for most implementations this would amount to... define an audience that covers all the resource services where the access token can be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is perfectly legal but maybe not in the spirit of the spec:) I am receiving feedback from developers that binding access tokens narrowly to the resource where they will be presented is concerning from a chattiness perspective (latency issues) and general load on the deployed AS infrastructure.
This is an interesting point. In my experience, the main boundary used to define a resource is either reflecting an underlying, *actual* resource that exists independently of the API facade slapped on top of it (say a VM) or it is the context within a certains et of scopes makes sense (say an API facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value audiences. Do you think it should be made more explicit? Perhaps in a dedicated section?
[rest of thread snipped]

  


--------------7E1BA5F47718B01A0AA3000D--


From nobody Thu Apr  4 12:48:45 2019
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 468A91204BE for ; Thu,  4 Apr 2019 12:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 RHjIi8ZRqomF for ; Thu,  4 Apr 2019 12:48:38 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650126.outbound.protection.outlook.com [40.107.65.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBF8120427 for ; Thu,  4 Apr 2019 12:48:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=hZ+HE9pE8dRKxg7vQTF+C/UdA+zI1ur0YLmTxqBJG9YWXFzAndw4/OhuFfVQxzHPb8tF/c1ZDTKY3vK8GnkbWx72202Ceo4us1myWiwYkmqJtKEH/Hznf6qIapzZvuIBy4O0YpmqmXrqrw4DuOP2B2VH87SVecsCAkTcggP+JGc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U7X4QXMRoCEoDUW2yPZnz+q8EVupVXd0FBPxQILqC88=; b=cakMjRK/LjxP2lhuy18aLurtNBtX+dczfACkkHc1QQqCJkvi4EcMmMA23hsSvt6Y/FQ6mgyR2WLNRLLf8BtCyRUO+CEa8/v9QAZoBvliEqvoZy9YhMSkFhXcTSVRtbPd7ErQGiyA7yCx23/DY2itUTw4ezmBY0W0bFHAQYuRpvY=
ARC-Authentication-Results: i=1; test.office365.com 1;dmarc=none action=none header.from=microsoft.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U7X4QXMRoCEoDUW2yPZnz+q8EVupVXd0FBPxQILqC88=; b=QPmPN6668rl0N/4EuRmkJFbdczWutAbkZGzGQduJvRPSfXPm25FI/somX7UYxH69MRAgNbX7BQ10nV7QAWn3G5cs35vE49V4z/8w96SlPYViSb/RkbUznAbh7xTGW51ieS7u9OAr82a3qH27bNmFmVPm+QyynYptXmsYmF3zKuE=
Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0448.namprd00.prod.outlook.com (52.132.118.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1800.0; Thu, 4 Apr 2019 19:48:34 +0000
Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::d017:ba79:6e59:70b]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::d017:ba79:6e59:70b%3]) with mapi id 15.20.1813.000; Thu, 4 Apr 2019 19:48:34 +0000
From: Mike Jones 
To: George Fletcher , Hans Zandbelt 
CC: Vittorio Bertocci , IETF oauth WG 
Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Thread-Index: AQHU4plzn+J3IOowe0OXYYpdxUABdqYbvMyAgACe2ICAAAThAIAAC2CAgAABTACAAJjzgIAADBmAgABhiACAACYMAIAAiF0AgAACU4CADNOJgIAAAkaAgAE81oCAAEGb8A==
Date: Thu, 4 Apr 2019 19:48:33 +0000
Message-ID: 
References:               <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>
In-Reply-To: <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>
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=5e15aff7-6c17-48dd-86c0-0000b297ac95; 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=2019-04-04T19:45:38-0800; 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: [2001:4898:80e8:9:b06a:53dc:1605:18d6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3d7cca39-0661-4dd4-2b24-08d6b936859f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR00MB0448; 
x-ms-traffictypediagnostic: SN6PR00MB0448:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(376002)(396003)(39860400002)(189003)(199004)(51914003)(81166006)(81156014)(105586002)(25786009)(52536014)(790700001)(30864003)(10090500001)(440504004)(4326008)(5660300002)(71200400001)(5070765005)(22452003)(8676002)(186003)(8990500004)(6436002)(53386004)(6116002)(6246003)(74316002)(316002)(106356001)(606006)(99286004)(46003)(53546011)(476003)(229853002)(102836004)(11346002)(68736007)(256004)(6506007)(93886005)(517774005)(53946003)(446003)(86612001)(14444005)(8936002)(54906003)(76176011)(53936002)(71190400001)(478600001)(110136005)(7736002)(10290500003)(33656002)(486006)(72206003)(7696005)(97736004)(2906002)(86362001)(236005)(9686003)(966005)(14454004)(6306002)(54896002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0448; H:SN6PR00MB0304.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dT4f2NcNju3NMFkUwk3Bidveii6f94KYV7GfJdHa5etMQMN29XnqqRLw/tKuVgGQoknDefvzlsA3QkKIsJT/aPRk8sWjdoa9/U0ViYK/FdHwyhQBhhzXC8YD8NG2VqX9aR/90OSWQ/M1bNwQIWcW0sqTifBQERso1qLl2VVyElqeljfZkg4egN7oxXygs+aP2W/698EuUFDMK7Ke2TWl0AgwnHtXCzOvKNqweTDLjbNFXnLt2xGq0ttyU+49e+Fu2mdDwnWIksXKWqxaioqYF9k2PyIGu4nJzl/CWc/0duvT7i+xb7BFEFSoRG5o6BEBfw7G77UurQFRZo2M7k5cNS2XnCvcH2gXLpemqy0iPiAK8GK0NvgfTTwaVuFKIV7KFJfFLYLzyfJvdbiaLiEwqjUth6mzHtX8YTSDngZHja8=
Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0304BC3C7D438F8A5715B36DF5500SN6PR00MB0304namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d7cca39-0661-4dd4-2b24-08d6b936859f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 19:48:33.8938 (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-Transport-CrossTenantHeadersStamped: SN6PR00MB0448
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 04 Apr 2019 19:48:43 -0000

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

SSBhZ3JlZSB3aXRoIEdlb3JnZSB0aGF0IHRoZSBzdWJqZWN0IG9mIGEgdG9rZW4gbXVzdCBiZSB0
aGUgcHJpbmNpcGFsIG9mIHRoYXQgdG9rZW4uICBUaGF0IHdoYXQgdGhlIEpXVCDigJxzdWLigJ0g
Y2xhaW0gaXMgZm9yLiAgSW5kZWVkLCB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIOKAnHN1YuKA
nSBkZWZpbml0aW9uIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rp
b24tNC4xLjIgaXM6DQpUaGUgInN1YiIgKHN1YmplY3QpIGNsYWltIGlkZW50aWZpZXMgdGhlIHBy
aW5jaXBhbCB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBKV1QuDQoNCklmIGFuIGFjY2VzcyB0
b2tlbiB1c2VzIOKAnHN1YuKAnSwgaXRzIHVzYWdlIG11c3QgY29tcGx5IHdpdGggdGhlIGRlZmlu
aXRpb24gZnJvbSBSRkMgNzUxOS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHZW9yZ2UgRmxldGNoZXINClNlbnQ6
IFRodXJzZGF5LCBBcHJpbCA0LCAyMDE5IDg6NTEgQU0NClRvOiBIYW5zIFphbmRiZWx0IDxoYW5z
LnphbmRiZWx0QHptYXJ0em9uZS5ldT4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89
NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10
b2tlbi1qd3QtMDANCg0KVGhlIG1vcmUgSSB0aGluayBhYm91dCB0aGlzIHRoZSBtb3JlIEkgbGFu
ZCBpbiB0aGUgIk5vIiBjYW1wLg0KDQpUaGUgc3ViamVjdCBvZiBhIHRva2VuIHNob3VsZCBiZSB0
aGUgcHJpbmNpcGFsIG9mIHRoYXQgdG9rZW4uIEl0IHNob3VsZG4ndCBtYXR0ZXIgd2hldGhlciB0
aGF0IGlzIGEgbWFjaGluZSwgYSB1c2VyLCBvciBhIGRldmljZS4gVHJ5aW5nIHRvIHNlcGFyYXRl
IG91dCAiaHVtYW5zIiBhcyBhIHNwZWNpYWwgY2xhc3Mgd2lsbCBqdXN0IG1ha2UgdGhpbmdzIG1v
cmUgY29tcGxpY2F0ZWQuIElmIHdlIG5lZWQgYSBjbGFpbSB0byBpZGVudGlmeSB0aGUgc3ViamVj
dCBpcyBhICJodW1hbiIgdGhlbiB3aHkgbm90IGp1c3QgYWRkIHRoYXQuIFRoaXMgZG9lc24ndCBi
cmVhayBhbnl0aGluZyBhbmQgbWFrZXMgaXQgZWFzeSBmb3IgcGVvcGxlIHRvIGRldGVjdCB0aGlz
IGNhc2UgaW4gdGhvc2UgdXNlIGNhc2VzIHdoZXJlIGl0J3MgcmVxdWlyZWQuDQoNClRoYW5rcywN
Ckdlb3JnZQ0KT24gNC8zLzE5IDQ6NTYgUE0sIEhhbnMgWmFuZGJlbHQgd3JvdGU6DQpJIHdpbGwg
YXJndWUgdGhhdCBpbiBhIHdheSBzdWNoIGRlcGxveW1lbnRzIGFyZSBhbHJlYWR5IGJyb2tlbiBl
LmcuIGluIHRoZSB0eXBpY2FsIHVzZSBjYXNlIG9mIG9uYm9hcmRpbmcgY2xpZW50IGFjY291bnRz
IGluIHRoZSBzYW1lIGRpcmVjdG9yeS9PVS9uYW1lc3BhY2UgYXMgdXNlciBhY2NvdW50cyBhbmQg
d2UgZG9uJ3QgbmVlZCB0byBjYXRlciBmb3IgdGhhdC4NCg0KSGFucy4NCg0KT24gV2VkLCBBcHIg
MywgMjAxOSBhdCAxMDo0OCBQTSBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoQGFvbC5jb208bWFp
bHRvOmdmZmxldGNoQGFvbC5jb20+PiB3cm90ZToNCkkgYWdyZWUgdGhhdCB0aGlzIHdpbGwgYnJl
YWsgYSBsb3Qgb2YgZXhpc3RpbmcgZmxvd3MuLi4gZXNwZWNpYWxseSB0aG9zZSB1c2luZyBhbnkg
Zm9ybSBvZiB0aGUgY2xpZW50X2NyZWRlbnRpYWxzIGZsb3cuIEluIHRoYXQgc2Vuc2UgSSdtIG5v
dCBjb21wbGV0ZWx5IG9uIGJvYXJkIHlldCA6KQ0KT24gMy8yNi8xOSAxMjo1NiBQTSwgSGFucyBa
YW5kYmVsdCB3cm90ZToNCmdyZWF0IHN1bW1hcnkhIHRoaXMgd2lsbCBodXJ0IHF1aXRlIGEgZmV3
IGV4aXN0aW5nIG0ybSBkZXBsb3ltZW50cyBidXQgSSBkbyBsaWtlIHRoZSByaWdpZG5lc3Mgb2Yg
aXQgYWxsOiBpdCBpcyB2ZXJ5IGV4cGxpY2l0LCBjYW5ub3QgbWlzaW50ZXJwcmV0ZWQgYW5kIHRo
dXMgcHJldmVudHMgZmFpbHVyZSAod2hpY2ggaXMgcmVhbGx5IHdoYXQgRG9taW5pY2sgaXMgYWZ0
ZXIpOyBJJ20gb24gYm9hcmQNCg0KSGFucy4NCg0KT24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgNTo0
OSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v
cmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQp0aGFuayB5b3Ug
U3RlaW5hciBhbmQgZXZlcnlvbmUgZWxzZSBmb3IgdGhlIGNvbW1lbnRzIG9uIHRoaXMhDQpUbyBz
dW1tYXJpemUgdGhlIHNpdHVhdGlvbiBzbyBmYXI6IERvbWluaWNrLCBTdGVpbmFyLCBSb2IsIERh
dmlkLCBOb3YsIEJlcnRyYW5kIHJlY29tbWVuZCB1c2luZyBzdWIgb25seSBmb3IgdXNlcnMuIE1h
cnRpbiB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIHN1YiBmb3IgYXBwIG9ubHkgZmxvd3MgYXMgd2Vs
bC4gSGFucyBpcyBuZXV0cmFsLg0KVGhhdCBkb2VzIHNvdW5kIGxpa2UgdGhlIHN1YiBhcyB1c2Vy
IGhhcyBtb3JlIGNvbnNlbnN1cywgdGhvIGJlZm9yZSBjaGFuZ2luZyBpdCBJJ2Qgd2FpdCBmb3Ig
dGhlIHBlb3BsZSBjdXJyZW50bHkgYXQgSUVURjEwNCB0byBoYXZlIG1vcmUgdGltZSB0byBjb21t
ZW50IGFzIHdlbGwuDQpDbGFyaWZpY2F0aW9uLiBJZiB0aGUgZ29hbCBpcyB0byBiZSBhYmxlIHRv
IGFwcGx5IHRoZSBsb2dpYyAiaWYgdGhlcmUncyBhIHN1YiwgaXQncyBhIHVzZXIgZmxvdyIsIHdl
IGhhdmUgdG8gZXhwbGljaXRseSBkaXNhbGxvdyAoTVVTVCBOT1QpIHRoZSB1c2Ugb2Ygc3ViIHdo
ZW4gdGhhdCdzIG5vdCB0aGUgY2FzZS4gQXJlIGFsbCBPSyB3aXRoIGl0Pw0KDQpEYXZlLCB0aGUg
c3VnZ2VzdGlvbiBvZiBoYXZpbmcgZXhwbGljaXQgdHlwaW5nIGZvciBhcHAgb25seSB2cyB1c2Vy
IG9ubHkgaXMgaW50ZXJlc3RpbmchIEZvciB0aGUgcHVycG9zZSBvZiBwdXR0aW5nIHRvZ2V0aGVy
IGFuIGludGVyb3BlcmFibGUgcHJvZmlsZSwgdGhvLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgdGFibGUg
aXQgZm9yIHYxIGluIHRoZSBpbnRlcmVzdCBvZiBnZXR0aW5nIHRvIHNvbWV0aGluZyBlYXN5IHRv
IGFkb3B0IChoZW5jZSB3aXRoIHNtYWxsIGRlbHRhIHZzIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u
cykgZmFzdGVyLg0KDQpPbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAxOjQwIEFNIFN0ZWluYXIgTm9l
bSA8c3RlaW5hckB1ZGVsdC5ubzxtYWlsdG86c3RlaW5hckB1ZGVsdC5ubz4+IHdyb3RlOg0KSGkg
Vml0dG9yaW8sIHdlICAodGhlIG5hdGlvbmFsIGZlZGVyYXRpb24tZ2F0ZXdheSBmb3IgdGhlIGhl
YWx0aCBzZXJ2aWNlcyBpbiBub3J3YXkgLSAiSGVsc2VJRCIpICB0aGluayBoaXMgaXMgYSByZWFs
bHkgdmFsdWFibGUgaW5pdGlhdGl2ZSENCldlIGFsc28gYWdyZWUgd2l0aCBEb21pbmljayBjb25j
ZXJuaW5nIGRlZmluaXRpb24gb2YgdGhlICJzdWIiIGNsYWltLg0KDQo8bXZoPlN0ZWluYXI8L212
aD4NCg0KdGlyLiAyNi4gbWFyLiAyMDE5IGtsLiAwNzoyNSBza3JldiBEb21pbmljayBCYWllciA8
ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNv
bT4+Og0KRnJvbSBhbiBhY2Nlc3MgdG9rZW4gY29uc3VtZXIgKGFrYSBBUEkpIGRldmVsb3BlciBw
b2ludCBvZiB2aWV3LCBJIHByZWZlciB0aGlzIGxvZ2ljDQoNCiJJZiBzdWIgaXMgcHJlc2VudCAt
IGNsaWVudCBhY3RzIG9uIGJlaGFsZiBvZiBhIHVzZXIsIGlmIG5vdCAtIG5vdC4iDQoNCkFueXRo
aW5nIG1vcmUgY29tcGxpY2F0ZWQgaGFzIGEgcG90ZW50aWFsIG9mIGdvaW5nIHdyb25nLg0KDQoN
Ck9uIDI2LiBNYXJjaCAyMDE5IGF0IDAxOjM0OjUzLCBOb3YgTWF0YWtlIChtYXRha2VAZ21haWwu
Y29tPG1haWx0bzptYXRha2VAZ21haWwuY29tPikgd3JvdGU6DQpIaSBWaXR0b3JpbywNCg0KWWVh
aCwgSeKAmW0gY29uY2VybmluZyB1c2VyICYgY2xpZW50IGlkcyBjb2xsaXNpb24uDQpJIGhhdmVu
4oCZdCBzZWVuIHN1Y2ggaW1wbGVtZW50YXRpb25zLCBidXQgdXNlci1zZWxlY3QgdXNlcm5hbWUg
YXMgc3ViLCBvciBpbmNyZW1lbnRhbCBpbnRlZ2VyIGFzIHN1YiAmIGNsaWVudF9pZCB3aWxsIGJl
IGVhc2lseSBjb2xsaWRlLg0KDQpJZiB5b3UgY2FuIGVuZm9yY2UgY29sbGlzaW9uIHJlc2lzdGFu
dCBJRHMgYmV0d2VlbiB1c2VyICYgY2xpZW50IGluc3RhbmNlcywgaXTigJlsbCB3b3JrcyBmaW5l
LiBJIGZlZWwgaXRzIG92ZXJraWxsIHRob3VnaC4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpP
biBNYXIgMjYsIDIwMTksIGF0IDg6NTEsIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRo
MC5jb208bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+IHdyb3RlOg0KSGV5IE5vdiwgRG9taW5p
Y2ssIEhhbnMtDQp0aGFua3MgZm9yIHRoZSBjb21tZW50cy4gVGhhdCB3YXMgYW4gYXJlYSBJIHdh
cyBleHBlY3RpbmcgdG8gY2F1c2UgbW9yZSBkaXNjdXNzaW9uLCBhbmQgSSBhbSBnbGFkIHdlIGFy
ZSBoYXZpbmcgdGhpcyBvcHBvcnR1bml0eSB0byBjbGFyaWZ5Lg0KVGhlIGN1cnJlbnQgbGFuZ3Vh
Z2UgaW4gdGhlIGRyYWZ0IHRyYWNlcyB0aGUgZXR5bW9sb2d5IG9mIHN1YiB0byBPcGVuSUQgQ29u
bmVjdCBjb3JlLCBoZW5jZSBEb21pbmljayBvYnNlcnZhdGlvbiBpcyBvbiBwb2ludC4gSG93ZXZl
ciBpbiB0aGUgZGVzY3JpcHRpb24gSSBleHByZXNzIHNvbWV0aGluZyBpbiBsaW5lIHdpdGggNzUx
OSwgd2hpY2ggd2FzIGluIGZhY3QgbXkgaW50ZW50Lg0KDQpUaGUgaWRlYSB3YXMgdG8gcHJvdmlk
ZSBhbiBpZGVudGlmaWVyIG9mIHRoZSBjYWxsaW5nIHN1YmplY3QgdGhhdCBpcyBndWFyYW50ZWVk
IHRvIGJlIHByZXNlbnQgaW4gYWxsIGNhc2VzLSB0aGlzIHdvdWxkIGFsbG93IGFuIFNESyBkZXZl
bG9wZXIgdG8gdXNlIHRoZSBzYW1lIGNvZGUgZm9yIHRoaW5ncyBsaWtlIGxvb2t1cHMgYW5kIG1l
bWJlcnNoaXAgY2hlY2tzIHJlZ2FyZGxlc3Mgb2YgdGhlIG5hdHVyZSBvZiB0aGUgY2FsbGVyICh1
c2VyIGluIGEgZGVsZWdhdGVkIGNhc2UsIGFwcCBpbiBhcHAtb25seSBncmFudHMpLiBUaGUgaW5m
b3JtYXRpb24gdG8gZGlzY3JpbWluYXRlIGJldHdlZW4gdXNlciBhbmQgYXBwIGNhbGxlcnMgaXMg
YWx3YXlzIGF2YWlsYWJsZSBpbiB0aGUgdG9rZW4gKHNheSwgdGhlIGNhbGxlciBpcyBhIHVzZXIg
aWYgc3ViIT1jbGllbnRfaWQsIHdoZXJlIGNsaWVudF9pZCBpcyBhbHdheXMgZ3VhcmFudGVlZCB0
byBiZSBwcmVzZW50IGFzIHdlbGwpIGhlbmNlIHRoZXJlJ3Mgbm8gbG9zcyBpbiBleHByZXNzaXZl
IHBvd2VyLCBzaG91bGQgdGhhdCBkaWZmZXJlbmNlIGJlIHJlbGV2YW50IGZvciB0aGUgcmVzb3Vy
Y2Ugc2VydmVyLg0KDQpEb21pbmljaywgSGFucy0gSSBwcm9iYWJseSBtaXNzZWQgdGhlIHNlY3Vy
aXR5IGlzc3VlIHlvdSBndXlzIGFyZSB0aGlua2luZyBvZiBpbiB0aGlzIGNhc2UuIE9mIGNvdXJz
ZSwgaWYgdGhpcyB3b3VsZCBpbnRyb2R1Y2UgYSByaXNrIEkgY29tcGxldGVseSBhZ3JlZSBpdCBz
aG91bGQgYmUgY2hhbmdlZC0gSSdkIGp1c3QgbGlrZSB0byB1bmRlcnN0YW5kIGJldHRlciB0aGUg
cHJvYmxlbS4gQ291bGQgeW91IGV4cGFuZCBpdCBpbiBhIHNjZW5hcmlvL3VzZSBjYXNlIHRvIGNs
YXJpZnkgdGhlIHJpc2s/DQpOb3YtIHBsYXlpbmcgdGhpcyBiYWNrOiBpcyB0aGUgY29uY2VybiB0
aGF0IGEgdXNlciBhbmQgYSBjbGllbnQgbWlnaHQgaGF2ZSB0aGUgc2FtZSBpZGVudGlmaWVyIHdp
dGhpbiBhbiBJRFA/IFdoZW4gdXNpbmcgY29sbGlzaW9uIHJlc2lzdGFudCBJRHMsIGFzIGl0IGlz
IHVzdWFsbHkgdGhlIGNhc2UsIHRoYXQgc2VlbXMgdG8gYmUgYSByZW1vdGUgcG9zc2liaWxpdHkt
IGRpZCB5b3Ugc3R1bWJsZSBpbiBzdWNoIHNjZW5hcmlvIGluIHByb2R1Y3Rpb24/DQoNClRoYW5r
cw0KVi4NCg0KDQpPbiBNb24sIE1hciAyNSwgMjAxOSBhdCA3OjQ0IEFNIEhhbnMgWmFuZGJlbHQg
PGhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9u
ZS5ldT4+IHdyb3RlOg0KSSBiZWxpZXZlIHRoZXJlIGFyZSBwbGVudHkgb2YgT0F1dGggMi4wIG9u
bHkgdXNlIGNhc2VzIG91dCB0aGVyZS4uLiBidXQgbmV2ZXJ0aGVsZXNzIEkgYWdyZWUgd2l0aCB0
aGUgcG90ZW50aWFsIGNvbmZ1c2lvbiBhbmQgdGh1cyBzZWN1cml0eSBwcm9ibGVtcyBhcmlzaW5n
IGZyb20gdGhhdCAodGhvdWdoIG9uZSBtYXkgYXJndWUgdGhlIHNlbWFudGljcyBhcmUgdGhlIHNh
bWUpLg0KDQpIYW5zLg0KDQpPbiBNb24sIE1hciAyNSwgMjAxOSBhdCAzOjM5IFBNIERvbWluaWNr
IEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2
aWxlZ2UuY29tPj4gd3JvdGU6DQpZZXMgSSBrbm93IC0gYW5kIEkgdGhpbmsgaW4gaGluZHNpZ2h0
IGl0IHdhcyBhIG1pc3Rha2UgdG8gdXNlIHRoZSBzYW1lIGNsYWltIHR5cGUgZm9yIG11bHRpcGxl
IHNlbWFudGljcy4NCg0KQWxsIHRoZSDigJx0aGlzIGlzIE9JREMgbm90IE9BdXRo4oCdIGFyZ3Vt
ZW50cyBhcmUgbWFraW5nIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhleSBuZWVkIHRv
IGJlIC0gaW4gbXkgZXhwZXJpZW5jZSBhbG1vc3Qgbm8tb25lICh0aGF0IEkga25vdykgZG9lcyBP
SURDIG9ubHkgLSBub3IgT0F1dGggb25seS4gVGhleSBhbHdheXMgY29tYmluZSBpdC4NCg0KSW4g
cmVhbGl0eSB0aGlzIGxlYWRzIHRvIHBvdGVudGlhbCBzZWN1cml0eSBwcm9ibGVtcyAtIHRoaXMg
c3BlYyBoYXMgdGhlIHBvdGVudGlhbCB0byByZWN0aWZ5IHRoZSBzaXR1YXRpb24uDQoNCkRvbWlu
aWNrDQoNCk9uIDI1LiBNYXJjaCAyMDE5IGF0IDE0OjU4OjU2LCBIYW5zIFphbmRiZWx0IChoYW5z
LnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+
KSB3cm90ZToNCldpdGhvdXQgYWdyZWVpbmcgb3IgZGlzYWdyZWVpbmc6IE9JREMgZG9lcyBub3Qg
YXBwbHkgaGVyZSBzaW5jZSBpdCBpcyBub3QgT0F1dGggYW5kIGFuIGFjY2VzcyB0b2tlbiBpcyBu
b3QgYW4gaWRfdG9rZW4uDQpUaGUgSldUIHNwZWMgc2F5cyBpbiBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yOg0KDQoiVGhlICJzdWIiIChzdWJqZWN0KSBj
bGFpbSBpZGVudGlmaWVzIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0aGUNCiAgIHN1YmplY3Qgb2Yg
dGhlIEpXVC4gIFRoZSBjbGFpbXMgaW4gYSBKV1QgYXJlIG5vcm1hbGx5IHN0YXRlbWVudHMNCiAg
IGFib3V0IHRoZSBzdWJqZWN0LiAgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRoZXIgYmUgc2Nv
cGVkIHRvIGJlDQogICBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVy
IG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS4NCiAgIFRoZSBwcm9jZXNzaW5nIG9mIHRoaXMgY2xhaW0g
aXMgZ2VuZXJhbGx5IGFwcGxpY2F0aW9uIHNwZWNpZmljIg0KDQp3aGljaCBraW5kIG9mIHNwZWxs
cyAiY2xpZW50IiBpbiBjYXNlIG9mIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQgYnV0IEkg
YWxzbyBkbyB3b3JyeSBhYm91dCBSZXNvdXJjZSBTZXJ2ZXJzIHRoaW5raW5nL2FjdGluZyBvbmx5
IGluIHRlcm1zIG9mIHVzZXJzDQoNCkhhbnMuDQoNCk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDI6
NDEgUE0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRi
YWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCklNSE8gdGhlIHN1YiBjbGFpbSBzaG91
bGQgYWx3YXlzIHJlZmVyIHRvIHRoZSB1c2VyIC0gYW5kIG5vdGhpbmcgZWxzZS4NCg0KT0lEQyBz
YXlzOg0KDQoiU3ViamVjdCAtIElkZW50aWZpZXIgZm9yIHRoZSBFbmQtVXNlciBhdCB0aGUgSXNz
dWVyLiINCg0KY2xpZW50X2lkIHNob3VsZCBiZSB1c2VkIHRvIGlkZW50aWZ5IGNsaWVudHMuDQoN
CmNoZWVycw0KRG9taW5pY2sNCg0KDQpPbiAyNS4uIE1hcmNoIDIwMTkgYXQgMDU6MTM6MDMsIE5v
diBNYXRha2UgKG1hdGFrZUBnbWFpbC5jb208bWFpbHRvOm1hdGFrZUBnbWFpbC5jb20+KSB3cm90
ZToNCkhpIFZpdHRvcmlvLA0KDQpUaGFua3MgZm9yIHRoZSBnb29kIHN0YXJ0aW5nIHBvaW50IG9m
IHN0YW5kYXJkaXppbmcgSldULWl6ZWQgQVQuDQoNCk9uZSBmZWVkYmFjay4NClRoZSDigJxzdWLi
gJ0gY2xhaW0gY2FuIGluY2x1ZGUgMiB0eXBlcyBvZiBpZGVudGlmaWVyLCBlbmQtdXNlciBhbmQg
Y2xpZW50LCBpbiB0aGlzIHNwZWMuDQpJdCByZXF1aXJlcyB0aG9zZSAyIHR5cGVzIG9mIGlkZW50
aWZpZXJzIHRvIGJlIHVuaXF1ZSBlYWNoIG90aGVyIGluIHRoZSBJZFAgY29udGV4dC4NCg0KSSBw
cmVmZXIgb21pdHRpbmcg4oCcc3Vi4oCdIGNsYWltIGluIDItbGVnZ2VkIGNvbnRleHQsIHNvIHRo
YXQgbm8gc3VjaCBjb25zdHJhaW50IG5lZWRlZC4NCg0KdGhhbmtzDQoNCm5vdg0KDQoNCk9uIE1h
ciAyNSwgMjAxOSwgYXQgODoyOSwgVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2Np
PTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaT00MGF1
dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpEZWFyIGFsbCwNCkkganVzdCBzdWJt
aXR0ZWQgYSBkcmFmdCBkZXNjcmliaW5nIGEgSldUIHByb2ZpbGUgZm9yIE9BdXRoIDIuMCBhY2Nl
c3MgdG9rZW5zLiBZb3UgY2FuIGZpbmQgaXQgaW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8uDQpJIGhhdmUgYSBz
bG90IHRvIGRpc2N1c3MgdGhpcyB0b21vcnJvdyBhdCBJRVRGIDEwNCAoSSdsbCBiZSBwcmVzZW50
aW5nIHJlbW90ZWx5KS4gSSBsb29rIGZvcndhcmQgZm9yIHlvdXIgY29tbWVudHMhDQoNCkhlcmUn
cyBqdXN0IGEgYml0IG9mIGJhY2tzdG9yeSwgaW4gY2FzZSB5b3UgYXJlIGludGVyZXN0ZWQgaW4g
aG93IHRoaXMgZG9jIGNhbWUgdG8gYmUuIFRoZSB0cmFqZWN0b3J5IGl0IGZvbGxvd2VkIGlzIHNv
bWV3aGF0IHVudXN1YWwuDQoNCiAgKiAgIERlc3BpdGUgT0F1dGgyIG5vdCByZXF1aXJpbmcgYW55
IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0aHJvdWdoIHRoZSB5ZWFycyBJIGhhdmUgY29tZSBh
Y3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkgc29sdXRpb24gdXNpbmcgSldUIGZvciB0aGVpciBh
Y2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5kIHNjZW5hcmlvcyBhZGRyZXNzZWQgYnkgdGhvc2Ug
c29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNhbWUgYWNyb3NzIHZlbmRvcnMsIGJ1dCB0aGUgc3lu
dGF4IGFuZCBpbnRlcnByZXRhdGlvbnMgaW4gdGhlIGltcGxlbWVudGF0aW9ucyBhcmUgZGlmZmVy
ZW50IGVub3VnaCB0byBwcmV2ZW50IGRldmVsb3BlcnMgZnJvbSByZXVzaW5nIGNvZGUgYW5kIHNr
aWxscyB3aGVuIG1vdmluZyBmcm9tIHByb2R1Y3QgdG8gcHJvZHVjdC4NCiAgKiAgIEkgYXNrZWQg
c2V2ZXJhbCBpbmRpdmlkdWFscyBmcm9tIGtleSBwcm9kdWN0cyBhbmQgc2VydmljZXMgdG8gc2hh
cmUgd2l0aCBtZSBjb25jcmV0ZSBleGFtcGxlcyBvZiB0aGVpciBKV1QgYWNjZXNzIHRva2VucyAo
VEhBTksgWU9VIERvbWluaWNrIEJhaWVyIChJZGVudGl0eVNlcnZlciksIEJyaWFuIENhbXBiZWxs
IChQaW5nSWRlbnRpdHkpLCBEYW5pZWwgRG9iYWxpYW4gKE1pY3Jvc29mdCksIEthcmwgR3Vpbm5l
c3MgKE9rdGEpIGZvciB0aGUgdG9rZW5zIGFuZCBleHBsYW5hdGlvbnMhKS4NCkkgc3R1ZGllZCBh
bmQgY29tcGFyZWQgYWxsIHRob3NlIGluc3RhbmNlcywgaWRlbnRpZnlpbmcgY29tbW9uYWxpdGll
cyBhbmQgZGlmZmVyZW5jZXMuDQogICogICBJIHB1dCB0b2dldGhlciBhIHByZXNlbnRhdGlvbiBz
dW1tYXJpemluZyBteSBmaW5kaW5ncyBhbmQgc3VnZ2VzdGluZyBhIHJvdWdoIGludGVyb3BlcmFi
bGUgcHJvZmlsZSAoc2xpZGVzOiBodHRwczovL3NlYy51bmktc3R1dHRnYXJ0LmRlL19tZWRpYS9l
dmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMucHB0
eDxodHRwczovL3NlYy4udW5pLXN0dXR0Z2FydC5kZS9fbWVkaWEvZXZlbnRzL29zdzIwMTkvc2xp
ZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJvZmlsZV9mb3JfYXRzLnBwdHg+ICkgLSBnb3QgZWFybHkg
ZmVlZGJhY2sgZnJvbSBGaWxpcCBTa29rYW4gb24gaXQuIFRoeCBGaWxpcCENCiAgKiAgIFRoZSBw
cmVzZW50YXRpb24gd2FzIGZvbGxvd2VkIHVwIGJ5IDEuNSBob3VycyBvZiB1bmNvbmZlcmVuY2Ug
ZGlzY3Vzc2lvbiwgd2hpY2ggd2FzIGluY3JlZGlibHkgdmFsdWFibGUgdG8gZ2V0IHRpZ2h0LWxv
b3AgZmVlZGJhY2sgYW5kIGluY29ycG9yYXRlIG5ldyBpZGVhcy4gSm9obiBCcmFkbGV5LCBCcmlh
biBDYW1wYmVsbCBWbGFkaW1pciBEemh1dmlub3YsIFRvcnN0ZW4gTG9kZGVyc3RlZHQsIE5hdCBT
YWtpbXVyYSwgSGFubmVzIFRzY2hvZmVuaWcgd2VyZSBhbGwgdGhlcmUgYW5kIGNvbnRyaWJ1dGVk
IGdlbmVyb3VzbHkgdG8gdGhlIGRpc2N1c3Npb24uIFRoYW5rIHlvdSEhIQ0KTm90ZTogaWYgeW91
IHdlcmUgYXQgT1NXMjAxOSwgcGFydGljaXBhdGVkIGluIHRoZSBkaXNjdXNzaW9uIGFuZCBkaWRu
J3QgZ2V0IGNyZWRpdGVkIGluIHRoZSBkcmFmdCwgbXkgYXBvbG9naWVzOiBwbGVhc2Ugc2VuZCBt
ZSBhIG5vdGUgYW5kIEknbGwgbWFrZSB0aGluZ3MgcmlnaHQgYXQgdGhlIG5leHQgdXBkYXRlLg0K
ICAqICAgT24gbXkgZmxpZ2h0IGJhY2sgSSBkaWQgbXkgYmVzdCB0byBpbmNvcnBvcmF0ZSBhbGwg
dGhlIGlkZWFzIGFuZCBmZWVkYmFjayBpbiBhIGRyYWZ0LCB3aGljaCB3aWxsIGJlIGRpc2N1c3Nl
ZCBhdCBJRVRGMTA0IHRvbW9ycm93LiBSaWZhYXQsIEhhbm5lcyBhbmQgYWJvdmUgYWxsIEJyaWFu
IHdlcmUgYWxsIHN1cGVyIGhlbHBmdWwgaW4gbmVnb3RpYXRpbmcgdGhlIG15c3RlcmlvdXMgc3lu
dGF4IG9mIHRoZSBSRkMgZm9ybWF0IGFuZCBzdWJtaXNzaW9uIHByb2Nlc3MuDQpJIHdhcyBibG93
biBhd2F5IGJ5IHRoZSBhdmFpbGFiaWxpdHksIGludm9sdmVtZW50IGFuZCB3aWxsaW5nbmVzcyB0
byBpbnZlc3QgdGltZSB0byBnZXQgdGhpbmdzIHJpZ2h0IHRoYXQgZXZlcnlvbmUgZGVtb25zdHJh
dGVkIGluIHRoZSBwcm9jZXNzLiBUaGlzIGlzIGFuIGFtYXppbmcgY29tbXVuaXR5Lg0KVi4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQoNCi0tDQpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVs
dEB6bWFydHpvbmUuZXU+DQpabWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0em9uZS5ldTxodHRwOi8v
d3d3LnptYXJ0em9uZS5ldT4NCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFp
bHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFy
dHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQoNCg0KLS0NClZlbm5saWcgaGlsc2VuDQoNClN0ZWluYXIgTm9lbQ0K
UGFydG5lciBVZGVsdCBBUw0KU3lzdGVtdXR2aWtsZXINCg0KfCBzdGVpbmFyQHVkZWx0Lm5vPG1h
aWx0bzpzdGVpbmFyQHVkZWx0Li5ubz4gfCBoZWlAdWRlbHQubm88bWFpbHRvOmhlaUB1ZGVsdC5u
bz4gIHwgKzQ3IDk1NSAyMSA2MjAgfCB3d3cudWRlbHQubm88aHR0cDovL3d3dy51ZGVsdC5uby8+
IHwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KaGFucy56
YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0K
Wm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K
DQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1h
cnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56
bWFydHpvbmUuZXU+DQoNCg==

--_000_SN6PR00MB0304BC3C7D438F8A5715B36DF5500SN6PR00MB0304namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg
NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpw
Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u
YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6
MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm
b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOmJsYWNrO30NCnAuZ21haWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5
MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5
ODI1Mzg0M2Fpcm1haWxvbiwgbGkuZ21haWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0x
NzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5
Mjk3NjA5ODI1Mzg0M2Fpcm1haWxvbiwgZGl2LmdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdt
YWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1t
LTE4NjE0OTI5NzYwOTgyNTM4NDNhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8t
NzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW1fLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW1fNTE5
ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW1fLTE4NjE0OTI5NzYwOTgyNTM4NDNhaXJtYWlsX29uOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5n
bWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWls
LW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgy
MDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2Fpcm1haWxvbiwgbGku
Z21haWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFp
bC1tNTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2dtYWlsLW04
MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdhaXJtYWlsb24sIGRp
di5nbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2Mmdt
YWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwt
bTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2Fpcm1haWxvbg0K
CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbV8tMTcw
Nzc5OTMzMjg4MDU3NzYyZ21haWwtbV81MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbV8tMTg2MTQ5
Mjk3NjA5ODI1Mzg0M2dtYWlsLW1fODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW1fMTI4MDcxNzk2
OTUxNTEwNjgxN2Fpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjpibGFjazt9DQpwLmdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW0t
MTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4NjE0
OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5
NTE1MTA2ODE3Z21haWwtbTg0NzU3Mjg2NTYyNDU0OTI0OTVhaXJtYWlsb24sIGxpLmdtYWlsLW0t
NzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgw
MDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDEx
Mzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3Z21haWwtbTg0NzU3Mjg2NTYyNDU0
OTI0OTVhaXJtYWlsb24sIGRpdi5nbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3
MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDky
OTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUx
NTEwNjgxN2dtYWlsLW04NDc1NzI4NjU2MjQ1NDkyNDk1YWlybWFpbG9uDQoJe21zby1zdHlsZS1u
YW1lOmdtYWlsLW1fLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tXy0xNzA3Nzk5MzMyODgwNTc3
NjJnbWFpbC1tXzUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tXy0xODYxNDkyOTc2MDk4MjUzODQz
Z21haWwtbV84MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbV8xMjgwNzE3OTY5NTE1MTA2ODE3Z21h
aWwtbV84NDc1NzI4NjU2MjQ1NDkyNDk1YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K
CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWNv
bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ5OTExMTEwOw0KCW1zby1saXN0LXRl
bXBsYXRlLWlkczoxODgxNTkzMDk4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk
aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps
ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w
aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t
Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHdpdGggR2VvcmdlIHRoYXQgdGhlIHN1Ympl
Y3Qgb2YgYSB0b2tlbiBtdXN0IGJlIHRoZSBwcmluY2lwYWwgb2YgdGhhdCB0b2tlbi4mbmJzcDsg
VGhhdCB3aGF0IHRoZSBKV1Qg4oCcc3Vi4oCdIGNsYWltIGlzIGZvci4mbmJzcDsgSW5kZWVkLCB0
aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIOKAnHN1YuKAnSBkZWZpbml0aW9uIGF0DQo8YSBocmVm
PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yIj5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yPC9hPiBpczo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2JhY2tncm91bmQ6d2hp
dGUiPlRoZSAmcXVvdDtzdWImcXVvdDsgKHN1YmplY3QpIGNsYWltIGlkZW50aWZpZXMgdGhlIHBy
aW5jaXBhbCB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBKV1QuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj5JZiBhbiBhY2Nlc3MgdG9rZW4gdXNlcyDigJxzdWLigJ0sIGl0
cyB1c2FnZSBtdXN0IGNvbXBseSB3aXRoIHRoZSBkZWZpbml0aW9uIGZyb20gUkZDIDc1MTkuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IE9BdXRoICZsdDtvYXV0aC1ib3VuY2Vz
QGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5HZW9yZ2UgRmxldGNoZXI8YnI+DQo8
Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDQsIDIwMTkgODo1MSBBTTxicj4NCjxiPlRvOjwv
Yj4gSGFucyBaYW5kYmVsdCAmbHQ7aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUmZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7Vml0dG9yaW89NDBhdXRoMC5jb21AZG1h
cmMuaWV0Zi5vcmcmZ3Q7OyBJRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNj
ZXNzLXRva2VuLWp3dC0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbW9yZSBJIHRoaW5rIGFi
b3V0IHRoaXMgdGhlIG1vcmUgSSBsYW5kIGluIHRoZSAmcXVvdDtObyZxdW90OyBjYW1wLjxicj4N
Cjxicj4NClRoZSBzdWJqZWN0IG9mIGEgdG9rZW4gc2hvdWxkIGJlIHRoZSBwcmluY2lwYWwgb2Yg
dGhhdCB0b2tlbi4gSXQgc2hvdWxkbid0IG1hdHRlciB3aGV0aGVyIHRoYXQgaXMgYSBtYWNoaW5l
LCBhIHVzZXIsIG9yIGEgZGV2aWNlLiBUcnlpbmcgdG8gc2VwYXJhdGUgb3V0ICZxdW90O2h1bWFu
cyZxdW90OyBhcyBhIHNwZWNpYWwgY2xhc3Mgd2lsbCBqdXN0IG1ha2UgdGhpbmdzIG1vcmUgY29t
cGxpY2F0ZWQuIElmIHdlIG5lZWQgYSBjbGFpbSB0byBpZGVudGlmeSB0aGUgc3ViamVjdA0KIGlz
IGEgJnF1b3Q7aHVtYW4mcXVvdDsgdGhlbiB3aHkgbm90IGp1c3QgYWRkIHRoYXQuIFRoaXMgZG9l
c24ndCBicmVhayBhbnl0aGluZyBhbmQgbWFrZXMgaXQgZWFzeSBmb3IgcGVvcGxlIHRvIGRldGVj
dCB0aGlzIGNhc2UgaW4gdGhvc2UgdXNlIGNhc2VzIHdoZXJlIGl0J3MgcmVxdWlyZWQuPGJyPg0K
PGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA0LzMvMTkgNDo1NiBQTSwgSGFucyBaYW5kYmVsdCB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB3aWxsIGFyZ3VlIHRoYXQgaW4gYSB3YXkgc3VjaCBkZXBsb3ltZW50cyBhcmUgYWxyZWFkeSBi
cm9rZW4gZS5nLiBpbiB0aGUgdHlwaWNhbCB1c2UgY2FzZSBvZiBvbmJvYXJkaW5nIGNsaWVudCBh
Y2NvdW50cyBpbiB0aGUgc2FtZSBkaXJlY3RvcnkvT1UvbmFtZXNwYWNlIGFzIHVzZXIgYWNjb3Vu
dHMgYW5kIHdlIGRvbid0IG5lZWQgdG8gY2F0ZXIgZm9yIHRoYXQuDQo8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbnMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDMsIDIwMTkgYXQg
MTA6NDggUE0gR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9s
LmNvbSI+Z2ZmbGV0Y2hAYW9sLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoYXQgdGhpcyB3aWxsIGJyZWFrIGEgbG90IG9m
IGV4aXN0aW5nIGZsb3dzLi4uIGVzcGVjaWFsbHkgdGhvc2UgdXNpbmcgYW55IGZvcm0gb2YgdGhl
IGNsaWVudF9jcmVkZW50aWFscyBmbG93LiBJbiB0aGF0IHNlbnNlIEknbSBub3QgY29tcGxldGVs
eSBvbiBib2FyZA0KIHlldCA6KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiAzLzI2LzE5IDEyOjU2IFBNLCBIYW5zIFphbmRiZWx0IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Z3JlYXQgc3VtbWFyeSEgdGhpcyB3aWxsIGh1cnQgcXVpdGUgYSBmZXcgZXhpc3RpbmcgbTJt
IGRlcGxveW1lbnRzIGJ1dCBJIGRvIGxpa2UgdGhlIHJpZ2lkbmVzcyBvZiBpdCBhbGw6IGl0IGlz
IHZlcnkgZXhwbGljaXQsIGNhbm5vdCBtaXNpbnRlcnByZXRlZCBhbmQgdGh1cyBwcmV2ZW50cyBm
YWlsdXJlICh3aGljaCBpcyByZWFsbHkgd2hhdCBEb21pbmljayBpcyBhZnRlcik7IEknbSBvbiBi
b2FyZA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYW5z
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBUdWUsIE1hciAyNiwgMjAxOSBhdCA1OjQ5IFBNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0
b3Jpbz08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PnRoYW5rIHlvdSBTdGVpbmFyIGFuZCBldmVyeW9uZSBlbHNlIGZvciB0aGUgY29tbWVudHMgb24g
dGhpcyENCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHN1
bW1hcml6ZSB0aGUgc2l0dWF0aW9uIHNvIGZhcjogRG9taW5pY2ssIFN0ZWluYXIsIFJvYiwgRGF2
aWQsIE5vdiwgQmVydHJhbmQgcmVjb21tZW5kIHVzaW5nIHN1YiBvbmx5IGZvciB1c2Vycy4gTWFy
dGluIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgc3ViIGZvciBhcHAgb25seSBmbG93cyBhcyB3ZWxs
LiBIYW5zIGlzIG5ldXRyYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGF0IGRvZXMgc291bmQgbGlrZSB0aGUgc3ViIGFzIHVzZXIgaGFzIG1v
cmUgY29uc2Vuc3VzLCB0aG8gYmVmb3JlIGNoYW5naW5nIGl0IEknZCB3YWl0IGZvciB0aGUgcGVv
cGxlIGN1cnJlbnRseSBhdCBJRVRGMTA0IHRvIGhhdmUgbW9yZSB0aW1lIHRvIGNvbW1lbnQgYXMg
d2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkNsYXJpZmljYXRpb24uIElmIHRoZSBnb2FsIGlzIHRvIGJlIGFibGUgdG8gYXBwbHkgdGhlIGxv
Z2ljICZxdW90O2lmIHRoZXJlJ3MgYSBzdWIsIGl0J3MgYSB1c2VyIGZsb3cmcXVvdDssIHdlIGhh
dmUgdG8gZXhwbGljaXRseSBkaXNhbGxvdyAoTVVTVCBOT1QpIHRoZSB1c2Ugb2Ygc3ViIHdoZW4g
dGhhdCdzIG5vdCB0aGUgY2FzZS4gQXJlIGFsbCBPSyB3aXRoIGl0PzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZlLCB0aGUgc3VnZ2VzdGlv
biBvZiBoYXZpbmcgZXhwbGljaXQgdHlwaW5nIGZvciBhcHAgb25seSB2cyB1c2VyIG9ubHkgaXMg
aW50ZXJlc3RpbmchIEZvciB0aGUgcHVycG9zZSBvZiBwdXR0aW5nIHRvZ2V0aGVyIGFuIGludGVy
b3BlcmFibGUgcHJvZmlsZSwgdGhvLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgdGFibGUgaXQgZm9yIHYx
IGluIHRoZSBpbnRlcmVzdCBvZiBnZXR0aW5nIHRvIHNvbWV0aGluZyBlYXN5DQogdG8gYWRvcHQg
KGhlbmNlIHdpdGggc21hbGwgZGVsdGEgdnMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zKSBmYXN0
ZXIuJm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgMTo0MCBBTSBTdGVp
bmFyIE5vZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVpbmFyQHVkZWx0Lm5vIiB0YXJnZXQ9Il9i
bGFuayI+c3RlaW5hckB1ZGVsdC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFZpdHRvcmlv
LCB3ZSZuYnNwOyAodGhlIG5hdGlvbmFsIGZlZGVyYXRpb24tZ2F0ZXdheSBmb3IgdGhlIGhlYWx0
aCBzZXJ2aWNlcyBpbiBub3J3YXkgLSAmcXVvdDtIZWxzZUlEJnF1b3Q7KSZuYnNwOyB0aGluayBo
aXMgaXMgYSByZWFsbHkgdmFsdWFibGUgaW5pdGlhdGl2ZSENCjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFsc28gYWdyZWUgd2l0aCBEb21pbmljayBjb25j
ZXJuaW5nIGRlZmluaXRpb24gb2YgdGhlICZxdW90O3N1YiZxdW90OyBjbGFpbS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O212aCZndDtT
dGVpbmFyJmx0Oy9tdmgmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPnRpci4gMjYuIG1hci4gMjAxOSBrbC4gMDc6MjUgc2tyZXYgRG9taW5p
Y2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0
YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbSBhbiBhY2Nlc3MgdG9rZW4gY29uc3VtZXIg
KGFrYSBBUEkpIGRldmVsb3BlciBwb2ludCBvZiB2aWV3LCBJIHByZWZlciB0aGlzIGxvZ2ljPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtJZiBz
dWIgaXMgcHJlc2VudCAtIGNsaWVudCBhY3RzIG9uIGJlaGFsZiBvZiBhIHVzZXIsIGlmIG5vdCAt
IG5vdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPkFueXRoaW5nIG1vcmUgY29tcGxpY2F0ZWQgaGFzIGEgcG90ZW50aWFsIG9mIGdvaW5nIHdy
b25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2
MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzYWly
bWFpbG9uIj4NCk9uIDI2LiBNYXJjaCAyMDE5IGF0IDAxOjM0OjUzLCBOb3YgTWF0YWtlICg8YSBo
cmVmPSJtYWlsdG86bWF0YWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hdGFrZUBnbWFp
bC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFZpdHRvcmlvLDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCBJ4oCZbSBjb25jZXJu
aW5nIHVzZXIgJmFtcDsgY2xpZW50IGlkcyBjb2xsaXNpb24uPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmVu4oCZdCBzZWVuIHN1Y2ggaW1w
bGVtZW50YXRpb25zLCBidXQgdXNlci1zZWxlY3QgdXNlcm5hbWUgYXMgc3ViLCBvciBpbmNyZW1l
bnRhbCBpbnRlZ2VyIGFzIHN1YiAmYW1wOyBjbGllbnRfaWQgd2lsbCBiZSBlYXNpbHkgY29sbGlk
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SWYgeW91IGNhbiBlbmZvcmNlIGNvbGxpc2lvbiByZXNpc3RhbnQgSURzIGJldHdlZW4gdXNlciAm
YW1wOyBjbGllbnQgaW5zdGFuY2VzLCBpdOKAmWxsIHdvcmtzIGZpbmUuIEkgZmVlbCBpdHMgb3Zl
cmtpbGwgdGhvdWdoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iZ21haWwtbV8t
NzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW1fLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW1fNTE5
ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW1fLTE4NjE0OTI5NzYwOTgyNTM4NDNBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBNYXIgMjYsIDIwMTksIGF0IDg6NTEsIFZpdHRvcmlv
IEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9
Il9ibGFuayI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXkgTm92LCBE
b21pbmljaywgSGFucy0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+dGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoYXQgd2FzIGFuIGFyZWEgSSB3YXMgZXhwZWN0
aW5nIHRvIGNhdXNlIG1vcmUgZGlzY3Vzc2lvbiwgYW5kIEkgYW0gZ2xhZCB3ZSBhcmUgaGF2aW5n
IHRoaXMgb3Bwb3J0dW5pdHkgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBkcmFm
dCB0cmFjZXMgdGhlIGV0eW1vbG9neSBvZiBzdWIgdG8gT3BlbklEIENvbm5lY3QgY29yZSwgaGVu
Y2UgRG9taW5pY2sgb2JzZXJ2YXRpb24gaXMgb24gcG9pbnQuIEhvd2V2ZXIgaW4gdGhlIGRlc2Ny
aXB0aW9uIEkgZXhwcmVzcyBzb21ldGhpbmcgaW4gbGluZSB3aXRoIDc1MTksIHdoaWNoIHdhcyBp
biBmYWN0IG15IGludGVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhlIGlkZWEgd2FzIHRvIHByb3ZpZGUgYW4gaWRlbnRpZmllciBvZiB0
aGUgY2FsbGluZyBzdWJqZWN0IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGluIGFs
bCBjYXNlcy0gdGhpcyB3b3VsZCBhbGxvdyBhbiBTREsgZGV2ZWxvcGVyIHRvIHVzZSB0aGUgc2Ft
ZSBjb2RlIGZvciB0aGluZ3MgbGlrZSBsb29rdXBzIGFuZCBtZW1iZXJzaGlwIGNoZWNrcyByZWdh
cmRsZXNzIG9mIHRoZSBuYXR1cmUgb2YNCiB0aGUgY2FsbGVyICh1c2VyIGluIGEgZGVsZWdhdGVk
IGNhc2UsIGFwcCBpbiBhcHAtb25seSBncmFudHMpLiBUaGUgaW5mb3JtYXRpb24gdG8gZGlzY3Jp
bWluYXRlIGJldHdlZW4gdXNlciBhbmQgYXBwIGNhbGxlcnMgaXMgYWx3YXlzIGF2YWlsYWJsZSBp
biB0aGUgdG9rZW4gKHNheSwgdGhlIGNhbGxlciBpcyBhIHVzZXIgaWYgc3ViIT1jbGllbnRfaWQs
IHdoZXJlIGNsaWVudF9pZCBpcyBhbHdheXMgZ3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGFzDQog
d2VsbCkgaGVuY2UgdGhlcmUncyBubyBsb3NzIGluIGV4cHJlc3NpdmUgcG93ZXIsIHNob3VsZCB0
aGF0IGRpZmZlcmVuY2UgYmUgcmVsZXZhbnQgZm9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNr
LCBIYW5zLSBJIHByb2JhYmx5IG1pc3NlZCB0aGUgc2VjdXJpdHkgaXNzdWUgeW91IGd1eXMgYXJl
IHRoaW5raW5nIG9mIGluIHRoaXMgY2FzZS4gT2YgY291cnNlLCBpZiB0aGlzIHdvdWxkIGludHJv
ZHVjZSBhIHJpc2sgSSBjb21wbGV0ZWx5IGFncmVlIGl0IHNob3VsZCBiZSBjaGFuZ2VkLSBJJ2Qg
anVzdCBsaWtlIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBwcm9ibGVtLiBDb3VsZCB5b3UgZXhw
YW5kDQogaXQgaW4gYSBzY2VuYXJpby91c2UgY2FzZSB0byBjbGFyaWZ5IHRoZSByaXNrPzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm92LSBwbGF5
aW5nIHRoaXMgYmFjazogaXMgdGhlIGNvbmNlcm4gdGhhdCBhIHVzZXIgYW5kIGEgY2xpZW50IG1p
Z2h0IGhhdmUgdGhlIHNhbWUgaWRlbnRpZmllciB3aXRoaW4gYW4gSURQPyBXaGVuIHVzaW5nIGNv
bGxpc2lvbiByZXNpc3RhbnQgSURzLCBhcyBpdCBpcyB1c3VhbGx5IHRoZSBjYXNlLCB0aGF0IHNl
ZW1zIHRvIGJlIGEgcmVtb3RlIHBvc3NpYmlsaXR5LSBkaWQgeW91IHN0dW1ibGUgaW4gc3VjaA0K
IHNjZW5hcmlvIGluIHByb2R1Y3Rpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Vi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNSwgMjAxOSBhdCA3
OjQ0IEFNIEhhbnMgWmFuZGJlbHQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHpt
YXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGVyZSBhcmUgcGxlbnR5IG9m
IE9BdXRoIDIuMCBvbmx5IHVzZSBjYXNlcyBvdXQgdGhlcmUuLi4gYnV0IG5ldmVydGhlbGVzcyBJ
IGFncmVlIHdpdGggdGhlIHBvdGVudGlhbCBjb25mdXNpb24gYW5kIHRodXMgc2VjdXJpdHkgcHJv
YmxlbXMgYXJpc2luZyBmcm9tIHRoYXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRp
Y3MgYXJlIHRoZSBzYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkhhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDM6MzkgUE0gRG9taW5pY2sgQmFpZXIg
Jmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9i
bGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGluIGhpbmRz
aWdodCBpdCB3YXMgYSBtaXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZvciBtdWx0
aXBsZSBzZW1hbnRpY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5BbGwgdGhlIOKAnHRoaXMgaXMgT0lEQyBub3QgT0F1dGjigJ0gYXJndW1lbnRzIGFy
ZSBtYWtpbmcgdGhpbmdzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGV5IG5lZWQgdG8gYmUgLSBp
biBteSBleHBlcmllbmNlIGFsbW9zdCBuby1vbmUgKHRoYXQgSSBrbm93KSBkb2VzIE9JREMgb25s
eSAtIG5vciBPQXV0aA0KIG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUgaXQuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiByZWFsaXR5IHRoaXMgbGVh
ZHMgdG8gcG90ZW50aWFsIHNlY3VyaXR5IHByb2JsZW1zIC0gdGhpcyBzcGVjIGhhcyB0aGUgcG90
ZW50aWFsIHRvIHJlY3RpZnkgdGhlIHNpdHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzA0NTU0NTk0NTg3
MzUzMjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0
MDdnbWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3Nmdt
YWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uIj4NCk9uIDI1LiBNYXJjaCAyMDE5IGF0
IDE0OjU4OjU2LCBIYW5zIFphbmRiZWx0ICg8YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6
bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwv
YT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRob3V0IGFncmVlaW5nIG9yIGRp
c2FncmVlaW5nOiBPSURDIGRvZXMgbm90IGFwcGx5IGhlcmUgc2luY2UgaXQgaXMgbm90IE9BdXRo
IGFuZCBhbiBhY2Nlc3MgdG9rZW4gaXMgbm90IGFuIGlkX3Rva2VuLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEpXVCBzcGVjIHNheXMgaW4g
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEu
MiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkj
c2VjdGlvbi00LjEuMjwvYT46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mcXVvdDtUaGUgJnF1b3Q7c3ViJnF1b3Q7IChzdWJqZWN0KSBjbGFpbSBpZGVudGlm
aWVzIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdWJqZWN0IG9mIHRoZSBKV1Qu
Jm5ic3A7IFRoZSBjbGFpbXMgaW4gYSBKV1QgYXJlIG5vcm1hbGx5IHN0YXRlbWVudHM8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz
cDthYm91dCB0aGUgc3ViamVjdC4mbmJzcDsgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRoZXIg
YmUgc2NvcGVkIHRvIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7bG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2Yg
dGhlIGlzc3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7VGhlIHByb2Nlc3Npbmcg
b2YgdGhpcyBjbGFpbSBpcyBnZW5lcmFsbHkgYXBwbGljYXRpb24gc3BlY2lmaWMmcXVvdDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2gg
a2luZCBvZiBzcGVsbHMgJnF1b3Q7Y2xpZW50JnF1b3Q7IGluIGNhc2Ugb2YgdGhlIGNsaWVudCBj
cmVkZW50aWFscyBncmFudCBidXQgSSBhbHNvIGRvIHdvcnJ5IGFib3V0IFJlc291cmNlIFNlcnZl
cnMgdGhpbmtpbmcvYWN0aW5nIG9ubHkgaW4gdGVybXMgb2YgdXNlcnM8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFucy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDI6NDEgUE0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhy
ZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJh
aWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+SU1ITyB0aGUgc3ViIGNsYWltIHNob3VsZCBhbHdheXMgcmVmZXIgdG8g
dGhlIHVzZXIgLSBhbmQgbm90aGluZyBlbHNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+T0lEQyBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+U3Vi
amVjdCAtIElkZW50aWZpZXIgZm9yIHRoZSBFbmQtVXNlciBhdCB0aGUgSXNzdWVyLiZxdW90Ozwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGllbnRfaWQgc2hvdWxkIGJlIHVzZWQgdG8g
aWRlbnRpZnkgY2xpZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Y2hlZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTcw
NDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2
MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4
NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04NDc1NzI4NjU2MjQ1NDky
NDk1YWlybWFpbG9uIj4NCk9uIDI1Li4gTWFyY2ggMjAxOSBhdCAwNToxMzowMywgTm92IE1hdGFr
ZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXRh
a2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVml0dG9yaW8sIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZ29vZCBzdGFydGluZyBwb2lu
dCBvZiBzdGFuZGFyZGl6aW5nIEpXVC1pemVkIEFULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgZmVlZGJhY2suPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcc3Vi4oCdIGNsYWlt
IGNhbiBpbmNsdWRlIDIgdHlwZXMgb2YgaWRlbnRpZmllciwgZW5kLXVzZXIgYW5kIGNsaWVudCwg
aW4gdGhpcyBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SXQgcmVxdWlyZXMgdGhvc2UgMiB0eXBlcyBvZiBpZGVudGlmaWVycyB0byBiZSB1
bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQIGNvbnRleHQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlZmVyIG9taXR0aW5nIOKAnHN1
YuKAnSBjbGFpbSBpbiAyLWxlZ2dlZCBjb250ZXh0LCBzbyB0aGF0IG5vIHN1Y2ggY29uc3RyYWlu
dCBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPnRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5ub3Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyNSwgMjAxOSwgYXQgODoyOSwgVml0dG9yaW8gQmVy
dG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBk
bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAu
Y29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLCA8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgc3VibWl0dGVkIGEgZHJh
ZnQgZGVzY3JpYmluZyBhIEpXVCBwcm9maWxlIGZvciBPQXV0aCAyLjAgYWNjZXNzIHRva2Vucy4g
WW91IGNhbiBmaW5kIGl0IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8iIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1v
YXV0aC1hY2Nlc3MtdG9rZW4tand0LzwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBzbG90IHRvIGRpc2N1c3MgdGhpcyB0b21v
cnJvdyBhdCBJRVRGIDEwNCAoSSdsbCBiZSBwcmVzZW50aW5nIHJlbW90ZWx5KS4gSSBsb29rIGZv
cndhcmQgZm9yIHlvdXIgY29tbWVudHMhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyBqdXN0IGEgYml0IG9mIGJhY2tzdG9yeSwgaW4g
Y2FzZSB5b3UgYXJlIGludGVyZXN0ZWQgaW4gaG93IHRoaXMgZG9jIGNhbWUgdG8gYmUuIFRoZSB0
cmFqZWN0b3J5IGl0IGZvbGxvd2VkIGlzIHNvbWV3aGF0IHVudXN1YWwuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkRlc3BpdGUgT0F1dGgyIG5vdCByZXF1aXJpbmcg
YW55IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0aHJvdWdoIHRoZSB5ZWFycyBJIGhhdmUgY29t
ZSBhY3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkgc29sdXRpb24gdXNpbmcgSldUIGZvciB0aGVp
ciBhY2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5kIHNjZW5hcmlvcyBhZGRyZXNzZWQgYnkgdGhv
c2Ugc29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNhbWUgYWNyb3NzIHZlbmRvcnMsIGJ1dCB0aGUN
CiBzeW50YXggYW5kIGludGVycHJldGF0aW9ucyBpbiB0aGUgaW1wbGVtZW50YXRpb25zIGFyZSBk
aWZmZXJlbnQgZW5vdWdoIHRvIHByZXZlbnQgZGV2ZWxvcGVycyBmcm9tIHJldXNpbmcgY29kZSBh
bmQgc2tpbGxzIHdoZW4gbW92aW5nIGZyb20gcHJvZHVjdCB0byBwcm9kdWN0LjxvOnA+PC9vOnA+
PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkkg
YXNrZWQgc2V2ZXJhbCBpbmRpdmlkdWFscyBmcm9tIGtleSBwcm9kdWN0cyBhbmQgc2VydmljZXMg
dG8gc2hhcmUgd2l0aCBtZSBjb25jcmV0ZSBleGFtcGxlcyBvZiB0aGVpciBKV1QgYWNjZXNzIHRv
a2VucyAoVEhBTksgWU9VIERvbWluaWNrIEJhaWVyIChJZGVudGl0eVNlcnZlciksJm5ic3A7PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJyaWFuIENhbXBiZWxsIChQaW5nSWRlbnRpdHkp
LCBEYW5pZWwgRG9iYWxpYW4gKE1pY3Jvc29mdCksIEthcmwNCiBHdWlubmVzcyAoT2t0YSkgZm9y
IHRoZSB0b2tlbnMgYW5kIGV4cGxhbmF0aW9ucyE8L3NwYW4+KS48YnI+DQpJIHN0dWRpZWQgYW5k
IGNvbXBhcmVkIGFsbCB0aG9zZSBpbnN0YW5jZXMsIGlkZW50aWZ5aW5nIGNvbW1vbmFsaXRpZXMg
YW5kIGRpZmZlcmVuY2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkkgcHV0IHRvZ2V0aGVyIGEgcHJlc2VudGF0
aW9uIHN1bW1hcml6aW5nIG15IGZpbmRpbmdzIGFuZCBzdWdnZXN0aW5nIGEgcm91Z2ggaW50ZXJv
cGVyYWJsZSBwcm9maWxlIChzbGlkZXM6DQo8YSBocmVmPSJodHRwczovL3NlYy4udW5pLXN0dXR0
Z2FydC5kZS9fbWVkaWEvZXZlbnRzL29zdzIwMTkvc2xpZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJv
ZmlsZV9mb3JfYXRzLnBwdHgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vc2VjLnVuaS1zdHV0
dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9vc3cyMDE5L3NsaWRlcy9iZXJ0b2NjaV8tX2Ffand0X3By
b2ZpbGVfZm9yX2F0cy5wcHR4PC9hPiApIC0gZ290IGVhcmx5IGZlZWRiYWNrIGZyb20gRmlsaXAg
U2tva2FuIG9uIGl0LiBUaHggRmlsaXAhPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIHByZXNlbnRhdGlvbiB3YXMgZm9s
bG93ZWQgdXAgYnkgMS41IGhvdXJzIG9mIHVuY29uZmVyZW5jZSBkaXNjdXNzaW9uLCB3aGljaCB3
YXMgaW5jcmVkaWJseSB2YWx1YWJsZSB0byBnZXQgdGlnaHQtbG9vcCBmZWVkYmFjayBhbmQgaW5j
b3Jwb3JhdGUgbmV3IGlkZWFzLiBKb2huIEJyYWRsZXksIEJyaWFuIENhbXBiZWxsIFZsYWRpbWly
IER6aHV2aW5vdiwgVG9yc3RlbiBMb2RkZXJzdGVkdCw8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+Jm5ic3A7TmF0DQogU2FraW11cmEsIEhhbm5lcyBUc2Nob2ZlbmlnPC9zcGFuPiZuYnNw
O3dlcmUgYWxsIHRoZXJlIGFuZCBjb250cmlidXRlZCBnZW5lcm91c2x5IHRvIHRoZSBkaXNjdXNz
aW9uLiBUaGFuayB5b3UhISE8YnI+DQpOb3RlOiBpZiB5b3Ugd2VyZSBhdCBPU1cyMDE5LCBwYXJ0
aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb24gYW5kIGRpZG4ndCBnZXQgY3JlZGl0ZWQgaW4gdGhl
IGRyYWZ0LCBteSBhcG9sb2dpZXM6IHBsZWFzZSBzZW5kIG1lIGEgbm90ZSBhbmQgSSdsbCBtYWtl
IHRoaW5ncyByaWdodCBhdCB0aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L2xpPjxsaSBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KT24gbXkgZmxpZ2h0IGJh
Y2sgSSBkaWQgbXkgYmVzdCB0byBpbmNvcnBvcmF0ZSBhbGwgdGhlIGlkZWFzIGFuZCBmZWVkYmFj
ayBpbiBhIGRyYWZ0LCB3aGljaCB3aWxsIGJlIGRpc2N1c3NlZCBhdCBJRVRGMTA0IHRvbW9ycm93
LiBSaWZhYXQsIEhhbm5lcyBhbmQgYWJvdmUgYWxsIEJyaWFuIHdlcmUgYWxsIHN1cGVyIGhlbHBm
dWwgaW4gbmVnb3RpYXRpbmcgdGhlIG15c3RlcmlvdXMgc3ludGF4IG9mIHRoZSBSRkMgZm9ybWF0
IGFuZCBzdWJtaXNzaW9uDQogcHJvY2Vzcy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBibG93biBhd2F5IGJ5IHRoZSBhdmFpbGFiaWxpdHks
IGludm9sdmVtZW50IGFuZCB3aWxsaW5nbmVzcyB0byBpbnZlc3QgdGltZSB0byBnZXQgdGhpbmdz
IHJpZ2h0IHRoYXQgZXZlcnlvbmUgZGVtb25zdHJhdGVkIGluIHRoZSBwcm9jZXNzLiBUaGlzIGlz
IGFuIGFtYXppbmcgY29tbXVuaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg
bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6
b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLSA8YSBocmVmPSJo
dHRwOi8vd3d3LnptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPg0Kd3d3LnptYXJ0em9uZS5l
dTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEg
aHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+
aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPlptYXJ0Wm9uZSBJQU0gLSA8YSBocmVmPSJodHRwOi8vd3d3LnptYXJ0em9uZS5ldSIg
dGFyZ2V0PSJfYmxhbmsiPg0Kd3d3LnptYXJ0em9uZS5ldTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5WZW5u
bGlnIGhpbHNlbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiM1MDAwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIy
MjIyMiI+U3RlaW5hciBOb2VtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPlBhcnRuZXIg
VWRlbHQgQVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+U3lzdGVtdXR2aWtsZXI8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMy
MjIyMjIiPnwmbmJzcDs8YSBocmVmPSJtYWlsdG86c3RlaW5hckB1ZGVsdC4ubm8iIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNGRkZGQ0MiPnN0
ZWluYXJAdWRlbHQubm88L3NwYW4+PC9hPiZuYnNwO3wmbmJzcDs8YSBocmVmPSJtYWlsdG86aGVp
QHVkZWx0Lm5vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPmhl
aUB1ZGVsdC5ubzwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7fCZuYnNwOyYjNDM7NDcNCiA5NTUgMjEg
NjIwJm5ic3A7fCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cudWRlbHQubm8vIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPnd3dy51ZGVsdC5ubzwvc3Bhbj48L2E+
Jm5ic3A7fCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxh
bmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij5abWFydFpvbmUgSUFNIC0gPGEgaHJlZj0iaHR0cDovL3d3dy56bWFydHpvbmUu
ZXUiIHRhcmdldD0iX2JsYW5rIj4NCnd3dy56bWFydHpvbmUuZXU8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxh
bmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij5abWFydFpvbmUgSUFNIC0gPGEgaHJlZj0iaHR0cDovL3d3dy56bWFydHpvbmUu
ZXUiIHRhcmdldD0iX2JsYW5rIj4NCnd3dy56bWFydHpvbmUuZXU8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN6PR00MB0304BC3C7D438F8A5715B36DF5500SN6PR00MB0304namp_--


From nobody Thu Apr  4 12:59:13 2019
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 A5D441201D4 for ; Thu,  4 Apr 2019 12:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=zmartzone-eu.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 f0WxrRBV3zFZ for ; Thu,  4 Apr 2019 12:59:05 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 902761201B3 for ; Thu,  4 Apr 2019 12:59:05 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id w5so4742621qtb.11 for ; Thu, 04 Apr 2019 12:59:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c2yXs5/kVHrc2NXzGT5CliD0jv4FSD5X8u4eQMWL/oI=; b=zIhh2rD7yTfvDUwCecSZ/UDyz9O/eXksRStwp7E2SKiFa0LrPshCYYb2DUNsuUxUW9 wopctbm4VLwTkNcb/UIMZp9Q5p16nh5qRVoStmS0Ns82x/PNeqzpZ9trTqBcANAZxLoE 8BgqQhHNK9Ofaw1HS3+bGSmf2sAyQ+6cF988550O+kJCmTHgzU4neEGUgmz7z4FnzW3d YTSJ6HtdXq/yNq17aoGlezmT98SrazX/3jbBCgHbLox7Y2cfiviR8QGrHyAP1SrO7i5n /WmksMq0DJFcfuWZLcEDYbPb8F7U8EUTtIX77jCnepRhl07mr9IaJQtrW8zqkFbzC5/Y Qa8A==
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=c2yXs5/kVHrc2NXzGT5CliD0jv4FSD5X8u4eQMWL/oI=; b=MTAcpyQTyaBfAfmlv/xh48YylADo2g49pLx72Irwe39Jn/9dlbNClsrOGbmVU3/zgp G7YCz7jv732e708ixcozsJGrG/9BRRdDRaD+heOxUN6Vg28Pg/j06Fng0T04Uhv1Ljo6 bG7B9qCJ/aD+UwVci90nhoJFnllTX4iWMnSFNUhdFg+ymcKi9P8YocDlGRsn1D8c5cek HYWN9wkzeR/Vf3t+TP8CLmDXyLOwHG7Mc3FZFhVOnvDQoXF2gddMOYcWnU3IMP/MYK5/ KsYLo9duVOWbX3rG1yRa/rJxpKAzHVc016LTARhZ6T7DWW3fl/4KtbxEm6VAJWe1aiH3 G+rw==
X-Gm-Message-State: APjAAAVowOQXkA4cQivBnHgloYR1pmk4mJMYxGf2JffSBsqp9repMmiX ol8V9sGOuoXo8z4WCNw/ANGMbE0C2XveShlIXOedcA==
X-Google-Smtp-Source: APXvYqynXpNUx+yP/af4dTer7dXRhdmOct9Owkavdznb+zAE+WLz2YCCo01Qwda+FxTiJYvKfQjCeWn/WobtvoascyI=
X-Received: by 2002:aed:3766:: with SMTP id i93mr7125520qtb.227.1554407944419;  Thu, 04 Apr 2019 12:59:04 -0700 (PDT)
MIME-Version: 1.0
References:               <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> 
In-Reply-To: 
From: Hans Zandbelt 
Date: Thu, 4 Apr 2019 21:58:51 +0200
Message-ID: 
To: Mike Jones 
Cc: George Fletcher ,  Vittorio Bertocci , IETF oauth WG 
Content-Type: multipart/alternative; boundary="0000000000005d14fc0585b9cdd2"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 04 Apr 2019 19:59:11 -0000

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

the definition of RFC 7519 is actually "petitio principii" and a lot of
deployments put claims about the Resource Owner in the access token (as a
Resource Server implementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
wrote:

> I agree with George that the subject of a token must be the principal of
> that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for.  Indee=
d, the first
> sentence of the =E2=80=9Csub=E2=80=9D definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>
> The "sub" (subject) claim identifies the principal that is the subject of
> the JWT.
>
>
>
> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with=
 the definition
> from RFC 7519.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt 
> *Cc:* Vittorio Bertocci ; IETF oau=
th
> WG 
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> The more I think about this the more I land in the "No" camp.
>
> The subject of a token should be the principal of that token. It shouldn'=
t
> matter whether that is a machine, a user, or a device. Trying to separate
> out "humans" as a special class will just make things more complicated. I=
f
> we need a claim to identify the subject is a "human" then why not just ad=
d
> that. This doesn't break anything and makes it easy for people to detect
> this case in those use cases where it's required.
>
> Thanks,
> George
>
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>
> I will argue that in a way such deployments are already broken e.g. in th=
e
> typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for
> that.
>
>
>
> Hans.
>
>
>
> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>
> I agree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
> do like the rigidness of it all: it is very explicit, cannot misinterpret=
ed
> and thus prevents failure (which is really what Dominick is after); I'm o=
n
> board
>
>
>
> Hans.
>
>
>
> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0.com@dmarc.ietf.org> wrote:
>
> thank you Steinar and everyone else for the comments on this!
>
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have th=
e
> sub for app only flows as well. Hans is neutral.
>
> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more tim=
e
> to comment as well.
>
> Clarification. If the goal is to be able to apply the logic "if there's a
> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
> of sub when that's not the case. Are all OK with it?
>
>
>
> Dave, the suggestion of having explicit typing for app only vs user only
> is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getti=
ng
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
>
>
>
> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>
> Hi Vittorio, we  (the national federation-gateway for the health services
> in norway - "HelseID")  think his is a really valuable initiative!
>
> We also agree with Dominick concerning definition of the "sub" claim.
>
>
>
> Steinar
>
>
>
> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dbaier@leastprivilege.com>:
>
> From an access token consumer (aka API) developer point of view, I prefer
> this logic
>
>
>
> "If sub is present - client acts on behalf of a user, if not - not."
>
>
>
> Anything more complicated has a potential of going wrong.
>
>
>
> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:
>
> Hi Vittorio,
>
>
>
> Yeah, I=E2=80=99m concerning user & client ids collision.
>
> I haven=E2=80=99t seen such implementations, but user-select username as =
sub, or
> incremental integer as sub & client_id will be easily collide.
>
>
>
> If you can enforce collision resistant IDs between user & client
> instances, it=E2=80=99ll works fine. I feel its overkill though.
>
>
>
> Sent from my iPhone
>
>
> On Mar 26, 2019, at 8:51, Vittorio Bertocci  wrote:
>
> Hey Nov, Dominick, Hans-
>
> thanks for the comments. That was an area I was expecting to cause more
> discussion, and I am glad we are having this opportunity to clarify.
>
> The current language in the draft traces the etymology of sub to OpenID
> Connect core, hence Dominick observation is on point. However in the
> description I express something in line with 7519, which was in fact my
> intent.
>
>
>
> The idea was to provide an identifier of the calling subject that is
> guaranteed to be present in all cases- this would allow an SDK developer =
to
> use the same code for things like lookups and membership checks regardles=
s
> of the nature of the caller (user in a delegated case, app in app-only
> grants). The information to discriminate between user and app callers is
> always available in the token (say, the caller is a user if sub!=3Dclient=
_id,
> where client_id is always guaranteed to be present as well) hence there's
> no loss in expressive power, should that difference be relevant for the
> resource server.
>
>
>
> Dominick, Hans- I probably missed the security issue you guys are thinkin=
g
> of in this case. Of course, if this would introduce a risk I completely
> agree it should be changed- I'd just like to understand better the proble=
m.
> Could you expand it in a scenario/use case to clarify the risk?
>
> Nov- playing this back: is the concern that a user and a client might hav=
e
> the same identifier within an IDP? When using collision resistant IDs, as
> it is usually the case, that seems to be a remote possibility- did you
> stumble in such scenario in production?
>
>
>
> Thanks
>
> V.
>
>
>
>
>
> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt 
> wrote:
>
> I believe there are plenty of OAuth 2.0 only use cases out there... but
> nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
>
>
>
> Hans.
>
>
>
> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier 
> wrote:
>
> Yes I know - and I think in hindsight it was a mistake to use the same
> claim type for multiple semantics.
>
>
>
> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making thi=
ngs more
> complicated than they need to be - in my experience almost no-one (that I
> know) does OIDC only - nor OAuth only. They always combine it.
>
>
>
> In reality this leads to potential security problems - this spec has the
> potential to rectify the situation.
>
>
>
> Dominick
>
> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu)
> wrote:
>
> Without agreeing or disagreeing: OIDC does not apply here since it is not
> OAuth and an access token is not an id_token.
>
> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>
>
>
> "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"
>
>
>
> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
>
>
> Hans.
>
>
>
> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier 
> wrote:
>
> IMHO the sub claim should always refer to the user - and nothing else.
>
>
>
> OIDC says:
>
>
>
> "Subject - Identifier for the End-User at the Issuer."
>
>
>
> client_id should be used to identify clients.
>
>
>
> cheers
>
> Dominick
>
>
>
> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:
>
> Hi Vittorio,
>
>
>
> Thanks for the good starting point of standardizing JWT-ized AT.
>
>
>
> One feedback.
>
> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-us=
er and client, in
> this spec.
>
> It requires those 2 types of identifiers to be unique each other in the
> IdP context.
>
>
>
> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so tha=
t no such
> constraint needed.
>
>
>
> thanks
>
>
>
> nov
>
>
>
> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
>
>
>
> Dear all,
>
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
>
>
> Here's just a bit of backstory, in case you are interested in how this do=
c
> came to be. The trajectory it followed is somewhat unusual.
>
>    - Despite OAuth2 not requiring any specific format for ATs, through
>    the years I have come across multiple proprietary solution using JWT f=
or
>    their access token. The intent and scenarios addressed by those soluti=
ons
>    are mostly the same across vendors, but the syntax and interpretations=
 in
>    the implementations are different enough to prevent developers from re=
using
>    code and skills when moving from product to product.
>    - I asked several individuals from key products and services to share
>    with me concrete examples of their JWT access tokens (THANK YOU Domini=
ck
>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>    (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>    I studied and compared all those instances, identifying commonalities
>    and differences.
>    - I put together a presentation summarizing my findings and suggesting
>    a rough interoperable profile (slides:
>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a=
_jwt_profile_for_ats.pptx
>    
>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>    - The presentation was followed up by 1.5 hours of unconference
>    discussion, which was incredibly valuable to get tight-loop feedback a=
nd
>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov=
,
>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>    and contributed generously to the discussion. Thank you!!!
>    Note: if you were at OSW2019, participated in the discussion and
>    didn't get credited in the draft, my apologies: please send me a note =
and
>    I'll make things right at the next update.
>    - On my flight back I did my best to incorporate all the ideas and
>    feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa=
at,
>    Hannes and above all Brian were all super helpful in negotiating the
>    mysterious syntax of the RFC format and submission process.
>
> I was blown away by the availability, involvement and willingness to
> invest time to get things right that everyone demonstrated in the process=
.
> This is an amazing community.
>
> V.
>
> _______________________________________________
> 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
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> Vennlig hilsen
>
>
>
> Steinar Noem
>
> Partner Udelt AS
>
> Systemutvikler
>
>
>
> | steinar@udelt.no  | hei@udelt.no  | +47 955 21 620 |
> www.udelt.no |
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>


--=20
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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


the definition of RFC 75=
19 is actually "petitio principii" and a lot of deployments put c=
laims about the Resource Owner in the access token (as a Resource Server im=
plementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@microsoft.com> wro=
te:











I agree with Geor=
ge that the subject of a token must be the principal of that token.=C2=A0 T=
hat what the JWT =E2=80=9Csub=E2=80=9D claim is for.=C2=A0 Indeed, the firs=
t sentence of the =E2=80=9Csub=E2=80=9D definition at
https://tools.ietf.org/html/rfc7519#section-4.1.2 is:


The "sub" (subject) claim identifie=
s the principal that is the subject of the JWT.


=C2=A0<=
/u>


If an access toke=
n uses =E2=80=9Csub=E2=80=9D, its usage must comply with the definition fro=
m RFC 7519.


=C2=A0<=
/u>


=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
/u>


=C2=A0<=
/u>






From:=
 OAuth <oauth-bounces@ietf.org>
On Behalf Of George Fletcher

Sent: Thursday, April 4, 2019 8:51 AM

To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>

Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF o=
auth WG <oauth@ietf.=
org>

Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<=
/u>






=C2=A0


The more I think about this the more I land in th=
e "No" camp.



The subject of a token should be the principal of that token. It shouldn=
9;t matter whether that is a machine, a user, or a device. Trying to separa=
te out "humans" as a special class will just make things more com=
plicated. If we need a claim to identify the subject
 is a "human" then why not just add that. This doesn't break =
anything and makes it easy for people to detect this case in those use case=
s where it's required.



Thanks,

George




On 4/3/19 4:56 PM, Hans Zandbelt wrote:








I will argue that in a way such deployments are alre=
ady broken e.g. in the typical use case of onboarding client accounts in th=
e same directory/OU/namespace as user accounts and we don't need to cat=
er for that.





=C2=A0






Hans.






=C2=A0






On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <=
gffletch@aol.com&=
gt; wrote:








I agree that this will break a lot of existing fl=
ows... especially those using any form of the client_credentials flow. In t=
hat sense I'm not completely on board
 yet :)




On 3/26/19 12:56 PM, Hans Zandbelt wrote:<=
/u>










great summary! this will hurt quite a few existing m=
2m deployments but I do like the rigidness of it all: it is very explicit, =
cannot misinterpreted and thus prevents failure (which is really what Domin=
ick is after); I'm on board





=C2=A0






Hans.






=C2=A0






On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci &l=
t;Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:








thank you Steinar and everyone else for the comments=
 on this!





To summarize the situation so far: Dominick, Steinar=
, Rob, David, Nov, Bertrand recommend using sub only for users. Martin woul=
d like to have the sub for app only flows as well. Hans is neutral.<=
u>






That does sound like the sub as user has more consen=
sus, tho before changing it I'd wait for the people currently at IETF10=
4 to have more time to comment as well.






Clarification. If the goal is to be able to apply th=
e logic "if there's a sub, it's a user flow", we have to =
explicitly disallow (MUST NOT) the use of sub when that's not the case.=
 Are all OK with it?






=C2=A0






Dave, the suggestion of having explicit typing for a=
pp only vs user only is interesting! For the purpose of putting together an=
 interoperable profile, tho, I would suggest we table it for v1 in the inte=
rest of getting to something easy
 to adopt (hence with small delta vs existing implementations) faster.=C2=
=A0 =C2=A0 =C2=A0






=C2=A0






On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no>=
 wrote:








Hi Vittorio, we=C2=A0 (the national federation-gatew=
ay for the health services in norway - "HelseID")=C2=A0 think his=
 is a really valuable initiative!





We also agree with Dominick concerning definition of=
 the "sub" claim.






=C2=A0






<mvh>Steinar</mvh>






=C2=A0






tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier &l=
t;dbaier@lea=
stprivilege.com>:










From an access token consumer (aka API) developer point of view=
, I prefer this logic






=C2=A0






"If sub is present - client acts on behalf of a user, if n=
ot - not."






=C2=A0






Anything more complicated has a potential of going wrong.




=C2=A0


On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:












Hi Vittorio,






=C2=A0






Yeah, I=E2=80=99m concerning user & client ids c=
ollision.






I haven=E2=80=99t seen such implementations, but use=
r-select username as sub, or incremental integer as sub & client_id wil=
l be easily collide.






=C2=A0






If you can enforce collision resistant IDs between u=
ser & client instances, it=E2=80=99ll works fine. I feel its overkill t=
hough.








=C2=A0




Sent from my iPhone








On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:










Hey Nov, Dominick, Hans- 




thanks for the comments. That was an area I was expe=
cting to cause more discussion, and I am glad we are having this opportunit=
y to clarify.






The current language in the draft traces the etymolo=
gy of sub to OpenID Connect core, hence Dominick observation is on point. H=
owever in the description I express something in line with 7519, which was =
in fact my intent.






=C2=A0






The idea was to provide an identifier of the calling=
 subject that is guaranteed to be present in all cases- this would allow an=
 SDK developer to use the same code for things like lookups and membership =
checks regardless of the nature of
 the caller (user in a delegated case, app in app-only grants). The informa=
tion to discriminate between user and app callers is always available in th=
e token (say, the caller is a user if sub!=3Dclient_id, where client_id is =
always guaranteed to be present as
 well) hence there's no loss in expressive power, should that differenc=
e be relevant for the resource server.






=C2=A0






Dominick, Hans- I probably missed the security issue=
 you guys are thinking of in this case. Of course, if this would introduce =
a risk I completely agree it should be changed- I'd just like to unders=
tand better the problem. Could you expand
 it in a scenario/use case to clarify the risk?






Nov- playing this back: is the concern that a user a=
nd a client might have the same identifier within an IDP? When using collis=
ion resistant IDs, as it is usually the case, that seems to be a remote pos=
sibility- did you stumble in such
 scenario in production?






=C2=A0






Thanks






V.=C2=A0






=C2=A0






=C2=A0






On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt=
@zmartzone.eu> wrote:










I believe there are plenty of OAuth 2.0 only use cas=
es out there... but nevertheless I agree with the potential confusion and t=
hus security problems arising from that (though one may argue the semantics=
 are the same).






=C2=A0




Hans.






=C2=A0






On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <<=
a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp=
rivilege.com> wrote:










Yes I know - and I think in hindsight it was a mistake to use t=
he same claim type for multiple semantics.






=C2=A0






All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience almo=
st no-one (that I know) does OIDC only - nor OAuth
 only. They always combine it.






=C2=A0






In reality this leads to potential security problems - this spe=
c has the potential to rectify the situation.






=C2=A0




Dominick<=
/p>


On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:
















Without agreeing or disagreeing: OIDC does not apply=
 here since it is not OAuth and an access token is not an id_token.<=
u>







=C2=A0




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






=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in=
 a JWT are normally statements






=C2=A0 =C2=A0about the subject.=C2=A0 The subject va=
lue MUST either be scoped to be






=C2=A0 =C2=A0locally unique in the context of the is=
suer or be globally unique.






=C2=A0 =C2=A0The processing of this claim is general=
ly application specific"






=C2=A0






which kind of spells "client" in case of t=
he client credentials grant but I also do worry about Resource Servers thin=
king/acting only in terms of users






=C2=A0






Hans.










=C2=A0






On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <<=
a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp=
rivilege.com> wrote:










IMHO the sub claim should always refer to the user - and nothin=
g else.






=C2=A0






OIDC says:






=C2=A0






"Subject - Identifier for the End-User at the Issuer."






=C2=A0






client_id should be used to identify clients.=







=C2=A0






cheers






Dominick




=C2=A0



On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:








Hi Vittorio, 




=C2=A0






Thanks for the good starting point of standardizing =
JWT-ized AT.






=C2=A0






One feedback.






The =E2=80=9Csub=E2=80=9D claim can include 2 types =
of identifier, end-user and client, in this spec.






It requires those 2 types of identifiers to be uniqu=
e each other in the IdP context.






=C2=A0






I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-l=
egged context, so that no such constraint needed.






=C2=A0






thanks






=C2=A0






nov



















On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:




=C2=A0










Dear all, 




I just submitted a draft describing a JWT profile fo=
r OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/<=
/a>.






I have a slot to discuss this tomorrow at IETF 104 (=
I'll be presenting remotely). I look forward for your comments!<=
u>






=C2=A0






Here's just a bit of backstory, in case you are =
interested in how this doc came to be. The trajectory it followed is somewh=
at unusual.









I was blown away by the availability, involvement an=
d willingness to invest time to get things right that everyone demonstrated=
 in the process. This is an amazing community.=C2=A0








V.










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth








=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













=C2=A0




--
























=C2=A0




--



























_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













=C2=A0




-- 












Vennlig hilsen






=C2=A0<=
/u>








Steinar Noem<=
/u>






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=A0=
www.udelt.no=C2=A0|=C2=A0


















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













=C2=A0




-- 












_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0















=C2=A0




-- 





=C2=A0









-- 


--0000000000005d14fc0585b9cdd2--


From nobody Thu Apr  4 13:10:05 2019
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 AA0791200B2 for ; Thu,  4 Apr 2019 13:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wjC-EzTj8tZc for ; Thu,  4 Apr 2019 13:09:57 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650105.outbound.protection.outlook.com [40.107.65.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D478120479 for ; Thu,  4 Apr 2019 13:09:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=atmqaBey4j/X22KItg1ZPLT6M2Fl6DD1HEUDd6QK1IIStVAuGy1zn4xmFaYYuJ+WL7uR8tBP15FlYiL/OWThZ2pdOyS3k1KbLliBC/+TwdGVRZRsU3hTM4s7v3Ysqnp+NRPddyQ0qZtNVRxOB58dI0Fi/Le72U4/ZAY1aMRWOqU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h6gnyAmkQdlAhmu+xlo/LS9a33qqi9nTbekl6c3wed0=; b=SsGm5fmCouHP8hOrFEkVH6Ml7k58oiqVWmhvcdx6KDHlJQBHXEg2aAGvpX8YKcYqF0/5kSiOXWBjHlITLLk/GoavDaYqK3nahPjk2wNf2NUO3kkszU4VBB6Cl1HqPmbz2lxqGI5q+5HcKBSayeAoGVPxxTS4e8zDsXO09IdzgEA=
ARC-Authentication-Results: i=1; test.office365.com 1;dmarc=none action=none header.from=microsoft.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h6gnyAmkQdlAhmu+xlo/LS9a33qqi9nTbekl6c3wed0=; b=cfUGvwQCvLS2l131IFeiNGPiDIa2Ei843DQGLQJ+jItmecg15LLx6vFu8sBm5Y3C+bOOIOJvxdqHpEZnop1d/JtcaQ/L6aAPj9bjwawndXl+HGVB6sGuPIlOhKijXMxsPG6z/lF8n/e4xEIuaVX4XmSsUhyViB0GVp1VAGMip38=
Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0397.namprd00.prod.outlook.com (52.132.118.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1814.0; Thu, 4 Apr 2019 20:09:44 +0000
Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::d017:ba79:6e59:70b]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::d017:ba79:6e59:70b%3]) with mapi id 15.20.1813.000; Thu, 4 Apr 2019 20:09:44 +0000
From: Mike Jones 
To: Hans Zandbelt 
CC: George Fletcher , Vittorio Bertocci , IETF oauth WG 
Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Thread-Index: AQHU4plzn+J3IOowe0OXYYpdxUABdqYbvMyAgACe2ICAAAThAIAAC2CAgAABTACAAJjzgIAADBmAgABhiACAACYMAIAAiF0AgAACU4CADNOJgIAAAkaAgAE81oCAAEGb8IAAA7GAgAACx/A=
Date: Thu, 4 Apr 2019 20:09:44 +0000
Message-ID: 
References:               <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>  
In-Reply-To: 
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=66147420-4804-45e0-b963-000028644240; 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=2019-04-04T20:08:47-0800; 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: [2001:4898:80e8:9:b06a:53dc:1605:18d6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 87bb639f-aa16-473e-6774-08d6b9397ad9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR00MB0397; 
x-ms-traffictypediagnostic: SN6PR00MB0397:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(366004)(396003)(376002)(51914003)(199004)(189003)(102836004)(6506007)(53546011)(186003)(478600001)(53946003)(53936002)(6916009)(33656002)(5070765005)(46003)(30864003)(76176011)(790700001)(6116002)(7696005)(10090500001)(53386004)(236005)(10290500003)(55016002)(25786009)(105586002)(106356001)(4326008)(93886005)(6246003)(9686003)(6306002)(54896002)(256004)(229853002)(517774005)(86362001)(8990500004)(6436002)(97736004)(52536014)(606006)(86612001)(966005)(14444005)(81156014)(8676002)(81166006)(14454004)(72206003)(8936002)(71200400001)(71190400001)(2906002)(7736002)(316002)(54906003)(22452003)(486006)(74316002)(446003)(11346002)(476003)(5660300002)(99286004)(68736007)(440504004)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0397; H:SN6PR00MB0304.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yYnKeqfO7tEvlx6SZHE5sneUrVI7arwEBiP8OBOnpeIC/4A81PniqMslTKwfGIyrSUamUn01USteRPXGNUO52ETHDLn0flwjuxGuiRwkB6mW6IoW9Q3HpcdwKqFuhc4z5rN4K01kVIGaU47JLX0/gaqJTB0fEwnctKPmxeiG0guAaVe/0ZOAAATRNwAQRMvBLjHwR59NX7pDvQtWJPwjiAVoy30gdsuXbHeikc2rngtxMOfMxoFwB+KwUwMI5XNbeO4cF0jYGeb3RG1WB1xwEblnlR8IrFjXi++sAwl3AfvqGPNRwGXgIU9TNZAB3RCzkJ6ykbv4ECzkstkCb6GcoHSj6B4++uQfpC2rSAaPe6IPNwEnkHwKxs5QBu42KY1MX2BFtsHqFM+NlHexDnatTQt8vi2qqaT40AbiqaEb2Xc=
Content-Type: multipart/alternative; boundary="_000_SN6PR00MB030459810B40D98370728BBAF5500SN6PR00MB0304namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 87bb639f-aa16-473e-6774-08d6b9397ad9
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 20:09:44.3217 (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-Transport-CrossTenantHeadersStamped: SN6PR00MB0397
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 04 Apr 2019 20:10:03 -0000

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

SSBnZXQgdGhhdCBleGlzdGluZyBwcmFjdGljZSBpcyBsaWtlbHkgdG8gYmUgYWxsIG92ZXIgdGhl
IG1hcCwgYnV0IGlmIHdl4oCZcmUgdG8gY3JlYXRlIGEgSldUIGFjY2VzcyB0b2tlbiBzdGFuZGFy
ZCwgaXTigJlzIHJlYXNvbmFibGUgdG8gcmVxdWlyZSB0aGF0IHRoZSBjbGFpbXMgdXNhZ2UgY29t
cGx5IHdpdGggdGhlIEpXVCBzdGFuZGFyZHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEhh
bnMgWmFuZGJlbHQgPGhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KU2VudDogVGh1cnNkYXks
IEFwcmlsIDQsIDIwMTkgMTI6NTkgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20+DQpDYzogR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1h
cmMuaWV0Zi5vcmc+OyBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89NDBhdXRoMC5jb21AZG1h
cmMuaWV0Zi5vcmc+OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl
OiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDANCg0K
dGhlIGRlZmluaXRpb24gb2YgUkZDIDc1MTkgaXMgYWN0dWFsbHkgInBldGl0aW8gcHJpbmNpcGlp
IiBhbmQgYSBsb3Qgb2YgZGVwbG95bWVudHMgcHV0IGNsYWltcyBhYm91dCB0aGUgUmVzb3VyY2Ug
T3duZXIgaW4gdGhlIGFjY2VzcyB0b2tlbiAoYXMgYSBSZXNvdXJjZSBTZXJ2ZXIgaW1wbGVtZW50
ZXIgSSd2ZSBzdWZmZXJlZCBhIGxvdCBmcm9tIHRoaXMpDQoNCkhhbnMuDQoNCk9uIFRodSwgQXBy
IDQsIDIwMTkgYXQgOTo0OCBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSB3
aXRoIEdlb3JnZSB0aGF0IHRoZSBzdWJqZWN0IG9mIGEgdG9rZW4gbXVzdCBiZSB0aGUgcHJpbmNp
cGFsIG9mIHRoYXQgdG9rZW4uICBUaGF0IHdoYXQgdGhlIEpXVCDigJxzdWLigJ0gY2xhaW0gaXMg
Zm9yLiAgSW5kZWVkLCB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIOKAnHN1YuKAnSBkZWZpbml0
aW9uIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNC4xLjIg
aXM6DQpUaGUgInN1YiIgKHN1YmplY3QpIGNsYWltIGlkZW50aWZpZXMgdGhlIHByaW5jaXBhbCB0
aGF0IGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBKV1QuDQoNCklmIGFuIGFjY2VzcyB0b2tlbiB1c2Vz
IOKAnHN1YuKAnSwgaXRzIHVzYWdlIG11c3QgY29tcGx5IHdpdGggdGhlIGRlZmluaXRpb24gZnJv
bSBSRkMgNzUxOS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2Yg
R2VvcmdlIEZsZXRjaGVyDQpTZW50OiBUaHVyc2RheSwgQXByaWwgNCwgMjAxOSA4OjUxIEFNDQpU
bzogSGFucyBaYW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMu
emFuZGJlbHRAem1hcnR6b25lLmV1Pj4NCkNjOiBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW89
NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYu
b3JnPj47IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3Mt
dG9rZW4tand0LTAwDQoNClRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgdGhpcyB0aGUgbW9yZSBJIGxh
bmQgaW4gdGhlICJObyIgY2FtcC4NCg0KVGhlIHN1YmplY3Qgb2YgYSB0b2tlbiBzaG91bGQgYmUg
dGhlIHByaW5jaXBhbCBvZiB0aGF0IHRva2VuLiBJdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIg
dGhhdCBpcyBhIG1hY2hpbmUsIGEgdXNlciwgb3IgYSBkZXZpY2UuIFRyeWluZyB0byBzZXBhcmF0
ZSBvdXQgImh1bWFucyIgYXMgYSBzcGVjaWFsIGNsYXNzIHdpbGwganVzdCBtYWtlIHRoaW5ncyBt
b3JlIGNvbXBsaWNhdGVkLiBJZiB3ZSBuZWVkIGEgY2xhaW0gdG8gaWRlbnRpZnkgdGhlIHN1Ympl
Y3QgaXMgYSAiaHVtYW4iIHRoZW4gd2h5IG5vdCBqdXN0IGFkZCB0aGF0LiBUaGlzIGRvZXNuJ3Qg
YnJlYWsgYW55dGhpbmcgYW5kIG1ha2VzIGl0IGVhc3kgZm9yIHBlb3BsZSB0byBkZXRlY3QgdGhp
cyBjYXNlIGluIHRob3NlIHVzZSBjYXNlcyB3aGVyZSBpdCdzIHJlcXVpcmVkLg0KDQpUaGFua3Ms
DQpHZW9yZ2UNCk9uIDQvMy8xOSA0OjU2IFBNLCBIYW5zIFphbmRiZWx0IHdyb3RlOg0KSSB3aWxs
IGFyZ3VlIHRoYXQgaW4gYSB3YXkgc3VjaCBkZXBsb3ltZW50cyBhcmUgYWxyZWFkeSBicm9rZW4g
ZS5nLiBpbiB0aGUgdHlwaWNhbCB1c2UgY2FzZSBvZiBvbmJvYXJkaW5nIGNsaWVudCBhY2NvdW50
cyBpbiB0aGUgc2FtZSBkaXJlY3RvcnkvT1UvbmFtZXNwYWNlIGFzIHVzZXIgYWNjb3VudHMgYW5k
IHdlIGRvbid0IG5lZWQgdG8gY2F0ZXIgZm9yIHRoYXQuDQoNCkhhbnMuDQoNCk9uIFdlZCwgQXBy
IDMsIDIwMTkgYXQgMTA6NDggUE0gR2VvcmdlIEZsZXRjaGVyIDxnZmZsZXRjaEBhb2wuY29tPG1h
aWx0bzpnZmZsZXRjaEBhb2wuY29tPj4gd3JvdGU6DQpJIGFncmVlIHRoYXQgdGhpcyB3aWxsIGJy
ZWFrIGEgbG90IG9mIGV4aXN0aW5nIGZsb3dzLi4uIGVzcGVjaWFsbHkgdGhvc2UgdXNpbmcgYW55
IGZvcm0gb2YgdGhlIGNsaWVudF9jcmVkZW50aWFscyBmbG93LiBJbiB0aGF0IHNlbnNlIEknbSBu
b3QgY29tcGxldGVseSBvbiBib2FyZCB5ZXQgOikNCk9uIDMvMjYvMTkgMTI6NTYgUE0sIEhhbnMg
WmFuZGJlbHQgd3JvdGU6DQpncmVhdCBzdW1tYXJ5ISB0aGlzIHdpbGwgaHVydCBxdWl0ZSBhIGZl
dyBleGlzdGluZyBtMm0gZGVwbG95bWVudHMgYnV0IEkgZG8gbGlrZSB0aGUgcmlnaWRuZXNzIG9m
IGl0IGFsbDogaXQgaXMgdmVyeSBleHBsaWNpdCwgY2Fubm90IG1pc2ludGVycHJldGVkIGFuZCB0
aHVzIHByZXZlbnRzIGZhaWx1cmUgKHdoaWNoIGlzIHJlYWxseSB3aGF0IERvbWluaWNrIGlzIGFm
dGVyKTsgSSdtIG9uIGJvYXJkDQoNCkhhbnMuDQoNCk9uIFR1ZSwgTWFyIDI2LCAyMDE5IGF0IDU6
NDkgUE0gVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRtYXJjLmlldGYu
b3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KdGhhbmsgeW91
IFN0ZWluYXIgYW5kIGV2ZXJ5b25lIGVsc2UgZm9yIHRoZSBjb21tZW50cyBvbiB0aGlzIQ0KVG8g
c3VtbWFyaXplIHRoZSBzaXR1YXRpb24gc28gZmFyOiBEb21pbmljaywgU3RlaW5hciwgUm9iLCBE
YXZpZCwgTm92LCBCZXJ0cmFuZCByZWNvbW1lbmQgdXNpbmcgc3ViIG9ubHkgZm9yIHVzZXJzLiBN
YXJ0aW4gd291bGQgbGlrZSB0byBoYXZlIHRoZSBzdWIgZm9yIGFwcCBvbmx5IGZsb3dzIGFzIHdl
bGwuIEhhbnMgaXMgbmV1dHJhbC4NClRoYXQgZG9lcyBzb3VuZCBsaWtlIHRoZSBzdWIgYXMgdXNl
ciBoYXMgbW9yZSBjb25zZW5zdXMsIHRobyBiZWZvcmUgY2hhbmdpbmcgaXQgSSdkIHdhaXQgZm9y
IHRoZSBwZW9wbGUgY3VycmVudGx5IGF0IElFVEYxMDQgdG8gaGF2ZSBtb3JlIHRpbWUgdG8gY29t
bWVudCBhcyB3ZWxsLg0KQ2xhcmlmaWNhdGlvbi4gSWYgdGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0
byBhcHBseSB0aGUgbG9naWMgImlmIHRoZXJlJ3MgYSBzdWIsIGl0J3MgYSB1c2VyIGZsb3ciLCB3
ZSBoYXZlIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgKE1VU1QgTk9UKSB0aGUgdXNlIG9mIHN1YiB3
aGVuIHRoYXQncyBub3QgdGhlIGNhc2UuIEFyZSBhbGwgT0sgd2l0aCBpdD8NCg0KRGF2ZSwgdGhl
IHN1Z2dlc3Rpb24gb2YgaGF2aW5nIGV4cGxpY2l0IHR5cGluZyBmb3IgYXBwIG9ubHkgdnMgdXNl
ciBvbmx5IGlzIGludGVyZXN0aW5nISBGb3IgdGhlIHB1cnBvc2Ugb2YgcHV0dGluZyB0b2dldGhl
ciBhbiBpbnRlcm9wZXJhYmxlIHByb2ZpbGUsIHRobywgSSB3b3VsZCBzdWdnZXN0IHdlIHRhYmxl
IGl0IGZvciB2MSBpbiB0aGUgaW50ZXJlc3Qgb2YgZ2V0dGluZyB0byBzb21ldGhpbmcgZWFzeSB0
byBhZG9wdCAoaGVuY2Ugd2l0aCBzbWFsbCBkZWx0YSB2cyBleGlzdGluZyBpbXBsZW1lbnRhdGlv
bnMpIGZhc3Rlci4NCg0KT24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgMTo0MCBBTSBTdGVpbmFyIE5v
ZW0gPHN0ZWluYXJAdWRlbHQubm88bWFpbHRvOnN0ZWluYXJAdWRlbHQubm8+PiB3cm90ZToNCkhp
IFZpdHRvcmlvLCB3ZSAgKHRoZSBuYXRpb25hbCBmZWRlcmF0aW9uLWdhdGV3YXkgZm9yIHRoZSBo
ZWFsdGggc2VydmljZXMgaW4gbm9yd2F5IC0gIkhlbHNlSUQiKSAgdGhpbmsgaGlzIGlzIGEgcmVh
bGx5IHZhbHVhYmxlIGluaXRpYXRpdmUhDQpXZSBhbHNvIGFncmVlIHdpdGggRG9taW5pY2sgY29u
Y2VybmluZyBkZWZpbml0aW9uIG9mIHRoZSAic3ViIiBjbGFpbS4NCg0KPG12aD5TdGVpbmFyPC9t
dmg+DQoNCnRpci4gMjYuIG1hci4gMjAxOSBrbC4gMDc6MjUgc2tyZXYgRG9taW5pY2sgQmFpZXIg
PGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5j
b20+PjoNCkZyb20gYW4gYWNjZXNzIHRva2VuIGNvbnN1bWVyIChha2EgQVBJKSBkZXZlbG9wZXIg
cG9pbnQgb2YgdmlldywgSSBwcmVmZXIgdGhpcyBsb2dpYw0KDQoiSWYgc3ViIGlzIHByZXNlbnQg
LSBjbGllbnQgYWN0cyBvbiBiZWhhbGYgb2YgYSB1c2VyLCBpZiBub3QgLSBub3QuIg0KDQpBbnl0
aGluZyBtb3JlIGNvbXBsaWNhdGVkIGhhcyBhIHBvdGVudGlhbCBvZiBnb2luZyB3cm9uZy4NCg0K
DQpPbiAyNi4gTWFyY2ggMjAxOSBhdCAwMTozNDo1MywgTm92IE1hdGFrZSAobWF0YWtlQGdtYWls
LmNvbTxtYWlsdG86bWF0YWtlQGdtYWlsLmNvbT4pIHdyb3RlOg0KSGkgVml0dG9yaW8sDQoNClll
YWgsIEnigJltIGNvbmNlcm5pbmcgdXNlciAmIGNsaWVudCBpZHMgY29sbGlzaW9uLg0KSSBoYXZl
buKAmXQgc2VlbiBzdWNoIGltcGxlbWVudGF0aW9ucywgYnV0IHVzZXItc2VsZWN0IHVzZXJuYW1l
IGFzIHN1Yiwgb3IgaW5jcmVtZW50YWwgaW50ZWdlciBhcyBzdWIgJiBjbGllbnRfaWQgd2lsbCBi
ZSBlYXNpbHkgY29sbGlkZS4NCg0KSWYgeW91IGNhbiBlbmZvcmNlIGNvbGxpc2lvbiByZXNpc3Rh
bnQgSURzIGJldHdlZW4gdXNlciAmIGNsaWVudCBpbnN0YW5jZXMsIGl04oCZbGwgd29ya3MgZmlu
ZS4gSSBmZWVsIGl0cyBvdmVya2lsbCB0aG91Z2guDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0K
T24gTWFyIDI2LCAyMDE5LCBhdCA4OjUxLCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0dG9yaW9AYXV0
aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCkhleSBOb3YsIERvbWlu
aWNrLCBIYW5zLQ0KdGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoYXQgd2FzIGFuIGFyZWEgSSB3
YXMgZXhwZWN0aW5nIHRvIGNhdXNlIG1vcmUgZGlzY3Vzc2lvbiwgYW5kIEkgYW0gZ2xhZCB3ZSBh
cmUgaGF2aW5nIHRoaXMgb3Bwb3J0dW5pdHkgdG8gY2xhcmlmeS4NClRoZSBjdXJyZW50IGxhbmd1
YWdlIGluIHRoZSBkcmFmdCB0cmFjZXMgdGhlIGV0eW1vbG9neSBvZiBzdWIgdG8gT3BlbklEIENv
bm5lY3QgY29yZSwgaGVuY2UgRG9taW5pY2sgb2JzZXJ2YXRpb24gaXMgb24gcG9pbnQuIEhvd2V2
ZXIgaW4gdGhlIGRlc2NyaXB0aW9uIEkgZXhwcmVzcyBzb21ldGhpbmcgaW4gbGluZSB3aXRoIDc1
MTksIHdoaWNoIHdhcyBpbiBmYWN0IG15IGludGVudC4NCg0KVGhlIGlkZWEgd2FzIHRvIHByb3Zp
ZGUgYW4gaWRlbnRpZmllciBvZiB0aGUgY2FsbGluZyBzdWJqZWN0IHRoYXQgaXMgZ3VhcmFudGVl
ZCB0byBiZSBwcmVzZW50IGluIGFsbCBjYXNlcy0gdGhpcyB3b3VsZCBhbGxvdyBhbiBTREsgZGV2
ZWxvcGVyIHRvIHVzZSB0aGUgc2FtZSBjb2RlIGZvciB0aGluZ3MgbGlrZSBsb29rdXBzIGFuZCBt
ZW1iZXJzaGlwIGNoZWNrcyByZWdhcmRsZXNzIG9mIHRoZSBuYXR1cmUgb2YgdGhlIGNhbGxlciAo
dXNlciBpbiBhIGRlbGVnYXRlZCBjYXNlLCBhcHAgaW4gYXBwLW9ubHkgZ3JhbnRzKS4gVGhlIGlu
Zm9ybWF0aW9uIHRvIGRpc2NyaW1pbmF0ZSBiZXR3ZWVuIHVzZXIgYW5kIGFwcCBjYWxsZXJzIGlz
IGFsd2F5cyBhdmFpbGFibGUgaW4gdGhlIHRva2VuIChzYXksIHRoZSBjYWxsZXIgaXMgYSB1c2Vy
IGlmIHN1YiE9Y2xpZW50X2lkLCB3aGVyZSBjbGllbnRfaWQgaXMgYWx3YXlzIGd1YXJhbnRlZWQg
dG8gYmUgcHJlc2VudCBhcyB3ZWxsKSBoZW5jZSB0aGVyZSdzIG5vIGxvc3MgaW4gZXhwcmVzc2l2
ZSBwb3dlciwgc2hvdWxkIHRoYXQgZGlmZmVyZW5jZSBiZSByZWxldmFudCBmb3IgdGhlIHJlc291
cmNlIHNlcnZlci4NCg0KRG9taW5pY2ssIEhhbnMtIEkgcHJvYmFibHkgbWlzc2VkIHRoZSBzZWN1
cml0eSBpc3N1ZSB5b3UgZ3V5cyBhcmUgdGhpbmtpbmcgb2YgaW4gdGhpcyBjYXNlLiBPZiBjb3Vy
c2UsIGlmIHRoaXMgd291bGQgaW50cm9kdWNlIGEgcmlzayBJIGNvbXBsZXRlbHkgYWdyZWUgaXQg
c2hvdWxkIGJlIGNoYW5nZWQtIEknZCBqdXN0IGxpa2UgdG8gdW5kZXJzdGFuZCBiZXR0ZXIgdGhl
IHByb2JsZW0uIENvdWxkIHlvdSBleHBhbmQgaXQgaW4gYSBzY2VuYXJpby91c2UgY2FzZSB0byBj
bGFyaWZ5IHRoZSByaXNrPw0KTm92LSBwbGF5aW5nIHRoaXMgYmFjazogaXMgdGhlIGNvbmNlcm4g
dGhhdCBhIHVzZXIgYW5kIGEgY2xpZW50IG1pZ2h0IGhhdmUgdGhlIHNhbWUgaWRlbnRpZmllciB3
aXRoaW4gYW4gSURQPyBXaGVuIHVzaW5nIGNvbGxpc2lvbiByZXNpc3RhbnQgSURzLCBhcyBpdCBp
cyB1c3VhbGx5IHRoZSBjYXNlLCB0aGF0IHNlZW1zIHRvIGJlIGEgcmVtb3RlIHBvc3NpYmlsaXR5
LSBkaWQgeW91IHN0dW1ibGUgaW4gc3VjaCBzY2VuYXJpbyBpbiBwcm9kdWN0aW9uPw0KDQpUaGFu
a3MNClYuDQoNCg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgNzo0NCBBTSBIYW5zIFphbmRiZWx0
IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpv
bmUuZXU+PiB3cm90ZToNCkkgYmVsaWV2ZSB0aGVyZSBhcmUgcGxlbnR5IG9mIE9BdXRoIDIuMCBv
bmx5IHVzZSBjYXNlcyBvdXQgdGhlcmUuLi4gYnV0IG5ldmVydGhlbGVzcyBJIGFncmVlIHdpdGgg
dGhlIHBvdGVudGlhbCBjb25mdXNpb24gYW5kIHRodXMgc2VjdXJpdHkgcHJvYmxlbXMgYXJpc2lu
ZyBmcm9tIHRoYXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRoZSBz
YW1lKS4NCg0KSGFucy4NCg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMzozOSBQTSBEb21pbmlj
ayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJp
dmlsZWdlLmNvbT4+IHdyb3RlOg0KWWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGluIGhpbmRzaWdo
dCBpdCB3YXMgYSBtaXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZvciBtdWx0aXBs
ZSBzZW1hbnRpY3MuDQoNCkFsbCB0aGUg4oCcdGhpcyBpcyBPSURDIG5vdCBPQXV0aOKAnSBhcmd1
bWVudHMgYXJlIG1ha2luZyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoZXkgbmVlZCB0
byBiZSAtIGluIG15IGV4cGVyaWVuY2UgYWxtb3N0IG5vLW9uZSAodGhhdCBJIGtub3cpIGRvZXMg
T0lEQyBvbmx5IC0gbm9yIE9BdXRoIG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUgaXQuDQoNCklu
IHJlYWxpdHkgdGhpcyBsZWFkcyB0byBwb3RlbnRpYWwgc2VjdXJpdHkgcHJvYmxlbXMgLSB0aGlz
IHNwZWMgaGFzIHRoZSBwb3RlbnRpYWwgdG8gcmVjdGlmeSB0aGUgc2l0dWF0aW9uLg0KDQpEb21p
bmljaw0KDQpPbiAyNS4gTWFyY2ggMjAxOSBhdCAxNDo1ODo1NiwgSGFucyBaYW5kYmVsdCAoaGFu
cy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1
Pikgd3JvdGU6DQpXaXRob3V0IGFncmVlaW5nIG9yIGRpc2FncmVlaW5nOiBPSURDIGRvZXMgbm90
IGFwcGx5IGhlcmUgc2luY2UgaXQgaXMgbm90IE9BdXRoIGFuZCBhbiBhY2Nlc3MgdG9rZW4gaXMg
bm90IGFuIGlkX3Rva2VuLg0KVGhlIEpXVCBzcGVjIHNheXMgaW4gaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMjoNCg0KIlRoZSAic3ViIiAoc3ViamVjdCkg
Y2xhaW0gaWRlbnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQgaXMgdGhlDQogICBzdWJqZWN0IG9m
IHRoZSBKV1QuICBUaGUgY2xhaW1zIGluIGEgSldUIGFyZSBub3JtYWxseSBzdGF0ZW1lbnRzDQog
ICBhYm91dCB0aGUgc3ViamVjdC4gIFRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0aGVyIGJlIHNj
b3BlZCB0byBiZQ0KICAgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3Vl
ciBvciBiZSBnbG9iYWxseSB1bmlxdWUuDQogICBUaGUgcHJvY2Vzc2luZyBvZiB0aGlzIGNsYWlt
IGlzIGdlbmVyYWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYyINCg0Kd2hpY2gga2luZCBvZiBzcGVs
bHMgImNsaWVudCIgaW4gY2FzZSBvZiB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IGJ1dCBJ
IGFsc28gZG8gd29ycnkgYWJvdXQgUmVzb3VyY2UgU2VydmVycyB0aGlua2luZy9hY3Rpbmcgb25s
eSBpbiB0ZXJtcyBvZiB1c2Vycw0KDQpIYW5zLg0KDQpPbiBNb24sIE1hciAyNSwgMjAxOSBhdCAy
OjQxIFBNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpk
YmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoZSBzdWIgY2xhaW0gc2hv
dWxkIGFsd2F5cyByZWZlciB0byB0aGUgdXNlciAtIGFuZCBub3RoaW5nIGVsc2UuDQoNCk9JREMg
c2F5czoNCg0KIlN1YmplY3QgLSBJZGVudGlmaWVyIGZvciB0aGUgRW5kLVVzZXIgYXQgdGhlIElz
c3Vlci4iDQoNCmNsaWVudF9pZCBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSBjbGllbnRzLg0K
DQpjaGVlcnMNCkRvbWluaWNrDQoNCg0KT24gMjUuLiBNYXJjaCAyMDE5IGF0IDA1OjEzOjAzLCBO
b3YgTWF0YWtlIChtYXRha2VAZ21haWwuY29tPG1haWx0bzptYXRha2VAZ21haWwuY29tPikgd3Jv
dGU6DQpIaSBWaXR0b3JpbywNCg0KVGhhbmtzIGZvciB0aGUgZ29vZCBzdGFydGluZyBwb2ludCBv
ZiBzdGFuZGFyZGl6aW5nIEpXVC1pemVkIEFULg0KDQpPbmUgZmVlZGJhY2suDQpUaGUg4oCcc3Vi
4oCdIGNsYWltIGNhbiBpbmNsdWRlIDIgdHlwZXMgb2YgaWRlbnRpZmllciwgZW5kLXVzZXIgYW5k
IGNsaWVudCwgaW4gdGhpcyBzcGVjLg0KSXQgcmVxdWlyZXMgdGhvc2UgMiB0eXBlcyBvZiBpZGVu
dGlmaWVycyB0byBiZSB1bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQIGNvbnRleHQuDQoNCkkg
cHJlZmVyIG9taXR0aW5nIOKAnHN1YuKAnSBjbGFpbSBpbiAyLWxlZ2dlZCBjb250ZXh0LCBzbyB0
aGF0IG5vIHN1Y2ggY29uc3RyYWludCBuZWVkZWQuDQoNCnRoYW5rcw0KDQpub3YNCg0KT24gTWFy
IDI1LCAyMDE5LCBhdCA4OjI5LCBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9
NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0
aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkRlYXIgYWxsLA0KSSBqdXN0IHN1Ym1p
dHRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgYSBKV1QgcHJvZmlsZSBmb3IgT0F1dGggMi4wIGFjY2Vz
cyB0b2tlbnMuIFlvdSBjYW4gZmluZCBpdCBpbiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0Ly4NCkkgaGF2ZSBhIHNs
b3QgdG8gZGlzY3VzcyB0aGlzIHRvbW9ycm93IGF0IElFVEYgMTA0IChJJ2xsIGJlIHByZXNlbnRp
bmcgcmVtb3RlbHkpLiBJIGxvb2sgZm9yd2FyZCBmb3IgeW91ciBjb21tZW50cyENCg0KSGVyZSdz
IGp1c3QgYSBiaXQgb2YgYmFja3N0b3J5LCBpbiBjYXNlIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBo
b3cgdGhpcyBkb2MgY2FtZSB0byBiZS4gVGhlIHRyYWplY3RvcnkgaXQgZm9sbG93ZWQgaXMgc29t
ZXdoYXQgdW51c3VhbC4NCg0KICAqICAgRGVzcGl0ZSBPQXV0aDIgbm90IHJlcXVpcmluZyBhbnkg
c3BlY2lmaWMgZm9ybWF0IGZvciBBVHMsIHRocm91Z2ggdGhlIHllYXJzIEkgaGF2ZSBjb21lIGFj
cm9zcyBtdWx0aXBsZSBwcm9wcmlldGFyeSBzb2x1dGlvbiB1c2luZyBKV1QgZm9yIHRoZWlyIGFj
Y2VzcyB0b2tlbi4gVGhlIGludGVudCBhbmQgc2NlbmFyaW9zIGFkZHJlc3NlZCBieSB0aG9zZSBz
b2x1dGlvbnMgYXJlIG1vc3RseSB0aGUgc2FtZSBhY3Jvc3MgdmVuZG9ycywgYnV0IHRoZSBzeW50
YXggYW5kIGludGVycHJldGF0aW9ucyBpbiB0aGUgaW1wbGVtZW50YXRpb25zIGFyZSBkaWZmZXJl
bnQgZW5vdWdoIHRvIHByZXZlbnQgZGV2ZWxvcGVycyBmcm9tIHJldXNpbmcgY29kZSBhbmQgc2tp
bGxzIHdoZW4gbW92aW5nIGZyb20gcHJvZHVjdCB0byBwcm9kdWN0Lg0KICAqICAgSSBhc2tlZCBz
ZXZlcmFsIGluZGl2aWR1YWxzIGZyb20ga2V5IHByb2R1Y3RzIGFuZCBzZXJ2aWNlcyB0byBzaGFy
ZSB3aXRoIG1lIGNvbmNyZXRlIGV4YW1wbGVzIG9mIHRoZWlyIEpXVCBhY2Nlc3MgdG9rZW5zIChU
SEFOSyBZT1UgRG9taW5pY2sgQmFpZXIgKElkZW50aXR5U2VydmVyKSwgQnJpYW4gQ2FtcGJlbGwg
KFBpbmdJZGVudGl0eSksIERhbmllbCBEb2JhbGlhbiAoTWljcm9zb2Z0KSwgS2FybCBHdWlubmVz
cyAoT2t0YSkgZm9yIHRoZSB0b2tlbnMgYW5kIGV4cGxhbmF0aW9ucyEpLg0KSSBzdHVkaWVkIGFu
ZCBjb21wYXJlZCBhbGwgdGhvc2UgaW5zdGFuY2VzLCBpZGVudGlmeWluZyBjb21tb25hbGl0aWVz
IGFuZCBkaWZmZXJlbmNlcy4NCiAgKiAgIEkgcHV0IHRvZ2V0aGVyIGEgcHJlc2VudGF0aW9uIHN1
bW1hcml6aW5nIG15IGZpbmRpbmdzIGFuZCBzdWdnZXN0aW5nIGEgcm91Z2ggaW50ZXJvcGVyYWJs
ZSBwcm9maWxlIChzbGlkZXM6IGh0dHBzOi8vc2VjLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2
ZW50cy9vc3cyMDE5L3NsaWRlcy9iZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4
PGh0dHBzOi8vc2VjLi51bmktc3R1dHRnYXJ0LmRlL19tZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlk
ZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMucHB0eD4gKSAtIGdvdCBlYXJseSBm
ZWVkYmFjayBmcm9tIEZpbGlwIFNrb2thbiBvbiBpdC4gVGh4IEZpbGlwIQ0KICAqICAgVGhlIHBy
ZXNlbnRhdGlvbiB3YXMgZm9sbG93ZWQgdXAgYnkgMS41IGhvdXJzIG9mIHVuY29uZmVyZW5jZSBk
aXNjdXNzaW9uLCB3aGljaCB3YXMgaW5jcmVkaWJseSB2YWx1YWJsZSB0byBnZXQgdGlnaHQtbG9v
cCBmZWVkYmFjayBhbmQgaW5jb3Jwb3JhdGUgbmV3IGlkZWFzLiBKb2huIEJyYWRsZXksIEJyaWFu
IENhbXBiZWxsIFZsYWRpbWlyIER6aHV2aW5vdiwgVG9yc3RlbiBMb2RkZXJzdGVkdCwgTmF0IFNh
a2ltdXJhLCBIYW5uZXMgVHNjaG9mZW5pZyB3ZXJlIGFsbCB0aGVyZSBhbmQgY29udHJpYnV0ZWQg
Z2VuZXJvdXNseSB0byB0aGUgZGlzY3Vzc2lvbi4gVGhhbmsgeW91ISEhDQpOb3RlOiBpZiB5b3Ug
d2VyZSBhdCBPU1cyMDE5LCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb24gYW5kIGRpZG4n
dCBnZXQgY3JlZGl0ZWQgaW4gdGhlIGRyYWZ0LCBteSBhcG9sb2dpZXM6IHBsZWFzZSBzZW5kIG1l
IGEgbm90ZSBhbmQgSSdsbCBtYWtlIHRoaW5ncyByaWdodCBhdCB0aGUgbmV4dCB1cGRhdGUuDQog
ICogICBPbiBteSBmbGlnaHQgYmFjayBJIGRpZCBteSBiZXN0IHRvIGluY29ycG9yYXRlIGFsbCB0
aGUgaWRlYXMgYW5kIGZlZWRiYWNrIGluIGEgZHJhZnQsIHdoaWNoIHdpbGwgYmUgZGlzY3Vzc2Vk
IGF0IElFVEYxMDQgdG9tb3Jyb3cuIFJpZmFhdCwgSGFubmVzIGFuZCBhYm92ZSBhbGwgQnJpYW4g
d2VyZSBhbGwgc3VwZXIgaGVscGZ1bCBpbiBuZWdvdGlhdGluZyB0aGUgbXlzdGVyaW91cyBzeW50
YXggb2YgdGhlIFJGQyBmb3JtYXQgYW5kIHN1Ym1pc3Npb24gcHJvY2Vzcy4NCkkgd2FzIGJsb3du
IGF3YXkgYnkgdGhlIGF2YWlsYWJpbGl0eSwgaW52b2x2ZW1lbnQgYW5kIHdpbGxpbmduZXNzIHRv
IGludmVzdCB0aW1lIHRvIGdldCB0aGluZ3MgcmlnaHQgdGhhdCBldmVyeW9uZSBkZW1vbnN0cmF0
ZWQgaW4gdGhlIHByb2Nlc3MuIFRoaXMgaXMgYW4gYW1hemluZyBjb21tdW5pdHkuDQpWLg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp
bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp
ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0
QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJQU0gLSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93
d3cuem1hcnR6b25lLmV1Pg0KDQoNCi0tDQpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWls
dG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+DQpabWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0
em9uZS5ldTxodHRwOi8vd3d3LnptYXJ0em9uZS5ldT4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KVmVubmxpZyBoaWxzZW4NCg0KU3RlaW5hciBOb2VtDQpQ
YXJ0bmVyIFVkZWx0IEFTDQpTeXN0ZW11dHZpa2xlcg0KDQp8IHN0ZWluYXJAdWRlbHQubm88bWFp
bHRvOnN0ZWluYXJAdWRlbHQuLm5vPiB8IGhlaUB1ZGVsdC5ubzxtYWlsdG86aGVpQHVkZWx0Lm5v
PiAgfCArNDcgOTU1IDIxIDYyMCB8IHd3dy51ZGVsdC5ubzxodHRwOi8vd3d3LnVkZWx0Lm5vLz4g
fA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCi0tDQpoYW5zLnph
bmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+DQpa
bWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0em9uZS5ldTxodHRwOi8vd3d3LnptYXJ0em9uZS5ldT4N
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpP
QXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQot
LQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6
b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFy
dHpvbmUuZXU+DQoNCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhh
bnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUu
ZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+DQo=

--_000_SN6PR00MB030459810B40D98370728BBAF5500SN6PR00MB0304namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K
CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t
bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjt9DQpwLmdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwtbS03MDQ1NTQ1OTQ1
ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAy
MTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2Fpcm1haWxvbiwgbGkuZ21haWwtbTQ2MDg5
NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkz
MzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4
MjUzODQzYWlybWFpbG9uLCBkaXYuZ21haWwtbTQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcw
NDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2
MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzYWlybWFpbG9uDQoJe21zby1z
dHlsZS1uYW1lOmdtYWlsLW1fNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3
MzUzMjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0
MDdnbWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNhaXJtYWlsb247DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwt
bS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5
ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYw
MTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdhaXJtYWlsb24sIGxpLmdtYWls
LW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0x
NzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5
Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1
MTUxMDY4MTdhaXJtYWlsb24sIGRpdi5nbWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0t
NzA0NTU0NTk0NTg3MzUzMjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgw
MDYwNjQxODYwMjE0MDdnbWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDEx
Mzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uDQoJe21zby1zdHls
ZS1uYW1lOmdtYWlsLW1fNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUz
MjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdn
bWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWls
LW0xMjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0
NTk0NTg3MzUzMjA1OWdtYWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQx
ODYwMjE0MDdnbWFpbC1tLTE4NjE0OTI5NzYwOTgyNTM4NDNnbWFpbC1tODIwMzA2MDExMzg3NzE2
Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3Z21haWwtbTg0NzU3Mjg2NTYyNDU0OTI0OTVh
aXJtYWlsb24sIGxpLmdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwtbS03MDQ1NTQ1OTQ1
ODczNTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAy
MTQwN2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2
Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdnbWFpbC1tODQ3NTcyODY1NjI0NTQ5MjQ5NWFpcm1h
aWxvbiwgZGl2LmdtYWlsLW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwtbS03MDQ1NTQ1OTQ1ODcz
NTMyMDU5Z21haWwtbS0xNzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAyMTQw
N2dtYWlsLW0tMTg2MTQ5Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21h
aWwtbTEyODA3MTc5Njk1MTUxMDY4MTdnbWFpbC1tODQ3NTcyODY1NjI0NTQ5MjQ5NWFpcm1haWxv
bg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzQ2MDg5NjIzNjk4Nzc5NjcyMDRnbWFpbC1tLTcw
NDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2MmdtYWlsLW01MTk4MDA2
MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21haWwtbTgyMDMwNjAxMTM4
NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04NDc1NzI4NjU2MjQ1NDky
NDk1YWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh
bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA2
NjYwODcwMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA4ODA0NjczNDt9DQpAbGlzdCBsMDps
ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww
OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0
IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s
DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+SSBnZXQgdGhhdCBleGlzdGluZyBwcmFjdGljZSBpcyBsaWtlbHkg
dG8gYmUgYWxsIG92ZXIgdGhlIG1hcCwgYnV0IGlmIHdl4oCZcmUgdG8gY3JlYXRlIGEgSldUIGFj
Y2VzcyB0b2tlbiBzdGFuZGFyZCwgaXTigJlzIHJlYXNvbmFibGUgdG8gcmVxdWlyZSB0aGF0IHRo
ZSBjbGFpbXMgdXNhZ2UgY29tcGx5IHdpdGggdGhlIEpXVCBzdGFuZGFyZHMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw
NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSGFucyBaYW5kYmVsdCAmbHQ7aGFu
cy56YW5kYmVsdEB6bWFydHpvbmUuZXUmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg
QXByaWwgNCwgMjAxOSAxMjo1OSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gR2VvcmdlIEZsZXRj
aGVyICZsdDtnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBWaXR0b3JpbyBC
ZXJ0b2NjaSAmbHQ7Vml0dG9yaW89NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBJRVRG
IG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6
IFtPQVVUSC1XR10gZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgZGVmaW5pdGlvbiBv
ZiBSRkMgNzUxOSBpcyBhY3R1YWxseSAmcXVvdDtwZXRpdGlvIHByaW5jaXBpaSZxdW90OyBhbmQg
YSBsb3Qgb2YgZGVwbG95bWVudHMgcHV0IGNsYWltcyBhYm91dCB0aGUgUmVzb3VyY2UgT3duZXIg
aW4gdGhlIGFjY2VzcyB0b2tlbiAoYXMgYSBSZXNvdXJjZSBTZXJ2ZXIgaW1wbGVtZW50ZXIgSSd2
ZSBzdWZmZXJlZCBhIGxvdCBmcm9tIHRoaXMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXByIDQsIDIwMTkgYXQgOTo0OCBQ
TSBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB3aXRoIEdlb3JnZSB0
aGF0IHRoZSBzdWJqZWN0IG9mIGEgdG9rZW4gbXVzdCBiZSB0aGUgcHJpbmNpcGFsIG9mIHRoYXQg
dG9rZW4uJm5ic3A7IFRoYXQgd2hhdCB0aGUgSldUIOKAnHN1YuKAnSBjbGFpbSBpcyBmb3IuJm5i
c3A7IEluZGVlZCwgdGhlIGZpcnN0IHNlbnRlbmNlDQogb2YgdGhlIOKAnHN1YuKAnSBkZWZpbml0
aW9uIGF0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rp
b24tNC4xLjIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y
ZmM3NTE5I3NlY3Rpb24tNC4xLjI8L2E+IGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDb25zb2xhcztiYWNrZ3JvdW5kOndoaXRlIj5UaGUgJnF1b3Q7c3ViJnF1b3Q7IChzdWJq
ZWN0KSBjbGFpbSBpZGVudGlmaWVzIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0aGUgc3ViamVjdCBv
ZiB0aGUgSldULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPklmIGFu
IGFjY2VzcyB0b2tlbiB1c2VzIOKAnHN1YuKAnSwgaXRzIHVzYWdlIG11c3QgY29tcGx5IHdpdGgg
dGhlIGRlZmluaXRpb24gZnJvbSBSRkMgNzUxOS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr
ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206
PC9iPiBPQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+R2VvcmdlIEZsZXRjaGVyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJp
bCA0LCAyMDE5IDg6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbnMgWmFuZGJlbHQgJmx0OzxhIGhy
ZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhh
bnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFZpdHRvcmlv
IEJlcnRvY2NpICZsdDtWaXR0b3Jpbz08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMu
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m
Z3Q7OyBJRVRGIG9hdXRoIFdHICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QtMDA8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBtb3JlIEkgdGhpbmsg
YWJvdXQgdGhpcyB0aGUgbW9yZSBJIGxhbmQgaW4gdGhlICZxdW90O05vJnF1b3Q7IGNhbXAuPGJy
Pg0KPGJyPg0KVGhlIHN1YmplY3Qgb2YgYSB0b2tlbiBzaG91bGQgYmUgdGhlIHByaW5jaXBhbCBv
ZiB0aGF0IHRva2VuLiBJdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIgdGhhdCBpcyBhIG1hY2hp
bmUsIGEgdXNlciwgb3IgYSBkZXZpY2UuIFRyeWluZyB0byBzZXBhcmF0ZSBvdXQgJnF1b3Q7aHVt
YW5zJnF1b3Q7IGFzIGEgc3BlY2lhbCBjbGFzcyB3aWxsIGp1c3QgbWFrZSB0aGluZ3MgbW9yZSBj
b21wbGljYXRlZC4gSWYgd2UgbmVlZCBhIGNsYWltIHRvIGlkZW50aWZ5IHRoZSBzdWJqZWN0DQog
aXMgYSAmcXVvdDtodW1hbiZxdW90OyB0aGVuIHdoeSBub3QganVzdCBhZGQgdGhhdC4gVGhpcyBk
b2Vzbid0IGJyZWFrIGFueXRoaW5nIGFuZCBtYWtlcyBpdCBlYXN5IGZvciBwZW9wbGUgdG8gZGV0
ZWN0IHRoaXMgY2FzZSBpbiB0aG9zZSB1c2UgY2FzZXMgd2hlcmUgaXQncyByZXF1aXJlZC48YnI+
DQo8YnI+DQpUaGFua3MsPGJyPg0KR2VvcmdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gNC8zLzE5IDQ6NTYgUE0sIEhhbnMgWmFuZGJlbHQg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SSB3aWxsIGFyZ3VlIHRoYXQgaW4gYSB3YXkgc3VjaCBkZXBsb3ltZW50cyBhcmUgYWxy
ZWFkeSBicm9rZW4gZS5nLiBpbiB0aGUgdHlwaWNhbCB1c2UgY2FzZSBvZiBvbmJvYXJkaW5nIGNs
aWVudCBhY2NvdW50cyBpbiB0aGUgc2FtZSBkaXJlY3RvcnkvT1UvbmFtZXNwYWNlIGFzIHVzZXIg
YWNjb3VudHMgYW5kDQogd2UgZG9uJ3QgbmVlZCB0byBjYXRlciBmb3IgdGhhdC4gPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFucy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwg
QXByIDMsIDIwMTkgYXQgMTA6NDggUE0gR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBocmVmPSJtYWls
dG86Z2ZmbGV0Y2hAYW9sLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdmZmxldGNoQGFvbC5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo
dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkg
YWdyZWUgdGhhdCB0aGlzIHdpbGwgYnJlYWsgYSBsb3Qgb2YgZXhpc3RpbmcgZmxvd3MuLi4gZXNw
ZWNpYWxseSB0aG9zZSB1c2luZyBhbnkgZm9ybSBvZiB0aGUgY2xpZW50X2NyZWRlbnRpYWxzIGZs
b3cuIEluIHRoYXQgc2Vuc2UNCiBJJ20gbm90IGNvbXBsZXRlbHkgb24gYm9hcmQgeWV0IDopPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMy8y
Ni8xOSAxMjo1NiBQTSwgSGFucyBaYW5kYmVsdCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JlYXQgc3VtbWFyeSEg
dGhpcyB3aWxsIGh1cnQgcXVpdGUgYSBmZXcgZXhpc3RpbmcgbTJtIGRlcGxveW1lbnRzIGJ1dCBJ
IGRvIGxpa2UgdGhlIHJpZ2lkbmVzcyBvZiBpdCBhbGw6IGl0IGlzIHZlcnkgZXhwbGljaXQsIGNh
bm5vdCBtaXNpbnRlcnByZXRlZCBhbmQgdGh1cyBwcmV2ZW50cyBmYWlsdXJlICh3aGljaA0KIGlz
IHJlYWxseSB3aGF0IERvbWluaWNrIGlzIGFmdGVyKTsgSSdtIG9uIGJvYXJkIDxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhhbnMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIE1h
ciAyNiwgMjAxOSBhdCA1OjQ5IFBNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz08YSBo
cmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40
MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoYW5rIHlvdSBTdGVpbmFyIGFuZCBldmVy
eW9uZSBlbHNlIGZvciB0aGUgY29tbWVudHMgb24gdGhpcyENCjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gc3VtbWFyaXplIHRoZSBzaXR1YXRpb24gc28g
ZmFyOiBEb21pbmljaywgU3RlaW5hciwgUm9iLCBEYXZpZCwgTm92LCBCZXJ0cmFuZCByZWNvbW1l
bmQgdXNpbmcgc3ViIG9ubHkgZm9yIHVzZXJzLiBNYXJ0aW4gd291bGQgbGlrZSB0byBoYXZlIHRo
ZSBzdWIgZm9yIGFwcCBvbmx5IGZsb3dzIGFzIHdlbGwuDQogSGFucyBpcyBuZXV0cmFsLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IGRv
ZXMgc291bmQgbGlrZSB0aGUgc3ViIGFzIHVzZXIgaGFzIG1vcmUgY29uc2Vuc3VzLCB0aG8gYmVm
b3JlIGNoYW5naW5nIGl0IEknZCB3YWl0IGZvciB0aGUgcGVvcGxlIGN1cnJlbnRseSBhdCBJRVRG
MTA0IHRvIGhhdmUgbW9yZSB0aW1lIHRvIGNvbW1lbnQgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2xhcmlmaWNhdGlvbi4gSWYg
dGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0byBhcHBseSB0aGUgbG9naWMgJnF1b3Q7aWYgdGhlcmUn
cyBhIHN1YiwgaXQncyBhIHVzZXIgZmxvdyZxdW90Oywgd2UgaGF2ZSB0byBleHBsaWNpdGx5IGRp
c2FsbG93IChNVVNUIE5PVCkgdGhlIHVzZSBvZiBzdWIgd2hlbiB0aGF0J3Mgbm90IHRoZSBjYXNl
Lg0KIEFyZSBhbGwgT0sgd2l0aCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRhdmUsIHRoZSBzdWdnZXN0aW9uIG9mIGhhdmluZyBl
eHBsaWNpdCB0eXBpbmcgZm9yIGFwcCBvbmx5IHZzIHVzZXIgb25seSBpcyBpbnRlcmVzdGluZyEg
Rm9yIHRoZSBwdXJwb3NlIG9mIHB1dHRpbmcgdG9nZXRoZXIgYW4gaW50ZXJvcGVyYWJsZSBwcm9m
aWxlLCB0aG8sIEkgd291bGQgc3VnZ2VzdCB3ZSB0YWJsZQ0KIGl0IGZvciB2MSBpbiB0aGUgaW50
ZXJlc3Qgb2YgZ2V0dGluZyB0byBzb21ldGhpbmcgZWFzeSB0byBhZG9wdCAoaGVuY2Ugd2l0aCBz
bWFsbCBkZWx0YSB2cyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMpIGZhc3Rlci4mbmJzcDsgJm5i
c3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+T24gVHVlLCBNYXIgMjYsIDIwMTkgYXQgMTo0MCBBTSBTdGVpbmFyIE5vZW0g
Jmx0OzxhIGhyZWY9Im1haWx0bzpzdGVpbmFyQHVkZWx0Lm5vIiB0YXJnZXQ9Il9ibGFuayI+c3Rl
aW5hckB1ZGVsdC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkhpIFZpdHRvcmlvLCB3ZSZuYnNwOyAodGhlIG5hdGlvbmFsIGZl
ZGVyYXRpb24tZ2F0ZXdheSBmb3IgdGhlIGhlYWx0aCBzZXJ2aWNlcyBpbiBub3J3YXkgLSAmcXVv
dDtIZWxzZUlEJnF1b3Q7KSZuYnNwOyB0aGluayBoaXMgaXMgYSByZWFsbHkgdmFsdWFibGUgaW5p
dGlhdGl2ZSENCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
V2UgYWxzbyBhZ3JlZSB3aXRoIERvbWluaWNrIGNvbmNlcm5pbmcgZGVmaW5pdGlvbiBvZiB0aGUg
JnF1b3Q7c3ViJnF1b3Q7IGNsYWltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmx0O212aCZndDtTdGVpbmFyJmx0Oy9tdmgmZ3Q7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50
aXIuIDI2LiBtYXIuIDIwMTkga2wuIDA3OjI1IHNrcmV2IERvbWluaWNrIEJhaWVyICZsdDs8YSBo
cmVmPSJtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRi
YWllckBsZWFzdHByaXZpbGVnZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb20gYW4g
YWNjZXNzIHRva2VuIGNvbnN1bWVyIChha2EgQVBJKSBkZXZlbG9wZXIgcG9pbnQgb2Ygdmlldywg
SSBwcmVmZXIgdGhpcyBsb2dpYzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPiZxdW90O0lmIHN1YiBpcyBwcmVzZW50IC0gY2xpZW50IGFjdHMgb24g
YmVoYWxmIG9mIGEgdXNlciwgaWYgbm90IC0gbm90LiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFueXRoaW5nIG1vcmUgY29tcGxpY2F0
ZWQgaGFzIGEgcG90ZW50aWFsIG9mIGdvaW5nIHdyb25nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJnbWFpbC1tNDYwODk2MjM2OTg3Nzk2NzIwNGdtYWlsLW0tNzA0NTU0NTk0NTg3MzUzMjA1OWdt
YWlsLW0tMTcwNzc5OTMzMjg4MDU3NzYyZ21haWwtbTUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1t
LTE4NjE0OTI5NzYwOTgyNTM4NDNhaXJtYWlsb24iPg0KT24gMjYuIE1hcmNoIDIwMTkgYXQgMDE6
MzQ6NTMsIE5vdiBNYXRha2UgKDxhIGhyZWY9Im1haWx0bzptYXRha2VAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWF0YWtlQGdtYWlsLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBW
aXR0b3Jpbyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlllYWgsIEnigJltIGNvbmNlcm5pbmcgdXNlciAmYW1wOyBjbGllbnQgaWRzIGNv
bGxpc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SSBoYXZlbuKAmXQgc2VlbiBzdWNoIGltcGxlbWVudGF0aW9ucywgYnV0IHVzZXItc2Vs
ZWN0IHVzZXJuYW1lIGFzIHN1Yiwgb3IgaW5jcmVtZW50YWwgaW50ZWdlciBhcyBzdWIgJmFtcDsg
Y2xpZW50X2lkIHdpbGwgYmUgZWFzaWx5IGNvbGxpZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB5b3UgY2FuIGVuZm9yY2UgY29s
bGlzaW9uIHJlc2lzdGFudCBJRHMgYmV0d2VlbiB1c2VyICZhbXA7IGNsaWVudCBpbnN0YW5jZXMs
IGl04oCZbGwgd29ya3MgZmluZS4gSSBmZWVsIGl0cyBvdmVya2lsbCB0aG91Z2guPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9ImdtYWlsLW1fNDYwODk2MjM2OTg3Nzk2NzIwNGdt
YWlsLW1fLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tXy0xNzA3Nzk5MzMyODgwNTc3NjJnbWFp
bC1tXzUxOTgwMDYwNjQxODYwMjE0MDdnbWFpbC1tXy0xODYxNDkyOTc2MDk4MjUzODQzQXBwbGVN
YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VudCBmcm9tIG15IGlQaG9u
ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP
biBNYXIgMjYsIDIwMTksIGF0IDg6NTEsIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJt
YWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+Vml0dG9yaW9AYXV0aDAu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhleSBOb3YsIERvbWluaWNrLCBIYW5zLQ0KPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGFua3MgZm9yIHRoZSBj
b21tZW50cy4gVGhhdCB3YXMgYW4gYXJlYSBJIHdhcyBleHBlY3RpbmcgdG8gY2F1c2UgbW9yZSBk
aXNjdXNzaW9uLCBhbmQgSSBhbSBnbGFkIHdlIGFyZSBoYXZpbmcgdGhpcyBvcHBvcnR1bml0eSB0
byBjbGFyaWZ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5UaGUgY3VycmVudCBsYW5ndWFnZSBpbiB0aGUgZHJhZnQgdHJhY2VzIHRoZSBldHlt
b2xvZ3kgb2Ygc3ViIHRvIE9wZW5JRCBDb25uZWN0IGNvcmUsIGhlbmNlIERvbWluaWNrIG9ic2Vy
dmF0aW9uIGlzIG9uIHBvaW50LiBIb3dldmVyIGluIHRoZSBkZXNjcmlwdGlvbiBJIGV4cHJlc3Mg
c29tZXRoaW5nIGluIGxpbmUNCiB3aXRoIDc1MTksIHdoaWNoIHdhcyBpbiBmYWN0IG15IGludGVu
dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPlRoZSBpZGVhIHdhcyB0byBwcm92aWRlIGFuIGlkZW50aWZpZXIgb2YgdGhlIGNhbGxpbmcg
c3ViamVjdCB0aGF0IGlzIGd1YXJhbnRlZWQgdG8gYmUgcHJlc2VudCBpbiBhbGwgY2FzZXMtIHRo
aXMgd291bGQgYWxsb3cgYW4gU0RLIGRldmVsb3BlciB0byB1c2UgdGhlIHNhbWUgY29kZSBmb3Ig
dGhpbmdzIGxpa2UNCiBsb29rdXBzIGFuZCBtZW1iZXJzaGlwIGNoZWNrcyByZWdhcmRsZXNzIG9m
IHRoZSBuYXR1cmUgb2YgdGhlIGNhbGxlciAodXNlciBpbiBhIGRlbGVnYXRlZCBjYXNlLCBhcHAg
aW4gYXBwLW9ubHkgZ3JhbnRzKS4gVGhlIGluZm9ybWF0aW9uIHRvIGRpc2NyaW1pbmF0ZSBiZXR3
ZWVuIHVzZXIgYW5kIGFwcCBjYWxsZXJzIGlzIGFsd2F5cyBhdmFpbGFibGUgaW4gdGhlIHRva2Vu
IChzYXksIHRoZSBjYWxsZXIgaXMgYSB1c2VyIGlmIHN1YiE9Y2xpZW50X2lkLA0KIHdoZXJlIGNs
aWVudF9pZCBpcyBhbHdheXMgZ3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGFzIHdlbGwpIGhlbmNl
IHRoZXJlJ3Mgbm8gbG9zcyBpbiBleHByZXNzaXZlIHBvd2VyLCBzaG91bGQgdGhhdCBkaWZmZXJl
bmNlIGJlIHJlbGV2YW50IGZvciB0aGUgcmVzb3VyY2Ugc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9taW5pY2ssIEhhbnMt
IEkgcHJvYmFibHkgbWlzc2VkIHRoZSBzZWN1cml0eSBpc3N1ZSB5b3UgZ3V5cyBhcmUgdGhpbmtp
bmcgb2YgaW4gdGhpcyBjYXNlLiBPZiBjb3Vyc2UsIGlmIHRoaXMgd291bGQgaW50cm9kdWNlIGEg
cmlzayBJIGNvbXBsZXRlbHkgYWdyZWUgaXQgc2hvdWxkIGJlIGNoYW5nZWQtIEknZA0KIGp1c3Qg
bGlrZSB0byB1bmRlcnN0YW5kIGJldHRlciB0aGUgcHJvYmxlbS4gQ291bGQgeW91IGV4cGFuZCBp
dCBpbiBhIHNjZW5hcmlvL3VzZSBjYXNlIHRvIGNsYXJpZnkgdGhlIHJpc2s/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vdi0gcGxheWluZyB0
aGlzIGJhY2s6IGlzIHRoZSBjb25jZXJuIHRoYXQgYSB1c2VyIGFuZCBhIGNsaWVudCBtaWdodCBo
YXZlIHRoZSBzYW1lIGlkZW50aWZpZXIgd2l0aGluIGFuIElEUD8gV2hlbiB1c2luZyBjb2xsaXNp
b24gcmVzaXN0YW50IElEcywgYXMgaXQgaXMgdXN1YWxseSB0aGUgY2FzZSwgdGhhdA0KIHNlZW1z
IHRvIGJlIGEgcmVtb3RlIHBvc3NpYmlsaXR5LSBkaWQgeW91IHN0dW1ibGUgaW4gc3VjaCBzY2Vu
YXJpbyBpbiBwcm9kdWN0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlYuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBNYXIgMjUsIDIw
MTkgYXQgNzo0NCBBTSBIYW5zIFphbmRiZWx0ICZsdDs8YSBocmVmPSJtYWlsdG86aGFucy56YW5k
YmVsdEB6bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9u
ZS5ldTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgdGhlcmUgYXJlIHBsZW50eSBvZiBPQXV0aCAyLjAg
b25seSB1c2UgY2FzZXMgb3V0IHRoZXJlLi4uIGJ1dCBuZXZlcnRoZWxlc3MgSSBhZ3JlZSB3aXRo
IHRoZSBwb3RlbnRpYWwgY29uZnVzaW9uIGFuZCB0aHVzIHNlY3VyaXR5IHByb2JsZW1zIGFyaXNp
bmcgZnJvbSB0aGF0ICh0aG91Z2ggb25lDQogbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRo
ZSBzYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5IYW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+T24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMzozOSBQTSBEb21pbmljayBCYWllciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2Js
YW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5ZZXMgSSBrbm93IC0gYW5kIEkgdGhpbmsgaW4gaGluZHNpZ2h0IGl0IHdhcyBhIG1pc3Rh
a2UgdG8gdXNlIHRoZSBzYW1lIGNsYWltIHR5cGUgZm9yIG11bHRpcGxlIHNlbWFudGljcy48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BbGwgdGhl
IOKAnHRoaXMgaXMgT0lEQyBub3QgT0F1dGjigJ0gYXJndW1lbnRzIGFyZSBtYWtpbmcgdGhpbmdz
IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGV5IG5lZWQgdG8gYmUgLSBpbiBteSBleHBlcmllbmNl
DQogYWxtb3N0IG5vLW9uZSAodGhhdCBJIGtub3cpIGRvZXMgT0lEQyBvbmx5IC0gbm9yIE9BdXRo
IG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gcmVhbGl0eSB0aGlzIGxlYWRzIHRvIHBvdGVu
dGlhbCBzZWN1cml0eSBwcm9ibGVtcyAtIHRoaXMgc3BlYyBoYXMgdGhlIHBvdGVudGlhbCB0byBy
ZWN0aWZ5IHRoZSBzaXR1YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp
bi1ib3R0b206MTIuMHB0Ij5Eb21pbmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWls
LW00NjA4OTYyMzY5ODc3OTY3MjA0Z21haWwtbS03MDQ1NTQ1OTQ1ODczNTMyMDU5Z21haWwtbS0x
NzA3Nzk5MzMyODgwNTc3NjJnbWFpbC1tNTE5ODAwNjA2NDE4NjAyMTQwN2dtYWlsLW0tMTg2MTQ5
Mjk3NjA5ODI1Mzg0M2dtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1
MTUxMDY4MTdhaXJtYWlsb24iPg0KT24gMjUuIE1hcmNoIDIwMTkgYXQgMTQ6NTg6NTYsIEhhbnMg
WmFuZGJlbHQgKDxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFy
Z2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPikgd3JvdGU6PG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aG91dCBhZ3JlZWluZyBvciBkaXNhZ3JlZWluZzogT0lE
QyBkb2VzIG5vdCBhcHBseSBoZXJlIHNpbmNlIGl0IGlzIG5vdCBPQXV0aCBhbmQgYW4gYWNjZXNz
IHRva2VuIGlzIG5vdCBhbiBpZF90b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIEpXVCBzcGVjIHNheXMgaW4NCjxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNC4xLjIiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4y
PC9hPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
cXVvdDtUaGUgJnF1b3Q7c3ViJnF1b3Q7IChzdWJqZWN0KSBjbGFpbSBpZGVudGlmaWVzIHRoZSBw
cmluY2lwYWwgdGhhdCBpcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3N1YmplY3Qgb2YgdGhlIEpXVC4mbmJzcDsg
VGhlIGNsYWltcyBpbiBhIEpXVCBhcmUgbm9ybWFsbHkgc3RhdGVtZW50czxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YWJv
dXQgdGhlIHN1YmplY3QuJm5ic3A7IFRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0aGVyIGJlIHNj
b3BlZCB0byBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsgJm5ic3A7bG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhl
IGlzc3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtUaGUgcHJvY2Vzc2luZyBv
ZiB0aGlzIGNsYWltIGlzIGdlbmVyYWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYyZxdW90OzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d2hp
Y2gga2luZCBvZiBzcGVsbHMgJnF1b3Q7Y2xpZW50JnF1b3Q7IGluIGNhc2Ugb2YgdGhlIGNsaWVu
dCBjcmVkZW50aWFscyBncmFudCBidXQgSSBhbHNvIGRvIHdvcnJ5IGFib3V0IFJlc291cmNlIFNl
cnZlcnMgdGhpbmtpbmcvYWN0aW5nIG9ubHkgaW4gdGVybXMgb2YgdXNlcnM8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhhbnMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+T24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMjo0MSBQTSBEb21pbmljayBCYWll
ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0i
X2JsYW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5JTUhPIHRoZSBzdWIgY2xhaW0gc2hvdWxkIGFsd2F5cyByZWZlciB0byB0aGUgdXNl
ciAtIGFuZCBub3RoaW5nIGVsc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+T0lEQyBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlN1
YmplY3QgLSBJZGVudGlmaWVyIGZvciB0aGUgRW5kLVVzZXIgYXQNCiB0aGUgSXNzdWVyLiZxdW90
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPmNsaWVudF9pZCBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSBjbGllbnRzLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Y2hlZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkRvbWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTQ2MDg5NjIzNjk4Nzc5
NjcyMDRnbWFpbC1tLTcwNDU1NDU5NDU4NzM1MzIwNTlnbWFpbC1tLTE3MDc3OTkzMzI4ODA1Nzc2
MmdtYWlsLW01MTk4MDA2MDY0MTg2MDIxNDA3Z21haWwtbS0xODYxNDkyOTc2MDk4MjUzODQzZ21h
aWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04
NDc1NzI4NjU2MjQ1NDkyNDk1YWlybWFpbG9uIj4NCk9uIDI1Li4gTWFyY2ggMjAxOSBhdCAwNTox
MzowMywgTm92IE1hdGFrZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5jb20iIHRhcmdl
dD0iX2JsYW5rIj5tYXRha2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBWaXR0b3JpbywNCjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3Ig
dGhlIGdvb2Qgc3RhcnRpbmcgcG9pbnQgb2Ygc3RhbmRhcmRpemluZyBKV1QtaXplZCBBVC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u
ZSBmZWVkYmFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+VGhlIOKAnHN1YuKAnSBjbGFpbSBjYW4gaW5jbHVkZSAyIHR5cGVzIG9mIGlkZW50
aWZpZXIsIGVuZC11c2VyIGFuZCBjbGllbnQsIGluIHRoaXMgc3BlYy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgcmVxdWlyZXMgdGhvc2Ug
MiB0eXBlcyBvZiBpZGVudGlmaWVycyB0byBiZSB1bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQ
IGNvbnRleHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5JIHByZWZlciBvbWl0dGluZyDigJxzdWLigJ0gY2xhaW0gaW4gMi1sZWdnZWQg
Y29udGV4dCwgc28gdGhhdCBubyBzdWNoIGNvbnN0cmFpbnQgbmVlZGVkLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhhbmtzPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ub3Y8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBN
YXIgMjUsIDIwMTksIGF0IDg6MjksIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWls
dG86dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj52aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+RGVhciBhbGwsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkkganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBkZXNjcmliaW5nIGEg
SldUIHByb2ZpbGUgZm9yIE9BdXRoIDIuMCBhY2Nlc3MgdG9rZW5zLiBZb3UgY2FuIGZpbmQgaXQg
aW4mbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i
ZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tl
bi1qd3QvPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+SSBoYXZlIGEgc2xvdCB0byBkaXNjdXNzIHRoaXMgdG9tb3Jyb3cgYXQgSUVURiAx
MDQgKEknbGwgYmUgcHJlc2VudGluZyByZW1vdGVseSkuIEkgbG9vayBmb3J3YXJkIGZvciB5b3Vy
IGNvbW1lbnRzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SGVyZSdzIGp1c3QgYSBiaXQgb2YgYmFja3N0b3J5LCBpbiBjYXNlIHlvdSBh
cmUgaW50ZXJlc3RlZCBpbiBob3cgdGhpcyBkb2MgY2FtZSB0byBiZS4gVGhlIHRyYWplY3Rvcnkg
aXQgZm9sbG93ZWQgaXMgc29tZXdoYXQgdW51c3VhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPg0KRGVzcGl0ZSBPQXV0aDIgbm90IHJlcXVpcmluZyBhbnkgc3BlY2lm
aWMgZm9ybWF0IGZvciBBVHMsIHRocm91Z2ggdGhlIHllYXJzIEkgaGF2ZSBjb21lIGFjcm9zcyBt
dWx0aXBsZSBwcm9wcmlldGFyeSBzb2x1dGlvbiB1c2luZyBKV1QgZm9yIHRoZWlyIGFjY2VzcyB0
b2tlbi4gVGhlIGludGVudCBhbmQgc2NlbmFyaW9zIGFkZHJlc3NlZCBieSB0aG9zZSBzb2x1dGlv
bnMgYXJlIG1vc3RseSB0aGUgc2FtZSBhY3Jvc3MgdmVuZG9ycywgYnV0IHRoZQ0KIHN5bnRheCBh
bmQgaW50ZXJwcmV0YXRpb25zIGluIHRoZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGRpZmZlcmVudCBl
bm91Z2ggdG8gcHJldmVudCBkZXZlbG9wZXJzIGZyb20gcmV1c2luZyBjb2RlIGFuZCBza2lsbHMg
d2hlbiBtb3ZpbmcgZnJvbSBwcm9kdWN0IHRvIHByb2R1Y3QuPG86cD48L286cD48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSSBhc2tlZCBzZXZl
cmFsIGluZGl2aWR1YWxzIGZyb20ga2V5IHByb2R1Y3RzIGFuZCBzZXJ2aWNlcyB0byBzaGFyZSB3
aXRoIG1lIGNvbmNyZXRlIGV4YW1wbGVzIG9mIHRoZWlyIEpXVCBhY2Nlc3MgdG9rZW5zIChUSEFO
SyBZT1UgRG9taW5pY2sgQmFpZXIgKElkZW50aXR5U2VydmVyKSwmbmJzcDs8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+QnJpYW4gQ2FtcGJlbGwgKFBpbmdJZGVudGl0eSksIERhbmllbCBE
b2JhbGlhbiAoTWljcm9zb2Z0KSwgS2FybA0KIEd1aW5uZXNzIChPa3RhKSBmb3IgdGhlIHRva2Vu
cyBhbmQgZXhwbGFuYXRpb25zITwvc3Bhbj4pLjxicj4NCkkgc3R1ZGllZCBhbmQgY29tcGFyZWQg
YWxsIHRob3NlIGluc3RhbmNlcywgaWRlbnRpZnlpbmcgY29tbW9uYWxpdGllcyBhbmQgZGlmZmVy
ZW5jZXMuJm5ic3A7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSSBwdXQgdG9nZXRoZXIgYSBwcmVzZW50YXRpb24gc3VtbWFy
aXppbmcgbXkgZmluZGluZ3MgYW5kIHN1Z2dlc3RpbmcgYSByb3VnaCBpbnRlcm9wZXJhYmxlIHBy
b2ZpbGUgKHNsaWRlczoNCjxhIGhyZWY9Imh0dHBzOi8vc2VjLi51bmktc3R1dHRnYXJ0LmRlL19t
ZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9h
dHMucHB0eCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9zZWMudW5pLXN0dXR0Z2FydC5kZS9f
bWVkaWEvZXZlbnRzL29zdzIwMTkvc2xpZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJvZmlsZV9mb3Jf
YXRzLnBwdHg8L2E+ICkgLSBnb3QgZWFybHkgZmVlZGJhY2sgZnJvbSBGaWxpcCBTa29rYW4gb24g
aXQuIFRoeCBGaWxpcCE8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t
bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgcHJlc2VudGF0aW9uIHdhcyBmb2xsb3dlZCB1cCBi
eSAxLjUgaG91cnMgb2YgdW5jb25mZXJlbmNlIGRpc2N1c3Npb24sIHdoaWNoIHdhcyBpbmNyZWRp
Ymx5IHZhbHVhYmxlIHRvIGdldCB0aWdodC1sb29wIGZlZWRiYWNrIGFuZCBpbmNvcnBvcmF0ZSBu
ZXcgaWRlYXMuIEpvaG4gQnJhZGxleSwgQnJpYW4gQ2FtcGJlbGwgVmxhZGltaXIgRHpodXZpbm92
LCBUb3JzdGVuIExvZGRlcnN0ZWR0LDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz
cDtOYXQNCiBTYWtpbXVyYSwgSGFubmVzIFRzY2hvZmVuaWc8L3NwYW4+Jm5ic3A7d2VyZSBhbGwg
dGhlcmUgYW5kIGNvbnRyaWJ1dGVkIGdlbmVyb3VzbHkgdG8gdGhlIGRpc2N1c3Npb24uIFRoYW5r
IHlvdSEhITxicj4NCk5vdGU6IGlmIHlvdSB3ZXJlIGF0IE9TVzIwMTksIHBhcnRpY2lwYXRlZCBp
biB0aGUgZGlzY3Vzc2lvbiBhbmQgZGlkbid0IGdldCBjcmVkaXRlZCBpbiB0aGUgZHJhZnQsIG15
IGFwb2xvZ2llczogcGxlYXNlIHNlbmQgbWUgYSBub3RlIGFuZCBJJ2xsIG1ha2UgdGhpbmdzIHJp
Z2h0IGF0IHRoZSBuZXh0IHVwZGF0ZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpPbiBteSBmbGlnaHQgYmFjayBJIGRpZCBt
eSBiZXN0IHRvIGluY29ycG9yYXRlIGFsbCB0aGUgaWRlYXMgYW5kIGZlZWRiYWNrIGluIGEgZHJh
ZnQsIHdoaWNoIHdpbGwgYmUgZGlzY3Vzc2VkIGF0IElFVEYxMDQgdG9tb3Jyb3cuIFJpZmFhdCwg
SGFubmVzIGFuZCBhYm92ZSBhbGwgQnJpYW4gd2VyZSBhbGwgc3VwZXIgaGVscGZ1bCBpbiBuZWdv
dGlhdGluZyB0aGUgbXlzdGVyaW91cyBzeW50YXggb2YgdGhlIFJGQyBmb3JtYXQgYW5kIHN1Ym1p
c3Npb24NCiBwcm9jZXNzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SSB3YXMgYmxvd24gYXdheSBieSB0aGUgYXZhaWxhYmlsaXR5LCBpbnZvbHZl
bWVudCBhbmQgd2lsbGluZ25lc3MgdG8gaW52ZXN0IHRpbWUgdG8gZ2V0IHRoaW5ncyByaWdodCB0
aGF0IGV2ZXJ5b25lIGRlbW9uc3RyYXRlZCBpbiB0aGUgcHJvY2Vzcy4gVGhpcyBpcyBhbiBhbWF6
aW5nIGNvbW11bml0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5WLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1
dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRi
ZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25l
LmV1PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0g
LQ0KPGEgaHJlZj0iaHR0cDovL3d3dy56bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj53d3cu
em1hcnR6b25lLmV1PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5l
dSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLQ0KPGEgaHJlZj0iaHR0
cDovL3d3dy56bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj53d3cuem1hcnR6b25lLmV1PC9h
Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+VmVubmxpZyBoaWxzZW48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzIy
MjIyMiI+U3RlaW5hciBOb2VtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+UGFydG5l
ciBVZGVsdCBBUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPlN5c3RlbXV0dmlrbGVy
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzIyMjIyMiI+fCZuYnNwOzxhIGhyZWY9Im1haWx0bzpzdGVpbmFyQHVkZWx0Li5ubyIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6I0ZG
RkZDQyI+c3RlaW5hckB1ZGVsdC5ubzwvc3Bhbj48L2E+Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Im1h
aWx0bzpoZWlAdWRlbHQubm8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzEx
NTVDQyI+aGVpQHVkZWx0Lm5vPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDt8Jm5ic3A7JiM0Mzs0Nw0K
IDk1NSAyMSA2MjAmbmJzcDt8Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy51ZGVsdC5uby8iIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+d3d3LnVkZWx0Lm5vPC9z
cGFuPjwvYT4mbmJzcDt8Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpv
bmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5abWFydFpvbmUgSUFNIC0NCjxhIGhyZWY9
Imh0dHA6Ly93d3cuem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+d3d3LnptYXJ0em9uZS5l
dTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286
cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48
L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0
em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLQ0KPGEgaHJl
Zj0iaHR0cDovL3d3dy56bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj53d3cuem1hcnR6b25l
LmV1PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJl
bHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUu
ZXU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0Wm9uZSBJQU0gLSA8
YSBocmVmPSJodHRwOi8vd3d3LnptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPg0Kd3d3Lnpt
YXJ0em9uZS5ldTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_SN6PR00MB030459810B40D98370728BBAF5500SN6PR00MB0304namp_--


From nobody Thu Apr  4 13:11:34 2019
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 9AB19120132 for ; Thu,  4 Apr 2019 13:11:32 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=zmartzone-eu.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 iCdDRiZe55do for ; Thu,  4 Apr 2019 13:11:28 -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 CA8391200B2 for ; Thu,  4 Apr 2019 13:11:27 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id d13so4841866qth.5 for ; Thu, 04 Apr 2019 13:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YqwOihLXlEein2Oy/y+yNqoiasuKo+mZ22B+ADd44l0=; b=g6Vbl5SKCG+PkJJES3AHjirm9MjlgnJZbA7gZaqbBqv1Wi7141EkA/lVn4OXYtdNIf 7sSe9PY6SKHs2V7n0q9EJvWiA+TWNKP8ZU6XnUikn4U/l/7cxlIRuNvSKx2ipifI7saY pO+gC1QdVW75GDkvREObURljk0vH6KwgjBFP9ycyZ+QpHZQ7sVZQtCw6QwCz+eKhUHqC ToPb6pNscRSAxuDwHIxX2BLPzbIV/nwct/whTVJEl1jmZnKXLEb7L6n+KjjWmcHDzh4Q Xh70rlBSueUAS5zflHFN5dkUdnzj/Hjw9TQ8z/aybk02+7T+ToyqlZ5Z5x/9GyQmDIxq SUyQ==
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=YqwOihLXlEein2Oy/y+yNqoiasuKo+mZ22B+ADd44l0=; b=FVctCyEFxH6Z3VBuODF7XLR8Ir0lXjWRD1/xwSBXBHKm8e3DFlDYNq7rOC4sljayHJ HuYm+ZKqxQKWEJ7mb83KwXFFndVHmPyJe195N8JNciYa/VoXQL6o/q/+4dqESI67V46k rglf/7YwSVnrtpCfi7KciNyfeRSQ7sFZRcYly9VGCHbtEbo8A+lVsYPMV9PN2nQtMunr QeJDO+sdGDTZ00iH9fmcYTXX7LqN6lec17VUM3JxFSlaS4+qlqmMTkXX4deew+ppX2im A2MUuNG65tzwtseTjY/3rVDNufo1ub3ZaJkDrTPQuVb0pubWijQnQW60zNtyDk7QMFbm dbPQ==
X-Gm-Message-State: APjAAAWQSdDfwifLJBknn2q1aBnDbU30BNiZIdCmkTYK9g7E2jDm7n+R RTKqiIc1V/+eOjDNfZt8WWhSwdN24YO5TzLh8px1IVfP
X-Google-Smtp-Source: APXvYqwFhQT4EbBQ8WzaXmHfMB/HyZuo+z32YAGWZnggKK00BfFGhj/Kd8R6dUrbhpCWAsy+UFssmZXxxF7Kcsclg5I=
X-Received: by 2002:a0c:b753:: with SMTP id q19mr6745536qve.69.1554408686782;  Thu, 04 Apr 2019 13:11:26 -0700 (PDT)
MIME-Version: 1.0
References:               <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com>   
In-Reply-To: 
From: Hans Zandbelt 
Date: Thu, 4 Apr 2019 22:11:15 +0200
Message-ID: 
To: Mike Jones 
Cc: George Fletcher ,  Vittorio Bertocci , IETF oauth WG 
Content-Type: multipart/alternative; boundary="0000000000009ca2290585b9f97f"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 04 Apr 2019 20:11:33 -0000

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

I also meant to say that (of course) the JWT standard doesn't say that the
JWT is supposed to be about the client or about the resource owner, hence
both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones 
wrote:

> I get that existing practice is likely to be all over the map, but if
> we=E2=80=99re to create a JWT access token standard, it=E2=80=99s reasona=
ble to require
> that the claims usage comply with the JWT standards.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Hans Zandbelt 
> *Sent:* Thursday, April 4, 2019 12:59 PM
> *To:* Mike Jones 
> *Cc:* George Fletcher ; Vittorio
> Bertocci ; IETF oauth WG <
> oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> the definition of RFC 7519 is actually "petitio principii" and a lot of
> deployments put claims about the Resource Owner in the access token (as a
> Resource Server implementer I've suffered a lot from this)
>
>
>
> Hans.
>
>
>
> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones 
> wrote:
>
> I agree with George that the subject of a token must be the principal of
> that token.  That what the JWT =E2=80=9Csub=E2=80=9D claim is for.  Indee=
d, the first
> sentence of the =E2=80=9Csub=E2=80=9D definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>
> The "sub" (subject) claim identifies the principal that is the subject of
> the JWT.
>
>
>
> If an access token uses =E2=80=9Csub=E2=80=9D, its usage must comply with=
 the definition
> from RFC 7519.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt 
> *Cc:* Vittorio Bertocci ; IETF oau=
th
> WG 
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> The more I think about this the more I land in the "No" camp.
>
> The subject of a token should be the principal of that token. It shouldn'=
t
> matter whether that is a machine, a user, or a device. Trying to separate
> out "humans" as a special class will just make things more complicated. I=
f
> we need a claim to identify the subject is a "human" then why not just ad=
d
> that. This doesn't break anything and makes it easy for people to detect
> this case in those use cases where it's required.
>
> Thanks,
> George
>
> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
>
> I will argue that in a way such deployments are already broken e.g. in th=
e
> typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for
> that.
>
>
>
> Hans.
>
>
>
> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher  wrote:
>
> I agree that this will break a lot of existing flows... especially those
> using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
>
> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
>
> great summary! this will hurt quite a few existing m2m deployments but I
> do like the rigidness of it all: it is very explicit, cannot misinterpret=
ed
> and thus prevents failure (which is really what Dominick is after); I'm o=
n
> board
>
>
>
> Hans.
>
>
>
> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci  40auth0.com@dmarc.ietf.org> wrote:
>
> thank you Steinar and everyone else for the comments on this!
>
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
> Bertrand recommend using sub only for users. Martin would like to have th=
e
> sub for app only flows as well. Hans is neutral.
>
> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more tim=
e
> to comment as well.
>
> Clarification. If the goal is to be able to apply the logic "if there's a
> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
> of sub when that's not the case. Are all OK with it?
>
>
>
> Dave, the suggestion of having explicit typing for app only vs user only
> is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getti=
ng
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
>
>
>
> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem  wrote:
>
> Hi Vittorio, we  (the national federation-gateway for the health services
> in norway - "HelseID")  think his is a really valuable initiative!
>
> We also agree with Dominick concerning definition of the "sub" claim.
>
>
>
> Steinar
>
>
>
> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dbaier@leastprivilege.com>:
>
> From an access token consumer (aka API) developer point of view, I prefer
> this logic
>
>
>
> "If sub is present - client acts on behalf of a user, if not - not."
>
>
>
> Anything more complicated has a potential of going wrong.
>
>
>
> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:
>
> Hi Vittorio,
>
>
>
> Yeah, I=E2=80=99m concerning user & client ids collision.
>
> I haven=E2=80=99t seen such implementations, but user-select username as =
sub, or
> incremental integer as sub & client_id will be easily collide.
>
>
>
> If you can enforce collision resistant IDs between user & client
> instances, it=E2=80=99ll works fine. I feel its overkill though.
>
>
>
> Sent from my iPhone
>
>
> On Mar 26, 2019, at 8:51, Vittorio Bertocci  wrote:
>
> Hey Nov, Dominick, Hans-
>
> thanks for the comments. That was an area I was expecting to cause more
> discussion, and I am glad we are having this opportunity to clarify.
>
> The current language in the draft traces the etymology of sub to OpenID
> Connect core, hence Dominick observation is on point. However in the
> description I express something in line with 7519, which was in fact my
> intent.
>
>
>
> The idea was to provide an identifier of the calling subject that is
> guaranteed to be present in all cases- this would allow an SDK developer =
to
> use the same code for things like lookups and membership checks regardles=
s
> of the nature of the caller (user in a delegated case, app in app-only
> grants). The information to discriminate between user and app callers is
> always available in the token (say, the caller is a user if sub!=3Dclient=
_id,
> where client_id is always guaranteed to be present as well) hence there's
> no loss in expressive power, should that difference be relevant for the
> resource server.
>
>
>
> Dominick, Hans- I probably missed the security issue you guys are thinkin=
g
> of in this case. Of course, if this would introduce a risk I completely
> agree it should be changed- I'd just like to understand better the proble=
m.
> Could you expand it in a scenario/use case to clarify the risk?
>
> Nov- playing this back: is the concern that a user and a client might hav=
e
> the same identifier within an IDP? When using collision resistant IDs, as
> it is usually the case, that seems to be a remote possibility- did you
> stumble in such scenario in production?
>
>
>
> Thanks
>
> V.
>
>
>
>
>
> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt 
> wrote:
>
> I believe there are plenty of OAuth 2.0 only use cases out there... but
> nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
>
>
>
> Hans.
>
>
>
> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier 
> wrote:
>
> Yes I know - and I think in hindsight it was a mistake to use the same
> claim type for multiple semantics.
>
>
>
> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making thi=
ngs more
> complicated than they need to be - in my experience almost no-one (that I
> know) does OIDC only - nor OAuth only. They always combine it.
>
>
>
> In reality this leads to potential security problems - this spec has the
> potential to rectify the situation.
>
>
>
> Dominick
>
> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu)
> wrote:
>
> Without agreeing or disagreeing: OIDC does not apply here since it is not
> OAuth and an access token is not an id_token.
>
> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>
>
>
> "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"
>
>
>
> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
>
>
> Hans.
>
>
>
> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier 
> wrote:
>
> IMHO the sub claim should always refer to the user - and nothing else.
>
>
>
> OIDC says:
>
>
>
> "Subject - Identifier for the End-User at the Issuer."
>
>
>
> client_id should be used to identify clients.
>
>
>
> cheers
>
> Dominick
>
>
>
> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:
>
> Hi Vittorio,
>
>
>
> Thanks for the good starting point of standardizing JWT-ized AT.
>
>
>
> One feedback.
>
> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-us=
er and client, in
> this spec.
>
> It requires those 2 types of identifiers to be unique each other in the
> IdP context.
>
>
>
> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so tha=
t no such
> constraint needed.
>
>
>
> thanks
>
>
>
> nov
>
>
>
> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
>
>
>
> Dear all,
>
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
>
>
> Here's just a bit of backstory, in case you are interested in how this do=
c
> came to be. The trajectory it followed is somewhat unusual.
>
>    - Despite OAuth2 not requiring any specific format for ATs, through
>    the years I have come across multiple proprietary solution using JWT f=
or
>    their access token. The intent and scenarios addressed by those soluti=
ons
>    are mostly the same across vendors, but the syntax and interpretations=
 in
>    the implementations are different enough to prevent developers from re=
using
>    code and skills when moving from product to product.
>    - I asked several individuals from key products and services to share
>    with me concrete examples of their JWT access tokens (THANK YOU Domini=
ck
>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>    (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>    I studied and compared all those instances, identifying commonalities
>    and differences.
>    - I put together a presentation summarizing my findings and suggesting
>    a rough interoperable profile (slides:
>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a=
_jwt_profile_for_ats.pptx
>    
>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>    - The presentation was followed up by 1.5 hours of unconference
>    discussion, which was incredibly valuable to get tight-loop feedback a=
nd
>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov=
,
>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>    and contributed generously to the discussion. Thank you!!!
>    Note: if you were at OSW2019, participated in the discussion and
>    didn't get credited in the draft, my apologies: please send me a note =
and
>    I'll make things right at the next update.
>    - On my flight back I did my best to incorporate all the ideas and
>    feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa=
at,
>    Hannes and above all Brian were all super helpful in negotiating the
>    mysterious syntax of the RFC format and submission process.
>
> I was blown away by the availability, involvement and willingness to
> invest time to get things right that everyone demonstrated in the process=
.
> This is an amazing community.
>
> V.
>
> _______________________________________________
> 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
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> Vennlig hilsen
>
>
>
> Steinar Noem
>
> Partner Udelt AS
>
> Systemutvikler
>
>
>
> | steinar@udelt.no  | hei@udelt.no  | +47 955 21 620 |
> www.udelt.no |
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
>
>
> --
>
> hans.zandbelt@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
>


--=20
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu

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


I also meant to say that (of course) the JWT standard does=
n't say that the JWT is supposed to be about the client or about the re=
source owner, hence both are valid

Hans.

=

On Thu, Ap=
r 4, 2019 at 10:09 PM Mike Jones <Michael.Jones@microsoft.com> wrote:











I get that existi=
ng practice is likely to be all over the map, but if we=E2=80=99re to creat=
e a JWT access token standard, it=E2=80=99s reasonable to require that the =
claims usage comply with the JWT standards.


=C2=A0<=
/u>


=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
/u>


=C2=A0<=
/u>


From: Hans Zandbelt <hans.zandbelt@zmartzone.eu&g=
t; 

Sent: Thursday, April 4, 2019 12:59 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>; Vittorio Ber=
tocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF oauth WG <oauth@ietf.org>

Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<=
/u>


=C2=A0








the definition of RFC 7519 is actually "petitio=
 principii" and a lot of deployments put claims about the Resource Own=
er in the access token (as a Resource Server implementer I've suffered =
a lot from this)






=C2=A0






Hans.






=C2=A0






On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <Michael.Jones@mi=
crosoft.com> wrote:










I agree with Geor=
ge that the subject of a token must be the principal of that token.=C2=A0 T=
hat what the JWT =E2=80=9Csub=E2=80=9D claim is for.=C2=A0 Indeed, the firs=
t sentence
 of the =E2=80=9Csub=E2=80=9D definition at 
https://tools.ietf.org/html/rfc7519#section-4.1.2 is:<=
/u>



The "sub" (=
subject) claim identifies the principal that is the subject of the JWT.


=C2=A0<=
/u>


If an access toke=
n uses =E2=80=9Csub=E2=80=9D, its usage must comply with the definition fro=
m RFC 7519.


=C2=A0<=
/u>


=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike


=C2=A0<=
/u>






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of George Fletcher

Sent: Thursday, April 4, 2019 8:51 AM

To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>

Cc: Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org>; IETF o=
auth WG <oauth@ietf.=
org>

Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00<=
/u>






=C2=A0


The more I think about this the more I land in th=
e "No" camp.



The subject of a token should be the principal of that token. It shouldn=
9;t matter whether that is a machine, a user, or a device. Trying to separa=
te out "humans" as a special class will just make things more com=
plicated. If we need a claim to identify the subject
 is a "human" then why not just add that. This doesn't break =
anything and makes it easy for people to detect this case in those use case=
s where it's required.



Thanks,

George




On 4/3/19 4:56 PM, Hans Zandbelt wrote:








I will argue that in a way such deployments are alre=
ady broken e.g. in the typical use case of onboarding client accounts in th=
e same directory/OU/namespace as user accounts and
 we don't need to cater for that. 




=C2=A0






Hans.






=C2=A0






On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <=
gffletch@aol.com&=
gt; wrote:








I agree that this will break a lot of existing fl=
ows... especially those using any form of the client_credentials flow. In t=
hat sense
 I'm not completely on board yet :)




On 3/26/19 12:56 PM, Hans Zandbelt wrote:<=
/u>










great summary! this will hurt quite a few existing m=
2m deployments but I do like the rigidness of it all: it is very explicit, =
cannot misinterpreted and thus prevents failure (which
 is really what Dominick is after); I'm on board 




=C2=A0






Hans.






=C2=A0






On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci &l=
t;Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:








thank you Steinar and everyone else for the comments=
 on this!





To summarize the situation so far: Dominick, Steinar=
, Rob, David, Nov, Bertrand recommend using sub only for users. Martin woul=
d like to have the sub for app only flows as well.
 Hans is neutral.






That does sound like the sub as user has more consen=
sus, tho before changing it I'd wait for the people currently at IETF10=
4 to have more time to comment as well.






Clarification. If the goal is to be able to apply th=
e logic "if there's a sub, it's a user flow", we have to =
explicitly disallow (MUST NOT) the use of sub when that's not the case.
 Are all OK with it?






=C2=A0






Dave, the suggestion of having explicit typing for a=
pp only vs user only is interesting! For the purpose of putting together an=
 interoperable profile, tho, I would suggest we table
 it for v1 in the interest of getting to something easy to adopt (hence wit=
h small delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0






=C2=A0






On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no>=
 wrote:








Hi Vittorio, we=C2=A0 (the national federation-gatew=
ay for the health services in norway - "HelseID")=C2=A0 think his=
 is a really valuable initiative!





We also agree with Dominick concerning definition of=
 the "sub" claim.






=C2=A0






<mvh>Steinar</mvh>






=C2=A0






tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier &l=
t;dbaier@lea=
stprivilege.com>:










From an access token consumer (aka API) developer point of view=
, I prefer this logic






=C2=A0






"If sub is present - client acts on behalf of a user, if n=
ot - not."






=C2=A0






Anything more complicated has a potential of going wrong.




=C2=A0


On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:












Hi Vittorio,






=C2=A0






Yeah, I=E2=80=99m concerning user & client ids c=
ollision.






I haven=E2=80=99t seen such implementations, but use=
r-select username as sub, or incremental integer as sub & client_id wil=
l be easily collide.






=C2=A0






If you can enforce collision resistant IDs between u=
ser & client instances, it=E2=80=99ll works fine. I feel its overkill t=
hough.








=C2=A0




Sent from my iPhone








On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:










Hey Nov, Dominick, Hans-





thanks for the comments. That was an area I was expe=
cting to cause more discussion, and I am glad we are having this opportunit=
y to clarify.






The current language in the draft traces the etymolo=
gy of sub to OpenID Connect core, hence Dominick observation is on point. H=
owever in the description I express something in line
 with 7519, which was in fact my intent.






=C2=A0






The idea was to provide an identifier of the calling=
 subject that is guaranteed to be present in all cases- this would allow an=
 SDK developer to use the same code for things like
 lookups and membership checks regardless of the nature of the caller (user=
 in a delegated case, app in app-only grants). The information to discrimin=
ate between user and app callers is always available in the token (say, the=
 caller is a user if sub!=3Dclient_id,
 where client_id is always guaranteed to be present as well) hence there=
9;s no loss in expressive power, should that difference be relevant for the=
 resource server.






=C2=A0






Dominick, Hans- I probably missed the security issue=
 you guys are thinking of in this case. Of course, if this would introduce =
a risk I completely agree it should be changed- I'd
 just like to understand better the problem. Could you expand it in a scena=
rio/use case to clarify the risk?






Nov- playing this back: is the concern that a user a=
nd a client might have the same identifier within an IDP? When using collis=
ion resistant IDs, as it is usually the case, that
 seems to be a remote possibility- did you stumble in such scenario in prod=
uction?






=C2=A0






Thanks






V.=C2=A0






=C2=A0






=C2=A0






On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt=
@zmartzone.eu> wrote:










I believe there are plenty of OAuth 2.0 only use cas=
es out there... but nevertheless I agree with the potential confusion and t=
hus security problems arising from that (though one
 may argue the semantics are the same).






=C2=A0




Hans.






=C2=A0






On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <<=
a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp=
rivilege.com> wrote:










Yes I know - and I think in hindsight it was a mistake to use t=
he same claim type for multiple semantics.






=C2=A0






All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are =
making things more complicated than they need to be - in my experience
 almost no-one (that I know) does OIDC only - nor OAuth only. They always c=
ombine it.






=C2=A0






In reality this leads to potential security problems - this spe=
c has the potential to rectify the situation.






=C2=A0




Dominick<=
/p>


On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:
















Without agreeing or disagreeing: OIDC does not apply=
 here since it is not OAuth and an access token is not an id_token.<=
u>







=C2=A0




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






=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in=
 a JWT are normally statements






=C2=A0 =C2=A0about the subject.=C2=A0 The subject va=
lue MUST either be scoped to be






=C2=A0 =C2=A0locally unique in the context of the is=
suer or be globally unique.






=C2=A0 =C2=A0The processing of this claim is general=
ly application specific"






=C2=A0






which kind of spells "client" in case of t=
he client credentials grant but I also do worry about Resource Servers thin=
king/acting only in terms of users






=C2=A0






Hans.










=C2=A0






On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <<=
a href=3D"mailto:dbaier@leastprivilege.com" target=3D"_blank">dbaier@leastp=
rivilege.com> wrote:










IMHO the sub claim should always refer to the user - and nothin=
g else.






=C2=A0






OIDC says:






=C2=A0






"Subject - Identifier for the End-User at
 the Issuer."






=C2=A0






client_id should be used to identify clients.=







=C2=A0






cheers






Dominick




=C2=A0



On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:








Hi Vittorio,





=C2=A0






Thanks for the good starting point of standardizing =
JWT-ized AT.






=C2=A0






One feedback.






The =E2=80=9Csub=E2=80=9D claim can include 2 types =
of identifier, end-user and client, in this spec.






It requires those 2 types of identifiers to be uniqu=
e each other in the IdP context.






=C2=A0






I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-l=
egged context, so that no such constraint needed.






=C2=A0






thanks






=C2=A0






nov








=C2=A0





On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:




=C2=A0










Dear all,





I just submitted a draft describing a JWT profile fo=
r OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/<=
/a>.






I have a slot to discuss this tomorrow at IETF 104 (=
I'll be presenting remotely). I look forward for your comments!<=
u>






=C2=A0






Here's just a bit of backstory, in case you are =
interested in how this doc came to be. The trajectory it followed is somewh=
at unusual.









I was blown away by the availability, involvement an=
d willingness to invest time to get things right that everyone demonstrated=
 in the process. This is an amazing community.=C2=A0








V.










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth








=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













=C2=A0




--















ZmartZone IAM -
www.zmartzone.eu<=
/span>



































=C2=A0




--















ZmartZone IAM -
www.zmartzone.eu<=
/span>






































_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













=C2=A0




--













Vennlig hilsen






=C2=A0<=
/u>








Steinar 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=A0=
www.udelt.no=C2=A0|=C2=A0


















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













=C2=A0




--
















ZmartZone IAM -
www.zmartzone.eu<=
/span>
















=C2=A0

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0















=C2=A0




--
















ZmartZone IAM -
www.zmartzone.eu<=
/span>
















=C2=A0

















=C2=A0




-- 












-- 


--0000000000009ca2290585b9f97f--


From nobody Thu Apr  4 13:20:38 2019
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 064681200B2 for ; Thu,  4 Apr 2019 13:20:35 -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, HTML_MESSAGE=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 KRtRw4b7r5e5 for ; Thu,  4 Apr 2019 13:20:30 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 512BB12013F for ; Thu,  4 Apr 2019 13:20:30 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x34KKVnN009562 for ; Thu, 4 Apr 2019 16:20:31 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 4 Apr 2019 16:19:35 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 4 Apr 2019 16:20:28 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 4 Apr 2019 16:20:28 -0400
From: Justin Richer 
To: oauth 
Thread-Topic: MTLS and SAN
Thread-Index: AQHU6yPYeeBaFjv2GU6wVOU/HAbP4A==
Date: Thu, 4 Apr 2019 20:20:28 +0000
Message-ID: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_220488FBC7EB42A385D6BD3756786550mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG] MTLS and SAN
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, 04 Apr 2019 20:20:35 -0000

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

V2XigJl2ZSBqdXN0IHN0YXJ0ZWQgaW1wbGVtZW50YXRpb24gb2YgU0FOLWJhc2VkIGNlcnRpZmlj
YXRlIGF1dGhlbnRpY2F0aW9uLCBiYXNlZCBvbiB0aGUgY2hhbmdlcyBpbiB2ZXJzaW9uIC0xMyBv
ZiB0aGUgZHJhZnQuIEkgYmVsaWV2ZSB0aGlzIGFkZGl0aW9uIGlzIGEgYml0IHVuY2xlYXIsIGR1
ZSB0byBpdCBiZWluZyBhZGRlZCBzbyBsYXRlIGluIHRoZSBkb2N1bWVudCBwcm9jZXNzLg0KDQpN
eSBxdWVzdGlvbiBpcyBob3cgZG9lcyBhbiBBUyBkZXRlcm1pbmUgd2hldGhlciB0byBETiBvciBT
QU4gZm9yIGNlcnRpZmljYXRlIGNoZWNraW5nPyBDb3JvbGxhcnksIGFyZSB0aGVzZSBtdXR1YWxs
eSBleGNsdXNpdmUgb3IgY2FuIHRoZXkgYmUgdXNlZCB0b2dldGhlcj8gQ3VycmVudGx5LCB0aGUg
c3BlY2lmaWNhdGlvbiB0ZXh0IGxpc3RzIEROIGFuZCBTQU4gYXMgYW4g4oCcb3LigJ0gd2l0aCBu
byBpbmRpY2F0aW9uIHdoZXRoZXIgdGhpcyBpcyBhbiBpbmNsdXNpdmUgb3IgZXhjbHVzaXZlIOKA
nG9y4oCdLCBhbmQgd2hhdCB0byBkbyB3aGVuIHRoZXJl4oCZcyBvdmVybGFwLg0KDQpUaGlzIGhh
cyBpbXBsaWNhdGlvbnMgYm90aCBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzZXJ2ZXIg
cHJvY2Vzc2luZyB0aGUgcmVxdWVzdCBhcyB3ZWxsIGFzIHRoZSBjbGllbnQgbWV0YWRhdGEgbW9k
ZWwsIHNpbmNlIHRoZSBjbGllbnQgZmllbGRzIGFyZSBhbGwgaW4gcGFyYWxsZWwgdG8gZWFjaCBv
dGhlci4gSSBjYW4gc2VlIGEgZmV3IHdheXMgb2YgaGFuZGxpbmcgdGhpcy4NCg0KDQoxKSBPbmUg
b2YgdGhlIGZpZWxkcyB0YWtlcyBwcmVjZWRlbmNlIG92ZXIgdGhlIG90aGVyLiBTYXkgZm9yIGV4
YW1wbGUgeW91IGNob29zZSB0aGUgRE4gZmllbGQ6IGlmIGl04oCZcyBzZXQsIHRoZW4geW91IGRv
IEROIG1hdGNoaW5nIGFuZCBpZ25vcmUgdGhlIFNBTiBmaWVsZHMgZW50aXJlbHksIGJvdGggaW4g
dGhlIGNlcnQgYW5kIGluIHRoZSBjbGllbnTigJlzIHJlZ2lzdHJhdGlvbi4gSW52ZXJzZSBpcyB0
cnVlIGlmIHlvdSBjaG9vc2UgdGhlIFNBTiBmaWVsZHMgb3ZlciB0aGUgRE4gYnV0IHRoZSBwcmlu
Y2lwbGUgaXMgdGhlIHNhbWUuIFdlIHNob3VsZCBiZSBleHBsaWNpdCBpZiB0aGVyZeKAmXMgYW4g
aW50ZW5kZWQgcHJlY2VkZW5jZSBiZXR3ZWVuIHRoZXNlIHR3bywgYW5kIGV2ZW4gbW9yZSBleHBs
aWNpdCBpZiB0aGUgRE4gYW5kIFNBTiBhcmUgYXQgZXF1YWwgbGV2ZWwgYW5kIHRoZSBBUyBnZXRz
IHRvIGNob29zZS4gV2UgYWxzbyBuZWVkIHRvIGJlIGNsZWFyIGlmIGl04oCZcyBhbiBlcnJvciBj
b25kaXRpb24gaWYgYm90aCBhcmUgc2V0IHNpbXVsdGFuZW91c2x5LCBsaWtlIHRoZSB3YXkgdGhh
dCBqd2tzIGFuZCBqd2tzX3VyaSBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLg0KMikgWW91IHNldCBh
biBleHBsaWNpdCBzd2l0Y2ggaW4geW91ciBjbGllbnQgbW9kZWwgdGhhdCBzYXlzIHdoZXRoZXIg
dG8gdXNlIHRoZSBETiBvciB0aGUgU0FOIGZpZWxkcyBpbiBjb21wYXJpc29uLCBhbmQgeW91ciBj
b2RlIGJyYW5jaGVzIGJhc2VkIG9uIHRoYXQgdG8gZWl0aGVyIEROIG9yIFNBTiBwcm9jZXNzaW5n
LiBUaGlzIGNvdWxkIGFsc28gYmUgYWRkZWQgYXMgYW4gZXhwbGljaXQgY2xpZW50IG1ldGFkYXRh
IGZpZWxkLCBvciBpdCBjb3VsZCBiZSBhbiBpbnRlcm5hbCBkZXRhaWwuIElmIGFuIGludGVybmFs
IGRldGFpbCwgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IHRoZXJlIG5vdCBiZWluZyBhIHBy
ZWRlZmluZWQgcHJlY2VkZW5jZSBiZXR3ZWVuIHRoZSBmaWVsZHMuDQozKSBJZiBpdOKAmXMgYWxs
b3dhYmxlIHRvIHVzZSB0aGVtIHRvZ2V0aGVyLCB5b3UgbWF0Y2ggZXZlcnl0aGluZyB0aGF04oCZ
cyBzZXQgaW4gdGhlIGNsaWVudCwgYW5kIGF0IGxlYXN0IG9uZSBmaWVsZCBNVVNUIGJlIHNldC4N
Cg0KDQpXaGF04oCZcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IgZm9yIGltcGxlbWVudGVycywgYW5k
IHNob3VsZCB3ZSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoaXM/IFdlIGFyZSBzdGFydGluZyBv
dXIgaW1wbGVtZW50YXRpb24gd2l0aCAoMSkgcGVuZGluZyB0aGUgb3V0Y29tZSBvZiB0aGlzIHRo
cmVhZCwgYW5kIEnigJlkIGJlIGN1cmlvdXMgdG8ga25vdyBob3cgb3RoZXJzIGFyZSBpbXBsZW1l
bnRpbmcgdGhpcyBpbiB0aGVpciBzeXN0ZW1zLg0KDQpUaGFua3MsDQrigJQgSnVzdGluDQoNCg==

--_000_220488FBC7EB42A385D6BD3756786550mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldl4oCZdmUganVzdCBzdGFydGVkIGltcGxlbWVu
dGF0aW9uIG9mIFNBTi1iYXNlZCBjZXJ0aWZpY2F0ZSBhdXRoZW50aWNhdGlvbiwgYmFzZWQgb24g
dGhlIGNoYW5nZXMgaW4gdmVyc2lvbiAtMTMgb2YgdGhlIGRyYWZ0LiBJIGJlbGlldmUgdGhpcyBh
ZGRpdGlvbiBpcyBhIGJpdCB1bmNsZWFyLCBkdWUgdG8gaXQgYmVpbmcgYWRkZWQgc28gbGF0ZSBp
biB0aGUgZG9jdW1lbnQgcHJvY2Vzcy4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk15IHF1ZXN0aW9uIGlzIGhvdyBkb2VzIGFuIEFTIGRl
dGVybWluZSB3aGV0aGVyIHRvIEROIG9yIFNBTiBmb3IgY2VydGlmaWNhdGUgY2hlY2tpbmc/IENv
cm9sbGFyeSwgYXJlIHRoZXNlIG11dHVhbGx5IGV4Y2x1c2l2ZSBvciBjYW4gdGhleSBiZSB1c2Vk
IHRvZ2V0aGVyPyZuYnNwO0N1cnJlbnRseSwgdGhlIHNwZWNpZmljYXRpb24gdGV4dCBsaXN0cyBE
TiBhbmQgU0FOIGFzIGFuIOKAnG9y4oCdIHdpdGggbm8gaW5kaWNhdGlvbiB3aGV0aGVyDQogdGhp
cyBpcyBhbiBpbmNsdXNpdmUgb3IgZXhjbHVzaXZlIOKAnG9y4oCdLCBhbmQgd2hhdCB0byBkbyB3
aGVuIHRoZXJl4oCZcyBvdmVybGFwLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBoYXMgaW1wbGljYXRpb25zIGJvdGggZm9yIHRo
ZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmVyIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgYXMg
d2VsbCBhcyB0aGUgY2xpZW50IG1ldGFkYXRhIG1vZGVsLCBzaW5jZSB0aGUgY2xpZW50IGZpZWxk
cyBhcmUgYWxsIGluIHBhcmFsbGVsIHRvIGVhY2ggb3RoZXIuIEkgY2FuIHNlZSBhIGZldyB3YXlz
IG9mIGhhbmRsaW5nIHRoaXMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MSkgT25l
IG9mIHRoZSBmaWVsZHMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIHRoZSBvdGhlci4gU2F5IGZvciBl
eGFtcGxlIHlvdSBjaG9vc2UgdGhlIEROIGZpZWxkOiBpZiBpdOKAmXMgc2V0LCB0aGVuIHlvdSBk
byBETiBtYXRjaGluZyBhbmQgaWdub3JlIHRoZSBTQU4gZmllbGRzIGVudGlyZWx5LCBib3RoIGlu
IHRoZSBjZXJ0IGFuZCBpbiB0aGUgY2xpZW504oCZcyByZWdpc3RyYXRpb24uIEludmVyc2UgaXMg
dHJ1ZSBpZiB5b3UgY2hvb3NlDQogdGhlIFNBTiBmaWVsZHMgb3ZlciB0aGUgRE4gYnV0IHRoZSBw
cmluY2lwbGUgaXMgdGhlIHNhbWUuIFdlIHNob3VsZCBiZSBleHBsaWNpdCBpZiB0aGVyZeKAmXMg
YW4gaW50ZW5kZWQgcHJlY2VkZW5jZSBiZXR3ZWVuIHRoZXNlIHR3bywgYW5kIGV2ZW4gbW9yZSBl
eHBsaWNpdCBpZiB0aGUgRE4gYW5kIFNBTiBhcmUgYXQgZXF1YWwgbGV2ZWwgYW5kIHRoZSBBUyBn
ZXRzIHRvIGNob29zZS4gV2UgYWxzbyBuZWVkIHRvIGJlIGNsZWFyIGlmIGl04oCZcyBhbg0KIGVy
cm9yIGNvbmRpdGlvbiBpZiBib3RoIGFyZSBzZXQgc2ltdWx0YW5lb3VzbHksIGxpa2UgdGhlIHdh
eSB0aGF0IGp3a3MgYW5kIGp3a3NfdXJpIGFyZSBtdXR1YWxseSBleGNsdXNpdmUuJm5ic3A7PC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjIpIFlvdSBzZXQgYW4gZXhwbGljaXQgc3dpdGNoIGluIHlvdXIg
Y2xpZW50IG1vZGVsIHRoYXQgc2F5cyB3aGV0aGVyIHRvIHVzZSB0aGUgRE4gb3IgdGhlIFNBTiBm
aWVsZHMgaW4gY29tcGFyaXNvbiwgYW5kIHlvdXIgY29kZSBicmFuY2hlcyBiYXNlZCBvbiB0aGF0
IHRvIGVpdGhlciBETiBvciBTQU4gcHJvY2Vzc2luZy4gVGhpcyBjb3VsZCBhbHNvIGJlIGFkZGVk
IGFzIGFuIGV4cGxpY2l0IGNsaWVudCBtZXRhZGF0YSBmaWVsZCwNCiBvciBpdCBjb3VsZCBiZSBh
biBpbnRlcm5hbCBkZXRhaWwuIElmIGFuIGludGVybmFsIGRldGFpbCwgd2Ugc2hvdWxkIGJlIGV4
cGxpY2l0IGFib3V0IHRoZXJlIG5vdCBiZWluZyBhIHByZWRlZmluZWQgcHJlY2VkZW5jZSBiZXR3
ZWVuIHRoZSBmaWVsZHMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMpIElmIGl04oCZcyBh
bGxvd2FibGUgdG8gdXNlIHRoZW0gdG9nZXRoZXIsIHlvdSBtYXRjaCBldmVyeXRoaW5nIHRoYXTi
gJlzIHNldCBpbiB0aGUgY2xpZW50LCBhbmQgYXQgbGVhc3Qgb25lIGZpZWxkIE1VU1QgYmUgc2V0
LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXTigJlzIHRoZSBpbnRl
bmRlZCBiZWhhdmlvciBmb3IgaW1wbGVtZW50ZXJzLCBhbmQgc2hvdWxkIHdlIGJlIG1vcmUgZXhw
bGljaXQgYWJvdXQgdGhpcz8gV2UgYXJlIHN0YXJ0aW5nIG91ciBpbXBsZW1lbnRhdGlvbiB3aXRo
ICgxKSBwZW5kaW5nIHRoZSBvdXRjb21lIG9mIHRoaXMgdGhyZWFkLCBhbmQgSeKAmWQgYmUgY3Vy
aW91cyB0byBrbm93IGhvdyBvdGhlcnMgYXJlIGltcGxlbWVudGluZyB0aGlzIGluIHRoZWlyIHN5
c3RlbXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj5UaGFua3MsPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg
c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp
ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog
YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v
bmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_220488FBC7EB42A385D6BD3756786550mitedu_--


From nobody Thu Apr  4 13:23:40 2019
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 DDA71120601 for ; Thu,  4 Apr 2019 13:23:36 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TOLRGw4gzQpN for ; Thu,  4 Apr 2019 13:23:34 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0: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 147F41200B2 for ; Thu,  4 Apr 2019 13:23:33 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id l203so3046409oia.3 for ; Thu, 04 Apr 2019 13:23:33 -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=gH8yAy82YPrJa1A09VS1yVLZWeYwzNVyV3zAT9RZK7g=; b=Rop2r96K2KSIniPCipdQermbURK7fTxC81bJDh3MezihX45dCWH7YesheCgADKrvse M9bNKQbFNP5h1/wValZ09oLq84DaQ0qI36ZCkDqzXc9NZZv/w9kvBfLeMFXH/1Rfzg4d budO+t1B3IvopA63oFonALBN+95puhXvLgGahaONxu+jZKWpCj6ZgEowZfl2/MCTp89D YWXArnkzf2N8LYYBAZrWkdoJVJ6CK9YeHTUPaEL49sDCWvpY1Qf6vZfiesXj60OJFrYE DY0k9sa6oLLFVSz8IHkqzQEN+cxc6ym9VKV1d0EWiKApRkCKDTwHW9TTeycycZGC3phv yxsQ==
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=gH8yAy82YPrJa1A09VS1yVLZWeYwzNVyV3zAT9RZK7g=; b=iLf02PoTQ/BH+EZdh+P111TIz3gm2bqHXRTKz6OJ9lyqZKF5+cGr4eVsZsii8SgTzP s2Cs72bA+9lFbTfolReKH7YhUQbvJwFSSKCDafkB1W/Pwa9GfI1jx7prEZyliXlj8Knj K+0ojdJVYu1/NNG8bO37alJF6yoDGaZNv7noq5V5PwraSRVg1PbZZrinobM4pS2mZZTG JgbsKV79uD14bxWwo6atIQDw8ypbjpJwrz6kxdsKiW738BnNJ30ArXD4m4s51gSZOjpj Ytnqfpxhe2tnKSJYTR/Sr6fpiyJ9q6jgWvJ62xdIRi1Rjeg9eEk6vvn/d+LDGa/YOvFn 5QIw==
X-Gm-Message-State: APjAAAVuuspJBrdjg5OqllkN7vZQJ/i0TiX7aFLTsxtAmkT+Q3va1mWO /fww6GQAidxuyMfDjWfvtk/xNGBzKjsbZzth+Q==
X-Google-Smtp-Source: APXvYqz2ffE+mNuvB9NPU8U1XxtbshAcVoHT6XAy/6v4hc2G6OrqboNX48IOYWPPNIpKxgcqzWy5H1fuwakEFgc4BF0=
X-Received: by 2002:aca:eb55:: with SMTP id j82mr4691959oih.178.1554409412186;  Thu, 04 Apr 2019 13:23:32 -0700 (PDT)
MIME-Version: 1.0
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>
In-Reply-To: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>
From: Filip Skokan 
Date: Thu, 4 Apr 2019 22:23:21 +0200
Message-ID: 
To: Justin Richer 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000d9591c0585ba24fb"
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 04 Apr 2019 20:23:39 -0000

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

Justin, I had the exact same question off list and believe draft 13
clarified this.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2

A client using the "tls_client_auth" authentication method MUST use exactly
one of the below metadata parameters to indicate the certificate subject
value that the authorization server is to expect when authenticating the
respective client.

Then it lists the different dn/san properties.

S pozdravem,
*Filip Skokan*


On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:

> We=E2=80=99ve just started implementation of SAN-based certificate authen=
tication,
> based on the changes in version -13 of the draft. I believe this addition
> is a bit unclear, due to it being added so late in the document process.
>
> My question is how does an AS determine whether to DN or SAN for
> certificate checking? Corollary, are these mutually exclusive or can they
> be used together? Currently, the specification text lists DN and SAN as a=
n
> =E2=80=9Cor=E2=80=9D with no indication whether this is an inclusive or e=
xclusive =E2=80=9Cor=E2=80=9D, and
> what to do when there=E2=80=99s overlap.
>
> This has implications both for the implementation of the server processin=
g
> the request as well as the client metadata model, since the client fields
> are all in parallel to each other. I can see a few ways of handling this.
>
>
> 1) One of the fields takes precedence over the other. Say for example you
> choose the DN field: if it=E2=80=99s set, then you do DN matching and ign=
ore the
> SAN fields entirely, both in the cert and in the client=E2=80=99s registr=
ation.
> Inverse is true if you choose the SAN fields over the DN but the principl=
e
> is the same. We should be explicit if there=E2=80=99s an intended precede=
nce
> between these two, and even more explicit if the DN and SAN are at equal
> level and the AS gets to choose. We also need to be clear if it=E2=80=99s=
 an error
> condition if both are set simultaneously, like the way that jwks and
> jwks_uri are mutually exclusive.
> 2) You set an explicit switch in your client model that says whether to
> use the DN or the SAN fields in comparison, and your code branches based =
on
> that to either DN or SAN processing. This could also be added as an
> explicit client metadata field, or it could be an internal detail. If an
> internal detail, we should be explicit about there not being a predefined
> precedence between the fields.
> 3) If it=E2=80=99s allowable to use them together, you match everything t=
hat=E2=80=99s set
> in the client, and at least one field MUST be set.
>
>
> What=E2=80=99s the intended behavior for implementers, and should we be m=
ore
> explicit about this? We are starting our implementation with (1) pending
> the outcome of this thread, and I=E2=80=99d be curious to know how others=
 are
> implementing this in their systems.
>
> Thanks,
> =E2=80=94 Justin
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


On Thu, =
4 Apr 2019 at 22:20, Justin Richer <j=
richer@mit.edu> wrote:






We=E2=80=99ve just started implementation of SAN-based certificate authenti=
cation, based on the changes in version -13 of the draft. I believe this ad=
dition is a bit unclear, due to it being added so late in the document proc=
ess.=C2=A0






My question is how does an AS determine whether to DN or SAN for certi=
ficate checking? Corollary, are these mutually exclusive or can they be use=
d together?=C2=A0Currently, the specification text lists DN and SAN as an =
=E2=80=9Cor=E2=80=9D with no indication whether
 this is an inclusive or exclusive =E2=80=9Cor=E2=80=9D, and what to do whe=
n there=E2=80=99s overlap.=C2=A0






This has implications both for the implementation of the server proces=
sing the request as well as the client metadata model, since the client fie=
lds are all in parallel to each other. I can see a few ways of handling thi=
s.











1) One of the fields takes precedence over the other. Say for example =
you choose the DN field: if it=E2=80=99s set, then you do DN matching and i=
gnore the SAN fields entirely, both in the cert and in the client=E2=80=99s=
 registration. Inverse is true if you choose
 the SAN fields over the DN but the principle is the same. We should be exp=
licit if there=E2=80=99s an intended precedence between these two, and even=
 more explicit if the DN and SAN are at equal level and the AS gets to choo=
se. We also need to be clear if it=E2=80=99s an
 error condition if both are set simultaneously, like the way that jwks and=
 jwks_uri are mutually exclusive.=C2=A0


2) You set an explicit switch in your client model that says whether t=
o use the DN or the SAN fields in comparison, and your code branches based =
on that to either DN or SAN processing. This could also be added as an expl=
icit client metadata field,
 or it could be an internal detail. If an internal detail, we should be exp=
licit about there not being a predefined precedence between the fields.=C2=
=A0


3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s set in the client, and at least one field MUST be set.











What=E2=80=99s the intended behavior for implementers, and should we b=
e more explicit about this? We are starting our implementation with (1) pen=
ding the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are implementing this in their systems.=C2=A0







Thanks,





=E2=80=94 Justin














_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000d9591c0585ba24fb--


From nobody Thu Apr  4 13:36:32 2019
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 B69551201B3 for ; Thu,  4 Apr 2019 13:36: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, HTML_MESSAGE=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 rC7k3Jw5EZaZ for ; Thu,  4 Apr 2019 13:36:28 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 E340F12016D for ; Thu,  4 Apr 2019 13:36:27 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x34KaSrF030269; Thu, 4 Apr 2019 16:36:39 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 4 Apr 2019 16:35:14 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 4 Apr 2019 16:36:06 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Thu, 4 Apr 2019 16:36:06 -0400
From: Justin Richer 
To: Filip Skokan 
CC: oauth 
Thread-Topic: [OAUTH-WG] MTLS and SAN
Thread-Index: AQHU6yPYm24VQsQf0UuOqTG8+b1fiqYstUSAgAADkAA=
Date: Thu, 4 Apr 2019 20:36:06 +0000
Message-ID: <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu>
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_427903635D79411CBE4ED99A90E36951mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 04 Apr 2019 20:36:31 -0000

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

VGhhbmsgeW91LCBJIGRpZCBtaXNzIHRoYXQgdGV4dC4gVGhpcyBzaG91bGQgYmUgY2FsbGVkIG91
dCBtb3JlIGV4cGxpY2l0bHkgaW4gwqcyLjEsIHBlcmhhcHMgYnkgc3BlY2lmeWluZyB0aGF0IGl0
IGlzIG9ubHkgb25lIGZpZWxkLiBUaGlzIHN0aWxsIGRvZXNu4oCZdCBzZXQgcHJlY2VkZW5jZSwg
YnV0IGl0IGltcGxpZXMgdGhhdCBpdOKAmXMgYW4gZXJyb3IgZm9yIGEgY2xpZW50IHRvIGhhdmUg
bW9yZSB0aGFuIG9uZSBmaWVsZCBzZXQgb2YgdGhlIGF2YWlsYWJsZSBvcHRpb25zLiBJcyB0aGF0
IHlvdXIgcmVhZCBvbiB0aGlzIGFzIHdlbGw/DQoNCuKAlCBKdXN0aW4NCg0KT24gQXByIDQsIDIw
MTksIGF0IDQ6MjMgUE0sIEZpbGlwIFNrb2thbiA8cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpw
YW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCg0KSnVzdGluLCBJIGhhZCB0aGUgZXhhY3Qgc2Ft
ZSBxdWVzdGlvbiBvZmYgbGlzdCBhbmQgYmVsaWV2ZSBkcmFmdCAxMyBjbGFyaWZpZWQgdGhpcy4N
Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbXRscy0xMyNz
ZWN0aW9uLTIuMS4yDQoNCkEgY2xpZW50IHVzaW5nIHRoZSAidGxzX2NsaWVudF9hdXRoIiBhdXRo
ZW50aWNhdGlvbiBtZXRob2QgTVVTVCB1c2UgZXhhY3RseSBvbmUgb2YgdGhlIGJlbG93IG1ldGFk
YXRhIHBhcmFtZXRlcnMgdG8gaW5kaWNhdGUgdGhlIGNlcnRpZmljYXRlIHN1YmplY3QgdmFsdWUg
dGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgdG8gZXhwZWN0IHdoZW4gYXV0aGVudGlj
YXRpbmcgdGhlIHJlc3BlY3RpdmUgY2xpZW50Lg0KDQpUaGVuIGl0IGxpc3RzIHRoZSBkaWZmZXJl
bnQgZG4vc2FuIHByb3BlcnRpZXMuDQoNClMgcG96ZHJhdmVtLA0KRmlsaXAgU2tva2FuDQoNCg0K
T24gVGh1LCA0IEFwciAyMDE5IGF0IDIyOjIwLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l
ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KV2XigJl2ZSBqdXN0IHN0YXJ0ZWQg
aW1wbGVtZW50YXRpb24gb2YgU0FOLWJhc2VkIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uLCBi
YXNlZCBvbiB0aGUgY2hhbmdlcyBpbiB2ZXJzaW9uIC0xMyBvZiB0aGUgZHJhZnQuIEkgYmVsaWV2
ZSB0aGlzIGFkZGl0aW9uIGlzIGEgYml0IHVuY2xlYXIsIGR1ZSB0byBpdCBiZWluZyBhZGRlZCBz
byBsYXRlIGluIHRoZSBkb2N1bWVudCBwcm9jZXNzLg0KDQpNeSBxdWVzdGlvbiBpcyBob3cgZG9l
cyBhbiBBUyBkZXRlcm1pbmUgd2hldGhlciB0byBETiBvciBTQU4gZm9yIGNlcnRpZmljYXRlIGNo
ZWNraW5nPyBDb3JvbGxhcnksIGFyZSB0aGVzZSBtdXR1YWxseSBleGNsdXNpdmUgb3IgY2FuIHRo
ZXkgYmUgdXNlZCB0b2dldGhlcj8gQ3VycmVudGx5LCB0aGUgc3BlY2lmaWNhdGlvbiB0ZXh0IGxp
c3RzIEROIGFuZCBTQU4gYXMgYW4g4oCcb3LigJ0gd2l0aCBubyBpbmRpY2F0aW9uIHdoZXRoZXIg
dGhpcyBpcyBhbiBpbmNsdXNpdmUgb3IgZXhjbHVzaXZlIOKAnG9y4oCdLCBhbmQgd2hhdCB0byBk
byB3aGVuIHRoZXJl4oCZcyBvdmVybGFwLg0KDQpUaGlzIGhhcyBpbXBsaWNhdGlvbnMgYm90aCBm
b3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzZXJ2ZXIgcHJvY2Vzc2luZyB0aGUgcmVxdWVz
dCBhcyB3ZWxsIGFzIHRoZSBjbGllbnQgbWV0YWRhdGEgbW9kZWwsIHNpbmNlIHRoZSBjbGllbnQg
ZmllbGRzIGFyZSBhbGwgaW4gcGFyYWxsZWwgdG8gZWFjaCBvdGhlci4gSSBjYW4gc2VlIGEgZmV3
IHdheXMgb2YgaGFuZGxpbmcgdGhpcy4NCg0KDQoxKSBPbmUgb2YgdGhlIGZpZWxkcyB0YWtlcyBw
cmVjZWRlbmNlIG92ZXIgdGhlIG90aGVyLiBTYXkgZm9yIGV4YW1wbGUgeW91IGNob29zZSB0aGUg
RE4gZmllbGQ6IGlmIGl04oCZcyBzZXQsIHRoZW4geW91IGRvIEROIG1hdGNoaW5nIGFuZCBpZ25v
cmUgdGhlIFNBTiBmaWVsZHMgZW50aXJlbHksIGJvdGggaW4gdGhlIGNlcnQgYW5kIGluIHRoZSBj
bGllbnTigJlzIHJlZ2lzdHJhdGlvbi4gSW52ZXJzZSBpcyB0cnVlIGlmIHlvdSBjaG9vc2UgdGhl
IFNBTiBmaWVsZHMgb3ZlciB0aGUgRE4gYnV0IHRoZSBwcmluY2lwbGUgaXMgdGhlIHNhbWUuIFdl
IHNob3VsZCBiZSBleHBsaWNpdCBpZiB0aGVyZeKAmXMgYW4gaW50ZW5kZWQgcHJlY2VkZW5jZSBi
ZXR3ZWVuIHRoZXNlIHR3bywgYW5kIGV2ZW4gbW9yZSBleHBsaWNpdCBpZiB0aGUgRE4gYW5kIFNB
TiBhcmUgYXQgZXF1YWwgbGV2ZWwgYW5kIHRoZSBBUyBnZXRzIHRvIGNob29zZS4gV2UgYWxzbyBu
ZWVkIHRvIGJlIGNsZWFyIGlmIGl04oCZcyBhbiBlcnJvciBjb25kaXRpb24gaWYgYm90aCBhcmUg
c2V0IHNpbXVsdGFuZW91c2x5LCBsaWtlIHRoZSB3YXkgdGhhdCBqd2tzIGFuZCBqd2tzX3VyaSBh
cmUgbXV0dWFsbHkgZXhjbHVzaXZlLg0KMikgWW91IHNldCBhbiBleHBsaWNpdCBzd2l0Y2ggaW4g
eW91ciBjbGllbnQgbW9kZWwgdGhhdCBzYXlzIHdoZXRoZXIgdG8gdXNlIHRoZSBETiBvciB0aGUg
U0FOIGZpZWxkcyBpbiBjb21wYXJpc29uLCBhbmQgeW91ciBjb2RlIGJyYW5jaGVzIGJhc2VkIG9u
IHRoYXQgdG8gZWl0aGVyIEROIG9yIFNBTiBwcm9jZXNzaW5nLiBUaGlzIGNvdWxkIGFsc28gYmUg
YWRkZWQgYXMgYW4gZXhwbGljaXQgY2xpZW50IG1ldGFkYXRhIGZpZWxkLCBvciBpdCBjb3VsZCBi
ZSBhbiBpbnRlcm5hbCBkZXRhaWwuIElmIGFuIGludGVybmFsIGRldGFpbCwgd2Ugc2hvdWxkIGJl
IGV4cGxpY2l0IGFib3V0IHRoZXJlIG5vdCBiZWluZyBhIHByZWRlZmluZWQgcHJlY2VkZW5jZSBi
ZXR3ZWVuIHRoZSBmaWVsZHMuDQozKSBJZiBpdOKAmXMgYWxsb3dhYmxlIHRvIHVzZSB0aGVtIHRv
Z2V0aGVyLCB5b3UgbWF0Y2ggZXZlcnl0aGluZyB0aGF04oCZcyBzZXQgaW4gdGhlIGNsaWVudCwg
YW5kIGF0IGxlYXN0IG9uZSBmaWVsZCBNVVNUIGJlIHNldC4NCg0KDQpXaGF04oCZcyB0aGUgaW50
ZW5kZWQgYmVoYXZpb3IgZm9yIGltcGxlbWVudGVycywgYW5kIHNob3VsZCB3ZSBiZSBtb3JlIGV4
cGxpY2l0IGFib3V0IHRoaXM/IFdlIGFyZSBzdGFydGluZyBvdXIgaW1wbGVtZW50YXRpb24gd2l0
aCAoMSkgcGVuZGluZyB0aGUgb3V0Y29tZSBvZiB0aGlzIHRocmVhZCwgYW5kIEnigJlkIGJlIGN1
cmlvdXMgdG8ga25vdyBob3cgb3RoZXJzIGFyZSBpbXBsZW1lbnRpbmcgdGhpcyBpbiB0aGVpciBz
eXN0ZW1zLg0KDQpUaGFua3MsDQrigJQgSnVzdGluDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0K

--_000_427903635D79411CBE4ED99A90E36951mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <37959F6A9C7E7943AB329278B28E5214@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rIHlvdSwgSSBkaWQgbWlzcyB0aGF0IHRl
eHQuIFRoaXMgc2hvdWxkIGJlIGNhbGxlZCBvdXQgbW9yZSBleHBsaWNpdGx5IGluIMKnMi4xLCBw
ZXJoYXBzIGJ5IHNwZWNpZnlpbmcgdGhhdCBpdCBpcyBvbmx5IG9uZSBmaWVsZC4gVGhpcyBzdGls
bCBkb2VzbuKAmXQgc2V0IHByZWNlZGVuY2UsIGJ1dCBpdCBpbXBsaWVzIHRoYXQgaXTigJlzIGFu
IGVycm9yIGZvciBhIGNsaWVudCB0byBoYXZlIG1vcmUgdGhhbiBvbmUgZmllbGQgc2V0IG9mIHRo
ZSBhdmFpbGFibGUNCiBvcHRpb25zLiBJcyB0aGF0IHlvdXIgcmVhZCBvbiB0aGlzIGFzIHdlbGw/
DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6
IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+
DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciA0LCAyMDE5LCBh
dCA0OjIzIFBNLCBGaWxpcCBTa29rYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwYW52YS5pcEBnbWFp
bC5jb20iIGNsYXNzPSIiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K
PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBk
aXI9Imx0ciIgY2xhc3M9IiI+SnVzdGluLCBJIGhhZCB0aGUgZXhhY3Qgc2FtZSBxdWVzdGlvbiBv
ZmYgbGlzdCBhbmQgYmVsaWV2ZSBkcmFmdCAxMyBjbGFyaWZpZWQgdGhpcy4NCjxkaXYgY2xhc3M9
IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLW10bHMtMTMjc2VjdGlvbi0yLjEu
MiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt
bXRscy0xMyNzZWN0aW9uLTIuMS4yPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QSBjbGllbnQgdXNpbmcgdGhlJm5ic3A7JnF1b3Q7
dGxzX2NsaWVudF9hdXRoJnF1b3Q7IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBNVVNUIHVzZSBleGFj
dGx5IG9uZSBvZiB0aGUgYmVsb3cgbWV0YWRhdGEgcGFyYW1ldGVycyB0byBpbmRpY2F0ZSB0aGUg
Y2VydGlmaWNhdGUgc3ViamVjdCB2YWx1ZSB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBp
cyB0byBleHBlY3Qgd2hlbiBhdXRoZW50aWNhdGluZyB0aGUgcmVzcGVjdGl2ZSBjbGllbnQuPGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj5UaGVuIGl0IGxpc3RzIHRoZSBkaWZmZXJlbnQgZG4vc2FuIHByb3BlcnRp
ZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xlYXI9ImFsbCIg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX3Np
Z25hdHVyZSI+UyBwb3pkcmF2ZW0sPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RmlsaXAgU2tv
a2FuPC9iPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv
dGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgNCBBcHIgMjAx
OSBhdCAyMjoyMCwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0
LmVkdSIgY2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46
MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7
cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3Jk
OyIgY2xhc3M9IiI+V2XigJl2ZSBqdXN0IHN0YXJ0ZWQgaW1wbGVtZW50YXRpb24gb2YgU0FOLWJh
c2VkIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uLCBiYXNlZCBvbiB0aGUgY2hhbmdlcyBpbiB2
ZXJzaW9uIC0xMyBvZiB0aGUgZHJhZnQuIEkgYmVsaWV2ZSB0aGlzIGFkZGl0aW9uIGlzIGEgYml0
IHVuY2xlYXIsIGR1ZSB0byBpdCBiZWluZyBhZGRlZCBzbyBsYXRlIGluIHRoZSBkb2N1bWVudA0K
IHByb2Nlc3MuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj5NeSBxdWVzdGlvbiBpcyBob3cgZG9lcyBhbiBBUyBkZXRlcm1pbmUgd2hldGhl
ciB0byBETiBvciBTQU4gZm9yIGNlcnRpZmljYXRlIGNoZWNraW5nPyBDb3JvbGxhcnksIGFyZSB0
aGVzZSBtdXR1YWxseSBleGNsdXNpdmUgb3IgY2FuIHRoZXkgYmUgdXNlZCB0b2dldGhlcj8mbmJz
cDtDdXJyZW50bHksIHRoZSBzcGVjaWZpY2F0aW9uIHRleHQgbGlzdHMgRE4gYW5kIFNBTiBhcyBh
biDigJxvcuKAnSB3aXRoIG5vIGluZGljYXRpb24gd2hldGhlcg0KIHRoaXMgaXMgYW4gaW5jbHVz
aXZlIG9yIGV4Y2x1c2l2ZSDigJxvcuKAnSwgYW5kIHdoYXQgdG8gZG8gd2hlbiB0aGVyZeKAmXMg
b3ZlcmxhcC4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPlRoaXMgaGFzIGltcGxpY2F0aW9ucyBib3RoIGZvciB0aGUgaW1wbGVtZW50YXRp
b24gb2YgdGhlIHNlcnZlciBwcm9jZXNzaW5nIHRoZSByZXF1ZXN0IGFzIHdlbGwgYXMgdGhlIGNs
aWVudCBtZXRhZGF0YSBtb2RlbCwgc2luY2UgdGhlIGNsaWVudCBmaWVsZHMgYXJlIGFsbCBpbiBw
YXJhbGxlbCB0byBlYWNoIG90aGVyLiBJIGNhbiBzZWUgYSBmZXcgd2F5cyBvZiBoYW5kbGluZyB0
aGlzLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEpIE9uZSBvZiB0aGUgZmllbGRz
IHRha2VzIHByZWNlZGVuY2Ugb3ZlciB0aGUgb3RoZXIuIFNheSBmb3IgZXhhbXBsZSB5b3UgY2hv
b3NlIHRoZSBETiBmaWVsZDogaWYgaXTigJlzIHNldCwgdGhlbiB5b3UgZG8gRE4gbWF0Y2hpbmcg
YW5kIGlnbm9yZSB0aGUgU0FOIGZpZWxkcyBlbnRpcmVseSwgYm90aCBpbiB0aGUgY2VydCBhbmQg
aW4gdGhlIGNsaWVudOKAmXMgcmVnaXN0cmF0aW9uLiBJbnZlcnNlIGlzIHRydWUgaWYgeW91IGNo
b29zZQ0KIHRoZSBTQU4gZmllbGRzIG92ZXIgdGhlIEROIGJ1dCB0aGUgcHJpbmNpcGxlIGlzIHRo
ZSBzYW1lLiBXZSBzaG91bGQgYmUgZXhwbGljaXQgaWYgdGhlcmXigJlzIGFuIGludGVuZGVkIHBy
ZWNlZGVuY2UgYmV0d2VlbiB0aGVzZSB0d28sIGFuZCBldmVuIG1vcmUgZXhwbGljaXQgaWYgdGhl
IEROIGFuZCBTQU4gYXJlIGF0IGVxdWFsIGxldmVsIGFuZCB0aGUgQVMgZ2V0cyB0byBjaG9vc2Uu
IFdlIGFsc28gbmVlZCB0byBiZSBjbGVhciBpZiBpdOKAmXMgYW4NCiBlcnJvciBjb25kaXRpb24g
aWYgYm90aCBhcmUgc2V0IHNpbXVsdGFuZW91c2x5LCBsaWtlIHRoZSB3YXkgdGhhdCBqd2tzIGFu
ZCBqd2tzX3VyaSBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj4yKSBZb3Ugc2V0IGFuIGV4cGxpY2l0IHN3aXRjaCBpbiB5b3VyIGNsaWVudCBtb2RlbCB0
aGF0IHNheXMgd2hldGhlciB0byB1c2UgdGhlIEROIG9yIHRoZSBTQU4gZmllbGRzIGluIGNvbXBh
cmlzb24sIGFuZCB5b3VyIGNvZGUgYnJhbmNoZXMgYmFzZWQgb24gdGhhdCB0byBlaXRoZXIgRE4g
b3IgU0FOIHByb2Nlc3NpbmcuIFRoaXMgY291bGQgYWxzbyBiZSBhZGRlZCBhcyBhbiBleHBsaWNp
dCBjbGllbnQgbWV0YWRhdGEgZmllbGQsDQogb3IgaXQgY291bGQgYmUgYW4gaW50ZXJuYWwgZGV0
YWlsLiBJZiBhbiBpbnRlcm5hbCBkZXRhaWwsIHdlIHNob3VsZCBiZSBleHBsaWNpdCBhYm91dCB0
aGVyZSBub3QgYmVpbmcgYSBwcmVkZWZpbmVkIHByZWNlZGVuY2UgYmV0d2VlbiB0aGUgZmllbGRz
LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zKSBJZiBpdOKAmXMgYWxsb3dhYmxlIHRvIHVz
ZSB0aGVtIHRvZ2V0aGVyLCB5b3UgbWF0Y2ggZXZlcnl0aGluZyB0aGF04oCZcyBzZXQgaW4gdGhl
IGNsaWVudCwgYW5kIGF0IGxlYXN0IG9uZSBmaWVsZCBNVVNUIGJlIHNldC48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i
Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGF04oCZcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3Ig
Zm9yIGltcGxlbWVudGVycywgYW5kIHNob3VsZCB3ZSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRo
aXM/IFdlIGFyZSBzdGFydGluZyBvdXIgaW1wbGVtZW50YXRpb24gd2l0aCAoMSkgcGVuZGluZyB0
aGUgb3V0Y29tZSBvZiB0aGlzIHRocmVhZCwgYW5kIEnigJlkIGJlIGN1cmlvdXMgdG8ga25vdyBo
b3cgb3RoZXJzIGFyZSBpbXBsZW1lbnRpbmcgdGhpcyBpbiB0aGVpciBzeXN0ZW1zLiZuYnNwOzwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
VGhhbmtzLDxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh
bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4
dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4N
CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0
aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9
IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i
Ij4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_427903635D79411CBE4ED99A90E36951mitedu_--


From nobody Thu Apr  4 13:54:59 2019
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 36B431201EF for ; Thu,  4 Apr 2019 13:54:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4sSXlyEllNK0 for ; Thu,  4 Apr 2019 13:54:54 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0: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 9105E1204B4 for ; Thu,  4 Apr 2019 13:54:54 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id x188so3073866oia.13 for ; Thu, 04 Apr 2019 13:54:54 -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=3fY7IF/Xvw1fueFCA4ZtrA2qocun+CirAWfHnnsC6NU=; b=Bh8+2gy1Lo/YwumPuK3K+LPcIWFUh6i/1eb0kOE7zmLQLqdM5RATED5J4ebxy8Pyaw 5gSTXiw8+AClctbBIdlQv7MhD+3yXEWVYW3vGbDFB7aRi9H5tQRhMfJ1Zo5VThOZkhqf tRs8lKC5aoUSVfwe9cxLxSdHNmtdckd6g/DP9fpogbV3ZnlbSSwysTxY0sfZBKyW9971 fVGyJ4tpNsvkgXUe2VDvGAe1BmRcVNikUe0DHgrin+mqLHG3PTUcq3CdZAyeVU1wT1C3 TO+mH5tuRlQjLFW48u4VdzqImx6uhsB5RjjHw4hS8Ge0j55bKHjFKJM9PHypQ5GqZnK1 qBLA==
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=3fY7IF/Xvw1fueFCA4ZtrA2qocun+CirAWfHnnsC6NU=; b=sZRvPBvjzJsLunrWwHPOsVOqv/FCj0vz2HN4okWh+KZ2u4jP/TlIvxXPkOm2b9rUvW Wn8fxMYugKpAdgxWZYhtbjAoV/jnEwydlMGbBQhMXPNGwgur6Lc8IoDU8qTTaGvLeEWO jgZ5U4Mwz3EdgfttB8TAN7yP+gmVSvqiStXpj+K/HkowufqnL/IdqQdWAyDdAtCLXnLA +keYl3CIo+tixQMDP0lbFVXH9U8d/blbyHDwupAhp6Kv+O05Dw6C5V7HZ/am1HVXIRQx +bTW/9YsUgLqnrV1vnKPEszGgi7CB7PMzTTRoOm/n/sLrv7WfdB24r7C70qEJBnfmW3V 2vYQ==
X-Gm-Message-State: APjAAAXlzpwvAHtHFYm2YiQrEY4SaEKeityKCbaMmWZ617VQOoQRlbLd 977rYePtjC7XhDaA/WzV98vJiL5v//THPWUvvA==
X-Google-Smtp-Source: APXvYqx3HtvhBIksgA9SivO1920VZCXH5eYj+X5u/ZAOMti7mveQd++/q+q7Jugly0atdcyyNFurnYmMQ/5TUALA2uc=
X-Received: by 2002:aca:db83:: with SMTP id s125mr4525160oig.61.1554411293790;  Thu, 04 Apr 2019 13:54:53 -0700 (PDT)
MIME-Version: 1.0
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>  <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu>
In-Reply-To: <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu>
From: Filip Skokan 
Date: Thu, 4 Apr 2019 22:54:42 +0200
Message-ID: 
To: Justin Richer 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000000059810585ba950f"
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 04 Apr 2019 20:54:57 -0000

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

Yes.

S pozdravem,
*Filip Skokan*


On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:

> Thank you, I did miss that text. This should be called out more explicitl=
y
> in =C2=A72.1, perhaps by specifying that it is only one field. This still
> doesn=E2=80=99t set precedence, but it implies that it=E2=80=99s an error=
 for a client to
> have more than one field set of the available options. Is that your read =
on
> this as well?
>
> =E2=80=94 Justin
>
> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>
> Justin, I had the exact same question off list and believe draft 13
> clarified this.
>
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>
> A client using the "tls_client_auth" authentication method MUST use
> exactly one of the below metadata parameters to indicate the certificate
> subject value that the authorization server is to expect when
> authenticating the respective client.
>
> Then it lists the different dn/san properties.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>
>> We=E2=80=99ve just started implementation of SAN-based certificate
>> authentication, based on the changes in version -13 of the draft. I beli=
eve
>> this addition is a bit unclear, due to it being added so late in the
>> document process.
>>
>> My question is how does an AS determine whether to DN or SAN for
>> certificate checking? Corollary, are these mutually exclusive or can the=
y
>> be used together? Currently, the specification text lists DN and SAN as =
an
>> =E2=80=9Cor=E2=80=9D with no indication whether this is an inclusive or =
exclusive =E2=80=9Cor=E2=80=9D, and
>> what to do when there=E2=80=99s overlap.
>>
>> This has implications both for the implementation of the server
>> processing the request as well as the client metadata model, since the
>> client fields are all in parallel to each other. I can see a few ways of
>> handling this.
>>
>>
>> 1) One of the fields takes precedence over the other. Say for example yo=
u
>> choose the DN field: if it=E2=80=99s set, then you do DN matching and ig=
nore the
>> SAN fields entirely, both in the cert and in the client=E2=80=99s regist=
ration.
>> Inverse is true if you choose the SAN fields over the DN but the princip=
le
>> is the same. We should be explicit if there=E2=80=99s an intended preced=
ence
>> between these two, and even more explicit if the DN and SAN are at equal
>> level and the AS gets to choose. We also need to be clear if it=E2=80=99=
s an error
>> condition if both are set simultaneously, like the way that jwks and
>> jwks_uri are mutually exclusive.
>> 2) You set an explicit switch in your client model that says whether to
>> use the DN or the SAN fields in comparison, and your code branches based=
 on
>> that to either DN or SAN processing. This could also be added as an
>> explicit client metadata field, or it could be an internal detail. If an
>> internal detail, we should be explicit about there not being a predefine=
d
>> precedence between the fields.
>> 3) If it=E2=80=99s allowable to use them together, you match everything =
that=E2=80=99s
>> set in the client, and at least one field MUST be set.
>>
>>
>> What=E2=80=99s the intended behavior for implementers, and should we be =
more
>> explicit about this? We are starting our implementation with (1) pending
>> the outcome of this thread, and I=E2=80=99d be curious to know how other=
s are
>> implementing this in their systems.
>>
>> Thanks,
>> =E2=80=94 Justin
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>

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


Yes.

S pozdravem,
Fili=
p Skokan


On Thu, 4 Apr 2019 at 22:36, Justin Riche=
r <jricher@mit.edu> wrote:
=







Thank you, I did miss that text. This should be called out more explicitly =
in =C2=A72.1, perhaps by specifying that it is only one field. This still d=
oesn=E2=80=99t set precedence, but it implies that it=E2=80=99s an error fo=
r a client to have more than one field set of the available
 options. Is that your read on this as well?







=E2=80=94 Justin









On Apr 4, 2019, at 4:23 PM, Filip Skokan <panva.ip@gmail.com> wrote:










Justin, I had the exact same question off list and believe=
 draft 13 clarified this.












A client using the=C2=A0"tls_client_auth" authentication met=
hod MUST use exactly one of the below metadata parameters to indicate the c=
ertificate subject value that the authorization server is to expect when au=
thenticating the respective client.









Then it lists the different dn/san properties.









S po=
zdravem,

Filip Skokan




















On Thu, 4 Apr 2019 at 22:20, Justin R=
icher <jricher@mit.=
edu> wrote:






We=E2=80=99ve just started implementation of SAN-based certificate aut=
hentication, based on the changes in version -13 of the draft. I believe th=
is addition is a bit unclear, due to it being added so late in the document
 process.=C2=A0






My question is how does an AS determine whether to DN or SAN for certi=
ficate checking? Corollary, are these mutually exclusive or can they be use=
d together?=C2=A0Currently, the specification text lists DN and SAN as an =
=E2=80=9Cor=E2=80=9D with no indication whether
 this is an inclusive or exclusive =E2=80=9Cor=E2=80=9D, and what to do whe=
n there=E2=80=99s overlap.=C2=A0






This has implications both for the implementation of the server proces=
sing the request as well as the client metadata model, since the client fie=
lds are all in parallel to each other. I can see a few ways of handling thi=
s.











1) One of the fields takes precedence over the other. Say for example =
you choose the DN field: if it=E2=80=99s set, then you do DN matching and i=
gnore the SAN fields entirely, both in the cert and in the client=E2=80=99s=
 registration. Inverse is true if you choose
 the SAN fields over the DN but the principle is the same. We should be exp=
licit if there=E2=80=99s an intended precedence between these two, and even=
 more explicit if the DN and SAN are at equal level and the AS gets to choo=
se. We also need to be clear if it=E2=80=99s an
 error condition if both are set simultaneously, like the way that jwks and=
 jwks_uri are mutually exclusive.=C2=A0


2) You set an explicit switch in your client model that says whether t=
o use the DN or the SAN fields in comparison, and your code branches based =
on that to either DN or SAN processing. This could also be added as an expl=
icit client metadata field,
 or it could be an internal detail. If an internal detail, we should be exp=
licit about there not being a predefined precedence between the fields.=C2=
=A0


3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s set in the client, and at least one field MUST be set.











What=E2=80=99s the intended behavior for implementers, and should we b=
e more explicit about this? We are starting our implementation with (1) pen=
ding the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are implementing this in their systems.=C2=A0







Thanks,





=E2=80=94 Justin













_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





















--0000000000000059810585ba950f--


From nobody Fri Apr  5 00:18:30 2019
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 E4D28120378 for ; Fri,  5 Apr 2019 00:18:27 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=willeke-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 CQsQPIe6mqRP for ; Fri,  5 Apr 2019 00:18:24 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 DC9BA120376 for ; Fri,  5 Apr 2019 00:18:23 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id a6so4078611oie.5 for ; Fri, 05 Apr 2019 00:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yU9QubUImBuzj6xX13FYCBW0rGJlcap0qDt1oMMSU3g=; b=G/Ox6IveFHtRyJyp0ys10bb2tUNhxAx+voBy18N96Kjty258zlTYdpRo6/buVdAFIQ XhiHNrWyjbrEZAoD8k7mNtlbyowyLumrSwgc1uupd1sWaHDAtaDsBNOLqur0tkKsiqBz 8FltnDNJnmQpHK0FHbUDaddoOMBP1v55qjjpT6uHMlXNXJDIxGjhfrsGsXe5FNXE2yVi QKL7CvgWSLgGXgqI7AUWMtnYzXQWa12CS22qui5t/iMcr4dR2Ltqw8JYY6If1Az4S9Qu SQjc7Pp8r+o/RPtAcHmHJWtLqB/hSlQhdVeseKptg6kfSgCJONefiBVH4lr/BNITS9K3 V4mg==
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=yU9QubUImBuzj6xX13FYCBW0rGJlcap0qDt1oMMSU3g=; b=ZZNZjGLU/zrKjKXuLMyPBJPUVZgYmQ7o7qMiqA7rWOiHBfD38udMc1q5hzK9Rlixoh eRgcfRh0uXNmNbODhsmOtS8fud2V2xuulcDx0dHXSF8tBH12yar6sYWhiEZ+C522YB8j t5l9iVrOwF5ueV5xW1P/2ycpNHKGyu3417DsqVIPEiKLw8UXNW0X0oeFSTX6Gh38MrAC 1cO0XCkkKA8CO5/t3CksidAXhjW697H7AEsAm5EGiKipNXVanNJDUAHQenVbUfsbYWUe xhbZUxi0I7FvMrTET0VZUM8Hpx6PTBbbIDUEw05iI7zy58wP5C3qiAOwQguwOFXJv/Rb +UiA==
X-Gm-Message-State: APjAAAWSK1Mi7ytCDdTUstkaat4E6YExvHkKvi3+ce9V6MTkbgnTmSr2 HfPYgfUUbUJwpbVLGMt6BO7YAZiOhsi+FONSpoTQfmw/rUfRkg==
X-Google-Smtp-Source: APXvYqycEG29x42gtH/r5bsCg4+Xg8YdxeYbq7YlOmEQj0PyM1nuPbwZn+RTjZ/FrITfBasYI6DvKQ7PKdHMlDz6Pi4=
X-Received: by 2002:aca:b841:: with SMTP id i62mr6445124oif.103.1554448702627;  Fri, 05 Apr 2019 00:18:22 -0700 (PDT)
MIME-Version: 1.0
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>  <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu> 
In-Reply-To: 
From: Jim Willeke 
Date: Fri, 5 Apr 2019 03:17:45 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000bdf8dd0585c34ad4"
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 05 Apr 2019 07:18:28 -0000

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

I may not be completely up to date in this discussion,  However, RFC 6125

"In general, *this specification recommends and prefers* use of
   subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the
   subject field (CN-ID) where possible, as more completely described in
   the following sections.  However, specifications that reuse this one
   can legitimately encourage continued support for the CN-ID identifier
   type if they have good reasons to do so, such as backward
   compatibility with deployed infrastructure (see, for example,
   [EV-CERTS])."

And I believe this is the more common practice.
https://security.stackexchange.com/questions/175786/is-it-required-to-have-=
the-same-domain-name-and-common-name-for-ssl-certificate/175788#175788

--
-jim
Jim Willeke


On Thu, Apr 4, 2019 at 4:55 PM Filip Skokan  wrote:

> Yes.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:
>
>> Thank you, I did miss that text. This should be called out more
>> explicitly in =C2=A72.1, perhaps by specifying that it is only one field=
. This
>> still doesn=E2=80=99t set precedence, but it implies that it=E2=80=99s a=
n error for a
>> client to have more than one field set of the available options. Is that
>> your read on this as well?
>>
>> =E2=80=94 Justin
>>
>> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>>
>> Justin, I had the exact same question off list and believe draft 13
>> clarified this.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>>
>> A client using the "tls_client_auth" authentication method MUST use
>> exactly one of the below metadata parameters to indicate the certificate
>> subject value that the authorization server is to expect when
>> authenticating the respective client.
>>
>> Then it lists the different dn/san properties.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>>
>>> We=E2=80=99ve just started implementation of SAN-based certificate
>>> authentication, based on the changes in version -13 of the draft. I bel=
ieve
>>> this addition is a bit unclear, due to it being added so late in the
>>> document process.
>>>
>>> My question is how does an AS determine whether to DN or SAN for
>>> certificate checking? Corollary, are these mutually exclusive or can th=
ey
>>> be used together? Currently, the specification text lists DN and SAN as=
 an
>>> =E2=80=9Cor=E2=80=9D with no indication whether this is an inclusive or=
 exclusive =E2=80=9Cor=E2=80=9D, and
>>> what to do when there=E2=80=99s overlap.
>>>
>>> This has implications both for the implementation of the server
>>> processing the request as well as the client metadata model, since the
>>> client fields are all in parallel to each other. I can see a few ways o=
f
>>> handling this.
>>>
>>>
>>> 1) One of the fields takes precedence over the other. Say for example
>>> you choose the DN field: if it=E2=80=99s set, then you do DN matching a=
nd ignore
>>> the SAN fields entirely, both in the cert and in the client=E2=80=99s r=
egistration.
>>> Inverse is true if you choose the SAN fields over the DN but the princi=
ple
>>> is the same. We should be explicit if there=E2=80=99s an intended prece=
dence
>>> between these two, and even more explicit if the DN and SAN are at equa=
l
>>> level and the AS gets to choose. We also need to be clear if it=E2=80=
=99s an error
>>> condition if both are set simultaneously, like the way that jwks and
>>> jwks_uri are mutually exclusive.
>>> 2) You set an explicit switch in your client model that says whether to
>>> use the DN or the SAN fields in comparison, and your code branches base=
d on
>>> that to either DN or SAN processing. This could also be added as an
>>> explicit client metadata field, or it could be an internal detail. If a=
n
>>> internal detail, we should be explicit about there not being a predefin=
ed
>>> precedence between the fields.
>>> 3) If it=E2=80=99s allowable to use them together, you match everything=
 that=E2=80=99s
>>> set in the client, and at least one field MUST be set.
>>>
>>>
>>> What=E2=80=99s the intended behavior for implementers, and should we be=
 more
>>> explicit about this? We are starting our implementation with (1) pendin=
g
>>> the outcome of this thread, and I=E2=80=99d be curious to know how othe=
rs are
>>> implementing this in their systems.
>>>
>>> Thanks,
>>> =E2=80=94 Justin
>>>
>>> _______________________________________________
>>> 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
>

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


I may not be completely up to date in thi=
s discussion,=C2=A0 However,=C2=A0RFC 6125=C2=A0
"In general,=
=C2=A0this specification recommends and prefers=C2=A0use of
=C2=A0 =C2=A0subjectAltName entries (DNS-ID, SRV-ID, URI-ID, =
etc.) over use of the
=C2=A0 =C2=A0subject field (CN-=
ID) where possible, as more completely described in
=
=C2=A0 =C2=A0the following sections.=C2=A0 However, specifications that reu=
se this one
=C2=A0 =C2=A0can legitimately encourage c=
ontinued support for the CN-ID identifier
=C2=A0 =C2=
=A0type if they have good reasons to do so, such as backward
=C2=A0 =C2=A0compatibility with deployed infrastructure (see, for =
example,
=C2=A0 =C2=A0[EV-CERTS])."


On Thu, Apr 4, 2019=
 at 4:55 PM Filip Skokan <panva.ip=
@gmail.com> wrote:
Yes.

S pozdravem,
F=
ilip Skokan


<=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Apr 2019 at 22:36, Justin Ri=
cher <jricher@mit.e=
du> wrote:

=E2=80=94 Justin









On Apr 4, 2019, at 4:23 PM, Filip Skokan <panva.ip@gmail.com> wrote:










Justin, I had the exact same question off list and believe=
 draft 13 clarified this.












A client using the=C2=A0"tls_client_auth" authentication met=
hod MUST use exactly one of the below metadata parameters to indicate the c=
ertificate subject value that the authorization server is to expect when au=
thenticating the respective client.









Then it lists the different dn/san properties.









S pozdravem,

Filip Skokan




















On Thu, 4 Apr 2019 at 22:20, Justin R=
icher <jricher@mit.=
edu> wrote:






We=E2=80=99ve just started implementation of SAN-based certificate aut=
hentication, based on the changes in version -13 of the draft. I believe th=
is addition is a bit unclear, due to it being added so late in the document
 process.=C2=A0






My question is how does an AS determine whether to DN or SAN for certi=
ficate checking? Corollary, are these mutually exclusive or can they be use=
d together?=C2=A0Currently, the specification text lists DN and SAN as an =
=E2=80=9Cor=E2=80=9D with no indication whether
 this is an inclusive or exclusive =E2=80=9Cor=E2=80=9D, and what to do whe=
n there=E2=80=99s overlap.=C2=A0






This has implications both for the implementation of the server proces=
sing the request as well as the client metadata model, since the client fie=
lds are all in parallel to each other. I can see a few ways of handling thi=
s.











1) One of the fields takes precedence over the other. Say for example =
you choose the DN field: if it=E2=80=99s set, then you do DN matching and i=
gnore the SAN fields entirely, both in the cert and in the client=E2=80=99s=
 registration. Inverse is true if you choose
 the SAN fields over the DN but the principle is the same. We should be exp=
licit if there=E2=80=99s an intended precedence between these two, and even=
 more explicit if the DN and SAN are at equal level and the AS gets to choo=
se. We also need to be clear if it=E2=80=99s an
 error condition if both are set simultaneously, like the way that jwks and=
 jwks_uri are mutually exclusive.=C2=A0


2) You set an explicit switch in your client model that says whether t=
o use the DN or the SAN fields in comparison, and your code branches based =
on that to either DN or SAN processing. This could also be added as an expl=
icit client metadata field,
 or it could be an internal detail. If an internal detail, we should be exp=
licit about there not being a predefined precedence between the fields.=C2=
=A0


3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s set in the client, and at least one field MUST be set.











What=E2=80=99s the intended behavior for implementers, and should we b=
e more explicit about this? We are starting our implementation with (1) pen=
ding the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are implementing this in their systems.=C2=A0







Thanks,





=E2=80=94 Justin













_______________________________________________

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



--000000000000bdf8dd0585c34ad4--


From nobody Fri Apr  5 10:13:43 2019
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 7B1C112047C for ; Fri,  5 Apr 2019 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcErE6wtc_AN for ; Fri,  5 Apr 2019 10:13:39 -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 A1B2612007A for ; Fri,  5 Apr 2019 10:13:39 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id m10so6315610otp.2 for ; Fri, 05 Apr 2019 10:13: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=YKHN6s0bcau9jtDq+B5bMDlK4ubbkxN7SsopozMd7jY=; b=g20qroziqMEKf0HhbvsJzk+ntzILUeQO+C+rhYyJQh7agvkcs0FHrXkLJkqWI64dQg OdcjJBIY+oUHhapl22iobzusvcEhuqVzeivny3phabRH8KAsXC/KxkBZNZwqXkEt2VL6 Y0dN3BIgWNf25fy9hcJXAshenZBzFEbgZuxBprfvnb65WCgGyBOBpuq0HDXHv0LYZUd4 oDsQaTJh7xuWLZC+G/r0PW7TPntXp7e/NhyraUqgwzp003UoFoN6JBHrJEhXxLX7AbKD /8Jb2K4H3fGUL+aDXJF2+MDa5TQqUvZdQdiPhhwZklLLPe9Gnnicqr3mcxlEuNRNBsSC +cZA==
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=YKHN6s0bcau9jtDq+B5bMDlK4ubbkxN7SsopozMd7jY=; b=RdfHsQvLr6aY//JMqbEp3/KOkYuVFFjh44ORBCnEYCtiAxGev1XRFEjhAqMG5JoBwT VSTF+H4zl9aOaQE5+wRQ71iGSdjmyjGFyiQ/Y8CK5ETKG7XfAoehBvV6b8HU4XKssVjU XEMloacUXz4BPjD0V1uNXXPlK322EVMRblUSNxGQYvt4LgDndq8REpZPfn1fJxCpsw41 OblHUAl3/Di8p3PPG5mE/YRtnCPSXaOJo+PqQW9yt+iN6mlszW2xgj4rx5HpKHaXAJFH Je9bdeyFRV/u1jN37i4orn5TKzbBwOUffE7Ey2d3LR8i9KhGw2BucybEzb5+lJxb3P/L CmfQ==
X-Gm-Message-State: APjAAAVRoLWNXhK5HuLZam2BiSKEEintC4oQcPVxO/OlOz3xeqNwIJmc 6ECiUZsGJujLOnm/v/q/0iahMBoIehoMDCKfeRkZNNs=
X-Google-Smtp-Source: APXvYqw0xDVlWKjHmjUOT1RduGmR3rtWE8klQJaQ4nyi4eTUV6FesTBt8a/YnrH+/JaI676rFR79XlDSwLUl3m2upjw=
X-Received: by 2002:a9d:6313:: with SMTP id q19mr9167149otk.90.1554484418596;  Fri, 05 Apr 2019 10:13:38 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan 
Date: Fri, 5 Apr 2019 19:13:27 +0200
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="00000000000094566a0585cb9b72"
Archived-At: 
Subject: [OAUTH-WG] CORS and the Device Authorization Grant (device flow)
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, 05 Apr 2019 17:13:42 -0000

--00000000000094566a0585cb9b72
Content-Type: text/plain; charset="UTF-8"

Hello *,

I recall implementing an early draft of this flow few years ago for a
client landscape composed primarily of older set-top boxes, old and new TV
models of various brands (LG, Samsung, Sony) and also HbbTV standards 1.5
and 2.0.

I remember having to set up CORS on both the device authorization and token
endpoints (unheard of at the time!) for the sake of these clients.

The reason they required CORS is that these were implemented using, mostly
proprietary, xhtml/html5 based sandboxes running on those devices. The APIs
developers were given were javascript ones, more specifically the http
client was obviously XMLHttpRequest and the whole app when being developed
was debugged in a regular browser.

Since the specification does not mention CORS anywhere I wonder if
a) I was deceived by our business partners to think this was a generic
problem of these client types and not just developers being lazy to turn
off cors when debugging,
b) this was corrected or
c) it's still happening and noone just didn't brought it up

What are your experiences with CORS setup on the device authorization and
token endpoints in relation to device flow for Smart TV, set-top boxes and
HbbTV stream apps (excluding tvOS and AndroidTV).

Best,
*Filip*

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


Hello *,

I recall implementi=
ng an early draft of this flow few years ago for a client landscape compose=
d primarily of older set-top boxes, old and new TV models of various brands=
 (LG, Samsung, Sony) and also HbbTV standards 1.5 and 2.0.

I remember having to set up CORS on both the device authorization =
and token endpoints (unheard of at the time!) for the sake of these clients=
.

The reason they required CORS is that these =
were implemented using, mostly proprietary, xhtml/html5 based sandboxes run=
ning on those devices. The APIs developers were given were javascript ones,=
 more specifically the http client was obviously XMLHttpRequest and the who=
le app when being developed was debugged in a regular browser.
Since the specification does not mention CORS anywhere I wonde=
r if
a) I was deceived by our business partners to think this was=
 a generic problem of these client types and not just developers being lazy=
 to turn off cors when debugging,
b) this was corrected or
<=
div>c) it's still happening and noone just didn't brought it up

What are your experiences with CORS setup on the devi=
ce authorization and token endpoints in relation to device flow for Smart T=
V, set-top boxes and HbbTV stream apps (excluding tvOS and AndroidTV).
Best,
Filip


--00000000000094566a0585cb9b72--


From Jorgen.Binningsbo@difi.no  Tue Mar 26 09:35:23 2019
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 EC8BE1205E6 for ; Tue, 26 Mar 2019 09:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=difidrift.onmicrosoft.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 2s_gD6j8mm8g for ; Tue, 26 Mar 2019 09:35:18 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140058.outbound.protection.outlook.com [40.107.14.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4071206B2 for ; Tue, 26 Mar 2019 09:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=difidrift.onmicrosoft.com; s=selector1-difi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LaJmJU+sotKN5HGNDGGVi6bB6qzeOElGdaW/sZBodNU=; b=lB2xhyWgzhsPsQSE0vplR9tM/u6+9eCdyzb1E4ps6E7B5HOeenxgY+KRzfSOGlWGbKJAXdcl34wi5Nm5xF3KL8dO7t3RPZ69I+Em0vWOO/17XSfWmNe5FO5To4dqaZi3rjpQLadJg5ywVUlPTFKc1ZNKcF3n6b3yyIftYjQVxIg=
Received: from HE1PR0102MB2585.eurprd01.prod.exchangelabs.com (10.170.251.138) by HE1PR0102MB3084.eurprd01.prod.exchangelabs.com (10.167.35.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 16:35:02 +0000
Received: from HE1PR0102MB2585.eurprd01.prod.exchangelabs.com ([fe80::bc28:a6c2:2867:f6d]) by HE1PR0102MB2585.eurprd01.prod.exchangelabs.com ([fe80::bc28:a6c2:2867:f6d%4]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 16:35:02 +0000
From: =?utf-8?B?QmlubmluZ3Niw7gsIErDuHJnZW4=?= 
To: Dave Tonge , Dominick Baier 
CC: IETF oauth WG 
Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Thread-Index: AQHU4plzwvKjf6KddUWNfr1RQV+wAKYbvMyAgACe2ICAAAThAIAAC2CAgAABTACAAJjzgIAADBmAgABhiACAACJSAIAAgWGw
Date: Tue, 26 Mar 2019 16:35:01 +0000
Message-ID: 
References:          
In-Reply-To: 
Accept-Language: nb-NO, en-US
Content-Language: nb-NO
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jorgen.Binningsbo@difi.no; 
x-originating-ip: [79.170.81.253]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c533531a-9e87-43e0-239b-08d6b208fe9f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0102MB3084; 
x-ms-traffictypediagnostic: HE1PR0102MB3084:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39850400004)(136003)(396003)(376002)(346002)(366004)(51914003)(189003)(199004)(52314003)(25786009)(110136005)(7736002)(2906002)(476003)(54896002)(97736004)(85182001)(14444005)(256004)(71190400001)(71200400001)(14454004)(8936002)(486006)(6306002)(6116002)(5660300002)(7696005)(66066001)(74482002)(236005)(4326008)(30864003)(9686003)(186003)(45080400002)(52536014)(53936002)(66574012)(53386004)(8676002)(55016002)(106356001)(68736007)(11346002)(26005)(85202003)(74316002)(446003)(3846002)(102836004)(478600001)(6436002)(5070765005)(93886005)(33656002)(53546011)(517774005)(606006)(76176011)(6506007)(966005)(81166006)(316002)(81156014)(99286004)(86362001)(72206003)(105586002)(777600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0102MB3084; H:HE1PR0102MB2585.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: difi.no does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6S2ijetImx03ne+MlstoTO9LW/sV2WHEX+LhIF9a/yoXt2zdUddYUe1wCB3uVtGtk6xf7F6gHLcsey0kgW9tdlOfwjLZ8son0NGvSKKZAamhi6tEQjC+EOoKqHcky9jShoW1co+S/d9ifpQuyeWsa6J4jQV9zKvNESsCW/L+oZRNRqgSzd/SFVWO94jKh3JApJK641YdCXtd9W96kfC14WpQhtpiQospFwKT2Ej7EvvJZzzG7G41gjEmbgNcjXgSCFAszOkiUpjoGHOxUGnEOHLxqEMsOFiFR5ec1cDjBDJDhG6Qu55HNDQfIXxnOp3IORzZligXrK9Swq+PdiVunmqLRLyO0Am8HeWSLaC+Lei0bYQlEATaA2/aUSXAG4/Iprw7Ix02KuwyDRKf5WQJT/PVVRMv3S1qZeOwJ7ceVy8=
Content-Type: multipart/alternative; boundary="_000_HE1PR0102MB2585D9664A190C7EC7000BD7F75F0HE1PR0102MB2585_"
MIME-Version: 1.0
X-OriginatorOrg: difi.no
X-MS-Exchange-CrossTenant-Network-Message-Id: c533531a-9e87-43e0-239b-08d6b208fe9f
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 16:35:01.9367 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 250f5e75-599c-4614-9707-0ced6114ffc6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0102MB3084
Archived-At: 
X-Mailman-Approved-At: Fri, 05 Apr 2019 10:43:30 -0700
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 16:37:04 -0000

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

SGksDQoNCg0KDQpXZSBoYXZlIGEgbWFjaGluZS10by1tYWNoaW5lIHNjZW5hcmlvIHdoZXJlIGNs
aWVudHMsIFJTZXMgYW5kIG91ciBBUyBhbGwgYmVsb25nIHRvIGRpZmZlcmVudCBsZWdhbCBlbnRp
dGllcy4NCg0KDQoNClNvbWUgUlNlcyByZXF1aXJlIHRoZWlyIGNsaWVudHMgdG8gbGltaXQgdGhl
IGFjY2VzcyB0b2tlbiB0byBhIHNwZWNpZmljIFJlc291cmNlIE93bmVyLCB3aGlsZSBvdGhlciBS
U2VzIGRvbid0LiBJbiB0aGUgZm9ybWVyIGNhc2UsIHdlIHVzZSAnc3ViJyB0byBpZGVudGlmeSB0
aGF0IFJlc291cmNlIE93bmVyLiAgSW4gc3VjaCBhIG1peGVkIGRlcGxveW1lbnQgc2NlbmFyaW8s
IGFsbG93aW5nIHVzaW5nICdzdWInIGZvciBkaWZmZXJlbnQgbWVhbmluZ3MgY2FuIGxlYWQgdG8g
Y29uZnVzaW9uLCBzbyBJIHRoaW5rIHRoZSBhY3R1YWwgbWVhbmluZyBzaG91bGQgYmUgZXhwbGlj
aXRseSBzaWduYWxsZWQgbGlrZSBEYXZlIHN1Z2dlc3RzIGJlbG93Lg0KDQoNCg0KSGF2aW5nIHNh
aWQgdGhhdCwgSSBkbyBwcmVmZXIgdG8gbGltaXQgdGhlIHVzYWdlIG9mICdzdWInIGluIGFjY2Vz
cyB0b2tlbnMgZm9yIHRoZSBFbmQgVXNlciBvbmx5Lg0KDQoNCg0KDQoNCkFzIGEgc2lkZSBub3Rl
LCBpbiBvdXIgY2FzZSB3ZSBuZWVkIGEgbW9yZSBmb3JtYWwgY2xpZW50IGlkZW50aWZpY2F0aW9u
IHRoYW4gdGhlIGNsaWVudF9pZCBhbG9uZSAoYXMgdGhleSBhcmUgcmFuZG9tbHkgZ2VuZXJhdGVk
IGJ5IERDUiksICBhbmQgaGF2ZSB0aHVzIG9wdGVkIGZvciBhIGN1c3RvbSBjbGFpbSBgY2xpZW50
X293bmVyYCBjb250YWluaW5nIHRoZSByZWdpc3RlcmVkIGNvbXBhbnkgaWRlbnRpZmllci4gIFdl
IHB1bGwgdGhpcyBvdXQgZnJvbSBjZXJ0aWZpY2F0ZSB1c2VkIHRvIHNpZ24gdGhlIEpXVC1ncmFu
dCAoUkZDNzUyMykgZnJvbSB0aGUgdG9rZW4gcmVxdWVzdC4gICBXZSBjb3VsZCBvZiBjb3Vyc2Ug
aGF2ZSB1c2VkIOKAmHN1YuKAmSBmb3IgY2xpZW50X293bmVyLCBidXQgdGhhdCB3b3VsZCByZXF1
aXJlIHVzIHRvIGludmVudCBhbm90aGVyIGN1c3RvbSBjbGFpbSBmb3IgdGhvc2UgUlNlcyB0aGF0
IHJlcXVpcmVzIFJPLWxpbWl0ZWQgdG9rZW5zLiAgICBUbyBtYWtlIG1hdHRlcnMgZXZlbiBtb3Jl
IGNvbXBsaWNhdGVkLCB0aGVyZSBtaWdodCBiZSBidXNpbmVzcyBkZWxlZ2F0aW9uIGhhcHBlbmlu
ZywgIHdoZXJlIGNvbXBhbnkgQSBydW5uaW5nIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFs
ZiBvZiBkaWZmZXJlbnQgb3RoZXIgY29tcGFuaWVzIEIsQyxE4oCmIGFuZCB0aGUgaW5zdGFudGFu
ZW91cyBBK0Igb3IgQStDIHJlbGF0aW9uIGFsc28gaGF2ZSB0byBiZSBjb21tdW5pY2F0ZWQgaW4g
dGhlIHRva2VuICAoQWNjb3JkaW5nIHRvIEVVIHByaXZhY3kgbGF3cywgSSBiZWxpdmUgQSBpcyB0
aGUgRGF0YSBQcm9jZXNzb3IgYW5kIHRoZWlyIGN1c3RvbWVyIEIsQyxE4oCmIGFyZSBEYXRhIENv
bnRyb2xsZXIpLiAgIFNvIGFnYWluIHRoaXMgbGVhZHMgbWUgdG8gdGhpbmsgdGhhdCBjbGllbnQg
aWRlbnRpZmljYXRpb24gc2hvdWxkIGJlIGtlcHQgaW4gc2VwYXJhdGUgY2xhaW1zLg0KDQoNCg0K
QW55d2F5LCBmb3IgdXMgYXMgdXNlciBvZiB0aGUgb2F1dGgyIHByb3RvY29scywgdGhpcyBkcmFm
dCBpcyB3ZWxjb21lICENCg0KDQoNCg0KDQpLaW5kIHJlZ2FyZHMsDQotLQ0KSsO4cmdlbiBCaW5u
aW5nc2LDuA0KUHJvZHVjdCBPd25lciwgTm9yd2VnaWFuIE5hdGlvbmFsIGVJRCBJbmZyYXN0cnVj
dHVyZSAoSUQtcG9ydGVuKQ0KDQpGcmE6IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBQ
w6UgdmVnbmUgYXYgRGF2ZSBUb25nZQ0KU2VuZHQ6IHRpcnNkYWcgMjYuIG1hcnMgMjAxOSAwOS4y
Nw0KVGlsOiBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbT4NCktvcGk6
IElFVEYgb2F1dGggV0cgPG9hdXRoQGlldGYub3JnPg0KRW1uZTogUmU6IFtPQVVUSC1XR10gZHJh
ZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMA0KDQpUaGFua3MgVml0dG9yaW8g
Zm9yIHlvdXIgcHJlc2VudGF0aW9uIGFuZCBwdXR0aW5nIHRoaXMgZHJhZnQgdG9nZXRoZXIuDQoN
CkkgYWdyZWUgd2l0aCBEb21pbmNrIHRoYXQgdGhlcmUgaXMgYSBwb3RlbnRpYWwgb2YgdGhpbmdz
IGdvaW5nIHdyb25nIHdoZW4gYHN1YmAgaGFzIG11bHRpcGxlIG1lYW5pbmdzLg0KSG93ZXZlciBJ
IGNhbiBzZWUgdGhhdCB1c2luZyBgc3ViYCBmb3IgYSBjbGllbnRfaWQgc2VtYW50aWNhbGx5IG1h
a2VzIHNlbnNlIGluIHNvbWUgc2l0dWF0aW9ucyBhbmQgSSBhZ3JlZSB0aGF0IGl0IG1ha2VzIGl0
IHNpbXBsZXIgZnJvbSBhbiBTREsgcG9pbnQgb2YgdmlldyBmb3IgdGhlcmUgdG8gYWx3YXlzIGJl
IGEgYHN1YmAuDQoNCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdGhhdCBlaXRoZXIgdGhlcmUgaXMg
YW4gZXhwbGljaXQgdHlwZSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gInVzZXIgYWNjZXNzIHRv
a2VucyIgYW5kICJhcHBsaWNhdGlvbiBhY2Nlc3MgdG9rZW5zIiwgb3IgZmFpbGluZyB0aGF0IHRo
ZSBgc3ViYCBpcyB1c2VkIHRvIGluZGljYXRlIHRoZSBkaWZmZXJlbmNlLg0KDQpGdXJ0aGVybW9y
ZSBhbiBhZ3JlZW1lbnQgb24gdGhlIG5hbWluZyBhbmQgZGVzY3JpcHRpb24gb2YgdGhlc2UgdHdv
IHR5cGVzIG9mIGFjY2VzcyB0b2tlbnMgd291bGQgYmUgaGVscGZ1bCBtb3JlIGdlbmVyYWxseS4N
Cg0KRGF2ZQ0KDQpPbiBUdWUsIDI2IE1hciAyMDE5IGF0IDA3OjI1LCBEb21pbmljayBCYWllciA8
ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNv
bT4+IHdyb3RlOg0KRnJvbSBhbiBhY2Nlc3MgdG9rZW4gY29uc3VtZXIgKGFrYSBBUEkpIGRldmVs
b3BlciBwb2ludCBvZiB2aWV3LCBJIHByZWZlciB0aGlzIGxvZ2ljDQoNCiJJZiBzdWIgaXMgcHJl
c2VudCAtIGNsaWVudCBhY3RzIG9uIGJlaGFsZiBvZiBhIHVzZXIsIGlmIG5vdCAtIG5vdC4iDQoN
CkFueXRoaW5nIG1vcmUgY29tcGxpY2F0ZWQgaGFzIGEgcG90ZW50aWFsIG9mIGdvaW5nIHdyb25n
Lg0KDQoNCg0KT24gMjYuIE1hcmNoIDIwMTkgYXQgMDE6MzQ6NTMsIE5vdiBNYXRha2UgKG1hdGFr
ZUBnbWFpbC5jb208bWFpbHRvOm1hdGFrZUBnbWFpbC5jb20+KSB3cm90ZToNCkhpIFZpdHRvcmlv
LA0KDQpZZWFoLCBJ4oCZbSBjb25jZXJuaW5nIHVzZXIgJiBjbGllbnQgaWRzIGNvbGxpc2lvbi4N
CkkgaGF2ZW7igJl0IHNlZW4gc3VjaCBpbXBsZW1lbnRhdGlvbnMsIGJ1dCB1c2VyLXNlbGVjdCB1
c2VybmFtZSBhcyBzdWIsIG9yIGluY3JlbWVudGFsIGludGVnZXIgYXMgc3ViICYgY2xpZW50X2lk
IHdpbGwgYmUgZWFzaWx5IGNvbGxpZGUuDQoNCklmIHlvdSBjYW4gZW5mb3JjZSBjb2xsaXNpb24g
cmVzaXN0YW50IElEcyBiZXR3ZWVuIHVzZXIgJiBjbGllbnQgaW5zdGFuY2VzLCBpdOKAmWxsIHdv
cmtzIGZpbmUuIEkgZmVlbCBpdHMgb3ZlcmtpbGwgdGhvdWdoLg0KDQpTZW50IGZyb20gbXkgaVBo
b25lDQoNCk9uIE1hciAyNiwgMjAxOSwgYXQgODo1MSwgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRv
cmlvQGF1dGgwLmNvbTxtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tPj4gd3JvdGU6DQpIZXkgTm92
LCBEb21pbmljaywgSGFucy0NCnRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBUaGF0IHdhcyBhbiBh
cmVhIEkgd2FzIGV4cGVjdGluZyB0byBjYXVzZSBtb3JlIGRpc2N1c3Npb24sIGFuZCBJIGFtIGds
YWQgd2UgYXJlIGhhdmluZyB0aGlzIG9wcG9ydHVuaXR5IHRvIGNsYXJpZnkuDQpUaGUgY3VycmVu
dCBsYW5ndWFnZSBpbiB0aGUgZHJhZnQgdHJhY2VzIHRoZSBldHltb2xvZ3kgb2Ygc3ViIHRvIE9w
ZW5JRCBDb25uZWN0IGNvcmUsIGhlbmNlIERvbWluaWNrIG9ic2VydmF0aW9uIGlzIG9uIHBvaW50
LiBIb3dldmVyIGluIHRoZSBkZXNjcmlwdGlvbiBJIGV4cHJlc3Mgc29tZXRoaW5nIGluIGxpbmUg
d2l0aCA3NTE5LCB3aGljaCB3YXMgaW4gZmFjdCBteSBpbnRlbnQuDQoNClRoZSBpZGVhIHdhcyB0
byBwcm92aWRlIGFuIGlkZW50aWZpZXIgb2YgdGhlIGNhbGxpbmcgc3ViamVjdCB0aGF0IGlzIGd1
YXJhbnRlZWQgdG8gYmUgcHJlc2VudCBpbiBhbGwgY2FzZXMtIHRoaXMgd291bGQgYWxsb3cgYW4g
U0RLIGRldmVsb3BlciB0byB1c2UgdGhlIHNhbWUgY29kZSBmb3IgdGhpbmdzIGxpa2UgbG9va3Vw
cyBhbmQgbWVtYmVyc2hpcCBjaGVja3MgcmVnYXJkbGVzcyBvZiB0aGUgbmF0dXJlIG9mIHRoZSBj
YWxsZXIgKHVzZXIgaW4gYSBkZWxlZ2F0ZWQgY2FzZSwgYXBwIGluIGFwcC1vbmx5IGdyYW50cyku
IFRoZSBpbmZvcm1hdGlvbiB0byBkaXNjcmltaW5hdGUgYmV0d2VlbiB1c2VyIGFuZCBhcHAgY2Fs
bGVycyBpcyBhbHdheXMgYXZhaWxhYmxlIGluIHRoZSB0b2tlbiAoc2F5LCB0aGUgY2FsbGVyIGlz
IGEgdXNlciBpZiBzdWIhPWNsaWVudF9pZCwgd2hlcmUgY2xpZW50X2lkIGlzIGFsd2F5cyBndWFy
YW50ZWVkIHRvIGJlIHByZXNlbnQgYXMgd2VsbCkgaGVuY2UgdGhlcmUncyBubyBsb3NzIGluIGV4
cHJlc3NpdmUgcG93ZXIsIHNob3VsZCB0aGF0IGRpZmZlcmVuY2UgYmUgcmVsZXZhbnQgZm9yIHRo
ZSByZXNvdXJjZSBzZXJ2ZXIuDQoNCkRvbWluaWNrLCBIYW5zLSBJIHByb2JhYmx5IG1pc3NlZCB0
aGUgc2VjdXJpdHkgaXNzdWUgeW91IGd1eXMgYXJlIHRoaW5raW5nIG9mIGluIHRoaXMgY2FzZS4g
T2YgY291cnNlLCBpZiB0aGlzIHdvdWxkIGludHJvZHVjZSBhIHJpc2sgSSBjb21wbGV0ZWx5IGFn
cmVlIGl0IHNob3VsZCBiZSBjaGFuZ2VkLSBJJ2QganVzdCBsaWtlIHRvIHVuZGVyc3RhbmQgYmV0
dGVyIHRoZSBwcm9ibGVtLiBDb3VsZCB5b3UgZXhwYW5kIGl0IGluIGEgc2NlbmFyaW8vdXNlIGNh
c2UgdG8gY2xhcmlmeSB0aGUgcmlzaz8NCk5vdi0gcGxheWluZyB0aGlzIGJhY2s6IGlzIHRoZSBj
b25jZXJuIHRoYXQgYSB1c2VyIGFuZCBhIGNsaWVudCBtaWdodCBoYXZlIHRoZSBzYW1lIGlkZW50
aWZpZXIgd2l0aGluIGFuIElEUD8gV2hlbiB1c2luZyBjb2xsaXNpb24gcmVzaXN0YW50IElEcywg
YXMgaXQgaXMgdXN1YWxseSB0aGUgY2FzZSwgdGhhdCBzZWVtcyB0byBiZSBhIHJlbW90ZSBwb3Nz
aWJpbGl0eS0gZGlkIHlvdSBzdHVtYmxlIGluIHN1Y2ggc2NlbmFyaW8gaW4gcHJvZHVjdGlvbj8N
Cg0KVGhhbmtzDQpWLg0KDQoNCk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDc6NDQgQU0gSGFucyBa
YW5kYmVsdCA8aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRA
em1hcnR6b25lLmV1Pj4gd3JvdGU6DQpJIGJlbGlldmUgdGhlcmUgYXJlIHBsZW50eSBvZiBPQXV0
aCAyLjAgb25seSB1c2UgY2FzZXMgb3V0IHRoZXJlLi4uIGJ1dCBuZXZlcnRoZWxlc3MgSSBhZ3Jl
ZSB3aXRoIHRoZSBwb3RlbnRpYWwgY29uZnVzaW9uIGFuZCB0aHVzIHNlY3VyaXR5IHByb2JsZW1z
IGFyaXNpbmcgZnJvbSB0aGF0ICh0aG91Z2ggb25lIG1heSBhcmd1ZSB0aGUgc2VtYW50aWNzIGFy
ZSB0aGUgc2FtZSkuDQoNCkhhbnMuDQoNCk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDM6MzkgUE0g
RG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5jb208bWFpbHRvOmRiYWllckBs
ZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNClllcyBJIGtub3cgLSBhbmQgSSB0aGluayBpbiBo
aW5kc2lnaHQgaXQgd2FzIGEgbWlzdGFrZSB0byB1c2UgdGhlIHNhbWUgY2xhaW0gdHlwZSBmb3Ig
bXVsdGlwbGUgc2VtYW50aWNzLg0KDQpBbGwgdGhlIOKAnHRoaXMgaXMgT0lEQyBub3QgT0F1dGji
gJ0gYXJndW1lbnRzIGFyZSBtYWtpbmcgdGhpbmdzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGV5
IG5lZWQgdG8gYmUgLSBpbiBteSBleHBlcmllbmNlIGFsbW9zdCBuby1vbmUgKHRoYXQgSSBrbm93
KSBkb2VzIE9JREMgb25seSAtIG5vciBPQXV0aCBvbmx5LiBUaGV5IGFsd2F5cyBjb21iaW5lIGl0
Lg0KDQpJbiByZWFsaXR5IHRoaXMgbGVhZHMgdG8gcG90ZW50aWFsIHNlY3VyaXR5IHByb2JsZW1z
IC0gdGhpcyBzcGVjIGhhcyB0aGUgcG90ZW50aWFsIHRvIHJlY3RpZnkgdGhlIHNpdHVhdGlvbi4N
Cg0KRG9taW5pY2sNCg0KDQpPbiAyNS4gTWFyY2ggMjAxOSBhdCAxNDo1ODo1NiwgSGFucyBaYW5k
YmVsdCAoaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1h
cnR6b25lLmV1Pikgd3JvdGU6DQpXaXRob3V0IGFncmVlaW5nIG9yIGRpc2FncmVlaW5nOiBPSURD
IGRvZXMgbm90IGFwcGx5IGhlcmUgc2luY2UgaXQgaXMgbm90IE9BdXRoIGFuZCBhbiBhY2Nlc3Mg
dG9rZW4gaXMgbm90IGFuIGlkX3Rva2VuLg0KVGhlIEpXVCBzcGVjIHNheXMgaW4gaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMjoNCg0KIlRoZSAic3ViIiAo
c3ViamVjdCkgY2xhaW0gaWRlbnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQgaXMgdGhlDQogICBz
dWJqZWN0IG9mIHRoZSBKV1QuICBUaGUgY2xhaW1zIGluIGEgSldUIGFyZSBub3JtYWxseSBzdGF0
ZW1lbnRzDQogICBhYm91dCB0aGUgc3ViamVjdC4gIFRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0
aGVyIGJlIHNjb3BlZCB0byBiZQ0KICAgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2Yg
dGhlIGlzc3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuDQogICBUaGUgcHJvY2Vzc2luZyBvZiB0
aGlzIGNsYWltIGlzIGdlbmVyYWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYyINCg0Kd2hpY2gga2lu
ZCBvZiBzcGVsbHMgImNsaWVudCIgaW4gY2FzZSBvZiB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdy
YW50IGJ1dCBJIGFsc28gZG8gd29ycnkgYWJvdXQgUmVzb3VyY2UgU2VydmVycyB0aGlua2luZy9h
Y3Rpbmcgb25seSBpbiB0ZXJtcyBvZiB1c2Vycw0KDQpIYW5zLg0KDQpPbiBNb24sIE1hciAyNSwg
MjAxOSBhdCAyOjQxIFBNIERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29t
PG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPj4gd3JvdGU6DQpJTUhPIHRoZSBzdWIg
Y2xhaW0gc2hvdWxkIGFsd2F5cyByZWZlciB0byB0aGUgdXNlciAtIGFuZCBub3RoaW5nIGVsc2Uu
DQoNCk9JREMgc2F5czoNCg0KIlN1YmplY3QgLSBJZGVudGlmaWVyIGZvciB0aGUgRW5kLVVzZXIg
YXQgdGhlIElzc3Vlci4iDQoNCmNsaWVudF9pZCBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSBj
bGllbnRzLg0KDQpjaGVlcnMNCkRvbWluaWNrDQoNCg0KT24gMjUuLiBNYXJjaCAyMDE5IGF0IDA1
OjEzOjAzLCBOb3YgTWF0YWtlIChtYXRha2VAZ21haWwuY29tPG1haWx0bzptYXRha2VAZ21haWwu
Y29tPikgd3JvdGU6DQpIaSBWaXR0b3JpbywNCg0KVGhhbmtzIGZvciB0aGUgZ29vZCBzdGFydGlu
ZyBwb2ludCBvZiBzdGFuZGFyZGl6aW5nIEpXVC1pemVkIEFULg0KDQpPbmUgZmVlZGJhY2suDQpU
aGUg4oCcc3Vi4oCdIGNsYWltIGNhbiBpbmNsdWRlIDIgdHlwZXMgb2YgaWRlbnRpZmllciwgZW5k
LXVzZXIgYW5kIGNsaWVudCwgaW4gdGhpcyBzcGVjLg0KSXQgcmVxdWlyZXMgdGhvc2UgMiB0eXBl
cyBvZiBpZGVudGlmaWVycyB0byBiZSB1bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQIGNvbnRl
eHQuDQoNCkkgcHJlZmVyIG9taXR0aW5nIOKAnHN1YuKAnSBjbGFpbSBpbiAyLWxlZ2dlZCBjb250
ZXh0LCBzbyB0aGF0IG5vIHN1Y2ggY29uc3RyYWludCBuZWVkZWQuDQoNCnRoYW5rcw0KDQpub3YN
Cg0KDQpPbiBNYXIgMjUsIDIwMTksIGF0IDg6MjksIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jp
by5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86dml0dG9yaW8uYmVy
dG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KRGVhciBhbGwsDQpJ
IGp1c3Qgc3VibWl0dGVkIGEgZHJhZnQgZGVzY3JpYmluZyBhIEpXVCBwcm9maWxlIGZvciBPQXV0
aCAyLjAgYWNjZXNzIHRva2Vucy4gWW91IGNhbiBmaW5kIGl0IGluIGh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3QvLg0K
SSBoYXZlIGEgc2xvdCB0byBkaXNjdXNzIHRoaXMgdG9tb3Jyb3cgYXQgSUVURiAxMDQgKEknbGwg
YmUgcHJlc2VudGluZyByZW1vdGVseSkuIEkgbG9vayBmb3J3YXJkIGZvciB5b3VyIGNvbW1lbnRz
IQ0KDQpIZXJlJ3MganVzdCBhIGJpdCBvZiBiYWNrc3RvcnksIGluIGNhc2UgeW91IGFyZSBpbnRl
cmVzdGVkIGluIGhvdyB0aGlzIGRvYyBjYW1lIHRvIGJlLiBUaGUgdHJhamVjdG9yeSBpdCBmb2xs
b3dlZCBpcyBzb21ld2hhdCB1bnVzdWFsLg0KDQogICogICBEZXNwaXRlIE9BdXRoMiBub3QgcmVx
dWlyaW5nIGFueSBzcGVjaWZpYyBmb3JtYXQgZm9yIEFUcywgdGhyb3VnaCB0aGUgeWVhcnMgSSBo
YXZlIGNvbWUgYWNyb3NzIG11bHRpcGxlIHByb3ByaWV0YXJ5IHNvbHV0aW9uIHVzaW5nIEpXVCBm
b3IgdGhlaXIgYWNjZXNzIHRva2VuLiBUaGUgaW50ZW50IGFuZCBzY2VuYXJpb3MgYWRkcmVzc2Vk
IGJ5IHRob3NlIHNvbHV0aW9ucyBhcmUgbW9zdGx5IHRoZSBzYW1lIGFjcm9zcyB2ZW5kb3JzLCBi
dXQgdGhlIHN5bnRheCBhbmQgaW50ZXJwcmV0YXRpb25zIGluIHRoZSBpbXBsZW1lbnRhdGlvbnMg
YXJlIGRpZmZlcmVudCBlbm91Z2ggdG8gcHJldmVudCBkZXZlbG9wZXJzIGZyb20gcmV1c2luZyBj
b2RlIGFuZCBza2lsbHMgd2hlbiBtb3ZpbmcgZnJvbSBwcm9kdWN0IHRvIHByb2R1Y3QuDQogICog
ICBJIGFza2VkIHNldmVyYWwgaW5kaXZpZHVhbHMgZnJvbSBrZXkgcHJvZHVjdHMgYW5kIHNlcnZp
Y2VzIHRvIHNoYXJlIHdpdGggbWUgY29uY3JldGUgZXhhbXBsZXMgb2YgdGhlaXIgSldUIGFjY2Vz
cyB0b2tlbnMgKFRIQU5LIFlPVSBEb21pbmljayBCYWllciAoSWRlbnRpdHlTZXJ2ZXIpLCBCcmlh
biBDYW1wYmVsbCAoUGluZ0lkZW50aXR5KSwgRGFuaWVsIERvYmFsaWFuIChNaWNyb3NvZnQpLCBL
YXJsIEd1aW5uZXNzIChPa3RhKSBmb3IgdGhlIHRva2VucyBhbmQgZXhwbGFuYXRpb25zISkuDQpJ
IHN0dWRpZWQgYW5kIGNvbXBhcmVkIGFsbCB0aG9zZSBpbnN0YW5jZXMsIGlkZW50aWZ5aW5nIGNv
bW1vbmFsaXRpZXMgYW5kIGRpZmZlcmVuY2VzLg0KICAqICAgSSBwdXQgdG9nZXRoZXIgYSBwcmVz
ZW50YXRpb24gc3VtbWFyaXppbmcgbXkgZmluZGluZ3MgYW5kIHN1Z2dlc3RpbmcgYSByb3VnaCBp
bnRlcm9wZXJhYmxlIHByb2ZpbGUgKHNsaWRlczogaHR0cHM6Ly9zZWMudW5pLXN0dXR0Z2FydC5k
ZS9fbWVkaWEvZXZlbnRzL29zdzIwMTkvc2xpZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJvZmlsZV9m
b3JfYXRzLnBwdHg8aHR0cHM6Ly9zZWMuLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9v
c3cyMDE5L3NsaWRlcy9iZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4PiApIC0g
Z290IGVhcmx5IGZlZWRiYWNrIGZyb20gRmlsaXAgU2tva2FuIG9uIGl0LiBUaHggRmlsaXAhDQog
ICogICBUaGUgcHJlc2VudGF0aW9uIHdhcyBmb2xsb3dlZCB1cCBieSAxLjUgaG91cnMgb2YgdW5j
b25mZXJlbmNlIGRpc2N1c3Npb24sIHdoaWNoIHdhcyBpbmNyZWRpYmx5IHZhbHVhYmxlIHRvIGdl
dCB0aWdodC1sb29wIGZlZWRiYWNrIGFuZCBpbmNvcnBvcmF0ZSBuZXcgaWRlYXMuIEpvaG4gQnJh
ZGxleSwgQnJpYW4gQ2FtcGJlbGwgVmxhZGltaXIgRHpodXZpbm92LCBUb3JzdGVuIExvZGRlcnN0
ZWR0LCBOYXQgU2FraW11cmEsIEhhbm5lcyBUc2Nob2ZlbmlnIHdlcmUgYWxsIHRoZXJlIGFuZCBj
b250cmlidXRlZCBnZW5lcm91c2x5IHRvIHRoZSBkaXNjdXNzaW9uLiBUaGFuayB5b3UhISENCk5v
dGU6IGlmIHlvdSB3ZXJlIGF0IE9TVzIwMTksIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lv
biBhbmQgZGlkbid0IGdldCBjcmVkaXRlZCBpbiB0aGUgZHJhZnQsIG15IGFwb2xvZ2llczogcGxl
YXNlIHNlbmQgbWUgYSBub3RlIGFuZCBJJ2xsIG1ha2UgdGhpbmdzIHJpZ2h0IGF0IHRoZSBuZXh0
IHVwZGF0ZS4NCiAgKiAgIE9uIG15IGZsaWdodCBiYWNrIEkgZGlkIG15IGJlc3QgdG8gaW5jb3Jw
b3JhdGUgYWxsIHRoZSBpZGVhcyBhbmQgZmVlZGJhY2sgaW4gYSBkcmFmdCwgd2hpY2ggd2lsbCBi
ZSBkaXNjdXNzZWQgYXQgSUVURjEwNCB0b21vcnJvdy4gUmlmYWF0LCBIYW5uZXMgYW5kIGFib3Zl
IGFsbCBCcmlhbiB3ZXJlIGFsbCBzdXBlciBoZWxwZnVsIGluIG5lZ290aWF0aW5nIHRoZSBteXN0
ZXJpb3VzIHN5bnRheCBvZiB0aGUgUkZDIGZvcm1hdCBhbmQgc3VibWlzc2lvbiBwcm9jZXNzLg0K
SSB3YXMgYmxvd24gYXdheSBieSB0aGUgYXZhaWxhYmlsaXR5LCBpbnZvbHZlbWVudCBhbmQgd2ls
bGluZ25lc3MgdG8gaW52ZXN0IHRpbWUgdG8gZ2V0IHRoaW5ncyByaWdodCB0aGF0IGV2ZXJ5b25l
IGRlbW9uc3RyYXRlZCBpbiB0aGUgcHJvY2Vzcy4gVGhpcyBpcyBhbiBhbWF6aW5nIGNvbW11bml0
eS4NClYuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8bWFpbHRvOmhh
bnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElBTSAtIHd3dy56bWFydHpvbmUu
ZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+DQoNCg0KLS0NCmhhbnMuemFuZGJlbHRAem1hcnR6
b25lLmV1PG1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldT4NClptYXJ0Wm9uZSBJQU0g
LSB3d3cuem1hcnR6b25lLmV1PGh0dHA6Ly93d3cuem1hcnR6b25lLmV1Pg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K
T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCi0tDQoNCg==

--_000_HE1PR0102MB2585D9664A190C7EC7000BD7F75F0HE1PR0102MB2585_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAw
IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h
dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9z
ZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TGF0
bzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6
bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q
bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJSZW4gdGVrc3QgVGVnbiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLm1zb25vcm1hbDAs
IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h
bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS03NjI1
ODc2NTgwMTIzMjk5NDEwYWlybWFpbG9uLCBsaS5nbWFpbC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBh
aXJtYWlsb24sIGRpdi5nbWFpbC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBhaXJtYWlsb24NCgl7bXNv
LXN0eWxlLW5hbWU6Z21haWwtbV8tNzYyNTg3NjU4MDEyMzI5OTQxMGFpcm1haWxfb247DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW0tNzYyNTg3NjU4MDEy
MzI5OTQxMGdtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4
MTdhaXJtYWlsb24sIGxpLmdtYWlsLW0tNzYyNTg3NjU4MDEyMzI5OTQxMGdtYWlsLW04MjAzMDYw
MTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdhaXJtYWlsb24sIGRpdi5nbWFp
bC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0x
MjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTc2
MjU4NzY1ODAxMjMyOTk0MTBnbWFpbC1tXzgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tXzEyODA3
MTc5Njk1MTUxMDY4MTdhaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KcC5nbWFpbC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBnbWFpbC1tODIwMzA2MDExMzg3
NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3Z21haWwtbTg0NzU3Mjg2NTYyNDU0OTI0
OTVhaXJtYWlsb24sIGxpLmdtYWlsLW0tNzYyNTg3NjU4MDEyMzI5OTQxMGdtYWlsLW04MjAzMDYw
MTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdnbWFpbC1tODQ3NTcyODY1NjI0
NTQ5MjQ5NWFpcm1haWxvbiwgZGl2LmdtYWlsLW0tNzYyNTg3NjU4MDEyMzI5OTQxMGdtYWlsLW04
MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdnbWFpbC1tODQ3NTcy
ODY1NjI0NTQ5MjQ5NWFpcm1haWxvbg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy03NjI1ODc2
NTgwMTIzMjk5NDEwZ21haWwtbV84MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbV8xMjgwNzE3OTY5
NTE1MTA2ODE3Z21haWwtbV84NDc1NzI4NjU2MjQ1NDkyNDk1YWlybWFpbF9vbjsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRXBvc3RTdGlsMjENCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlJlbnRla3N0VGVnbg0KCXttc28tc3R5bGUtbmFtZToi
UmVuIHRla3N0IFRlZ24iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiUmVuIHRla3N0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu
LkVwb3N0U3RpbDI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu
ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox
NjEzNDMzOTE3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTMyNzU2ODAyO30NCkBsaXN0IGww
OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl
bC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu
MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu
MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206
MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJOTy1CT0siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpLDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBoYXZlIGEgbWFjaGluZS10by1tYWNoaW5lIHNjZW5hcmlv
IHdoZXJlIGNsaWVudHMsIFJTZXMgYW5kIG91ciBBUyBhbGwgYmVsb25nIHRvIGRpZmZlcmVudCBs
ZWdhbCBlbnRpdGllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U29tZSBSU2VzIHJl
cXVpcmUgdGhlaXIgY2xpZW50cyB0byBsaW1pdCB0aGUgYWNjZXNzIHRva2VuIHRvIGEgc3BlY2lm
aWMgUmVzb3VyY2UgT3duZXIsIHdoaWxlIG90aGVyIFJTZXMgZG9uJ3QuIEluIHRoZSBmb3JtZXIg
Y2FzZSwgd2UgdXNlICdzdWInIHRvIGlkZW50aWZ5IHRoYXQgUmVzb3VyY2UgT3duZXIuJm5ic3A7
IEluIHN1Y2ggYSBtaXhlZCBkZXBsb3ltZW50IHNjZW5hcmlvLCBhbGxvd2luZyB1c2luZyAnc3Vi
Jw0KIGZvciBkaWZmZXJlbnQgbWVhbmluZ3MgY2FuIGxlYWQgdG8gY29uZnVzaW9uLCBzbyBJIHRo
aW5rIHRoZSBhY3R1YWwgbWVhbmluZyBzaG91bGQgYmUgZXhwbGljaXRseSBzaWduYWxsZWQgbGlr
ZSBEYXZlIHN1Z2dlc3RzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IYXZp
bmcgc2FpZCB0aGF0LCBJIGRvIHByZWZlciB0byBsaW1pdCB0aGUgdXNhZ2Ugb2YgJ3N1YicgaW4g
YWNjZXNzIHRva2VucyBmb3IgdGhlIEVuZCBVc2VyIG9ubHkuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
QXMgYSBzaWRlIG5vdGUsIGluIG91ciBjYXNlIHdlIG5lZWQgYSBtb3JlIGZvcm1hbCBjbGllbnQg
aWRlbnRpZmljYXRpb24gdGhhbiB0aGUgY2xpZW50X2lkIGFsb25lIChhcyB0aGV5IGFyZSByYW5k
b21seSBnZW5lcmF0ZWQgYnkgRENSKSwmbmJzcDsgYW5kIGhhdmUgdGh1cyBvcHRlZCBmb3IgYSBj
dXN0b20gY2xhaW0gYGNsaWVudF9vd25lcmAgY29udGFpbmluZyB0aGUgcmVnaXN0ZXJlZCBjb21w
YW55IGlkZW50aWZpZXIuJm5ic3A7DQogV2UgcHVsbCB0aGlzIG91dCBmcm9tIGNlcnRpZmljYXRl
IHVzZWQgdG8gc2lnbiB0aGUgSldULWdyYW50IChSRkM3NTIzKSBmcm9tIHRoZSB0b2tlbiByZXF1
ZXN0LiAmbmJzcDsmbmJzcDtXZSBjb3VsZCBvZiBjb3Vyc2UgaGF2ZSB1c2VkIOKAmHN1YuKAmSBm
b3IgY2xpZW50X293bmVyLCBidXQgdGhhdCB3b3VsZCByZXF1aXJlIHVzIHRvIGludmVudCBhbm90
aGVyIGN1c3RvbSBjbGFpbSBmb3IgdGhvc2UgUlNlcyB0aGF0IHJlcXVpcmVzIFJPLWxpbWl0ZWQg
dG9rZW5zLiAmbmJzcDsmbmJzcDsmbmJzcDtUbw0KIG1ha2UgbWF0dGVycyBldmVuIG1vcmUgY29t
cGxpY2F0ZWQsIHRoZXJlIG1pZ2h0IGJlIGJ1c2luZXNzIGRlbGVnYXRpb24gaGFwcGVuaW5nLCZu
YnNwOyB3aGVyZSBjb21wYW55IEEgcnVubmluZyB0aGUgY2xpZW50IGlzIGFjdGluZyBvbiBiZWhh
bGYgb2YgZGlmZmVyZW50IG90aGVyIGNvbXBhbmllcyBCLEMsROKApiBhbmQgdGhlIGluc3RhbnRh
bmVvdXMgQSYjNDM7QiBvciBBJiM0MztDIHJlbGF0aW9uIGFsc28gaGF2ZSB0byBiZSBjb21tdW5p
Y2F0ZWQgaW4gdGhlIHRva2VuDQogJm5ic3A7KEFjY29yZGluZyB0byBFVSBwcml2YWN5IGxhd3Ms
IEkgYmVsaXZlIEEgaXMgdGhlIERhdGEgUHJvY2Vzc29yIGFuZCB0aGVpciBjdXN0b21lciBCLEMs
ROKApiBhcmUgRGF0YSBDb250cm9sbGVyKS4mbmJzcDsmbmJzcDsgU28gYWdhaW4gdGhpcyBsZWFk
cyBtZSB0byB0aGluayB0aGF0IGNsaWVudCBpZGVudGlmaWNhdGlvbiBzaG91bGQgYmUga2VwdCBp
biBzZXBhcmF0ZSBjbGFpbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFueXdheSwg
Zm9yIHVzIGFzIHVzZXIgb2YgdGhlIG9hdXRoMiBwcm90b2NvbHMsIHRoaXMgZHJhZnQgaXMgd2Vs
Y29tZSAhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+SsO4cmdlbiBCaW5uaW5nc2LDuDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UHJvZHVjdCBPd25lciwgTm9y
d2VnaWFuIE5hdGlvbmFsIGVJRCBJbmZyYXN0cnVjdHVyZSAoSUQtcG9ydGVuKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+RnJhOjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcm
Z3Q7IDxiPlDDpSB2ZWduZSBhdjwvYj4gRGF2ZSBUb25nZTxicj4NCjxiPlNlbmR0OjwvYj4gdGly
c2RhZyAyNi4gbWFycyAyMDE5IDA5LjI3PGJyPg0KPGI+VGlsOjwvYj4gRG9taW5pY2sgQmFpZXIg
Jmx0O2RiYWllckBsZWFzdHByaXZpbGVnZS5jb20mZ3Q7PGJyPg0KPGI+S29waTo8L2I+IElFVEYg
b2F1dGggV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPkVtbmU6PC9iPiBSZTogW09B
VVRILVdHXSBkcmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAwPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIFZpdHRvcmlv
IGZvciB5b3VyIHByZXNlbnRhdGlvbiBhbmQgcHV0dGluZyB0aGlzIGRyYWZ0IHRvZ2V0aGVyLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBN
UyZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHdpdGggRG9taW5jayB0aGF0IHRoZXJlIGlzIGEg
cG90ZW50aWFsIG9mIHRoaW5ncyBnb2luZyB3cm9uZyB3aGVuIGBzdWJgIGhhcyBtdWx0aXBsZSBt
ZWFuaW5ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1
b3Q7LHNhbnMtc2VyaWYiPkhvd2V2ZXIgSSBjYW4gc2VlIHRoYXQgdXNpbmcgYHN1YmAgZm9yIGEg
Y2xpZW50X2lkIHNlbWFudGljYWxseSBtYWtlcyBzZW5zZSBpbiBzb21lIHNpdHVhdGlvbnMgYW5k
IEkgYWdyZWUgdGhhdCBpdCBtYWtlcyBpdCBzaW1wbGVyIGZyb20gYW4gU0RLIHBvaW50IG9mIHZp
ZXcgZm9yIHRoZXJlIHRvIGFsd2F5cyBiZSBhIGBzdWJgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5N
eSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRoYXQgZWl0aGVyIHRoZXJlIGlzIGFuIGV4cGxpY2l0IHR5
cGUgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuICZxdW90O3VzZXIgYWNjZXNzIHRva2VucyZxdW90
OyBhbmQgJnF1b3Q7YXBwbGljYXRpb24gYWNjZXNzIHRva2VucyZxdW90Oywgb3IgZmFpbGluZyB0
aGF0IHRoZSBgc3ViYCBpcyB1c2VkIHRvIGluZGljYXRlDQogdGhlIGRpZmZlcmVuY2UuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1
b3Q7LHNhbnMtc2VyaWYiPkZ1cnRoZXJtb3JlIGFuIGFncmVlbWVudCBvbiB0aGUgbmFtaW5nIGFu
ZCBkZXNjcmlwdGlvbiBvZiB0aGVzZSB0d28gdHlwZXMgb2YgYWNjZXNzIHRva2VucyB3b3VsZCBi
ZSBoZWxwZnVsIG1vcmUgZ2VuZXJhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5EYXZlPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBUdWUsIDI2IE1hciAyMDE5IGF0IDA3OjI1LCBEb21pbmljayBCYWllciAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20iPmRiYWllckBsZWFzdHByaXZpbGVnZS5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb20g
YW4gYWNjZXNzIHRva2VuIGNvbnN1bWVyIChha2EgQVBJKSBkZXZlbG9wZXIgcG9pbnQgb2Ygdmll
dywgSSBwcmVmZXIgdGhpcyBsb2dpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+JnF1b3Q7SWYgc3ViIGlzIHByZXNlbnQgLSBjbGllbnQgYWN0cyBvbiBi
ZWhhbGYgb2YgYSB1c2VyLCBpZiBub3QgLSBub3QuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbnl0aGluZyBtb3JlIGNvbXBsaWNhdGVkIGhh
cyBhIHBvdGVudGlhbCBvZiBnb2luZyB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS03NjI1
ODc2NTgwMTIzMjk5NDEwYWlybWFpbG9uIj5PbiAyNi4gTWFyY2ggMjAxOSBhdCAwMTozNDo1Mywg
Tm92IE1hdGFrZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5jb20iIHRhcmdldD0iX2Js
YW5rIj5tYXRha2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBWaXR0b3Jpbyw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVh
aCwgSeKAmW0gY29uY2VybmluZyB1c2VyICZhbXA7IGNsaWVudCBpZHMgY29sbGlzaW9uLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlbuKA
mXQgc2VlbiBzdWNoIGltcGxlbWVudGF0aW9ucywgYnV0IHVzZXItc2VsZWN0IHVzZXJuYW1lIGFz
IHN1Yiwgb3IgaW5jcmVtZW50YWwgaW50ZWdlciBhcyBzdWIgJmFtcDsgY2xpZW50X2lkIHdpbGwg
YmUgZWFzaWx5IGNvbGxpZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPklmIHlvdSBjYW4gZW5mb3JjZSBjb2xsaXNpb24gcmVzaXN0YW50IElE
cyBiZXR3ZWVuIHVzZXIgJmFtcDsgY2xpZW50IGluc3RhbmNlcywgaXTigJlsbCB3b3JrcyBmaW5l
LiBJIGZlZWwgaXRzIG92ZXJraWxsIHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXYgaWQ9ImdtYWlsLW1fLTc2MjU4NzY1ODAxMjMyOTk0MTBBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48YnI+DQpPbiBNYXIgMjYsIDIwMTksIGF0IDg6NTEsIFZpdHRvcmlvIEJlcnRvY2Np
ICZsdDs8YSBocmVmPSJtYWlsdG86Vml0dG9yaW9AYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+
Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXkgTm92LCBEb21pbmljaywg
SGFucy0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtz
IGZvciB0aGUgY29tbWVudHMuIFRoYXQgd2FzIGFuIGFyZWEgSSB3YXMgZXhwZWN0aW5nIHRvIGNh
dXNlIG1vcmUgZGlzY3Vzc2lvbiwgYW5kIEkgYW0gZ2xhZCB3ZSBhcmUgaGF2aW5nIHRoaXMgb3Bw
b3J0dW5pdHkgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZSBjdXJyZW50IGxhbmd1YWdlIGluIHRoZSBkcmFmdCB0cmFjZXMg
dGhlIGV0eW1vbG9neSBvZiBzdWIgdG8gT3BlbklEIENvbm5lY3QgY29yZSwgaGVuY2UgRG9taW5p
Y2sgb2JzZXJ2YXRpb24gaXMgb24gcG9pbnQuIEhvd2V2ZXIgaW4gdGhlIGRlc2NyaXB0aW9uIEkg
ZXhwcmVzcyBzb21ldGhpbmcgaW4gbGluZSB3aXRoIDc1MTksIHdoaWNoIHdhcyBpbiBmYWN0IG15
IGludGVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlIGlkZWEgd2FzIHRvIHByb3ZpZGUgYW4gaWRlbnRpZmllciBvZiB0aGUgY2FsbGlu
ZyBzdWJqZWN0IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGluIGFsbCBjYXNlcy0g
dGhpcyB3b3VsZCBhbGxvdyBhbiBTREsgZGV2ZWxvcGVyIHRvIHVzZSB0aGUgc2FtZSBjb2RlIGZv
ciB0aGluZ3MgbGlrZSBsb29rdXBzIGFuZCBtZW1iZXJzaGlwIGNoZWNrcyByZWdhcmRsZXNzIG9m
IHRoZSBuYXR1cmUgb2YNCiB0aGUgY2FsbGVyICh1c2VyIGluIGEgZGVsZWdhdGVkIGNhc2UsIGFw
cCBpbiBhcHAtb25seSBncmFudHMpLiBUaGUgaW5mb3JtYXRpb24gdG8gZGlzY3JpbWluYXRlIGJl
dHdlZW4gdXNlciBhbmQgYXBwIGNhbGxlcnMgaXMgYWx3YXlzIGF2YWlsYWJsZSBpbiB0aGUgdG9r
ZW4gKHNheSwgdGhlIGNhbGxlciBpcyBhIHVzZXIgaWYgc3ViIT1jbGllbnRfaWQsIHdoZXJlIGNs
aWVudF9pZCBpcyBhbHdheXMgZ3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGFzDQogd2VsbCkgaGVu
Y2UgdGhlcmUncyBubyBsb3NzIGluIGV4cHJlc3NpdmUgcG93ZXIsIHNob3VsZCB0aGF0IGRpZmZl
cmVuY2UgYmUgcmVsZXZhbnQgZm9yIHRoZSByZXNvdXJjZSBzZXJ2ZXIuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNrLCBIYW5zLSBJ
IHByb2JhYmx5IG1pc3NlZCB0aGUgc2VjdXJpdHkgaXNzdWUgeW91IGd1eXMgYXJlIHRoaW5raW5n
IG9mIGluIHRoaXMgY2FzZS4gT2YgY291cnNlLCBpZiB0aGlzIHdvdWxkIGludHJvZHVjZSBhIHJp
c2sgSSBjb21wbGV0ZWx5IGFncmVlIGl0IHNob3VsZCBiZSBjaGFuZ2VkLSBJJ2QganVzdCBsaWtl
IHRvIHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBwcm9ibGVtLiBDb3VsZCB5b3UgZXhwYW5kDQogaXQg
aW4gYSBzY2VuYXJpby91c2UgY2FzZSB0byBjbGFyaWZ5IHRoZSByaXNrPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm92LSBwbGF5aW5nIHRoaXMg
YmFjazogaXMgdGhlIGNvbmNlcm4gdGhhdCBhIHVzZXIgYW5kIGEgY2xpZW50IG1pZ2h0IGhhdmUg
dGhlIHNhbWUgaWRlbnRpZmllciB3aXRoaW4gYW4gSURQPyBXaGVuIHVzaW5nIGNvbGxpc2lvbiBy
ZXNpc3RhbnQgSURzLCBhcyBpdCBpcyB1c3VhbGx5IHRoZSBjYXNlLCB0aGF0IHNlZW1zIHRvIGJl
IGEgcmVtb3RlIHBvc3NpYmlsaXR5LSBkaWQgeW91IHN0dW1ibGUgaW4gc3VjaA0KIHNjZW5hcmlv
IGluIHByb2R1Y3Rpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Vi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNSwgMjAxOSBhdCA3OjQ0IEFNIEhh
bnMgWmFuZGJlbHQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5l
dSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGVyZSBhcmUgcGxlbnR5IG9mIE9BdXRoIDIu
MCBvbmx5IHVzZSBjYXNlcyBvdXQgdGhlcmUuLi4gYnV0IG5ldmVydGhlbGVzcyBJIGFncmVlIHdp
dGggdGhlIHBvdGVudGlhbCBjb25mdXNpb24gYW5kIHRodXMgc2VjdXJpdHkgcHJvYmxlbXMgYXJp
c2luZyBmcm9tIHRoYXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRo
ZSBzYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhh
bnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDM6MzkgUE0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhy
ZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJh
aWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+WWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGluIGhpbmRzaWdodCBpdCB3
YXMgYSBtaXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZvciBtdWx0aXBsZSBzZW1h
bnRpY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5B
bGwgdGhlIOKAnHRoaXMgaXMgT0lEQyBub3QgT0F1dGjigJ0gYXJndW1lbnRzIGFyZSBtYWtpbmcg
dGhpbmdzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGV5IG5lZWQgdG8gYmUgLSBpbiBteSBleHBl
cmllbmNlIGFsbW9zdCBuby1vbmUgKHRoYXQgSSBrbm93KSBkb2VzIE9JREMgb25seSAtIG5vciBP
QXV0aA0KIG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUgaXQuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiByZWFsaXR5IHRoaXMgbGVhZHMgdG8gcG90
ZW50aWFsIHNlY3VyaXR5IHByb2JsZW1zIC0gdGhpcyBzcGVjIGhhcyB0aGUgcG90ZW50aWFsIHRv
IHJlY3RpZnkgdGhlIHNpdHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9taW5pY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzYyNTg3
NjU4MDEyMzI5OTQxMGdtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1
MTUxMDY4MTdhaXJtYWlsb24iPg0KT24gMjUuIE1hcmNoIDIwMTkgYXQgMTQ6NTg6NTYsIEhhbnMg
WmFuZGJlbHQgKDxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFy
Z2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPikgd3JvdGU6PG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPldpdGhvdXQgYWdyZWVpbmcgb3IgZGlzYWdyZWVpbmc6IE9JREMg
ZG9lcyBub3QgYXBwbHkgaGVyZSBzaW5jZSBpdCBpcyBub3QgT0F1dGggYW5kIGFuIGFjY2VzcyB0
b2tlbiBpcyBub3QgYW4gaWRfdG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSldUIHNwZWMgc2F5cyBpbiA8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yIiB0YXJnZXQ9Il9ibGFu
ayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yPC9h
Pjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O1Ro
ZSAmcXVvdDtzdWImcXVvdDsgKHN1YmplY3QpIGNsYWltIGlkZW50aWZpZXMgdGhlIHByaW5jaXBh
bCB0aGF0IGlzIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZuYnNwO3N1YmplY3Qgb2YgdGhlIEpXVC4mbmJzcDsgVGhlIGNsYWlt
cyBpbiBhIEpXVCBhcmUgbm9ybWFsbHkgc3RhdGVtZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2Fib3V0IHRoZSBzdWJq
ZWN0LiZuYnNwOyBUaGUgc3ViamVjdCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBzY29wZWQgdG8gYmU8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyAmbmJzcDtsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyIG9yIGJl
IGdsb2JhbGx5IHVuaXF1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtUaGUgcHJvY2Vzc2luZyBvZiB0aGlzIGNsYWltIGlz
IGdlbmVyYWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGljaCBraW5kIG9mIHNwZWxscyAm
cXVvdDtjbGllbnQmcXVvdDsgaW4gY2FzZSBvZiB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50
IGJ1dCBJIGFsc28gZG8gd29ycnkgYWJvdXQgUmVzb3VyY2UgU2VydmVycyB0aGlua2luZy9hY3Rp
bmcgb25seSBpbiB0ZXJtcyBvZiB1c2VyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMjUs
IDIwMTkgYXQgMjo0MSBQTSBEb21pbmljayBCYWllciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiYWll
ckBsZWFzdHByaXZpbGVnZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYmFpZXJAbGVhc3Rwcml2aWxl
Z2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J
TUhPIHRoZSBzdWIgY2xhaW0gc2hvdWxkIGFsd2F5cyByZWZlciB0byB0aGUgdXNlciAtIGFuZCBu
b3RoaW5nIGVsc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5PSURDIHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0IC0gSWRlbnRpZmll
ciBmb3IgdGhlIEVuZC1Vc2VyIGF0IHRoZSBJc3N1ZXIuJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPmNsaWVudF9pZCBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSBjbGllbnRz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5j
aGVlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkRvbWluaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzYyNTg3NjU4MDEyMzI5OTQx
MGdtYWlsLW04MjAzMDYwMTEzODc3MTY2OTc2Z21haWwtbTEyODA3MTc5Njk1MTUxMDY4MTdnbWFp
bC1tODQ3NTcyODY1NjI0NTQ5MjQ5NWFpcm1haWxvbiI+DQpPbiAyNS4uIE1hcmNoIDIwMTkgYXQg
MDU6MTM6MDMsIE5vdiBNYXRha2UgKDxhIGhyZWY9Im1haWx0bzptYXRha2VAZ21haWwuY29tIiB0
YXJnZXQ9Il9ibGFuayI+bWF0YWtlQGdtYWlsLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFZpdHRvcmlvLCA8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhl
IGdvb2Qgc3RhcnRpbmcgcG9pbnQgb2Ygc3RhbmRhcmRpemluZyBKV1QtaXplZCBBVC48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGZlZWRi
YWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIOKAnHN1YuKAnSBjbGFpbSBjYW4gaW5jbHVkZSAyIHR5cGVzIG9mIGlkZW50aWZpZXIsIGVu
ZC11c2VyIGFuZCBjbGllbnQsIGluIHRoaXMgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHJlcXVpcmVzIHRob3NlIDIgdHlwZXMgb2Yg
aWRlbnRpZmllcnMgdG8gYmUgdW5pcXVlIGVhY2ggb3RoZXIgaW4gdGhlIElkUCBjb250ZXh0Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHBy
ZWZlciBvbWl0dGluZyDigJxzdWLigJ0gY2xhaW0gaW4gMi1sZWdnZWQgY29udGV4dCwgc28gdGhh
dCBubyBzdWNoIGNvbnN0cmFpbnQgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm92PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMjUsIDIwMTksIGF0
IDg6MjksIFZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVy
dG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52aXR0b3Jp
by5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E
ZWFyIGFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBq
dXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgYSBKV1QgcHJvZmlsZSBmb3IgT0F1dGgg
Mi4wIGFjY2VzcyB0b2tlbnMuIFlvdSBjYW4gZmluZCBpdCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10
b2tlbi1qd3QvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC88L2E+LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgc2xvdCB0
byBkaXNjdXNzIHRoaXMgdG9tb3Jyb3cgYXQgSUVURiAxMDQgKEknbGwgYmUgcHJlc2VudGluZyBy
ZW1vdGVseSkuIEkgbG9vayBmb3J3YXJkIGZvciB5b3VyIGNvbW1lbnRzITxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlJ3MganVzdCBhIGJp
dCBvZiBiYWNrc3RvcnksIGluIGNhc2UgeW91IGFyZSBpbnRlcmVzdGVkIGluIGhvdyB0aGlzIGRv
YyBjYW1lIHRvIGJlLiBUaGUgdHJhamVjdG9yeSBpdCBmb2xsb3dlZCBpcyBzb21ld2hhdCB1bnVz
dWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpEZXNwaXRlIE9B
dXRoMiBub3QgcmVxdWlyaW5nIGFueSBzcGVjaWZpYyBmb3JtYXQgZm9yIEFUcywgdGhyb3VnaCB0
aGUgeWVhcnMgSSBoYXZlIGNvbWUgYWNyb3NzIG11bHRpcGxlIHByb3ByaWV0YXJ5IHNvbHV0aW9u
IHVzaW5nIEpXVCBmb3IgdGhlaXIgYWNjZXNzIHRva2VuLiBUaGUgaW50ZW50IGFuZCBzY2VuYXJp
b3MgYWRkcmVzc2VkIGJ5IHRob3NlIHNvbHV0aW9ucyBhcmUgbW9zdGx5IHRoZSBzYW1lIGFjcm9z
cyB2ZW5kb3JzLCBidXQgdGhlDQogc3ludGF4IGFuZCBpbnRlcnByZXRhdGlvbnMgaW4gdGhlIGlt
cGxlbWVudGF0aW9ucyBhcmUgZGlmZmVyZW50IGVub3VnaCB0byBwcmV2ZW50IGRldmVsb3BlcnMg
ZnJvbSByZXVzaW5nIGNvZGUgYW5kIHNraWxscyB3aGVuIG1vdmluZyBmcm9tIHByb2R1Y3QgdG8g
cHJvZHVjdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps
MCBsZXZlbDEgbGZvMSI+DQpJIGFza2VkIHNldmVyYWwgaW5kaXZpZHVhbHMgZnJvbSBrZXkgcHJv
ZHVjdHMgYW5kIHNlcnZpY2VzIHRvIHNoYXJlIHdpdGggbWUgY29uY3JldGUgZXhhbXBsZXMgb2Yg
dGhlaXIgSldUIGFjY2VzcyB0b2tlbnMgKFRIQU5LIFlPVSBEb21pbmljayBCYWllciAoSWRlbnRp
dHlTZXJ2ZXIpLCZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5CcmlhbiBDYW1w
YmVsbCAoUGluZ0lkZW50aXR5KSwgRGFuaWVsIERvYmFsaWFuIChNaWNyb3NvZnQpLCBLYXJsDQog
R3Vpbm5lc3MgKE9rdGEpIGZvciB0aGUgdG9rZW5zIGFuZCBleHBsYW5hdGlvbnMhPC9zcGFuPiku
PGJyPg0KSSBzdHVkaWVkIGFuZCBjb21wYXJlZCBhbGwgdGhvc2UgaW5zdGFuY2VzLCBpZGVudGlm
eWluZyBjb21tb25hbGl0aWVzIGFuZCBkaWZmZXJlbmNlcy4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+
PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJIHB1dCB0
b2dldGhlciBhIHByZXNlbnRhdGlvbiBzdW1tYXJpemluZyBteSBmaW5kaW5ncyBhbmQgc3VnZ2Vz
dGluZyBhIHJvdWdoIGludGVyb3BlcmFibGUgcHJvZmlsZSAoc2xpZGVzOg0KPGEgaHJlZj0iaHR0
cHM6Ly9zZWMuLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9vc3cyMDE5L3NsaWRlcy9i
ZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4IiB0YXJnZXQ9Il9ibGFuayI+DQpo
dHRwczovL3NlYy51bmktc3R1dHRnYXJ0LmRlL19tZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlkZXMv
YmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMucHB0eDwvYT4gKSAtIGdvdCBlYXJseSBm
ZWVkYmFjayBmcm9tIEZpbGlwIFNrb2thbiBvbiBpdC4gVGh4IEZpbGlwITxvOnA+PC9vOnA+PC9s
aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBw
cmVzZW50YXRpb24gd2FzIGZvbGxvd2VkIHVwIGJ5IDEuNSBob3VycyBvZiB1bmNvbmZlcmVuY2Ug
ZGlzY3Vzc2lvbiwgd2hpY2ggd2FzIGluY3JlZGlibHkgdmFsdWFibGUgdG8gZ2V0IHRpZ2h0LWxv
b3AgZmVlZGJhY2sgYW5kIGluY29ycG9yYXRlIG5ldyBpZGVhcy4gSm9obiBCcmFkbGV5LCBCcmlh
biBDYW1wYmVsbCBWbGFkaW1pciBEemh1dmlub3YsIFRvcnN0ZW4gTG9kZGVyc3RlZHQsPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwO05hdA0KIFNha2ltdXJhLCBIYW5uZXMgVHNj
aG9mZW5pZzwvc3Bhbj4mbmJzcDt3ZXJlIGFsbCB0aGVyZSBhbmQgY29udHJpYnV0ZWQgZ2VuZXJv
dXNseSB0byB0aGUgZGlzY3Vzc2lvbi4gVGhhbmsgeW91ISEhPGJyPg0KTm90ZTogaWYgeW91IHdl
cmUgYXQgT1NXMjAxOSwgcGFydGljaXBhdGVkIGluIHRoZSBkaXNjdXNzaW9uIGFuZCBkaWRuJ3Qg
Z2V0IGNyZWRpdGVkIGluIHRoZSBkcmFmdCwgbXkgYXBvbG9naWVzOiBwbGVhc2Ugc2VuZCBtZSBh
IG5vdGUgYW5kIEknbGwgbWFrZSB0aGluZ3MgcmlnaHQgYXQgdGhlIG5leHQgdXBkYXRlLjxvOnA+
PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x
Ij4NCk9uIG15IGZsaWdodCBiYWNrIEkgZGlkIG15IGJlc3QgdG8gaW5jb3Jwb3JhdGUgYWxsIHRo
ZSBpZGVhcyBhbmQgZmVlZGJhY2sgaW4gYSBkcmFmdCwgd2hpY2ggd2lsbCBiZSBkaXNjdXNzZWQg
YXQgSUVURjEwNCB0b21vcnJvdy4gUmlmYWF0LCBIYW5uZXMgYW5kIGFib3ZlIGFsbCBCcmlhbiB3
ZXJlIGFsbCBzdXBlciBoZWxwZnVsIGluIG5lZ290aWF0aW5nIHRoZSBteXN0ZXJpb3VzIHN5bnRh
eCBvZiB0aGUgUkZDIGZvcm1hdCBhbmQgc3VibWlzc2lvbg0KIHByb2Nlc3MuPG86cD48L286cD48
L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgYmxvd24gYXdheSBi
eSB0aGUgYXZhaWxhYmlsaXR5LCBpbnZvbHZlbWVudCBhbmQgd2lsbGluZ25lc3MgdG8gaW52ZXN0
IHRpbWUgdG8gZ2V0IHRoaW5ncyByaWdodCB0aGF0IGV2ZXJ5b25lIGRlbW9uc3RyYXRlZCBpbiB0
aGUgcHJvY2Vzcy4gVGhpcyBpcyBhbiBhbWF6aW5nIGNvbW11bml0eS4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Vi48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg
bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpo
YW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRA
em1hcnR6b25lLmV1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5abWFydFpv
bmUgSUFNIC0gPGEgaHJlZj0iaHR0cDovL3d3dy56bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5r
Ij4NCnd3dy56bWFydHpvbmUuZXU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Im1haWx0bzpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5l
dSIgdGFyZ2V0PSJfYmxhbmsiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5abWFydFpvbmUgSUFNIC0gPGEgaHJlZj0iaHR0cDov
L3d3dy56bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5rIj4NCnd3dy56bWFydHpvbmUuZXU8L2E+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpMYXRvO2NvbG9yOiMwMEE0Qjci
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_HE1PR0102MB2585D9664A190C7EC7000BD7F75F0HE1PR0102MB2585_--


From milind.nikam@extrapreneursindia.com  Sat Mar 30 21:28:27 2019
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 2F3E61200EA for ; Sat, 30 Mar 2019 21:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=extrapreneursindia-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 UFEyvyZDP3o9 for ; Sat, 30 Mar 2019 21:28:24 -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 935FD12001A for ; Sat, 30 Mar 2019 21:28:24 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id d1so1168881plj.8 for ; Sat, 30 Mar 2019 21:28:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=extrapreneursindia-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=pALtr9vrKhMHYdkquvzPnYz8u8RY6xR0GZcErzRB+0A=; b=MqigQHpJehpJCg027wTSooQbL5XzN6wOV1QU0VUZlxpJpxFf5EzxFAfCBjlsSgdYzh UWLT4eoVXLmpJaj3jpoyAhV8cv4XTNrx1GVe3tCIhKjE6t+GTLuMsPMLeAnUklXdzpia C/bV/tEN+LPv7d2s0pIjMb1ZgS92i6PC94su8tsswrHF7Qlj7skcqCDhzqvHKs4WkS5T 0jvOptvG5Vi5Fyh/sz/KXzggR4BE2sCa5SQZJCt883poZXVIMYHqs2W+iiAJi2EGQ9PD S9mtWSAVaVfoqakGBVgbx5T6zogGPtSdNVfbXjJLEGGRo7RG9RBRsskGZvics5ZUlG5V +TpA==
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:date:message-id:mime-version :thread-index:content-language; bh=pALtr9vrKhMHYdkquvzPnYz8u8RY6xR0GZcErzRB+0A=; b=TayRSkNBI7pQ4JWcCchwYlks80vqbeT0LhvJ75QmSs+XXWO3Rwhkx7y9RRiu4cYGW/ /OI2dkjaQvX2VmTK29tLBo+IG+C1OnR1szq32PEReKyy1+7sf1cwghlmDoTx61T4u4BH Rh4zicO11bCJZs8YLskb3QEGoqu4n/9XBB++BH4BE+XBM/aapDLfRPfJcrs5GK5GJ9cQ PNcKAUXtafEQeCy1jourDrEDgA2GDAHdM0OyHcRWFH2koHOHJomWGLzM/Ye/4N6yOD72 qtKciVgdbY3BgVHUrWTQGwupLcMtO3vNQMzZljnowIm5IYuehorvWgPVZauX3oAiQ/hn iX6w==
X-Gm-Message-State: APjAAAVbCPsGerzcJ5PL+bnWsgmWmhw8vbf2g5GHznHU/bclE94JcUWi UQWBS4jVvpkEpWqXhDpt9d/kbUn1YIw=
X-Google-Smtp-Source: APXvYqwduMjzxgCqi5qOG6CVubTcQcZShIZmHIeoudpdtMNfMK95KXiKE82b1INzHa25N5Brd2HmCQ==
X-Received: by 2002:a17:902:b788:: with SMTP id e8mr47379860pls.339.1554006503500;  Sat, 30 Mar 2019 21:28:23 -0700 (PDT)
Received: from EPILap15 ([157.33.230.191]) by smtp.gmail.com with ESMTPSA id p128sm13594384pfp.30.2019.03.30.21.28.20 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 21:28:22 -0700 (PDT)
From: Milind Nikam 
X-Google-Original-From: "Milind Nikam" 
To: 
Date: Sun, 31 Mar 2019 09:58:17 +0530
Message-ID: <000001d4e77a$2c425cc0$84c71640$@extrapreneursindia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D4E7A8.45FBAA30"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdTneVGoHd7ocwDRTJi151EjN5O0pA==
Content-Language: en-in
Archived-At: 
X-Mailman-Approved-At: Fri, 05 Apr 2019 10:43:30 -0700
Subject: [OAUTH-WG] Possible help with product design
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, 31 Mar 2019 04:31:21 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0001_01D4E7A8.45FBAA30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Team,

 

We are in a process of architecting the web project with the technology
stack as Angular 7 & .NET Core 2.2.
We wanted to implement token, So we did some research and finalized OAuth
2.0 & JWT would be the platform.

However, I am new to OAuth 2.0. and even also JWT.
So I need possible help from you to implement token security in OAuth 2.0 &
JWT with .NET Core 2.2.
I will appreciate if you share some sample code available with you.

 

 

 

Thanks and Regards, 

Milind Nikam

 

EXTRAPRENEURS India Pvt. Ltd.

102, Bhakti Genesis, Wakad Hinjewadi Road, Wakad, Pune - 411057

Mobile: +91-9970190334  | Landline: +91 (020) 6920 9001 | Website:
 www.extrapreneursindia.com  | Skype:
Milind.nikam2

 

This communication and any attached files may contain information that is
confidential or privileged. Any unauthorized review, use, disclosure or
distribution is prohibited. 

 If this communication has been received in error, please notify me and
delete or destroy it immediately.

 

 


------=_NextPart_000_0001_01D4E7A8.45FBAA30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Dear Team,
 
We are in a =
process of architecting the web project with the technology stack as =
Angular 7 & .NET Core 2.2.
We wanted to implement token, So we =
did some research and finalized OAuth 2.0 & JWT would be the =
platform.
However, I am new to OAuth =
2.0. and even also JWT.
So I need possible help from you to implement =
token security in OAuth 2.0 & JWT with .NET Core 2.2.
I will =
appreciate if you share some sample code available with =
you.
 
 
 
Thanks =
and Regards, 
Milind Nikam
 
EXTRAPRENEURS =
India Pvt. Ltd.
102, Bhakti Genesis, Wakad =
Hinjewadi Road, Wakad, Pune – =
411057
Mobile: +91-9970190334 =
 | Landline: +91 (020) 6920 9001 | Website: www.extrapreneursindia.com  | Skype: Milind.nikam2
 =

This =
communication and any attached files may contain information that is =
confidential or privileged. Any unauthorized review, use, disclosure or =
distribution is prohibited. 
 =
;If this communication has been received in error, please notify me and =
delete or destroy it immediately.
 
 

------=_NextPart_000_0001_01D4E7A8.45FBAA30--


From nobody Fri Apr  5 10:43:46 2019
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 62FB91200D8 for ; Sun, 31 Mar 2019 04:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=extrapreneursindia-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 g8tJLLH13xpa for ; Sun, 31 Mar 2019 04:12:46 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 3758D1200C7 for ; Sun, 31 Mar 2019 04:12:46 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id d1so1391805plj.8 for ; Sun, 31 Mar 2019 04:12:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=extrapreneursindia-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rZinGkXA/C+DtfWEHpOdWlMxn5z3cU1E5rzeEE9MhmU=; b=faRKVZFFD+ViUMsVvIRkS6hQo7i/uODzAENASwGA9nsdUXqbg3KKOqqTtVsfXPkDPX evDK2FN8E9NOq41xICuZzudiy23dMkXNdmEp9fBfkFv5QaMDWnkw1Sk662JzW3CBqOCI gWmC7aIyW/90VizUkDRYZRmGHKSBI41yU9z8ee2xkcphvXbvVkZMJ96f5NjC49l5VDqv IdC6r4gYZE6NSHKodttnA9RniJvSnLEXt46/CEkPpEXi6jhQIe2PSPoPALf3sV6XPpIX 51RQy3mSyXc1TlnJtrM0I/7PxrvfJM56LGI7AD0wwTbxuGS9PHJSFbTH2sVWaLcRoTQ1 PfRA==
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:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=rZinGkXA/C+DtfWEHpOdWlMxn5z3cU1E5rzeEE9MhmU=; b=Wr0Zw8IoOFI8wwoGY+39XZfWt7oUx3BZFw2kWyqeamN9l42xWbEqAQTU0IK9j8tcep pTa9AJ8WNx+sMag1KIC2xd7ortbQuuLStpyLV5zvMfli4FZ+EqGLMicS0a6YAr84lOIr EJ/RAv3MtZbNFZXgaEhOoYVZoD5jwqZOqRNrtbCQ99iQOFa7vxsI/rDKtKChQ6e72VHG wtQicISohK+imEA3rR0QPWpYWoyKVPLPGMaKjQt5sqohxgzgt5SqATRdjrHtLJ4FXiiF Wu8w9pocQ5bTAhM0rU7SfInnz7do5PgbJa/gDEJGhf60a3Z96Xg9dY24t+DHu5xkRd3i ryjQ==
X-Gm-Message-State: APjAAAWenjbBnn3N1vSdvQFjbnEGqntAvIHpdHNcDDtwrkHJxH3YKWfc qwvo21jCnwAR7Z3/Vn8GpS9wnPJ+vLw=
X-Google-Smtp-Source: APXvYqwehnudKKE/kRnP2q5uMYlv24PWz3F3UJK8EbvZ3NCFecUqY2oXPr1/PzEB8IMR6olLSZxTtw==
X-Received: by 2002:a17:902:121:: with SMTP id 30mr59486988plb.315.1554030765278;  Sun, 31 Mar 2019 04:12:45 -0700 (PDT)
Received: from EPILap15 ([157.33.230.191]) by smtp.gmail.com with ESMTPSA id w123sm14954656pfw.72.2019.03.31.04.12.42 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 04:12:44 -0700 (PDT)
From: Milind Nikam 
X-Google-Original-From: "Milind Nikam" 
To: 
Date: Sun, 31 Mar 2019 16:42:37 +0530
Message-ID: <000801d4e7b2$a9a31820$fce94860$@extrapreneursindia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdTnsqWU7RAsbcjmRbCIvlnqc3vnsA==
Content-Language: en-in
Archived-At: 
X-Mailman-Approved-At: Fri, 05 Apr 2019 10:43:30 -0700
Subject: [OAUTH-WG] Possible help with product design
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, 31 Mar 2019 11:12:48 -0000

Dear Team,

We are in a process of architecting the web project with the technology
stack as Angular 7 & .NET Core 2.2.
We wanted to implement token, So we did some research and finalized OAuth
2.0 & JWT would be the platform.
However, I am new to OAuth 2.0. and even also JWT.
So I need possible help from you to implement token security in OAuth 2.0 &
JWT with .NET Core 2.2.
I will appreciate if you share some sample code available with you.



Thanks and Regards, 
Milind Nikam

EXTRAPRENEURS India Pvt. Ltd.
102, Bhakti Genesis, Wakad Hinjewadi Road, Wakad, Pune - 411057
Mobile: +91-9970190334  | Landline: +91 (020) 6920 9001 | Website:
www.extrapreneursindia.com  | Skype: Milind.nikam2


From Robert.Lembree@se.com  Wed Apr  3 03:14:56 2019
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 117BD12009A for ; Wed,  3 Apr 2019 03:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=se.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 Gv9YhrLqpJCe for ; Wed,  3 Apr 2019 03:14:52 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::70e]) (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 83CD812008B for ; Wed,  3 Apr 2019 03:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=se.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ywTpFMoP6pAxw8KuyLjmOfSeDMwhnqeiyjHLOnp2l4U=; b=c7z8X2xCYKkcZkYKtFI233OfymImTskkXCu4/pEdu+nPSIHrlqynHy6rmkpe3AKwfug+YvzCBdFBKUpZynRLEGbngl0baCzr2pq6yStQ98/MlXK4XIo7a2cyv93n4BQCMP9cK1q8fg6C7cdObbty+evQEP+CYIlObtWpIZ1LZPQ=
Received: from AM0PR04MB6322.eurprd04.prod.outlook.com (20.179.35.146) by AM0PR04MB6210.eurprd04.prod.outlook.com (20.179.33.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Wed, 3 Apr 2019 10:14:48 +0000
Received: from AM0PR04MB6322.eurprd04.prod.outlook.com ([fe80::692f:722a:dc49:9b48]) by AM0PR04MB6322.eurprd04.prod.outlook.com ([fe80::692f:722a:dc49:9b48%4]) with mapi id 15.20.1750.017; Wed, 3 Apr 2019 10:14:48 +0000
From: Robert Lembree 
To: "oauth@ietf.org" 
Thread-Topic: Question regarding RFC 7800
Thread-Index: AdTqBeiMzR+QhhWmQiK/WODtosExuQ==
Date: Wed, 3 Apr 2019 10:14:48 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Robert.Lembree@se.com; 
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5fd4754a-0e47-482b-8f6e-08d6b81d33ed
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:AM0PR04MB6210; 
x-ms-traffictypediagnostic: AM0PR04MB6210:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(366004)(39860400002)(376002)(199004)(189003)(6506007)(54556002)(2906002)(55016002)(6916009)(71190400001)(33656002)(106356001)(256004)(25786009)(68736007)(5640700003)(476003)(102836004)(478600001)(861006)(72206003)(99286004)(316002)(14454004)(5660300002)(97736004)(606006)(26005)(81166006)(9686003)(86362001)(74316002)(4744005)(7696005)(8936002)(71200400001)(8676002)(54896002)(186003)(2351001)(2501003)(6306002)(81156014)(99936001)(52536014)(7116003)(6436002)(19627405001)(486006)(790700001)(733005)(1730700003)(105586002)(53936002)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR04MB6210; H:AM0PR04MB6322.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: se.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rXGprePxxmKZOrwUzZoJIeybcjlVtGEY0Yu2BZmnJJiVkjjRL3Qx2igL0eVvQiC50VYe+9ujbcghh5n6WSPOoeAFc6lsG1TYRcBHBooGPQ3ev12ry5tGXvXsZJ9jW1fO06rfpDQlkeXWgclfIWQBz1A2kbG7+QtF5xE4FqOtesQJ2QmeaXsZl1V4pp/gXRD/wYtti9NqHp/pOtZa+we4zqD+AO6chv3eaaHwZ+YAyPeRyVjzL5fCOdPzaQy4/6x+IaiP6hg3zsh6u5PYjqAVfPzaW2fChK8ZLXRMKCOvB1NZ+zTCUyh62tnFwMbhl4mxM9KF2HWcDGuqt1Lqqi0hVJeyX9zmUSJirX1apax5mwrEyoUPdcsgh4H6Ve5Q2olxB0wC6GUrAFgu83PvHA02HXZN+IlRwxj3/G3Ubf2Hsx4=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01BE_01D4EA16.D414CCA0"
MIME-Version: 1.0
X-OriginatorOrg: se.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5fd4754a-0e47-482b-8f6e-08d6b81d33ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 10:14:48.2761 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6e51e1ad-c54b-4b39-b598-0ffe9ae68fef
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB6210
Archived-At: 
X-Mailman-Approved-At: Fri, 05 Apr 2019 10:43:30 -0700
Subject: [OAUTH-WG] Question regarding RFC 7800
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, 03 Apr 2019 10:15:53 -0000

------=_NextPart_000_01BE_01D4EA16.D414CCA0
Content-Type: multipart/related;
	boundary="----=_NextPart_001_01BF_01D4EA16.D414F3B0"


------=_NextPart_001_01BF_01D4EA16.D414F3B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_01C0_01D4EA16.D414F3B0"


------=_NextPart_002_01C0_01D4EA16.D414F3B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello folks,

                What is the status of RFC 7800?  We=92re finding the =
need for
this, and wonder what we might be able to do to help move this along?

=20

Regards,

rob

=20

--


Robert Lembr=E9e
Lead Cybersecurity Architect
Innovation & Technology
Industrial Automation Business
Schneider Electric

D  +1 978 975 9971
M  +1 603 494 0559
E    robert.lembree@se.com

800 Federal St.
3W-WS179
Andover, MA 01810
United States

=20


 =20

=20

=20


------=_NextPart_002_01C0_01D4EA16.D414F3B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hello folks,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 What is =
the status of RFC 7800?=A0 We’re finding the need for this, and =
wonder what we might be able to do to help move this =
along?
 
Regards,
rob
 
--
Robert =
Lembr=E9e
Lead Cybersecurity =
Architect
Innovation & =
Technology
Industrial Automation =
Business
Schneider =
Electric
D  +1 978 975 9971
M  +1 603 494 0559
E  robert.lembree@se.com
800 Federal St.
3W-WS179
Andover, MA =
01810
United States
 
=

3D"https://www.schneider-electric.com/en/work/solutions/cybersecurity=3D"ISA_Cybersecurity_Expert-small"
 
 

------=_NextPart_002_01C0_01D4EA16.D414F3B0--

------=_NextPart_001_01BF_01D4EA16.D414F3B0
Content-Type: image/png;
	name="image001.png"
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAnQAAABICAYAAAB/TmgwAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAP+QSURBVHhe
7L0HgGXXVaa7q+6tnFPnqG7lHGw5yxFjMzbBjG0wYcgwwMwQHmmAGeARhhnAwABDNjAwBJNxzras
LFmxpW51zl05p1vhfd/a51SXWjIOGFt+06dVqlv3nnvOPvvss9e//7XWv6pNHb2rDa2tqY5/lbq6
tMpPbKurvLOSVldWeb2SEr/5K36zV2pqbEjtbS2prbWZn5bU0tKcGioNKb7O/+r4Pnvzkjfiv7pU
7/vF69X6lOr5x8HdK614fL4TO69tnKs4XuxWbOdfnt/X46/mU8X53er92+Z7Jk+19vnaabmeuCQ+
4wW//eoKL73GOtvIQZaXU1pcWk4VDlLHm9VKPa89h1/gPQ5Sz2/fsv98HVvZPA64ZH/wu76+Eudb
5W/7Y3llOS3WOCHH8Pgr7sufFc/BTz0/DRyvUqnE57lXvTYvJven3eZPfcV+t1XeI9teiQ/8hueJ
e1r0QdnVdTS6vr7Kj9dRHs/r8vL4m8+jbxkD7BntKS9s1U4tjrnuprFXeeEe73ynl0Pr/L55P89R
bvl+5/7zHkQbio+jHdHrtIX2rPBjP/p5vlbuxPJSqi0vplptOS3z2cpyHrfx2xsbfViXqvxuY8w2
NvA9+5CbYh/UV6sxJhaXamlmbp574bioS43VSox1x73XVGW/uDY+s4dzO4rrLQdacZ/LMe/Y8dLi
/jhYy2uPsbEcz4DjzX6NfT02NzT3Q35SHEPei3x9Kdq3sLjEb0d53meez+YZUwsMJMedHdTA+Gnh
Wh1Dy3xnkc9q/I6x753lvJXiGbW/YnzkIRDjvUr/1uzbpdXoV3dY5su+jj/X7k1+1n0+8qPrGCoa
5q84btzBtXPUO3a97mJkOQ/4RHiAehrgkGtpqqaq81PRpxXGegMfeHz7zT6u+gxyO92cW+o4cNyX
YlwvF8+6z47nc/O79scSnenvPBfYTo7r+FqpTw9P3J1GF89xxGoxH+ZzlFtcUzkpFc+bFxD3OcbI
+Y+f+s3cF2mlnEu84PLpys9e+Sh538+fsOioPAWU/8v9df5Rir6KP88/jhf8nftmlS8tnppO/bdt
Tru/++q0NFV7ejMvvnOxBy72wLO+B5glG1J9Y0taWVxgUltO1daOVGlsxpgsBwhyshWchXl1QhUY
OLnwewbDMTM+m1ZHZ1IFg9fV2Z7a2loBHwIEJk1+VzEk/s5GJYOhhqoGQpDipOV71dTe0pSamhrX
Zr7SpMcEtwaS1iz7OkOfDUFsMbuVZiEblrX5jk802HnuXY1rzWAVsMPEPbewlBaZ8SuF9anSxmaM
t7+XMI41PnNKtSuqGqs4MMDLtvH95ob61ApAqDY0ZdCmcQhjbB/m8y1hEJeZvMem59MsfdcggOD6
ljh2S2OFY1TC0GqQNXgamwwQU2qk37rbmlI7oML2L7oP3wvDVBhAQYcGzMm/vU2g3R7nnVuYi3um
Mfd+NDc306gqoKDGtS3m9+NaGQu8v7yyGMeo4zoEpxWAegZFS9lQ856gwvtaXwewCcOjJfW3QDVQ
S/6zADkZlJ23NmHoilvm8eKjwB6llcq3M+5hYaUC4AR0oG+XFtPy0nwYYbcKbfcao7+5Rm9ttL8A
nTNzs2lufiG+7Xcch13tHamhgX5YrvEZxxLzRtuzwfcY3ssYy7zf3NwYsMU+bmlpiXEeCxG+KDBs
amZhVIwf71sxRHL7uVfzPGNeX1NTcwbnASzsywy6YrG0BgozaFob29E9Ag8WAFzHLOO15lgBeAo+
4p6wj0Bvnvf9fGqxWCxE26upleeriXYu+9wu1GIhsVKAJNsTgDYwerEk4LhVxlRD1ed+NQPEAvQE
AOKaBIwZ2OXnyjtWoc9KIJOfv/K+5Rvu5QaGib3z+I4Fine2QEe2xba2MS5bG+sZ/7SD+aKJ57GJ
NpUAzuezjjHnfZiaA4QDbvNgqou2CnR9vgSerMnife+n98RrKoFc9F2AVQFzXuS5jhVhHR0cTFOz
PK91TfkKCwAXbV2PfL1Ha3+vn4nyta4b/vnPWBuVi1z/zuA3forno7z/Xt/aYFgDcsUh4zt5sRDd
en4KPH/etfec8Ipml23lWZjvnEiVdp+h9SOuaPfFXxd74GIPfFH0gNYYgIIRrwI4MAJLczOpVt+Y
ljHi9UtLqZHZIa/cnWQyQ1NXlWHID/4qBibAC3+PTM6mwdHx+KzSADhj/zAYHAF4GMtHDaaGQEDg
j1NQIxP1LVfsTFfu3ra2ml9v/4t576nzYTF5FQvgPEHGl/KqPcCE7RN7ZsotrsGJPYweBs2ZT4OQ
OZtsmIBcYWRqfHG2thDMhkDLhpXzn9ekkVjQAKwsxXkaKiupa6UGMKU/6Z/JmXmA2RKgTTCWGR4n
bPuptUngVJfmMD7Ly9kALnKsucXFaLtgQ3ARgMKTFuzFPPdnNc1nlog+1WDZ182AkpbGaoCEAFR8
2sA+S9y/pWhfPQBEwAzYFGBzv6PfAZ/LgLToq6AwM2tYV9+UTWKwXpwDsCbAr4PFrPd13MsMANwn
AItt4bNVjh/fDTbMz/L9KIFO+VRkg1UYs8J4rd3DwqasgcGSdpBtifPQzoYGQJwslrc8M1oMxmIM
0DtVwFeATO45gE32squjM8av40/2xb7LjGsToKUBpmshLQiUgxVif4BvQyNPQNyDDJY91iL3bXB0
jHG0GkCuo7UJ8N9KHwCuOGfu48zYZtzivZ1JU9Oz0b+xqGlh/7j+YtXkng4zv1OykgJ1Fx4Z6caR
lmifWwPnbQagtS43AN5qaYqxIZALGOkzJxDn0FXBGO+5kJgD4AXQ9cwyvj7ZAUoKMCFgzva+AIl8
z7asAaFKsGAen+GVgVzBbgmcgrkr73XxsJTtKR+eOF2eCtbamtnKfNODBedflQfHRYzjurONe815
ZRhbm/JSb4nnxWPVgtn3WZFRz+DTtrg485p9rmqgzXn+FuvZm/lU5xeCGcB6b/O98uOYM+LRk9HM
AGjNA+Cw8lLjPpXItJhzMkW+NrbztMd+jL84csHclWM/06rlcxCXFttajxRArJwD1z4sdirOnr9k
A72WuA/eCu9nccNzi4qr8/nM+8fhaRsdfP7kF19d7IGLPfBF2QN4MfJkEpMORm0F1mZ1YTrVd25g
AqwCShYDVGhI6+txOwJMZKV0f2i0NE66NmI+cAJZamRyZWYUzAEW6mB7KswaVQ0sQNGZvMbEuwxo
WMGQLssUibrqnLTzZBoTbCC17JqS6VrvSshTT4ZhT1mOeg25GQUAlcsRcC5jfHVTCeKc5Pmbn8xD
wObwBU2hRlwjJdCsYnUauFYRw+KiBhOmK4xpscIPoJrZHr/jOUdnF1NTZSYAoEbEVbXHbMdd1Nak
Qclu2wbYuBZAXTPGykMKLtzfgwgUNczxZ+AIwBnGTTZvgTdnZ2ppeXohsyBrRnAxXIBtzVhZj6Fh
r5vPLnSOLTMjEJtdnAumTUY0mDfvH5YiwA0nK9m3BsB4fVVQl8eG7toVgGGlwvv8nPcLZYBTH8aB
Y7AISCv8eD9X7eumGAeFtfkkD0gGdmHp4oqy2Slgx3lDVVxr+b4AU4bS8VsRoAYQ4NweKwx0vnYv
QHAngxduY9rTQL/buXlR4j4Z+LUyXudhM2dm5gA/tTS5MptavW7BfBhIwXo1M8l+h8uT8RRge6gV
2LI6OsN943lau0OMJwBoX0933AfvXbR93aAuGS3bIQu3nNFFAFC/Ey5Z2p8Zp9XMsC0vBPhcYFzJ
Pi0A2AQ4Mk3+jrHsFcaqxudIV3I8YBmgxMNWGHKBkc8fuy4VLJXX6DhctIsCNGW4U2KEzJVmMJTD
KTKoKTfBfLSgxDhrT2u+y/nx9eBBC+Y7HI1yDGem2edrZoHniv5rgamrn8pHd1Hh/cyjJi9kPICL
nOVwn+bFWw5hyM+ofRcDOp4tAWA+UsyB0dcFavO64tnJ91FgXA9QDGbPZvu9WFDmv3O78/sRkhCX
5iDIwyS+U4KrAM3xjTh3/mq+GaveoKJbfB5Ld/7a45A7rDhh8TJPmHGsOG55X+Pw5Xlye9e+69t5
/Ra7lKxguWgoGnfx18UeuNgDX2Q9UHUSWMJ9pQs1GBkmzRWMWndtMl156Z5wwchmudJdhHHS7aIB
8XX+wfXlxMnEIKhrwODHBMjrKq5bp3TBwDJs0XIN1x8AQAdeQ31DquHC0G2VYIoWYUfm52G42nFl
MfnJHGm4sguvAGrn50BeZWOdZ9MMAVZKoFYspQPw2Q5ZmZjcjVEq2LaYMHVDykhhqPnc9msg3WJe
LsCIBq61YAwy2MrH0pzYMsFWRP3IDPjDtepOLmMSF+wc2Bzn2yb2ncVCLnJ9YWft/7CUq+GKtj3h
5o5r87pkkzI40NWrm22BYwEBsxGKvsbQcczJ2XkMeZ7fPbfHa5Sh4fOJuUViwnClxj2CadGlHJ/j
NiyATSNMn2wfXvPUyHdk+OK+0VYNo6wrHt98vdH1YU1oQAn0ivsR/SYLWBiRda/O38nS8q83bn5a
GOe4d+U+/i6MHW3P73MvK7KpdlPun7BS3s+wb4VlDBuXPxdslSY0t8x2ehMC5QRo8k7KulXphwbG
Zavu6aBVGB/BghYMpOxWADJZ68zeZTMeN68AN/aH47eaGmVV3b8wurmt+TmJOC6ei3ndvkU8lX0u
gGiEVXV8OraXeU599mZwLY7P1pLjqgQugk5fB+Arnom8sOEYHKeJtjvMwsUY6NP+YIzmldjatBVs
F/voShV0hku7YOV8Xe4Z+xWPYL5NmX32ZQ6lKGis4vZmMOTYdq4o78J5ECcwC7dicdtEkksybMav
crwZ3dWzRZxcwT6uNTrfvWhDzAMFeMsLwwxyvIbWhvysZ7arPFGO7bUb1o8NvyOoq67i8p0hHIEJ
QbfvGhDy5AGK8nkz+iuOUY5b+z/GSMGaXfA8lGMlXwdtK+L/ir9yzPJTtqf+XQK4fNa8qIytWEMV
70bb8i3KfRHPQ3nbC5AbtziOcnG72AMXe+CLtQfC5ZpgYwR09fw4Ly3z98LMdOqsLKUr9uyIadIY
Mle+MkiLrnoNqsZyzALqpjEwAoaRmYU0NrdQuDVyzFU9LEI94K0Kq1Ft1npxDoLW9W/U4dJcgQ1c
XahLh58cS4NnTkccXldXR+rld39PVyRc1AV4cl7KbECe8IoFqHNpsWpdlRnU7YbBkLGocQ48UWEE
swtKNjEDRY2TgEYABVmGO8cgd1yfYUh0LWbWzpV8xEdhEP1eo3FEnFujZyMEToI/WzVfuHfKQP1o
c/TZcoA4J9EG0JrGxHNo17KnI4O/mFCdfAVjARI10II4Z2EBX4pYPRlAJ/s50FvEg2E8jS3yvXra
1+hrmRoaIAM4Oj0XQMkzaHQNhrer3OYwlDZMt/DKqgAdRgR2qqF+JtqdQXAGjXX1CwDv+WD8GmG8
ZL38qZMhKyxExlJPoSaKu1U+IqUlOQ8iiru57hla/1l5twtWp4QUun7D/ZsPX2L7SMbJwU8RDpCB
nKA2g8XSuxfAMTYfAfsXwBpsM4abGLfsMtWtDPvm/Y77EndqDWhmw5hj4MKuB5jLVyMYysynN5nP
GQcLMMRz8y6AsttVAO3HPlN+Z55+H52aj/vrmPM+1cP6tjFAtcUzfD8WVtzjzCBlcCawagCs6IKu
XwaMcj4ZOo/rXXch4Hgux2XZD/aSz3S8L+ByfBg+YfvFuZp+mOp46jT87l+MT19ngjGDqLVnU2be
MSPbVY4F97UNdHnk5ngcx6CgKd+pov+KWxLfi0PnvmQ/meRIiuBvn2sZ7ej/GHB5QZkThcQzBUgr
4nXbm3BP87psZ+xWop8AOLkP47ptk/NNAM+8sNH9W1/L7ff4+V4X4K2IXSsbu4YfY17iJ5qUx2C8
ky84bwHuC046X0jui2JRlvug6AT3X1sQ+D2PWRyn7Kw8/KI/ookeJ36XrGBeLMU+uTNynGCsaYpx
sK55F19e7IGLPfDF1QNEezG5zgOqnISFMBhng+DnYANuf/Dx9OSpEYK9MXAwOfUwNAbOV3XJuVpl
anBiXZRxElxoFHWF4XqqyfoREyYj5zQc0ynAI7I3IxFDgNca7lDZh8W5uXRufDqdnZhJDWeHCYQm
i7a5KXV2tKa+7q60oa879QL0GnRXFTOV85iTdxhcp/fAphpJjWwGL7IWxqoJfjSGgrJgAtgEbysL
mVVrbiDoGRdrJCPElJfdf362GjF/2b2U59c8uQfDoaGKuTYzQA26esLYFPN1/JYpyJOoba8ARMJV
zVuG5+XX59ubA9Tz+Rs8bsEg+IXSoHpdebb2OnJGp26aErhlligDipzBmhsULhavwevx2myDAJJr
N2bJvwXri7BWQTpo6IOJgaEC9M3h/hKsdLXxnXA95qV9ZkPzec7Hy/lBWM9o5/r/f+aPSf52vuii
M9cdJM5vgwvgFi6rAvCtJVoUfVnG75X9l6mVHB+abWTOno0xYP8FsCtav3Y9pWVmTLGokWkuXaiO
6Ry7aXwiwHsOd71uexY+Aibb6nogFg22yaZyj3zP7FR5wkWeo3nGrUyqrKzfcyw6NmVeu3g+bIHJ
D7OEA4jP7f1GgF0HyRt+dwLGOzNyjJGIDdRo52SP/FMAKW/RcnHlxTNT2HmhTvS21697OTNZuS8K
fjPcmZlkdszlY9reDBzzMyNzKKiNBWMx7mKRYC+7ICralG9tvr/+38VSxAJyfrO9g3Er75Pfdw7g
fwK+tRCFyAi3vSzW6Ne2ZsBz9G92Q3ttAf6iLdmNndlLY/IMx9DtHA8r9zWmrRxnFuxvMf7iWZNV
W8d2FR8F7vK6ir/jK3mSKq7q/DiOR7gYzvG6PHy8X1xU8Zz7VjCq/sQx85gvjx+Z3L5f9HMcrjy3
98cvrds//5kd58tFTOK6R+riy4s9cLEHvsh6AJTmJAELgdV2sqxnRghIA+iamZ9LR84MppaejQA6
g73IaNX9JvsAUGMWWJNRyKveiOtmIstoo5RpyH3i5KMMgJl4fJdIa89kynwjM2ZjR1di3o33IlYI
V98o2aDDk3Pp1LnRYNPMOu3obEsdbW2AQpuewU5dZM9mkJTlPsyuzQbIrNDedly6zNayZCPTtTXJ
iSUNLy2bDxYvQzkDtrPBd6LM1FuAg/g7g7jydQAkJs+QQfDaox2CvDwDh8vYazyPHNa6QgMpCxfX
ZYA7ru55XKlTGGFdUjk+MfigMGb2qAB0TtdbwaQGsyCTEInHxjhq63TnZvaiDLb2pBoy2x3GT4BS
WJsSGgnuFgAgkRXKfjk2LGcWBjNbuNvifVEo+yyQQFOpkDjS0sE9yBmgeSusyHp24XPyYDwdyJWH
jXsX466Id3N0BOvkLTj/vQwTfD9ubHE/8u+MBx3IJjWUexl7CYhlfxMkchZ0cZV8YXqGJCLAWldn
RwCWGmgg9mUszMJWT5GROreYR4DZywHkOLjsWXa1cy6Ok13lOavU64icHZvFPgb0C7IDdIYbHmBd
LE5qJNWscoy4nTIxnHeajExBCZlNMab14ctyR3xcEU+W2a2ckONzb161oDC3PvdDLAQci3Fb83XH
+/Hc5ducl3U+s3mcZ5xxHuzmjj3f/x6PJWPsV7KGGTTm9sRtCXY0u/abjB/luh2HMpCuLpoYgy4+
7J8AbuWY5pi+H4lbxT0q56VgoYKGK1g+APMiHeLYjnlKls9FiyeGcK7Qpz4TcTyZT4ByLNqCGcvX
Gn1QXhp/eP/LcbT2O2OouC7vb7mVoHhthRU9EB1c9HM+VpkBfl4WJ45cnCfPSXF876+v15B4Me+U
n+fpd+1exHfKe5Nv2lrbLr642AMXe+CLswcM9U2VlvZiVvDBZmIgeN4HvtqIK1bQNjMaK9lIchBA
xMzghG9WGUYDcJW1szQOOWZrJQxFDtx3uo7sVlfYhdmPedBzsX/LwiTHNU5rObUSwBXuRo2nhiIY
BtyAALxJAOYQmbRp5VwcNVb4BrvjFqOxcc5oGcfUhVnjO1dv6U0vvHY3q/SmdIYM3CNnp2D+qmlL
bweTNW5Ur8uVe1wXRsbYIsEt59ZmiF1CYiImRifxzMppGzSAJcsR59UYlb/9LoagmJbL6bowZIUL
inc9xmxogqHtx/49SJPIvoVbtPi2rrlwwdEXLVhqgYCvo+3oZK2YdaxRC29gZtRKoxwQ2cmcO13G
lgXrVoKuomWCxDJwuzS0ggg5K7NyIwsU5lW5mRbd58RHBnXBfTMGLTJKI25qPeiKVvwrPhl54ZAN
5nnLWWa3lobvfAOyQRctZH4lfz+7RjOQzYAiux5j7Oq2h2lWcsTEnsxMF/3MoYZglT3SgtmofNc4
KxNZ5nk9BzifBpnNGvPIvhn0mLrheQQ23Dso3VodyRj82FVLS2Yww06TNNTk+OSf2dI5HwewXl8D
bGTZH5y3PFOM3QJZxCXwv5DksVWO3RWeTQ5t1mfBKcX4rSg3g1t0vnE2nek7mcY6h9JiAzF8xiUK
WvjXtNCaOqZ6Uu/oZuLIulMD8WQZdORjxR8kSq02Oi9k17PPZHtibLBPTjDK110yy6uEcax6rR7B
RQtPefNKC32wmJb4zEP63Bk2UHWByQKlkfHdwhzTyDma6vAWONTW3I0ZQK5WsicgYgqFnAK0eJ0Z
eR6TANPLmW4mnwUNwlWy+4vFl+c1jjYuao3pZmFDfGijyRgA7HDJRwcIjgXSa7vnrxVP1dp48zkM
HJ5ngWhywQyWY62Ut4k98vCLXQLe+SwXj1MMbz6LeNcYtoW7NI7pW+ufO+fb4oM4c/7yWsxdPC/l
01FcRAnw1hp/8cXFHrjYA19sPaCZj8D3MmZIxqyuqS1VkVlYMctNlwRAqrGlLdyxEZcUsWp5JR/C
qxgdp0hnYr+zqgxKzBk5DslZScBXzEMBAGIW4j2Bl98xfstZSK2wac5X19GTGtAJa+V9pVMadB+G
8WXSpr2zszN4dHXrAgRX+b1K+hvnXWloTkv8rAI4yP1M0yvIexhXRvO2behMh06cTk88eThVL7sk
XX3l5SFhYfZo1n7LE3AAO5qne0OQpbHXrRnJCbwfLtLitSDImEJd1qUYcBiWQuupJHSCveOgGpww
Hlx7xDlJr7EFCxbaf5ldC9cc7Vjy+FCIFaLDBVoNHKONmCDbEQSPxzBWSqZTJoHz1JRD4csmPwgq
zcJUFNbklrziz6xbdtFmsB0yMgX7EkHihSupFLs1ScD3gglVpxBDp/QFMLSwUSXnUIK4gLb/is9D
yQJlw5ddSYyD6PDcP2sGMpvCYJNFA2aN+taSAsQLs4BlxgvfV7ZE4KrUi5nNjncZIpN/BNFzLHRk
cgUG3hslNbx984YMcA9aWIQswj7LbJrF3MSPJK+gx30EZbFQ4vyN3MPB1tF0sP9YOtMxCLDI4LKe
8Tow25eumNyVdkxvAkjkhAuB9XjreLp9913sy1goGJUSCERHr+vucHXiRt1+ZHfacW4vIQ4ZaALj
wFr1abJpKp0cOJLODpwAyKHPVzD062/YXMtUmuwaSqe2HEx9Y5vSzrNXpK7pvniuVwUptPVc74m0
/5L7aLdxlIQcLDSnaw7fkjYubkrgv7zgcVzJLnLwB7fdl072HklV5FZs4+apzemlIy/mvbPpo123
p0azpEtAUzTGa2wD9F1a25muXrgsbVgeCGA+7zxEG842nEn/1POuAL9ZhKhYVjwDSImQB/7dMHJT
um7+BmIP7faCbfN7Pvfrzt9gVnLpbg3XcAGo7MeSuY8HuARIZQ9mwBtgbv1gjNYV+xb3q2TL1kBd
4ZI+D8TyN8rYurx4Wdc564/zDNe89kSWvmCP5RwXCzv+GSPYmJnHi9vFHrjYA1+8PSA2SZ1V1ebR
4MJSZRdMjudSwqReUVldoLidmtu6Yh4J18oag+TElo1qAEO0uFwaB7smU2cWa6F7phBtBYBWNzsR
yMlMON2oyiIshZxDduEYv9IKoNzd2YcGVSfHLrS9QlMtJxlMTE0Tk7QYAr0LGN/s/hUUArwWJ4kL
nGA1T3bnyHx68MllEiw6icfrQFusPm0yHq+vj7ap+m/8HNmnTdnd4oRtvJ2zsS4SM1a9XmP3QL9x
/ZHAQGMzq8cqXibSaMS8fGczTtDXRQwMx1pTwhdLhHsz91vE4MkI6f7hG+FuDUOgey0zER4pwJt2
w3gqz2niQxEP6PvaJV28QG4YBV2lObDeLZIscIk2w3II8DKgk1FyX7MoBdKyUMZ4ZVdNtCtcVyS+
AAQFI41M/DVYunp+WppauNf0X9zf88kJhSkt+uFfw0CU1iv3bU6Ese9pg27ftXuQLVuwjvGeWam5
P0ISxHFCUk6I40K/RHxYuEKJPZsYy2Yf4LoMKPIYwTKFy457FxqEWYRaEN3AZ/a97lVZqS7YtVYG
lYsAtd/EXrnKSHYPtvPZ8d7T6c7+R9JEdSZcmGsbTNOJ7tPpZMepdMnZXenqs9cQlyklld2ii1UE
wAF0ZaWJTzb1eE+XeNYeoMpBmqukPc1XcQ8BbgCv0a5z6cldD6fpNp7D3EvBsJUxX/FWAQx0QyaY
s8GBk2mk42y65OS1afsQ2e+gtYgtg2FcgNmrLOf8qunZ6XTH+AfSa9u+MvU19dLinPGthpyLo32t
iHhX5ng2MwN9cGl/6l6spB2NO9J8ZR4mrcjWueDC5vnOSMNoeqjp8fTc6ZvTzbM3MlZZrPHc2M8z
pMAGoFvnEn/GvqGrFVb+yPgHU09dW7qu5Zo0vzK/dgdKUJWTIhxfRXxZxKcV1HfEURYdVIRgBFrN
k2PeYkzyuwBJ7r4G2HxRPNeOp4iGKBi2cviez2CNuxMLlVW0LoNgzIi3YKaLc8VYz+fPYz5msGgK
s2feP58on8spjreVY4mQFfT9IpbxGTvt4psXe+BiD3wx9EDVGLNbb7wmPbb/cDp6ehDx1fbUTfKB
xqu2sBDljxZgYZbJbqyRPFHFkBsE7uwRQeQaQlX6AW11jdmNEkkExmMJsIy5U64ksgizgvxiuEYj
fE/HaRjlVd/TFYQbSCAyuzCfDhw7FfFZNYzNEsc3jqbVigowIwq5NpAwsYqA7+zyfDAG8kVZI4+j
AkDrarNUshhOD44Nh8Hu7uwMaYo2RHZlTI6dOpsnSlnFAHC6cfOE6MxmnJ4Zj15rZL4W6CrMb+iI
5cy70uDbH1PTM2lwaBjRVwRn29rz5BpzqGyl15cNe0zwgibez9IpWYzW40WcVm5IjKGoJsD5F5CT
ERQba7dKDFXg6HBzZRBobJzHF2Qok+GMvUASAypl2RXIO7J5gsFGqAnZqBIxhisVoBEubuOsaHVk
IkaMlpI1ZmfmoPgG2r5UWcysqUxQ6f/KViTudWYFMjDOegylj+xf8FiEkSz4hjiPwEyXL79Diy4z
b9mqZQtb2tVsx6IHGMtk9tKuCrIkbYC20KcL8Gwfs7DhkN5LRXwnkQfRsOd+VcyXRQmna+B/usJl
6RhOEXk2B/CdYTEwQfKDawJDB4JXdlwF/oRFxdV5vPNM+uiGB9NM/TxuvkKrosR0BSiQ2du/+WCa
g0W8+vR1qbrQmGaq6jrm+MenALpnwM0F98J+Rd97DbBig30w1Jc8kBaaGEv6IQtwEMH9LiwiON4Y
2gLgBXGYx+ty8xJs3ANppXE+XT9xQ2qvNKcZxky0qYg3dTy3tKC5196Y+ghtKGMGTUpQ5NgxWu4v
oDPEwfJaJiR4jDhOua3vk3w3AYPz6f3tH0mTSzPpRfMvZhbJySiybnG8Z/r+BUOuDGUQHAnoY5wX
wyZGrWDOz3jT9c8ayIkH7jxwKpm1GFe8HyNuDTTFgMtDzlfOAwJEY5R9TvK6Kvo2RoCvYy7JQC0S
SAqXbYkjnRdC1N2HvQSE7luu9vLhCmgYZ89Ade3c+XX0ZHahZFDo7PcMY+iCbrv458UeuNgDz/Ie
MPw3VZrbcePgLmLm6AD0XH/tNZE4MEvm6akTx9OBIyeI0yKGan42hIX7u7sDGBlbtICht7RUjv9X
v4s4I8GJyQmUFAu2iv/nupvGfOEuwhiuwvKorG+CRKiJGW8mExIZXJzH+CFcXMbxVRsEkfNpCukA
Ko3FMZyuIp5JRlEtNVkijRYzlbEwTbpLZbI4v/E3gibBqZPXxOxsOnZ2KM5Rli2qU/gYA5+MDYv3
l1Mf8Xw3XbEXw63T97yrLbtaOL8sm4awiKvSLXd0ZCY9cuB4agRMdsAI5hiZzOYImlSy95py3zgZ
Z/2/etstOC4qLegey2KtWVTYeEDdg9fs2Zr6NmwBaMAGhauoMBrFjKxgsqBtai6Ht4cOGQB53vPQ
bFk2z2HWcq7mUczkZi97VWF0sl84mNgo98Qx/b4gSPAZNiEbnMwrAp4Lw+Ev739cF2NgNVjQDFpy
r53nAPLfF1qSArA95cHJ3wlDHPFd65gGBKllCctElvNHc9/yfKV7NrM/4TL2vIYIFMki9tssLGVI
iBiMz8IhXKQaO5njIn5K13wwbfTDNIycrFxOJMmgXwAXIrawx7KkOe0mgwT7crRhMj3UdihNVXH1
ArCi2xz7Ebrga64OwB6lxlhMHGx7Mi0CFK9buSmO85QtwEUBFMo+KbumMPSBHbyeusZ0rudUOrD7
QeLm5oitK9hbWWlDDsYRU2ZxtEgfNBHkUA9jU2tGf7GnFWZXxCr4yqzowW2Ppc6Wanr5wvPTMLGp
a0K5nptdWvism592+lApH0fOfKafc8hBxhSxrbBgIHeE8fnU98tLjf73GfMNjhGgmDF1d/s9qXmu
IT0/3RpZ2hf2Szne1sGxtV0yoDN+NWcb26asV5dHVgCuGB45xKGQrjwPeorTxW2PrxVj1r6O56a4
Pg9T7JPxWmbOSsmgEnoFYCv6xOEYmbTrIgrWQlOLY2Tk6MFzJ9qOiGksVi9rQC6O4T7xaVxzALii
79deFtf91E68+NfFHrjYA19sPRAuV+BQ/IukBq7A4HcDrauImm7fuQv3JvE2g7qhAFm4qTZvGkgD
vb1k+M0Sl4UgsMCOH2PaBGjGHy2w3wJyDTpJDSY3Biu7xfgtSIu4rbA6aRk3TZhO/l5yohJcFcK7
NUCkcT/tAMneVoxLc0tqbW0Lt+vwxFQkD0zPEtsE4BNICK4itBq3lxNtdWUhSn3VAaBMnjBTUWPc
BJgUhy0X9UydBJeobjA/S/wU7cBMR0k0QWgbdVF1dRqHFitsDQjHEPQuEO83NjoKEG0G9DancTTf
TBRZJbNxlvqhmzZupK5qW1ynosQzuOAElHWzU2l+ekJYmDZeckWaHh9Jo4Onos6nzI9Cy7lEWnYr
tnT04cbDSJ4eTj099H9nK0ydumQ5GD+y/Qwk19UGPRQxcfRqiMz6dzGpR/yXnB3xZsphRK1OQbgm
UxshcLEfg3XgWmEEGr0vZDWH2G1hoYzxk81yn6jXG5bMIHa+Tx9HwgpsVJbKD0uUDU4AeykwgR79
m21nvF/Cr8yQFlYnrGamOUrjmBuajdUauNNY+mZpbAugU+5j7Gc2tFrMHNQfwrkhRo1gdugpcn0C
aU4noKsGgMkG3yboajVBwb+zM1q7mlnlDG69VxnQRc60zHMRpxhuchIehnFzDnWPpAZclPma6tLs
ScIHTk6w8GlIjRubUsvOVoSi69LUk5Np7PBoapxpSpd3C5rPAxe7QDZ16thkWhjlMx9k/wvmJ99L
x2sjzN72fjQde1fTPRv2wajNcF3rwBxjY/LMWGoYqUtXrG5L2xs3pdb6trQCwhJInk0j6cmWk6m+
TS4sl5erQWF+fPrjiI83oxnZ9ZQ5L1ro7Yv7YYPMkjUWNfdPuPVK0FncU5N5SiWO8mArxGHMnGZe
MCHe8IUu2Ple+iVcw4A6pFnuarg37ZrfFe7icovlE2Nz7uwsFVVcLK1j/IqddKu3TlNzujNrN2aX
/PllQozJApzFmrEcW09pd7GwKUjotQZ4vTEyi6FYZkoFkisPUIDHImkkQGGJsooDrZdDKcd9EHEe
I9Yl5xvjmAtAWB7PcxaAcA1cFl8pNRNjWRQeZBlDF9rrj/iUW3rxj4s9cLEHvkh6APufmSAnG+OE
BCO6kSKuy0B/MhqvvPTSNDf7cBqeIWYNMHLg4KHUe0tX2rF1U9Yy07gYW4QBKIGdIqo1QR6/zw6N
pJGJyZwJWyw3nWhkikKTzskvJk2wnGyhdTFnxmEE5mHpCveYWQ1qoxFbt7yYMwsrSkYwEVUAFjoU
6wGCLbrK0M0j0ivVzY0HE1jDTbza2kOQdjOaYFJ8SwA6vi8rpiuX/au4bIFkqSvAi4XPAT3zo+nh
T9wXrtqOzq7U0tYRjGAYU/ab4JoEs6vEbjXCZkzPDqexc6eIWZrGKFq+aRXXU1vafcnedBo37OLI
SBrATdy9bSMcyHK67957Ac4NafPAhrREjF/T6nyaHB1JV15xHaB5Q0y0I2TmnptC6Jf4xemxs2nf
4eNpDK2+nbt2pW2bB6Lcl6DEvnPCj9qb9LMurhKM2F6Bm0bT2K9psi/ruFcyhjJ2jQ2UdxMQxv3J
oCEns+h6KpgjcZBMlW8HS5ddf2Ff1rmswmBwz5TCqZPBDB1CPaKWDHOcZXZ11VjLYFWzSzKftbCk
4Q7KSRrZlVpUnQgXoRjxfBWKkm0p/VMyXeq/qe8WZZjCkHEdUdfWpJOoYBr2zmszW3iB+60OVxuu
Qt2qM4B63aeWo8vXZ7arHUBwPs+GBjTGh245AV+4qTPQz0kAuV/y9WYjHJiBMbbYzAKjyv00m1Xw
TcLLxKNjadfUzrSjFXDCaU/PnU1PnHs8tYw2pxe0PC9dsfXytLG5O421jWdc7CV5LmNWh1fS82eu
TVvbN0eyRAnmou9oR++W1nRz76Xp4+370rmGocLNmu/hEu7kySMjaeviQHpxx63psrY9qb+hO9oe
1Ry4ptOzg2n71PH0UM8TaaR3FJVq6hQfG08b5/pSe19HZPeuoejc1ZEQpBD5kkC3ADHBGpVuwgsn
x7igdW/ap2jrtQ+2pec1PZcKD63EyM2kA82H00jrSEiKCOxqvbX0wMGH0mUNl/v0xxiy71ecFIbq
0o3zN6eNrZsjljA8xxGv5r0ngYWFU1t9X5pk7gigWeCtEogFO80fxscuAG4FmMtRGqwcpoVLtGx3
MXQ9UPEIrV1QaNgVICvvnkd7vPK8gcXze4KsGCsxbnKbc8JF4SYt+jgfJbenBG0lXozvl/sV7Stj
8mLdFJ+dR3DxDLryy8T8xe1iD1zsgS/SHkBdDtcRLh5FdwVcivBaRLydDFPBl269ju6edNmle9PM
o/vSHGLAo+Pjad8TB9JN118bReAVBtZ45ooKgDGCjcNw8p6A7tzYFLFFFKo3g5DYuI3d7emyXduD
0ZsFXJwYhC0qZiBFjj2vMXVRgYBN9ydh1+jiUWcWBmx1BbAXLIRukzzzNQksF2YAKsY4deb4NqpQ
RGKGbuWp4exO5F/EB2JwrCEb4SgRuye4hIPQHRoln4LDgaWg+sXEBOANNo39QmeM4wjEJum3ZerR
tsgcNhHLR+mtBdiP/t7+tGvLRrTCsH8zU+ncAw+kHmITr9y1NRdz5/UMrKLu6QWMzxRB+J1duLqv
viadPXogHT90gPqvyD/A7K1gzDp7G9LY8GCamxhJLej3TYyNpMUtW9LjgLsmWNQ9WzcQMwerJ6Nn
MBLXGBm3MeUXAq+0Oa4xCDOZtMz3hPwJcVolI5ETXHKfBBwSjPjbJA37yd9hvAqGQkPtLTAGSpDh
/TCA3GzoeoFiBoer1PTNh86xgtkYSdcEBZLRYhj28M1ltiGMGCWfiutwn2AjAYu6/gVvWbMsx2FK
M/jbpIcQuY6YTeOzinjAuIzs/nZcm/AS7rYw0oWosgkP3mPurTV3s7ZhBvAZAOf6pnML6Aaa8Wob
PYZ6fQGEvIyCvYvXhdSFQFvDTgJSGf8WlR543jrr2tNLtjw/bWpD75HOHJ/dkq6obE7d2/vSphYk
Q2S4zYKlSP169tK40Q6Y2lt6rkpXdlzKM8QCKkqHpdRBDKdl31rop5E0kR6tOwzrXFOsI8bxMizb
2P7htI0s01dv+JK0rWFLsMqn5ifXGKnAsCud6eqV61L/+Ob0kcmPpX0nH0tXrlyRXtz34rStuj09
vPDoU1yo3kMB0AjJHcssprwfZeycmbSGJZSAI4YAJ5kDvBnTuh5MGKLRUteVdpO00NXYTaY6KSET
TWmk5eNrrKdj4KGpx1J/0/YYIx44AzPuHY7jHc1Xpt2A1AWTQfysBD8xDgXyi8TiKaCdF6VrIDye
oAzoKiTMLCo7A3IPpvaCba3NAdjjgckEWmz5UzUAo3kF8ipB3Xp2ObC/7SiepWhBjM3csBI3rjvs
U8DceUbugn3jmcrj8nwCRn6v3EJVpXjun36FF9+52AMXe+CLpQeqTnRmlQoGjKsaGZ9In3jo4dTa
ApDAndIJMyXY6Nu0Je0hs/Txw0fxR7Wkk6fO8H532r17V0wOa2LCzExl1QTniccOHkf/bSL1Agrb
W5rTkZMnAoTs2LYtjOQSBm14fAo35CJGqCHdsHdHuPZmAEcjw0OUQiJ7jb91neoarMOgmsRQurTq
Ql9Lt4E/SotwUoBd1Rg9wONKE9UoeKuKC1h37DJsmu7kVY4TEyrvCyYrxAnViNVbVlICELpAXU11
sDynQK8ZF4/MXqNgkASRnNGrGxXX6MQ0cUltacPGTamHPpudGk9nh4fT9PR0JBMsYDxrMIO7N/Wm
/k0AWdo8OUkmbp5jcU2zH+xfA8koL3jBrfT/o+mhRx+Hybs0tXf3pZaV6XQGdq8F8Njd2pSGxiYi
8WP7ji3p7LnBdP+j+9MWXLtbNvYE4Ao8JLjR7em94S0BbKz2ZRAK11xM6oK3YjKXZQ1g53yvYSmA
XWksQ5QYUGKCheNGoB0MXvh76M3s9StsToY1wcwUxjROE1ZNS5mZtzpdr2WQUhgZ75bBUqqJCdIy
wIus6nApAQpwja8u5YScOuoBhxi07RWkwuJlMJub5fnr0T2Lz0zA4b1SezC72vKFCiDmLRxKZ8nO
NcBclrIuYZcdKlbQoB8de1FxxE4q+1OsxvFzXdxsnEuQ6D4RQ0mGaceqPHBhTe0GQFrbDlja1Jo2
oHdmQsuO+m3pKtyfdu1ChAagw8a4rZmO/ZRNsV31C12YMIrpl1aj+PlvieeFYQqIq6R7q4fTYPMk
IEcXOLvRj5OnJlP7UEd68YaXoRu3IQ2ywChBfgbsGf1wxXEXu2p96fkLL0zbG5BTad2ZequwW8S4
1prXZaUW/ST4mmPMN1JmT7dzHbGv4QrlmItdOa5zrQs4xxzs1xygaQ3oRQfmCi+DeARmuddVXNTN
lZ7UvNRCVq2l7DJYgn8nPs82PnWTUTWhZJL43kVF0I0VdJciu7b8fvZeFiCIHbKHNrc3pFYKWjHG
bulLXX+q4prPo9ECGTrHxBiwv/P1rDUymp4/i1/FM1GyZ+v7Zv2F5c+L76073FOuvHimYxh6C/MQ
zX1rOEHZlnhAis8LIPq0TrygTy/++ezpgbKsYDmOnz0tu9iSL2QPhA7daqxSsxBoG/FpPe3NaXho
MI0MnossTwuEt1PJoY0kgV7YpQBZrI4PHjoUoK+/vy/LYBTAypWz2Zr7j59N+0+e4Xtt6bnXXBYA
58ix4yH8qesvCwPnepbOPP490N+fWRAM5wyxeg8/tj+dGRuDUVhMu3ZuDBfk+BTxRsGW5FqisnDh
goJ9yIXOM5gBLeZVu5IjymyEwSduLKRNFE92BlcPi/JAMI06X2YDNCgrojgy0IKg9xnYL6KeOFbO
qGsG+LU1LacuDO1Gtd+47uGR0TR7an9aGkH/ThzCMQQGK4oeAwpHYRc//Il96QaA6qV7doc72j7z
0jtgAbwG+7Wdts7K2my+JLV29aZNZBSOjU+S5UuoehMGfH482vvEwcNpCyzg5bt2EM84mU5R0eMR
QN/O7Zu5R20Rh5dX5jkrLnTLiom9dG+HrSrfcxSatVyAssgcDMOTWY8AevZl2IEis9ZSaXRSwDk/
8/sloPc9+ztc7LmQfTBz4QqWlTPDVrrQnwIGFgxLNDzkK0SmjhZZrTITUSuU4z0F6DlGqnBzhsEr
3MYxqALZ5rbFECsctAIs9jPuUP23MPSFIQwQVsMNzz1vAGAVSiXR/rK+p821pq59U4K63H25gHtp
+I1pNOu68NYSiwh4hW16rNaRxissOswaNibtktX0ofn70y21vemK5S20hczZ0HVj7VRkwbZEhujT
pwrB7CRZ3oOEIcwC4ux/kzHqlnJoAJq/6UTfaJquoiXJMb2ORRI2lk8tp6varsGVuxVWD4DMv4iv
DGb06SealzGr70qXtnVHu6ZEi5wtql1csEUcIW+HJEwZGylo1h1aAN7yKxF7GDGHTz9OOX6DK4d5
nKvMIttCrOxa4CXt5fpcVJ1HS3FbuBmAR0DuYhX2H6Y4iEs6q0LfeqwYG7EQyVse41lCKP7FWAl+
tWD9nnqKC5sb+KkEXGsDqmiLJ/Cz9eAvQG0BmuN3OQBjoK7b+XxCw1pD1w5bgLs1JJwXUGtbPvza
/wp8mU9bAL7Yu2Spn3YnL77xbOwB73ET9mBZO1ZSs8/Ghl5s0+e9B6pzZLKegDUzCB+/BgH33ena
a65KD953dxo8ey41t7SEO29iFPHTpa60ZevmtAo7NzJlIsJiOvAk7sGOm6gmwAADoISMCUbqyOmR
9Pjx05FYcePll6ReSiNNAehEDDlTMrvnSj270tjmrMP8eU9Pb9qxZRMyEEzkJFoMAebmjYXSncZe
l+3eSazZJo6LS5d9LLU0a6klgNQSYG5piWxVQaMTNQDHOrRRAsnJumB83E9plUXKWIU4L0wbPtdg
KxsXx/Nkjrtw1TqcMEpKlwr04DNoJdfLcTrM88AVXcX1KpBdIomkHS2LrtbGSN4gWi3N1RPXB8P2
wOOH0ujoWJT7Kj04VRgkXW2TkzPp7qNn02pTZ+rduDnt7iFea3IqPTGFy0hGkJ9mqzQ01NLw2Hg6
dvxUuuaKS6lx25m62lvTOKzfoWMn0hn6fCfxjd0AO3X+NJeeKzRO+V8JzCJm3ffDbZljf3LGZna5
hrtRECZTUSScZIMXZi6OpQkpszyzVcz7Z8PiPv4uYyfL8Z0RYjY9TwUPcfcDEWW0GS/jeJnByRgz
liHZUulqjcQDfwne8jEzzMxZ1cHFFmxisIiCtgL4W1ZKRs9/6qUZOtAEMKqwWDDuT7ZJ13zwjUpG
BMtXtDwMdB6rGcxZrs3mFn0YAJUqEroLC4u/udaTrpranm7v2ccxi5JdILWjbQj4ro6md7NwuGR+
Y7p56tK0cb43+hHHMK5+wkobdWEWRpzfJhotbV1N7115EDZsX9ZFhIFqqbWka85elTYssjgiBAAJ
bpopQM4hDDUAXcdCW7pyw5WZQSv6NnqxcMWfZxEL4MGvYAWKno9nah0GiQMXmExx7NDidVEgeCqB
TJG5vX6W8/7K+q5n7cpjhWYfhqsF8D7eNpLOdB2JOEGZztgEg/Rto4uDYhwJqkIE+7KU9q3enZ6s
/0QAM/XtmrnmS8/ekPqWNgZbFc0vriHfUVdAGefl0UVFFvu0HGrPhDm9HcX1rWHV9fvFd4uTPAXU
FTvF93MflWP3fLeWlWYc52XP50uNU5ZAbN2JMzGcG2Q1i7iqNdb4/D3K3VVefAatFzyK62/TxdfP
kh4QxPU39KTX9r00fWzivnRw9lgx/p8lDbzYjC9oD4BBWlJ3Tw+g7gwMAit3gN0swKu3r59s0va0
eevWyCzVIPr4NxBj1mzs1/6DaYoZQBftk08eTNdddUWRZVmfjlN79RGkTtxuuWwnZba6YjURwqwB
DjTw5yecsiSSE6guSvXQsijuarh0xycnKNk1RCzbeGrv6iGmD0OFkduyeXOwf16DW47ryj9zALT9
xPwdIju3EXC2nQDucZiuYXTiZB2bSYSQJWxt7gipCgPj1XhbqbaEu7cHsbXsrgDAwUZEboDu16JE
ViK2DU9S+EwXFjBIgEkZlCrHXm3swoBk1q/NGpAYrVV13ChxtkjyxNjoULCLzchnzEFlHDkLAzny
OG7tbalr+2UhlXD1ls60qbMh3fvkI2kZ5q4Te9wK+LRyAdA5tQHiTsB2XrJ9U+rr68U+Uee2vSVt
QDR5aHgsHTtxIg3Dtm7Z0Jd6ezpCuy9iHembhigknyf6ACMBnPJPRebL3+5j8JgZcEa5h60v2LrC
cq8xOQF4dHlraWTf4m4UDFxhqfx1QTbiU0d+AZKeYlVkZszixeUe2RjGMOKC5KUgrPRlhVu5MMLZ
Kq0PdsqxkFpu7VwkcAhq/SeTHMwhoMl4OK5ziVgp4z4Nhm9CyNUuaKBvc5JQwOL4L5IgCuMZ56Yv
deUak1hv8Hyx5eSRbNMjrg/mbO/otnS47mw63U0GK8eO5vGvBuhaBNw/1Hok7a+eTjcNXZaun7ki
LnNpdYH7GZGm5y/W08DaTiYSfYBtsdG24dXhNDEzkV62+pLU29wXpcVK+Gw7V4hZ68J92UMChGBx
vTUX5sS4CNRQuEG974EpMggKuC7gjxJk+b6t37zm0OyDoYxKMnFLsrs7+uKC/T2GhOf6962dWtdN
4lHLuTTUspgOdj2RhlrProE5s5FnzhIWgSu2hZjXC1tRx5QwywxVRpQ53kdXBslknkovSq9KvQ39
UZnFa1+LXYtRuy7+0eSWp11dfmPNlVm8zm/GAc6/WA/0CsBUktFPGaYO7fI8AdaKAeN9KHFfAcrq
6BfjDpeJva0Q4xnu2kJSZw04+vVifK6qvVM8DnGOggzPF1Y8cyHhWDCRn+R6L7797OgBR6QLmD0t
O9Mnph+/yNA9O27Ls6YVkFZVQFEn7ANSIhRaHz13Jh3D+HcBGLbv3BEALrIQdeNolIhN27B5C5Il
0wj/nkkLuDBOnDxJjFxX2gtjdnJoIj145FQwaTfs2Za2ATBKsc1yoRqu1lhxZiNXToFtZIReefne
9OSRY2maeL0GY9do34YNG9NZ2LkpXcOAq6b2zpikjLWzwkXMlfwvaq7yV65wcH5Fa3B8V08/tWAx
mGOTfHc29cAYbuttwV3ZFaWdlD55fEyl//r08hfcksZPEft3Yi5kP1at4VlMgFGn1gtBJiWMtTIp
zZ3IPFidYhrXqHVlcaNRYWAG0nNlLseS0Yu4VjE+CDk3W38WcFapm0+turmJRezduI26oBNpZmyR
4PgKSRDTZLVW0tDgEDFErajup9Rt7i6q+s2cv5ukiVnctscPHkTSZW8Rw0gQPBm5l2wbSDu39KWD
uLwPHuPeTHCtGwF2ne3BitaIKQr5B6GOMWl2YIE6vCYZrXqEg0N7TXYjtNly4sha35bg2c8L6xbm
QeYmElrUuqMvIsAtu1Zzbd9CxmTNsjwdEGSmRCCXa/u2oHU2MTYU2bybNm4l5nAqTU+OZyCk0ZVx
04yutYlWh2EsQWg20iEQ7FVnjYd4LwvaZtuWnai5RJUAo0GdumD56KPCjV4a4og3tHcKRtkTOpbj
asog+KJ/zTyWVdYVaX/3znelW89dlT6y8CCZo5MR0qAbMcda5bYuNNXS7QMPpWnG981ksRqDl9nr
CzbeKpze8YHXVuNnlrjLebKmS640f5hZJ8uLtVXbvXMZ8BT3LzsY88JobbMfaVeZ8FJ4UOPjrC15
QXvcv/iJBJHi8wwIn9583ylCMM9/yL4NstvXLKaPrL6neL8IG7B9usqJa1Cy5fqGW4ghbHq6YRNs
F//KftHvOrOMaxp+vYvPfbZjfNs22xFdVCxTHMex2MljLD4t2l8Qauu7KH/ZgRO/112ox/bv9d+N
+1DsbyZ4XqvEm7mPcoOKhPD8TAHk/HDJDOxTM3gB0DnsYlLw7Sjpx7TTyd/2zTjBI1xU42ZCL3oc
W2Z5c68iayc3u7xt5aU98525+O6ztQeclz75cuPZ2uqL7frX7oGIAMtBwXkVrhEf2LghbegfgA0B
LKmlFfNLZqwi1oZJQX26KXToTo2Mkwm6EvF0KwCfA4NoaiFOehXSHJdu7o+pI6osBCVUrD5jznMm
yskMbiuAs40E9n/7v/v69IM/+bPprk88TKWFlgB0S0iOzBJ/NDdHnBrxdKk6nDr7BtJjTx4JgDGH
YLAZs7a9HbZOnTpZxiEYrFlcWLPEDz129DR6ejPoiBGbRwyeAK7/mitCdkRmzUzelakxSmAtpV/9
4e9O/+t3fjf90eOPpSbYSRnCJa6pDnDb1t6eGmDhsnsPI9veF1ItNdyd9QaJ4wqtwi42A0IWWB3L
/rXiil3FVTrLpU6irWWmbyNJJ33dHaFE/6Jrr0o/8F3fkn74x34iPXHgifQombXTsCgyZ30WP+9u
TUcBohtaK0iVdKN1Z+1ZcWNjuv+RJ2Dm2mACq2nozJl0+Y03wK72BI66hKSJfjKKj50aSo+SnLJj
ywYyjKmwYYUDGEpBwiT9FO5lGMN53O9mgeqcM0mkAgANkBPheLCntLuGoLGGsglWpLEQlQ2AGG7M
DJLUpTOZxNqqwVxFEJmAUB1AqBMO6Dlky3zPbF+tmuXlZOTCOHEvlwHNO1hU7L308vTxD707KmVs
JPEEgjNNjqP9Z5Yq+5R6ZyGBA5CscZxyvDk+QmcvGL7sbtW+lqXtstxIlnWJthKPZZ1gGUqVcowD
U2sxV88wCYH2GrdpfBhj1oNGfVvZXYGfvlH7QJct15m16bIdzSMdfUKA+Y7alvTSc/XpwekD6VAr
IQ+UxGrpaAltwzqrgGjoEW97aMPjqf1oS7pq5dJ8TRdsUdGhcLH5UWT91jIw856pOVdhMGTg5oOn
NBD3ldi8wHHeB1sZ+m4XxrKVZr/AI0FJFtfhvnznwpi4OI2fBSAvmFthUpFk8TQAWPRJ2ZanXF6Q
e/laSkRkprDAZPTAWGqf6UzXDdwUiPzCGDxLWq0HVsFAo+2X3fVZILtcYEZ923DbFzymi5e40FwC
L2q5hjs+ty4And+PiSvf3xIhrQGl8kKefsvWsGFMgbC5+fryM1K+9HfF+qrGqZIuX6OE4TKJI1OP
jKaFSZ43wNv0vrFUJamGSSwtzcBcIwLt2mll0vhc6uoOtKbWra2paQPjqoN44w6eA0WsmQPXAN7a
Cc/f66cNsotvXOyBiz3wRdEDVd17MPcB3CoYszZiyJql8gmUtuJCJSZLpxuDmjP5EHFJGJ5Ldu8G
EDyWxvlgGlD18L4nyNbsT5cA5K7Yjo6aLjLFuorlZ9Yry3FOEV/DZDUPSAhXrMflg15i+G68cm8a
Ons6dZDReQSm6gjVF7b1b0hv/tLb0nXXXRtCvu/80O1p32OPRezZq1/1yvS8W2/FEM+lf3z3e9Nd
d9yDltve9LVf80aSEVjREodz970PpDd86Utp7wzyIFekxZnJ9Jd/94/p8P0P5OD4vp2gup70Ta9/
Vdq+ZXP6ii9/fbqfeLcTx0+kb/u6N6fL91yShsm6/dt/fEc6e3YwKmcstfWGsO/Nl+5K17zsOeH6
uO7KK9IDHHPf44+n176SDEIYub971/vSo08eTk0d3ekNL31JegUMoHFVf/dP70wfeP8H0jnc1d19
G1NdS1caBbi94Hm3kNU6kQ4ePJJe9+WvTbe94mVkF59M7+DaTpw+yZ1oBNQtpK983WvScUDrgeGR
yMjd3Lsxbdp1aXr/hz8G+JpLL33RC9LXfu3rQxT5j/7yb9K7ONdrb3teesGtz00fu+MOtAVn0stf
+jJi+obT2VMn0vNe8MI0i7afYO/AE4+n0wDEXLkCtzIg6eqrrk033nhLAJgDjz+YTp84Eszn1h1X
AYRqqW9gI6xqYzp54nA6d+ZkAH/d9pddchn7DaThc6fTscP7A7z1DuAqHtic5hFmHgWh1WCiLrnk
ktSvJh/nOnr0EExcU9qybSeJN71p71XXpyefoP4oMjC6XTW9LRx7+25KUNGv02QWHz/yJO2fTjsv
uTza09VNEXfG26ljhzmPMZKyzFb8RAGE727YuSXc7w2A07Mnj0a856YtO9LpU8fSoO0nS1IwuHvP
5RyrN80Qq3mUY01PT8Z1bdy4JYDf+PgYY3KEBQiag3sujcoiBw8fIlFmOAPdcFUWFEzgDFm0xbSj
ujENzHan7WO96VTTcBpqHkujPdOpqR8BXQEdP/W43R9oegQB3a1RT3ht83AAv5nTU2l2UnmebJAj
Zo++7J7q4rtqLQJoqblblsSK9iDJM1udjsQQwVwGI/xPqnINcRWsUmnnxcPhM3XXDH7KuMunz3RP
hTUB1vxfEav59P0/ubuvdBWX17Y0g9wKYsuVM43pRb0vT72NA2lo9Uy+BvvEvrZSynHK/hGTqns9
YBLP+AJzTe9sf2ruoQoHOChPTSUTl88UrLWXHl2R40pzXWOlfta13NJc0ajcHyXgXENr+W7k/9Zh
pdj9gq4NTbhoZHZlB0jnr8UhoP8EsbuTZOID0hbH+eG9Sh/jA0C3tH8w1ROCUtnameonyPx1HmUh
Ud1BhRpjfsk0nj02lRaGcE235Oe4QgWPKsxetRftTX4r2hzXXWo2Pv3mXHznYg9c7IEvkh4gHtnC
88az6VPC2CmhMTmaWojHqtPvVNqhYvHodZWSIX39nal62Y50zxNH0xRB/0sYzR09XekFezYieGu1
A1bpxsJELIo6XpklaALIdbU0pkME9T95+FgwIOEqCFGwlDYSE3bD3p3IIqykB4mT6WDS+eFvfXN6
8XNuSO/+0EfTnr2XpZ+4/rr0n3/qZ9OrXn5bejXAaXTwTNq4d3t66fNvST/7C7+Yrr/myvQzP/kT
6fEnD6UDR0kUOHEsffe/+5q0mbi7Bx/bl669dE96zo3Xp9/+zd9Khybm01FU76FH0sypw3hTZ2D9
Fsj2bU2v+ca3pDe97kvSE/v2pRffcn160XNvSb/wi/8j3QXYq9vYy2Q5mG7ZeWP6xZ/+CYDUR0Or
7PWv+E+wYriuT5xM1119Zbr62mvTt/3gj6c3feWXpy97xW3pY7ffnrph1X7q+78njZ0+jvGmjBpu
31EqX9z2kpekb/qGt6Rf+KW3pre8+U3p37zu1enjDzyY9uzYkf7D93xX+vn//ku4YkfJsk3p5qsu
S6940fPST/7Mz+OCnEhf9drviL75oR//L+nfvuGr0ktf9qr0BP1r/3/tG78akASj2dKdrr/5eenP
//af0BJ8NH3Tt35nqh2qpPd/9Pb0n37oJ9MMgO7k6dMwAY8jh7IPhhKXDTfl+muvT895/ksBLoMR
xH7Dc15ErKGVQubTDbe8MO7vmZPHAFed6eatt6W7PvpeWNKpdM2NCMO2tKXJidF0GYBQMH8CsLZz
15605/KrSbw5BficTRt2b0r9GzYHaG6lBu5119+cHnv4E8ESK4+yqFQM43Pbjktg6M6RQDKSrrnh
+SH4PDp8Nu0AyPq9Rx+4M11+5XWIQHem0ZFBGFUSRjB6D9//cUAeLnvHL+OsfVN3uuzaWzD6Y2HU
NwDkJtH3cxx6PY88/EA6fvTJdNX1NwI+bRfja8v21NbZnR7gHO0c9xrauAQ7e/ToYdjqmXTl1dfH
8XXDXn/dDemBBx/ge9QRhhEtwUIlsoIDDgXwMP7ruU3XI9ExmwYnhtPxpeF0oPVUmmzJ2Zz1xPSN
d06lYwQ/b1zZVHJIAVzsl9VTlAWbuDwNtA1EnKqb0a4C1j5iOa3V0rFIDOUysjzIiET5LpifxX7q
zhIiYMZ2oLQiXu4pblHZrDV/aM4M1i8cgCSAUK51+pQtQgwzSMqaeRmseb3LZHMv0Yan1KG1v1zm
FWzh2rGKc6zVRvVQ/Js+Pp06T/WkW/teki5tvyIDrwIuByTiDRcwK6dX07UzN6f+VmPlcgyhHGsH
8kBdDV0hMl16HIKtDeYuf38tBLMAXgXUyk27AJxlIJm/m1+u+9LaxZSArwDdxftrYNXvG8PGQnoJ
4LZweBopJFg3QkRqVLuIaAhYuNrwfGoA7MvEWXojdDHxiGRHP70uSrW2rhfGmKtHBkogtzSBhM2o
VV04xyR7j8IiH8KjYCxpK9ncHG8Z0Ni2EVmokiX8IjFgF5t5sQcu9sD5HqgqrqqWW7ie+NfBhDCA
66cTQKartEyELxaQ6yY1V6wruAA3podODKV5WAJ8kcSADac5ylht2rYpFKwi/iMYCuYg9lcs2MzQ
A/v3p1MwXZds6ktzuH/GR6cKrwPxZrgZLTF2/yGYIzTsvuZFV6evef2r07ve+c70S7/81tS9eWf6
vV/7xfTmr3pdOnL4cPqd33sbALGSXv2KV6SveMOL0pe99IVRY3OQ6gy/+L/+MJ06dQqR4Zlgyx4l
meNnfv6X0n/6xjekr/yqN6QH7749Hbz98Sg837Uwku762DGSL6bSfffdSz3KhvSGL3t1uv/Oj6aP
fei94fr79u/5T+mFtz4nHWcCHIYxmavNhZbdGIkLd9758fRPsHFv+73fDZfgd//Aj6aX3/bi9Bu/
9HPpJbfckMYAf7/1R/8nDcFsXXf15enr3vzG9JznvZAsXrJYcd9981veSObujvT2v/37YK6+61u+
Pv3ZH/xB+pnf/EMAzrXpD/7nL6XXveZL0q+89VfRB+xIHwYY/tcf/7F0xSXb6fOWAHgHARevfNGt
6fv+/XfEMf7ub/4iEkC+999/T/qGt7wlPYDGXTff9WcFEKnbddumjSRXbIv79OhDD6T77r832Khd
ZMrqqhTQvf71X5EWKFf2zr/7s2DTvuprvj1dfcOt6d47PxwG+8zJ4+neOz4UIsvPv+3VAKy9aQRA
tWnz9nTPnR+B6Tycnvv8CiDummAEdfM++vCDaRAgPg8wbGyaSoPDo8Ea7thJ1YSdl8Dg1sP0nUp9
CDWfPHaQ8+MeNkuaNvXADA5s2JTu+/j72OcErNwV6QoAWm//pkhuEEDed8cH08bNO9L1t7yABUpH
Ghmyfq8sF25SNQ1p90P3342sYkt63otemfY9cl86dmh/uu3VX542oLs4zj3ctHVHeujBe9Lhg0+k
zbCFtwD2NhLHp808DaspY2ebt2zdlnp6+9K73/OPDIfF9JrXvA4Gew+M62i4IMU9SqScbR1NM0hv
TKGlZizb5dPbUgvaala/2N6+PW1b3Y4mSDXd3boPQJezORtw1x9ZOJ56V3rOu10LIKNr/6bGa9Ol
nXspWZfLgwVo5f/zZOu6SNsxtyEdQiplsHkkAF0jpdnmNy0gK7Q/3VoHW6yG3Zq7LwOSAqeEq1R2
b4WEjUNdxGvWSJSa3bwOoJKJvW5GrUfqZZl9ja/LyCjHDgpO5+rRhKsn9jTTURkfxbyzxl/mN/l4
eQYwQyWLxt7CXe5J6MQK8aW3bLo5Pbf9emSGuD7O07wOhOSjmezUlG5uvSFd0rkHWRb3y9dlnKN/
5yVmPle0I3osu2EL73DObuWehaZjSKtcuK1n5kqiMy9a111iviT7NE+H5zvXay+ybeeJi5s7SmiH
5cpY8OrNr+8gtKOL/jzH+4AyXaYeV429ajsJWhtJ6DqNpNE52FbKolFSI9Xh1ci1YPkB2FpKrn1H
S5p4iBAF/LEVBKcjJhbA5xU3dLVQyxsZKeKFl2cNh3jaRV5842IPXOyBL5IeqI5MzqV7D51KjV19
0Pg9aY6V38GRhXRi6lysvi0FZjyT2layTxpTXT+NTNy6r+4nJmwEsdTGOowyhmKCOKx79h1kQm0k
47Inqiy0ENfWQKyUE5HB8icGR1I7WaS3Xnc5TEJreuLMoxEEn+dXAeBq2nd6jJ/xdOP2nvSC6y4L
WZAX3fay9K6/u4n4seW0GTmTxsiOWwGsfHvqA6BMkAVrXN/BE2ejZuvRY8fS3777gyxaa2lnZ0tk
qt7/6BPpCHIq9973QHrFK1+VHjwzmY4T3NZAEkAaOZEq20kwwNhPAUxbYdHaCcp/1wc/lE4fP5oe
PXI6ver1b0wvgUX707spmg6Ig+Jh/6Z0ZnAwPcHnQxOzaZKEjv0Hnkx7d2xM/WSYqtU1Tb8Mj4yl
7/2u70hX7NqSHkQ42FqstrMCy7VpQ3/6mq/+inToIG5DXHrXw0D29vWlN33dW9JrvvqNwfJsohxY
B8xQW3tXmiLGbh8ubgWKb7n5Ftp3OA1s2Zre9kdvS7fccH1kB3/oA+9Nuzb1pybYmgmYqD2UC3sS
IN2CwPN2gLgiyNqeTsDOtVdnt+nZ0/QB7vYNJIts47s5+L8eDcA96YnHHqIN2znneLjEb+S8bcQ5
KnlzAmCju9OyW5OAmK4ehGfZrx1G6+ZbX5xufM4LGR/EFSIvk6tN1KeTR/bHPgLJbkSVr776prAn
s7MkmNCWCkK59UbkuyjQTsqwqXdIm3T1Wkf37OljEf81PHwu9muCDZSJGyeJQjdsGwxeZG1a9aRY
oHjNLmAUh9bd24/712NZsUO3nNVBbF8vcZqe6xx9YkeN4+rX3dvS2hEJOcNU7zgFqNOVu3fvFamz
oyO94uWvjmvogKkchJ0zps3qHYKzMx3j6X1bHwhDKlNlO0Zo5wsWbkitVFhZou8WGggRaGQslptA
gDbMLmFwnwFSZCiCvC5ZsDUrfgT8zuAknGx0XH8NrcjZnjTUBLj0E5MzOlfT4c1H09ahDQkYmZM2
Isy1/HaRhFDIZewHzD0w8GC4b/cO70lXT12V2pbbIst0LTibCzLzcr7NrHCvuUzXAEADJCeaxtJk
w9Sa+zdi7aj33EysYbD36zbLdzWdII6TuNGV9sItzC5NW5rS+NJYGp8bQyqJZzp68anfDYBGn5kZ
XKPf/B0VF4pNkRPdqlauKLf4mPYEtMxhxXEfDWUIEBZ4sDxPicrOu0/z53kGW7+tuZs9bBZ2XNun
NjafZg5NpIVzLAol1UhgaN3TleanTFwRfXJnAWwVvBy9L9ycqgNtafoYIjQwbFF1xHMxSa8whzvG
QjLHxHSYuXqL55qpDzCs60I1ABfr7IHRAPhqXtYRv1uH+9WavQpq12aeIcHlKVdy8Y8v9h7I8bw5
rrVcc2RvgTb3mYI9P/kVuzDKR1GiKFLNPu/dE8++c3sw5J/8/C4us3BX3k8S4/+vW9UszTk03kJh
CpeNSuIqly1gnOcIdm/CCDuhRbkrV3b8MQIbZ4khqy5MMvG2AkpaMMgLgIYlgv2H0E776EP7007c
hLrwVq2dSmzHMCtuAdKW/q60azvxR8RbjRILpmRI4ZcJd97R4dl0x9FxasriUiBR4cHHD6Izt5De
8a73pL9/zwdwxa6mLQPdcQu/4xu+hmzOM+n7f/WHEdrdlH7j195KnNwUrtWtMFRO5EyKGKHDp0bC
tSuAmgMQjhF3ViMjdWyFbDreaxs+GAkMM9TM1PiPUaf1OJInc4CVGa7xA/c+kfYQ46Um36GhyTRF
e7a0NabDuNyMlm4CcJ0cnoAZhFVgH/vtCrJ+1aPTpdrEdf3bN70hru8P/+RPqSQxmm6++cZIjmji
GOOAwF/59d9OL3n+c3CVvjS9573vI0lhNv3Fn/zv9OTQeAC+Mfq1F1+rZdiOwzpuHuhLH/vY7enF
L3ohgGpLOnbkULqT2LhGwIS6fQKSBpI6BNqdvCfr5mZQv5mjt9xwXdqCjt/hQ7BfTOplFmULSSWG
axk/VsZL2ZYOAKCfCYx7kLoxoaG9oy8SBVpJFrHf6kjU8JoW6HuzUgV5jz10X7hFm/luK2DI/axA
smQyhWwKgPOa626hMsiZtP+xT6RuZGk2b925ZlS90QIoa6Yaf+eDrH6i521saYeNoxKJxt3KHQre
BiMMEIjM2hw2IIAzq9FHOYRsi1ixqMca7I3MEu6psMw5e9W6v7q1mmjzGPenA5kZAdosLvm+vg1k
3o5FZqq217HlWL/7nrsDGA8QCzhNvKbyEjHZCG7YV3bOiTB4T8DC4xtPApCQ9gEYLVGI70jH2fRk
x4lIZsi2n8zGaRJ+lunf9bNQ8YcZlPMwc2ZuKqRrok5M2F4G19tYB8PFvxumr0jDHaNpqGE0pD9Y
nqXp3rl0V/UTaXUUpr22OQNnzhuRrjTWH9v7eM+BJKAThC4i0vvohsfSYMtgev7ZW1MroQo9iyww
GmBPMyJMDbsb0ylAcMcS48iMGqDoCMzkk91PpLkGAD3nCKFmq25w7r6G3mDangKErK3Msa8cvTI9
0voImdjZVWvSyJPdB9KWxa3piqWraGMGxk/ZAokRgwaDpxixSTvnOy9P/Q0kWQWCLdMpCsAXEjcl
ySYIi3jBAjSW1F2YhmwSg3lTyLxI/ImDO74UTidkZZk6zIuj1KSez3fdLYAs4SS6Vy1pDIWe3a1m
VY9RMm0hy5UsTxFmMMr8SZLVxMMsZOrHM1PomCWueJm5s143q9VzrFwyDrCj3rbIro45SHA3bTYw
sXTGyEUZRLLvow3E3FERLtXOID7FfV48N5uWr7dk4uffMP//ybjm8IFCNP8LAHI+WV/WlH5iQLRU
YGRlaov4WcMRathn2f0Kz2qZgvTP3ROfIKsWeRQ3v6sE0Ocb1EVbY65/+oJuffsbsUkNMQ85E7F4
sSb8p/jOF+uYpEIWq1gDzZkBdUs2QdmPoZ9m4LigoIGkAsFYiMfSf+qZQQ6lMdLn6yg0vwroakCv
q2qWIiChguDwSlNblPuaXJCpaw5jar1sSz3VM9g1furUOYdbmWGCCceIY3dpwGheetll6bveKFBk
AIIwH37siXTPJx5JG3F/6Y6rYMS/5MW3pvd+4MPh6lTuZPveS9PrvvRVlBVrRAwZqQtcb00AmZie
Qi5CNxuZXri2mEbTLEkDVc5Vz7EaJs+luilcEgN7yUCdS3P0x3OfQ2LCez9CvN2B9G3f8m1MmHXp
FS9+XvTJ777jIwEIdndU0mG1xaxEAbgYJIt297bNgM3edD+fW2t1FWZRgd9NXRhkHh5r1PZSWeNW
EhPaYSebWE2v0iZ10G6/70ESPR5Jv/BTP54eJIbtwUceS9fedFN6/J0fID6sLb3m1a9Kn7j/vnT7
XfeE6K2VJd79gY+kN73xjWn7ti3pV/77L4RczAk06B7jOFdfc21U55Dd2wU793d/93cwYhPBnpgA
cd3szWnrNlyKDz8SgFk35ASg24SLKDRBn5npqoUzAeX6m25Ol1yKEeWe7ST437bOAFrs0724Us02
7iJbuJcM6Ts/8v40Bfu2B9a0p3cg2NMduy+Pc5sw0QyIM/nBTFGPF/U3yYDt6ducthNf54PKtAhj
tgAgRV8PN/sM4DDHK9UHQ7h775XE8r0kHcEdqivXZIUR4uuq1wJE4747ZBU6LlxpYYLz/4KLWQ9+
2Cdq/EoIWksYS3vGc1C3+Lrrb0mN+/fBUu4OsHbu3FncqZfDek7kDFb6/OSpk1Tp2EV2eF/U/b3i
0svSoSOH05nTuPvDmC6l7sXWtHdic9rfzXuZIkqrPY3p/V2fwJUJIOWtaQDPEi7LmBxtLMefJ05q
w+qe0J9aExamz7yvaW8l3bPCWKkcXHPpOb2ZJNGAsPa1I5emHRNbU9Nsc9qKoO7YdtoMcxMJF1y/
8XkfaLsjbZ3blHZSQ3bDbB/jtJJGGylf14rYcdu5NNE4mUFoSNDQJASWD88dSrND0+lL+16V9kzu
Tvf1fwIdS5433ast9emxnfvSyMxw6qVk2DRg70zbWcCVbuZidUx/LyAT1DBXSTs6d6RT/Fu/xfnY
ddfsDhZ9w+lwJ0krsJx1PIdVBLcfGn8wDcwMpL5Kbyza1rboF0AOQ+i+1fvSQ/UPPWXytl8alxvS
lcNXpR2zu52SSmdrHjKB00R01gdmDBpfXJKAa3ZDV6n6lMxlxydTjWSFpdnslnVnEzdWmB/r2zk4
4GoJUEcWVCQp1DN/yjL7/Yjh8z2A3yqrDeeUekJHFEFv6AMME/JRaVaonR2VJoGNW7ZAtIsBgFxU
dWH+XSXrfZXqMvpp6/hO6NSNsRiRpXMxPgZ4U9eT9sX5/cezGlJE3c2paaA9mFUTJtZiFr9YLdoX
uN0unpoBOwKlUpLrC9kk77XM/0BjX3px9y3pOR3Xpa1NeI4QJx6qjaZTC2fTE7NH0r2TD6cj8ycL
YPbJWyww9Ltv3vBl6dqOy7naSvqtU/873T3xUGoFLH4+NmOFWyrN6VW9LwIfNKVHZw6kR1ALKEFb
2QaBtWzcK3pfkF7f//IY9w9P7U9/MfiONFwbe9r+n4+2/2ufo7piRQUCo8WszYC7FuJ/2iqdgDZZ
pWX05VqJk9sEoyIjlstz3fHYkXRuboTJDuQ7cRLDfQ4JTydCNciQpkBmZAUjPEcg7woMgbPKCnEr
rhpXkMOYgiEL/TgYHsi2mKAsAWbs2vvuvDftJHt2D7InGjVN2533fiJ934/8ePr2b3hTegtuyUVW
GP9Atukf//lfpccOHEo/8r3fmX7k+/8DyQZ3prf9+dtBne0wcASXHzgQyR4VAF5XS1+6675PpCf2
P4mUR1caW21Kf//hO9MYMiM9tK1KlmmNGKjVk/vSH//Rn6SvJSFhEnfEz731N9P3fetb0k/86A+n
MUqh/egv/056/NjptBOj2E7mWwUX6JHTZ8i6/Rjgklgq2v04cipHSIg4B7jtAxy9+/0fTGfJGP2D
P/vL9B+/53vSbS9+SXo/+z+6/xCgYIrszKPpHe99fzCBRx69P/3TO9+FhEVnevvb355e8pznpP/4
3d8ehvzOO25P73//e0MmZcfGgchCPYX7+tEnnky7tlAm7eGHYARbqCU7lT724Q8FeL70ssvJDJ1N
7/inf0h33XVnFEJ/xz/9PQH9t6Rjx46mD334AwCPI+kEjN/jT+xL+/c/Hrp8zTCL4W7XINCHx0iU
mJgcTjfdfCs2qoG4uI+l+4g/3M290j16Epf0pi1bUg/ZoPd8/APE4t2ZdQKJMbyRuLMbbrqVsm3n
0j3E2VkBZHjwWJqbPhtJDyPI0dxzx7vSdTe+IF16+WXE2x1KQ+eOwvKNkX07GHI2O3EhHz/+eDq4
n0QJ2L+xkdPp9g/8bbryulvTdTc9H6A6lh598P5wV5tNO4ILNrKscaHqDp4nzq0URtY+TpKZepJY
Rq3qAkkZxviZCauky1GYToPjrdl77z23p2uvvSndeAMJFADKB+6/C0ZwDLcw8jwAN0eoTKFi0R/8
6IfSrt2XAUg3EKv4MPGBADezCGWjuBfttaZ09fCOdLx9KC1UrU+cEyQWKvRTZbJ41gtXp88S3505
CYMyvpou796FhrDs2QWRXM11PHuzT19xhlbbUjp1BB3CRzYx2Q7Qhvm08VV96cyeYauxBTjy3xLP
+bH20+lE25kMJAUaRSKTvwOkReKEYLc+zQ/PpMl94+mypj2pq55M49FN6UBDR5rsZkEIG+73l7i+
k52ngWmnM79VHCfOyHXVYJKmcTde13AtIsft6WTBmJYTnlh2WQ/BQiXdNHxDGukcSVN13MOifNfY
xrF09MSh1DHPorItkPtTN3KcptYJC699KFvL/DPKAq6ywEKncydAXg/F+S2Alt6KfME+ADkmrVjV
237fq43ipn+CkJKdHann2q5UB0gyDm58BPDGOaos5qL0HoC/cXd3sHVRhVqpEkCnISjBsuFSXQYE
VgcITSGeDS9xqiA5MrdvJHXeuDF1XgngAvQtjJPhe/c5gAL7IFNSh1FjdZxZNRnBdrJXdyBZRF3s
motkhTCJmaugt5njmFmJs2hbxtXLyg/6FmFoMl1br2C+nuTc3ahlyjR+gTfHyKL1mum7XAXk6ZvG
WcCUE3CyDuUC87hMkWO1Cdv06brWPJbl72Sw/PlsekCgM7+8kLY1b0r/dsNr0p0Tn0j3AJLs92ZA
x+ebvVoPajY3bUg/tOPb0/O6bnhKR/aQHHRZ6+70sp7np6/d+Lr0g0/+XHps9lD0wSfbYuEN23VZ
2yXpurYrYreeqslX62o6/yuOn9JdfG3bZekHt39LsI1/cvZv070Tj4Ru7fot38e6tK1xY7q27fL4
a56qT1Xav7Yw/lds6xfi0NUIXpb1CObDQvHEQ8E2qLlmuv4csUVVAN88q1HX1mcXibFjIquDeWtZ
wAUAmFtl4s2ipCQzqGzHZKcgsfp0K2qCLQL3mKVq7RvTXB2VFDCGbVRNqEPDbZmKC3o7lIw4PTic
XvvtP0g1iN7UdvYAwIWHDEmKZgOHARW//Bu/E67hcWTgV9Efw5al+x58KH3F139r6kPuxFg9iGNW
tTB07PnXQ6eJLQJ0aoQADj/yc/+DiZFSQrT9/sHZ9PFf/l2KpS+kLuL9Vjv7UvM8MSZkR/75ez6S
/uLdH4nMU5MC/ssvvrWod7ucpnt2kPmJQO/I4fTI8CISJwPp7gceSu+6i/iiouzZW3/7j9MIRr+7
uzMdgIn8jz/6U2kPgOQwma/f8QM/xgOOGwQg147b0kSSaTI97+cYA2Rq9hM393t//GeppQ+2pH46
/SrZp0MtvaFrt5Os4tmZeeLx0JmCWmhkkh9gwpahuOve+2CKyGZjgE9R6cJs0Y9+5EPpEeLsDh0l
kxYWTU09a6j+1m//Nh3+NtT8lbXI978BVvbXf/1XAQG4fKgNWsXItFC3syKryEQlaHnvuwCFH/8I
xqwWgL+eh6O2MBDiyo89dAc/90RVERnLBhgBpWlOHHkUqZLHI/5Sn6NSNbPT5wDch2En5qMSg8b0
2IF705En7glJlIg1kh00OBxD+r5/+L21KiOnjjwYrjoNzwJj4MjhfWnr9isjEcLNOL2H7v04rKfX
hKQIsZD33fUhRo2xoE7WMj91AMLBdPfQ2WDpxpEcuftOADDtbgUQf/D97w4tvw0D/QEQP377B+P5
0KBr372We+5GGgZgLXMtAzcPg/Kh2+9O+//sH8L97uXeeMWudPXeXdG/eW5ZTbuW+tNtI1enj23e
lxYb6UPKjUTZ2nWIRMbGA8yfBaoR9/TC1uthsTamQWpCPG0LLPP0GBLfkVUeOjOcls7Ukfm7l5rA
K+nGQ9uIW21KhwZOMtZxzaHNVkqaZFdtAY4Kq1Z+Jjuka3H61ESaQP/s6uoV6ba+F7CoQ65muivd
ULsq3d/ycJptgnWzZmzhwixdGxFPJ0hFEFswMr5/GDfvxvSigeeGiHNZ5KqYg2G/VtMgwsF3pMMI
cbek3qXNaebKg/gI4zaEJ+GRzkdJ0NhISbxct/gpoO6T9Eswv4z52WVi0VZgqdyvYPhCGzPYXLUT
AUyKYyMRtD7iRjAnmzZ3Ehcz19K+tzNi37SBy4DU2dM8m7BojZth5GXUzsKQd+EJcNz1wtzg6qyS
7BCMGaElZqY2bcaLAVtZbWXuZAHdxE89i4l5mlMPayaI1j07cc8gZdsY49sBiggkC2Rqk4B55ts6
5oH6DSQ6wcw1oEK+DNO3AsA0hMZV8yrzR3VjZ3TS8iixvxFXSpth5OeQNVk6NZVaNxpS8IV3uQrK
NjX2x6geXCSR54KYJ2+1d0ZGSCZM8Ce420v1hF3N29Ic9/XJuaNpYslaRv/89ZThD3tadhCbOZkm
l3K/frpbCQb7YK12tistVE0v7bk12C/PPb5MOcbZ4wGSBB+fz83Fn+f8xs1ftQbmbO/Q4mgaXRoX
ClMxpTMNNPSlrmoHYuNt0VsXPkrP1Ob1rPjn030ZIJ/qOpcCRKeXZ9Pw4lj68Pg9rFsKr8wzNHa9
RuVT2PzP5834PJ2L2cLAafW5cq6ZhnER6RLLXdUDNmSDnjxyMFacC624k1o3hLZcx8pcapo5i2EH
zMUDwERpcC3AbJUA71ZmnqrfnydZQlcr54i4JRe8SJws4koggC9Wx5je7N4AdLiC7VyhjBEAqw7W
pR2w1cAxdcu1wIY1A/Cm0F4zKLgdV2YE4lu6CyDSg/TEMi46XYcLxGNNYYzrOzZFUsKMMV20w4X2
gmKrAMkKgGABpmgQ1nB1lWDtoWP6MDh3T2owvktXKitpq1OElEkXWZ+AxX5V+BERDjc0Ltqop8Ag
U/h3aXwoDbqCBtwuMOEs1GgDT8nw+BQr9nb6ixVOA/X4BmDAcKNOTkxHRl6dn+k20S1i+TD64SxV
O5Y1gvSLs+8gpcump2e5FyvpxJlz6SVIqLz5374BN+8WwNiv4QprTVtRh5+nLw4cPBQl1HaQvTrC
pJ912DgW1hMOldbpXlHgwsceoV/dRwDaVatZ4AZewr21TLyNpbCq1c4AdNnoVmC0pnHbmRG3HNIl
NVjeumKyCtCk5hdjREBmnKRMRNQ/DSOPkeNvZWEU4w2/u0HaGs8gRLLoa86ONF4oF433O8b6KC+x
ygprAdC5Cjjt7MagR6xcsTBxJBYiwopVR1a1n8u6cNXjxEY207+WizOWq3SL2FbHsOBMgOr1RIIB
xqJBSQna5BiNK+Bza6CGRhmrwhAlxqg6Vto7cOHzd417cOz0MGxwJyATcWtAtpcvyEqHqZlsLOZ2
Sn/tYGGkIKx94Odc78LgfBp/bCSN3T+YNqz0pZ7dA+n49FAa7WNhdHmurxvsUZTVynFc2W4Vr6MP
eA250djRRFWUtlSZPwOjPAsr2J/27qOcXvN0Gr2UBdk2rpnQBN2Hwc6URFR+pDmGfcEwB3yMn0Di
5eRSel7zDellG14cFRq816stS+mKxd2p+URDuqP73rS4CdZS93DEleV2yUIZgD99eCqNPzGc2ie7
0vX9SNqsdKRFmSqQRz2Apkpsm0NpkcSswdMz6aO4Rtowjs1DuFLpx87ruGaqpQRDs3MlPTqxL122
vBdWXlH0fM/KfgxXe9CNdhP94S227CAAp0JSaBdjsw/5pIWY+2Bkea5m8VAYA9vCtXlPaE1kjZqY
gGgnAAgAcYZ+bKOKzVbmn4NkmU6z8GM+WxoHWMyS5MEzWOlpTvNHxrMck+cgjq7aZtYqSTvMk0tI
JUUICs/gMlUfFllgNl6DEDvjcsXYOcChfbvE8RbOzJA4wZzI9XdcgYvZZAn+bt7anlo3VdPoR86m
xp3d3Aee2VNjeCQycKggSVJp51nGHVznQm0EAEmmvxmx1pgO0WLOs3R2JiSqVlQr/8LjOap5zMIa
vTZd1nJJeuvJPwRkMXcWMVBeVw2bsbV5azBht0/cnz48dne6peOa9L3bvzFiu/bPHk6D54bTWG3i
U4IoAaEg8Ad2fHP6s7P/mD4COPj0XYc8qyxqL2/Znb5t65vTJYDC/33279L0EnGijJ2v2/Tl4d58
25m/Th8auwtyQbH4Tx8s/ksxgPOni2vdrOV2auFc+tUTb0uPw8TJHG5v2pRupO/2tGwj/AmipoDA
Pg9em8yjLs6odS0Tum6KWN8+911dxS7wT/Dqsb1ngnOZUxO6IvaO9xeYU3UDC7SamCeajPNd1y/P
dG6ZWmPh3E+L9c7hD6cnZg4xVubSQ5RAa+OBLllbY/qMk3NudzyUck6290L2dZF2LxbX6OeWeVzP
7npMz+FvFxFel9cyh/2xLc20af3Y/Jfes3/p9+UeAzRoHCKo3IwQV29MNMYLGWO3OD2eFhq7ATSs
8MrYHej80Ahj37LOK6JHabmxPYz26twE2AiqH8akBlPXyPsruOo0fEvc4CZXqHTUIoHnK22bmbxc
pmPMAUgzZA4uq5bP+Uemx1gRM9HQns4N21IjrlHdtf0Yzk7kLKZxpzU0AugAjiNIYHSwTwvHOQM7
Z3yWYNXNwHevq9rAapmM3goAYJXYHG/xSv92XK0I3nLuFeRalnEVEyCUmjpxU9knw6fD/VO/cQ8T
H2DrLFUxmBCNuRpmco68QuvJkmW4gFyGQsb1MH2zgJYpAFgL7ulqJ24AqO/JyXkyFudJUmhFlBgD
B1OE3xtwaywdgcmwYS3dVJ+YxqVNkH0Drqx4kGqzaZZjCzjN9lymJugsIPvIsRPpL//+Henuj30o
tfO9ayidBv0VtVyNz9u5dUvUu7U4e5RGsz+iO4F0TOLWuV0KJVU/I6EBEGAms4zr0iIuNOIjrTpU
oS+N2ZqjCoEF681yloU1Tu5D7/n7NDmCfhzslkBIkGim8jxunwr3sSHKFoVzJB4Cf2s5Mu3NYx7A
0hq/JXDKmZYB5mhnjfNpbAVQgfV4SEPcGlBex6RRY/FgAodjNTJapd459NDZY6kbsWVXZYKwGouT
cwg298GMqr1o5m8L7njjH+cx5CbRWOVjlhjK/l5q5aKrNzQ2Hfu0NcHakOGqBIxyPoLUdhJBjAdt
pF9MmjA7dwU9uSkMtPfsxAhuRRKITEAxhnNWoyp7zYTWDHAZeLQ5DW0gwaZziGoo2elXk30d4uex
udQ83UP0AC7sIUIHmHQqfSyEyGoebeGZgAWqwPSsoFUmwF+WDaevVwVmUTzYoc3YPTwHk96TRvYf
4L4twhyb6NQDEG9Og3fWp8UdE6lxy1xqBVg2dQNyqTyQM3N5TslAnQdMTB8bhyVrTnuaqdrRc1m6
rhNGlLF3jAXHFAK2p4ZGiGMl89eyVHPNaWIDGcfIojT0q97rWOP5pC+mcLHOHGbOmGlL/bDOH+0a
TA+2DKX6ebJiL6mkyf2ca/oYbD2yKmTPzwEelysnYvmxMAYw+WuC90+QFboMaCG5yjjHUyO45rnU
tvm2dHTxALpt9DG17KqUDgvlYOcUXZoCIxIOpIPNbq6bqqSPNR1KT7TwHmDS0I9FXaZcVxPMWgvj
ewFDs0iIwgFCBUbnx+HqmBuQU1miYkPzpuY0fZIMWpMeSHhogUGr140JG1fd2sF1AvR0D3McM011
k1Z4Hpo6sxzU/BFieDYwVxLzNnOUOFQYtmWev4XDVN7h2qPSBe2YO82C6RhMNvfe7FWB3BIgbJnr
rOGmrecaq5vaU3UbYTIHhuO+LXPfBGvS3yu0NRbtViDh2nQLm/FU6e8IkO15TKRYQBZl+fKOZwWg
02B3UJru+o4rYJC6A5jZHeUmkyord3zhTJpYngoDb5xUH+P6vx5+azqzOESZSEAq/wJo5Nkl2LML
GTuN/obG3nRF654w1mVIg0Ck1C/UYD8TEFtk3pYV/Mnd38PioDP99qk/p02nAkTMMY8L5L5p8xvS
D+38DmxSc/rb4ffFQsxjCw48V5lM8MnO8S818AFSIg46b4Kn6NMlYtzpo4NzxwCx96ZtAE/dzsH6
FrqN1+GmvKR1Z/TPNPsadyZYvrA6jN/TdfvS7ucBrJrTsfnT6b7JR9II59gM03o17lEZQGWU7gCA
39qGnFDL9ujvR4h/e2gabwXHEEzVuK8OwuvQmLycY/bR1glY0wPE+bmv99Pvea87GSMbiA30+h6a
fiKur7W+Jd3Sdg3thtyhn0/On+V6u57Wjfb9PEzuZa2XRNs3I1DuvTgwd4Q4uycCxMlutkHKvKoX
hQb6bYp23D1JWBNM5it6npdGIWsemHoMttPQm2fHBpiGryFD0BT5CjIEq6F9BUiRzeGCwpWFUVnt
I8MTVqYKUMN6QPGjsL9iqRnZI8AS7FA9tGcd+0hCaNDr6HzSEIkXstSTLjAmJSbUZgBNK3FDMn0y
KE4w2d2R3VdWrzAbFN8p/5FVCZMmAJHBs+OaZQGZFOcwBBQvTVVcjUsY5Rl0w/o24RLFKMucOJ/H
usAJLP6mFQCteoHl4nRqBDQtb7osjlUPYAlmiGOtUrGhAmsRhpE2yRou920FpJHZCTtlVYCGptZo
R5PG3evl+HO4kWu4E5t6t3E+VsFDxwEDuI8BcnMAvzkeCtlMH2qzbeeJwarq7izirIxjLN2ighzd
nSuypwIswID9FJpe3h8A2kfvvCt9RDHj1s4ok7Y8P4UO3QnkSDrIwuxNh48fS6fPniPjciMSD4AP
DJnHaEXDStHnKgbD7FvveF0E3PPAu1LnBTUSgoWqIudi1RDP2kYCyZQxUlHqinbDSNVxzx964O4A
c+1U2hAcLhYl4wRHNcC4payq1Sx/KgMVTDBnjbJyaw6tHFS+zPeFNsZeyurVZNH8HnFHAvQAzwji
1nBxyiaePnMssqgNC1BXr9qMUaJ9y7Th6KFH6c/DqZ2x2kymqokf0wC3YYDICmPQ8nCt9JsMqIzh
IoBNEDkHIBgCaI+REDEFSJFhiwUA97oRo7oAk2EftVM3d474RMfNDL+F9pIcS/SRIsfLtOck2YNN
3J9GEoUWieNb5ZlohTk1bi4NAaiPYMRhOWVSOrkfW3BZ92xhbF/TmE6f60uzCMJOE9qwUsfK8DhG
d/8IiyvAwjLPBnIeNdpn/WHBVw0W0LVIg0ySZEsTPc4zd7AyzlqDWB4Z02aAVgsMM99pmCYz/SQL
rs7pNLONjNZWWKJuwE2F67PSwBQhBo8gjIxMRte2DWng0gayJofTexY/kmoca4Q41SXG45HBidQB
6G1kTCwANBcfBOgT11aBcFo20Yr3x9GUXJppRs4Flru+Mw2Dwkamz+RwCxZWmyZ3cJ/608woGfQ+
H6udqRVX6vzEIAwXbDZ9XDvYnE4+yQhQMql+Jqp86Fl4rO106rsHAMfA6SOmbx5wK0syic+ymT5d
xCCPTnOiGYyVYufcp65uAF3LkdTYNsk8AoPNs1HV0PIct5OwUw9bMQ5AWyTjlFTQVMezHbAgwFEl
TZ9g/lAWDtZNAeB5GLYGEhTartuQZs5SPm5qKTVwTwWTqwCpiD3C5TpPZQ/Ff5uIkVuJGDeYb7Ll
W6/oY+qR/XOM6NZlPgaUCsjmR1gA9LIg5lrnYW9lU50T5s/if53GU3JJT6rh2tV9XK88EwuKevTl
rPcaSNXKE84x8SDx/EzDLtCngr56S4fJBB6fClfys0VYWLe4Rj7rGT51M4ZL0Pb2wXfGvGSM2Kam
AQzseJrEFT3CbxmaDubgG9quTJ2VDlygI2nfDJ4m7uKFwfOhTWjMXvHP827hmJdj7KdxzQsmBBXr
AaHGv53jf8vmNwIYetJPHv6V9NHx+9K17ZcFMPFY9049kk6SdPAjALpv3vJvAzx9Ympf2gtIOrNA
bDAgKlzEsD374xxTwQ59rlyYMd9yv3WxDphJzjYAOPvebd+QXth1U4AgAcqTs0dpDwQGQLTG/NSP
C/Ytm16Xntd5Y9revHmtv6boi/unHk1/fu6fnpLw8eq+F6evrb4Opu/qOIf34IOjd6T/eepPw537
LVvemHbDqM4B6D4wdmV6YectqR9A5naW+/jXQ+9Ofz343nCV9xGP9ybi+V7YfVO6pBlNzmI7AXi/
g7jEPz7zN+Eaf1n3relr2E/m7u+G3pc+Bijdxf4C6Bd23cyYsEoQcwxj4UJeLphLxo0M72v6Xxrn
sd/ddJXfR+zj2878bbjtdf1/3/ZvBihSPYl+0qv4wq5b0peQkOF9e3Dm8fRTh3+da34qi/y0Qft5
eoOlB5MLA9ps9hU0vCqrxKfxT1AWLiIZF0BZEze6jozGOuPh/ABDvgx6thKEBlEeTF7F4bhiNmnf
dgw54Ih4ObNJrSLRyI9lnOpXAIg+rAqawnhEUoTsGd9tMeUe4FQfqynAFG5bgYXGv5HjKJvRAbVb
J0M2MwEw5NaQQDAHU7TIBDxx5miqIGZbRattkcD3YGyYhNsBX0swKbMGKmPtWmozqZWMSikpj0Mq
JhM3oIgrWbXOKdemrIl8U/0mAqc72VdXHka+BfBiGa8mrwtZh0V1wlxv0VeN3VtICumO6gfV0IDR
5ddF7dgZjKBzJ0YGNqPeWqesls0gVuIgzivQ5Nhm2c6iLdWBERcARvabbRG0KAJNhGALxqy9hYD4
GcARYMPjDhD31eaEzj/EU9KmgQFcjGNpGP20LvXYdDnbb/YJ59O4OannAHjeh+lZrCNo1Hgpgntr
AJIlQHMfUimCVl3XBtrLmNmv6Jiy4R6iW5ZgJ3W5VxlLMhgygsbCCS4EWpHKLyijE1aN3VPRH4C0
aGA+bY9MUGUseC8cwcpRcO26WpdoV9SDleUDZC8DyuYAHGjawDoR/8P95BSx+KiHQW1kgSJrvAyw
miExZRaXc2PDDFmXBKAzVhVxnrM6CccbsaySoNw+4W9Z0yUMxtlRXOXFBD9DSTlBk71WVweoMoaP
Kz9NLKntrfA8dGOkXVuaLd7QBKhk3NZxDa7WoZwiQWiJeFTh6hTXUrMGLd9rpL1txJbWsers5lm6
hJJOfc21dITYzlmkWQwPWMAFV0cSjg7FFVwLTbMufPAZjjGeeF419Pb3EudUz01x5+ivyKTUlYqx
gmltZqzLBs8g/B0LNdpQB3CuDWHQx9yXsYjwbwWQ0YyxWjYzc7I+GM3m2Wp6/OFBxgestrV4Oa5x
ki7smo0phSWtUDawoQlwQzWSBmMDz6pFZyC+iwFYcYL2mxnvy7q1uUeGRzQj/9K5Sgk9AHFq2YIe
YQux/Gr98WzBuM9xPBdWTegOLsFeNuF5XGkl09p5BRduAiwvAXBMrGkn666b780Sd6XkyirJTzg4
WW0j0cIYrjcLX4YU7cgeJGLAfWkzrOTgXDVNcn4XWbpk2wwZqCOmCGDbA+M2NUpb7EsZaEcBl1TX
Y01fxj3snIkMLiJadnWRyUp7GWetG1ngirAYu2KSxg20hM/mYPTqyYptxS274nPFZ0078XzwDMyS
MRvLHe4RNyvHuTEmmvZ2M6eySCGZoeJiiVWDjKwsWwXh5eXBybR4kJgt4grrcd+vOu8WGbeCNwFd
dStJG/TXivMqWcgrLhABsYJJs2Gr9HvEB17ok/o8GaLP5DTK9FyGm/P1/a+gFvI+2KVNsECU3ANI
fcvmf5veMfLhYFsEWx08J+MY285KWwCq3zr5ZxE/9kxushJIfcXAK9O/6Xs5z3KWt9C6vW/09vSP
Ix8KoChbJ3t3acuuAEZvO/s36eOTZKrjoZLVyUtW3YvNAVj+BDfs/9j7o4CUWwLs/Mft/y7AwEbA
gmyTTNMTuEB///Rfpn38lkX7XGyGDNjOtw+9K/1wy3esgZZ2+uQl3c9NLwKYfFnfywLUCdJO446V
vfs2wOdXDHzJWhNkxQRb3bCQJhe8o/qhp4DOV/a8MOZP9/GaO0ly8vuH5k4EgPU9+8Xzfnn/qwLk
Hpk7mXbj5t0EM/bN3LMDM0fTB8fvTN+z7evSWzZ+eQZXAFHf2wkYfF7nDelNVBLSRSqo89pKEOa9
9OfrcXF/9YYvXWu3AL6f69lAP5eb49sEjpfCsH3n1q8N97rX90/DHwx2Uqb3NX0vTT1878cP/XKM
I1k6aZhuvGVfveG19MFlcTgzbXc1QfTo3fpc3LDPwTGqsl/zuDArTPCVmXGMNsOYGUjDsAQ7Nt9/
KZMVLB4uv5bRI6z4ZtNC8wATDRMVoIUlLatXXIEKvsJCLDHBhguFCdbYM92l1eZOpEwwMrhX6ytT
HI6V5+SZNNu9NS11EFRPGacc92KdadxnU7pC9S7iloRZWtWlxuPVu+sqjAYTPpIoAky/tMgE1YHr
a5lzOajMXnTSisoXsHbCTB8vkyLm22HY5Im4ltrYYBrdcQ2xOUdSHYCupsbePIK2PJRGzlQWXEkz
kbL7HCzgamtvqowex7iOAgDJcKyHnXSyxI0VGmaNBhwzyOgzAv3SKm5a3QRTiNsuzQMYZY44djMg
sFmjQ6zdHJ9p+Fdx9S5DFTfj4jW7cp62WWvW0j1yY65RJVsEI4LEadq2gEZXR2d7asQiTOF6abKe
LkwBVwLD0BIAUkatr2cTcUG4hTiOYEvXpJmnKlAsG/PIuQVOWXxXdtTLMBR8PhiI+TkSCGapDdrZ
inuV66AdSrfMYFTqjfezlJNF6A2ED45Kds9sZyGjbl4lXTIoN9ZOI+fDZ2zSisDAmCaPCZCSAVEk
eFmAGaDTCiZmyupiDhI5HuR6ga6MqNp5MsoAGkHZLGxEk+CfQH3j89q4dsMGajAwshAtTPgrsh8+
nqwjxDzGLYa4jeMvmCGMOSeKdso4KSeBAZe+d8Vbz5jKQfOWylP3DqBFWxoplccgQlR6Jk1Mce+m
WNwAllscD1RICKZYRsRArmBpzXyTieRc3Oc5noEDp89Rd5b7xLPXyAKjuXdL3PjWVjKwdZd5Dzn/
CuNXy1uvW4126PIVbJPuGa91qy/qovYeBKijjfx0AfSiwp+AmQ5dWgWIySrSjwIS495qViGwJ7gv
NWq+NrfRl7rrlAIx9MHnRB0nxoBag3UA6m6+24h00CJyJ/X0cSdjdLXR+0xfq1clYGehY1/K2Hqu
uM8yhjxP8y6MZI4YswLbCuBlAY0/Bl9qMQQEMLzMAqoNSRx1HWXt6ztdCAK+YdPrmcOWAdSrLR1p
2u5Fx7CFOaslqoEQPO9ih/YvCnyd0Vn0rLIAsQ9NkNrRQVtMLOCG2MurJkOp48a/GjGXxzjVLOBL
eR43wVIVltAsUhcc9SYkID+jBMgi8Wih+Qvb6wDzXtQbXkIyxIrJEs5HAKklalS3XEpWvW3kUPO4
S+tIFqkArlaI7YvFo+dBTHiFY5k0oZDiKqBweZx5R9YYaZPV4ak0f9RQjIIJJGtW6RILdAvWVgHB
9YDWiJFWsy7GjNInPKN8vkwsXx3MpXF5uZ7rs8U0fXLrZvyVQOAlPc8JIPTOkY+kawAaG2B4/+rc
u4JJ+8+7vieAw38//nssoNCNxO32vdu+Mf3gjm9NP3P0f0a243o3ahh6xtoWMiLfvOHfpHeOfiRY
H62HbMxbAAvHiUO9feK+MOQNPCuXtu4Kl+/dkw9GLFgOJeHWFUK7jh/jvg4DbB4E2Mj6GWd3Fe7d
TlyQv3HyT4LFu5K/BRdf0vtiXHiUW/T+fw62SIxiHvvA6J08A83pW4nz6+a85SYQ0fXpz6W4jv/L
kV+NfnwdQLncPjB2R/qLc+9I0yuzaUfT5gBHEzVCAtY8K4QEzx1Pv861yDD+4M5vi+tzk60URGc3
at7umHggvZUYPtvxfTu+iWvfG4BPCZQZWPFX9rwo9pOF+/VTfxz3oJnPv3/7N4VMiYAt4hFd9BSb
QFKg+YqeF8Q7juDfOfV/4h62YVe/duPr07/pf1l8Jtmh+/fNG78swJxsrDImfwwjJ4A/iwfimza9
IQDk87puTI/h5vVcgkfZxs2NG3ApnwpAek37pSRk3B1ANsoiPgu2ECqqOekoIwKDZnagS89lmIOF
7u0hHqyRrqAppQJ/HaBEJslYrvoqEy2rwZqrPoCXweOCuCU+r5LdGmE8AhYYApMMasbTzc3AEmDc
OzBSZO65Qo1MS2MKpP4xuFaiWGVQ1yxQDniRndNgzwGkmji/xrQBw1bnKp/jGVzciau1jqLwsxbm
piZnoyt0TabGgwlsnvYpHBsQjwlysX8nBA8ABWmJVQBnxFnJfjHfCVTCRWIhd9iWhUZrYTIxzhEj
5UQdhj4zSUpgVGVAALj1Gj0e7HquvdXEAsiZUTPIqAaAlwkw2sE8nIPvp2H6wh0JE+KMruuKtR+u
GsSZDczu3ZCaYBGnw0UJa9DfH3GFTUzkiwtPZlamRYBK0ggTVhNs5yLHW4FlmTOrDWMyz/WOLBH4
jVtoHgM6BXiBd8HQAyhVLTDFlNWgvR+xJfSZRtZYxxXHA+fXBT3PtY8QqNxH9Ycl7m+V2LWcaIIB
IkVTaY4wbAJD3e+CNM5XLzjgFFVW1Lqkdckvqe5LJyupEswgP94p3an2g5nCYXTNVo4AWAwclMhi
xHaaeOBxGG/hqfcYOVhXQ9nMgxe1OI0P5Frsatm/BmIeGmAHGxUnFhTqRDc2FJA0z3HmpaMdn37I
tdt/si+WtjNYoEY/1ut2LoCmLGc9fS0IEPws4RqcGB0PfTGlORsxpgInIBGMNu8LbEyVj0QBDHs0
gv7h2Qjejz9bcEmvomEXMkICMGNZAEvqADZ4DQA7GWDjXZv4ni5IC7EvwRyCJxir6ph5D3OYQEvE
5JngQYxhqCfzXAiu6AdDElq4Zz5nkeDBOYKJdxREALRA00EhuGQfs57tW/pfd/QKsZVLAroFzs/3
HBM8EYBpPjNerRD7teIIBw9wXCHmsxWpIDX2jIUQ6Mhrr+oC5TPd+qu1gqWO+FTAHDpui/SBGZx1
84PEfw3RBgzxjOEAPsg58z4Yfsc+z+Us84KLCGMOZVIF8C7sgik0EcAQBv7WJe+Qn+O10K1SFKmX
Ca9jAULgcMx1uucaYUsX2L8iDRxGUrrauY6+kuX23nLPa4AukyNUCPB0UYJLM690CADRCTHK7Roz
Ktjznk3pxeA50tMBKAxUyWkEWN5PZU38XBdsTKjMy3UDGfAtkeQQ7tUBBIE5fwBIjrcC67wKe2y1
iDqSYtS6WwJMqmvnfYrEKzvOcWgnwLjH6/LvZ4Fh+tRNyP03izE1rktXmfpvB+ePpzfADjVyT/7g
zF+mh2ae4B5W0lE01v5p5IPp2ze/OWKzHixiri48TxsLdZkog/d1i84y9v9w/u3hEh3GfVfKqAho
BCJTMG4CGQ26oTTjxFUdpO6yzFzJ7hmPdbY2nDYACGT7DML//TN/lf4MVswEkMcJ7hfoGTemi1M3
4YVu4U/dH8+8h60ydu2vh98TMWgv631euCR3NG1ZY7j85i2d1+IW/uq43jIb90muWXZRlk0AW2br
CqYjRKrY/nroPen9AD9B7YcBWyWgEwTJypVuc9mu/wXQ8no7mZONPxPQubnIf07HtWuA034W4ArS
BF2X4qZ2C/AHUAxNzoIJNeZPcK072U2m8V2jHwV0nYj9Ty8S01tstkWGTVbXTftwPf3+n3f/+2in
rGkZdnBd++UBSMssWZM9TuL6/eXjvx99uQVw5/grhaQ/23v0ufyeqY75oVaeIia9fJGLA9th1WDb
dKOOn0YLazCU9uva0Jwxts1VfnAoTPrEhlUYmMbILcHUOFlX0byKjERdVeGWItgYfTpjohZlpGAf
VgFk1SFKJzmBW8Bc/OXqBPBlXJIsWZ0ASoMTlFKp8GzGGo9QBP5WSTwAiEKjyyAE0+dspTvByZur
E2CswFbFRA/DKHvnKq51ihJhnFeGwBW7ulFLBH+7fz3MYZ3SBTHaMAiAuSYm0WVisZq5xnmV5p0Y
Y1AVq1pOvkz7Zydh8XQLurIWDJgo4uRO+xZ4b56VeD2TT0t7d2jxrWhkcefIrlRxpTQxOcvS9Biv
BfO3jLFfgvEzVgyOkxUiP/BgjWOnQ9JlALdQ4zIVGPj+Vmro1gtWMBpjAODpGcokTSHNYb1QKLd6
AoxXAWr1AMkmQEKjwqlQ5IqXmkUambvWSzBWDxaiEde14MG+NPawxvUZN4dpjnsUSvoC2vCImoGp
7pJG1Z7TeOLuUYHchAeAxpzadAJWMoIbYK7svcjuBTgG+2Y1BgCA+8fYZNBVNJq457ybPshRFklJ
G42czn7aZYkw9G7DjbnimHNhIhji42CvBJphswx6J/Ozrxv7p+uVTF3YLPtBV7TB68tDuGjIYmw3
1g1jN00cVaPaIhpg2pCTN02MEHhYlgtwHFLc2lRBFydlXxcJVsy0bQL2BcFXRCxGQyNOMdZPYf0r
qcNMLoB5jj8lkcDyWQCgkPk2UYFjMEqZpOgLO5zjLeJWFmw1sp+jsAZjucI1tMBSxnkAHnMI6XqU
VlyiLijMXOaLxIXwHV6uwKpNuJLRjW5JMmO1YMXM/jQGbVn0HBm1GAdW+lX6tWIcK7IdPgGez/lA
MGs7BYhLChsX2XEOKT0BGjwlXZrMEoglBMdU4DjutW2xbbmih6DHeMpZWGzjIg29MDbTNYh9umxm
HPc9XKDcW8GmYRr2fWBaDrFASMM8369r7Yp5QmZH1tAFV+himiAUfR/ca8xoy/RFzC3Mc02Oq8jQ
h9UggSZi0ARsSvK4IOH66/xRGNiAcrNJBWYeL1Kg81FXce86r67gnnVfP7ONKzCcEB+5nqvsbZGk
ECusjMtjHrNoyPwpEjBGYOa8qxknhit11USMWIAWANJwAAEa760wT0Smr+wu8RHNu1jYdNB7Vi+J
BRV3zWfIc9v+SF569jN00Qfxk12bAgeNrV0i+7IbcKTKwI3tV6XnwrSEDeDfxoZ+YoDxXAAyfG99
rJq3zL5SXPfdox9LXwkoNFbqidmDoSn3MMK1E0iQCLSC4eafQEP3qHOS7ymuL2P3/x79jYjJs026
PGX0dP2ZHVkmXdxL0oAxZbpbBYQCh5cSF2YblWr5XAE6+ycnFkylh2f2p0MA3r86927A4+VxjTd2
XBkxf263dT03PTD9WLx2U3BYNkomy/bYXy7uy2so9xOA2p/NeE4ykM3DMzL3i3/5nq0GW5qzSFkA
xeomb3pwBpp6w23u5u8riWEUSHpAz2kih164buLsQi9Q2+O8zlj2vpfbONfqs94EKNelXV5f2Qb1
90qG0Rbq0t1NAcRoR3EeXwvs47qLOE4Z3PeNfhz3+gNx/oMwk1F1Ix7UZ8eGDbQxGrtCqBF3Rm3j
XlwYgA2N3+RZDCogqJuC3FxcJO2Ggce4hpo6XQLIMSZMwVm9N0vesK7NYew1rk6Y0SkAGgPpl3TX
TZIV6SpaF0wYq2Ly88kKw4PRIEBcW7yoi4JJaRx31gpU5xyrVmMQQEFh9OsIvF41tgRaZdXYKK5p
Btagwkp5eRUnJCSYBswAcVJFwx3SSMaorNYKLFctYpB0U3TxkNFm9NHqnPSUbgFgzSGToEzG1Awx
TVyvzFZdaFiZ1EETdB0CMGZpJ0oBBIgD4MiKbMFl1MV7TYjCOvDmDXQGpPbQnC2IfVZ4AOgMbArX
CtvZ0kBCxQCPAEXn5zmX4GADwdhmYEaVCdo7hhHQUswQpzaFW8/kDefhFjIDW9s60j0PjeMJglVS
CoJ+sMA9ZoyJBd0+QQkGqApgNvZnDFdtJfxDxPs5qUfBVP+znJlyMZQ0QyA2aveG6D2MnUr7CuFy
bNmhGAcBxiMvNmIpK4CJtURLHzjGlxm2enRC3Jcz1IixakPOITAHr5fRC9RAm70b+2nrMU66DhcI
6J9bgr1T6DiSKeQZiI0SNHkAAIrjcB5DJiMjUyhQFxks4V42zk2AJLMrayP7Ngsb5OM7r6YY5/Cc
wbzw3zhuKhNwlkyuABDNyJYA9AUjuleNmZONLk1CA99vhuEJ++v4oUlq/AlOBJS6bn1/nv26BEG6
S+m3ee6hiQQK+ucs2FUSaHI8hk0RSFpPuYljyUV5P2dgWlrIxA72mWPMso86iyaz+EVL8nnv28yu
LBYa9RzXzM5VXM/TJH/MM67kaj2HOpPz9MtcSPowtgNgAbzRSVw1QYkxbib0MokoLigqnWY6yEox
SlhI1XwWGHctxoy6n6wqP4uEKTSSoS6rb6fWWBDOEQPqtVXG0a40HELgq6wNz0srOpWOIxNElIhp
BDBWNxILq/QQYLCdMnbNGONGYnDDeMsUMzadTO1jF5NKClmy0LACr2Eel/GMRnWFSjjOS7S7zWQA
BxdMaDF6goGtsUhzfBkC4HhdABi3d1BXlbizRZ6ThWNTLETpG1iu0JUjbi7ArIldPoBFVqqJJLEV
Y0mmLcCrNzKYyXzfnA5XKN+lGLDyIsvEzNaZIFEkMPgAKSVkBmpIwzBOOzv0UjBmp7N7uL6PDO0+
yvwRP+cxq9th6nAN144DPjlX4xa8Esxfy1T0qMO9ujjDcwfbV687Fq27SJZwDuPfEvWuYyH8Rb55
LRpw46LMypShKTdjsnSZ3kdgf8jbBOw4v8myTTPG3nriDxHYPQBzcyUB8zvS9++4MZ0gW/Lnj/2v
yGJtYt6W9RKEWYHh+SQPCH4aImkP7wvkhuPS17p2zYS9AXCpa3iKZJ1CdChaEENl7ffntvMFJ/bF
vyNRQLmSj+PulGGSrTw0fyydWDidfn7P/4N0CfHhMZsxH2hXi21Xy9bUW+2O6ywzgAWqT+u34lr9
WnltvnbxbBtKwFMKN5fXXF5/eT7P7TdkMQe5V/+vrnEYecGdx1mI5DzlVJaIcXxZzPPlsWZhQcut
jHkLsWfuk8B7/eb9KUGpUi2/ffrP0z4Ae7NC3WzuL3gzzMafkrEchgWWrXQz6/WC4fO5vXmf5dFC
tiQ4Jt2m/CzCyi00EPcDEm8YPpbqR9B86xpADBMq0jJhMiCcLCQwiGdTj8y/rYFpSfGwk07grILC
lWqgrZO88TlMok0wRlXrbk6T4WncHTF3xpTE0Hb1zDFF3IRuRbZaA0Z+754t6KttTB1KgxSIX9Bl
YrqTd6u1DF1c6vIzrs/s15jxgBjE4RmnpnyKJ6HWWbG6E5tk94lTeHggAC6Wo5IB0yAsWwtWlxXG
ok0wZJwerkiL3Ruj5So9mCgZTSxGsyLFIB+NtEMwsm0FM+7r5MlJTDjQx2a8iskUNd3BxLgpaWGy
hsHqxhrNYDyUz+jF4HKWaI/usQr9FbFpGlvOFfaBQedjYCLEMobIexmOTLGOQNnz8j9dn7oiKxhb
r9P210W8hka8HJ/F42o8He0XJ2TdM4kwQBnX1oir0yLfxlVb/68RMKnYsIHxupk0DOHa4js5Eq44
Bt8V0JkQ0YBbTm07XbMyMe6nWzZLyJkEIwNGcodMFoDPikeN9F07mYRe85QB5sbVFaBFF6dMm+yS
98b+iQlFgGqGdCQyZAYimBnaEQDPmsQx+fhRvh/thK6ZwZw18hyYTPQsQk5QEeTwQSh4+tc4xdCn
8xojViovSEISwr6ONTsMF32orpkHkog8O2dCQ97HWNUG2hmhSx6Hthh2H6tbmqhb3/vWbH/G88GY
4ZzGhzXKYPumiy4+b5Hd4T3BnOCwEyYpNuPbYIQ7AQst3hPGFdon6eyEgrSLaXAakdGxCZrdG+EE
9bhTK7LwgM0Fnm2fhQbY3DnoKUdZg+OXez1DKTfHajP1fV06jJLAoJafCUM1npFaN7Gbw6fCFaqb
fBGgVh2ARQZYC1BcQHgfmtrJjqUKTZo3ycBxluP9jOUdI0ZtlZrLrYQZTABsJk8T79q/JZKsKmS/
Gobhg29IRcsGwkPIxl868lAw1a1k3coqa6RaCMdoIZmrpxN23drGtFdmxXYttfUyZwB4eB7MyhaA
OeaXXdSRRWzt2uPNuMEv5bmDKgsmLB46h5C/eQZF5MYqGq6ANIqxckrIqN0ZWzwPedGamTv+NlMc
lrq+E/CpSxavRQX5pagiYZIOCy4GP4tlTkSyA3c29W9oTEMHkFYZlpXj2nGn+uRY7zXahFyKx15G
M9BSYY0bmZ/Jfl5SwNjyX2yC0eXBog5sL0lwOhpsqzRzMN7Pnk3LpEENmY+nsDnP3E4fBxkx3Zga
eBMZZjHoul/VPtvdtC1itWTUNPYXbp7PWDLjxN41/NH0npGPhXfhqra96cd2fhcJBC9Nv4cbN4OU
SmS/auDNlvwEyRkPTT0erJAAxnYLKjtIxviqgVcH0yOYFGBl6aangsm8zP0cbwWzZfWKNxLM/1ra
/76x24kFRNKL9t3SfjVZpTx7xXYA17VZrK8jKcQWGpf2FQOvSn8//P4AOMa9eR2+Xs9ult+PhQH9
ar8chdl758iH4/VfkZRxG+yjrtj1sXfrr1ZLaWUN22jliQ5csoo9vx13ruyioG5n8xYY1+sCXK8/
v/fzIBmpJrsIQHfBuL2IBJT3EEO3EfewMYLlJqh8CFmSkb5xmMuekDkxweZdgG1Fir0rZkwr2WK8
s6XRyvuiq1xA+8mu4XN89z6rw5FcqDVxEtE08mALrgAurbBBruPRAWGC7w63kaBkhRgO2bIgu3W/
hbvC+B7doBgWGTd6oAkglelW9gwSxYzFZh4kgI7CtMaxcJ5G2L0ljZsBwOyjkLBWWHmJq6+8Kn3l
q1+WXvG8m9ON11weGXLrt8j+jPNf3C72wOeyB0qnwfljzgHuH3j40fShO+5Kdz+8j5JrBLEba2dc
aJDPTHIaU92rSp/IlhlrpySOiQpA/CkyMyeJw2qSWfYhKRYhstpVQJ9GQn29gH+gNZMJdAM3sWgx
BsvxLmPW2Uq8oEA7BI8BRiETw/kFFO5PO9qszSlw5Ble5FlqcqHB532wswMtLNZg3VthqjrIyL6c
0lVj87gn2LcTF7+l30ZggUZZofU04hY0lrQNZgiAMVnFQFKTtWZWraQ39YxneNHcYnWYhtRN5uXM
bGMaoQ3t1DTuJAPdMnYTY6OwUWTLWrGgtg1BbZg3nveqLDxzxdK07CdA1XmB405NoG0nJmU+6CCz
vREtxQWO38j327q7AcW1SPxRQmYaNrtK/O8isbAzI8T6MuW6yDD+T5HtyAQePIlxRWhUaR1jaKeG
OC6gffeNVHc4nhaJc60zSzj6nXmFBe1Gysq1Ah5nAL8hfAzSs3KMgbMVspHrYJiNb3MLV6oxa7ik
DVGIv+P+sDuMavwN4xYYVBDqeDFjHDdtxHfj3pfZdF9rvvrTsJnFKL+rgL5KTycLYoBZL4zuslqU
jK0O5l8Zw80wc8YAFguMho0ku6ifQ98ZM1nlbxnCJipIBJO+kYoAXENtDBZWbwvnjBjJGJNf+Pk0
WFz6QiOuu884rDKj0b5WqFZbVSYf+F6MJbwKxqt9HOD0mr6XhKzFH5x5ewTY7wAM/OjO70w7YZ3u
n3w0TaGUUF+IFWdlTMWpVpEU2YVMxTelnzv6W+l2ZEh03Zotqbixmmd6CAzyF9gINH7v9F+kn9r9
H9NP7/5PvP7LSGqQ9dGWCQS/gqzOV9OWPzj9V+k+ylO9su+Fn9RFJ1D41wALJXg0dtCfZ9pkx9TJ
ewJQ9wCg7hbi2dy+ftNXxGuzc03qcH75jVN/8hTZkuj/AsyZ/OGxpukD++vF3c+JBAKBryBJsP1M
pcW8f/umD6a7Jh7k3t0WQPhbt7yJmMKtuH1PhmzI88kovglplF858QexuCxd7iaePDS9P2RNZO7c
vm3rm8KtvItM2itw3Zab/TsCc/se3OrqzzmGvgzpElm9fTNPxm4mhrySbNd/JPP1z8794xp4zEjn
C/98/HOWrmqCg0rxjStkjklcNLSzes1ulrRxdwRi6y5dVmZBmQIYNGaxWCEaPBzsmzczE1URcyMz
ZwB4xL8b20ILDJo3wHsVl83KNA8fK+A5VqW1UVy6XYga2lW62MyE5Xuve8kL0vd929el59yQB9Yz
bSWYM+vSyUgWS5fYxe1iD3wmPWAsXDk5yII+E5euOPALn3tz/Dx+4EnKfH2MWrCI4AICppA1cey2
Ina9iKGdAKzovnQRI5s6hSTGLG7ceZJTGmCOFJuepN6uYFCAMmEMKC58y5Y1UdVhQU07Nfc4toz4
LGECC7jyTFapA9ydQ4rG568BV6VMzwwZ0bpjF1VdB4BEkK6gglhHmQ0Z7BoM8wptw6PLIorklsoG
7D1MFmsk4+3weEccYIOxrzyNy7gzVwAhodIPs9tgkgmlyqoYzCa48Z5WEkp4VudxiTbXtaZNm4kH
JIBjkQBk4w1XAGZ9dZMRYrBSO0vogdnGRPItNcB2W40BdzMLtAWCyEZhkRr5XYUBM1nYGNy+tj6k
RjakrTv74xrqCMO4ajdSOngPjEfsrN8cLKdAtiZQ1q1MjG7r5lcGiDOGpgOpHjPqhxEvGT7dlxYn
EN7FEFstZBYjMI47tTuoWc8Jgwob3oBgsQB9BpdzJ5PaPF6FsYNjyLXA+htGiddA8FTtIyGLbHWz
V42BDPkRxH1lqOvoh4YuwBbZpQpAwy8Haxh4KeJxABCCQ8vrKb4cblmzoWU/+RMpoiWTYGAolxCC
XkS0b2mcMYH4b8nyGSJTMRyiXcY5L6aXKRWX0MOrp1JEHVqTpWRKgD3drLh3Pa91YxsUkFb2RSjT
A+CVNYrEjc85T/SZPIqxr67PswtUWYFB+SGyUnWRlayWz6ngwFi3UeOBi4BCGTnFb7UJ9xNsrwzH
q3tfEkbbhAkzSQ1i/+1TWbbEpY6bBtrAdse5x74bQHGw/1j6L2TJ3oWchy47j9FPwP3vAt5mcMm2
wOq4GYf9CK7Zn8Y1+O1bvib95K7vRXbkIECPWDueRYGE5v93EBz+B1guDaTnUnR4/RzjeQWsZlmq
Z/a5AnVem2ziPw5/IBhDdeLM+rxwM4nj7WjB3T3xEC1YIvv2f0e5sJd0PSf6/cq2nLXqJri1rwXZ
5SaLKYg1Fk05kJs5j0LNZZKCWaDesz8gEUSx4dJu68YtN+MM5/BwyYDKbL6c4xgX90bYz/WbWa+P
Tj+ZvqTvxWvgqoNEFmPzzFQ1mcVEih7i374UIO0mG1mCyDYTnbg3bx98V7D0St/IyJnJ7E+5Pc51
fnDszviux3QTZJayNE/rxGfJGxQoaMStwq1HcHcVtiyy2oxrcnijrB98IxNG5PMp3IocSVXV+ijp
RIJD5uDyhMDoneN/EdBZBOo6QRg4HtpnujyVE4Hl01vd7OqQbLIWtL2yzMUiQutN6SWveHn6D//p
e9NmCtB/OpvCryE8bJyUAqEXQd2n020X95GRjmD/HHf36YqqXnnZpemSHVvTnXd9LO17nLIz2ORu
3HltSHdYHWTGepyhaUYJHHTarKiygEtPV3ov7NLYJGySyTEwNLp2ZwASY5aGA+Bs3jDAMQSAVi0Q
HLDgkk3h+zMwPFPGj1qaT3cn4HAcdmqI+K85jrWM+CkiP2maY+eKIAJNouVsF0BkHmZ9iefMOLN6
5DrmWZCd1Q/Ms2yWcVsHyQdN6DfiHm3S5cw+Bs636bLXPa8LCT08M2ErHLvdLAFfm7WO4aus4ja0
cgYLtR5d8VQVqRF7t8jiTRpqAVA7qywSSR3NSA2B+vjca+wlgxWwxfGXTGQJeRdAFdnDo0O4cglF
WGJS7QIQTxE0Homi9SRhIZPUaAwpYMaKJnOzlFKj21s5dgvArAVdzRp9QSpA6oeh6aySiKUnM8r6
cVGyqM29rP6vjnObnNNMHN4cfT9DdZwpBGmXEFmcuu2yNFI3yPWZWcdtjfrJeIlnAW4EcjfRQTXK
ftWZMOGiWJcp85wxd8bUOV+uEAayHAkMeeGr9EkFceHKFiShBGScu0oVCYHgSj/AX7etmnYwdNZb
xY+U4+6iGgjub1ykDl0LQUQxCDNjdY7IxnLv27pxlbcRljAGGObcS4BEtRtl4zzmomxiwegtT1P+
CCmU5StxiT8LGDpZOeUtZMIEddkRf34bJGNUEPK/AGenyUQVpLx/5HbsmOE6JCkBOARfj8DaXEe1
CaUmHqQ81O9P/lW4RiOGtYi/0rgfQ47kt0//n3R07lS4Yn/j5J+mF1DI3kxQddk+wXfvAezsVyNu
HQgRMAkKFOj96aO/znduChCn4PA00kJ/BWgQyFiaStDWCmhRxPcPATaDyGOUFRwENo/BDv02GaBn
a0NPqezwL5mkc+m7lN438nH64kC6AmC2FVkW+1RANgKwPYugsDFyj5K1aVyYLmEzOH/x2O+k93d8
HFYu768rVUkPXZv20/8++/fpfY23x/HNVlWLzizZmwtmb327jWO0b8wg/ZFD/53YPQTF+SdLZn/Y
j4r4ughTGubXT/4x1SvuJhN1M6XT8BByrwTlJ3AV2zaBvMDKv92sTKEszZH5E5Q1+6P08fH70+Vt
mZVznAiiBXhuJpzIEhrb+Iewt96b3bhkN8ImWp3EOMtTjCndz7bJxIhfPP47MQZlf0/QvjJx419y
b/61vksYiYxWDvCViQvXTdYEiEDzcMMKyHTJohFXBYC1KQlSRwfBBujeMSZYiQ9j4hp1qRYxZA1W
O8B1YRKBMU0ZHcL+WWuQgOXVyKwjNkUXBp9YEufq665IP/yD35s6CIL+TLaov8nPorVcLwK6z6Tr
/i/e1/gr63QW8WafQU80Yfivu+6W9MGP3End3IOpEzZo5/YtaXJ6Kh0/fgrZQbKTATVWZ9i6cSPu
wdl0Bv3EZgBaG8zOZtyRk+j6nQYAtuAaW4nYTgCXSQqCOYz2PN9pxfBu2rIpEoOsyWvWd39Hb2qn
woXVOU6eHU6b+8j6MhaPI7QDZMYnLIdkrJ6xamZpkqxEeIP1jOcQK57m+DWTNJigJgh/WJ63nBtu
JCZKg6rqiN1cUSvS5ALiEVe41lqEZvBsU7FgBJYNqW4WXF1pElZtAuZNLb2ouAZg285qTWHnaZMA
+N0M2mjD9afenRnY6krOwaot8LNIXeQmnlmlWaI8G5O68Z3OCQ0N6jspoyA7Ri3lcatZMG8wmU/N
EQekm8zFJwvNGoHqi6jhVyYOBytn/FzIltBvjQM7grXrpV5zEwBbFt9zuRCt9ewBgMIauLA0NpaY
wHYSwwY297A4BZiTYTtK/O40LGqFfrLuakiJROAwfWPsqyDNeCWAkZn34dbUU0Gf1HUI2JhHxXJm
m+JaVXB7GcCmLtz8OGBYtzBVPuqJ1WsEzJW1iJVAqcnccIJGQ1nQg1wFvUUeGUkvTQNIOC1wnn6k
IWDbep63MbVdSkwjDKYhNMuA5Qpl5FY3kKAyAvMzA2hTHghXbeOubjwjJI15Pcic1KGhF7p1Mfd/
YTcJARMalMPIDNxTN9kW3WzGgrmv7NZjMGPaKtmiXG9zOX0IUOCPEhkaY71FgsX1dUN1FQoAPwAb
U9YgPYnR/mOAhnU6lUIxkUGmTRbpQvYsQB37DVKJ4i+pXKHrrgzit/yYm8H2OaKYUAIWXf+EQLHn
LTNZ/b56eoKqUAT4HLr1ynbbn+8nQ1MTbJavEiOyarKFAku13kpnou7NMVhG22l7svQIGptcjxnu
gtjMXuWkA13KP7zj26NubbntQ5rkEYCumamyXIo1GxOnvtuZ4cG4V1MAK8tmeY8F3bup2HAXmn5W
9RBEmwX8XtpsiS416gR8oQFImxSUVv/PzRg6Y+Eaee68D7qOu8ZZMLKNIz4vsC3ruQpYPUaZ5KGo
8h2IQrsoyPd6Jq7Jc7ifr//07D/EsRw39o198kwxhF/YpyafHTvAzSSOxayvihmrAjImZhbi4Uow
uNtAeoVtmSdxjRgj4irTTCsofvbXWLUySUZQsatPRSoNfi8CoLUFhPvjlsUtxPFqTNbNBADLAhjb
scqEr/u1vasnveE7vvkzBnNlRzogjRuatT2IqJZutM+0o/2eg9Ubd6HP/LM95oVt+GyO80zfcUUZ
GkjFivMzvdbPdn8jGD6diacc+M+22APbNccCJQrMh2n/zGMjenv70hvf8NXpwx9+Xyx4WniOuim7
1tvTnatc8DCYuNBGDFgrIK4Nl6w6e7LRLqTct6+nK0qLWRvWTNQm455wz/UB0GbnWoN9ssKD43qg
G0PG3wb3NwoMDPrnvB6rDSAXDiSeu4V+Kobwt9dkOMUY9WRl3hsEGEye1p+dpCZsIwyfWoLWBB4j
g1xWz2iiET6TaZwPiRkAC5IyLu2syLFCSat6MmtlHWeQwlH2ZQ7msAnf7ZJxfuzZ3QdbCdunC9lI
3F6C99utkYvLtxPXn6Bh3kxz9u6iaoH1YMcpYbVIFq4JPssAuinK4nXBaFWW1eozucXFpkk9cpD1
qbdXLUJjDhmJtnMFuSCqO3RtJDyE+UeAGhmmMmkydYCtCpP7PLGDRMjHsDfDfna1J61MnKaKDeLm
CnfTTsWbnbKX+y6L/jh5+oFY1TeQIVuPnI3ivw3EtVlZYkUhX/pqmeoPtVHCUmizMiH1LRxhI8cm
IWWZ/je+UdqxAkNmDIrArA5x5DrrLBOjV4ebus4KImezYHrsS3zcAuPTOrj1Deo0qnfH9wDH8VwJ
GmE5OzYzjwJqdXnPnYJ9df5lfFQAbh0we5WrUSFIVCOxTjD9IPhbBoTXAHP2nQn+4Rou3Jef7Zzw
ufpeBmaVqDjwz27FI+v+FxZ3F3gJRPzMRYIG/JM94zJAeS7LB8yF4LMUid+VWftU84MgrtEsfRP6
cB2WQOrC70WcrAlfhiitm3N8LYj4VOf5bPvYY5uF6xZJhzLq/FM25Zm2vL/Pmn2Q66uu31fgqmbd
i3tvQfT3m9fAnO7V3ydeUMA3Dnhd4pmV1XwZLtRtkP6biMMrr/GVuEa/ZsOXsTDLSS722ZMHjkb2
7c0kbHw3VSP+65FfIzRiItyedYAp224fC4LXu2zzEyExZP1VwyZy0ottjmg7w1DWZcWWdknQFjQT
847X43137Ol+lb10oeAxcjaACWcuu53lPnN78dneu8/ke9XdyxNpO7EikekZF5yzI3Nz88QX5YMY
gQaIWrZHN1CUYGInU/6XEd+d1ddhHIfu2ZiP7FxX2hyX7y8SS+PkUStkIlYoAbU4OhZ6V2ZLKunx
pV/6nHTjc7La82e7yUioN/eRsXuCgjVl+zPdXEX9MYKKZicZCLp++58oYqsXdC0Bl/+S7VdIjbe8
zGUE4X46m+6DjxHs+++3vuUpu0sbKxRp6ZvP16b74mMEDH/vtq//lKe0zp6TmLEKz6btNEK1xo1Y
h/A9Ix+NcjyfzXb11VelRx/9RDp75mR68PETHKLUVcvPT393ZzDWB46cimSJMJq64PAbCvx2b92Q
9h87k4bGJ0OvMVwzLHR8X4Hjx2HgaoY+yJDrKgLY7d66MTI9j54dSSMjhEAEQFSXsZp6Oih8D0g8
eOx0Oj00GtqNujwruHN7YZ+u2LMzDfKdQyfPcR7yPQFWink7Ad5w5aUBCAdPwljR1jZjYll8zQHo
rty1LbWTkfo4Wb51xP+1sKAbHrVSBlpcAIsNm3qJHRxP506eTkMnje2juL0Z2pz/xssvAag2pZGh
c6mLa+5AoJpyKWj9yRQAqHUDIt0zQPzgduR8inyCYCf1Nk7DLJn44O9R+kl3aI0kDkG0oSEhQKjS
jrIr7ZtCGkm5Hrdw3SoPhGTHdioJ2IcxgZsEAIAeJZawnsL3LSvE9gb+E1grcjyfxpnTrMcb+mx+
ywoZs5xzVlCEe9hcdgCdieLVLnTethFjY1IDu7qIXWbFv2Tc2whgmJJfZvOHX7So+EBoXbi1V4ip
FDSvyO55HgGd8jcwZiuGnQjEYHdXI74z1tBZhkczA7hfoVoEafLEOMP4AZrrTuC2gxkUUNYTj1kP
gK+zJGAX8dEdZpPD3nZTau4yvCOwgDJ+Uw+PRNtLza3P5ln4Qn7nkwEh3y9lJ/659j3T98No60P/
DLZPR5PsmRbf/1pA7pma7vmLxPpPeWWfrP98TgRDxugZd6jOXjsxZrKAupplBJ/beX3UjTU71ng4
YyFNaCk3XbmncTHr3pUZ8z7pitb1K5litqtAuexTyQv/tv3G2ZXSMB4vV/LJOqWSMTEPx6JaQqqS
LsHOWpfX6iHrNf5ioRhgOn8vXnMM3cO6V/1+zlp2P8G+EmA5JePZCOqqqrmv0DmqrLNujokrdNV0
SUR6vtlaIW2aRsl0ISkcrSyEZaH8wyGrZbKkD+7WJeI6aqzWzYZz5b7Aa0N0arhWAyQqwsfsV48c
gkKhul+snLXAitYar1/1FV/9KQeYOyhkqCZMF/5ti+e6ncM3bjaTlKi6OkenKLey8Dj15I4HqjcW
wFXFOQbMZFFoWZo3glGZZNXpUX/GG9kORf+q3hdGeRk3P3OFbizAwwArs2DcFF3UF+/AVLzR4zpo
pWl78enrfy83B5K0v758s3/2zxxGv+imou3DtH0qVpQCSAeVx1Gk0UHk/l7fncSVfDVBom20w78d
xM+nPMme1h1xHAtW2waPY8Hq9QPOB9D2eo2ma9ve3G+e29qWXXEe07LPEZC8wMrKVZGuDQGupWq8
ztwfXgtB2pzf6/LhMtbEdnvNUeEhVoHzxEjk0i+qoHtu70FJzfu9iKdgcKjc7QRhjIPZY9Lfimx6
fB+gAc6tIKSbcTMGwRqkmjOvVtjvXJyv7F+vt7wu75FtsD/sH+9PFSkUZQjGEAs1+PlluAcM6i0F
Km2b37PA9z83/Smeef0NN+LKnCHNH9mIWAPF8jtWcy2AM4P/n08pryxsnEFb6OUVLtEbrusJ1sr9
Ywv3Y5a52LV7R1xftvNZRDMEtWnVZuL4rMfrh/a9gDEAC/ts2Eppokth73iOJ6dgbWhDMy5aJVOq
imPDhg/0wiSa3MS5JgAMrbBFAq/nA/xMoNA929mpTA4B//HM45KjHT29vdQGprwd12hCkkkGDbgy
N3CsLTv3RMWSWTJQlznGrDI/hFh0o8uYEHM2KaOV8bUyR8YpZTpQoCO2ELcXWbUdva3ULzZHtZI2
9pId24LEBseYIfBfKe2+nnYAS44ZmyRhYARmS5A3NjEDozdJjN4c2oxTXO88uQoALkM+nMcoOxia
j94LriOYPS5El/RMDfaUEnrdVcZR3AMZvvCPInHENdL1p5s3pElLokaZuRySEp4Fy4w0cw7DR/i3
BLhbVmpF9k3tQVEmbW3Z3kHfWtO3AGwyiLBjSySDzCMMnbYCtKx1EhIsmEizMvhtvNuyUj90miys
ccregJhLBXUIjqsJatIDwcmW1+Y7GEBi+urVt8RToeRSPa76ylnEzqe5rs1o63Heeuo7N+PKbmhn
/x6qAg3yvG9CNOdZEEO3NmlefPGs7IFY9DAnS3iYkSr4asXmCIisGOHcKWgyEeWmjquiHut7T3+s
qDZxIj97Jlvyz4zYc9itCd25kkMc16SJeJ7UXl0jlVbRBNwedrkD5vD9Y8QF4qLWPmoftHkv6r6Z
OfiKdAytQIFljrWrj7JfttWkD12s+2afjLi6vWgMbubZ7qhvC3updIm2zfn+MGSQLGa4a/lnBRGP
L3GiTfogFTFCABqA92zaqvNoA4x02Il0HuKeDeroMDkYhK3rQoBm6aBFJqlZmIJ5JutBgp2XYdg0
Sirru4oxRi6qCVglIERqVevPgqftqsPjfllS+FUjtQPBUPbpYMV/7ty5tP/A/rRnx5b0wuc991P2
jSBHlsybpYH/d5u+KjrdkiKjAD1peunSTgrpPjyyP0Qi3fc2ihG/fuAV6YcP/mKUXhEMvKzn1lDL
lqEx1kKjuIvg6VdRcuT/DP5j+pEd30lcw/70R2TPCHQcNN5wVwFSyg4AmQ1p5G+GCbQo9DuHPxRA
8Ks2vDpoZgelqezWi3PfXgDP1256fQAlXaUGdP4OwoZmaAloZLKuoTSJDOEnCDb1XJeQet0EiLPY
8T2shgQvMl8KP0qH/+yeH4g4j187+bYAjX5HbSS1f8qHxLZZgNi1hUDpm7e8gYeukQDUPyIQdAww
1xtp/U/MHUk/dfjXgjkU+JQBoK6efo7z+DAKkj22ffDnXJdAqYsAcsvbWJPwRTCG6hC9l6BXYzEe
RH389KK6YbUAal898JrIhHr74LsjSNkHyAfldf0vTz9x5FdCD+hKUv6vIohXsCWrFUWcKRqt4OT/
IZU8wDH3+Ct5UO07C2Q7GXRBj38HGWeC/V89+YfpF/b8EPUSHwaIPxGA9K/OvTPA/Yvbb0n3zz2W
rqaMjFlp/41V4vUEUH/bljcHKPxr2ib0sh/XSyY80wDt7OpL9z9+GEbKYvc5rstNt9+2zZuCDaox
9jO1LwcO4DXAHcAhN97b3REMdQggY6Bz3JBJRDnRyAlONktNuSWeSZOMvA8FkZPdtXxX0Vzjxxat
tmApLY5u7J3VE3z2FgF2HrodYNeCG1htyAjit7JLEwwR5wvJD0tXVXAh46JtaEaEWhkWzrtg3Vrc
ypa2wgkYcWNWUjAGULDYZvF6kjqcZY8fP5G2b98eyRYyhFF6yzrLAA3dmsqCtBNrt4lyVy4K5xfG
g0lahYmbBaSeoiiriz68mYAuIvZwWbdQOslKF/O4B9s5b/cAEiY7cBnVIcQt+cX1TACUdB+PoK1n
tvHY+AQ6exSvt1QZpbkmAH2LVpxRA4/2mhTRgLt4kR/7wRJgTfSNsY9zMxbSYdVfh8yHsYUkRXjN
3htZrhAsYX6rAjgFg8VHMH98zoK3NoeBwqW9gkt5STAlOesAoH8qZNI0bSBdQ4Hlbcb18ZkJELps
/ZFp41qXV1j4KmXDfVpWxNhjxJKB/xt7qSdkA3FhxPOtAs7qF7l/GxEclrvUOBI7U4PtraI9aJ3j
lagOAqjVZc9dXDLBAl26xTOIts+yYHMRf3G72AP/TA8490S1DSag47hHtVfagHHmYZMcZO0sZL+b
BbKb2nAmSwje7kG6xXlauyTw2wOo+u6t31AsuOtDZuYQSRrrN22vIs8/vuu7I35vEbLh1q7r0n8+
/CuRvKBt+lokat7AXH0KgkC5Et2l2qcBSBsTMiQRnt99Y4S7HJo/is2YTbdh/99Cnddz2C0fJ2P1
fufUX8R8/ybq+X504p50+NyJAKfWkP066vmaXX0zZdIkeSQjDM54Nm3VIWqKjjvJsUpewpBVDQSk
UHiNbKksiKlQqxOdMStqRBHEjYRAFyv3KOYOWDMGSMCmyK9aVFHCSu0sWAFXlgrg6go9d3YwjbAy
vGTH5jBazayWhwZhxnBrtLd38PMpYiboOYGBxYB/gHR29WQUjNRI39JxDQV3/01k4LyHOm79sE2+
97N7vj+COX8eXaEHJh+Lm/XfL/mROM6fkqmjivdfDr0z2LK91Iv7MwIg9aXLUpmi/Y9DHwyjLjgT
fP300V8LxuqPzv4tTMYN6PpcEsWLBWyyT9bi++VLfyymXLcJ9jXjSjbwhb03kb7+AQBJruG3QKxF
pMLz+rVo4Xx84v4IrH2s7ckYXG+97MejvX9DcPA8wauycbppf/LIW9M3bP7KGMTf+cRPRC3DuxFl
tHixgPAeQJABwzJi3jsDT6XB1UtSZPEfAZ1ei3pMN9FHHse++BN+dgMeb+Dh+W97fyj95qk/DTbs
xwB6P3Dw54PN87rO8LBUOuvD7apmkw/03wy+JxTYFZMU0Jn5Zb9fRp/6gCrM6UN1F1pBv89DK33+
17g8vw6dI4Hyb5FZJtizfMx/A4T1ULXjPx/6pXAn+0AKyATmv09auwGwr+2/LVk+5z8++TOkqT8f
2YA3pecgOvkOAnllKs2qHgQYus1zP81eklY3Rf1nL/mBWH29//AdISRqHcDv3/4t6W1n/jpYUGsI
qqqujtWnAnMev514zXbcg042ijHnUlbW+eVZIJj3xOBoFsGNaS8/Ty54cnWN1XSSqilnxmBU/CwE
g2WPFHHO8TYG1XeCfoYIXp/G1ZeRXI7qUE8sdB45384t1FiEAT90BvFuq3cEXHR3USQxU4r8ghxc
PA1Oz3PO2dCmi5Gqa0IBaUMp2K8DcHjJtoF06PCJNATzrvvCds2QMNFQPcX+VjsgCQqg0d8FoAB8
zUYpMrXEYb5wv45MGLsneNVVbGIAjKexfZTigr9LY9D3o4M4Lhnrw1Nqq8FwwSj1tBgLaCEYsm55
fk4COKYHqZkJk78ImDtCCayBvr400ANw4fo3Aoi7OlpSL/F4LVxfC27MXoDiSt3WNE2DZhQlhj0z
c3iK+W5Sty2ZvqOjI2nh5JOwb/PpOAvTJhjKDmL/FDtuR6NufNWKNbgqwaKKB1f1rRoUKUNneTZY
Rpm4UILIXh47MjJZo4xX4ZmoWFeXbNksCVIgMn7XaNPMKCwA4LaV5ylK5yE30rCRbFOFyD2eCcL0
R4V5uVoCflleYuCsYoJWDXp06OfpalJ2hPcqyKVUcUMHE+Kwo501yyWRdGERG7zG9A3H69AvLMOL
m8nStoDQghB5Ntmoi215lvWAjNhmFth6w8wiVRvObT9kgGSJn+vxcVFuZqyZvoI4M1VL16j7O76V
alEKRluVfX45/n79JrHwYsqw7W7expz/MOXVpsmqfUH8GIp0eeu20Kh7J3O/Wa5baJvLZ2PsTHD5
S/BBI69/B9LHjNwW7IzMmqSKNupnjvxGeHOcL42X1L1q/V/bY3uVu3l57/MJebqXmL5fDztme0s5
k2fT7amOIwLaaKCx4IwbVIHL78c10midVSZHZQEMFp5mAmxmwlwgcLmnZyDt3LYrA7qQGMg3wAlE
liFWqzFv5QlMV8JSlL1RZRNBRjLG2jCCcwRcj42NR1JGP8XnP51NVWdr7MlgydpcBqCyVIhaQW6y
Vt+x9WuCYdGFqBGXcdGFKM0qe2WQo0Zf8ypg0ezJ7t2FEZKx2d64GfR9NusV0eabAT1uKlWbyr7I
ysLvCiiNH5DxsbixYECA935WBkcRU9R128pA0hVoP7ivBZpdQRj4uQhzM8oxdGf6mUZSAGMGjwWD
ZRHd3uxqAf0d2SxZI1ckxiW4+XpGwEJ2z9d0fFm8Z+yCPyVdLXjpq/YEWHN7HRS024fH7mZw5hjB
vW0704PnHg82sIvVlZvZX7ohzQxzE5zq6vQ9V1sG2l/asis+k5F8OWKMP3H4l9OdZA09RFuluVUe
v4F6gaWb9Rqu3YdF12eptm47bwGM2bd3p4eSWkEqmAv2/h4m8nEywLaQbu8qLYKOAUn2lwBQWt/+
vaqIIfyyQljycUBuOS/4aEq9C+xsuyrk05SLK2NZLCnjvbUAtBOULKbtvebTjEsUPF1/1eXBuFlJ
QUHgYHF0h/H6Khm5eBR8PwO2eA0YMdRLILdgrBZtjMoRxqnqXtP1EHQMTDis0gTJCjXdcZFx6tuC
DPclG9J8UI4xPTUJGDGTMtcY9B557kWfyzg9+ypujORIn7pyuWhGLLxCiDgSDTgu59CVOjZ8LpIW
suabLQWICESl9hi/4pRJmP1Fyomdxi85BctkGbQ6YtAazyH1EdST8SfEE3bxHFITdfjJQ+mJIbLJ
YLKUTDJOz8SPJgDTPYdxD3M/dgy0kR3M83H6WDqCbuUQoKztvuP2HuLMJj3sD5DaYhZxT1vaRlxh
K+iyiQm6oRsmr5PEEOYYE7yaWVyuMse08n7fjt3hRp1CP2+MmL4ZQOcCIHWa7ORJnv8lFrczp6me
gTdiBXaynVrGc7CHpG1RmksFaK7NiinquOmVsHIJ4sqWCjRj2s6OGpMAOuU6BWbGqa0KvuKmZQAe
z6aZ/7ii6xEBbADQKUkC6qZma2boZBEXyWL1djfD4uUyKi4WMkhfJrlj8YQlD2kLyRKheiiiprqE
lYmizB5jsBXR5xnjHWvoHLaTRTlFFRD6dHEV1rPTNsMZtyK7Yoxe6fbPrb24XeyBp/WA86827LuK
eG6rQRyaPR4eK8kJGbqrWeS7UFYUWA/IPubwfejHOZ2V864l1JRM+SWK3RtyJGtnHN6FdWzFFdps
Q2D0+Ai+9NKUkie5OkclPUEYk6BRu6WdLxNhnIOdMQVnEiV+5v7a8CnAoYLCOVbOOVO3r1eQwyj8
10Qsg5nKhg9p87UjxtmtT8p4tgyTag+TbFdPD+7PttQH69ZF4Kzle2TYBHQycGNMdvc99CBM2mIa
6N+YNm3cEoHHofsWK7w8z7g5WZbuoCAGsochS6KY+coxR5lEW9s7o5TSuZGx1IdESSNB0p9O/IZx
YLd0XhOlTH7u2G8xiD4cBvgMwCyxUjC+TuanjYFhLJZblCopYk8iw6i4YRYH1rhbBPgHd3xbsDEf
Aoy5yvCW6jdfYPV8GFenoMQBIdslABDl/9iufx+sjJpJ9oUZNqZ/G+Cpxo++9xbcm6Zrf+OmrwQs
7QhQFmCmKA6lgrnuS9k3ffOmrws61OMpNxWrVfCOQWgWI6zkPOxeXBvt1C1qO6SDtwOKSsbOGDFj
5VxJDC+NrsWUGV+QB3mFWMTxOI5CnsbBufIYr03me8k/45Dy/RX0TtD+x9LrYAlNIzfOzwEuoH3/
6B0BtFyt/fLxPwgXrnFzgrsnSGF339JlnR/QtijRIo3u9nbKw3hfpOH9Pca5ZqDFVWA/SkzEfzv2
27hYiaviwfoGqG/jGH14/weTgTboDIK2ewGXCk/60NvXZaBxlg2OdJ+1h9D3/LscD7ZBMP17ZGj9
9bH3pB/d9Z24Dc7HQK7djE/yYtxMR4yw5cnKBY4AyZquZrvmPK7oyRzMS//LLhmWYE/7rEV8FmMs
QhN8N1yrGfAJFDcQVyYQ1AUqI+dCSdC4FIlGAH0mnu5W0v+3bgrD7DMpuFxUsJsDhmZZfFdMaPmx
XBrLZyMSAiJGr8j4pR1ChCuuuSbctjltys/1/FquLL+272cIvDeGdi99YNtlFydwr/YP9EfZM8+j
a3FoaIgqEjOpf2sjn41FSEeUrgJc21etyIYIWqyMoftz/+nT9FEP89Fy2lhPYgf91UY/XM86p50s
+UbGCmRUlFcbnzuXRhm2QBUySnFxM6n34k5dIBnC6pnNlBcz6bVWRUoChNQM4Nq7Z0eIO0+TUKBb
uIb+n+X+JsdHaf9UGhwinnNwCFct8iqMxWVEl+MOWtKPpAPDTeq5v4uzCj4L8gBLFnO2rq8ab9P0
ocmpsnVrpEMByDyQ+8mw8lIXbQiAFmOEERF9MUtGah3xyCsA2iVYueLmoVcHaLdyjouGEHxXE6+S
umAXm5B2qWcBoJtXN67Hbh8A1MGGzsOE+p1GwOmSNWpxJbf2cawWwgViLF7cLvbAP98DzqvOnW5q
tSmsrDfLhAcJi9t6byUE6avDnkq47GYuNglQO+B8W45yX7m/8+40z6sQy1qzujPzPJm9B8boGeYj
kaK0i2TBXogdJUqcS7Xz4ouvInxKYsMYO3HA/rnDa+3Upupl0957LG1ZVBdxURzZxYadna9/nQFf
9qgIELWJJkPux6Xciu03LEgwGkkVz6K402oNtFkzaJxyMhMIlk4xudbQrFokmFkGTkM+TbbaJGr4
G3v7KZfTGYXTZ6an82weE1VeCWaGLhuGciWZDUaOF1K4U2JilJW/7tUzTJZqdbXhbh1BO0vDEIKm
/8wm/ary9jaAkDfA8ioyNyo/67L0+Jc3704NUAdSqm7edNmcFiQAmvjtFlMX+wpALE3y/xz8hbjZ
3iBdl95kFbLNjPlj4rP+cihr1xxkJaIr7kvqXpR+9OD/CK0imb9vYgBH9hDX/pXUv1u/2Y5fAuQo
XDjH4LA+noBQ0PMaQJdlYXTFOnBe0H1Tek3vbelPz/0DbfpvkVVjMsatAL4nB4/EysQOFcCV12at
vtf3v5J2/m3UILTNt6L3Y3vNgn0FzNnLcUv+9JH/GYBI0PbmjV+WvpyYQuno+3FdynJZasWHqQz0
dMVkO928zmWsk7FxgiVpdUHVz1Gw2tWT4Es38DUwnOr2vLpQ3fbhMu7tZ4/+ZsGSLcIQviLu2YPU
PvQaQ5OJFY8uc88j+2Nffmj8rgiylY0UbF4GYFNs8g9P/3XcW8eC7lj751eOvy3i52QQZQa3k2Qh
mP2Jw29FtPNAMIDS6SVrWWWgsE6L4zo2pOq/E2Z3oJFqA+x3ZeveT3tel8m67xOPkghArJj2Ohgs
GBAAThMsUQVds6gY5ZCTNXFM6lqV4bHObzBzSAiQ5bltM0k50EoCNmNUNfcRj+qUw99+z2D+vFgq
AuTjuBaM9rwSZ9YYzo+mgKEF4KCQ90LE1uVar8oO+UwKypY4DnY/DlLijswlZhjaVKCRsj5wfqBl
lvKCzfaqfdFHmYdcD9d4PhYZuD7LIH6BZwshFurk9bCA3LVzJwCEMcz3w/UJM9Xb3QNBFXmrMZ/Y
Nzt2XxLsof1mbJ+1ZldrVKroIoECPNOBnEcDbGMTosabiWUTHJ4YJG6OxIj+jvl08Jx6dwA8ZEma
mHMqzC/Wku4iKaQFRk/pGuerNmPaetHRMottfhOM3TTgU3A3k47u53hnDpJcwKQfiWJWcYDRsm4u
P/Njeb5TN05gJ4Cq0rgV5tQ6AJ4SJiuiaWv+lijYexP1nQF9JjiEK7dk8YTPom5+h0YUfS2IDHbO
H85LnN0KiSRxa3T7Zi0pJFjILAak1XM9VWLsFEEWya5aCqwyGwLCS/MwDrCKrSRzzAzW0pxVJLyH
eW1xcbvYA/9sDwh1BDh6foxZ/1ri0LQ5Ajg9K3qpyioRLuR/k8oTasNFuEnBgHmCEeyCjNxbNn55
zMtijT/F86bXzLi5EUCTdkYvlzqBeue+e+vXBdliUqDC0gKvIWLgtH2W+/pve344PGviAYkN7bj2
XQbRMmYe463EVhuCY+jUyNJYvtb1oEyMAiCcVaqIec0Yc4WUVXX4fy/5vmD53nbmb6JObbR7bdb8
wg+c6hxxHsvUExyhSLcinCvEuawwyS3jTolYHxsrICKLbXwF9XTT56Pz1ZzLgC9+u9oPij+zD05S
NSZX67Vmw2IsjZxVVv0+d/wgGVxM+DBgxw7uI5bmVPrEg59Ir3j5y//ZXhGA/QckJo7CRunHv4Es
GhkqjboBmvrun9N2He6fs+k5vdfHsTSYBuubeWotOylaWTPfMyvTgEdr/AmojAcTzZt1KSBQ1sLv
GQtgBuSXEl+l21A37ACrC2vcOUgEfwIPGboLt1eSmSPoMZV7V9NWgu+vjNqCZmjaboGQ7JyrFY8r
JfwWWCjjA5xhb2i/KvbdiHCqA93aegIRt/9AWriCjH7H7QyxgQPs9xxcwA5GS7DYJw7mj47fE8kE
xg0KhN18IOzLHQAlExN0Ndo3bm8Y+NK1GLLvoq98WLfT7tBpAg4JXLexvw+t3/H7DnL78o3oC7m9
ijgH+1Qmz4e+n7bJRrpZXsZ4P4GJ7TXD+N9ve0u4yAWj/2HbN0bMgw+wmcvS/La3mesyAcP7r2s5
imADxqXivXfGALoJ0KwP6Pm8P4LF0qPUSXbl92z9+sic+l5+m2wj1W/8pNftdX262xDyO+1d3eiU
5TrGES3HM1BDqX/KqgOwPavKZLj+yXR1MFMBoGJVaMA7QfCGNtzxAOAux8fFgQKoZVYs3KiCO74n
ONq2YyehCn3hwpV9yp/nGrC6TNVLbsTQK+wdlVh4ryXAl4wRxr9gACPpwQLtxcQUiRvBDNpUWsLx
g2kPl3HGFAE54hIyApDNKzfBaHtIYHgOWXyFyFcAc+pIAR7RnBQILZLl3uC8ob4djJLyJ/F3AFX6
yAx8Kk0sw0Qtm0VPVqnlucZJehhdZCFI8oLi5MaLMcuipTaadm7sRhMTBnADYJowiw3dsMFEEJjY
NUm913HKpFkzdmp8JJi9RmL2WnHPVgxhIE7VihFtBJ61KrQ7QM3Y3c3pwx13p7ODY6lxkXbMEIs4
NJcWSCIAuQboEqSpPbcyTXtJMijHmGUT6wBU4ycyo6cuXEMPoLSoNKHXOsCr/wR0UqdrWwaORSdn
sFW42t1F17N/ZtCdv+89mj2Fa5gYyIq13HBHL5PAFneL+956eX9qM4v3EHM88XuNuHnr6haJT4Rd
xgZ0XEyI+HQf+f+r93Mx/RiZosY138r8+9q+256xPx6Hkfvf5/4+7I5bWX6rzGI1ae5hkg7Py4/U
hRKDwNAY8LeS5CeT5vn02Jg8eDvSXYYAaS8NawqRX8b0h0lqNC7cqg+WcdOmhbuU76qI8d9P/G66
dHhXHE+CQdtopYoggdaBMp9FP7Mubw4LynF0HydeXBuhXZAQOUC8oNPlpy8A8/kZMtUNfTAC3f1Q
+7OotxP0oVZS6kabSJeecUBMHFZh4F9Z5ivie5y1ipigqCLBZBgin8bVRNq/RsDSQMWEE8YCo8Vk
q3tpDlmBqrUQOf4CZYnmyEZ753ve/ykBne0wvsyf9duNADt/CuuS9vTsLGi4/JYgxs2MGzdXBpch
OOomUDPAcv1WxuR5PkHDM21SuOs3wcQzbQIFaeX1WwmafE8QV8bplfvIMPmzftOFeeHmaqjcngsL
deFWgifft8bdhduFfSnALeVWBJ3lVsbKlUDS943xk/krN7OK/oKkji+lhmIpQjlAHKM/z7SZdfpa
GMr12/rrEcReqAPovreSjLJ+86E1i/nCTaDrzzNtrZSNuqI51yg01sMizr+MW8CH9i0wsJ+OdpXf
dczve/Jg6uU5csCFtIjvB2Aj05FYLMtPrWVB8pmLnvooLyAgyoDO/c1iHFOPzkcrGLpwvGZGT5An
AOQtNdaWyAjdf/RkuvPhJ8jGVOD7vPFX9zEX/fFk2S3rUdow6s997nMjYUK5EoGfIE9AZ/hWTE8A
xxLohQuO93tgDvu7AU9x1Iz04pgBTIuyTBETmAFfEEky9cX+mZRaRUQ4Bxxb1zlfXwaKrTB5lQo6
akyUzjRmmsrONcEcmZyhOLKAV2BJEEiameL6YOrqyOAUTNXjap6h704NkVjStTV1NlEFAWBllZrm
5nmedeJmWFh2dhNHibyMMkkygXMCPKtq4CmwWkhXd28a2LQNN3iVfbhn0JaNuHqh4lJjd64a4JS2
soWC8df0IPWxALgjZgh3qEDOUl0rzGVe1LLSJXokkAhZpERY/RjozXuoi5R+rfaSALSF+tnOpQK7
WAwXBFnci3J+LUZvpkzzllFg7m9BXSRp4PLFtVtFHqW+OTOGq5YOI/4xvrJIbCSu5Srxle099O9W
qkd0WJ4Nl2zHdBr66BRJGlxceY7iVBd/PTt7oKxt+4VonQt6QdHvkdCnfTR+PLNUORHHJDg9Kx8h
RvsYJIugpzGqKxRTUjHITjPXHgWErR9ygjdjrI3F043r3O6xXYwb7iRT5xwkONRLlUs2Gg6yGuFK
jwAQPZ+VMLIrNZMWasrpai2rgQgqVaxwPsqxduc3SazM7rFY5Bhl/VY9PZYKK9vjZ8+2rTo9OR4T
7/wsBb7D3UHnAXQacE0sWfvRzDOMR8RqBBOXwdz6166eY/qOXjGWR5FTJ39iS8LOxIxeTEYKDrOv
dWMxLLq9FunUKcogvffd70r7/t03pKuufDpw+XQ7TiO4QHuNA7y4fX57QPZUoGpM3bN+Y2AuYbQj
eztcjXXpTbihnThkOD/d7cSZM8SCnoqFjNZVCCbR4mgX9MiUVcL1mAk3H4Ngy4KQyWvDDNkyq9dF
rddcg7GQwiiOFXv5/MUEZZIFOnFkoi8gxxHPX5zQo/jAlUxgZtAaI2askqZJSJgno/OhB57gGUGY
08zToN5wv/G8CDxnrTlKu7yGiJsDZG1Ad+4aBJSHcTOOUvXARKhwiRYhBnEVRYZsboFzBFmzPN97
NvcBBqlUIFB0qnU/pTYCEOZmq9VXYxHopCxgFfDJyrbgIo01o8eyeo3SIcTkzaA114rsRg9ZqQsR
GmIsIlUniA6owLCurLSEVEsdMbDL9bjhkUrZf/hwuv7ynegZz6YqIucrADwlV1aIi1PSpAZ4W2BR
OYVsygrxdI3MgX0bNgIIYe4Ea8SvrZJEYkzcMqCt2k44whbYvUuyVt3CMKWJzhFnR7WI0JHz4tT2
BFRZ5itcrsWNWQV81gaJOzwLGKQN9a1U0ZjDkPUCbInDE7jGxFm4gTKrW2KtMmggj1CTLnKWRe5M
clNyBrRjQQCZs25oN33qWOHt6WPM6VxTIwkSTZvbUttlXXGsECOO7J2L27O1B4JY4Zk8RIC+Ho8v
FEMk2LG813898qvh5egnfMhn9uT82fDGmOQQsldKI8Uc9/RtffWK9Z/GVKZXUO3IYvO9T7a/uzgz
CswoRvqMt05gqNbj+k0mLjTDn2G7MOHBa9Cb9mzfqpZV7SNVvtJFaZhYWefJWa2rqIXIrXAVO8pP
KNUzmTcqDYDYpW4Sv9ROSSNX2yGLYFA433eFGy4ZV9wctzFqSgLeSKzQlbJADchmYjw6okcpQUQy
hsbpz/7sT9NP/sRPRHbtZ7Np3Jo1oBe3z3sPrGf3Pu8n/yxOKJgLlkkXJRPUhYzopzqk4Ojee+9h
okAwGemIOQz9PONP+2p2aZO1hVlgZHBUujFZ5hg7xd9LRUxbZFXJVhWr3AjOFVT53WC6CtHhsOwZ
CAXTg+vQckPhuvWf7601Ok+i/m3mrIkKPSF8vJqe/3xcjNZbFhjqGg4jXgiF8y1j9aKqBZ818bxP
ToyFzMeZE2fSaXQjDcUIEFwAjhwYfF6uxc9l7T3n3FA/gfqI2Ta0pn1UMDCbNb4WQNJjxMUU+CWD
xJA5iQVkSrfsrUs7qEJhmsgiQMnF4gz9Vg9AWQTtLQuI7C8AXX1jB+1m7oEVtZapUh6LnM+kkRoJ
DAt11D5FL7G+2o8OG2we9VtXV5BSYOXfiovYttlpJixNUY1iHLdsD0LLCxio+gpMFv29qhg0DJjJ
BmalVnCfyoy1bkbeBGHeVbT6apMwdsjQ1EasP2lbZeEKk2ZcpPe/IW5sjAUHzNIwwPKMabHMl5QV
a+yHaetyHqNP3N/sWoFZCbjWLKTjQbZXtq64J+XiOQZDRoMCPBcE6qCapJPjManPuY8MXsqBrY5O
k5iGFFVxTz/V2L/4+RemB2SLBEvKW+kKLENtPt+tcaaRILZW6/1kjBuc5ZAsa6YGg1bEsH++2/Z/
8/mql1+yI+3YtSsm9Hjw7Y0iwSEbCQYQ7Nnh46fT2TFoeZZ4PdSgXJkD5I0Ohnr8zj3bMQrL6cw5
lJNjsqd49hSVFQBs6s81cLxm9jMgeYnYl6iFjjTFlg39aQOFxWfR1hpECNQyYEePHkv/8Pf/kF73
ejTAPkWCxPobV7pw1hua/5tv7MVr/9Q9EExYkQGd7din72+aA8zdefcdxH6eCekMnxkU4sLgqu3W
3Yo7gBluGhDiM1OyUVWMajssUyP7y5YsmIHqPrA2mefOT2KuRJi9atpw3aPhVS3OsaRMRpQLyIum
vBrL39GdGuBQBrC4rohtLY7pM11fxMM18D2PL6h0IebZS5Cb3cc8uwgnt3atpr4t2zMYCywm+5jb
lU9q+8wgN1kig0sXclPGuw1Tvmx6LK2OoRJPBmuWNsqAJoOR7DaRtfPNcFFzHD2+Z3CXrk71k1W9
mvadmUwjKgi7zFSUme+6HrRGpX0gA2pWflxrGQ7Ce8qZvPSanXhOSQAgk3UefcAa7tN6AN4c8Thj
iPKSI5CquCQ9SrOq94C3GtczjYbb0JmFNEUd2KV2XLADLampE2YPQJdBlm7W3B8Rb0i7G3oArYr9
nsFFe3QiZ4/C1NHtkbka7lnEkq0oEV1nKbAi49d+k+WbHSY3F2C3ShLJqpm0sqIulkm88DhKpOT7
lGPk3EJWhsFmXOEaJVKCu2Js+YEA0eT1pl4bBCt7gnPh0m7f8VT2rxguF389y3rAu2TccOlZ+EI1
z2dOlqscNY7CioWBL25fsB7AI4R/m8kiNKh0ETABzJO6rziwdVeNpXNC3E5dQKtHTFBEu642myZH
BskMIwaNSfXYsWORtWqsjZOz/zYSrN1BSR2z2iwbFAkWTCRTkzNp34FDqUPxT+pcGkzdyCTfybE6
CXKWV3jPe99DfMsstV1fkwYGcvmtf27LMUo5Vk+R44vbxR74dHsgJ+tkhszx43PwqTbFsT965x3p
2NFDAdqUBQkZmEhEgLHmeekhy3AO8FGvDjDPyCLPkq5MI5oUDzZrMcSF+TuY8EBqOabMJgRYKoLg
ZcujdeGK1QQDZiJYN1N/GVNlxqt4DLJBX2NbgtopbDz7WFPZWDB2mV07do7/cwvyzBf+XbhHI4m/
YIDKz4KJNMMygvcz06TbODJxOYJ4pQEpkk27OtM2UMjNN9+Uw74K4Bk4OLc8wNCKyRMZ5cW5A8CC
PM4hb9SAi7iVbLMaQFoQGcK+VkLgvM5bOnStStGwpAYfmaowUHNkzS/MKGG8mh5enkqHWWBaGuzc
ckM6M48LRa8Bx/HcZtIWTuFoVK5frdu7Ph0dr6UpMmXrcHE1NM+lvpvIjO5nTiP+zLsRpQ0LhjRC
hmG+6kmsME7u/2vvTHcrS7LrfEhezkOSzLkyK6u6ulxDT7YBw5YtwS3oLfyc0j/9MQwDhmFI6G6V
qtrdWUPnzEzOMy/JS3/f2nGY2YAAwQKMRsL3ZrHIO50TJyJO7BVr77320t37SZY4e37YjahiccmP
9XVjjMmGNSPZ652iKofJErpMnIuXuHiNyZsAEAsCqU9e768AFsmcncJDom5cxTE6/2h0A7lXZPin
HdeormZ0yFBP1+aRb89zHVcTuNJ/ddytfPbOlPnnboLx+3/SHvin6sH+qRr0rl/gT9WG8XmrBwbq
yVmG6xiXisKlByyARxSLNo5ON6uLvzUeZ2DL7q6vdQ/v3uk2N9+QKnzWffzwfnfvgw8SrzaPNIOf
SayMzACupyyKWVak+PmbFb40tMotK5A7ZaE2fqYW9tp1qlX113/zN933333f/fIv/7L7/PPPu3v3
/jhB4N0B9BrGj3EP/Mt6QEDyz4M4j30Ku7O58aL76puvuu2Nl9399WXcrCidg45uLFCfmEmsi1Qw
pmj/WUCHmyJiUZ33vHcR9yri/TA0AiPZJMvqJcQhjEsZVUtcWXXCDw8x+tr9aM7xmWStQk1dxCXb
y5A0YMR3daeVeG0BpWIHC7AGe1lxwL955dKTeW/KekXOxC81nakGvGRz2DIVKAibVu5Yj5ug5Obq
LcZIQGpYRl1fzp3PVTxh70oVyhqeYV/1jJ9fTp8I+nzZBBDcpvc/+lE2hD/+7LPGw5VCVMCtpc1k
FwXLrEnGw3l9YfHCWlZoyNe//b16LmS8LnbHxModHSBjEr07jsH4LLMhTdviInc8SJxgbTpGrmm0
vYEcyFbAo0zZNkBu4dO17uLFPokPJE2soKG5SNLEI2rh3oSVgz0lH6MYS1QDdMvOfbmWkmAXlB+T
gTvfQB2f34lJ9kdQT6aum2gHz+SKEeKBsoAzHDMsnywucYyjXbJxYe8mqI5B0jsJGCResAQOyKI1
I3iQ8anxrAHoWdT2tB8XYwGYRzPrhrdwzSRw/F+Q1P+y2238rXEPjHvg/1kPDJ48e0ZmHTtf4t90
I8kWzM+zQE2jIo6R0p0h+zZHttk88SSW1XGlfQor9+DDj7p79+8jykkBDxbCU2JXXD8MtlaqQIbB
xf1COZTE5F10m9u7UaNf5NhHnM9duQHefmdokLrfd4ePi/arr/6h++abr7sPHz2KPIMPhYmVHVDQ
+FDdOhTgZ/hROiUGTC2Alryha8ldbC+pYuNkDmQfJ1C3Z/mLm+ucbLRDMgWNqTpHFkH5FsuWJUYw
ZrCRFaFD2lg0NiNq7Lp8DNj23JpOFvEEyTemYX7RMmmwISSg2J9m+WqYI2prdQGvlzZNEmdkfMtd
WMmlxXlc3IdhSAdEYhvA7TH8blWLiHmOYZ2FecBjEvHY5DcqKVPWPMYyAra06QKGVZb13ILpsKa3
qc4xC6Ppei8rq2v9AmN1+9btjLU2JPppnMNapIKHyGV5fcZv0OYVBFt9vrnxPIH1ju3c0lqupTfQ
DQkERBSldN2rAQP1iPnP73dDaK8/mm3BO49r9qmJbQhclAYJOGMDgbjzJO60PwJrOUC4lBzo2lVw
fSy/R/bjMdplzOUfnjxjc3ESXbVdSmVtvH7dvTYj0mvkPnAjJNOlXVxBksO5LkNnqa6Hd+lb7hmF
hRX9NR/K803B+Hh9ulgFdyY4aHiNY0v8qoAsMWEAEQ/ud5orMm5IXgkTCBJyrjguePBazxWLx7CE
ZTM2P0Ke/O1zN1iCyrcZtxVzZW+44fJRiRtv53k2WXnDz8oKCZ7eMjnGzES2w6Mkc5dZab3ZsIv1
3WKRdMP27sF6XaYt909AbI26nwjAE1zFbcv9qtgw96ZsYIkym3hVYHLSChcehy/Oc8/Eg9tcsn0y
1iXryo8++rD78osv0g87sHQHzHdhobGBTylJeGf9ZgDYBQkRxvnWuoRWFvfg7iPuW+ufJvEf1kwJ
lRdb3XDjjHg3Aqs5/vkz1jIz9z8F1N1C79DYPZMnTA7jQEPKlQnsBrhiZ25xn9zA9fz73e7s6eH1
zM/ip/KNg9T6Q3fs2QtcorB5Sp4ofzJBksUlosETJICEHWUCnr8WjKFfuDwX8G3c4CTHm1TSxfHR
Rdsj7HYbZY3w9XyW/qStNdjjx7gHxj3wPvbA4ISFbZ26iOu30EQDGFmLVcZrDomBGYBTgJj6cSxi
ccUALE6IdcuCx1KkYTrB+Anaskjrwroq8BE7aVkZf+l24nNHltbBSF4BUo6oQOHyq1vFJf4UoLG1
uV1Fv7UPvCYw/DXAbo+YvAOEPidnBJuzMXqjKN3XDjeGSLYiBqHib/qoIasdLMA43l1HV4qt8yGl
x44Odrp16mOaDbeztUmcz0aU10cs8HnI+rFQ/5MPDZBgxzq2s7THJBJZRiRZdK9dUfZIyzIJyNOI
Kocw4PfpAfE0tF3gKIidQA7Bz52ryUVByAUKLQrS7sN6zkHxbGy8QVX/YfrD2ESLvXv8ZAqinyVw
KwOuan1ZWQPRDYL3vMU70YewFhuvX6Us1PH+djKXF5fR5Pv8J92Dhx92BwDaYwDt8GgbYHKjW8e4
zRrnZYyQ3A1jby1STyE4HAJ4aE251WE8DoilPDsxMHbYrax/0C3f/hHXaZZxsTe9lqGtqXgv/3BW
aJArIP4a0MGCVDRUsUD+1i0WI98AWYBinrwFf/mkcSVCpzAejIEp7+98tnBcuQXrrzpv/zzhArx3
crSbOf3y5RviOwlsN3nBFHau8N4dqg9Y6F32hmxqM6pP+XnzklqFSI5ckmm1tnaze7F93P2bzz/s
7t++0SHSH5frCffKqXpznFUA7h0kSC6xXwEdwJo3BC2CuLDa/BN0WzNVJtv57vcl74xVuwIg9kxd
z345V4LlZQY9rv3k/ZRNRAGsgs7VAwFjecF4OsfZMW+vtxugchcKmJlIERD2thNzjF4FPoCnLQD9
mWxQgbo6VzJasyFp45A/2oi08cmGkB/n9BxA0j6JS1dg53s1Pep+yHpT4DQgsa46YEbNNqtW7FEB
Qn1NN4U3kfcYzMxTaQI3LF6Jjz98kE3OkHvMTY2bOv9efP6qezJaosYsG6vIINByNrAjAP4cWa5T
q3glOOf5LhslQNbpC4rcH5x1c3eJtVtnU5OAtxJcjyYfCQgDBnNwj7qxNxe6+U8Q+322z89B3KxS
lonNcyx0QTsOzL8Em8PoubBFs84rRC5F5QTvITNvh08oSXjJppSSYIdWniDRYwLXP3tzhITbeL8L
6ONu5lAKGttnOe74Me6BcQ+8rz0weAhg+OyLz8NkuNiXBAlArQl/ZpF3h5cFmcWFdeJMdyqgZHef
nS7q+LJglhAThPRRMS6mGrvIILAwKSYqONtD9mCOxUY25YwYEVk93SRvYO6sRbmPu3cCXSkz+Ao1
GQSMrhTlwdZuN+Bmb6dNzbUSA9UMRBg8GTNAE21fZL9611qK/NsDzAg+TlnArS27eyarZsbaGUXD
K6OM3P38GrAKytDpMvN5eBVjnvxpQdyC3xheDa2ATkZBYzpiIed7c8QEXsKwxcDQcTOAZg2srjT7
QFA3JP4m7BoB2lM8V/X+kPYNZtfJ/cW4HO0B6j4JSISrCCtmBqXtkG2bhwW6dq00uYPCSzAANN0+
R761m1h/QHD7PY4JayDaxbhQMrI7fvYS184QUL/W/eKLLym/tEybMGhhCZq5190nlAhILpZwiEDr
777/gYLwd4mFVLfwuLuxfr9b/wDxXy1IWJ4eeJWx9VEmV7BWZad00ffgrG4ivxPU0Qy08UFvn/c3
2lu2p+HDAIO5jFe5/ugX5phzxJiqHlwGVDT2421bCuQ0/JgQgmUqCTykXnGkPRpo6JMoZIfVl1M3
zjEwo1t2+Q/PXnSP//A8Mia/2/qhe/7dN4QrKNnBvSUE1pXp3GL8Bsxv54H3ju2blhHVOtOIu7fX
0Gzrdd/Q+yO+SnB+zP5CVs/5kgD4tNmgqIrDSn1Ve7X1gUA8QL9mdv7nNVaiRRnzhonyWuE6S5X5
d4tnqwKwrdurb8OCtZdNPiiAWCLC/RuTfN+x7UFa7tCAq0q6KPasNgnVKD/rddRz/01SkkawNkVM
2Lkgzmxd3qOyV8awgFsDdO0CCzTWNfYAT1fvLBuvyIEgtHsmAwcTN6IahODtjA3KAT/n3Lfl+rZ/
Kmv3FFB8ykbyYlrWvbmdWecmubcnp3B9CtaszIEEyAQASrfpkAoOl2dkjQLAZm/PddMwcq5jSnzm
2t0MmyTBGjD3aKmbfcB5P13tjn+PrMwT1AS896Qg2y1oZm1C5KDgox9o9QdrxeqHx3V/aV87drR1
RpkpPjc6qEzWK9j7MxJ0Lu/PUf6r3cDXrHgbWq8306hNiP4mG/8e98C4B96rHhhYANo4IEV/XXRd
6K8NQm3nfTWs3AGxbae4FV6+fBWmwPI4d4ltW8QAmozgWnyB+0324gQmTnBjCTHXHbf8LucGkJso
8T0FsE/UaLK7aMPFCAClawXW50oRwrbD155UCaSKySuDJcvhKiTNAegKnVDv2XxL+9y+uQ74mej2
Nl93zzco2EubLC1me8rNQ1vOAI+xH/xf42NTfE/AxPkH1JdNsLxg19euzZ/bXFlLd/LtvK7Bun2I
JRwpzUJG3SwG5BzWTkOuq2pEWxcVUaWE0SlloY6IWdF1uYDgqyr5xloJQowFMnv4EsbgDTIRq2t3
YNI+gKXc744cK4sLY6TM/Ns7pY81AJh8+8qrED6wZw+DsaRgqmKiMBE7O9Rz3d2llBsgG2HWIcKq
sinJFrz8rLvx+ScBwSe4dHTBGgjkeB4f7gFgcIdHkNYYLupjwjZ++/R5AOUUIHR++U63dveTgIor
jEoxcf6U663AXe9ys6G2WStV7+URhPfWLVev+aJj3u6ra2xR88Dv9pClMht91oCCY3sdH1fHKMZI
OqfGu4BFza1iyah5CVgdqE0mW6YAWs2sAhdtXpbrH3c317/kObgcXdg/+exTJC8ACuoh4gs1RtS+
PISVPpahRufMzM/TY7Im+YxacscwPke4ZWcWV7tZCsg/3TvrPr1DxZMvHgbAzxkiwPkX+b6bHj9/
amYsc1D20KsWpNuNgkylUny94ssKbHkvFsBpYCpXVWNkpYkGoYRlAe/hpnvEdz2WbSgEMem3Niat
18tlXGOeUci8rNP0/VdZGw08vPP9xPEJUNO+QouVqVtgdQKAlTi/xBG+ddcKuiZNjmgbz34uFcPl
3FImZgDz2WvfuZFSG0uh08ostvTgAfHDCqsrUiyY8n7XQ3EqO6b7FxB3dVYg6goGzsoL59tVJ3Wa
5IcJBXqnPVq5yy8szbUFa7ePlBOsnSLCU7cElcWey4YZa3dBEJyM3IDs2WVi5eY/X+9OAHYn3+1V
5qs1Yt1U6OdmU3gFE6eGXNKgvbxI4HAl6Xb+Z4kwQgEmWUsmAZcjrmnEnDtnPd57CsgjuePig3XW
INbcA+5pXMa5xWQDG/h/O6rjv8Y9MO6B96kHBu5QXfjD0AUYNSZO8AUw6d1R0bFaXiZAl0QG3HNn
KK4LmtRukqVw4R1yLF2vZFpQKgyBP9YXmYyRu0YW7CdPnpL5RnklyiH12lwFAosR6hk33R2XuDu0
km6q+0W9jL1rfQVXh+XgRwbH9t2g/NIdjOo0z19vUhrkzR7g5IiFumno6b6R+SuTUgZObNGMUEkn
8Lr6OTJxLO4jXa/NEGaLrVuvAUq7SxZiSikGGBqB0QRl0+YNYsLHcamoIn0zQLw0Ae2UOhtRXSGB
6mCAC2Pj4kKtAHeNXoLn+c4B8XYBW5x734BsGIappVXcKQABwPUCO+/FBLQhokw/CZKNMdLdWhnL
Jp1wfo6/Q63RrddIR6j9B2gYzQDULm+gk1bxiBYoH8I4/PdvNyvIm8cKIqr3Fi7IBNSYXHS3UG1d
VSsQI3TE+N1cvNXdu32T8T3BTb/Q3f/wk4zLCBFXQbY/k9TOnbAWbKFmjE65332hjLbGrdyy/WOi
uX/6cX73ZrJElBNCt7/sqc8zZjJwnru5TIMmMqY1V/J35lFzAAbAFPDLpqAxgM5DhWpf7+zwzgGs
8zqxnjK3BfimmQ/OH48i2DOu0f7TgFaYwAQu6BVcrusJYo+pFSgyt1OjlL9lh84AZGlimodWG2r+
//V//h1l5Ka63yvNgev29cvn3a9/+ziuduf4NIZ9NglMZnHKFlespPet/SdoMT4zWJUD97qPpSVZ
uDlZswFRxZalF9ouIJmnCaRvADrz0WNVIkWwVes/p11CHZrLrr8W2fu6qkJqtTcUddT4RmbFtiQ0
opzH1Zxi5vL5Htw7fPluMbi6e2XnZltIgZ/3mnz0TJ2uWE8fT0OSG6opF4YUgIDSD41EtC9ybagI
Ti3dBPAxPnyO0goJMZA9HxBLrAdBvbkL7tcUQkz91ZKp8fUrgdwSc5x1LcCLjFGJ0kkFPmEDZchH
1IC9QKtrZhtX7CMYW0SRaxTsGo5hBrTtAthNAeqWV+910x/e6A5//Sbiw7qJQ97GQ1AxebVh8j83
iwWQbY/zTkkVLz51Ze07N51sHK6UV+GkM1TYuCDbdvdXW3U/oXeXShUZu/Fj3APjHnhfe4BlwgDj
Sv2/GlVJoAJW6E8BTCpYWqAQ8aN4AuYxcsbDWVdxBZAnQyQTMIfbaG6aAti6F1gUk2QBI3XEYnYE
a7EPQ2SyQ3eOajM7Xhcf48LOcWn0mkplCNn1cm4N5ZRG0xgZXZlhzvyN2zGJFQuona+w69zv7q3M
c+6yCq+RlXjx8kW3g3s3fE8MQr9cNSvQGx0X+QYatXeyAonP4fgjds9mwl3AsFjaLC4i+0MmkXjD
U0ulyTxelMWjd7KjP4bZwpmaa5R500Ydn9Mn1lvFFSODZtF2YxXPcfeeGJPjMXk+Dat4qgHCBWRZ
Hk2e8X2CqH//Z39O8fkuGXv7uDVXU5JphaSVZVg39KQuAYbh5gAQZuQJgIjjO71gwV4iRkhjiHFY
k5dA3NljHzAm+2+eACaqSoguwPW1W92Dn1JTlqw5QeL6HVg+xFSXGOspxuC777/ttrbedCtLC4z/
/e7OnTscDlZOdiPgqSQfwtQ0MHctidEsfb1sO5pkR2/impEK4xJjXS7ufM0qAFyTsYpuEowpC0gx
jlEwo0vTKWAWp8xajFQZu7B5zobMc9lih66SXvpwA2UvZKIvAL4nGniC5z2H9VANvOedmhccz/JR
mnjn1QLzXkZVUJWao/ykXF5jJ2X2vKfOcfP5WKbfrCFa1RVM4um6/3L/TrcNkPv7r74Jm3dEnOch
8+uIkIZj4q4O2TDUsZlCiY2z3cZiAlREUsZrej6TB+aWurv3H3R37n/AeJPkhISGmaAgooQIKHjs
NHYTkbmfW7wHuYWC4rxtMWthJmmkMXLF+NWmL8AwoJXfPWhumCAM2TXD1+65ItsSO9iwVq2b/XcC
Rhv47sMHeOraswij5GZFiSWBXb8ZK706GcFi5wVQspMBgjDJvm9Si+2W6fdh2MOQ+ZCsYv4lsSC8
ZMW8xj3vtRL6QGoDmzJjHU24ccgrhq3GtCL1IrliogLnSRyjLCdzZkRCQkCqum8c73QTxm5ns5v/
eKmbJn5uAle6czSl0ATYiBL3faEbdubeR93J7ygS/pvNZMSG2XNMFN9ryRa208mQmW74h1In9o+A
0nPTB+rYZZ7TJrv3fOMAgpwR5TPnCCBfEs4xwi07JuhqOo4f4x54X3sAYotVCkPhTtRFQYOVRQ9X
WxZ2AVXWgxaT0dwqC+xeZfSOccO6iCpZ4s72zCByjQ/rzDEGaXtvF1cfLjuFK3EnmTk7MCO0N0AY
tIU1199aJMvwC5JgMTwOhlWoYcae67TuFTmSGQCJZZomUXvfefOyO9iwSsUE7i5ciZzLZI8+g+7d
lao3JC1U/9qayLSZxCDbNovL1pJHI6/leK+YN4ES1ysbNIMrdtGYJwx0dsz00RXfNXDZ3fI0TMTA
HT4L+RkgCy+1DQ/7p4vVhBAX/2ndqrpn7V5W03merxLLd4i7z/E4E+zyuVP6QTfe17/6u+7Tn/7r
7vbHP0HwlAUeUPiaoPhXB7h/ZLpop+E1cwzYgnpouHmvqIkn4bgwa1amiBVNKwzH0alsIO3kWqjY
nYSQOeLnpgHgV3zh6zdk3706x2U72T1aW+puzZ528zsbuNcXuq3tze6//a+/7/7dL37effblz8O0
jACxpY1URs6OKHEMWdbmPvM6G0MiP9PHZV67AtMPHkIHexltmttLnDVWyekKYAbY2XdD3Y7MkRlY
Rp8LJgVzMx0yFDCE9vUQFnHIWIW5lIlOhZPG1tLOIfF/xnpWcgFNbEkJjrVAQVZS8JWaft4ruqNp
2zmAXyMo0NLdLkMW05p+EJ14KQ3wxL0KOOM8y2xCBHQFPgsgGZd4a22t+6s//w8FkASlzpX8K606
r9MEjE3up01Evi+YWwfcYzt7xH/x/o4C4Bu73Y0HH3WvYGU3j74nLn6SuUpSBX3ihmEeV6Fu3PS/
3d0YMDFN6clVuoIbuT6hZcBGyevLOmCogcBMINLGqmo4vwV3AdKNTe85n8JpsooNswRM2Ya20Qp4
rPGPpF1jBgfMP0LTaL+/lXIRXLa2ul7lBBVbK2jyuUcNgHNsxEhcY5JPeN3PGSbs15I93M6ZoA7X
GH6MaRRoX9D/N+486BZeIT58uJH+nzDuUdYaABSXrvNTV6glGJy3SaTiM2zGpmbdIAnYqg2RmgGM
H/x2j1Dd427xxze6wVplhlsuLHtngaIAlIBJz7X0cxKUcMeefLPZnTwn4QKXq8xb4unsI8Ea88DO
y6a1n1NJcS7IbXWftEPmTnFAk6s8Fe2ZQofO+X6KnMo15fm+WrNxu8c98P95D7iHLHeQizJ3ORgg
ma6zMEBnsBUxurIa/NZgy0IsKGECS+dCJNB49mIDAHWSKLwS+HVRxDUkQNNIKmSKITKNfwhA6lXR
k8WXnXMtvvmmmasaRM45wCDL6M0h1DmnQQJomfHojwb9+VOzEWWxMHa4CgWULfwmHIBGJPgwTE0Z
2AIZgrDSwstuvAeTWhNBKWV/SpdLQ4LoMRmhso2nxJ/MyWaec60wdoLYS67TDNABMWG3VwBDup5B
Iar/HxjFzmNt9Qafpbjwgdm9snBz5Zq2n9mlz3N9p0pQyKiNYMVojzFrunNiPA2cp+0vn/8BbTNq
WD78UfdgZqK7T43Mfdzf22Tsyo56PfbXNJm0xgydmYEc7yduW9f37PBJaOD55RWCz9ggqjKFMdoh
1nD/2W+7fYPDEXWOSxvQsQxonPrgYTf9yafdNkzq7nff5lxffvnT7tEDRFM1ciahCGpTuVxjj0FM
cp/upObGD1hvgM1+bi6egED+bhxOfaDF0QU/2GZfigWShav6ohpoWWKZJxN4AsYAdH3lAdBTXOde
xzmbk+1d2DbHqYE0Db8Aao6YR7W/rFZyLqgGsALVcU/h9j5SwgIWg34U1K3DiK4swQTDzpp5OlDH
zOLN9lUQke7QOOacdAHp5cLUmM+ROW6sEyVxANElcfP20WeSJ34z7n47sAClrkfjQd04TQNclUxZ
W0EDD2AuW3dkjU7mzzb6apOXv+nmLre7J9/+A3FSbA7oszfO5rBJMqYFPmQ5p/xpwMt7txI1ZM4F
AKUTmVhBrk1duY9gERdx7bvRKbdkk94JAK3Yt4xjA3SCslSS6N15yZJ9Zw7k05kwAb6FgOt5Hv5m
/lwYi8qtYTSj9/rI/ua9JCB5L4d9bVPH8IvmntWdYLsEw2IvQZ4hDTJ4xkLm/ufztf4wnxKXWO1I
XBpxERPIldDhMFr0DS2QiVOeJIliVovg/g0wzqXIhjEH4lIGpJGFOgkLPWGKcr/R4b41K3V4DDD+
erubu8d8u49Xg/KLXnolltT9MWJtc34PyJidn7ydtWuoQDHjfkVGrFUjUiOW/4yJSzJFNkxZ6Grt
9t4ynKXF3KW+azwdNMmbgGu2jNokG0Q6oC2YfzQ1x0/GPTDugfekB7BDJXUxwLrHPRDaoO5rjVY9
arduLJC6aLo+blC/9Q26XLs7ZqfCjGAkplncdBma0ZnaiwA5Y/R6YdQJAJr6blkwZUrUb3NR1cCY
6Re5BY2DiQ1zBCsvsYRedMvDPerCYbxgRvaJLdvcQgPK2BV3swEEgWXXIXZx9ZTpaIxPXUMMq7vv
nLdlBArcZB11qbiQxg3Fcqy0SABAyQ6o3ebO/wJ2SKPMUo2hpy+mLwBGFFXH0D968EH3avuAPjmC
EQOM4gY9p50Pb6+TNbnSbX/1OLGBZ7g44gIj+k3GyED3S67vVFkRXDK2b0ibZlsM3XmKfbvTP++2
nv8QQL18/2H3irJE52S5IaAAeMM5xMdOkE5glFJqTUJOALqsHhWxf8acLfjavDF3s7BtSNPEaC93
z1e67jenu90r1vXpZbKK6X8ZuzniyLYYt+OdIVqAyKk8MFN3oruFMbl9V1CvXp+sY8xa9XlsokxD
SXTYfwq/VpxOG5KwI772R4NU7JYGXuYzsVUCupoTAUHJjuW4lI4b0IaYdECV4zRFvN4JJen2qWZy
lng45p4sL8c70CUWprDM9bzyPLhqudBkYzvhV6lqsARQGvK9Xdz1x6fGK+KI49jz9hVjOmu/8Dti
1hyvXGwFZJL9HMghCJNxKbejmaga1nxfMMe8TShDwI7dwPWZgEI7jDK0TyteqtzGAYgyZ2HP3uk/
5oybrxXmqskVqysr3V/85V/hDieoHkB7bPYt8+1S/yzfjPvfjQOvDQG55OryHndqc71Onqlt531L
wEDL3DWcYnphpbv36U+6o8lFmE6OIWPpPWIbwwwLO+s4iT31TvOe5Kc09GQt63kyTQM2fLklouT6
i5ENg5f1p/pUoHtKlusFqa1ey6x6jc2V7Zi7djViscZA8N8yYmf9ndCJYh1rRSgAF6ZWkBdW1hAF
/mZI3RgI+modssGVcFq6eJx7iXkmmGWOxMsv235AjKxxs3o33KT6WZ5fEBt5cUTm6QM2oi433OeC
z5HhAFlq2HC9YK5uEgeLi3WWxAk3CRckPfRAXtHgEZvHKfTrlhbud0fdCxIm9gPmsqopddJuoYBq
x8b7TJesF2wsne1JfGHrYwFe3xv2c0IkrlfMOt74Me6BcQ+8dz0wkCkSrFyhX7SAO9Q1wIUmsgxx
NZoc4WKqawsXK6DKChIHgImjE8AEi/xg5WY3g/FXakT238XQz7o4xpCxeBn2EdMXIyZoLNdcVOf5
K22gLcaD3YbRWgVwyBy+eb3R7aMfpWt3FwHkGAsV5hsw7AFBM6kFRl22PW7RczEmCV5XA67pwGl2
jWmSYdLClEq+iRU3uh9//BGisk+6PYPjyQR1ef2QmKRjJQ5op31zTpYo9diz8x/Cqh1dznb/++lW
YgXthzPe0GBcABSfULpodlu3c6nY9zIPgt1JdtZD4ll027mYmy1snNgEBsMcvGjMYZA1QktovhlU
/+zxN90xTN9oliSVi+PuFmASpwnAA6Ptrl2X4mi/uwPonoVN02DpDryAZTi2BijMzBnszRFB+Gdo
VkGcMo53u4lHxMTdgn1h/MxoVfC4wAai07CAG9bjhJ2Uufjso0fdwQK6fjAQgm9BXVnpAtdlMsqM
vgP12g3Sm1bnWo1TPhuDXyCn7S74AH3NnMtmABBX7txK/JAFzpwK46CF1JWqV3mmW4Yt01Bt4fKX
aZvHb2c73ARkPmPUnr4m65dSdHkdYCCreUQ8o/GZuqfv3boR8GA94sTE8c8QgKuITleskjkVeQA0
yxXMmAZolAZexZwFj+UckxMVixXHYRFEifOUilW+55T+mBmYXWuyRbU3yR6a+BYjCB1jyBxu5XLv
6UJdZC4fwLLswx6tUHLvl3/xH7tdsht3eX4GWrENglgBkfPrhM8eA/oSTJAwCzYoZtGSDanUjiEX
AnLvuyffkZxx+Lo72V3tXnLMKVhMxye8k4x6Y+pkwkx80D0b7jtgt3T/ZDAr09YWSw65uRJ01ObL
v9XATYcaVpHYQgGmb1stg3GbMjSkNgnOaQHdtBmdNZ2q3m3YTN3Lpa7s+yXTU5mw0cn0qe8lJk/G
t2LwhtF7Kxdp2C2Ze+b6DGW2JlnYnAGO48gwFIElmeMj+1BPhmDW+DruZ9lNAZWLURhR613aNsGu
97YAys2oc4KF0azVw8cwyIgPL/xohZJh8/S/E7mBXxnGffr9BlqVP4WpI05uuAmInMd9zvkuKS2m
Dp5u29w3nss2NJdySaXUwliyS7UmZk/pe+reJb6udWSb0uNf4x4Y98D71QODiOyyiC8B5ja2d8jw
Owx4040VTqvFA+mWcrd8xmJvDFEWWtiNGUCGrhqBkZmvGrwkCrggylLoDok0RskGGAOnfIfGws/5
t+K8t9bvIP55o1vC8J6ebSH2C9OFmPAeBuSI2CDjiYxvK92tMvxvYUFhgH45ysKUhasyIGsBK0FS
3bUG8JsUIFtmOzTY04ASr1VFerI9cKsivovhvkIgdxaQOcm1ujOfJ67FQjknAKorQMOQxfgM19jJ
Hu7UITIoHH9hcSkJHIqryrbtIlNxsX8cuRKNlOcpI9gYCVkEgQSfTdUHzn9Ftl3iegYwlQu4uDUU
tJkCa92zl9vd0usfup/9/Gfdg7uPAKbH3auNVzGSFhan9d0JjsO9q3lYzSmMuhmmxNnxum5HDdMA
2XtjIAX0Go4B/bqMO+gOavSnuF2fPfkWAL1piiDMQsUjWpFjjizO6fmV7ukPuCP3VrtPUOC/d3OZ
+QMAMSbQMS1c10akGKyejfL6M06NZSlz3kBPQz4K5vaAUDfqKaBiMEPRdGpYJkixGZ7rDUJMp0fB
eM8g2EqVirCwnEhBaQuyG78muDImVDbrzAoLAKhD5rKMjHPT5BSlKlaWAbaWu4vmX53uDDZWSRZj
DO0L53mBUPXXKrnCZIiKRVX3rFg82cNeBidj7tSMS06AxlyQxbMP/Bxu2enWxgDTFr6Q2KzEXmY7
E3ZpjoD2GZJuZM1jpJkXywFNA4DdkOtgw2WKjLGNAi3vGcICzK72KDKzvRagICdMGE5FgaSfFXxO
8xnH6YL+GgLotx7/ptvANT+w8omfE4zTFl23xmBe6rJkw+OxKgO49CAnmffGDE4zf7yHI8CdYeR/
vduU88zQvvvEnS0ursNaMz/RrqzNQLHr6vdNc11VC9bM06pOkw+5HIXVNS+kkicEc0mi4L63XNoc
XohJNe1ce3i4WQrocr41pi5xaY5s22QUJvI67ZPaM8RLXYMGYwdLvWCZLtY0pEqukAqxVIfAbgDg
MsO2vBuuh3yRazc+eEI2zbnj5NIlO2T+UXni/GS7W/gAtu6jVZg83a6NxZZlPSLMA/fr0r8lgeZv
UQx4w51O5Ygr1qDJOebFYrF21ny1zGISJHTF8js4T/Amje8EaBnByq54H7mxzGvX92716fgx7oFx
D7w/PQCWweVHfNju3h7xU2fdi42t7OC9643FCuPmwi04YyHSeLke+PtSzTkBgu7WGAg+Z6A6xlMt
tRhcY3B4T/YpWm4aOdiW0dWQBXahuwnzdWttle8dh4l7+Xyn25MBNPDcOBkWZ4HYhBmitRLFGPjo
AV2vDO8i604/8Ue8mxghz2tbAUnKffi6xnFAm2UyZGvcXZsBakDzIYD2MQLEA6o2jDSYUCF7BJ7v
7W8mhuo2Uh3PXgIyVGRX1JMOsmlheeJKqeB1/9ZopsJC+uhtHE3WddpRGXmwEbaR3xrDUwLtI/IO
sBMUHiN1MsF1GAx+QgyeQe7YvO7R7dXuF59+FAHcf3z6ptsAAA5pU3cCuHbxxog83+W8Jo9gyKYm
z3HwnnU3sIbGQ11iLHUzL8AyqFGnPInxkTGfXOfc6VL39d5L2MNinGQQD6miETHjG2UUBI47kzvd
vdPJboG+Mp5rBsbuz764F+OhYTfBJSaydBcqq7O5DguYaTHfMnnhdDQ8PbNF5YUBxkrQEk3A+OP8
VYxLHv4dRqeAe71e7wnWFwFnC8R8xqjxucSMep383kPI2jhMx0j3pfFxbm5MUPFale6JHIUVBhgD
3a8yTTmXgJt7YCgAj/yJQe+6M90QsSEwHo9qBMWuZQdEu/m+95TNa67A3i72+vMAAAgISURBVF1t
Pyt5Y83QiFU7q+KCxiCreWjwP11/Qdm6tNcu5bdqGyeACd37ZkjbMtmnubTXhIHq0+sNjQw8QE9Q
6+tVjk4AJBOF69/jcP9Zx1Swc/PRv8o9tYco9zKbtiTAmF2ra5Z5FObZDRxtNdFnIUCWq0a2Q5px
6hwQ/eYE9vA4TFHuExl24y4FUs592nIHTctH/+k/d8t3Pu4un1F7lblkvKbxkrY17lF14Nr4mlfu
n4kSMTauMXTn3JOOQUqDtb4uvTrxo3Vmq3Ta9JTrgcNWoEbRZg8WVjRzxxhgzmtGMwAp0kqZb/0C
X3+YJCHzbz1Xv+/mbMRG+YrsZF2dAzLEc0y/L/sX1zd9YMynY5B1kjmF/vAF2pQH3+Lqh3Vb+ITQ
B+7NFJTxVNZyhRGc+WCpW/3lh5E1Of0D1UkIJ5hcZL25SeKTunLqe5qgZRkxWbvQcQUMr0k4LzA3
SG24yiXbX9f497gHxj3wPvYAm15dP5NxvxxTimuGVWAGxBDXDMZT1+E5MV+yRpcAv0qeqPieSTXM
YEMiJwITMhN1exZxFvhJPudOXI0zgZU78YoLcseMkT3eJHNScIU+3eN/7A5wjVkSzHi7uKb4nLUI
awcdSq7610W7bTLjLtK1oNFrht4VPAkc2Ubryj0pw5kVsWqm6rJwwVMPL/FDykGYhBAXc1PcN+sR
gx83EaDOyhGWHTvEP3klMwmbBYKJ/0hQeO/u7QgEb7wyG64qCaSShIYLA2Of1eaYdsiIwfQpV6Cx
XyEmbgcGaKQhZXGeQqh5AV04M1RVgb8kSeHEIGjafMhx79272/3kZz9LJYrXm2+o2PAM4Eg2I9px
VpqYJcligfbJosqsLs0BtGjnnPWi6AeTL4zxWSBmTNBpnzrecS3SbzIbyxQcn4Rl+vb5FrZMlwwM
C7FU87jWZ6l+MAdLI2UxBLg/28cwHcMachLjy373+Ac06qh0wXWNkBoRjIStgW201JpxRFOROHHs
BEfF0KV3ei20ADpdvgCgtLuC2hNTp+2prAv+rqi4Gl/fK+BYQUsFbKd0eZmJaAiAsh6OifMYIViB
TJ8JqVF1bso4pyoBf4+uaCftnaEdl4zPCaLDl8ruyOjqE40xtGSUYMV4p2Iod2FkzUSdpz9uIPci
GzQD2InLVxeaQJkLqfPX1UezDnBsZYO4D+0f4x9NBKAPz5wfzLnExdmnfEeR4UOD8/msYK8UO3Af
My6HgDw7TvDihqLsuiw7xzCRgnbU/GfD44asWkEbq59tm6OgS9Zjr67d7laQtKkarHU7pgwa7fG1
ecvFMVYG4R/IrAfACbZJQEEfUvbz0uxxzh8wyD2moO8O1VBm6YPZhY9JMljo9jaedl//8BT383k2
O8vcD6smYjG/kqQhSM085j6OsLdTSBbNdjtRGH4Zscylmi9h3domocTD23ItyMv1tFjcgLlaK5Rt
msF9PzT+0vsPl291kmuQ5/J0xbTrZp1yTXBDSVaxG1E/enlEP++QZGQ2KwBbGZFK0KJPYeVGJiMY
BpF1y80hIJf14+gZynnEwy59ud5NkmwVzTubBRt3ga7lzIdsUmTmLMVHfKu1YodvYEdJ3AqIy6aI
Yypp4ul0AWcCZIiz8XFsvY64xuPe9Y3WL+Nf4x4Y98B71wOD7777PoAuGZIuRtzkBr1f4ApSEkJj
c4kxG02h90aw/JWxQSlEr9GESTAWxIWL52ZPuiCYRZeYJo0bWZhXLMymqc0C+Izj6U73KHZ+2L2J
O20fEMPCrytJ94xd6C7XhT+W2wNKvTXXXeviEBwujQFuFRMSA1/r1fVOtJbmWLl80wSDaEwl8/Yi
DIZNXUYM1tqcR2rLGeANmJLRWCCmDh8j8UgKjB52Kwu65SZTHuqFMX22C2ZsD2B1BbNjGa0h7MYQ
N6eGUGC6ikH3scHn71hPFkO5RUaiDJAb4yFAOsLCVUAzVnkfd/O0sXD2P6b7WLCBgTLbdhVW7hUV
JF5R6/UYrazvf/t9d+P2Pdqke3criSu6GnXJmV17yPFkYexfgWRc0mpmcXIzReNOBeSkugFN2Ceu
7kDWh/EcTq6l7yOoC2i8xADvbsDcEU93RrUIjfjsyo0AiUmu5+bNW90+QHNm4odunZgf+3Ck29Z+
anRKbQZ0/BYY721IYE0Gsox0nhfWybyqIa5Px20dZq/erPGXsalEgsQs5XPt+834+l5qf/bhANq+
ZqTLTd+SEBoLlFmW962Ji9GMQHA1czqZoo2N4txuAKwbXJI9p0jLlKC2VyOIU5dwCcZplWQfmSdD
DiZgugRq+VwRRAEDAgUBf67VTZBxbrzm8YcwRm4iZLWStZlrkPEtYKw8iSBFhtR7WTDn90vjzThB
Y+QqszPXYt8Iqpuh7xM2BE6RS/E+9p50jGW3+gx2+ivCuTRAhmcIqyzDKKA7wk3rccKWCsD47TzM
uAjEkr49ImuYmFlqB2++ft49/h9/2x0/fQywW+q2cDWek2Fq7yWO0fXJkW4DGkDF1VbSif1m5qpA
zblQgrrXpcG4NsPospy0savZUcDUWNG69+r7Tqr6rv+mujfIvxyf71Tco99yPuT99qRfptK+DFjt
Kfw7EiQkOzmuhCXo2qylyH7hbZi4S5InIoVin/jItY26Y+LqjpA4UYzYhIsk87a5mA0yFzV8fUz9
WOJazb5Nn/IZFxVd8TKubDLDvoUJLBa1+k5M6Xyo5XX4hooSVqDo75d224x/jXtg3APvTw/8H8aR
KCgA2XNGAAAAAElFTkSuQmCC

------=_NextPart_001_01BF_01D4EA16.D414F3B0
Content-Type: image/png;
	name="image002.png"
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAEcAAABHCAYAAABVsFofAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO
xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACTzSURBVHhe
zXwHeFzVue2a3jSSZtS7ZFluso17L7gAtgHbgA0GUmgvF8ijJS/t4z5uSC5JuBBCCtybYEIxNRib
lhtsDMa4Y4y7ZVzVLau30fSZt/59ZuQmyRYB7ttm0GjmzJmz1/7L+tf+j4xRDnwdQ502yn8ckSAi
/lZEAu0I+zsRDnTyNR90kTCCfo96X6/XATo9whF+hh/SG0wwWhKhNxr4ixV6swMGsxN6kx06UxLA
93X8J//F/veVz8L4z54xGvYh0FGJcGctgh218HecRNRbz7k3wN/ZiFAoAKPBCJMhCn0MrHAoDKuZ
UyMIXf4wjHo9LBYDwlEdvEEgGNbDaDQiwW6B0WRAIET8YITZYkYkaoCPvwsoJpMFOqsLOrMbJlsK
TAnpBNENoz0dJnumAvCfGf0CJ9TVAF/LIQRajiLYegwRbw0iIS+MuhDsxiBCPj86OjxIsoYRifDU
XR0whnxo6ojicJ0OJxqiSLaFkJ/uwNpdrThZ78ENM1MQggUvrmkiEFbcvjALM4aa0dABrNjQii0H
2zBjVDqSHUbsP1qPcaUZmD4qg8cSnagdAY8XkY4qWJKccOhdaK4PExQr7I4EBHkNIV0ijI5sgsXP
OLJgJHgXO/oEJ0hr8DXsga/xAIKdNXSHDoR9dA9/MxDugs/rgUkfQV2rHu9ubYErwYAb52Tg+Q86
8NGuFsybmINbLsvFhsONWLMXtJAoTjU04fLxbryxsQ0FGQ6EzJkEpgIpaW4sWVCIosQILSABVdUd
ePrdWmRkysRSMHSwG3urIvj96pNwpeXCYjXi0We3YNTwLDz4/clY+9FxvLf+I9y6dBwtMoyKk60Y
OzIfeblpaK2voIuKSzppTAm0LictLZMWls3X03vF6jxwgp6T8FR9Al/zQYS6TiHUdpzA1CEcZJzQ
mRkDzEh0WLHjRBRbynQIBHQ4WN6OfeU+fO/qAiQ5E/Da+nIcqArh+KkaTCgxo9OnQ31zJ0oyDDhc
4cG04UG0tLZj0tBEZKYl42j1ATS3+xEMZNK16D5WK5o7WnC0/BSmjsrDJ5+V03L0qGkMYMiADGw7
0ICPdtTiwJEm1Lf5MX3yEKzd6cGzq7/Ad741G5mpLix/ewPe3bgLdywbjYlj8tDR2crFbUaQvmyy
uRCNNCIcqoEfjGFGJ8z2XMa0dOgY9+LjPHA6Kz5Cw47HGDibETUnImpKI+JpMJtdys8lxBrNBvgD
Hry/tU5Zw8yxnBSBO1HTiU+POFB1qhOLpg3A+l0NePi1JkwvTcKsYQbYrWY0D0tDXpoeE0rTYCUI
voAfD1w/EO9vP4VPdjQifXYOwuEwSvIS8P1lI2GzGhicndi4twGfHqjHdxcOR1aaDXZ7E9yuRIQY
o3bsqsfuA1WccAAnqtswqrQETS3t2F12EssWj4XFloCuIAO4BHFO3tveimDDAYJkgSUxiWtu4dxC
sBGcM0ePbmUw2ei3DGiuITBmjUGksx7+io0w8QQ6vRld3jDGDklGSqKZIIVw/ZxCnHjlOA6dqENt
QyIWT0/HgnEWTC7JxNEGE0pyEzC2KBFBWDF9nAluRwSFedkMrAbkplkwb3oBll0RoBUEkO6yIRTV
o3RgEv7jvlzsP9GBcUNTsXH3KQwvToWDVjt7UhGm0RpeeGcf0tOTMGl0ITq62pHgKIXJaMdba/Zj
844jmDZxMK1mALw+xiG9UYETDgfR0chFJWDek7VwWRPhcKXRemxnWY2AdB44zqJ5CDSXoansbzCl
mmBLTIY/4oU3osUMPfNGMBRCMoFZODkZ5adCqK7zYHiBGfcsGoOhuWbMn5KPoM+H8UMj8HFlmzuj
ONGs5+ciTNMBVDboYWDqjkRCnHwInx9h7DIye+l0PKadGYkLKdmIr5mZyiuqW5GcYMHokmSmfANq
ahoJhBU//PY4WPlTrGHMvXPR2B5Cdq4bf35xCyaOHYAFV4yiu1gRNfL7yAh0/GyY9MFodcCWmoVA
ex0trwvmhEK+n3de7DkPHCNTotGZCz0BAbNA24F1CHnbYNaHeLFMySYjU7MFAU765rm5nLyOFwXk
Z+YxLeuxo9yA2iYf44OXcaYLza0eNLUxY7V2od3j4yoGGYNC8HQFCA5X9CKG1WxCEsGxMd07bCak
JNkIlhXuRCsyUuxIczlQXJCKpCQ7jh+twqwxOVhy1UgCZ+ekI3RLg7rusJ5uZbbB5vKi61QlbO4s
WFPoSjo5LvHC4ChKRROj3UHHuGLwH2Oq5jKSq3hDVrT6zAhErWjzckXrvDhU3oQjFU04XtuK2vpO
eHwBWkdUrb781B5y1i/PNX1cCV8zV+OcIfxPrE34o55cSWJpdiqBynGjODcZRTnJGDowHbl56bAy
tjhTU+BITYUzuwCJuQOUq0WiXSRRdDnd+RGmx5hjtNJ6bBmI0j/FFOWLQxEbDtYl4M2PjmHL7gp0
kq0FQ1FaUIhEL6LM9csOOX8kEtEmGnseJ+7yWm8kXnHw2EIg9v0nattRzseGz3W0dD3MtBg70/7Q
AjcWzxmGK6+bjfTBgxFl/IkyVOiiJJK0qJ5GzwHZ6oaBLDPYViFmJFdAhsvVI5v9dH8dKuvaviwO
jDXaBXv9AQXGiOHD4fF0orKiCoMGlSA1LRV79+1HR3s7cnJyeOF6VFdXcwGEFl/cENCC4SgfYcXA
Wzv9aG/3YGxpDuzJLjqBiQSRZqYszkjLO52+L5ytzEkkR274w0f5YQY0+oiRMaco0wYLaX9fw5WU
iAEDinHpzEvx8YaPcfIk0+n116OhsQE7dn6O+fPnM2WaEOCF792zF5deOhNvv/02PGTW8+fNQz2P
27VrN65acCUWXDkf77zzDvlICNOmT0dpaSlefuklOOx23H77bdi6bTtWvfUWcrKzUVtbg9SUVFRU
ViorPHfYrSYU5KbAmZamhYwgvSLazvqOFttLedmj5ejNZJGWZPqifJA/WPMgokOG20wTZdjnsFgs
+PbNN6Gz04MDZWV44P771CTLDh7EnLlzkZ2RoSxBaqQRl4yE3+/DHoIxcOBATJ82FcuXP4uKigoU
FhVhwvgJ6OzoIKgDFPcZPmwYpkydrIA4cuw4igoLkUjWPLikBG63GwP4mblz5uDI4aMYMngQZsyY
geeffwHjxo3FQw89hKeefloB6PV6cZDXY7E5YNe1IzfTDbPDxXKFlCTSQpZPpo8kOkbPhULP4Jik
AiYBpB8LqAobBlQ9ArBbtI9cv2QJxo0di5dffZUm2658/9777sfdd93FibajmpYxefIUVWl/vmsX
Q0IYDU2NOHbkCNOwHSUDi7FqlYeA7cE0gtVIizHS3QoKClQa95EKDB8xEo1NzbRWM0GzoKioEC4X
C00e4Exwqp8OuwOTJk7ESyteUq4nBLKrq4uAj8PS65bgRb6+cvVqchkrS4kUZq4AyFUQDTVTDPAw
JtOSdCSBPYxeLMdOVpygzFPzRuEnfEY6muTQgtf8+QtQXVWJjZs2q9//8sxyrvQKdWG7du/Gnf9y
J1NrEla++SZf86CYVpGclIwNGzZg85bNmD51GimBAZs2fIL6U6dQXlGJ1ZyEhWz14KEyBvow3exy
uoobx0+cwGAG0Z07dvC4clqhn3FpL5qaG+HjuUm/YKOlFBcXE6QXlbXMmDGdFh/hwrUxfrXBlpPJ
Os3JJEPFwM8akW4V9gdJbDkfeVwsODpWtaKbaG5F/5UIp6STMPkG6ytawz/+8T5GjizF4kULsXv3
HtQxtjz91FNooxX5jweURdQwDmzdto3uNZh038HayY/dX3zB1aM1ffaZOq2HVrZ1+3bCf3qY+f6O
nZ9hz66drK4d6PR04YMPP1Tg1TU0oKWlBb985BGUl5crOee1118ja/cysHtQS9Yrw2q2YgXd8k1+
RoZwHYOZU6J+FCKrDzNQhwmyyUIKcD4XVp/p0XKEcerNAk5IBWNxjShPoddF4CbRsrJGWvHyCizu
XIgpkycRmDps+/RTPPHk79XFips98eST3bM9cGA/5CHvmYSUyKBLiOUImMKCJYUraUyxYx1JGdms
uAgnbCSdOHrsmPqYicfV1tSSJWsgyKisrlE/lz/7LIKkFjLKyg6yuG3tPsZpZ+rmecMCDB8Rcqdw
gJxMcZx+WI66doMtxi+E1gvB0nBMpuVI5O/y+vDW2++ox5njzFwmz6VMUARN4aG9q37nc3kIc9Ve
j6t6fBojkMLIo7TeCOOZnZRCJifDQBcXl48wXUssFKsT948DI8es+eCDs67LlSRlhi5mNdSe6FYh
0gkVjPvDcxQ4MX4jLkCbVA+ZlI0VudHQczqXC4x5oLb6cWBkUpygxmJplfIQcPi+JnXK+c5k0LHf
YyAJEHG2LdakAKJliSWHw+L22mfj338uF5ezCbcSow2RwYvFiOWE+FM+JfVaT6NXsUuuVyfVmtQj
LB3kITqvjbWNUXTdM0Zs3U8Dw+NE+jzTYsTnFSj8Gbcg9R3yT2EdP4s8l5JD3tR+ygIpcOji8lkB
KM6o1bXw9Tho8WU7EyCJYXZmO/mMACJuJZaj3EoSTS+jdyVQuRInIsCISymAqMnYzKTl5yMdtxgB
UFvV0y4koMhrYjVx95LjVGxTLhYHJz4lrWSIP5QLMTHoaLFxy1MA8SHHGDl5OYW8Fr8ODWJtyPVK
KJBjVZbiIyJpP0iWjp6tRj7Xu+UYLZRiKQQpl9IAklW3WWg54mpnjNNT4qGqEDztRgKKQY4XNxJ3
6LYeAUabrGY9Gpixj3KVBRzNnXS6sFZzCSDCt1Tw1oS3KN1KGK6cK0KiKvHpXLeyMBQkO81a/JJA
rAAKMOb4lVv123J0Oq4+Aeq2GrEiPhLIc8wibvcwJDAGeLFGMd/YFZrIjZKdTrSTSfu56yDrlEEK
X9/InYlYrJCzWRl8U1gxC5hCCLtUPDg9UpOTmQU7EOihNLAQfL/Enl6GURWgBJSkVrZ+hCxGpGAm
QH3tTPVuOaxaFddRQVTcSnMxiwhHsVUW0rV40SIUsyQQEmYgeO3kLY/++79j2c03o4jE7xWm/E2b
t2L6lMm48VvfxsnaWrz44ov4V9L8VIIhNF8s4gSJ3so33lAXe/8PfkCZIQ9WlihiJSKu/ZHUYN6C
BZg4eTLFdStdxQQvCefaNe9jzdo1eOCeO3HJ6NF8zavcy2azUdo1M5u+i7XvvEnbZFbj66IehGg9
US5alOcVa+q/5Ygria4j4BAUla14QcoVYmfLysrCrbfeilJW1gcPHEBba4u6OJPJpOqhu1hKiMk3
N7fitttvxy233Y7fP/GEcjv5XD5LhaNHjyKbhaPUakLi9pI83rBsGUZecgkZeDXa2lpV8JRzzmE9
dctttylG3VB/CqUsL6RMEEBzMrNQShY9buIkdXU1rOSPkxslkZULMJJhpYBVViMVvmS9PoDpM+ao
bxBAJEvR5GUHUp6r9BtDRwhaOwtGKTbvuPUWfMG6yUwAO2g9v/3t45g6bRquvPpqZGVlsqqegU/J
hB8hs01iEdnc3Iz8/Hz8nBbkZr30b7/4Ba5bupRlQ1BNXoje//3XB7F961Y1+fr6elVvyVi+/Bm8
8PzzeORXv8KSpdezgl+Ahx/+Bf763HNYwVpqDAH705/+hNdeeQUtHZ1IJHE1UwmIhDVgpBKXLCg2
05cE13u2kgDMTTapq0TMEv1YMpbJxPIhxnLjQpSYbz4txepkscqJ7Nu9C8dOlGMV66p77rsPi665
Vk3u9ddeo2zaiqz0dFWty4WJm1VTZpCSQGovF/UWyU6SojNZ2RfwvGL6AmY8PkhJYbMnKCbexNi1
b/8+6tgnQapOxt2mWQ7LmfKqKvXcnZ3MmCMpn6AQIEnlkgi0qvpLuJWyFO5CBOmbYVbpIozLdq3D
fnYql0JTYs4Tv3tSmb5MQLSXppZWvEcJQ1xh+syZymre5e8pDKwmghmJBdAl1y/FwOKBSsp4/dXX
VOyZQY0nncD86Cc/6S4zZlMfam/TJr5o4UJcSb2nZNAgvEHAX6BcIYHeyO1iRVo5JCvGh2Cgsp8q
hegNtCLZs9cp3vRlUrmQLYIa4i6hI78U3lPc3Au0Evlwd9qVLxeK38aL3rB+PQtEj3I7byf3cjmm
Tp+GEuotMqSqnkmQ3mDQlVVTvIXfsfT6G+DnNvLhw4dZzP4DVZVVcDK7iRazm1JHU1OTOt7v96pA
rCYuMVCaDugidXTBTi6QWLOm6J2fSZX8Kj5AyzE7U2FNy0Pjwc2ci0QOVqO9jD5JoMQYKQGiAR9T
H7siaBncloj3TqjJSVYQt/jt44/jCwZARcZYfYvrLFx8jfranazAJcDeyAy2evVbypoNBFXGH1is
bqBsIZymsbGJat8wFZzFzV5iVb118xYFpIeAiwQi489/+QuVgN1YuXKlimsDCgtoceWaAtgDy1Ak
kORVp5Q7cqWgn7GHJYRiTb1HnV7BkSrcYKGcGOE2bf1hWHhimzOFVtnYHeVVzOE/F9W5SZMmIjMz
Q33dHq74nXffhUtnzcZfGTz/+7338NMHH8R4ilJLb7geW7ds7Z5DPSUICcBJdDexDItFrIPuy7gy
avQYKgBaAfz5zp2KA8mwENhD+/djy6ZNmDhpEq666moG4D+y8Ayqjg4ZcVKpGQVJoqpVaIHtDehs
rFbv69mlIdznS1gOs5JkKhZ3Zpq1ibWJnhqJgB+P8VZOxMRjsimE//JXv0aAjNPLjPLXZ5dj2Y03
Kma8c8dneI/uMnbcODWRm2g9hw4dgjNR2ycSJS+RFiHgiHxh4feIIihWIulfNCDhOQ///OfdliPx
qL6uDh+uW4c5l12G7/K4p//rvxQ4krpj6Jw951jwVaxbYo1U4tw+7itd9Vl4Ko7DPXADEZZ0LpW6
th+lfW8ZJ3nfAw8gJSVFrboQNum9qauuxK6du9REj5HHZHEy//33vytOE6bpyzG/ZOqVz1SRywg4
kr2SuLfU3NxCK3iKBNCq9B65+hCTwnF+9gVmoDfpSpLh3PzO9yi+l1G/FssS6dXC4+69/14+T8D+
vXth4cL5mZ3UHr88JChLFc75yG6rxM/uyfRgPr2DQ2QN3HeOhr2qQIzKgxcrQle8tmqkJryJpn3u
sDMbBGVLlKYrRDGVE5FUvPb99+FgsE1LS8fWGH9Jz8hEAvVgSS6SxfzUWPbt3acIYVjtibEG4gQT
aWleKoItzU2KjYulNTFG7T/0Ljcdwe9IU/Fx/UfrNcPhwyYxMjZ/VYup/4nlaA/VUREnbf0BR6QK
KR8iFNWVnqNYMrutHOxMYCEnw0ruIBlCygajWYgi3Y/HGMmFhPuINagNQbpFAmOIy+1SMUFqtMzM
TJX6VWErk4lV5xaCn5aehpRwSozRasJUkAAZmHYdJJASJ4QQSlaz02LEsgRUsaBUbg2JGwoFUamb
Q9ixxSzFqmg/WhAWCiiZKi7i9YBNH1W58Bz24UXCTMsx2UJOZKfcKIVcfGgrcoa8EHuuZAYR6GMy
hdqZlNcYwwTM+O/yXIvOMT3nrM/HPhMTuyRrabWQTC6226m+53TG0aryszOQhQvnJD9TdbwkNB6v
ro3lkZ5dI72NXt1Kz2YBaVAM+RvO0HQMbCxiwIzpOXKdsQRyzvm1i+sGTc1dnF58X8twcTlCE7E4
aZEc5GNqcWWvXY7R9Br1nK+ZaWliJWKJ5y5KfE9e4azpGd1DNhFdTtaJMV1Icyt2W0hDpqoCeh59
VOVWTc/xaFW5VnxKScHOLrZ1yJDyX3DqFsZV5DttRWdaVPdzBYSm7MkE1ET5XNxE3EHKWj3dQCxK
iJ12nPZQlhM7fzyQam9paJxvM9qkbdwrT2XfT5jxU31erRLBtrG5UpSH/oKjp8Cu55awigXiBiJb
8KeBGSY7M4mZQMdMcHp54pONKmnz/Ee3m8WsQGQFn69D2zIh8LJZZyehFGYsdEDkiADJmkgTmhXG
AmncPbvd5/R36ZiSusETI4y5m+zSWrkF0+nXQNHqKsYhRwbn6Ow/ODoGKyMbCriEMYlUtjbImNkR
VcSdw1T2xtS0aCtxlgvF65gzABIglJLHCSoWGw0RGPYeM2BLYWln9hGCOIU8SPSWQ2WH8PHHHzNr
7SFYXcqNZeJxgM/8qYGhWZTEMxKF7r1yJbzx+nPTnCp1K+9WCUBqLFpOYo5yrX5bjnxAb3RQ0xGO
o4ns4lYmTmRISRYyU2zd4IgraHFCJEsJtgJCDBDhNTFwJJtJ5vFyW0cy0g/+z49I/6eq9x977DES
xk9xH7eUr73uWiygDCG7m//xm99gD0sFc0wNiIvrZwOlAaQs54wiW9wnKyURJYVuxdyVuimLzYNE
abAmZnPReu9V7r22UuDYCUY2J8qMJXFCUGdJMXJEPvJzXNh5lDKC/GOoEWD00tahlADNQsSsdVxN
oepK+Sdv8dFtCosG4NHHH2N5MFplnV//+tdY9/4aZe4/+uEPccNNy3AbhTFJ/T9/+GH8lsB9wm1k
GUIPpOCMb9ecBkkL2t3bODGXkgamkYPSeY20lpheLVqOtO8amXD6Gn2CY5AW1IQC+DyHNJlUdULp
kMwaakhJDmybj6u4I3WXZJTTAVPbCdCzbUV2E/XUguS9pvomJXAJMFJOyHiINdfLL7+seJAUnCJZ
SDHaWN+AH//0pxg8ZAh+8rOfURWsopvthY3HKQAU+OJCktG0XYfu7+fzcMzdc9PZnVHkYleaX+00
CEhSoztSh7B27N2l1EL0hZyOvTkmex783i+0uCOrJo2T7KWbPqUUaz7cg89PtKkLU9bBNyOs2sV8
xXpkhYWFyq6A9N9IMbmAymAcmGdYDz1P9U5cTQrDVkofKSxim8imH3v0UWVVPyJAohfdeffdSjWs
pAKQnJykYpMsgNqOiWWzuMtJTAkSvEx3Ai4ZzM51EsAwO1cVmY1K+1wYiZmj2WrLmNrH6BMc4SYG
UzIRThY9UAlFEpR1dra3Ti7FhEvyCc4+slcWpwyasqKyA6m2TmhhUkfphNnSz5spQUyYMB63UDuW
ITLH3999V3VfyHGjxoymlpyDdWvXqpoqa/QoVUeNoNQxl/0+86+8Es9xL1y0aicbwePgaG6kaTXq
ufDgWHofPyybbbmF7EEW5iebicy8dH290QpbclGfWs4FLUdFd52V7aolpOdHVUCWR4h3vbjyXbh8
7kh8uK0CR+rYHkvrUHtHIkPKksv2K/9JkRnUsWWO2yCq8YhgSLpevWoVMimsz5g1i303RayrTBTF
a1RNJa73G2rQr7H353cU5MeNH692KgayGcq5iTUW07wSzGJWo3YV5LnSc9iuy+ep1I2nj8tDfm4S
Wr0BtWCKYRL4hIyRWia+wOjbcgQcRnOTpYBfWM3fQuyF4S1Bvjbes8DO9VlDccPO43jspU9ZHPKe
Bdns5z+1Nat2LaSCibCR2w/Zkk0ml5HRyl0KaRuZMGEi8rgFI4LVMQplb7FdRGqiLEogEn8WUAp9
+qmnqf9swXxmrxJ2dolLSbuLFJ+SmCTOdO9+yhWKaxOkuROKcOnEAnRxcWTLVydbylw4HTNvUu70
Cwbji7IcOUiv5x6QKYulxF66a6f6cl9Ij6QMNxbMH4Vte2uxbmcFY0RYbb1KcGauVDFDUqcKzrJb
GpM5m6kvH2U72+hRoxXH+evy5RhEGfW2O/6X6vwSy6pkS1xJyWAMpKU998wzSguSyly+W5i0RRJA
zGLELSXuSBAWq8kjr1k0ZxAVQqoBHvb+SfnGrCmcze4aCCtdqq9qPG5QF7QczbV4s4apmDeK7FQu
BbanhtjjJzdZjBqTj+/dMAH7jzXw7hmaO31KiJdK3bxQAy9YTNpLCSPeL3OYOpAq/HicbJkcO34M
29nk9P177lEimTRZdrLD1MfvuHbJdXj8scfZRPk56ihwiaAvQEuWkoCvgJFYx+sM0EqkmfvHt07B
5LF57CJlozl5l541WSTEPh+LC+4BVyop5mLGRYGjADJwR9NcikDXVgponehid7q3tQ0O+vaMWYPw
cFsXfvzkOrR5/OqmM5mAci+h6zHNxCP1E7d5q6urVE1VSTF908aNmMcu0pGXjML27dvU9o2XiuKD
TN/SUTpt5gxOzoj1VP02UV49xR7BJJEpyJm6Yw6vz8/fpVng3mUTMHtqMTkZX5NYo7o7uEgMws40
3miSWHAxuKhjLhocYXcWxxgEOsvRXr2ZK0ctJX0QfO01MATqMO/yUq50CA/958cKILnJsNuCYj3E
leQqH677QLmbxCHZbfjk448ogCXCSrm0g7FINvVkQi1UBF9+9RWs/XAdihmwR44cqcBRZQJBj/cl
SwwWtc/BBoe7lozDtVcMo8ZDpsyaKTlrMLrqjsHTcARpgy5HysCFfeo356LWD3DEvUxwpFyBzlPV
8DQf5wu8mayrk34eZDwwYsFlg5Wi99B/buBOo+xOau0hYvoSkGVn9E9/+AN3KZcqla6ZZUSgI8Rj
eZ/nOUNyy7Chg3HH9/4Fcy+7HE//8Q/cvNuvVD9xV4kZQhukn1nuh7ibwNx49XCkZibyNiUKdCwP
Ah72J3YyeCflIa3kWqXf9Gf0Cxw5sfCelIHXIVy2gitykK6WzJLCpTpGWYZh/qxiKnwG/Oovm3l3
TJsqISRIC0jSBbpu/ceqA+NvK99Uk9zCztIKbquIOC8WI/LnMPYhFzMzZXMbeQT3w1e/uRKrmMlk
h9NGFxPrCfG8Enzlbpof3DwRCy8fhtQMJ+/LYKVHF5JNKW/9IVic2cgYeiNMvJWxv6Pf4MgXWByF
SClezKC8gm5VS+qQzudeBEUjoUo4f3YxEih3/vnNz3mfFG+OZTwwSfAlaF6u6jp2hl577TX4Httx
r5h3BffFT6ombhnSdZFOCTU+nuaet+y719SeVERTEqE/JnaVsL6796YJuGL2IG4b8X5PJWZJhmS8
493IFmcGUgcugjNjbH9x6W/MOfv8dtcI+vFNqDv4Kl3sKKl4qtq2CVAaCBvCmDujgA0CVhT/w4W3
NnzBzMGNQa5q3C1+xoC7d98+dRuANGlLu0p8SB21ZfMm1eP8t9dfV7080oaoRDHZceWBl40vxHcW
kT3PHIQgyWdA0hWjsGTASKBNXY+raD6c6V8OmH4G5PPBT0gbRZPVoe7Aq8xeh1WqlOI0xAbr5rCH
N6emIjttHAbkJePV9w+irLxBWxHGC+E6T5HgrV61WoEje+WyhyX9xNI6Io3cldy2Ua7MyYvqKDEm
KzUBi2aU4EbeTzViRA7aeO+Wkmqkc0yO473rFt4F7Cq4HI70MX3uhV/InL6UW515Umf6JYo3nDzw
CjobylSrioH6c5TVenNHFxyJBnz32lIUZCfRzXZh16E6pmoSs9hJaslp/vbGyh6vM36MACPjEt47
9a2rRmDxZcPgdDt475ewXwFF3E36/ALUaIrgLpgHe2rpheZ+wff/aXDkG+zuEuSPuwc1u59BZ/0B
xh/Kn5IZSE3lRrIApYvZU3IwqNCFZ1ftxZqtx3mTrNYx0cPWdvdFx0VYt9OKsUOzcP+3J2LsqHz4
aSVdLK5lg062nqLcspYndtcguBkLLQn9D749IfWVgCMnlvI/f9y9OFX2Bpp5s2zA10KLYk8hd0wl
lbdxQy4t1YAf3jIW40uz8MRL23G0qkW91xNIcWDyMxLxHbrQDVdKmk5W95oqhUJqN9FxSCMMFMlt
7qFILb6m3+m6L/P5ysCRL5F+nszhN8KeMlS5mbeV9Rb1HZEipWr3cm9aUvqsiVkoyb8Cj72wHRt2
VvKGMW7AnXOVkt0G5bvxb3fOwBjeW25lNvIrQS3WrSrCJ/8GhlTXyXmzGHh5s30f7SQX9KEeDvhK
wVEWQCASs8cSoIGo2fW8siK5Z1vHm/VFyxDeYzbx1umCBDxy70ysXPsFnntnL042aj09Mmy8bWkh
g+7/vmkiCgbwlh/5exZqpyPWcicWQ6BtrqFIGXC1liljtx98GRB6+8xXDo4CiP5v4h/gyBl9K+XI
wagrWwV/Ww11IbawyPawBFgy2FTePH/zwlLGohT8bsU27DlSj7x0J+5YPEqRukzeBi0ybJigqv1Q
1bDEm3J5u5MrbzacmROYIZO/SjzOOtfXAk78G0zWZMaBy6i6FaLhi3fRWrWRdxAmM6PZlHt0shaz
84aNWVOKlLtt/bySwn0yrpk/HEmpTnh424/EF7V3JjsGJHb2lGHUY2ayJChWit7XOb5WcOJulpA2
TP0JF5urEM3HP+Ak2wkShS9mMz8lTAvrrKn8KwNDB2XCyg6sBBeBkTStbtqgK/IvrciNuK7CKxSp
M39F2ehCwH7t4MQvwJKQgYxhS+ha6Wit3oiupjIG0yS1kS997dLCn5go93kxvjB4i0gv1iJ/ecWc
kMcSYDySsqd85UH3G8tWF1oJmbC7aBbdLA/N5R+io45365GjROI3u1FmCPP3MP/ujomqYSTspwow
kjfJT+HPYRc6/Vf+/jdmOWdeuY1SZVZiruJG7XXbEPTSzRif7GkF8Dbxhv7aMiTlDYczazKF/Mv4
nqY9f9PjfwQcmaSe95GmD1lKC0lES+V69Qc3/K38wxvydzMcbrrQVMaYBd80Ht9ctrqYmUmQNVgS
0Fr5MbwtFXzuZDG7hMRuzsV8/Gs95n/Mcs6cVWLWVKZrNiwY1nNPacz/F8DI9f0/9FNEXjIZw9UA
AAAASUVORK5CYII=

------=_NextPart_001_01BF_01D4EA16.D414F3B0--

------=_NextPart_000_01BE_01D4EA16.D414CCA0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU+zCCBDYw
ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy
dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ
QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha
MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg
RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e
mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe
dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr
TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE
XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV
NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk
cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0
IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7
rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU
LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD
yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIFLjCC
BBagAwIBAgIRAMePYYr9d+THm0Kodx0QQxEwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT
D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTkwMjE5MDAwMDAwWhcNMjAwMjE5MjM1OTU5WjAm
MSQwIgYJKoZIhvcNAQkBFhVyb2JlcnQubGVtYnJlZUBzZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCrUb1e6sP7mQHKxyuvLRgHWUpzStgggreamgOU0g+/P7kwDCrSOWPrv9Oy
3tzBnwVg/KtNnvzJT+CPk4NIoewQBn21kShB66uo+Wj7bUADQvuvdsL9pmRfWy8KhuvS1aO9frTT
1eqkS8g3bG/2gumaIxL5izC7RhZ+4k7KkMMISbYcBra1fvOpYKiXuDLBVNBuZYwnae7HlTuhP5oo
KnkElLlANssxxMvXH2vHUIDxCg3ew9ZRzydiIIYhSCabjAiFN8K9pY0013uwzxVrI4DFwXPjm0+l
K31iHIGcICf4VpoSHKNZ6JDSzNibBYcrOaYd5DS/iEADelijWi4CzDQ1AgMBAAGjggHkMIIB4DAf
BgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU2Chtl8BkfGTm3+Y342HY
HpjNDicwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQG
CysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBABgNVHSAEOTA3MDUGDCsGAQQBsjEBAgEB
ATAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBaBgNVHR8EUzBRME+gTaBL
hklodHRwOi8vY3JsLnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3JsMIGKBggrBgEFBQcBAQR+MHwwVQYIKwYBBQUHMAKGSWh0dHA6Ly9j
cnQuc2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h
aWxDQS5jcnQwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29tMCAGA1UdEQQZMBeB
FXJvYmVydC5sZW1icmVlQHNlLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEArOIvrlEhqSyz1wgEQfLx
bbN+vTCt5+5gN0vDLib4sbt0kg8eMCRVauGbyOwDcL8Haq2vswAJZhT8VCQ6iWqeiideE9n6gBgG
qq6flOjAgeVFRbu0P1m6F0ZCGoVl0782oE8JiRXUXT6lXDulBFZgnVl3KJEDV5h1N8XvmCLyhmhd
m3p3dSGUS2BM5acOsjr6V5OxB6UsNneiNH6u6M5ms3f2LzTJ1+NT5jQD3VPY0Vq/gDTpOyU1qUas
JnRMv2RefUxklaaLLq4rnpth1Mk4AN+uajHTcjBhWAIffgaQL/sENpn3QBnNbWW3/t/kEU58BtIh
JXrtKkIrFd0dcAZ2EDCCBXcwggRfoAMCAQICEBPqKHBb9OztDDZjCYBhQzYwDQYJKoZIhvcNAQEM
BQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVz
dCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGIMQswCQYDVQQGEwJVUzETMBEGA1UE
CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJV
U1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIASZRc2DsPbCLPQrFcNdu3NJ9NMrVCD
YeKqIE0JLWQJ3M6Jn8w9qez2z8Hc8dOx1ns3KBErR9o5xrw6GbRfpr19naNjQrZ28qk7K5H44m/Q
7BYgkAk+4uh0yRi0kdRiZNt/owbxiBhqkCI8vP4T8IcUe/bkH47U5FHGEWdGCFHLhhRUP7wz/n5s
nP8WnRi9UY41pqdmyHJn2yFmsdSbeAPAUDrozPDcvJ5M/q8FljUfV1q3/875PbcstvZU3cjnEjpN
rkyKt1yatLcgPcp/IjSufjtoZgFE5wFORlObM2D3lL5TN5BzQ/Myw1Pv26r+dE5px2uMYJPexMcM
3+EyrsyTO1F4lWeL7j1W/gzQaQ8bD/MlJmszbfduR/pzQ+V+DqVmsSl8MoRjVYnEDcGTVDAZE6zT
fTen6106bDVc20HXEtqpSQvf2ICKCZNijrVmzyWIzYS4sT+kOQ/ZAp7rEkyVfPNrBaleFoPMuGfi
6BOdzFuC00yz7Vv/3uVzrCM7LQC/NVV0CUnYSVgaf5I25lGSDvMmfRxNF7zJ7EMm0L9BX0CpRET0
medXh55QH1dUqD79dGMvsVBlCeZYQi5DGky08CVHWfoEHpPUJkZKUIGy3r54t/xnFeHJV4QeD2PW
6WK61l9VLupcxigIBCU5uA4rqfJMlxwHPw1S9e3vL4IPAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAU
rb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1Ud
DwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7
MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5j
cmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29t
MA0GCSqGSIb3DQEBDAUAA4IBAQCTZfY3g5UPXsOCHB/Wd+c8isCqCfDpCybx4MJqdaHHecm5UmDI
KRIO8K0D1gnEdt/lpoGVp0bagleplZLFto8DImwzd8F7MhduB85aFEE6BSQb9hQGO6glJA67zCp1
3blwQT980GM2IQcfRv9gpJHhZ7zeH34ZFMljZ5HqZwdrtI+LwG5DfcOhgGyyHrxThX3ckKGkvC3v
RnJXNQW/u0a7bm03mbb/I5KRxm5A+I8pVupf1V8UU6zwT2Hq9yLMp1YL4rg0HybZexkFaD+6PNQ4
BqLT5o8O47RxbUBCxYS0QJUr9GWgSHn2HYFjlp1PdeD4fOSOqdHyrYqzjMchzcLvMIIGEDCCA/ig
AwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF
UlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwHhcNMTgxMTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj
dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQK
Qf/e+Ua56NY75tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6n
BEibivHbSuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHd
JDfqB6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC
0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz6OX2
ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5v1qqK0rP
VIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNVHQ8BAf8EBAMC
AYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYD
VR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNv
bS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgw
PwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVz
dENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B
AQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfXehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFu
SUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnC
LwRfCX6iLPvGlh9j30lKzcT+mLO1NLGWMeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/X
fdJ5jR3YCq8H0OPZkNoVkDQ5CSSF8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQS
qXh3TbjugGnG+d9yZX3lB8bwc/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6l
DFqkXVsp+3KyLTZGXq6F2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhA
mtMGquITn/2fORdsNmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE1
9GUi8K8plBNKcIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5
ssebmHQREJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14AC
HuVvJsmzNicxggRNMIIESQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w
PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp
bCBDQQIRAMePYYr9d+THm0Kodx0QQxEwCQYFKw4DAhoFAKCCAnUwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDAzMTAxNDQ2WjAjBgkqhkiG9w0BCQQxFgQUSJTE
NbYAC8DYZB2xqV1W+hGudKIwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCgYIKoZI
hvcNAwcwCwYJYIZIAWUDBAEWMA4GCCqGSIb3DQMCAgIAgDALBglghkgBZQMEAQIwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgb0G
CSsGAQQBgjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQD
EzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR
AMePYYr9d+THm0Kodx0QQxEwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEb
MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9T
ZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv
biBhbmQgU2VjdXJlIEVtYWlsIENBAhEAx49hiv135MebQqh3HRBDETANBgkqhkiG9w0BAQEFAASC
AQAs58NlwgI9VjsQCOSW2WNEo5yPAKnTm9NkrkeyyqgYQcVBSffcuyLO9XD3f2JQGpXjqj0i0b2R
L53Mn1e3N9TbKZlKBgliSr31hJnK9p9nvlT7ElBm007+LUIkXII9jZagPREh48hjyL/8wzWbmmI0
+iqxUkShonJ15t0TxMrOM21DnKahesyUCIfN3rrrPa0IYxH4S4e7+1HtFQdaFnVWhK2dPHQ1Fmyt
G7eIs4iWllQNTUXUVTTiezlCe6RNhY5c3VqdzDpsR4Y54QnCKbkHnRflrC/L9lNi8pf00kb2+nDS
EvMDvlYvps3AYVJybrMGuWbLQduxtQz5MrUYyu09AAAAAAAA

------=_NextPart_000_01BE_01D4EA16.D414CCA0--


From nobody Sun Apr  7 23:35:33 2019
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 0FB68120161 for ; Sun,  7 Apr 2019 23:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.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 1zFJEQARm10P for ; Sun,  7 Apr 2019 23:35:29 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2DF1200FC for ; Sun,  7 Apr 2019 23:35:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FTkSRmklmmBDFtMyrGrjL6FZsdVBxYf4ymYCbrIJKz8=; b=NuRwcLWotzW8WN85UL92Nkow7T7C/LXhQda0RQt2rBldVkM6RLdiidB62j1GoVqc+FY+ySAkT0ldFk3EurpzPT9MoUcDlA66Fsy2h/oLdt6uoC+28JCQwoPqGXDO8V4LZWJwSFGeBT8FtatXmdX5sJ24cP6xRXawNK09zher94s=
Received: from VI1P18901CA0012.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::22) by DB6P18901MB0104.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:27::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 06:35:26 +0000
Received: from HE1EUR02FT018.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::206) by VI1P18901CA0012.outlook.office365.com (2603:10a6:801::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16 via Frontend Transport; Mon, 8 Apr 2019 06:35:26 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT018.mail.protection.outlook.com (10.152.10.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1771.16 via Frontend Transport; Mon, 8 Apr 2019 06:35:26 +0000
Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 8 Apr 2019 08:35:25 +0200
To: 
References: 
From: Ludwig Seitz 
Message-ID: <3d290fc5-7120-d40d-8513-7903702fd364@ri.se>
Date: Mon, 8 Apr 2019 08:35:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070409050900020000080906"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(39850400004)(396003)(376002)(346002)(2980300002)(199004)(189003)(104016004)(77096007)(6916009)(74482002)(16526019)(22746008)(31686004)(40036005)(36756003)(22756006)(5000100001)(64126003)(26005)(76176011)(386003)(5024004)(97736004)(53546011)(186003)(2906002)(478600001)(966005)(65806001)(65956001)(14444005)(229853002)(2351001)(6306002)(106466001)(53936002)(6246003)(3846002)(44832011)(8936002)(336012)(305945005)(71190400001)(86362001)(446003)(476003)(126002)(7736002)(11346002)(2616005)(69596002)(31696002)(486006)(16576012)(316002)(568964002)(16586007)(106002)(81166006)(8676002)(84326002)(235185007)(81156014)(58126008)(68736007)(6666004)(356004)(5660300002)(65826007)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0104; H:mail.ri.se; FPR:; SPF:Pass;  LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 345911d7-3483-4e96-f16c-08d6bbec62af
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:DB6P18901MB0104; 
X-MS-TrafficTypeDiagnostic: DB6P18901MB0104:
X-Microsoft-Antispam-PRVS: 
X-Forefront-PRVS: 0001227049
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: LNNh/j1FA+nZbidkDlL1muJMGTfX/xZjm7d5/fjQDeefDmU0KJ08pXYRijq1K/AoKeTRbXRtdmuHWwSD/FQ9sv5afdaTZ/rvsce9qe29Ia8p+rA2vwt3z3IDpUrMMDq06YI8Ya9pOfW3dt8CmfeQnOweEb2F+fV6l7aEd7mer4qMVWkKb7N3xx+C4OC+UWvZIIZKJ2LgLt+J1w5NMU0I+2orNMVnGmQtDEml9V2xooy0Dlqp2FSsvK2uzPPEDbt5pB5Ff6np6k+meswVO9NwXfSL5uSL0/B9ngRPI8Rn+LegL4+/FnEVcIFkjrdet31gTdx57D0zqplmun8bomQBfW3w5TvH+8P9dRGHuSxsOhJ8vKPnPcjbzAc1ckRvOXu5Y4SV/YA4G4L/yOu/S3tqtgiKw9rO83vCpJYl3kPBYQ0=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2019 06:35:26.1147 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 345911d7-3483-4e96-f16c-08d6bbec62af
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197];  Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0104
Archived-At: 
Subject: Re: [OAUTH-WG] Question regarding RFC 7800
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, 08 Apr 2019 06:35:32 -0000

--------------ms070409050900020000080906
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 03/04/2019 12:14, Robert Lembree wrote:
> Hello folks,
>=20
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 What is the status of RF=
C 7800?=A0 We=92re finding the need=20
> for this, and wonder what we might be able to do to help move this alon=
g?
>=20
> Regards,
>=20
> rob
>=20


If I may be so bold to drop a shameless plug for the ACE WG here [1]. As =

you are working with Schneider Electric, the work in ACE (based on=20
OAuth, but for Contrained Environments) might be more relevant for you.

We have adopted a constrained profile of RFC 7800 (among other things):
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/


Regards,

Ludwig


[1] https://datatracker.ietf.org/group/ace/documents/

--=20
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51


--------------ms070409050900020000080906
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
DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG
A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD
bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV
BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC
MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3
DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF
v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi
0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf
itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P
5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC
AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5
tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB
DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu
Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg
PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz
MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy
MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw
AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh
djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T
v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt
9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA
4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS
Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh
bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6
FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8
ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6
pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3
OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC
Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE
CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx
MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs
aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/
LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ
pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10
aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/
I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/
aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh
Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB
LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB
Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD
6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB
o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1
c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw
BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw
czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC
AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh
LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0
LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs
aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z
/+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj
pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8
vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD
tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe
MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b
ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB
11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA
3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z
z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO
/lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB
MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp
YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg
ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQwODA2
MzUxMlowLwYJKoZIhvcNAQkEMSIEIG0oWOuZlQnYNDSkexZ1RYRL+eNk2/gdx4R1h4m/KI78
MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh
MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw
awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy
YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C
MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwDQYJKoZIhvcNAQEBBQAEggEAQQ25q7q6/SO0oGc7I94XHu0SU1godA7V/oN4lsCebspX
4qohcAtPYqhBay+XtrXYbIQMW6HGaTTpdFcL3xQxfILjWC1rK3T/nM427BN9G1HdCCc/5ot6
r4UDbCkjUBRhywp6xV5BU9yPas9sJvq/z+//aaURMCvqejAer+uzQjqMCNIO9Qtj3B72BcS3
XZfZPDJ4V7ATvIRu0ANRAhqlklsCDI6EbUDOOARgTGoTBFawfUgKOpQYn65r1BSjHej7CI3d
CAE9CfgakR7nekDFVo0hUembIfVvfJUiRlwOBUY+b07a0mdqGSf9RWQxTCEyzCPe2SS9YIHH
Rz4c0Ck1FgAAAAAAAA==
--------------ms070409050900020000080906--


From nobody Mon Apr  8 05:05:16 2019
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 D6D5B1201EB for ; Mon,  8 Apr 2019 05:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 dYPi65-7umio for ; Mon,  8 Apr 2019 05:05:13 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00059.outbound.protection.outlook.com [40.107.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1AC120045 for ; Mon,  8 Apr 2019 05:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7UMieswqcaHdrOAa63941eTtIEIkMCgNMHTcblscPVU=; b=ETeGU/hyeELK+LzBcDK19tdAwOuiu4hG0l+4X4m/GfNcViYKtWoRfPfh1aSSHvR3rNJIdLqLd5D0bW7/7Da9rVDOQQB1SwIAOi5cmcZYabs24NizMiPWi/lVN8tz95e05/RvvaBzl4Z9AfN2lyPrupFRZcAaDPY1RaMRoczOACU=
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB2966.eurprd08.prod.outlook.com (52.135.163.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 12:05:10 +0000
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1771.011; Mon, 8 Apr 2019 12:05:10 +0000
From: Hannes Tschofenig 
To: Ludwig Seitz , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Question regarding RFC 7800
Thread-Index: AdTqBeiMzR+QhhWmQiK/WODtosExuQDz084AAAthYBA=
Date: Mon, 8 Apr 2019 12:05:10 +0000
Message-ID: 
References:  <3d290fc5-7120-d40d-8513-7903702fd364@ri.se>
In-Reply-To: <3d290fc5-7120-d40d-8513-7903702fd364@ri.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.121.190]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8a0bbd5a-b769-45b8-307f-08d6bc1a7335
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB2966; 
x-ms-traffictypediagnostic: AM6PR08MB2966:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(396003)(376002)(346002)(40434004)(13464003)(189003)(199004)(105586002)(229853002)(7696005)(486006)(99286004)(6506007)(3846002)(11346002)(52536014)(71190400001)(6246003)(6436002)(53546011)(68736007)(25786009)(6306002)(33656002)(2906002)(446003)(26005)(71200400001)(186003)(66066001)(6116002)(102836004)(476003)(74316002)(5024004)(76176011)(5660300002)(14454004)(256004)(966005)(2501003)(106356001)(14444005)(305945005)(8676002)(8936002)(7736002)(53936002)(9686003)(316002)(81156014)(97736004)(81166006)(110136005)(55016002)(72206003)(478600001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB2966; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: VrG7GdEiDAzmCbau23ZIZeqOb1NxDKyOEi6oZL5oVH5qzxHM2WotwVvIR2thHSIJTRkfkUlh4tXlAUwc9DNhSbyxTx9Bf53Mh/ZDqsyv5lj8xty0P92Vp6n+jlrt9A7R2YxzjwvYbVYGPKOBndsKVHHmSMH1br8cu382WhuN77du0NMm9ccpOcAqAwsVyReK5B8imUNEFZ+fQURAZUCdder18rHKh8OX7cZApxmYz3BW8ehIgvvbiXRKwYC0Wmz5Jft5LOPREb7Vd5DSfHZTvB/H3C8VG3M14owW21XYzXlyUnSZiBtVsJ5kBPSCyXl1E22/oYRSHb0AwDbBGPxYo9C3uuXoO67K7wm7IusZbYoO3aAg/FehQKsjuhkEFibjrCIeY6iWBhrD3c97ewqaTbkRQqgjJFfpRZ2GhFVRCoc=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a0bbd5a-b769-45b8-307f-08d6bc1a7335
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 12:05:10.6300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2966
Archived-At: 
Subject: Re: [OAUTH-WG] Question regarding RFC 7800
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, 08 Apr 2019 12:05:16 -0000

Hi Robert,

the work on RFC 7800 has been completed from the point of view of the OAuth=
 working group.

As Ludwig mentioned below, it is being used by other working groups in the =
IETF but also by companies as-is.
Even in the OAuth working group we have other documents that build on top o=
f it, such as draft-ietf-oauth-mtls.

Ciao
Hannes

-----Original Message-----
From: OAuth  On Behalf Of Ludwig Seitz
Sent: Montag, 8. April 2019 08:35
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding RFC 7800

On 03/04/2019 12:14, Robert Lembree wrote:
> Hello folks,
>
>                  What is the status of RFC 7800?  We're finding the
> need for this, and wonder what we might be able to do to help move this a=
long?
>
> Regards,
>
> rob
>


If I may be so bold to drop a shameless plug for the ACE WG here [1]. As yo=
u are working with Schneider Electric, the work in ACE (based on OAuth, but=
 for Contrained Environments) might be more relevant for you.

We have adopted a constrained profile of RFC 7800 (among other things):
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/


Regards,

Ludwig


[1] https://datatracker.ietf.org/group/ace/documents/

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

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.


From nobody Mon Apr  8 05:09:57 2019
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 C33561201BE for ; Mon,  8 Apr 2019 05:09:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 kRwPP983pVfJ for ; Mon,  8 Apr 2019 05:09:53 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130044.outbound.protection.outlook.com [40.107.13.44]) (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 DA2271200D7 for ; Mon,  8 Apr 2019 05:09:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cjTgmki9WfR/H5G751t0dVmTJJROY34lpI/Sx7gjb7M=; b=pQn74Cd1A7s+WuSOluRQmuSPai+5Vrkp/HBiXDHQrE8WP8mWYV3qEelTzUm2FWusswTJxasfypEHrq7nCUPrGRfeUdztG4lAeAN/NLjmHpBHcRm5prTFwORChAAl2/zKCotQbXA3C7/lomCQlFJkrGoNJHMu9C9rnoYzyEXpku8=
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3112.eurprd08.prod.outlook.com (52.135.163.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 12:09:49 +0000
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1771.011; Mon, 8 Apr 2019 12:09:49 +0000
From: Hannes Tschofenig 
To: Milind Nikam , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Possible help with product design
Thread-Index: AdTneVGoHd7ocwDRTJi151EjN5O0pAGig8hQ
Date: Mon, 8 Apr 2019 12:09:49 +0000
Message-ID: 
References: <000001d4e77a$2c425cc0$84c71640$@extrapreneursindia.com>
In-Reply-To: <000001d4e77a$2c425cc0$84c71640$@extrapreneursindia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.121.190]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6cb964d3-9399-4a8d-3e25-08d6bc1b1963
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3112; 
x-ms-traffictypediagnostic: AM6PR08MB3112:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39860400002)(376002)(136003)(199004)(189003)(40434004)(26005)(446003)(5660300002)(68736007)(102836004)(11346002)(476003)(52536014)(486006)(76176011)(229853002)(3846002)(7736002)(66066001)(186003)(6506007)(790700001)(6436002)(478600001)(14454004)(86362001)(2906002)(106356001)(74316002)(105586002)(33656002)(72206003)(25786009)(53546011)(6246003)(606006)(97736004)(8676002)(55016002)(71200400001)(256004)(6306002)(9686003)(6116002)(966005)(81156014)(8936002)(81166006)(14444005)(53936002)(71190400001)(316002)(7696005)(2501003)(99286004)(110136005)(66574012)(9326002)(236005)(5024004)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3112; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 5y8qd3l/tI6SZy35mDyV8Z+dnTdYyRSt1B+fvBi/zdjjs55aqlCGY9IbuZgrd2pnYeYQKQt3Lt4PHkOEBQY+0bbuLfPMR9JyV3qUEUiJK2rWvJ49Hs2E9teYY8ZI8N+PQZGQJ57AjthkLWfMnId1NjxNqV9h3D/sU2DhXVw0D8I5bbtOVo7tBm9UJ6yoaICWtAdmtw132wmt+vqYtFDejUU+HAE7Ohedn9IsjeW5qjd+9/j9qKylqx9tLbyF0n0nxhFi14l5DAEefVHlB6yUKO+Ufodax8hb9xC2jyMIUU/RBCc7H0wS6r5JdlcNgzrE/oYaUJkmUqe1F9EsDL2NTOqx/l7WbAdNDQtkIt2d3uBHMQ8FYQjd75OdqJeRFEKsHHvg5AOkC35gRiNx1IWzd731NmGGiNxvUyETVwrmjm4=
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB368617ECC1E0CA2C131A91D2FA2C0AM6PR08MB3686eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cb964d3-9399-4a8d-3e25-08d6bc1b1963
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 12:09:49.4786 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3112
Archived-At: 
Subject: Re: [OAUTH-WG] Possible help with product design
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, 08 Apr 2019 12:09:56 -0000

--_000_AM6PR08MB368617ECC1E0CA2C131A91D2FA2C0AM6PR08MB3686eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Milind,

while there are lots of people on this list with hands-on experience with O=
Auth 2.0 the purpose of this mailing list is primarily for discussions rela=
ted to the specifications developed by the OAuth working group. Here you ca=
n find our active working group specifications: https://datatracker.ietf.or=
g/wg/oauth/documents/

If someone from this group reaches out to you (privately) to offer help tha=
t's great but otherwise you will have to search on the web for example code=
.

Ciao
Hannes
(Co-Chair of the OAuth WG)

From: OAuth  On Behalf Of Milind Nikam
Sent: Sonntag, 31. M=E4rz 2019 06:28
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible help with product design

Dear Team,

We are in a process of architecting the web project with the technology sta=
ck as Angular 7 & .NET Core 2.2.
We wanted to implement token, So we did some research and finalized OAuth 2=
.0 & JWT would be the platform.
However, I am new to OAuth 2.0. and even also JWT.
So I need possible help from you to implement token security in OAuth 2.0 &=
 JWT with .NET Core 2.2.
I will appreciate if you share some sample code available with you.



Thanks and Regards,
Milind Nikam

EXTRAPRENEURS India Pvt. Ltd.
102, Bhakti Genesis, Wakad Hinjewadi Road, Wakad, Pune - 411057
Mobile: +91-9970190334  | Landline: +91 (020) 6920 9001 | Website: www.extr=
apreneursindia.com  | Skype: Milind.nik=
am2

This communication and any attached files may contain information that is c=
onfidential or privileged. Any unauthorized review, use, disclosure or dist=
ribution is prohibited.
 If this communication has been received in error, please notify me and del=
ete or destroy it immediately.


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_AM6PR08MB368617ECC1E0CA2C131A91D2FA2C0AM6PR08MB3686eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Milind=
, 


&nbs=
p;


while the=
re are lots of people on this list with hands-on experience with OAuth 2.0 =
the purpose of this mailing list is primarily for discussions related to th=
e specifications developed by the OAuth
 working group. Here you can find our active working group specifications: =

https://datatr=
acker.ietf.org/wg/oauth/documents/


&nbs=
p;


If someon=
e from this group reaches out to you (privately) to offer help that’s=
 great but otherwise you will have to search on the web for example code.



&nbs=
p;


Ciao=



Hannes


(Co-Chair=
 of the OAuth WG)


&nbs=
p;






From: OAuth <oauth-bounces@ietf.org>
On Behalf Of Milind Nikam

Sent: Sonntag, 31. M=E4rz 2019 06:28

To: oauth@ietf.org

Subject: [OAUTH-WG] Possible help with product design






 


Dear Team,

 


We are in a process of architec=
ting the web project with the technology stack as Angular 7 & .NET Core=
 2.2.

We wanted to implement token, So we did some research and finalized OAuth 2=
.0 & JWT would be the platform.


However, I am new to OAuth 2.0.=
 and even also JWT.

So I need possible help from you to implement token security in OAuth 2.0 &=
amp; JWT with .NET Core 2.2.

I will appreciate if you share some sample code available with you.


 


 


 


Thanks and Regards,



Milind Nikam


 


EXTRAPRENEURS India Pvt. Ltd.


102, Bhakti Genesis, Wakad Hinjewadi Road, Wakad, Pune=
 – 411057


Mobile: +91-9970190334  | Landline: +91 (020) 6920 =
9001 | Website: www.extrapreneursindia.com
 | Skype: Milind.nikam2=



 


This communication and any attached fi=
les may contain information that is confidential or privileged. Any unautho=
rized review, use, disclosure or distribution
 is prohibited. 



 If this communication has been r=
eceived in error, please notify me and delete or destroy it immediately.


 


 



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_AM6PR08MB368617ECC1E0CA2C131A91D2FA2C0AM6PR08MB3686eurp_--


From nobody Mon Apr  8 05:10:24 2019
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 7098E1201EB for ; Mon,  8 Apr 2019 05:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 pNZxTFP0Ofpl for ; Mon,  8 Apr 2019 05:10:21 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D791202F6 for ; Mon,  8 Apr 2019 05:10:21 -0700 (PDT)
Received: from client-0237.vpn.uni-bremen.de (client-0237.vpn.uni-bremen.de [134.102.107.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44d8Pk6pWdzyV2; Mon,  8 Apr 2019 14:10:18 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 8 Apr 2019 14:10:18 +0200
Cc: "oauth@ietf.org" 
X-Mao-Original-Outgoing-Id: 576418216.4652081-e6ee522e0de66db73d877b81e4c68927
Content-Transfer-Encoding: quoted-printable
Message-Id: <680A3883-1973-4173-B7A7-69AB7A60781F@tzi.org>
References: 
To: Robert Lembree 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [OAUTH-WG] Question regarding RFC 7800
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, 08 Apr 2019 12:10:23 -0000

Hi Robert,

This raises the $64000 question: What piece of information made you =
consider that this draft might need more help?  Maybe there is some =
miscommunication that we can fix.

Gr=C3=BC=C3=9Fe, Carsten


> On Apr 3, 2019, at 12:14, Robert Lembree =
 wrote:
>=20
> Hello folks,
>                 What is the status of RFC 7800?  We=E2=80=99re finding =
the need for this, and wonder what we might be able to do to help move =
this along?
> =20
> Regards,
> rob
> =20
> --
> Robert Lembr=C3=A9e
> Lead Cybersecurity Architect
> Innovation & Technology
> Industrial Automation Business
> Schneider Electric
> D  +1 978 975 9971
> M  +1 603 494 0559
> E  robert.lembree@se.com
> 800 Federal St.
> 3W-WS179
> Andover, MA 01810
> United States
> 
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Apr  8 08:47:13 2019
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 16BDC120144 for ; Mon,  8 Apr 2019 08:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=se.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 Q-mB7xnwsIKy for ; Mon,  8 Apr 2019 08:28:17 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40138.outbound.protection.outlook.com [40.107.4.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31F5120154 for ; Mon,  8 Apr 2019 08:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=se.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PuaVwG8NiTrHze0y6J34bNslaYbYA+5pHqlNIdxreGM=; b=H+E0cgdWQtrN55vSATDEwlJCO1QgjdKyh3lDmZoAO7y5h/utvTy0ZUGLY8jLRimtnKduzwJjKJs7ZXSRTUlZkQqaFztjEXvF9p1u4O7rkQdWBscqrh9qJ/P3faP21Mmf+ILwfp7yscqOL65EMZG/Zc5kQAXlnuuhv5d3kE6dwSE=
Received: from AM0PR04MB6322.eurprd04.prod.outlook.com (20.179.35.146) by AM0PR04MB5121.eurprd04.prod.outlook.com (20.176.214.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Mon, 8 Apr 2019 15:28:14 +0000
Received: from AM0PR04MB6322.eurprd04.prod.outlook.com ([fe80::7c11:37c5:c3b5:1cd9]) by AM0PR04MB6322.eurprd04.prod.outlook.com ([fe80::7c11:37c5:c3b5:1cd9%4]) with mapi id 15.20.1771.016; Mon, 8 Apr 2019 15:28:14 +0000
From: Robert Lembree 
To: Carsten Bormann 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Question regarding RFC 7800
Thread-Index: AdTqBeiMzR+QhhWmQiK/WODtosExuQD/h9UAAAa1r2A=
Date: Mon, 8 Apr 2019 15:28:14 +0000
Message-ID: 
References:  <680A3883-1973-4173-B7A7-69AB7A60781F@tzi.org>
In-Reply-To: <680A3883-1973-4173-B7A7-69AB7A60781F@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Robert.Lembree@se.com; 
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce279349-c5a2-418a-78da-08d6bc36d151
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(49563074)(7193020); SRVR:AM0PR04MB5121; 
x-ms-traffictypediagnostic: AM0PR04MB5121:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(396003)(136003)(376002)(199004)(189003)(53546011)(6436002)(2906002)(102836004)(26005)(476003)(6916009)(11346002)(55236004)(6306002)(186003)(8936002)(74316002)(68736007)(316002)(486006)(76176011)(229853002)(55016002)(7696005)(446003)(8676002)(71200400001)(71190400001)(33656002)(66574012)(305945005)(81166006)(81156014)(6506007)(6246003)(86362001)(106356001)(478600001)(45080400002)(53936002)(52536014)(72206003)(25786009)(9686003)(4326008)(97736004)(99936001)(105586002)(14454004)(966005)(99286004)(5660300002)(256004)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR04MB5121; H:AM0PR04MB6322.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: se.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OZuImEnS9C6BQ/uYjp5jSOjHIrWGq7ZLXHRi6Ch/BSG3oy8vDpGnj3SFxGrsMi3G5XWZLYEjWvvsA14Yi+H0S+lUYiEDiEhOnnrGMiySAMBuy7QQ3Xs4h/Olq7QvVm4NvvL+4Io/ecl0wRBBifMX/SpFTDLa1TzGduwuaM+qVmjlAGZX/yyQU4gx1cquACvTGEXGLOIehTCD/SDVFWK/Rc3jJiN/jeiabl1yZYnEkO6UhjfozK3ux1yK8p7We+W6PS3PCkrL0Gr+HNredJ6+TdwMvE2pNy8h5UKZhTSMPiI+00opPKl3PA+h2HVg9d9Nc1oFcGZpEKf/PDmvxzM5dzBfuw+WbdTebOZL2+SZUo+XKcj29/I6f03mAsY3rKM9rJ26KgU3GCke6CGAGDV24wwMDjkl8jb4J4wWbDWSDJQ=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003C_01D4EDFE.26887460"
MIME-Version: 1.0
X-OriginatorOrg: se.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce279349-c5a2-418a-78da-08d6bc36d151
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 15:28:14.5126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6e51e1ad-c54b-4b39-b598-0ffe9ae68fef
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB5121
Archived-At: 
X-Mailman-Approved-At: Mon, 08 Apr 2019 08:46:50 -0700
Subject: Re: [OAUTH-WG] Question regarding RFC 7800
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, 08 Apr 2019 15:28:20 -0000

------=_NextPart_000_003C_01D4EDFE.26887460
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Carsten,
	I didn't see any specific issues.  I'm trying to understand where the =
RFC stands, and why or why not it might be smart to implement and use it =
as it stands.  My primary concern is compatibility with any anticipated =
changes to the RFC in advance of wide acceptance.

Regards,
rob


Hi Robert,

This raises the $64000 question: What piece of information made you =
consider that this draft might need more help?  Maybe there is some =
miscommunication that we can fix.

Gr=C3=BC=C3=9Fe, Carsten


> On Apr 3, 2019, at 12:14, Robert Lembree =
 wrote:
>
> Hello folks,
>                 What is the status of RFC 7800?  We=E2=80=99re finding =
the need for this, and wonder what we might be able to do to help move =
this along?
>
> Regards,
> rob
>
> --
> Robert Lembr=C3=A9e
> Lead Cybersecurity Architect
> Innovation & Technology
> Industrial Automation Business
> Schneider Electric
> D  +1 978 975 9971
> M  +1 603 494 0559
> E  robert.lembree@se.com
> 800 Federal St.
> 3W-WS179
> Andover, MA 01810
> United States
> 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> =
https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7CRobert.Lembree%=
40se.com%7C380e5a2c66ee403c895308d6bc1b3992%7C6e51e1adc54b4b39b5980ffe9ae=
68fef%7C0%7C1%7C636903222454083023&sdata=3D7WHGrasoqhizYah%2BenrVNEhb=
izupkYiS5Lnob4azLIs%3D&reserved=3D0

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud =
service.
______________________________________________________________________

------=_NextPart_000_003C_01D4EDFE.26887460
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU+zCCBDYw
ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy
dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ
QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha
MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg
RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e
mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe
dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr
TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE
XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV
NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB
BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk
cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0
IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7
rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU
LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD
yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIFLjCC
BBagAwIBAgIRAMePYYr9d+THm0Kodx0QQxEwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT
D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTkwMjE5MDAwMDAwWhcNMjAwMjE5MjM1OTU5WjAm
MSQwIgYJKoZIhvcNAQkBFhVyb2JlcnQubGVtYnJlZUBzZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCrUb1e6sP7mQHKxyuvLRgHWUpzStgggreamgOU0g+/P7kwDCrSOWPrv9Oy
3tzBnwVg/KtNnvzJT+CPk4NIoewQBn21kShB66uo+Wj7bUADQvuvdsL9pmRfWy8KhuvS1aO9frTT
1eqkS8g3bG/2gumaIxL5izC7RhZ+4k7KkMMISbYcBra1fvOpYKiXuDLBVNBuZYwnae7HlTuhP5oo
KnkElLlANssxxMvXH2vHUIDxCg3ew9ZRzydiIIYhSCabjAiFN8K9pY0013uwzxVrI4DFwXPjm0+l
K31iHIGcICf4VpoSHKNZ6JDSzNibBYcrOaYd5DS/iEADelijWi4CzDQ1AgMBAAGjggHkMIIB4DAf
BgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU2Chtl8BkfGTm3+Y342HY
HpjNDicwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQG
CysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBABgNVHSAEOTA3MDUGDCsGAQQBsjEBAgEB
ATAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBaBgNVHR8EUzBRME+gTaBL
hklodHRwOi8vY3JsLnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3JsMIGKBggrBgEFBQcBAQR+MHwwVQYIKwYBBQUHMAKGSWh0dHA6Ly9j
cnQuc2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h
aWxDQS5jcnQwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29tMCAGA1UdEQQZMBeB
FXJvYmVydC5sZW1icmVlQHNlLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEArOIvrlEhqSyz1wgEQfLx
bbN+vTCt5+5gN0vDLib4sbt0kg8eMCRVauGbyOwDcL8Haq2vswAJZhT8VCQ6iWqeiideE9n6gBgG
qq6flOjAgeVFRbu0P1m6F0ZCGoVl0782oE8JiRXUXT6lXDulBFZgnVl3KJEDV5h1N8XvmCLyhmhd
m3p3dSGUS2BM5acOsjr6V5OxB6UsNneiNH6u6M5ms3f2LzTJ1+NT5jQD3VPY0Vq/gDTpOyU1qUas
JnRMv2RefUxklaaLLq4rnpth1Mk4AN+uajHTcjBhWAIffgaQL/sENpn3QBnNbWW3/t/kEU58BtIh
JXrtKkIrFd0dcAZ2EDCCBXcwggRfoAMCAQICEBPqKHBb9OztDDZjCYBhQzYwDQYJKoZIhvcNAQEM
BQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVz
dCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGIMQswCQYDVQQGEwJVUzETMBEGA1UE
CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJV
U1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIASZRc2DsPbCLPQrFcNdu3NJ9NMrVCD
YeKqIE0JLWQJ3M6Jn8w9qez2z8Hc8dOx1ns3KBErR9o5xrw6GbRfpr19naNjQrZ28qk7K5H44m/Q
7BYgkAk+4uh0yRi0kdRiZNt/owbxiBhqkCI8vP4T8IcUe/bkH47U5FHGEWdGCFHLhhRUP7wz/n5s
nP8WnRi9UY41pqdmyHJn2yFmsdSbeAPAUDrozPDcvJ5M/q8FljUfV1q3/875PbcstvZU3cjnEjpN
rkyKt1yatLcgPcp/IjSufjtoZgFE5wFORlObM2D3lL5TN5BzQ/Myw1Pv26r+dE5px2uMYJPexMcM
3+EyrsyTO1F4lWeL7j1W/gzQaQ8bD/MlJmszbfduR/pzQ+V+DqVmsSl8MoRjVYnEDcGTVDAZE6zT
fTen6106bDVc20HXEtqpSQvf2ICKCZNijrVmzyWIzYS4sT+kOQ/ZAp7rEkyVfPNrBaleFoPMuGfi
6BOdzFuC00yz7Vv/3uVzrCM7LQC/NVV0CUnYSVgaf5I25lGSDvMmfRxNF7zJ7EMm0L9BX0CpRET0
medXh55QH1dUqD79dGMvsVBlCeZYQi5DGky08CVHWfoEHpPUJkZKUIGy3r54t/xnFeHJV4QeD2PW
6WK61l9VLupcxigIBCU5uA4rqfJMlxwHPw1S9e3vL4IPAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAU
rb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFFN5v1qqK0rPVIDh2JvAnfKyA2bLMA4GA1Ud
DwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7
MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5j
cmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29t
MA0GCSqGSIb3DQEBDAUAA4IBAQCTZfY3g5UPXsOCHB/Wd+c8isCqCfDpCybx4MJqdaHHecm5UmDI
KRIO8K0D1gnEdt/lpoGVp0bagleplZLFto8DImwzd8F7MhduB85aFEE6BSQb9hQGO6glJA67zCp1
3blwQT980GM2IQcfRv9gpJHhZ7zeH34ZFMljZ5HqZwdrtI+LwG5DfcOhgGyyHrxThX3ckKGkvC3v
RnJXNQW/u0a7bm03mbb/I5KRxm5A+I8pVupf1V8UU6zwT2Hq9yLMp1YL4rg0HybZexkFaD+6PNQ4
BqLT5o8O47RxbUBCxYS0QJUr9GWgSHn2HYFjlp1PdeD4fOSOqdHyrYqzjMchzcLvMIIGEDCCA/ig
AwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF
UlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwHhcNMTgxMTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2Vj
dGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQK
Qf/e+Ua56NY75tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6n
BEibivHbSuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHd
JDfqB6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC
0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz6OX2
ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5v1qqK0rP
VIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNVHQ8BAf8EBAMC
AYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYD
VR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNv
bS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgw
PwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVz
dENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B
AQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfXehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFu
SUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnC
LwRfCX6iLPvGlh9j30lKzcT+mLO1NLGWMeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/X
fdJ5jR3YCq8H0OPZkNoVkDQ5CSSF8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQS
qXh3TbjugGnG+d9yZX3lB8bwc/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6l
DFqkXVsp+3KyLTZGXq6F2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhA
mtMGquITn/2fORdsNmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE1
9GUi8K8plBNKcIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5
ssebmHQREJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14AC
HuVvJsmzNicxggRNMIIESQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w
PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp
bCBDQQIRAMePYYr9d+THm0Kodx0QQxEwCQYFKw4DAhoFAKCCAnUwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDA4MTUyODEyWjAjBgkqhkiG9w0BCQQxFgQUs7hE
+iruCanK4VSj/o83V2eBlUowgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCgYIKoZI
hvcNAwcwCwYJYIZIAWUDBAEWMA4GCCqGSIb3DQMCAgIAgDALBglghkgBZQMEAQIwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgb0G
CSsGAQQBgjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQD
EzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR
AMePYYr9d+THm0Kodx0QQxEwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEb
MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9T
ZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv
biBhbmQgU2VjdXJlIEVtYWlsIENBAhEAx49hiv135MebQqh3HRBDETANBgkqhkiG9w0BAQEFAASC
AQCqW1grVvZbpxT91ywoZDaFbnMq8it6QS9jNtXnxEMbz6xpqvZMSdK4+8siEm21/qqU6zbnqflM
5Tva3QoiY1DLrXMVGtyN90lz3JcVngUq2nHa96ARhVnUMQT9RvTtBm6kWyTirvUexl0vVM6sD3gC
QmcTMt51PS/gN1f9Q1jBseJMOWvUBeAbyAL73yQk7gwWQFYX/TBlHTH6zQ+UIAdNv9Eq6GotCSWb
GsSBmCnH1wqj1TRA4ikp4TEzkYoJIG65FQlub7eeCcuJ9gy2g9sJY1CW2nNExL5yC1G6tHfzACB5
IeNPlv7v4J8f4E/uQWaY2nMr5oyyAOQO17Eq278LAAAAAAAA

------=_NextPart_000_003C_01D4EDFE.26887460--


From nobody Mon Apr  8 10:07:25 2019
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 4A12B1200B7 for ; Mon,  8 Apr 2019 10:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 PfzJZYHRF0-9 for ; Mon,  8 Apr 2019 10:07:21 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::623]) (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 65DFA1203A6 for ; Mon,  8 Apr 2019 10:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xigr1DDCdzSvF650MD3CgbLMmMbHX2YR4LqQcvojoT8=; b=L4/hFFmg61NtZv3+DwSX3CRVlQHv4ILFcaXZWXo3MmHEM6IxCOPuM4xV8Jz4SvEMHPrb4NhmeyxEBsUusJNgEg4SzPR67ocg2KAqUUeNPxE6bX48jBxFv0ucneZJhcr581Ppp76UeG6kSeu4K6yzNcaY54CK1i4DpSxGt401EVs=
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4565.eurprd08.prod.outlook.com (20.179.3.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Mon, 8 Apr 2019 17:07:17 +0000
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1771.011; Mon, 8 Apr 2019 17:07:17 +0000
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Thread-Topic: Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaA==
Date: Mon, 8 Apr 2019 17:07:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [80.92.121.190]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 98afafac-90f7-432d-eb71-08d6bc44a7c5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4565; 
x-ms-traffictypediagnostic: AM6PR08MB4565:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(376002)(346002)(136003)(40434004)(53754006)(189003)(199004)(97736004)(6116002)(5660300002)(71190400001)(7696005)(72206003)(478600001)(68736007)(966005)(6916009)(71200400001)(5640700003)(9686003)(8676002)(6436002)(99286004)(2906002)(2501003)(7736002)(2351001)(14454004)(33656002)(256004)(55016002)(6306002)(14444005)(5024004)(3846002)(26005)(53936002)(81166006)(4744005)(25786009)(74316002)(81156014)(305945005)(186003)(316002)(86362001)(6506007)(8936002)(52536014)(1730700003)(102836004)(476003)(105586002)(66066001)(486006)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4565; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6mhfvHhE00AR20sy79JAGxyh0W3W/AAFQyzYkNh0NNFTTCnrGlZdiocr96SE9gHpA8xYtUSZqiIDUicpYqsunsha2tFLf2i76HWz1FzHuSjs3IJ5yyY8w7SMw3WvA9+1LCj5xBHVujVD0ydwyCgO2wdRncmkTEQPlsDWK8/DDRZmmi60Hml0N9EyOfCfrEfEtI06GAlhWql1U3Nxxnz9fxGB1t9R9GHXEL11CKbL+w4jAqIIOC0ffKlys9MrN9n7CmfS7MGJv/l/QbARpiHk2xKPAhzpOx++mKydM0q/ByDdATcal/WL3CFk5kyH+Gb1k4H0WYqL1qz0NCm6u9f/IzstzorDh8A4eFcPr/EZ5Y6PQHEMOlDoDGU/uYbgQE4c8mm1qpQoAAHp53fEpCRWWOsYxhWAJHTTtxRX5puakeA=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98afafac-90f7-432d-eb71-08d6bc44a7c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 17:07:17.6997 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4565
Archived-At: 
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 17:07:24 -0000

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  d=
ocument following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00

Please let us know by April 22nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 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.


From nobody Mon Apr  8 10:24:43 2019
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 C26B71200B7 for ; Mon,  8 Apr 2019 10:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtJFLCSWpV0O for ; Mon,  8 Apr 2019 10:24:40 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 5823E120059 for ; Mon,  8 Apr 2019 10:24:40 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id 103so12902610otd.9 for ; Mon, 08 Apr 2019 10:24:40 -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=V2fByFDLFcXnxUluPFib2s7S5p2RmF4vhhiPVf4jBhs=; b=XqSpXrq++7LgeJftyx3777dUYUN5C88azsdz3dDVXrJ/lprGXIgpSEZGz/VjSrRkz+ s7ZpIr8ThWh9l1vESSzoKxKrRmIroMZAzifJAVeMSFh2tcTJt3QgEm3VYaPo/LtpOhWP zdoPRPxI2F0Rki1VGvDYwaPQk6ne/wkD8p7fBJQazGXaUyCigR9niHI3F3eb9qneG+HP 3KicOTG4a17WMuC93Z/50knSycfQuQIWr2B2ZAQP9cfwiDWmS3b7eRauXttUa7dVaKnx g/YqCqIu00fHXiu7KtkS4VpHYBAtwVULZo3DTMh8qweBOLjdKHj56w43QG0itnoQsUnX mdbA==
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=V2fByFDLFcXnxUluPFib2s7S5p2RmF4vhhiPVf4jBhs=; b=SnnTYJcdomLNu9PC9CsyuQeApxoBh44n+tvQz9WQkY8dZQi2gRNX8tfv5/wcRsSN3r j8ceo9WZGB/6HslYiNtsQH/7zm6qMUmQD2XGBiAFNGUXEqJvtTVNbH3pgWTXpfhD1rWk RbzaWJKvMRcyKLsqZnNKgSXaEN3VnBgfqqCxk7EvXC+pgZeqTOdl0EYh1h1CaFixxOpe 83iaWHE5qisxQxhKcCkSFpThlTapyekMv4fPgQinmH3EozTE3pUUkfZWC5z/ZHSxY6LE hl9gtXELCbyTHDv3v62aA1aHcffR/pjdzn93m10avcThQqYEDcdf1KOk7WcIrTGEUFMz zIcw==
X-Gm-Message-State: APjAAAW74E/GOG6W08aXut/EX8K4WWJlB1AOVnBSLCeJ3Qw5usqk/BrQ RQR/ExE/VuWcj0mw2oFB7nrufbY1LtAHUID9pLCZ
X-Google-Smtp-Source: APXvYqw+EEds+esgaqvH8Z1e1MqUJ0rH0hFpkbjDGCro1YFiBTxgZ4bC544QWy3hZUxPZkuDxXrAm9q+xZmsaFN6WNk=
X-Received: by 2002:a9d:61c5:: with SMTP id h5mr17632411otk.330.1554744279347;  Mon, 08 Apr 2019 10:24:39 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Filip Skokan 
Date: Mon, 8 Apr 2019 19:24:28 +0200
Message-ID: 
To: Hannes Tschofenig 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000007cb6420586081c0f"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 17:24:42 -0000

--0000000000007cb6420586081c0f
Content-Type: text/plain; charset="UTF-8"

I support the draft's adoption.

Best,
*Filip Skokan*


On Mon, 8 Apr 2019 at 19:07, Hannes Tschofenig 
wrote:

> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I support the draft's adoption.

Best,
Filip Skokan


On Mon, 8 Apr 201=
9 at 19:07, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
Hi all,



this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens=
'=C2=A0 document following the positive feedback at the last IETF meeti=
ng in Prague.



Here is the document:

https://tools.ietf.org/html/draf=
t-bertocci-oauth-access-token-jwt-00



Please let us know by April 22nd whether you accept / object to the

adoption of this document as a starting point for work in the OAuth

working group.



Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are 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.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000007cb6420586081c0f--


From nobody Mon Apr  8 10:34:29 2019
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 59F941201EA for ; Mon,  8 Apr 2019 10:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 c11EIdMx_ISj for ; Mon,  8 Apr 2019 10:34:25 -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 4E1C2120105 for ; Mon,  8 Apr 2019 10:34:25 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id s15so8094982qtn.3 for ; Mon, 08 Apr 2019 10:34:25 -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:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=fbUFHbcTr9LyuKlbcCUT4klQjBGRFzl2bRBVd2pv5VA=; b=19lwk64z1K0i+fpBaZNYqc+IweVcZ2jBepnetQ1nM2/V+9bbVk9GsRwJsAJ0MdarWO mHtgBIqfm08oW+i8mDnp0bP4VgU86K7W+6kFe+nDpXnTl9QdmGf6SH71zcp3lvM6WAd3 sIAOSzKNuMnTK2ppSDfA/8bdafbkv7Y/KgWZb+R56ZNvaVxu9mJQAqtaD3XNcq4RWJFW 4xGpvCk7vk+rZRK+UBRIC6eiDCHwpO5cRTY9Qrq4rbDHCE/9e343O6EO4hgtM9S+gCSm jwOlUu4LdSCOr4ZJeqp7Mt3TaYVj0QZ58Q0iRTANhuXjUuFe9vVXX3zmbJSlNBdNE+cY iGnw==
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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fbUFHbcTr9LyuKlbcCUT4klQjBGRFzl2bRBVd2pv5VA=; b=ANLHBOQCpRYCqPZTrKksjgVbyd3n3iAn0j6kZTIPyacPzO55UyyXFW28CV/r0Ntj7b qe8JRKBW9tck2K3v87kHzkbcD8rOy1oicFJrm9po6u6qqbfAFK1CoaAlyQq3UYu35XIc 2Y/mushUYl3sc3g3TSmov69sBUUQC2TOgqaB9fXJeJ0nAN+JprJIEmZRUk1kG2nRFxKs zm8d4115BveKmNeejSD7HHtnjWMSpoP0tLgtzDVsVKLLEIrVX5lwUYAGVNrjaQP2PbOU /Gw/0BJ9G9eDjlL3mCSXvwRrQEhwweNCJUIur5M1Cgl9jxRDoproifN3olw8USuFWmgn /xBw==
X-Gm-Message-State: APjAAAVYq1m6qkm5bKLUN3ZmkXzSVmXTVJ3m6AKH/KHHOdfP155zP6Y9 CAo28bD2i05rjdNttOH/QBkPP/Sde52sQA==
X-Google-Smtp-Source: APXvYqxLc3qDyfbT51KnxMNc+hlQEkNsH8xV0q+P7Zarkk0FYbJUvTOEZblE4d0jJWvtFlOuDRNpHg==
X-Received: by 2002:ac8:2d02:: with SMTP id n2mr25342275qta.229.1554744863593;  Mon, 08 Apr 2019 10:34:23 -0700 (PDT)
Received: from [192.168.8.105] ([181.203.40.167]) by smtp.gmail.com with ESMTPSA id m46sm20531203qtk.95.2019.04.08.10.34.22 for  (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 10:34:22 -0700 (PDT)
To: oauth@ietf.org
References: 
From: John Bradley 
Message-ID: <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>
Date: Mon, 8 Apr 2019 19:34:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:66.0) Gecko/20100101 Thunderbird/66.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
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 17:34:27 -0000

I agree this should be adopted as a working group document.


On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Apr  8 10:38:41 2019
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 4EEFC12025B for ; Mon,  8 Apr 2019 10:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.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 e3VG-XTEs26u for ; Mon,  8 Apr 2019 10:38:36 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 B6BE21201EA for ; Mon,  8 Apr 2019 10:38:36 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id x12so16443761qts.7 for ; Mon, 08 Apr 2019 10:38:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=d95I81YQfSDAAgZa7LT1C5PtY5royHRj/mHLm9KrtGU=; b=Y5TfWPlBxM3qft0i2YiDh2jZ8eUOdBgsmRE7cJvMo08Roi2u/2qfRzmzWxNFSiB4jx pkCoC5xRUfzWRjQcfoIpTOfejxyQLYDBawolQoGIWIjod6JK4CbDbvn8fFWpW+FseGdJ Nw0qxbdzB0dn8iSn8l+xqQ6+HoMannGy6UqXaoriFQ97yZ4ywe7LozoFqhsbHEARojDn PHaRVGk469Ca+2OlcqAQp/tmArRj7lffY59cNnxdQAUBn1B3QyRiEQMQP5HHa4RZ/v5y CvF2drBGZM00SKf6Eh4niwKs5VaOLzKkSoapfhJm3q8did9T0INbsf64fOTyUiFouHu2 HUWw==
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=d95I81YQfSDAAgZa7LT1C5PtY5royHRj/mHLm9KrtGU=; b=fTriG83sS+j5fNLZEB/ubPzTaIm407vh2UZOfjisMma2oLU2RusiVBMoxzzX5IJuJ4 jmvjHg2Pj10I+1OZRoeeFIVKi0K5NtHKiU6pyrqzd5LWulWVLpnsgduORN6bdG7zp/yr BL6RxyuCVX0k+1s9PDJc+EpctzNx7pYJ/WBDLG7nQJXlLPuAkjYIPrHciCLLMuo9qtKk U9hgIHwKOdSeqYPfBYr+CRD/bGaXEtUVlFIviagahHIsbwAQrzczzgP5mm9FW1qxE+tT zzBZwTsNKS/SjR8UvgpQTiZfTgWH4kvo9Rms+EDlZTfjRPxa7QZ0LSIUwgKCTbVECGto vSEg==
X-Gm-Message-State: APjAAAWS6oeB8P59rSj0m+8EJn9BBouK+/k0yjYT+6zxvfUgq/or4Agv wNkOLzwrjvihS5gY7W9KV6AtVFRbOTewbcze54FJT738zvQ=
X-Google-Smtp-Source: APXvYqxOQjCprwBZHiNQ6x7hl4wN2tVyOxR2/RL75OhrPIANMCdRKHz0Kha2dtMLpKLtayFc3CBG9hhqgAUbcdKVRhM=
X-Received: by 2002:aed:3b31:: with SMTP id p46mr27173370qte.207.1554745115462;  Mon, 08 Apr 2019 10:38:35 -0700 (PDT)
MIME-Version: 1.0
References:  <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>
In-Reply-To: <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>
From: Hans Zandbelt 
Date: Mon, 8 Apr 2019 19:38:22 +0200
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000052e07b0586084e90"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 17:38:39 -0000

--00000000000052e07b0586084e90
Content-Type: text/plain; charset="UTF-8"

+1

Hans.

On Mon, Apr 8, 2019, 19:34 John Bradley  wrote:

> I agree this should be adopted as a working group document.
>
>
> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
> > Hi all,
> >
> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
> Tokens'  document following the positive feedback at the last IETF meeting
> in Prague.
> >
> > Here is the document:
> > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
> >
> > Please let us know by April 22nd whether you accept / object to the
> > adoption of this document as a starting point for work in the OAuth
> > working group.
> >
> > Ciao
> > Hannes & Rifaat
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1

Hans.

On Mon, Apr 8, 2019, 19:34 John Bradley <ve7jtb@ve7jtb.com> wrote:
I agree this should be adopted as a working group document.





On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:

> Hi all,

>

> this is the call for adoption of the 'JWT Usage in OAuth2 Access T=
okens'=C2=A0 document following the positive feedback at the last IETF =
meeting in Prague.

>

> Here is the document:

> https://tools.ie=
tf.org/html/draft-bertocci-oauth-access-token-jwt-00

>

> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.

>

> Ciao

> Hannes & Rifaat

>

> IMPORTANT NOTICE: The contents of this email and any attachments are c=
onfidential and may also be privileged. If you are not the intended recipie=
nt, please notify the sender immediately and do not disclose the contents t=
o any other person, use it for any purpose, or store or copy the informatio=
n in any medium. Thank you.

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailman/listinfo/oau=
th



_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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




--00000000000052e07b0586084e90--


From nobody Mon Apr  8 10:54:41 2019
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 BFF4D120318 for ; Mon,  8 Apr 2019 10:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 PsFV6Id0F9Pu for ; Mon,  8 Apr 2019 10:54:36 -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 8A7871202F7 for ; Mon,  8 Apr 2019 10:54:36 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id f6so11857627iop.3 for ; Mon, 08 Apr 2019 10:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y3dzzMhF6q9B60WwX1X26gclZmf99YOwKgBKZjwTkuQ=; b=Ng4v4zvigqbOszDJctv96jQQ/luSRQoA62orHitrSsUZft+eYJ9JmyAgpxdooAiYkB UkSXX+/V2u+QenGx9KzMGLyf5lkOgKaPp5oGHNRO7XIlcC410iRlgaj1vkdTNozo2eVZ 9NJLO2hIID+IYEFh8mw2X72rXYm2KizzXu3lA=
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=y3dzzMhF6q9B60WwX1X26gclZmf99YOwKgBKZjwTkuQ=; b=nKY9NctssdzcpEjvQPJGA7fEjo/wNIknylsLRrNy00htsmuAHScwt2ZanyvoYNZPfy 9Nr9Yygaji2o6+5nifBpZ7o3Emszr768nDBSHU+449Ea6Eut6iweXjkcWGCNt2md9TLr X4xhNJ+BMIuJkY6TrPIb2SZ7/rinbunnRm8cjRCBBbnMmpx0npQd4ETRoXRCkqvWJIcX bICbueibi0W+TDwy2WiXDfZEc72CwLjcQx5YhfnVyZ6/uIiD4yrr2RcdHMNMqqSCwVbV Znc0LDNUGyxk1jBqDmpZuAHI+1a8h8pVw937VAYFurmes0a9IKFDQLNcO1xaA4eO6LXp WHqQ==
X-Gm-Message-State: APjAAAUB3kJCdaFNqSFwmzR/gNp9lNhRnnOp2JEhiYKVakQXOHv9+jq0 7EJHV1NWBTmZDdjMHxZcQOwih3fwxXs97GPn7FU/OxM4Jj2NONQAfJ/BPeqbVYufdciC0MCoWvR fQhP2JOYWC508QA==
X-Google-Smtp-Source: APXvYqxtmu640U2Vc7f3+x+j9w3RikHQrpdmWEXOfzeklirEuxirUtHYK+vXw7i2sEJJSyrZpjdVcyq1Pl1PfaTSaK4=
X-Received: by 2002:a6b:3b46:: with SMTP id i67mr18875931ioa.67.1554746075653;  Mon, 08 Apr 2019 10:54:35 -0700 (PDT)
MIME-Version: 1.0
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>  <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu> 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 8 Apr 2019 11:54:09 -0600
Message-ID: 
To: Filip Skokan 
Cc: Justin Richer , oauth 
Content-Type: multipart/alternative; boundary="0000000000008e6490058608879c"
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 08 Apr 2019 17:54:40 -0000

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

Yes, the intent is that the client be configured (dynamically or statically
or however that comes to be) with one and only one expected subject, which
also includes the location in the certificate that subject will be. And
that is checked against at authentication time.

As the writer of the questionable text in question, it does seem pretty
clear to me as it is now. But as the writer, I'm also probably not well
positioned to see how it could be made more clearer. So if either of you
gentlemen have concrete text suggestions to help there, please send em for
consideration.

On Thu, Apr 4, 2019 at 2:55 PM Filip Skokan  wrote:

> Yes.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:
>
>> Thank you, I did miss that text. This should be called out more
>> explicitly in =C2=A72.1, perhaps by specifying that it is only one field=
. This
>> still doesn=E2=80=99t set precedence, but it implies that it=E2=80=99s a=
n error for a
>> client to have more than one field set of the available options. Is that
>> your read on this as well?
>>
>> =E2=80=94 Justin
>>
>> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>>
>> Justin, I had the exact same question off list and believe draft 13
>> clarified this.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>>
>> A client using the "tls_client_auth" authentication method MUST use
>> exactly one of the below metadata parameters to indicate the certificate
>> subject value that the authorization server is to expect when
>> authenticating the respective client.
>>
>> Then it lists the different dn/san properties.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>>
>>> We=E2=80=99ve just started implementation of SAN-based certificate
>>> authentication, based on the changes in version -13 of the draft. I bel=
ieve
>>> this addition is a bit unclear, due to it being added so late in the
>>> document process.
>>>
>>> My question is how does an AS determine whether to DN or SAN for
>>> certificate checking? Corollary, are these mutually exclusive or can th=
ey
>>> be used together? Currently, the specification text lists DN and SAN as=
 an
>>> =E2=80=9Cor=E2=80=9D with no indication whether this is an inclusive or=
 exclusive =E2=80=9Cor=E2=80=9D, and
>>> what to do when there=E2=80=99s overlap.
>>>
>>> This has implications both for the implementation of the server
>>> processing the request as well as the client metadata model, since the
>>> client fields are all in parallel to each other. I can see a few ways o=
f
>>> handling this.
>>>
>>>
>>> 1) One of the fields takes precedence over the other. Say for example
>>> you choose the DN field: if it=E2=80=99s set, then you do DN matching a=
nd ignore
>>> the SAN fields entirely, both in the cert and in the client=E2=80=99s r=
egistration.
>>> Inverse is true if you choose the SAN fields over the DN but the princi=
ple
>>> is the same. We should be explicit if there=E2=80=99s an intended prece=
dence
>>> between these two, and even more explicit if the DN and SAN are at equa=
l
>>> level and the AS gets to choose. We also need to be clear if it=E2=80=
=99s an error
>>> condition if both are set simultaneously, like the way that jwks and
>>> jwks_uri are mutually exclusive.
>>> 2) You set an explicit switch in your client model that says whether to
>>> use the DN or the SAN fields in comparison, and your code branches base=
d on
>>> that to either DN or SAN processing. This could also be added as an
>>> explicit client metadata field, or it could be an internal detail. If a=
n
>>> internal detail, we should be explicit about there not being a predefin=
ed
>>> precedence between the fields.
>>> 3) If it=E2=80=99s allowable to use them together, you match everything=
 that=E2=80=99s
>>> set in the client, and at least one field MUST be set.
>>>
>>>
>>> What=E2=80=99s the intended behavior for implementers, and should we be=
 more
>>> explicit about this? We are starting our implementation with (1) pendin=
g
>>> the outcome of this thread, and I=E2=80=99d be curious to know how othe=
rs are
>>> implementing this in their systems.
>>>
>>> Thanks,
>>> =E2=80=94 Justin
>>>
>>> _______________________________________________
>>> 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._

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


Yes, the intent is that the client be configured (dyn=
amically or statically or however that comes to be) with one and only one e=
xpected subject, which also includes the location in the certificate that s=
ubject will be. And that is checked against at authentication time. 

As the writer of the questionable text in question, =
it does seem pretty clear to me as it is now. But as the writer, I'm al=
so probably not well positioned to see how it could be made more clearer. S=
o if either of you gentlemen have concrete text suggestions to help there, =
please send em for consideration. 

On Thu, Apr 4, 2019 at 2:55 PM =
Filip Skokan <pa=
nva.ip@gmail.com> wrote:
Yes.

S poz=
dravem,
Filip Skokan


On Thu, 4 Apr 2019 at 2=
2:36, Justin Richer <jricher@mit.edu> wrote:






Thank you, I did miss that text. This should be called out more explicitly =
in =C2=A72.1, perhaps by specifying that it is only one field. This still d=
oesn=E2=80=99t set precedence, but it implies that it=E2=80=99s an error fo=
r a client to have more than one field set of the available
 options. Is that your read on this as well?







=E2=80=94 Justin









On Apr 4, 2019, at 4:23 PM, Filip Skokan <panva.ip@gmail.com> wrote:










Justin, I had the exact same question off list and believe=
 draft 13 clarified this.












A client using the=C2=A0"tls_client_auth" authentication met=
hod MUST use exactly one of the below metadata parameters to indicate the c=
ertificate subject value that the authorization server is to expect when au=
thenticating the respective client.









Then it lists the different dn/san properties.









S pozdravem,

Filip Skokan




















On Thu, 4 Apr 2019 at 22:20, Justin R=
icher <jricher@mit.=
edu> wrote:






We=E2=80=99ve just started implementation of SAN-based certificate aut=
hentication, based on the changes in version -13 of the draft. I believe th=
is addition is a bit unclear, due to it being added so late in the document
 process.=C2=A0






My question is how does an AS determine whether to DN or SAN for certi=
ficate checking? Corollary, are these mutually exclusive or can they be use=
d together?=C2=A0Currently, the specification text lists DN and SAN as an =
=E2=80=9Cor=E2=80=9D with no indication whether
 this is an inclusive or exclusive =E2=80=9Cor=E2=80=9D, and what to do whe=
n there=E2=80=99s overlap.=C2=A0






This has implications both for the implementation of the server proces=
sing the request as well as the client metadata model, since the client fie=
lds are all in parallel to each other. I can see a few ways of handling thi=
s.











1) One of the fields takes precedence over the other. Say for example =
you choose the DN field: if it=E2=80=99s set, then you do DN matching and i=
gnore the SAN fields entirely, both in the cert and in the client=E2=80=99s=
 registration. Inverse is true if you choose
 the SAN fields over the DN but the principle is the same. We should be exp=
licit if there=E2=80=99s an intended precedence between these two, and even=
 more explicit if the DN and SAN are at equal level and the AS gets to choo=
se. We also need to be clear if it=E2=80=99s an
 error condition if both are set simultaneously, like the way that jwks and=
 jwks_uri are mutually exclusive.=C2=A0


2) You set an explicit switch in your client model that says whether t=
o use the DN or the SAN fields in comparison, and your code branches based =
on that to either DN or SAN processing. This could also be added as an expl=
icit client metadata field,
 or it could be an internal detail. If an internal detail, we should be exp=
licit about there not being a predefined precedence between the fields.=C2=
=A0


3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s set in the client, and at least one field MUST be set.











What=E2=80=99s the intended behavior for implementers, and should we b=
e more explicit about this? We are starting our implementation with (1) pen=
ding the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are implementing this in their systems.=C2=A0







Thanks,





=E2=80=94 Justin













_______________________________________________

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.
--0000000000008e6490058608879c--


From nobody Mon Apr  8 11:06:00 2019
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 3E76112043A for ; Mon,  8 Apr 2019 11:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm6P5nC5mc3L for ; Mon,  8 Apr 2019 11:05:41 -0700 (PDT)
Received: from mail-it1-x133.google.com (mail-it1-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 1865512040D for ; Mon,  8 Apr 2019 11:05:41 -0700 (PDT)
Received: by mail-it1-x133.google.com with SMTP id k64so560238itb.5 for ; Mon, 08 Apr 2019 11:05:41 -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=GYLOe3i8VB0D6K4o+22kqpzYg1uETTuEUE9Kl//tjN0=; b=heY1393rsg2Xwc0nWyFxFj3HUhi9ddsuYxLt7BGJ6dknnaiwPAgUKJSaRWGxb02vPa Grpqmq5NaseZy6LDFeFiWFRg1UT2qgrVJ2cbgcUlnNPF5g0G0GWkzc4Gr00LPUHL0qWH 6sLZnW0r+pqqUntVrCUxqj2ZsJ7J9pNSMBU5/nOORBJ8OUPoNPonWRaWLKP7TO9f4iEw LSnsmP+w6hX0Dekn+IMoN3iwFiIMBZd+GDJ8Pn4lOvr+gbjuJQwbXyHhS2565SQF23Dd PdOi2HhUxdWnA5kWbfEIVArICsu8LS0/lapqrD7yt//pCGvP0Fkn4A+0J0o0RnDazaPq Cikg==
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=GYLOe3i8VB0D6K4o+22kqpzYg1uETTuEUE9Kl//tjN0=; b=RXfH85azYetdx9oPtwKOumtkjrt8XvdZQlVO56AJmR4kaVasYDkY/2ljvl2wsJanRW xCky+SedbfDD/HcZTAJiSadWTO1N/BCmTPK4Gco9uydOTRI1l9op58xTYIE07pDtS4L/ hkHmegdOlfiRq8crJyF13rBkve5qW3VeKyfvUKTv/MfcNrsQe19P44kO/VyonxB2Fn/H 5olsRb1mMRCmbopB5GoCd3zmFUQj2SQQnga7zp0pitrsXwrwNgGXwde7IT/MY5LDC2Ic EJKojnyI/t+VPiLYkK+JMDv+4cKyYC9d1rDAEG7fL8LizfqKwIkz+8KqzM+ItWbSZT0j LJmQ==
X-Gm-Message-State: APjAAAWU9L+1bvEEjczVNMpd6+S71LnK46/SNqdLV+X8my/rzzW2PLVZ ZujQb6DWxhkQnstQb9kk+v4G6Y0MCqYlSfhwp7jNcmIafDY=
X-Google-Smtp-Source: APXvYqxdR4LojhN+wHEdt7yerFSCIJu9DAUTgT/fDJgkFd5zkxGQ4bhOGxBaTAu9VXk9ieWW3J92t9IsfssEtaLU3Xw=
X-Received: by 2002:a24:e501:: with SMTP id g1mr20033540iti.22.1554746739938;  Mon, 08 Apr 2019 11:05:39 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 8 Apr 2019 14:05:28 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000265eb1058608afc0"
Archived-At: 
Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-jwt-introspection-response-02
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, 08 Apr 2019 18:05:47 -0000

--000000000000265eb1058608afc0
Content-Type: text/plain; charset="UTF-8"

All,

As discussed during the meeting in Prague, we are starting a WGLC on the *JWT
Response for OAuth Token Introspection* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

Please, review the document and provide feedback on any issues you see with
the document.

The WGLC will end April 22nd, 2019.

Regards,
 Rifaat and Hannes

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


All,

As dis=
cussed during the meeting in Prague, we are starting a WGLC on the JWT R=
esponse for OAuth Token Introspection document:

Please, review the document and provide f=
eedback on any issues you see with the document.

T=
he WGLC will end April 22nd, 2019.

Regards,
<=
div>=C2=A0Rifaat and Hannes


--000000000000265eb1058608afc0--


From nobody Mon Apr  8 11:11:38 2019
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 CC5381200B5 for ; Mon,  8 Apr 2019 11:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0p36Ev2HHBdT for ; Mon,  8 Apr 2019 11:11:32 -0700 (PDT)
Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (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 737201200A1 for ; Mon,  8 Apr 2019 11:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1554747091; bh=ljuUDWqcGuZkQTks5V5kSOGKWGD+VZqwmb0lvX6QWOQ=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=W8etWwlZRLew3dTk3JkICPzoidUb5a3hyveWDi1HDgziXwWPWTa/KvyUhe/xcTA+YhLELRuHwQBw1jeWVkxBZ3ANXjA60auoU9XbGROWycWtSO0cXs/A7WcN9aoT8pQ3uc2BiKu2qoz20x9aG0FIPDu99FFVxwUvbULdKolZM1IEbuqPYYk4Uie8t3855bTYK9LySBz4en/GCOf6MiSTEPc3apBx70jgJGskBNEux5KaEr+BVinVUfaejZtBEueEMHHKCA7H2UgE/qYc/L/YWhO2O9PKyYZZFETh6FTEGyiZ8Bo4PpJNzuaVlZBdYPYu/lf5ciRaaqqdrfIJio+Izw==
X-YMail-OSG: tHonMxUVM1ngfdqJuOWQlJ2dW0hLDWJ2hqlwu94aRpR5KEH1mby9aMz_isH07WH PDZQY5cIilir1CgA.KZpXepXs2HWLnsRLcmRvQPgySPbbuy9qCJPRBEtApIzvO5eu.ZG9cT55yJP t5Avm87IZnmS0AsdaH5fRlXrbqxNHkVIUdKTQCZI3M_Xtvndzs1MH.UjdTSaM35_VZPYKAOAFpA5 eIMZfFq_0EgVtHzI0qG1YYMA6HU7Yt7ubUyBbKPICfnUiHvNjpIiw2o3kVfZp6sCYzmUzsNEDMCx dtNPled6WOIGBrXceDjd9yVO02zBVzsCPHUUewVpXgSOe9Py5Qj.6Vt7P71efDpAzxDECn_Peg2p Nq8mHEbMcXZUGZ2zuhoHhJB9e9fylSDTzENnLCq.80X45ZjC9qyW_0wTO0ZkmqKKrMWe1eF0Y9dr 3_rdEaZNhMUh_D8V0mz5rQhvV0CrMoZFyrhiXqa0BpXMVk4V8wwMRY2.yAeFlXTRYqLOkzq3FAFv ViKprrtmA9aBDfjyz1Ivg..CEXKCYvvlUh2KCGueToQ1ihNw96y73lETHXNTR7yp1uTghGDhlnSR AWrIHqBnExzkAyi2A1bd5fholxjy24VSrRWPPjqcOkpGXEgFaJHDVILkQ8oN348Z2xGF.iuKQF4X nt8zYQh6SoTVFXnYiFoQDOGljCqVFo0pQ807BiVv3D8HT4.6k..rcPfPQs6NYgn5i8lz63xCjJ7g 6LAoB24MIwLwtSN8OM.FBEdUVKR2WJ9l3qkxTfj_d_w4hoI5VdDjU9EIT4ey.sNe0UwFIk.gymXt LS9mTpUUOlCIAmedqYtiTfWQ7HJrbV_BUNxK3XksiasEUW4RPbslKVHZI6IpmwrZNALpRVFvS79P v1eK9ssdcEEs4sPQT8hCE8CPQQXsAEdkIGSeft9zPHKmSBgFDTSxyX8Evk.RmPgrowThshoz8Q9K ZQ.dX9sAvvfAHKZeyFyY4EMrrl5lKXlfme68AaJFy.mB59lcqld32fiCGpgiG6zxTJi2kEo1gHUk HhOSYGbL0BOsHuF0lpPsFl2dUQQqlKL3IUbX5haSJaZ.ul1k9VU6.XMS9MtYjGW6W
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 8 Apr 2019 18:11:31 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp412.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3a1ac29a1d1307ecad5ec03e74b8a8b6;  Mon, 08 Apr 2019 18:11:28 +0000 (UTC)
To: Hans Zandbelt , oauth@ietf.org
References:  <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <81695294-fcde-4501-b520-ae48cd632a56@aol.com>
Date: Mon, 8 Apr 2019 14:11:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------595B30677CB090781449632B"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 18:11:36 -0000

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

+1 for me as well :)

On 4/8/19 1:38 PM, Hans Zandbelt wrote:
> +1
>
> Hans.
>
> On Mon, Apr 8, 2019, 19:34 John Bradley  > wrote:
>
>     I agree this should be adopted as a working group document.
>
>
>     On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
>     > Hi all,
>     >
>     > this is the call for adoption of the 'JWT Usage in OAuth2 Access
>     Tokens'?? document following the positive feedback at the last IETF
>     meeting in Prague.
>     >
>     > Here is the document:
>     > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>     >
>     > Please let us know by April 22nd whether you accept / object to the
>     > adoption of this document as a starting point for work in the OAuth
>     > working group.
>     >
>     > Ciao
>     > Hannes & Rifaat
>     >
>     > IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org 
>     > https://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


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


  
    
  
  
    +1 for me as well :)

    

    
On 4/8/19 1:38 PM, Hans Zandbelt wrote:

    

    

      
      
+1
        


        

        
Hans.

      

      

      

        
On Mon, Apr 8, 2019, 19:34
          John Bradley <ve7jtb@ve7jtb.com> wrote:

        

        
I agree this
          should be adopted as a working group document.

          

          

          On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:

          > Hi all,

          >

          > this is the call for adoption of the 'JWT Usage in OAuth2
          Access Tokens'?? document following the positive feedback at
          the last IETF meeting in Prague.

          >

          > Here is the document:

          > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00

          >

          > Please let us know by April 22nd whether you accept /
          object to the

          > adoption of this document as a starting point for work in
          the OAuth

          > working group.

          >

          > Ciao

          > Hannes & Rifaat

          >

          > IMPORTANT NOTICE: The contents of this email and any
          attachments are confidential and may also be privileged. If
          you are not the intended recipient, please notify the sender
          immediately and do not disclose the contents to any other
          person, use it for any purpose, or store or copy the
          information in any medium. Thank you.

          >

          > _______________________________________________

          > OAuth mailing list

          > OAuth@ietf.org

          > https://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


    

    

  


--------------595B30677CB090781449632B--


From nobody Mon Apr  8 11:21:11 2019
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 505AB1200A1 for ; Mon,  8 Apr 2019 11:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level: 
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEerX6Zei6om for ; Mon,  8 Apr 2019 11:21: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 E8BD51200F9 for ; Mon,  8 Apr 2019 11:21:06 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id u12so11870805iop.11 for ; Mon, 08 Apr 2019 11:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RZXPgsXFIFfqgIDGlc4RidwkyP0UR+G+TRcVQRunpxk=; b=MSFNxdDmCtW0vNu3XPRxbrtkRyqqj9AryBfYccibB/d0tUzE+BAHZ7VejMM0EAfTvv LjLpDk0WqzDCVfeZhQfkgRJPddPlEzN22/DLkRI2uRm/a8cInw7epiJVZG+0rcI8RdKW ThJ0IHkwS4JrQE5/2nGEV/yIhalTLQi/iZIpctsg1rKJXNJbyL+hS5nrBaOHqFOXe6Nl qLBs+kWT74F0L+nyifhcICGE7TO2yoG7o5TwuGl/mic1Owhzy7AWARV2t5MvkXHTrakX YnpKvPzb6Wjv8bzqEMET5lf0nnjSY2etxc8NmgI3O0o97D9ZfuRBDMrlH4D/kWTe4WK7 dScg==
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=RZXPgsXFIFfqgIDGlc4RidwkyP0UR+G+TRcVQRunpxk=; b=D1KsniI6m5Q3Qnay/kqmSnp5V83LNCXXVQDWXzlaXmPzJ6RsQEfcPZczxLsXB4jPNT ZndkYbcCqA3RwIlf7brK4y46sg+RE8MwkhcOnZpE9qBIc6dLLDdkveK6TfWrXL2nrQR1 +nmTyMe8IQSYSHwiEwYXzhhuMd4PwMGFmdslQMpar5oiiBp8BJ5AdGw7GmEV6Hias1Pb HY0tUjgTuaWUKX9MYAtBII4d12UnCqyZGj64/Du75vIK4A4xbIqOIBQ2IUvvqc0ALY// Z3TfmjK2uCtmGOH69IPue5rkepAGqQGtkTyEx9Tb2It0Fuy1eK5vArIcSXnfE+UWPigv 40zA==
X-Gm-Message-State: APjAAAWAkYlYt61tFs8rtEpYJgGcJ7ccL2k3BWiE9CKY9M5Ro5bWtTed oK44rlW9Vtu6nrXb9Njg5+kX5Z0HE2N+UeXVEsoyOR49Ja8=
X-Google-Smtp-Source: APXvYqzHszELvdrBVQh6jqbqpspC3y/KGuRfWX0mnAex3GSQYJgI3TJ5DjpSgfUNmjMnlz8n6WPXX4KSazpCbeTo/QI=
X-Received: by 2002:a5e:8e45:: with SMTP id r5mr21786077ioo.221.1554747665970;  Mon, 08 Apr 2019 11:21:05 -0700 (PDT)
MIME-Version: 1.0
References:  <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>  <81695294-fcde-4501-b520-ae48cd632a56@aol.com>
In-Reply-To: <81695294-fcde-4501-b520-ae48cd632a56@aol.com>
From: William Denniss 
Date: Mon, 8 Apr 2019 11:20:54 -0700
Message-ID: 
To: George Fletcher 
Cc: Hans Zandbelt , oauth 
Content-Type: multipart/alternative; boundary="00000000000058f6bf058608e6e9"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2019 18:21:10 -0000

--00000000000058f6bf058608e6e9
Content-Type: text/plain; charset="UTF-8"

I support adoption of this draft as a working group document.

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher  wrote:

> +1 for me as well :)
>
> On 4/8/19 1:38 PM, Hans Zandbelt wrote:
>
> +1
>
> Hans.
>
> On Mon, Apr 8, 2019, 19:34 John Bradley  wrote:
>
>> I agree this should be adopted as a working group document.
>>
>>
>> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
>> > Hi all,
>> >
>> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
>> Tokens'?? document following the positive feedback at the last IETF meeting
>> in Prague.
>> >
>> > Here is the document:
>> > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>> >
>> > Please let us know by April 22nd whether you accept / object to the
>> > adoption of this document as a starting point for work in the OAuth
>> > working group.
>> >
>> > Ciao
>> > Hannes & Rifaat
>> >
>> > IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


I support adoption of this draft as a working group docume=
nt.

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote=
:

 =20
   =20
 =20
  

    +1 for me as well :)=


    

    
On 4/8/19 1:=
38 PM, Hans Zandbelt wrote:

    

    

     =20
      
+1
        


        

        
Hans.

      

      

      

        
On Mon, Apr 8, 2019, 19:34
          John Bradley <ve7jtb@ve7jtb.com> wrote:

        

        
I agree this
          should be adopted as a working group document.

          

          

          On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:

          > Hi all,

          >

          > this is the call for adoption of the 'JWT Usage in OAuth=
2
          Access Tokens'?? document following the positive feedback at
          the last IETF meeting in Prague.

          >

          > Here is the document:

          > https:=
//tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00

          >

          > Please let us know by April 22nd whether you accept /
          object to the

          > adoption of this document as a starting point for work in
          the OAuth

          > working group.

          >

          > Ciao

          > Hannes & Rifaat

          >

          > IMPORTANT NOTICE: The contents of this email and any
          attachments are confidential and may also be privileged. If
          you are not the intended recipient, please notify the sender
          immediately and do not disclose the contents to any other
          person, use it for any purpose, or store or copy the
          information in any medium. Thank you.

          >

          > _______________________________________________

          > OAuth mailing list

          > OAuth@ietf.org

          > https://www.ietf.org/mailman/l=
istinfo/oauth

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinf=
o/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




--00000000000058f6bf058608e6e9--


From nobody Mon Apr  8 11:33:50 2019
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 47B851202F7 for ; Mon,  8 Apr 2019 11:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 7MiGVUIPxb8i for ; Mon,  8 Apr 2019 11:33:45 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-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 308101200EC for ; Mon,  8 Apr 2019 11:33:45 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id q14so760882itk.0 for ; Mon, 08 Apr 2019 11:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SvgsK4l5qQH22lcWioFSxEIi4vm0CwKppJnn6YPBO6Y=; b=NBJgSL9KZmVNPcxNPdBm+MYPiJ8E8vTqe30byey+3bB4XboZkb0DMic7z2nWSgzMyi 1Zb/vQ7aS00z540aK01/TLnh2L+3CMjHspB/qfBIQ+C9so/ACHVi6wpkl5RERqVU2Yio ETL6bxFhKt5KySRfeDDlgJhDaqrAl7Wo+HEdo=
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=SvgsK4l5qQH22lcWioFSxEIi4vm0CwKppJnn6YPBO6Y=; b=JUvunaiJCtKd9OfRvpFTlfwF4CMzouSKy3JdPm7DV1GsfDpQUgqfhk8naix9OGybql MJrdDbYJOPVIL+BL7W385fiACJATYokzYAKGiv6C4TYj+wLgcjZuU5n7cIAcQFea7KG/ ePgMn8maNbGy1bXRztj6hZmu4CpuYvj9ib/pKSddKdXs/TFgYTO8VJkBx6Dk78b7ryK1 33eHzSKlB/Yw/5LJ/0bvb787A240nLBYHgehk2SGp1OkNAQDyBtXesquys9rQKpPxovZ kPUe495lSaVRZG611TRnRrwqq2Cdz1xH9wk/qfgO1TXGCpVqlX1pdTYGnOLSt7cVsjeP 8Y9w==
X-Gm-Message-State: APjAAAUGwGLftWQeeUVYPmHlIOEC1r1Xivtn4rD1+BUToDzZSy+l3GSa 7hWAWjtP8/9WS+R9J/ZZESYyQnfragtOEr8i+bG2daBYNf5/6zepan1Mz+qtNnSoPSJlL8XGv3C QGeSi6eY39pu/Yg==
X-Google-Smtp-Source: APXvYqy2dbllgAq2q2sO84VG5SxK3KjYyB/agCHzUhS4SnLg9jhE0dOslG8qDo730MfXIojzu1SyffwuONeoCR9SWZw=
X-Received: by 2002:a24:d9d0:: with SMTP id p199mr22510708itg.104.1554748424182;  Mon, 08 Apr 2019 11:33:44 -0700 (PDT)
MIME-Version: 1.0
References:  <2a523e40-470b-4727-4e38-7a60552a285a@aol.com>     
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 8 Apr 2019 12:33:17 -0600
Message-ID: 
To: Vittorio Bertocci 
Cc: David Waite , George Fletcher , IETF oauth WG 
Content-Type: multipart/alternative; boundary="00000000000089f83805860913ad"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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, 08 Apr 2019 18:33:49 -0000

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

"quotes my own articles on the matter extensively" - I know and almost
mentioned that but didn't want to further embolden your ego :)

Silence is rarely assent. Especially near the end of the last session of
the last day of a workshop. And when I've got a train to catch.

I am somewhat sympathetic to the "... more reasons to provide guidance on
how to do so being aware of pitfalls ... " line of reasoning. But I'd
already indicated my intent to not fight you on this one anymore so that
doesn't change much. Carry on then.



On Thu, Apr 4, 2019 at 11:20 AM Vittorio Bertocci  wrote:

> But before I get in the details, let me make an uber-point..
> I am acutely aware of the potential for confusion and abuse in the contex=
t
> of OAuth and sign in, the article you pointed to quotes my own articles o=
n
> the matter extensively. But there are concrete aspects that need to be
> considered about what developers are trying to achieve in practice.
> OAuth2 is the de facto mechanism to secure API calls nowadays. That
> includes scenarios not directly addressed by the spec, such as first part=
y
> APIs. People do that for 1st party APIs as well because they can leverage=
 a
> well supported mechanism for driving authentication experiences and
> outsource authentication to products and services.
> Forgetting for a second about the fact that 3rd party APIs can use
> identity and authentication levels info as well, let me focus for a secon=
d
> on 1st party APIs. From the functionality perspective, delivering an app =
as
> a web site or as a native client+API combination doesn't change the
> business requirements and the information a backend needs to do its job.
> Given that we tell people NOT to use ID tokens for calling APIs: if a
> developer chooses to deliver their app as a native client+API instead of =
a
> web site, the only artifact they have available is the access token. So
> either we embed the info in the access token, and we do what we can to
> prevent abuse and the most likely pitfalls/privacy challenges/etc in the
> guidance, or we find a way for 1st party APIs to consume ID tokens (which
> is problematic- I discussed this with John and Nat at OSW and the place w=
e
> got stuck on was that we can; safely use sender constrain in that
> scenario). And to pre-empt comments on userinfo, that's asking for a lot =
of
> extra moving parts- the only outcome will be that people will keep
> embedding the info they need in the AT, but will do so in non-interoperab=
le
> way, and without the guidance and warnings that would at least contain so=
me
> of the damage.
>
> That said, inline.
>
> My concern isn't with reusing the names/types of the claims per se.  But
>> more generally that codifying the use of certain authentication-centric
>> claims in the context of an access token furthers the potential confusio=
n
>> around authentication vs. authorization that has been a nagging problem =
for
>> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
>
> see preamble.
>
> I  understand what you are saying but but personally do not find it
>> sufficiently compelling.  But that's just my opinion and not a hill I wa=
nt
>> to die on (at the present time anyway)..
>
> Noted :) does the fact that in some scenarios the AT might be the *only*
> artifact a backend will receive change the stance?
>
>  By the time it came up again near the end of the last unconference
>> session, I wasn't wanting to prolong things because I was kinda worn out
>> for the day and wanting to get to Frankfurt that evening before sunset
>> ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).
>
> Sorry for having tired you out :) at the time I echoed back what was
> suggested (to reflect the original values in the session) precisely to ma=
ke
> sure everyone had a chance to push back, and I got lots of nods (includin=
g
> from John who was in the first row). I misinterpreted your silence as
> assent, given that during that session you did chime in on other matters.=
.
> but I was expecting the discussion to keep going on the ML anyway, so it'=
s
> all according to plan :)
>
>  FWIW, to me, George's suggestion "assume[ing] that the auth_time value
>> should be updated to the latest time at which the user authenticated"
>> though some unspecified and in many cases non-existent link between the =
AT
>> and a current user session at the AS is an example of how
>> authentication-centric claims in an access token can be confusing.
>
>  I agree it can be confusing, but to me that makes the need to provide
> guidance on it more compelling, not less. There are important scenarios
> where access decisions are made on the basis of that information, and
> implementations WILL find a way to get the info they are interested into.
> To me that's all the more reasons to provide guidance on how to do so bei=
ng
> aware of pitfalls and with whatever protections we can put in place, as
> opposed to leave developers to their own device.
>
> On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell  40pingidentity.com@dmarc.ietf.org> wrote:
>
>> A few remarks/responses inline below this time...
>>
>> On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote:
>>
>>> Thanks guys for the comment, sorry for the delay in addressing them.
>>> I am not married to the claim types used in here, so if you think that
>>> reusing the ones in the id_token can cause confusion we should expand o=
n
>>> the specific ways in which you think might go south.
>>>
>>
>> My concern isn't with reusing the names/types of the claims per se.  But
>> more generally that codifying the use of certain authentication-centric
>> claims in the context of an access token furthers the potential confusio=
n
>> around authentication vs. authorization that has been a nagging problem =
for
>> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
>>
>>
>> However I think it's important that the information on say, whether the
>>> current token was obtained using MFA or a specific authentication facto=
r is
>>> something that API developers can legitimately latch to when doing
>>> authorization decisions. From the perspective of a developer modeling a
>>> solution, whether functionality is delivered as a route in a postback b=
ased
>>> web app (hence receiving an id_token or derived) or as an API consumed =
by a
>>> native app, the business requirement gating access to that functionalit=
y
>>> doesn't change. If the admin managing that resource establishes that ac=
cess
>>> should be performed only via MFA, the developer should be equipped to
>>> enforce that regardless of the stack used to expose functionality (web =
app,
>>> API).
>>> Although it is true that triggering the desired behavior might be
>>> achieved by the resource setting and contract with the AS, along the li=
nes
>>> of what David said, it's actually not uncommon for those policies to be
>>> assigned on the resource AFTER the current session was established and/=
or
>>> the corresponding AT was obtained and cached. Furthermore, the requirem=
ent
>>> might be more granular than an AS policy can tolerate (an API might
>>> requires MFA only for certain routes, hence hard to express in a static
>>> policy) and triggered in form of challenges. So the situation in which =
you
>>> have an AT with the right issuer, audience, etc but was obtained with a
>>> policy now obsolete/unacceptable to the RP is strong. Requesting to sup=
port
>>> revocation just for this seems overkill, especially given that the scen=
ario
>>> in which the same logical app is exposed as both web app and native
>>> client+API, the code consuming those claims is already in place. It jus=
t
>>> makes intuitive sense for developers.
>>> In summary, one can take steps to push as much of the MFA requirements
>>> to the AS settings for a particular request, but ultimately the desire =
of
>>> the API developer to enforce that it actually happened is a requirement=
 I
>>> encountered often in practice. Anything providing extra context to refi=
ne
>>> decisions about it (like auth_time, which might inform decisions about
>>> whether to accept an MFA check occurred N minutes ago or refuse access)=
.
>>>
>>
>> I understand what you are saying but but personally do not find it
>> sufficiently compelling.  But that's just my opinion and not a hill I wa=
nt
>> to die on (at the present time anyway)..
>>
>>
>>
>>> I thought that reusing the existing names for the same concepts just
>>> made sense (dev existing skills, existing codebases, etc etc) and
>>> especially in the case in which the values are exactly the same, and th=
e
>>> idea seemed to receive good support during OSW.
>>>
>>
>> Our recollection of OSW differs somewhat. As I recall there was support
>> for pointing to identity claims from OIDC for additional end-user info. =
But
>> there was some grumbling (from John and myself at least) at first mentio=
n
>> of acr/amr and auth_time. By the time it came up again near the end of t=
he
>> last unconference session, I wasn't wanting to prolong things because I =
was
>> kinda worn out for the day and wanting to get to Frankfurt that evening
>> before sunset ('cause I like to do stuff like this:
>> https://flic.kr/p/2fiAaPe :) ).
>>
>>
>>
>>> But I am completely open to change it of course, especially for cases
>>> like the one identified by George.
>>>
>>
>> FWIW, to me, George's suggestion "assume[ing] that the auth_time value
>> should be updated to the latest time at which the user authenticated"
>> though some unspecified and in many cases non-existent link between the =
AT
>> and a current user session at the AS is an example of how
>> authentication-centric claims in an access token can be confusing.
>>
>>
>>
>>
>>> WDYT?
>>>
>>> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote:
>>>
>>>> +1 to David's question here. I'd like to see justifying use cases
>>>> (beyond just the fact that some people are already doing it) for auth_=
time,
>>>> acr, and amr to be available in OAuth JWT access tokens.. Those claims=
 are
>>>> defined for, and in the context of, an ID Token and I fear that codify=
ing
>>>> their use in an access token will lead to misuse and/or confusion.
>>>>
>>>> On Mon, Apr 1, 2019 at 1:03 PM David Waite <
>>>> david@alkaline-solutions.com> wrote:
>>>>
>>>>> Do we know if there is a justifying use case for auth_time, acr, and
>>>>> amr to be available in OAuth JWT access tokens? These are meant to be
>>>>> messages about the client, either directly (in the case of client
>>>>> credentials) or about its delegated authorization of the user.
>>>>>
>>>>> Embedding attributes about the user (such as group membership and
>>>>> roles) can be used for the resource to make finer-grained decisions t=
han
>>>>> scopes, but normally I would expect say acr limitations enforced by a
>>>>> resource to instead be controlled by the AS requiring a higher qualit=
y
>>>>> authentication to release certain scopes.
>>>>>
>>>>> Thats of course not to say extensions to OAuth such as OIDC can=E2=80=
=99t
>>>>> provide these values, just that they might better be defined by those
>>>>> extensions.
>>>>>
>>>>> -DW
>>>>>
>>>>> On Apr 1, 2019, at 9:12 AM, George Fletcher <
>>>>> gffletch=3D40aol.com@dmarc.ietf.org> wrote:
>>>>>
>>>>> Thanks for writing this up. One comment on auth_time...
>>>>>
>>>>>    auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core ].
>>>>>       Important: as this claim represents the time at which the end u=
ser
>>>>>       authenticated, its value will remain the same for all the JWT
>>>>>       access tokens issued within that session.  For example: all the
>>>>>       JWT access tokens obtained with a given refresh token will all
>>>>>       have the same value of auth_time, corresponding to the instant =
in
>>>>>       which the user first authenticated to obtain the refresh token.
>>>>>
>>>>>
>>>>> During a current session a user can be challenged for additional
>>>>> credentials or required to re-authenticate due to a number of differe=
nt
>>>>> reasons. For example, OIDC prompt=3Dlogin or max_age=3DNNN. In this c=
ontext,
>>>>> I'd assume that the auth_time value should be updated to the latest t=
ime at
>>>>> which the user authenticated.
>>>>>
>>>>> If we need a timestamp for when the "session" started, then there
>>>>> could be a session_start_time claim.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>>>>
>>>>> Dear all,
>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 acces=
s
>>>>> tokens. You can find it in
>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jw=
t/
>>>>> .
>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presentin=
g
>>>>> remotely). I look forward for your comments!
>>>>>
>>>>> Here's just a bit of backstory, in case you are interested in how thi=
s
>>>>> doc came to be. The trajectory it followed is somewhat unusual.
>>>>>
>>>>>    - Despite OAuth2 not requiring any specific format for ATs,
>>>>>    through the years I have come across multiple proprietary solution=
 using
>>>>>    JWT for their access token. The intent and scenarios addressed by =
those
>>>>>    solutions are mostly the same across vendors, but the syntax and
>>>>>    interpretations in the implementations are different enough to pre=
vent
>>>>>    developers from reusing code and skills when moving from product t=
o product.
>>>>>    - I asked several individuals from key products and services to
>>>>>    share with me concrete examples of their JWT access tokens (THANK =
YOU
>>>>>    Dominick Baier (IdentityServer), Brian Campbell (PingIdentity),
>>>>>    Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens a=
nd
>>>>>    explanations!).
>>>>>    I studied and compared all those instances, identifying
>>>>>    commonalities and differences.
>>>>>    - I put together a presentation summarizing my findings and
>>>>>    suggesting a rough interoperable profile (slides:
>>>>>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci=
_-_a_jwt_profile_for_ats.pptx
>>>>>    
>>>>>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>>>>>    - The presentation was followed up by 1.5 hours of unconference
>>>>>    discussion, which was incredibly valuable to get tight-loop feedba=
ck and
>>>>>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuv=
inov,
>>>>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all
>>>>>    there and contributed generously to the discussion. Thank you!!!
>>>>>    Note: if you were at OSW2019, participated in the discussion and
>>>>>    didn't get credited in the draft, my apologies: please send me a n=
ote and
>>>>>    I'll make things right at the next update.
>>>>>    - On my flight back I did my best to incorporate all the ideas and
>>>>>    feedback in a draft, which will be discussed at IETF104 tomorrow. =
Rifaat,
>>>>>    Hannes and above all Brian were all super helpful in negotiating t=
he
>>>>>    mysterious syntax of the RFC format and submission process.
>>>>>
>>>>> I was blown away by the availability, involvement and willingness to
>>>>> invest time to get things right that everyone demonstrated in the pro=
cess.
>>>>> This is an amazing community.
>>>>> V.
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing listOAuth@ietf.org https://www.ietf.or=
g/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
>>>>>
>>>>
>>>> *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, pleas=
e
>>>> 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
>>>>
>>>
>> *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.*
>
>

--=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._

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


"quotes my own articles on the matter extensivel=
y" - I know and almost mentioned that but didn't want to further e=
mbolden your ego :) 

 Silence is rarely assent=
. Especially near the end of the last session of the last day of a workshop=
. And when I've got a train to catch. 

I a=
m somewhat sympathetic to the "... more reasons to provide guidance on=
 how to do so being aware of pitfalls ... " line of reasoning. But I&#=
39;d already indicated my intent to not fight you on this one anymore so th=
at doesn't change much. Carry on then. 


On Thu, Apr 4, 2019 at 11:20 AM Vittorio Bertocci <Vittorio=3D40auth0.com@d=
marc.ietf.org> wrote:
But before I get in the details, let me make =
an uber-point..=C2=A0
I am acutely aware of the potential for confusion=
 and abuse in the context of OAuth and sign in, the article you pointed to =
quotes my own articles on the matter extensively. But there are concrete as=
pects that need to be considered about what developers are trying to achiev=
e in practice.
OAuth2 is the de facto mechanism to secure API calls now=
adays. That includes scenarios not directly addressed by the spec, such as =
first party APIs. People do that for 1st party APIs as well because they ca=
n leverage a well supported mechanism for driving authentication experience=
s and outsource authentication to products and services.=C2=A0
<=
div>Forgetting for a second about the fact that 3rd party APIs can use iden=
tity and authentication levels info as well, let me focus for a second on 1=
st party APIs. From the functionality perspective, delivering an app as a w=
eb site or as a native client+API combination doesn't change the busine=
ss requirements and the information a backend needs to do its job.=C2=A0
Given that we tell people NOT to use ID tokens for calling APIs: if=
 a developer chooses to deliver their app as a native client+API instead of=
 a web site, the only artifact they have available is the access token. So =
either we embed the info in the access token, and we do what we can to prev=
ent abuse and the most likely pitfalls/privacy challenges/etc in the guidan=
ce, or we find a way for 1st party APIs to consume ID tokens (which is prob=
lematic- I discussed this with John and Nat at OSW and the place we got stu=
ck on was that we can; safely use sender constrain in that scenario). And t=
o pre-empt comments on userinfo, that's asking for a lot of extra movin=
g parts- the only outcome will be that people will keep embedding the info =
they need in the AT, but will do so in non-interoperable way, and without t=
he guidance and warnings that would at least contain some of the damage.

That said, inline.

My concern isn't with reusing th=
e names/types of the claims per se.=C2=A0 But more generally that codifying=
 the use of certain authentication-centric claims in the context of an acce=
ss token furthers the potential confusion around authentication vs. authori=
zation that has been a nagging problem for OAuth (i.e. the=C2=A0https://oauth.net/articles/authentication/=C2=A0article).=C2=A0
see pream=
ble.

I=C2=A0=C2=A0understand what you are saying bu=
t but personally do not find it sufficiently compelling.=C2=A0 But that'=
;s just my opinion and not a hill I want to die on (at the present time any=
way)..=C2=A0
Noted :) does the fact th=
at in some scenarios the AT might be the *only* artifact a backend will rec=
eive change the stance?

=C2=A0By the time it came up again near the end of the=
 last unconference session, I wasn't wanting to prolong things because =
I was kinda worn out for the day and wanting to get to Frankfurt that eveni=
ng before sunset ('cause I like to do stuff like this:=C2=A0http=
s://flic.kr/p/2fiAaPe=C2=A0:) ).
Sorry for having tired you out :) at the time I echoed back what was sugge=
sted (to reflect the original values in the session) precisely to make sure=
 everyone had a chance to push back, and I got lots of nods (including from=
 John who was in the first row). I misinterpreted your silence as assent, g=
iven that during that session you did chime in on other matters.. but I was=
 expecting the discussion to keep going on the ML anyway, so it's all a=
ccording to plan :)

=C2=A0FWIW, to me, George's suggestion "assume[in=
g] that the auth_time value should be updated to the latest time at which t=
he user authenticated" though some unspecified and in many cases non-e=
xistent link between the AT and a current user session at the AS is an exam=
ple of how authentication-centric claims in an access token can be confusin=
g.=C2=A0
=C2=A0I agree it can be confu=
sing, but to me that makes the need to provide guidance on it more compelli=
ng, not less. There are important scenarios where access decisions are made=
 on the basis of that information, and implementations WILL find a way to g=
et the info they are interested into. To me that's all the more reasons=
 to provide guidance on how to do so being aware of pitfalls and with whate=
ver protections we can put in place, as opposed to leave developers to thei=
r own device.=C2=A0

On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <=
bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
=

A few remarks/responses inline below this time... 
=

On Wed=
, Apr 3, 2019 at 1:38 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Thanks guys for the comment, sorry for the delay in addressi=
ng them.
I am not married to the claim types used in here, so if you th=
ink that reusing the ones in the id_token can cause confusion we should exp=
and on the specific ways in which you think might go south.

=C2=A0

However=
 I think it's important that the information on say, whether the curren=
t token was obtained using MFA or a specific authentication factor is somet=
hing that API developers can legitimately latch to when doing authorization=
 decisions. From the perspective of a developer modeling a solution, whethe=
r functionality is delivered as a route in a postback based web app (hence =
receiving an id_token or derived) or as an API consumed by a native app, th=
e business requirement gating access to that functionality doesn't chan=
ge. If the admin managing that resource establishes that access should be p=
erformed only via MFA, the developer should be equipped to enforce that reg=
ardless of the stack used to expose functionality (web app, API).=C2=A0
Although it is true that triggering the desired behavior might be ac=
hieved by the resource setting and contract with the AS, along the lines of=
 what David said, it's actually not uncommon for those policies to be a=
ssigned on the resource AFTER the current session was established and/or th=
e corresponding AT was obtained and cached. Furthermore, the requirement mi=
ght be more granular than an AS policy can tolerate (an API might requires =
MFA only for certain routes, hence hard to express in a static policy) and =
triggered in form of challenges. So the situation in which you have an AT w=
ith the right issuer, audience, etc but was obtained with a policy now obso=
lete/unacceptable to the RP is strong. Requesting to support revocation jus=
t for this seems overkill, especially given that the scenario in which the =
same logical app is exposed as both web app and native client+API, the code=
 consuming those claims is already in place. It just makes intuitive sense =
for developers.=C2=A0 =C2=A0
In summary, one can take steps to pu=
sh as much of the MFA requirements to the AS settings for a particular requ=
est, but ultimately the desire of the API developer to enforce that it actu=
ally happened=C2=A0is a requirement I encountered often in practice. Anythi=
ng providing extra context to refine decisions about it (like auth_time, wh=
ich might inform decisions about whether to accept an MFA check occurred N =
minutes ago or refuse access).

=
I understand what you are saying but but personally do not find it sufficie=
ntly compelling.=C2=A0 But that's just my opinion and not a hill I want=
 to die on (at the present time anyway).. 
=C2=A0
<=
br>

I thought that reusing the existing names for the same=
 concepts just made sense (dev existing skills, existing codebases, etc etc=
) and especially in the case in which the values are exactly the same, and =
the idea seemed to receive good support during OSW.

Our recollection of OSW differs somewhat. As I recall =
there was support for pointing to identity claims from OIDC for additional =
end-user info. But there was some grumbling (from John and myself at least)=
 at first mention of acr/amr and auth_time. By the time it came up again ne=
ar the end of the last unconference session, I wasn't wanting to prolon=
g things because I was kinda worn out for the day and wanting to get to Fra=
nkfurt that evening before sunset ('cause I like to do stuff like this:=
 https://flic.kr/p/=
2fiAaPe :) ).

=C2=A0
 But I am completel=
y open to change it of course, especially for cases like the one identified=
 by George.

FWIW, to me, George=
's suggestion "assume[ing] that the auth_time value should be upda=
ted to the latest time at which the user authenticated" though some un=
specified and in many cases non-existent link between the AT and a current =
user session at the AS is an example of how authentication-centric claims i=
n an access token can be confusing. 


=C2=A0
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell &l=
t;bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
+1 to David's question here. I'd like to see justifying use cas=
es (beyond just the fact that some people are already doing it) for auth_ti=
me, acr, and amr to be available in OAuth JWT access tokens.. Those claims =
are defined for, and in the context of, an ID Token and I fear that codifyi=
ng their use in an access token will lead to misuse and/or confusion. 
<=
/div>

On Mon, Apr 1, 2019 at 1:03 PM David Waite <david@alkaline-solutions.com=
> wrote:
Do we know if there is a justifying use case for auth_time, acr, and amr t=
o be available in OAuth JWT access tokens? These are meant to be messages a=
bout the client, either directly (in the case of client credentials) or abo=
ut its delegated authorization of the user.

Em=
bedding attributes about the user (such as group membership and roles) can =
be used for the resource to make finer-grained decisions than scopes, but n=
ormally I would expect say acr limitations enforced by a resource to instea=
d be controlled by the AS requiring a higher quality authentication to rele=
ase certain scopes.

Thats of course not to say ext=
ensions to OAuth such as OIDC can=E2=80=99t provide these values, just that=
 they might better be defined by those extensions.

-DW

On Apr 1, 2019, at 9:12 A=
M, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

 =20
   =20
 =20
  

    Thanks for writing this
      up. One comment on auth_time...

    

    
   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      authenticated, its value will remain the same for all the JWT
      access tokens issued within that session.  For example: all the
      JWT access tokens obtained with a given refresh token will all
      have the same value of auth_time, corresponding to the instant in
      which the user first authenticated to obtain the refresh token.



    During a current session a
      user can be challenged for additional credentials or required to
      re-authenticate due to a number of different reasons. For example,
      OIDC prompt=3Dlogin or max_age=3DNNN. In this context, I'd assume=
 that
      the auth_time value should be updated to the latest time at which
      the user authenticated. 

      

      If we need a timestamp for when the "session" started, then=
 there
      could be a session_start_time claim.

      

      Thanks,

      George

      

    
    
On 3/24/19 7:29 PM, Vittorio Bertocci
      wrote:

    

    

     =20
      

        

          
Dear all,
            
I just submitted a draft describing a JWT profile for
              OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access=
-token-jwt/.

            
I have a slot to discuss this tomorrow at IETF 104
              (I'll be presenting remotely). I look forward for your
              comments!

            

            


            

            
Here's just a bit of backstory, in case you are
              interested in how this doc came to be. The trajectory it
              followed is somewhat unusual.

            

              
    
                
  • Despite OAuth2 not requiring any specific format for
                  ATs, through the years I have come across multiple
                  proprietary solution using JWT for their access token.
                  The intent and scenarios addressed by those solutions
                  are mostly the same across vendors, but the syntax and
                  interpretations in the implementations are different
                  enough to prevent developers from reusing code and
                  skills when moving from product to product.
    • 
                
  • I asked several individuals from key products and
                  services to share with me concrete examples of their
                  JWT access tokens (THANK YOU Dominick Baier
                  (IdentityServer),=C2=A0Brian
                    Campbell (PingIdentity), Daniel Dobalian
                    (Microsoft), Karl Guinness (Okta) for the tokens and
                    explanations!). 
    
                  I studied and compared all those instances,
                  identifying commonalities and differences.=C2=A0
    • 
                
  • I put together a presentation summarizing my
                  findings and suggesting a rough interoperable profile
                  (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_=
jwt_profile_for_ats.pptx
                  ) - got early feedback from Filip Skokan on it. Thx
                  Filip!
    • 
                
  • The presentation was followed up by 1.5 hours of
                  unconference discussion, which was incredibly valuable
                  to get tight-loop feedback and incorporate new ideas.
                  John Bradley, Brian Campbell Vladimir Dzhuvinov,
                  Torsten Lodderstedt,=
=C2=A0Nat
                    Sakimura, Hannes Tschofenig=C2=A0were all there
                  and contributed generously to the discussion. Thank
                  you!!!
    
                  Note: if you were at OSW2019, participated in the
                  discussion and didn't get credited in the draft, my
                  apologies: please send me a note and I'll make things
                  right at the next update.
    • 
                
  • On my flight back I did my best to incorporate all
                  the ideas and feedback in a draft, which will be
                  discussed at IETF104 tomorrow. Rifaat, Hannes and
                  above all Brian were all super helpful in negotiating
                  the mysterious syntax of the RFC format and submission
                  process.
    • 
              

              
I was blown away by the availability, involvement and
                willingness to invest time to get things right that
                everyone demonstrated in the process. This is an amazing
                community.=C2=A0

            

            
V.

          

        

      

      

      

      
_______________________________________________
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






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








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.<=
/blockquote>




<=
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.
--00000000000089f83805860913ad--


From nobody Mon Apr  8 16:23:46 2019
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 1BF92120125 for ; Mon,  8 Apr 2019 16:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level: 
X-Spam-Status: No, score=-2.311 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 UW27e2HbM1Ts for ; Mon,  8 Apr 2019 16:23:42 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 B0B6F120123 for ; Mon,  8 Apr 2019 16:23:42 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38NIssV171500; Mon, 8 Apr 2019 23:23:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=bPK9DmV9d1D8ruis/Blh63VK+N3VC3fgJC5AOGV0QQ8=; b=AgO+iPAuucOF3ALjoA9jKI4Aa8kbneix4QJRlMVCZb/GjpDZb7KdcHS4HQPdS46SYhV7 knV1J0G1LivyOwLZjGEWUbNtsv0Nwyp3oRW+2QkV6FKofj6WXbj6qfZOlAN5yt3qo8qm YCQqnV0aokUK8HG1ke+TlWW/qbpitBbZo02Ue0i6fz2cicS6tEhkzf9d0bTg9hSrCPKR 4y8KplAA6vEM3eqJJDkoh9e0jmRBs+gQPeztbAf6DZtHffHyftSL1DGnEEgvqjeGgGAi PMX4Qv+MaBisRL8bp7XgQuausUGacqJDl/H9TS15k3sEX5Ge1Cf1oaAvOC3EUhGyK1UM 1Q== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2rpkhssmq2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 23:23:40 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38NNWgR095873; Mon, 8 Apr 2019 23:23:40 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2rpj5a8dyb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 23:23:39 +0000
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x38NNcY2009474; Mon, 8 Apr 2019 23:23:38 GMT
Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Apr 2019 16:23:38 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-71357F0F-E2AC-452F-B98D-73B14906330C
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com>
Date: Mon, 8 Apr 2019 16:23:36 -0700
Cc: Daniel Fett , oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com>
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com>
To: George Fletcher 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080168
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080168
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 08 Apr 2019 23:23:45 -0000

--Apple-Mail-71357F0F-E2AC-452F-B98D-73B14906330C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Question. One of the issues that Justin Richer=E2=80=99s signing draft tried=
 to address was url modification by tls terminators/load balencers/proxies/a=
pi gateways etc.=20

How do you see this issue in dpop? Is it a problem?=20

Phil

> On Apr 3, 2019, at 9:01 AM, George Fletcher  wrote:
>=20
> Perfect! Thank you! A couple comments on version 01...
>=20
>    POST /token HTTP/1.1
>    Host: server.example.com
>    Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
>    DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>=20
>    grant_type=3Dauthorization_code
>    &code=3DSplxlOBeZQQYbYS6WxSbIA
>    &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>    (remainder of JWK omitted for brevity)
>=20
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding h=
eader...
>=20
> Also, there is no discussion of the DPoP-Binding header outside of the tok=
en request, but I suspect that is the desired way to communicate the DPoP-Pr=
oof to the RS.
>=20
> Possibly an example in the session for presenting the token to the RS woul=
d help.
>=20
> Thanks,
> George
>=20
>> On 4/3/19 11:39 AM, Daniel Fett wrote:
>> This is fixed in -01:
>>=20
>> https://tools.ietf.org/html/draft-fett-oauth-dpop-01
>>=20
>> -Daniel
>>=20
>>> Am 03.04.19 um 17:28 schrieb George Fletcher:
>>> A quick question regarding...
>>>=20
>>>    o  "http_uri": The HTTP URI used for the request, without query and
>>>       fragment parts (REQUIRED).
>>>=20
>>> Is 'without' supposed to be 'with' ? The example shows the http_uri *wit=
h* the query parameters :)
>>>=20
>>>> On 3/28/19 6:17 AM, Daniel Fett wrote:
>>>> Hi all,
>>>>=20
>>>> I published the first version of the DPoP draft at https://tools.ietf.o=
rg/html/draft-fett-oauth-dpop-00
>>>>=20
>>>> Abstract
>>>>=20
>>>>    This document defines a sender-constraint mechanism for OAuth 2.0
>>>>    access tokens and refresh tokens utilizing an application-level
>>>>    proof-of-possession mechanism based on public/private key pairs.
>>>>=20
>>>> Thanks for the feedback I received so far from John, Mike, Torsten, and=
 others during today's session or before!
>>>>=20
>>>> If you find any errors I would welcome if you open an issue in the GitH=
ub repository at https://github.com/webhamster/draft-dpop
>>>>=20
>>>> - Daniel   =20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&=
r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DeQpusEFY7fROXNfEJmh0Qzke=
jgdgaVnILpbm2q8x9II&s=3D8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=3D

--Apple-Mail-71357F0F-E2AC-452F-B98D-73B14906330C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Question. One of the issues that Justin Ric=
her=E2=80=99s signing draft tried to address was url modification by tls ter=
minators/load balencers/proxies/api gateways etc. 

H=
ow do you see this issue in dpop? Is it a problem? 

Phil

On Apr 3, 2019=
, at 9:01 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:


 =20
    
 =20
 =20
    Perfect! Thank you! A couple comments on version 01...

    

    
   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=3Dauthorization_code
   &code=3DSplxlOBeZQQYbYS6WxSbIA
   &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)

    

    I believe the "(remainder of JWK..." should be moved to the
    DPoP-Binding header...

    

    Also, there is no discussion of the DPoP-Binding header outside of
    the token request, but I suspect that is the desired way to
    communicate the DPoP-Proof to the RS.

    

    Possibly an example in the session for presenting the token to the
    RS would help.

    

    Thanks,

    George

    

    
On 4/3/19 11:39 AM, Daniel Fett wrote:
    

    

      
      
This is fixed in -01:

      


      

      
https://to=
ols.ietf.org/html/draft-fett-oauth-dpop-01

      


      

      
-Daniel

      

      


      

      
Am 03.04.19 um 17:28 schrieb George
        Fletcher:

      

      

        
        A quick question
          regarding...

        

        
   o  "http_uri": The HTTP URI used for the r=
equest, without query and
      fragment parts (REQUIRED).

        

          Is 'without' supposed to be 'with' ? The example shows the
          http_uri *with* the query parameters :)

        

        
On 3/28/19 6:17 AM, Daniel Fett
          wrote:

        

        

          
          
Hi all,

          
I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00
          
Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.


          

          
Thanks for the feedback I received so far from John, Mike,
            Torsten, and others during today's session or before!

          
If you find any errors I would welcome if you open an issue
            in the GitHub repository at https://github.com/webham=
ster/draft-dpop

          
- Daniel    

          

          

          

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


        

        

      

      


      

    

    

 =20


=

--Apple-Mail-71357F0F-E2AC-452F-B98D-73B14906330C--


From nobody Mon Apr  8 16:40:59 2019
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 AB90F120142 for ; Mon,  8 Apr 2019 16:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 uduQt17m9Z62 for ; Mon,  8 Apr 2019 16:40:55 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 8372812013B for ; Mon,  8 Apr 2019 16:40:55 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x38Nflet026928; Mon, 8 Apr 2019 19:42:01 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 8 Apr 2019 19:40:38 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 8 Apr 2019 19:40:40 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 8 Apr 2019 19:40:40 -0400
From: Justin Richer 
To: Phil Hunt 
CC: George Fletcher , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] draft-fett-oauth-dpop-00
Thread-Index: AQHU5U95oChNewkbE0yijBoT2SQXPqYq3CgAgAADNQCAAAYXAIAIVykAgAAExAA=
Date: Mon, 8 Apr 2019 23:40:40 +0000
Message-ID: <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu>
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com>
In-Reply-To: <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_5C2A69C0FB0A48EA922AEBDEF11BF707mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 08 Apr 2019 23:40:58 -0000

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

Q29yb2xsYXJ5IHRvIHRoaXMsIGFyZSB0aGVyZSB0aG91Z2h0cyBvZiBoZWFkZXIgcHJvdGVjdGlv
biB1bmRlciB0aGlzIG1ldGhvZCwgYW5kIHRoZSBhc3NvY2lhdGVkIGlzc3VlIG9mIGhlYWRlciBt
b2RpZmljYXRpb24/DQoNCuKAlCBKdXN0aW4NCg0KT24gQXByIDgsIDIwMTksIGF0IDc6MjMgUE0s
IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tPj4gd3JvdGU6DQoNClF1ZXN0aW9uLiBPbmUgb2YgdGhlIGlzc3VlcyB0aGF0IEp1c3RpbiBS
aWNoZXLigJlzIHNpZ25pbmcgZHJhZnQgdHJpZWQgdG8gYWRkcmVzcyB3YXMgdXJsIG1vZGlmaWNh
dGlvbiBieSB0bHMgdGVybWluYXRvcnMvbG9hZCBiYWxlbmNlcnMvcHJveGllcy9hcGkgZ2F0ZXdh
eXMgZXRjLg0KDQpIb3cgZG8geW91IHNlZSB0aGlzIGlzc3VlIGluIGRwb3A/IElzIGl0IGEgcHJv
YmxlbT8NCg0KUGhpbA0KDQpPbiBBcHIgMywgMjAxOSwgYXQgOTowMSBBTSwgR2VvcmdlIEZsZXRj
aGVyIDxnZmZsZXRjaD00MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmdmZmxldGNoPTQw
YW9sLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpQZXJmZWN0ISBUaGFuayB5b3UhIEEg
Y291cGxlIGNvbW1lbnRzIG9uIHZlcnNpb24gMDEuLi4NCg0KDQogICBQT1NUIC90b2tlbiBIVFRQ
LzEuMQ0KICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tPGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5j
b20vPg0KICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7
Y2hhcnNldD1VVEYtOA0KICAgRFBvUC1CaW5kaW5nOiBleUpoYkdjaU9pSlNVMEV4WHpVaSAuLi4N
Cg0KICAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2NvZGUNCiAgICZjb2RlPVNwbHhsT0JlWlFR
WWJZUzZXeFNiSUENCiAgICZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFt
cGxlJTJFY29tJTJGY2INCiAgIChyZW1haW5kZXIgb2YgSldLIG9taXR0ZWQgZm9yIGJyZXZpdHkp
DQoNCkkgYmVsaWV2ZSB0aGUgIihyZW1haW5kZXIgb2YgSldLLi4uIiBzaG91bGQgYmUgbW92ZWQg
dG8gdGhlIERQb1AtQmluZGluZyBoZWFkZXIuLi4NCg0KQWxzbywgdGhlcmUgaXMgbm8gZGlzY3Vz
c2lvbiBvZiB0aGUgRFBvUC1CaW5kaW5nIGhlYWRlciBvdXRzaWRlIG9mIHRoZSB0b2tlbiByZXF1
ZXN0LCBidXQgSSBzdXNwZWN0IHRoYXQgaXMgdGhlIGRlc2lyZWQgd2F5IHRvIGNvbW11bmljYXRl
IHRoZSBEUG9QLVByb29mIHRvIHRoZSBSUy4NCg0KUG9zc2libHkgYW4gZXhhbXBsZSBpbiB0aGUg
c2Vzc2lvbiBmb3IgcHJlc2VudGluZyB0aGUgdG9rZW4gdG8gdGhlIFJTIHdvdWxkIGhlbHAuDQoN
ClRoYW5rcywNCkdlb3JnZQ0KDQpPbiA0LzMvMTkgMTE6MzkgQU0sIERhbmllbCBGZXR0IHdyb3Rl
Og0KVGhpcyBpcyBmaXhlZCBpbiAtMDE6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1mZXR0LW9hdXRoLWRwb3AtMDE8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t
L3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEZmV0dC0yRG9h
dXRoLTJEZHBvcC0yRDAxJmQ9RHdNRGFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly
TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta
TkEmbT1lUXB1c0VGWTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJnM9VEVhNVZn
YjNyQXp4Ykl1YXZCMWxONjVmbmtUeEtvTXA3RjJydzFBanVFWSZlPT4NCg0KLURhbmllbA0KDQpB
bSAwMy4wNC4xOSB1bSAxNzoyOCBzY2hyaWViIEdlb3JnZSBGbGV0Y2hlcjoNCkEgcXVpY2sgcXVl
c3Rpb24gcmVnYXJkaW5nLi4uDQoNCg0KICAgbyAgImh0dHBfdXJpIjogVGhlIEhUVFAgVVJJIHVz
ZWQgZm9yIHRoZSByZXF1ZXN0LCB3aXRob3V0IHF1ZXJ5IGFuZA0KICAgICAgZnJhZ21lbnQgcGFy
dHMgKFJFUVVJUkVEKS4NCg0KSXMgJ3dpdGhvdXQnIHN1cHBvc2VkIHRvIGJlICd3aXRoJyA/IFRo
ZSBleGFtcGxlIHNob3dzIHRoZSBodHRwX3VyaSAqd2l0aCogdGhlIHF1ZXJ5IHBhcmFtZXRlcnMg
OikNCg0KT24gMy8yOC8xOSA2OjE3IEFNLCBEYW5pZWwgRmV0dCB3cm90ZToNCg0KSGkgYWxsLA0K
DQpJIHB1Ymxpc2hlZCB0aGUgZmlyc3QgdmVyc2lvbiBvZiB0aGUgRFBvUCBkcmFmdCBhdCBodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmV0dC1vYXV0aC1kcG9wLTAwPGh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v
cmdfaHRtbF9kcmFmdC0yRGZldHQtMkRvYXV0aC0yRGRwb3AtMkQwMCZkPUR3TURhUSZjPVJvUDFZ
dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055
NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09ZVFwdXNFRlk3ZlJPWE5mRUptaDBRemtlamdk
Z2FWbklMcGJtMnE4eDlJSSZzPWVlTUdLWnE1Ujg2ZHYwWGdyQnNJaWp6dUk4T3pRcW5FLXZtVUVa
ODM2aFkmZT0+DQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNlbmRl
ci1jb25zdHJhaW50IG1lY2hhbmlzbSBmb3IgT0F1dGggMi4wDQogICBhY2Nlc3MgdG9rZW5zIGFu
ZCByZWZyZXNoIHRva2VucyB1dGlsaXppbmcgYW4gYXBwbGljYXRpb24tbGV2ZWwNCiAgIHByb29m
LW9mLXBvc3Nlc3Npb24gbWVjaGFuaXNtIGJhc2VkIG9uIHB1YmxpYy9wcml2YXRlIGtleSBwYWly
cy4NCg0KDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIEkgcmVjZWl2ZWQgc28gZmFyIGZyb20g
Sm9obiwgTWlrZSwgVG9yc3RlbiwgYW5kIG90aGVycyBkdXJpbmcgdG9kYXkncyBzZXNzaW9uIG9y
IGJlZm9yZSENCg0KSWYgeW91IGZpbmQgYW55IGVycm9ycyBJIHdvdWxkIHdlbGNvbWUgaWYgeW91
IG9wZW4gYW4gaXNzdWUgaW4gdGhlIEdpdEh1YiByZXBvc2l0b3J5IGF0IGh0dHBzOi8vZ2l0aHVi
LmNvbS93ZWJoYW1zdGVyL2RyYWZ0LWRwb3A8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3dlYmhhbXN0ZXJfZHJhZnQtMkRkcG9w
JmQ9RHdNRGFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZy
PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1lUXB1c0VGWTdm
Uk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJnM9UlIzdTgySWhON3docjhMZ1hNV00y
ZldON0VLSDZHTy1Ccy1IUnhFd0tIRSZlPT4NCg0KLSBEYW5pZWwNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP
QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgm
ZD1Ed01EYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9
bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWVRcHVzRUZZN2ZS
T1hOZkVKbWgwUXprZWpnZGdhVm5JTHBibTJxOHg5SUkmcz04TER2ZlRZRVNpMWZEZVJLN21RckhG
ZW85b2tvSjROVFpVNE9IeWVSSldrJmU9Pg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29h
dXRoJmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu
RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1lUXB1c0VG
WTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJnM9OExEdmZUWUVTaTFmRGVSSzdt
UXJIRmVvOW9rb0o0TlRaVTRPSHllUkpXayZlPQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQo=

--_000_5C2A69C0FB0A48EA922AEBDEF11BF707mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <5BC2E3821B61DE4CAD7EF78C80FEBE48@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkNvcm9sbGFyeSB0byB0aGlzLCBhcmUgdGhlcmUg
dGhvdWdodHMgb2YgaGVhZGVyIHByb3RlY3Rpb24gdW5kZXIgdGhpcyBtZXRob2QsIGFuZCB0aGUg
YXNzb2NpYXRlZCBpc3N1ZSBvZiBoZWFkZXIgbW9kaWZpY2F0aW9uPw0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh
bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0K4oCUIEp1c3RpbjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgOCwgMjAxOSwgYXQgNzoyMyBQ
TSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNs
YXNzPSIiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh
c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHls
ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s
aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5RdWVzdGlvbi4NCiBPbmUgb2YgdGhlIGlzc3VlcyB0
aGF0IEp1c3RpbiBSaWNoZXLigJlzIHNpZ25pbmcgZHJhZnQgdHJpZWQgdG8gYWRkcmVzcyB3YXMg
dXJsIG1vZGlmaWNhdGlvbiBieSB0bHMgdGVybWluYXRvcnMvbG9hZCBiYWxlbmNlcnMvcHJveGll
cy9hcGkgZ2F0ZXdheXMgZXRjLiZuYnNwOzwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt
ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCkhvdyBkbyB5
b3Ugc2VlIHRoaXMgaXNzdWUgaW4gZHBvcD8gSXMgaXQgYSBwcm9ibGVtPyZuYnNwOzxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlBoaWw8L2Rpdj4N
CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIEFwciAzLCAyMDE5LCBh
dCA5OjAxIEFNLCBHZW9yZ2UgRmxldGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmZsZXRjaD00
MGFvbC5jb21AZG1hcmMuaWV0Zi5vcmciIGNsYXNzPSIiPmdmZmxldGNoPTQwYW9sLmNvbUBkbWFy
Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBj
bGFzcz0iIj5QZXJmZWN0ISBUaGFuayB5b3UhIEEgY291cGxlIGNvbW1lbnRzIG9uIHZlcnNpb24g
MDEuLi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj4g
ICBQT1NUIC90b2tlbiBIVFRQLzEuMQ0KICAgSG9zdDogPGEgaHJlZj0iaHR0cDovL3NlcnZlci5l
eGFtcGxlLmNvbS8iIGNsYXNzPSIiPnNlcnZlci5leGFtcGxlLmNvbTwvYT4NCiAgIENvbnRlbnQt
VHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgNCiAg
IERQb1AtQmluZGluZzogZXlKaGJHY2lPaUpTVTBFeFh6VWkgLi4uDQoNCiAgIGdyYW50X3R5cGU9
YXV0aG9yaXphdGlvbl9jb2RlDQogICAmYW1wO2NvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQQ0K
ICAgJmFtcDtyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29t
JTJGY2INCiAgIChyZW1haW5kZXIgb2YgSldLIG9taXR0ZWQgZm9yIGJyZXZpdHkpPC9wcmU+DQo8
YnIgY2xhc3M9IiI+DQpJIGJlbGlldmUgdGhlICZxdW90OyhyZW1haW5kZXIgb2YgSldLLi4uJnF1
b3Q7IHNob3VsZCBiZSBtb3ZlZCB0byB0aGUgRFBvUC1CaW5kaW5nIGhlYWRlci4uLjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsc28sIHRoZXJlIGlzIG5vIGRpc2N1c3Npb24gb2YgdGhl
IERQb1AtQmluZGluZyBoZWFkZXIgb3V0c2lkZSBvZiB0aGUgdG9rZW4gcmVxdWVzdCwgYnV0IEkg
c3VzcGVjdCB0aGF0IGlzIHRoZSBkZXNpcmVkIHdheSB0byBjb21tdW5pY2F0ZSB0aGUgRFBvUC1Q
cm9vZiB0byB0aGUgUlMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUG9zc2libHkgYW4g
ZXhhbXBsZSBpbiB0aGUgc2Vzc2lvbiBmb3IgcHJlc2VudGluZyB0aGUgdG9rZW4gdG8gdGhlIFJT
IHdvdWxkIGhlbHAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzLDxiciBjbGFz
cz0iIj4NCkdlb3JnZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Im1v
ei1jaXRlLXByZWZpeCI+T24gNC8zLzE5IDExOjM5IEFNLCBEYW5pZWwgRmV0dCB3cm90ZTo8YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDo0MzVh
MWFkYi02MjkzLTg3NDUtOTZlOC1kNjA4ZjdkZDkzNGZAeWVzLmNvbSIgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPlRoaXMgaXMgZml4ZWQgaW4gLTAxOjwvZGl2Pg0KPGRp
diBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9Im1vei1jaXRlLXByZWZpeCI+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl
Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190
b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEZmV0dC0yRG9hdXRoLTJEZHBvcC0yRDAxJmFtcDtk
PUR3TURhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5F
JmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209
ZVFwdXNFRlk3ZlJPWE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJSSZhbXA7cz1URWE1Vmdi
M3JBenhiSXVhdkIxbE42NWZua1R4S29NcDdGMnJ3MUFqdUVZJmFtcDtlPSIgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmV0dC1vYXV0aC1k
cG9wLTAxPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48YnIgY2xhc3M9
IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+LURhbmllbDxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij48YnIgY2xhc3M9IiI+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+QW0gMDMuMDQuMTkgdW0gMTc6
Mjggc2NocmllYiBHZW9yZ2UgRmxldGNoZXI6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6NGM4NDlhNTUtMDEzYy1jNjA2LTg4NzctYWUzOWE2
YWI3OWZmQGFvbC5jb20iIGNsYXNzPSIiPg0KPGZvbnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwg
c2Fucy1zZXJpZiIgY2xhc3M9IiI+QSBxdWljayBxdWVzdGlvbiByZWdhcmRpbmcuLi48YnIgY2xh
c3M9IiI+DQo8L2ZvbnQ+PGJyIGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSI+ICAgbyAg
JnF1b3Q7aHR0cF91cmkmcXVvdDs6IFRoZSBIVFRQIFVSSSB1c2VkIGZvciB0aGUgcmVxdWVzdCwg
d2l0aG91dCBxdWVyeSBhbmQNCiAgICAgIGZyYWdtZW50IHBhcnRzIChSRVFVSVJFRCkuPC9wcmU+
DQo8Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlmIiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQpJcyAnd2l0aG91dCcgc3VwcG9zZWQgdG8gYmUgJ3dpdGgnID8gVGhlIGV4YW1w
bGUgc2hvd3MgdGhlIGh0dHBfdXJpICp3aXRoKiB0aGUgcXVlcnkgcGFyYW1ldGVycyA6KTxiciBj
bGFzcz0iIj4NCjwvZm9udD48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVm
aXgiPk9uIDMvMjgvMTkgNjoxNyBBTSwgRGFuaWVsIEZldHQgd3JvdGU6PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MGE5YWY2ZjYtMWI1ZC0y
NDRkLTA2YWYtOWQxNDQ2MWIxZDY5QHllcy5jb20iIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+SGkg
YWxsLDwvcD4NCjxwIGNsYXNzPSIiPkkgcHVibGlzaGVkIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRo
ZSBEUG9QIGRyYWZ0IGF0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf
aHRtbF9kcmFmdC0yRGZldHQtMkRvYXV0aC0yRGRwb3AtMkQwMCZhbXA7ZD1Ed01EYVEmYW1wO2M9
Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpC
VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWVRcHVzRUZZN2ZST1hO
ZkVKbWgwUXprZWpnZGdhVm5JTHBibTJxOHg5SUkmYW1wO3M9ZWVNR0tacTVSODZkdjBYZ3JCc0lp
anp1SThPelFxbkUtdm1VRVo4MzZoWSZhbXA7ZT0iIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMDwvYT48L3A+
DQo8cHJlIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn
aW4tYm90dG9tOiAwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJl
czogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPkFic3Ry
YWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNlbmRlci1jb25zdHJhaW50IG1lY2hh
bmlzbSBmb3IgT0F1dGggMi4wDQogICBhY2Nlc3MgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyB1
dGlsaXppbmcgYW4gYXBwbGljYXRpb24tbGV2ZWwNCiAgIHByb29mLW9mLXBvc3Nlc3Npb24gbWVj
aGFuaXNtIGJhc2VkIG9uIHB1YmxpYy9wcml2YXRlIGtleSBwYWlycy4NCjwvcHJlPg0KPGJyIGNs
YXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxwIGNsYXNzPSIiPlRoYW5rcyBmb3Ig
dGhlIGZlZWRiYWNrIEkgcmVjZWl2ZWQgc28gZmFyIGZyb20gSm9obiwgTWlrZSwgVG9yc3Rlbiwg
YW5kIG90aGVycyBkdXJpbmcgdG9kYXkncyBzZXNzaW9uIG9yIGJlZm9yZSE8L3A+DQo8cCBjbGFz
cz0iIj5JZiB5b3UgZmluZCBhbnkgZXJyb3JzIEkgd291bGQgd2VsY29tZSBpZiB5b3Ugb3BlbiBh
biBpc3N1ZSBpbiB0aGUgR2l0SHViIHJlcG9zaXRvcnkgYXQ8c3BhbiBjbGFzcz0iQXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4
dCIgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX19naXRodWIuY29tX3dlYmhhbXN0ZXJfZHJhZnQtMkRkcG9wJmFtcDtkPUR3TURhUSZhbXA7
Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZW
ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209ZVFwdXNFRlk3ZlJP
WE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJSSZhbXA7cz1SUjN1ODJJaE43d2hyOExnWE1X
TTJmV043RUtINkdPLUJzLUhSeEV3S0hFJmFtcDtlPSIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5o
dHRwczovL2dpdGh1Yi5jb20vd2ViaGFtc3Rlci9kcmFmdC1kcG9wPC9hPjwvcD4NCjxwIGNsYXNz
PSIiPi0gRGFuaWVsICZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L3A+DQo8YnIgY2xhc3M9IiI+DQo8Zmll
bGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0KPHByZSBjbGFz
cz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSI+T0F1dGhAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy
ZWV0ZXh0IiBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3TURh
USZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDty
PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209ZVFwdXNF
Rlk3ZlJPWE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJSSZhbXA7cz04TER2ZlRZRVNpMWZE
ZVJLN21RckhGZW85b2tvSjROVFpVNE9IeWVSSldrJmFtcDtlPSIgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPg0KPC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iIj48YnIgY2xhc3M9IiI+DQo8L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K
PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4g
Y2xhc3M9IiI+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNs
YXNzPSIiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0
Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll
dGYub3JnX21haWxtYW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1D
WENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdO
eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1lUXB1c0VGWTdmUk9YTmZFSm1oMFF6
a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJmFtcDtzPThMRHZmVFlFU2kxZkRlUks3bVFySEZlbzlva29K
NE5UWlU0T0h5ZVJKV2smYW1wO2U9IiBjbGFzcz0iIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv
X29hdXRoJmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN
VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO
NEtaTkEmYW1wO209ZVFwdXNFRlk3ZlJPWE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJSSZh
bXA7cz04TER2ZlRZRVNpMWZEZVJLN21RckhGZW85b2tvSjROVFpVNE9IeWVSSldrJmFtcDtlPTwv
YT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxz
cGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNw
bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv
cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0
aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz
cz0iIj5PQXV0aA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy
Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj
b3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNp
emUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i
Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog
MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u
ZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
YT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_5C2A69C0FB0A48EA922AEBDEF11BF707mitedu_--


From nobody Mon Apr  8 16:49:52 2019
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 1107712013D for ; Mon,  8 Apr 2019 16:49:43 -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, HTML_MESSAGE=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 DBpGomcCRaEZ for ; Mon,  8 Apr 2019 16:49:39 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 8086E12015E for ; Mon,  8 Apr 2019 16:49:39 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x38NncpL011442; Mon, 8 Apr 2019 19:49:39 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 8 Apr 2019 19:49:34 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 8 Apr 2019 19:49:36 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 8 Apr 2019 19:49:36 -0400
From: Justin Richer 
To: Brian Campbell 
CC: Filip Skokan , oauth 
Thread-Topic: [OAUTH-WG] MTLS and SAN
Thread-Index: AQHU6yPYm24VQsQf0UuOqTG8+b1fiqYstUSAgAADkACAAAUyAIAGFuKAgABjUAA=
Date: Mon, 8 Apr 2019 23:49:36 +0000
Message-ID: <7435DB60-3DD1-443A-89E0-9F524B0B2548@mit.edu>
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>  <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_7435DB603DD1443A89E09F524B0B2548mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 08 Apr 2019 23:49:50 -0000

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

VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbnMgZXZlcnlvbmUuIFNpbmNlIEkgZGlkbuKAmXQg
Y2F0Y2ggdGhlIG9uZS1hbmQtb25seS1vbmUgc2VudGltZW50IHdoZW4gcmVhZGluZyB0aGUgdXBk
YXRlcywgSSB3b3VsZCByZWNvbW1lbmQgYWx0ZXJpbmcgdGhlIHRleHQgYXMgZm9sbG93cyBpbiDC
pzIuMToNCg0KDQogICBUaGUgUEtJIChwdWJsaWMga2V5IGluZnJhc3RydWN0dXJlKSBtZXRob2Qg
b2YgbXV0dWFsIFRMUyBPQXV0aCBjbGllbnQNCiAgIGF1dGhlbnRpY2F0aW9uIGFkaGVyZXMgdG8g
dGhlIHdheSBpbiB3aGljaCBYLjUwOSBjZXJ0aWZpY2F0ZXMgYXJlDQogICB0cmFkaXRpb25hbGx5
IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uLiAgSXQgcmVsaWVzIG9uIGEgc2luZ2xlIHN1YmplY3QN
CiAgIGRpc3Rpbmd1aXNoZWQgbmFtZSAoRE4pIG9yIGEgc2luZ2xlIHN1YmplY3QgYWx0ZXJuYXRp
dmUgbmFtZSAoU0FOKSA8ZGVsZXRlZCB0ZXh0PiB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4g
VGhlIGNsaWVudOKAmXMgY2VydGlmaWNhdGUgY2hhaW4gaXMgdmFsaWRhdGVkIFtSRkM1MjgwXSBh
bmQgb25seSBvbmUgbmFtZSB2YWx1ZSBvZiBhbnkgdHlwZSBpcyB1c2VkIGZvciBlYWNoIGNsaWVu
dC4NCiAgIFRoZSBUTFMgaGFuZHNoYWtlIGlzIHV0aWxpemVkIHRvIHZhbGlkYXRlIHRoZSBjbGll
bnQncyBwb3NzZXNzaW9uIG9mDQogICB0aGUgcHJpdmF0ZSBrZXkgY29ycmVzcG9uZGluZyB0byB0
aGUgcHVibGljIGtleSBpbiB0aGUgY2VydGlmaWNhdGUNCiAgIGFuZCB0byB2YWxpZGF0ZSB0aGUg
Y29ycmVzcG9uZGluZyBjZXJ0aWZpY2F0ZSBjaGFpbi4gIFRoZSBjbGllbnQgaXMNCiAgIHN1Y2Nl
c3NmdWxseSBhdXRoZW50aWNhdGVkIGlmIHRoZSBzdWJqZWN0IGluZm9ybWF0aW9uIGluIHRoZQ0K
ICAgY2VydGlmaWNhdGUgbWF0Y2hlcyB0aGUgc2luZ2xlIGV4cGVjdGVkIHN1YmplY3QgY29uZmln
dXJlZCBvciByZWdpc3RlcmVkIGZvcg0KICAgdGhhdCBwYXJ0aWN1bGFyIGNsaWVudCAobm90ZSB0
aGF0IGEgcHJlZGljdGFibGUgdHJlYXRtZW50IG9mIERODQogICB2YWx1ZXMsIHN1Y2ggYXMgdGhl
IGRpc3Rpbmd1aXNoZWROYW1lTWF0Y2ggcnVsZSBmcm9tIFtSRkM0NTE3PGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM0NTE3Pl0sIGlzDQogICBuZWVkZWQgaW4gY29tcGFyaW5nIHRoZSBj
ZXJ0aWZpY2F0ZSdzIHN1YmplY3QgRE4gdG8gdGhlIGNsaWVudCdzDQogICByZWdpc3RlcmVkIERO
KS4gIFJldm9jYXRpb24gY2hlY2tpbmcgaXMgcG9zc2libGUgd2l0aCB0aGUgUEtJIG1ldGhvZA0K
ICAgYnV0IGlmIGFuZCBob3cgdG8gY2hlY2sgYSBjZXJ0aWZpY2F0ZSdzIHJldm9jYXRpb24gc3Rh
dHVzIGlzIGENCiAgIGRlcGxveW1lbnQgZGVjaXNpb24gYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyLg0KICAgQ2xpZW50cyBjYW4gcm90YXRlIHRoZWlyIFguNTA5
IGNlcnRpZmljYXRlcyB3aXRob3V0IHRoZSBuZWVkIHRvDQogICBtb2RpZnkgdGhlIHJlc3BlY3Rp
dmUgYXV0aGVudGljYXRpb24gZGF0YSBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCiAgIGJ5
IG9idGFpbmluZyBhIG5ldyBjZXJ0aWZpY2F0ZSB3aXRoIHRoZSBzYW1lIHN1YmplY3QgZnJvbSBh
IHRydXN0ZWQNCiAgIGNlcnRpZmljYXRlIGF1dGhvcml0eSAoQ0EpLg0KDQoNCkkgdGhpbmsgdGhl
IGxpc3Rpbmcgb2YgbWV0aG9kcyBpcyBjbGVhciBlbm91Z2ggYXMgaXQgaXMg4oCUIGJ1dCBteSBw
cm9ibGVtIHdhcyB0aGF0IEkgcmVhZCB0aGUgYWJvdmUgcGFyYWdyYXBoLCB0aGVuIGp1bXBlZCBy
aWdodCBpbnRvIHRoZSBsaXN0IGJlbG93IGZvciB0aGUgZXhhY3QgZmllbGRzIHdpdGhvdXQgcmVh
ZGluZyBpdHMgb3duIGludHJvZHVjdG9yeSBwYXJhZ3JhcGggYXMgd2VsbC4NCg0K4oCUIEp1c3Rp
bg0KDQpPbiBBcHIgOCwgMjAxOSwgYXQgMTo1NCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs
bEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdy
b3RlOg0KDQpZZXMsIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUgY2xpZW50IGJlIGNvbmZpZ3VyZWQg
KGR5bmFtaWNhbGx5IG9yIHN0YXRpY2FsbHkgb3IgaG93ZXZlciB0aGF0IGNvbWVzIHRvIGJlKSB3
aXRoIG9uZSBhbmQgb25seSBvbmUgZXhwZWN0ZWQgc3ViamVjdCwgd2hpY2ggYWxzbyBpbmNsdWRl
cyB0aGUgbG9jYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRoYXQgc3ViamVjdCB3aWxsIGJlLiBB
bmQgdGhhdCBpcyBjaGVja2VkIGFnYWluc3QgYXQgYXV0aGVudGljYXRpb24gdGltZS4NCg0KQXMg
dGhlIHdyaXRlciBvZiB0aGUgcXVlc3Rpb25hYmxlIHRleHQgaW4gcXVlc3Rpb24sIGl0IGRvZXMg
c2VlbSBwcmV0dHkgY2xlYXIgdG8gbWUgYXMgaXQgaXMgbm93LiBCdXQgYXMgdGhlIHdyaXRlciwg
SSdtIGFsc28gcHJvYmFibHkgbm90IHdlbGwgcG9zaXRpb25lZCB0byBzZWUgaG93IGl0IGNvdWxk
IGJlIG1hZGUgbW9yZSBjbGVhcmVyLiBTbyBpZiBlaXRoZXIgb2YgeW91IGdlbnRsZW1lbiBoYXZl
IGNvbmNyZXRlIHRleHQgc3VnZ2VzdGlvbnMgdG8gaGVscCB0aGVyZSwgcGxlYXNlIHNlbmQgZW0g
Zm9yIGNvbnNpZGVyYXRpb24uDQoNCk9uIFRodSwgQXByIDQsIDIwMTkgYXQgMjo1NSBQTSBGaWxp
cCBTa29rYW4gPHBhbnZhLmlwQGdtYWlsLmNvbTxtYWlsdG86cGFudmEuaXBAZ21haWwuY29tPj4g
d3JvdGU6DQpZZXMuDQoNClMgcG96ZHJhdmVtLA0KRmlsaXAgU2tva2FuDQoNCg0KT24gVGh1LCA0
IEFwciAyMDE5IGF0IDIyOjM2LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRv
OmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhhbmsgeW91LCBJIGRpZCBtaXNzIHRoYXQgdGV4
dC4gVGhpcyBzaG91bGQgYmUgY2FsbGVkIG91dCBtb3JlIGV4cGxpY2l0bHkgaW4gwqcyLjEsIHBl
cmhhcHMgYnkgc3BlY2lmeWluZyB0aGF0IGl0IGlzIG9ubHkgb25lIGZpZWxkLiBUaGlzIHN0aWxs
IGRvZXNu4oCZdCBzZXQgcHJlY2VkZW5jZSwgYnV0IGl0IGltcGxpZXMgdGhhdCBpdOKAmXMgYW4g
ZXJyb3IgZm9yIGEgY2xpZW50IHRvIGhhdmUgbW9yZSB0aGFuIG9uZSBmaWVsZCBzZXQgb2YgdGhl
IGF2YWlsYWJsZSBvcHRpb25zLiBJcyB0aGF0IHlvdXIgcmVhZCBvbiB0aGlzIGFzIHdlbGw/DQoN
CuKAlCBKdXN0aW4NCg0KT24gQXByIDQsIDIwMTksIGF0IDQ6MjMgUE0sIEZpbGlwIFNrb2thbiA8
cGFudmEuaXBAZ21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCg0K
SnVzdGluLCBJIGhhZCB0aGUgZXhhY3Qgc2FtZSBxdWVzdGlvbiBvZmYgbGlzdCBhbmQgYmVsaWV2
ZSBkcmFmdCAxMyBjbGFyaWZpZWQgdGhpcy4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtb2F1dGgtbXRscy0xMyNzZWN0aW9uLTIuMS4yDQoNCkEgY2xpZW50IHVzaW5n
IHRoZSAidGxzX2NsaWVudF9hdXRoIiBhdXRoZW50aWNhdGlvbiBtZXRob2QgTVVTVCB1c2UgZXhh
Y3RseSBvbmUgb2YgdGhlIGJlbG93IG1ldGFkYXRhIHBhcmFtZXRlcnMgdG8gaW5kaWNhdGUgdGhl
IGNlcnRpZmljYXRlIHN1YmplY3QgdmFsdWUgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg
aXMgdG8gZXhwZWN0IHdoZW4gYXV0aGVudGljYXRpbmcgdGhlIHJlc3BlY3RpdmUgY2xpZW50Lg0K
DQpUaGVuIGl0IGxpc3RzIHRoZSBkaWZmZXJlbnQgZG4vc2FuIHByb3BlcnRpZXMuDQoNClMgcG96
ZHJhdmVtLA0KRmlsaXAgU2tva2FuDQoNCg0KT24gVGh1LCA0IEFwciAyMDE5IGF0IDIyOjIwLCBK
dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdy
b3RlOg0KV2XigJl2ZSBqdXN0IHN0YXJ0ZWQgaW1wbGVtZW50YXRpb24gb2YgU0FOLWJhc2VkIGNl
cnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uLCBiYXNlZCBvbiB0aGUgY2hhbmdlcyBpbiB2ZXJzaW9u
IC0xMyBvZiB0aGUgZHJhZnQuIEkgYmVsaWV2ZSB0aGlzIGFkZGl0aW9uIGlzIGEgYml0IHVuY2xl
YXIsIGR1ZSB0byBpdCBiZWluZyBhZGRlZCBzbyBsYXRlIGluIHRoZSBkb2N1bWVudCBwcm9jZXNz
Lg0KDQpNeSBxdWVzdGlvbiBpcyBob3cgZG9lcyBhbiBBUyBkZXRlcm1pbmUgd2hldGhlciB0byBE
TiBvciBTQU4gZm9yIGNlcnRpZmljYXRlIGNoZWNraW5nPyBDb3JvbGxhcnksIGFyZSB0aGVzZSBt
dXR1YWxseSBleGNsdXNpdmUgb3IgY2FuIHRoZXkgYmUgdXNlZCB0b2dldGhlcj8gQ3VycmVudGx5
LCB0aGUgc3BlY2lmaWNhdGlvbiB0ZXh0IGxpc3RzIEROIGFuZCBTQU4gYXMgYW4g4oCcb3LigJ0g
d2l0aCBubyBpbmRpY2F0aW9uIHdoZXRoZXIgdGhpcyBpcyBhbiBpbmNsdXNpdmUgb3IgZXhjbHVz
aXZlIOKAnG9y4oCdLCBhbmQgd2hhdCB0byBkbyB3aGVuIHRoZXJl4oCZcyBvdmVybGFwLg0KDQpU
aGlzIGhhcyBpbXBsaWNhdGlvbnMgYm90aCBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBz
ZXJ2ZXIgcHJvY2Vzc2luZyB0aGUgcmVxdWVzdCBhcyB3ZWxsIGFzIHRoZSBjbGllbnQgbWV0YWRh
dGEgbW9kZWwsIHNpbmNlIHRoZSBjbGllbnQgZmllbGRzIGFyZSBhbGwgaW4gcGFyYWxsZWwgdG8g
ZWFjaCBvdGhlci4gSSBjYW4gc2VlIGEgZmV3IHdheXMgb2YgaGFuZGxpbmcgdGhpcy4NCg0KDQox
KSBPbmUgb2YgdGhlIGZpZWxkcyB0YWtlcyBwcmVjZWRlbmNlIG92ZXIgdGhlIG90aGVyLiBTYXkg
Zm9yIGV4YW1wbGUgeW91IGNob29zZSB0aGUgRE4gZmllbGQ6IGlmIGl04oCZcyBzZXQsIHRoZW4g
eW91IGRvIEROIG1hdGNoaW5nIGFuZCBpZ25vcmUgdGhlIFNBTiBmaWVsZHMgZW50aXJlbHksIGJv
dGggaW4gdGhlIGNlcnQgYW5kIGluIHRoZSBjbGllbnTigJlzIHJlZ2lzdHJhdGlvbi4gSW52ZXJz
ZSBpcyB0cnVlIGlmIHlvdSBjaG9vc2UgdGhlIFNBTiBmaWVsZHMgb3ZlciB0aGUgRE4gYnV0IHRo
ZSBwcmluY2lwbGUgaXMgdGhlIHNhbWUuIFdlIHNob3VsZCBiZSBleHBsaWNpdCBpZiB0aGVyZeKA
mXMgYW4gaW50ZW5kZWQgcHJlY2VkZW5jZSBiZXR3ZWVuIHRoZXNlIHR3bywgYW5kIGV2ZW4gbW9y
ZSBleHBsaWNpdCBpZiB0aGUgRE4gYW5kIFNBTiBhcmUgYXQgZXF1YWwgbGV2ZWwgYW5kIHRoZSBB
UyBnZXRzIHRvIGNob29zZS4gV2UgYWxzbyBuZWVkIHRvIGJlIGNsZWFyIGlmIGl04oCZcyBhbiBl
cnJvciBjb25kaXRpb24gaWYgYm90aCBhcmUgc2V0IHNpbXVsdGFuZW91c2x5LCBsaWtlIHRoZSB3
YXkgdGhhdCBqd2tzIGFuZCBqd2tzX3VyaSBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLg0KMikgWW91
IHNldCBhbiBleHBsaWNpdCBzd2l0Y2ggaW4geW91ciBjbGllbnQgbW9kZWwgdGhhdCBzYXlzIHdo
ZXRoZXIgdG8gdXNlIHRoZSBETiBvciB0aGUgU0FOIGZpZWxkcyBpbiBjb21wYXJpc29uLCBhbmQg
eW91ciBjb2RlIGJyYW5jaGVzIGJhc2VkIG9uIHRoYXQgdG8gZWl0aGVyIEROIG9yIFNBTiBwcm9j
ZXNzaW5nLiBUaGlzIGNvdWxkIGFsc28gYmUgYWRkZWQgYXMgYW4gZXhwbGljaXQgY2xpZW50IG1l
dGFkYXRhIGZpZWxkLCBvciBpdCBjb3VsZCBiZSBhbiBpbnRlcm5hbCBkZXRhaWwuIElmIGFuIGlu
dGVybmFsIGRldGFpbCwgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0IHRoZXJlIG5vdCBiZWlu
ZyBhIHByZWRlZmluZWQgcHJlY2VkZW5jZSBiZXR3ZWVuIHRoZSBmaWVsZHMuDQozKSBJZiBpdOKA
mXMgYWxsb3dhYmxlIHRvIHVzZSB0aGVtIHRvZ2V0aGVyLCB5b3UgbWF0Y2ggZXZlcnl0aGluZyB0
aGF04oCZcyBzZXQgaW4gdGhlIGNsaWVudCwgYW5kIGF0IGxlYXN0IG9uZSBmaWVsZCBNVVNUIGJl
IHNldC4NCg0KDQpXaGF04oCZcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IgZm9yIGltcGxlbWVudGVy
cywgYW5kIHNob3VsZCB3ZSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoaXM/IFdlIGFyZSBzdGFy
dGluZyBvdXIgaW1wbGVtZW50YXRpb24gd2l0aCAoMSkgcGVuZGluZyB0aGUgb3V0Y29tZSBvZiB0
aGlzIHRocmVhZCwgYW5kIEnigJlkIGJlIGN1cmlvdXMgdG8ga25vdyBob3cgb3RoZXJzIGFyZSBp
bXBsZW1lbnRpbmcgdGhpcyBpbiB0aGVpciBzeXN0ZW1zLg0KDQpUaGFua3MsDQrigJQgSnVzdGlu
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K
T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlz
IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm
b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcs
IHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy
b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl
bGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1
dGVyLiBUaGFuayB5b3UuDQoNCg==

--_000_7435DB603DD1443A89E09F524B0B2548mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <4A34FC3B71671A40A29DE70D4E8EC8E0@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb25z
IGV2ZXJ5b25lLiBTaW5jZSBJIGRpZG7igJl0IGNhdGNoIHRoZSBvbmUtYW5kLW9ubHktb25lIHNl
bnRpbWVudCB3aGVuIHJlYWRpbmcgdGhlIHVwZGF0ZXMsIEkgd291bGQgcmVjb21tZW5kIGFsdGVy
aW5nIHRoZSB0ZXh0IGFzIGZvbGxvd3MgaW4gwqcyLjE6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBweDsgYm9y
ZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJl
IGNsYXNzPSJuZXdwYWdlIj4gICBUaGUgUEtJIChwdWJsaWMga2V5IGluZnJhc3RydWN0dXJlKSBt
ZXRob2Qgb2YgbXV0dWFsIFRMUyBPQXV0aCBjbGllbnQNCiAgIGF1dGhlbnRpY2F0aW9uIGFkaGVy
ZXMgdG8gdGhlIHdheSBpbiB3aGljaCBYLjUwOSBjZXJ0aWZpY2F0ZXMgYXJlDQogICB0cmFkaXRp
b25hbGx5IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uLiAgSXQgcmVsaWVzIG9uIGEgPGIgY2xhc3M9
IiI+c2luZ2xlIDwvYj5zdWJqZWN0DQogICBkaXN0aW5ndWlzaGVkIG5hbWUgKEROKSBvciBhIDxi
IGNsYXNzPSIiPnNpbmdsZTwvYj4gc3ViamVjdCBhbHRlcm5hdGl2ZSBuYW1lIChTQU4pIDxiIGNs
YXNzPSIiPiZsdDtkZWxldGVkIHRleHQmZ3Q7PC9iPiB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVu
dC4gPGIgY2xhc3M9IiI+VGhlIGNsaWVudOKAmXMgY2VydGlmaWNhdGUgY2hhaW4gaXMgdmFsaWRh
dGVkIFtSRkM1MjgwXSBhbmQgb25seSBvbmUgbmFtZSB2YWx1ZSBvZiBhbnkgdHlwZSBpcyB1c2Vk
IGZvciBlYWNoIGNsaWVudC48L2I+DQogICBUaGUgVExTIGhhbmRzaGFrZSBpcyB1dGlsaXplZCB0
byB2YWxpZGF0ZSB0aGUgY2xpZW50J3MgcG9zc2Vzc2lvbiBvZg0KICAgdGhlIHByaXZhdGUga2V5
IGNvcnJlc3BvbmRpbmcgdG8gdGhlIHB1YmxpYyBrZXkgaW4gdGhlIGNlcnRpZmljYXRlDQogICBh
bmQgdG8gdmFsaWRhdGUgdGhlIGNvcnJlc3BvbmRpbmcgY2VydGlmaWNhdGUgY2hhaW4uICBUaGUg
Y2xpZW50IGlzDQogICBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRlZCBpZiB0aGUgc3ViamVjdCBp
bmZvcm1hdGlvbiBpbiB0aGUNCiAgIGNlcnRpZmljYXRlIG1hdGNoZXMgdGhlIDxiIGNsYXNzPSIi
PnNpbmdsZSA8L2I+ZXhwZWN0ZWQgc3ViamVjdCBjb25maWd1cmVkIG9yIHJlZ2lzdGVyZWQgZm9y
DQogICB0aGF0IHBhcnRpY3VsYXIgY2xpZW50IChub3RlIHRoYXQgYSBwcmVkaWN0YWJsZSB0cmVh
dG1lbnQgb2YgRE4NCiAgIHZhbHVlcywgc3VjaCBhcyB0aGUgZGlzdGluZ3Vpc2hlZE5hbWVNYXRj
aCBydWxlIGZyb20gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTE3
IiB0aXRsZT0iJnF1b3Q7TGlnaHR3ZWlnaHQgRGlyZWN0b3J5IEFjY2VzcyBQcm90b2NvbCAoTERB
UCk6IFN5bnRheGVzIGFuZCBNYXRjaGluZyBSdWxlcyZxdW90OyIgY2xhc3M9IiI+UkZDNDUxNzwv
YT5dLCBpcw0KICAgbmVlZGVkIGluIGNvbXBhcmluZyB0aGUgY2VydGlmaWNhdGUncyBzdWJqZWN0
IEROIHRvIHRoZSBjbGllbnQncw0KICAgcmVnaXN0ZXJlZCBETikuICBSZXZvY2F0aW9uIGNoZWNr
aW5nIGlzIHBvc3NpYmxlIHdpdGggdGhlIFBLSSBtZXRob2QNCiAgIGJ1dCBpZiBhbmQgaG93IHRv
IGNoZWNrIGEgY2VydGlmaWNhdGUncyByZXZvY2F0aW9uIHN0YXR1cyBpcyBhDQogICBkZXBsb3lt
ZW50IGRlY2lzaW9uIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl
ci4NCiAgIENsaWVudHMgY2FuIHJvdGF0ZSB0aGVpciBYLjUwOSBjZXJ0aWZpY2F0ZXMgd2l0aG91
dCB0aGUgbmVlZCB0bw0KICAgbW9kaWZ5IHRoZSByZXNwZWN0aXZlIGF1dGhlbnRpY2F0aW9uIGRh
dGEgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQogICBieSBvYnRhaW5pbmcgYSBuZXcgY2Vy
dGlmaWNhdGUgd2l0aCB0aGUgc2FtZSBzdWJqZWN0IGZyb20gYSB0cnVzdGVkDQogICBjZXJ0aWZp
Y2F0ZSBhdXRob3JpdHkgKENBKS48L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsgdGhlIGxpc3Rpbmcgb2YgbWV0aG9kcyBp
cyBjbGVhciBlbm91Z2ggYXMgaXQgaXMg4oCUIGJ1dCBteSBwcm9ibGVtIHdhcyB0aGF0IEkgcmVh
ZCB0aGUgYWJvdmUgcGFyYWdyYXBoLCB0aGVuIGp1bXBlZCByaWdodCBpbnRvIHRoZSBsaXN0IGJl
bG93IGZvciB0aGUgZXhhY3QgZmllbGRzIHdpdGhvdXQgcmVhZGluZyBpdHMgb3duIGludHJvZHVj
dG9yeSBwYXJhZ3JhcGggYXMgd2VsbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog
MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250
LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog
MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0K
PGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk
aXYgY2xhc3M9IiI+T24gQXByIDgsIDIwMTksIGF0IDE6NTQgUE0sIEJyaWFuIENhbXBiZWxsICZs
dDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIGNsYXNzPSIiPmJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9
IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs
dHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5ZZXMsIHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUg
Y2xpZW50IGJlIGNvbmZpZ3VyZWQgKGR5bmFtaWNhbGx5IG9yIHN0YXRpY2FsbHkgb3IgaG93ZXZl
ciB0aGF0IGNvbWVzIHRvIGJlKSB3aXRoIG9uZSBhbmQgb25seSBvbmUgZXhwZWN0ZWQgc3ViamVj
dCwgd2hpY2ggYWxzbyBpbmNsdWRlcyB0aGUgbG9jYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIHRo
YXQgc3ViamVjdCB3aWxsIGJlLiBBbmQgdGhhdCBpcyBjaGVja2VkIGFnYWluc3QNCiBhdCBhdXRo
ZW50aWNhdGlvbiB0aW1lLiA8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFzIHRoZSB3cml0ZXIgb2YgdGhlIHF1
ZXN0aW9uYWJsZSB0ZXh0IGluIHF1ZXN0aW9uLCBpdCBkb2VzIHNlZW0gcHJldHR5IGNsZWFyIHRv
IG1lIGFzIGl0IGlzIG5vdy4gQnV0IGFzIHRoZSB3cml0ZXIsIEknbSBhbHNvIHByb2JhYmx5IG5v
dCB3ZWxsIHBvc2l0aW9uZWQgdG8gc2VlIGhvdyBpdCBjb3VsZCBiZSBtYWRlIG1vcmUgY2xlYXJl
ci4gU28gaWYgZWl0aGVyIG9mIHlvdSBnZW50bGVtZW4gaGF2ZSBjb25jcmV0ZSB0ZXh0DQogc3Vn
Z2VzdGlvbnMgdG8gaGVscCB0aGVyZSwgcGxlYXNlIHNlbmQgZW0gZm9yIGNvbnNpZGVyYXRpb24u
IDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1
LCBBcHIgNCwgMjAxOSBhdCAyOjU1IFBNIEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnBhbnZhLmlwQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRl
ci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRp
diBkaXI9Imx0ciIgY2xhc3M9IiI+WWVzLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xlYXI9ImFsbCIg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsLW1f
LTQ1NTc3ODkyNTIyOTYxOTMwNzdnbWFpbC1tXzYzODQxMzQ1Nzc3NDAxOTM1NjhnbWFpbC1tXzgw
NTk1Mzk2MzY5NDA3NTA4MzRnbWFpbC1tXy01Mjg0NTEzNTMzMzY5OTc0MDM2Z21haWxfc2lnbmF0
dXJlIj4NClMgcG96ZHJhdmVtLDxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkZpbGlwIFNrb2th
bjwvYj48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz
PSJnbWFpbF9hdHRyIj5PbiBUaHUsIDQgQXByIDIwMTkgYXQgMjI6MzYsIEp1c3RpbiBSaWNoZXIg
Jmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFz
cz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw
eCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl
ZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IiI+VGhhbmsgeW91LCBJIGRpZCBtaXNzIHRoYXQgdGV4dC4g
VGhpcyBzaG91bGQgYmUgY2FsbGVkIG91dCBtb3JlIGV4cGxpY2l0bHkgaW4gwqcyLjEsIHBlcmhh
cHMgYnkgc3BlY2lmeWluZyB0aGF0IGl0IGlzIG9ubHkgb25lIGZpZWxkLiBUaGlzIHN0aWxsIGRv
ZXNu4oCZdCBzZXQgcHJlY2VkZW5jZSwgYnV0IGl0IGltcGxpZXMgdGhhdCBpdOKAmXMgYW4gZXJy
b3IgZm9yIGEgY2xpZW50IHRvIGhhdmUgbW9yZSB0aGFuIG9uZSBmaWVsZA0KIHNldCBvZiB0aGUg
YXZhaWxhYmxlIG9wdGlvbnMuIElzIHRoYXQgeW91ciByZWFkIG9uIHRoaXMgYXMgd2VsbD8NCjxk
aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4
OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDQsIDIwMTksIGF0IDQ6MjMgUE0sIEZp
bGlwIFNrb2thbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiIGNsYXNzPSIiPnBhbnZhLmlwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2
Pg0KPGJyIGNsYXNzPSJnbWFpbC1tXy00NTU3Nzg5MjUyMjk2MTkzMDc3Z21haWwtbV82Mzg0MTM0
NTc3NzQwMTkzNTY4Z21haWwtbV84MDU5NTM5NjM2OTQwNzUwODM0Z21haWwtbV8tNTI4NDUxMzUz
MzM2OTk3NDAzNmdtYWlsLW1fLTQ0ODA2OTY2MDEyNTU0MTUxNjlBcHBsZS1pbnRlcmNoYW5nZS1u
ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg
ZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SnVzdGluLCBJIGhh
ZCB0aGUgZXhhY3Qgc2FtZSBxdWVzdGlvbiBvZmYgbGlzdCBhbmQgYmVsaWV2ZSBkcmFmdCAxMyBj
bGFyaWZpZWQgdGhpcy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW9hdXRoLW10bHMtMTMjc2VjdGlvbi0yLjEuMiIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLW10bHMtMTMjc2VjdGlv
bi0yLjEuMjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPkEgY2xpZW50IHVzaW5nIHRoZSZuYnNwOyZxdW90O3Rsc19jbGllbnRfYXV0
aCZxdW90OyBhdXRoZW50aWNhdGlvbiBtZXRob2QgTVVTVCB1c2UgZXhhY3RseSBvbmUgb2YgdGhl
IGJlbG93IG1ldGFkYXRhIHBhcmFtZXRlcnMgdG8gaW5kaWNhdGUgdGhlIGNlcnRpZmljYXRlIHN1
YmplY3QgdmFsdWUgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgdG8gZXhwZWN0IHdo
ZW4gYXV0aGVudGljYXRpbmcgdGhlIHJlc3BlY3RpdmUgY2xpZW50LjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
VGhlbiBpdCBsaXN0cyB0aGUgZGlmZmVyZW50IGRuL3NhbiBwcm9wZXJ0aWVzLjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbC1tXy00NTU3Nzg5MjUyMjk2
MTkzMDc3Z21haWwtbV82Mzg0MTM0NTc3NzQwMTkzNTY4Z21haWwtbV84MDU5NTM5NjM2OTQwNzUw
ODM0Z21haWwtbV8tNTI4NDUxMzUzMzM2OTk3NDAzNmdtYWlsLW1fLTQ0ODA2OTY2MDEyNTU0MTUx
NjlnbWFpbF9zaWduYXR1cmUiPg0KUyBwb3pkcmF2ZW0sPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9
IiI+RmlsaXAgU2tva2FuPC9iPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRo
dSwgNCBBcHIgMjAxOSBhdCAyMjoyMCwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVk
dTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9
ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0
OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBjbGFz
cz0iIj5XZeKAmXZlIGp1c3Qgc3RhcnRlZCBpbXBsZW1lbnRhdGlvbiBvZiBTQU4tYmFzZWQgY2Vy
dGlmaWNhdGUgYXV0aGVudGljYXRpb24sIGJhc2VkIG9uIHRoZSBjaGFuZ2VzIGluIHZlcnNpb24g
LTEzIG9mIHRoZSBkcmFmdC4gSSBiZWxpZXZlIHRoaXMgYWRkaXRpb24gaXMgYSBiaXQgdW5jbGVh
ciwgZHVlIHRvIGl0IGJlaW5nIGFkZGVkIHNvIGxhdGUgaW4gdGhlIGRvY3VtZW50IHByb2Nlc3Mu
Jm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5NeSBxdWVzdGlvbiBpcyBob3cgZG9lcyBhbiBBUyBkZXRlcm1pbmUgd2hldGhlciB0byBETiBv
ciBTQU4gZm9yIGNlcnRpZmljYXRlIGNoZWNraW5nPyBDb3JvbGxhcnksIGFyZSB0aGVzZSBtdXR1
YWxseSBleGNsdXNpdmUgb3IgY2FuIHRoZXkgYmUgdXNlZCB0b2dldGhlcj8mbmJzcDtDdXJyZW50
bHksIHRoZSBzcGVjaWZpY2F0aW9uIHRleHQgbGlzdHMgRE4gYW5kIFNBTiBhcyBhbiDigJxvcuKA
nSB3aXRoIG5vIGluZGljYXRpb24gd2hldGhlcg0KIHRoaXMgaXMgYW4gaW5jbHVzaXZlIG9yIGV4
Y2x1c2l2ZSDigJxvcuKAnSwgYW5kIHdoYXQgdG8gZG8gd2hlbiB0aGVyZeKAmXMgb3ZlcmxhcC4m
bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PlRoaXMgaGFzIGltcGxpY2F0aW9ucyBib3RoIGZvciB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhl
IHNlcnZlciBwcm9jZXNzaW5nIHRoZSByZXF1ZXN0IGFzIHdlbGwgYXMgdGhlIGNsaWVudCBtZXRh
ZGF0YSBtb2RlbCwgc2luY2UgdGhlIGNsaWVudCBmaWVsZHMgYXJlIGFsbCBpbiBwYXJhbGxlbCB0
byBlYWNoIG90aGVyLiBJIGNhbiBzZWUgYSBmZXcgd2F5cyBvZiBoYW5kbGluZyB0aGlzLg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEpIE9uZSBvZiB0aGUgZmllbGRzIHRha2VzIHBy
ZWNlZGVuY2Ugb3ZlciB0aGUgb3RoZXIuIFNheSBmb3IgZXhhbXBsZSB5b3UgY2hvb3NlIHRoZSBE
TiBmaWVsZDogaWYgaXTigJlzIHNldCwgdGhlbiB5b3UgZG8gRE4gbWF0Y2hpbmcgYW5kIGlnbm9y
ZSB0aGUgU0FOIGZpZWxkcyBlbnRpcmVseSwgYm90aCBpbiB0aGUgY2VydCBhbmQgaW4gdGhlIGNs
aWVudOKAmXMgcmVnaXN0cmF0aW9uLiBJbnZlcnNlIGlzIHRydWUgaWYgeW91IGNob29zZQ0KIHRo
ZSBTQU4gZmllbGRzIG92ZXIgdGhlIEROIGJ1dCB0aGUgcHJpbmNpcGxlIGlzIHRoZSBzYW1lLiBX
ZSBzaG91bGQgYmUgZXhwbGljaXQgaWYgdGhlcmXigJlzIGFuIGludGVuZGVkIHByZWNlZGVuY2Ug
YmV0d2VlbiB0aGVzZSB0d28sIGFuZCBldmVuIG1vcmUgZXhwbGljaXQgaWYgdGhlIEROIGFuZCBT
QU4gYXJlIGF0IGVxdWFsIGxldmVsIGFuZCB0aGUgQVMgZ2V0cyB0byBjaG9vc2UuIFdlIGFsc28g
bmVlZCB0byBiZSBjbGVhciBpZiBpdOKAmXMgYW4NCiBlcnJvciBjb25kaXRpb24gaWYgYm90aCBh
cmUgc2V0IHNpbXVsdGFuZW91c2x5LCBsaWtlIHRoZSB3YXkgdGhhdCBqd2tzIGFuZCBqd2tzX3Vy
aSBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yKSBZ
b3Ugc2V0IGFuIGV4cGxpY2l0IHN3aXRjaCBpbiB5b3VyIGNsaWVudCBtb2RlbCB0aGF0IHNheXMg
d2hldGhlciB0byB1c2UgdGhlIEROIG9yIHRoZSBTQU4gZmllbGRzIGluIGNvbXBhcmlzb24sIGFu
ZCB5b3VyIGNvZGUgYnJhbmNoZXMgYmFzZWQgb24gdGhhdCB0byBlaXRoZXIgRE4gb3IgU0FOIHBy
b2Nlc3NpbmcuIFRoaXMgY291bGQgYWxzbyBiZSBhZGRlZCBhcyBhbiBleHBsaWNpdCBjbGllbnQg
bWV0YWRhdGEgZmllbGQsDQogb3IgaXQgY291bGQgYmUgYW4gaW50ZXJuYWwgZGV0YWlsLiBJZiBh
biBpbnRlcm5hbCBkZXRhaWwsIHdlIHNob3VsZCBiZSBleHBsaWNpdCBhYm91dCB0aGVyZSBub3Qg
YmVpbmcgYSBwcmVkZWZpbmVkIHByZWNlZGVuY2UgYmV0d2VlbiB0aGUgZmllbGRzLiZuYnNwOzwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj4zKSBJZiBpdOKAmXMgYWxsb3dhYmxlIHRvIHVzZSB0aGVtIHRv
Z2V0aGVyLCB5b3UgbWF0Y2ggZXZlcnl0aGluZyB0aGF04oCZcyBzZXQgaW4gdGhlIGNsaWVudCwg
YW5kIGF0IGxlYXN0IG9uZSBmaWVsZCBNVVNUIGJlIHNldC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj5XaGF04oCZcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IgZm9yIGltcGxl
bWVudGVycywgYW5kIHNob3VsZCB3ZSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoaXM/IFdlIGFy
ZSBzdGFydGluZyBvdXIgaW1wbGVtZW50YXRpb24gd2l0aCAoMSkgcGVuZGluZyB0aGUgb3V0Y29t
ZSBvZiB0aGlzIHRocmVhZCwgYW5kIEnigJlkIGJlIGN1cmlvdXMgdG8ga25vdyBob3cgb3RoZXJz
IGFyZSBpbXBsZW1lbnRpbmcgdGhpcyBpbiB0aGVpciBzeXN0ZW1zLiZuYnNwOzwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDxi
ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2
ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6
bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGln
bjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpu
b3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9IiI+DQri
gJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5PQXV0
aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r
IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h
PjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xh
c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnIg
Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxpIHN0eWxl
PSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHg7b3V0bGluZTowcHg7dmVydGljYWwt
YWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwyNTUpO2ZvbnQtZmFtaWx5OnBy
b3hpbWEtbm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLHN5c3RlbS11aSwmcXVv
dDtTZWdvZSBVSSZxdW90OyxSb2JvdG8sT3h5Z2VuLVNhbnMsVWJ1bnR1LENhbnRhcmVsbCwmcXVv
dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOnJnYig4NSw4NSw4
NSkiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjow
cHg7b3V0bGluZTowcHg7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDp0cmFuc3Bh
cmVudDtmb250LWZhbWlseTpwcm94aW1hLW5vdmEtemVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5
c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJnF1b3Q7U2Vnb2UgVUkmcXVvdDssUm9ib3RvLE94eWdl
bi1TYW5zLFVidW50dSxDYW50YXJlbGwsJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssQXJpYWws
c2Fucy1zZXJpZjtmb250LXdlaWdodDo2MDAiIGNsYXNzPSIiPjxmb250IHNpemU9IjIiIGNsYXNz
PSIiPkNPTkZJREVOVElBTElUWQ0KIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25m
aWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBk
aXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkN
CiB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdl
IGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48
L2ZvbnQ+PC9zcGFuPjwvaT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7435DB603DD1443A89E09F524B0B2548mitedu_--


From nobody Mon Apr  8 21:44:59 2019
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 5EA1312039E for ; Mon,  8 Apr 2019 21:44:57 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 YyfaH3UTo9JK for ; Mon,  8 Apr 2019 21:44:54 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 1595F120314 for ; Mon,  8 Apr 2019 21:44:54 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id w30so18251885qta.8 for ; Mon, 08 Apr 2019 21:44:54 -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=uMC/VIA7U0VxW6Ef4JKCaAhrMCBKE1YERnpwLa4AY5I=; b=l6SSFg27DpD2n6k4YObV/GQg8dO6U9z++tHF4D+c+q/Lv+Rh5GPc+4B+qHCHi3Y+Df N5fk8qny33u+DELomQhhzbj0opkyne1x3XhFehRgubBAsihj3l6JboHQsa6tde63fEQY GDxdmXVdQKT2oNjP7HqGWf8qma6TKGzRTswS2JFfLA0QQcWlHXPJG0bvtdFp1WX0cdqV 9a4Xx+/iOGmLJa7+b19YDywj3JWwmwBYwglLXCIdjgn1bcu6C9J/ltJGxobNV9OR/x6Z HRWdOJTod+OhJ48K87iDopN09mue7Ne6OfN2ixNUkE+FT0QJOjYfKeG+6TiddbbiHhjc LUWw==
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=uMC/VIA7U0VxW6Ef4JKCaAhrMCBKE1YERnpwLa4AY5I=; b=rHvYF/469Upfvcj/xxlPkiCM7hq9LBjI9sBR1Jqhk8V7EOnNmhyHLJNhuLnYkQ7o2h 4DY0aeQVpHbON9JvfSU5lpSutjiMcCApn2nrEqCKTKu0pNdwJVhvJPTY5RUMxSX9I1pC L0hsMn4l4FW5CnSgndKcx/BrD2ksnUhCBP+wfM3Am6bpQvDwKTInjVT7YqagvDIayvIk wkM8ftqYQc9SfO4pOO9cv1BmEtI05J8k/13nWXo3iV7OJs2uhDjBUEJfy4/6MqjSbOKN Z7w4KkvLdt/gtUGzNYe5sglrQWHSxY0W3U7ZzvvdXpgTFFAr4trSx5kRzDBo/URKTlzE bqtQ==
X-Gm-Message-State: APjAAAUKxjUuS7AzHqLpw8HL2grga2xxgUCcHacY0p/j6/leTxfn5/xV 81GERh1GBqWRSQkxRs1NU6FVs4EhsI5RUhkFCFY+9RAN3dgu
X-Google-Smtp-Source: APXvYqytFp6ibJpyayO3/2exotTgbC/cNY/NtQs3JQUb7peOGfQyI28wgho13HefEXVetjumTjmhKWuLdSHMBnKQvg4=
X-Received: by 2002:a0c:89b5:: with SMTP id 50mr26931612qvr.156.1554785093122;  Mon, 08 Apr 2019 21:44:53 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 8 Apr 2019 21:44:51 -0700
From: Dominick Baier 
In-Reply-To: 
References:  <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>  <81695294-fcde-4501-b520-ae48cd632a56@aol.com> 
MIME-Version: 1.0
Date: Mon, 8 Apr 2019 21:44:51 -0700
Message-ID: 
To: William Denniss ,  George Fletcher 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000002d91720586119dcb"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2019 04:44:57 -0000

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

+1

=E2=80=94=E2=80=94=E2=80=94
Dominick

On 8. April 2019 at 20:21:21, William Denniss (
wdenniss=3D40google.com@dmarc.ietf.org) wrote:

I support adoption of this draft as a working group document.

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher  wrote:

> +1 for me as well :)
>
> On 4/8/19 1:38 PM, Hans Zandbelt wrote:
>
> +1
>
> Hans.
>
> On Mon, Apr 8, 2019, 19:34 John Bradley  wrote:
>
>> I agree this should be adopted as a working group document.
>>
>>
>> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
>> > Hi all,
>> >
>> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
>> Tokens'?? document following the positive feedback at the last IETF meet=
ing
>> in Prague.
>> >
>> > Here is the document:
>> > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>> >
>> > Please let us know by April 22nd whether you accept / object to the
>> > adoption of this document as a starting point for work in the OAuth
>> > working group.
>> >
>> > Ciao
>> > Hannes & Rifaat
>> >
>> > IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. 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 listOAuth@ietf.orghttps://www.ietf..org/mailman/listinfo/oa=
uth 
>
>
> _______________________________________________
> 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

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

=

+1 
 
=E2=80=94=E2=80=94=E2=80=94
Do=
minick
 
On 8. April 2019 at 20:21:21=
, William Denniss (wdenniss=3D40google.com@dmarc.ietf.org) wrote:
 







I support adoption of this draft as a working group
document.






On Mon, Apr 8, 2019 at 11:11 AM
George Fletcher <gffletch=3D=
40aol.com@dmarc.ietf.org>
wrote:




+1
for me as well :)




On 4/8/19
1:38 PM, Hans Zandbelt wrote:




+1




Hans.








On Mon, Apr 8, 2019, 19:34 John
Bradley <ve7jtb@v=
e7jtb.com> wrote:



I agree this should be adopted as a working group document.





On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:

> Hi all,

>

> this is the call for adoption of the 'JWT Usage in OAuth2
Access Tokens'?? document following the positive feedback at the
last IETF meeting in Prague.

>

> Here is the document:

> https://tools.ie=
tf.org/html/draft-bertocci-oauth-access-token-jwt-00


>

> Please let us know by April 22nd whether you accept / object
to the

> adoption of this document as a starting point for work in the
OAuth

> working group.

>

> Ciao

> Hannes & Rifaat

>

> IMPORTANT NOTICE: The contents of this email and any
attachments are confidential and may also be privileged. If you are
not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for
any purpose, or store or copy the information in any medium. Thank
you.

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailman/listinfo/oau=
th



_______________________________________________

OAuth mailing list

OAut=
h@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.iet=
f.org/mailman/listinfo/oauth



--0000000000002d91720586119dcb--


From nobody Tue Apr  9 00:40:52 2019
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 1E2FE1203C2 for ; Tue,  9 Apr 2019 00:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=scottbrady91-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 PIC79jP0sFB7 for ; Tue,  9 Apr 2019 00:40:49 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 7F2BC1200FE for ; Tue,  9 Apr 2019 00:40:49 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id 103so14659525otd.9 for ; Tue, 09 Apr 2019 00:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scottbrady91-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oGuIIA0nNzOMuazUuCMdoNQwrimKA/rCBbILlmovSbY=; b=MSe60V7ZaDdDiPWi8YWovacfBYxbCnfIsp/wQwTLbezaa62T8pfrU19k622kuF81Jf Zhw98+sMouWFRboglF5bc1ZzphO+FbdzIc5FgfeiFlKOXxfT5AgbV7K7st+UN9oHvvXN LrpRl2qc7jjgut8B9cFRNHBE/YTNNCG+vo8aNsJgqVnxXR7+a6d5X4u2uKAIPzjGsFSr rZaiGfMoISDXCUHGI1Z5Ww7sQz86LYxXU98zfw4cyAou6it4a6opD0n6dnCkzjZrStw1 DjJeH7AYg27069Q4QilsYHdACV3Ita3U670kyCxsrpsLzWkCMZSKhbX4ifXchrwNnQMq u3CA==
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=oGuIIA0nNzOMuazUuCMdoNQwrimKA/rCBbILlmovSbY=; b=okOAFvaUfQ3kmLnXV1jcXsBjp5rC9HmYdgA0Spr9dPWRwrimp/+O1vBm4/cfSAJzCX yDT8kkL/Lh+8sWp2ulIoCGWvvWsKsJ0HfhNd69oNLiff2NiY2YMNYJVfOieYGKEOL3Za 7NIoiJ9NE8PtZu/RldtqyqtsKTPaLk9q0/fPYjeGl3rhpBR9NnHG0ItZC33QxpSlWYxe GMwvvYw7/twAKup2Id3VWEje+4S7ZgJT7+f2BQCEZ6Q7GFhSi8dLhiZp3iQlzADXlUn2 lH/iwflYnAWz/q+48nq10B+vcxMHZapZaK5UqCIqEhBhaAYfUwbHbTXyWdAQwZs1glcY ijfA==
X-Gm-Message-State: APjAAAWLoxrL2oKVvUcm6AEUGLzcc4gXWM7m+1WgRIWkmaOhgwK8VyD7 7NTSaZAUIFE6rC2uhwDxdSoOwMAQlxh035pbi2k61cVf
X-Google-Smtp-Source: APXvYqxjl7/d36NA9Kc+RWR4uQfUzHPuG8u1ZQtnvBiPDBu1m7m9ZfiDY1reUeI7+IrMnAUWzWvKXslues0Bpblvj5w=
X-Received: by 2002:a9d:738c:: with SMTP id j12mr22440722otk.119.1554795648479;  Tue, 09 Apr 2019 00:40:48 -0700 (PDT)
MIME-Version: 1.0
References:  <7caf266b-559b-52dc-e5fd-68d43c827ef8@ve7jtb.com>  <81695294-fcde-4501-b520-ae48cd632a56@aol.com>  
In-Reply-To: 
From: Scott Brady 
Date: Tue, 9 Apr 2019 08:40:36 +0100
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000538bd605861412b9"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2019 07:40:51 -0000

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

+1

On Tue, Apr 9, 2019 at 5:45 AM Dominick Baier 
wrote:

> +1
>
> =E2=80=94=E2=80=94=E2=80=94
> Dominick
>
> On 8. April 2019 at 20:21:21, William Denniss (
> wdenniss=3D40google.com@dmarc.ietf.org) wrote:
>
> I support adoption of this draft as a working group document.
>
> On Mon, Apr 8, 2019 at 11:11 AM George Fletcher  40aol.com@dmarc.ietf.org> wrote:
>
>> +1 for me as well :)
>>
>> On 4/8/19 1:38 PM, Hans Zandbelt wrote:
>>
>> +1
>>
>> Hans.
>>
>> On Mon, Apr 8, 2019, 19:34 John Bradley  wrote:
>>
>>> I agree this should be adopted as a working group document.
>>>
>>>
>>> On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
>>> > Hi all,
>>> >
>>> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
>>> Tokens'?? document following the positive feedback at the last IETF mee=
ting
>>> in Prague.
>>> >
>>> > Here is the document:
>>> > https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>>> >
>>> > Please let us know by April 22nd whether you accept / object to the
>>> > adoption of this document as a starting point for work in the OAuth
>>> > working group.
>>> >
>>> > Ciao
>>> > Hannes & Rifaat
>>> >
>>> > IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy =
the
>>> information in any medium. Thank you.
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://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
Thanks,

Scott Brady
scottbrady91.com 

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


+1

On Tue, Apr 9, 2019 at 5:45 AM Domi=
nick Baier <dbaier@leastpri=
vilege.com> wrote:
+=
1
 
 
=E2=
=80=94=E2=80=94=E2=80=94
Dominick
 
On 8. April 2019 at 20:21:21, William Denniss=
 (wdenniss=3D40google.com@dmarc.ietf.org) wrote:
 







I support adoption of this draft as a working group
document.






On Mon, Apr 8, 2019 at 11:11 AM
George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org>
wrote:




+1
for me as well :)




On 4/8/19
1:38 PM, Hans Zandbelt wrote:




+1




Hans.








On Mon, Apr 8, 2019, 19:34 John
Bradley <ve7jtb@v=
e7jtb.com> wrote:



I agree this should be adopted as a working group document.





On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:

> Hi all,

>

> this is the call for adoption of the 'JWT Usage in OAuth2
Access Tokens'?? document following the positive feedback at the
last IETF meeting in Prague.

>

> Here is the document:

> https://tools.ie=
tf.org/html/draft-bertocci-oauth-access-token-jwt-00


>

> Please let us know by April 22nd whether you accept / object
to the

> adoption of this document as a starting point for work in the
OAuth

> working group.

>

> Ciao

> Hannes & Rifaat

>

> IMPORTANT NOTICE: The contents of this email and any
attachments are confidential and may also be privileged. If you are
not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for
any purpose, or store or copy the information in any medium. Thank
you.

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ietf.org/mailman/listinfo/oau=
th



_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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










_______________________________________________
OAuth mailing list
OAuth@ie=
tf.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




-- 


Thanks,







Scott Brady






--000000000000538bd605861412b9--


From nobody Tue Apr  9 01:43:21 2019
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 0CCBA120779 for ; Tue,  9 Apr 2019 01:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 xHmHGfa7r6wZ for ; Tue,  9 Apr 2019 01:43:12 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450: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 C75C4120789 for ; Tue,  9 Apr 2019 01:43:11 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id d1so14127372edd.13 for ; Tue, 09 Apr 2019 01:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/2pzpomSjSL6a5eaonmVQjzi81h1itLpurW5rNautuQ=; b=Lijrit4Xpbph8ZraCwq/AF3w8kb6fdENP4jFcCvbfR2431CgkZTY0dfxB5ACDPpfVN 2D8kJCnkLDoahUW/LUJuLgXNSCNA063r4MCDhTaTExl+lCunsyaBafcATq06FmChU5s4 8Vmr1NyfTS5qvjgjdjifzp1lTqqgKQyx2rq40=
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=/2pzpomSjSL6a5eaonmVQjzi81h1itLpurW5rNautuQ=; b=eAmlt7HcM3bfTMjStFNNIy0MArnoUikHvQM9MixWxqe57yhaDfVuZu8HdXmY7FOlS7 md8mLPVJw4DjUtey6TENpteMqMtpB2mkGHVu/o9YNLCo9BpphdN74BNOh4w0rWweS9e8 XEy4iMneHUQXFcEyv02HnemRV5/ItMz8KRVf7tMajAQ++5xGYv1GRJUcITNe7n2U00X9 r37dQK4GsHtV4z0xwsPexSWVTJRtk4l1gyUXqFRAGKsDAv+OnukKQ7182dhVd9el+AJj RrYTCtNyLE91HNq78QntG3OQEm9poMTq4kVDFcldcBDjpR1AeAtdv8fcaxHYvPmn4V0X YGow==
X-Gm-Message-State: APjAAAWGZ6FFLy6HOjyV2QkdRIp06u6mJxpzFf1CMj8k23798Phc2iB4 Q006hMcqFJhcTKv+W+ypDBTEJlnT/aI=
X-Google-Smtp-Source: APXvYqxUwrHfq7tM6b8G2F1U7jiydi6f+9S5w8IOYJdIwl63YQS0FCBOCs32OMVB0HG0VMADBrOw7Q==
X-Received: by 2002:a17:906:498b:: with SMTP id p11mr20025345eju.119.1554799390097;  Tue, 09 Apr 2019 01:43:10 -0700 (PDT)
Received: from [192.168.2.118] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id l22sm5817974eja.67.2019.04.09.01.43.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 01:43:09 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden 
In-Reply-To: 
Date: Tue, 9 Apr 2019 09:43:07 +0100
Cc: "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2019 08:43:20 -0000

I support adoption of this draft.

=E2=80=94 Neil

> On 8 Apr 2019, at 18:07, Hannes Tschofenig  =
wrote:
>=20
> Hi all,
>=20
> this is the call for adoption of the 'JWT Usage in OAuth2 Access =
Tokens'  document following the positive feedback at the last IETF =
meeting in Prague.
>=20
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>=20
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>=20
> Ciao
> Hannes & Rifaat
>=20
> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended =
recipient, please notify the sender immediately and do not disclose the =
contents to any other person, use it for any purpose, or store or copy =
the information in any medium. Thank you.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Apr  9 13:39:00 2019
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 73E96120412 for ; Tue,  9 Apr 2019 13:38:58 -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, HTML_MESSAGE=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 VdV1iLlbnrwS for ; Tue,  9 Apr 2019 13:38:56 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 41815120408 for ; Tue,  9 Apr 2019 13:38:55 -0700 (PDT)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x39Kcoeh025760; Tue, 9 Apr 2019 16:38:53 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 9 Apr 2019 16:38:04 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 9 Apr 2019 16:38:49 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 9 Apr 2019 16:38:49 -0400
From: Justin Richer 
To: Filip Skokan 
CC: oauth 
Thread-Topic: [OAUTH-WG] CORS and the Device Authorization Grant (device flow)
Thread-Index: AQHU69Lw8hyWSP3eeU+KRY9ERJ+QfaY0k+CA
Date: Tue, 9 Apr 2019 20:38:49 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_CE3FD122907B482088D2BF8EF74BE1CFmitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] CORS and the Device Authorization Grant (device flow)
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, 09 Apr 2019 20:38:58 -0000

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

SSBoYXZlIG5vdCBzZWVuIHRoaXMgYXMgYSByZXF1aXJlbWVudCwgYnV0IHRoZSBkZXZpY2VzIHRo
YXQgSeKAmXZlIHdvcmtlZCBvbiB3ZXJlIG5vdCBpbXBsZW1lbnRlZCBvciBjb25zdHJhaW5lZCBp
biB0aGUgc2FtZSB3YXkgdGhhdCB5b3VycyB3ZXJlLiBUaGlzIHNlZW1zIGxpa2UgaXQgaXMgYSBk
ZXRhaWwgb2YgdGhhdCBlbnZpcm9ubWVudC4gVGhhdCBzYWlkLCB0aGUgZGV2aWNlIGdyYW50IHNw
ZWMgZG9lc27igJl0IHByZWNsdWRlIHRoZSB1c2Ugb2YgQ09SUyBvbiB0aGUgZGV2aWNlIGVuZHBv
aW50IGJ5IGJlaW5nIHNpbGVudCBhYm91dCBpdC4gSSBkb27igJl0IHNlZSBoYXJtIGluIG1lbnRp
b25pbmcgQ09SUyBpbiB0aGlzIGRyYWZ0LCBidXQgSSB3b3VsZCBkZWZlciB0byBvdGhlcnMgd2l0
aCBtb3JlIGRpcmVjdCBleHBlcmllbmNlIGluIGRldmljZSBpbXBsZW1lbnRhdGlvbi4NCg0K4oCU
IEp1c3Rpbg0KDQpPbiBBcHIgNSwgMjAxOSwgYXQgMToxMyBQTSwgRmlsaXAgU2tva2FuIDxwYW52
YS5pcEBnbWFpbC5jb208bWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZWxs
byAqLA0KDQpJIHJlY2FsbCBpbXBsZW1lbnRpbmcgYW4gZWFybHkgZHJhZnQgb2YgdGhpcyBmbG93
IGZldyB5ZWFycyBhZ28gZm9yIGEgY2xpZW50IGxhbmRzY2FwZSBjb21wb3NlZCBwcmltYXJpbHkg
b2Ygb2xkZXIgc2V0LXRvcCBib3hlcywgb2xkIGFuZCBuZXcgVFYgbW9kZWxzIG9mIHZhcmlvdXMg
YnJhbmRzIChMRywgU2Ftc3VuZywgU29ueSkgYW5kIGFsc28gSGJiVFYgc3RhbmRhcmRzIDEuNSBh
bmQgMi4wLg0KDQpJIHJlbWVtYmVyIGhhdmluZyB0byBzZXQgdXAgQ09SUyBvbiBib3RoIHRoZSBk
ZXZpY2UgYXV0aG9yaXphdGlvbiBhbmQgdG9rZW4gZW5kcG9pbnRzICh1bmhlYXJkIG9mIGF0IHRo
ZSB0aW1lISkgZm9yIHRoZSBzYWtlIG9mIHRoZXNlIGNsaWVudHMuLg0KDQpUaGUgcmVhc29uIHRo
ZXkgcmVxdWlyZWQgQ09SUyBpcyB0aGF0IHRoZXNlIHdlcmUgaW1wbGVtZW50ZWQgdXNpbmcsIG1v
c3RseSBwcm9wcmlldGFyeSwgeGh0bWwvaHRtbDUgYmFzZWQgc2FuZGJveGVzIHJ1bm5pbmcgb24g
dGhvc2UgZGV2aWNlcy4gVGhlIEFQSXMgZGV2ZWxvcGVycyB3ZXJlIGdpdmVuIHdlcmUgamF2YXNj
cmlwdCBvbmVzLCBtb3JlIHNwZWNpZmljYWxseSB0aGUgaHR0cCBjbGllbnQgd2FzIG9idmlvdXNs
eSBYTUxIdHRwUmVxdWVzdCBhbmQgdGhlIHdob2xlIGFwcCB3aGVuIGJlaW5nIGRldmVsb3BlZCB3
YXMgZGVidWdnZWQgaW4gYSByZWd1bGFyIGJyb3dzZXIuDQoNClNpbmNlIHRoZSBzcGVjaWZpY2F0
aW9uIGRvZXMgbm90IG1lbnRpb24gQ09SUyBhbnl3aGVyZSBJIHdvbmRlciBpZg0KYSkgSSB3YXMg
ZGVjZWl2ZWQgYnkgb3VyIGJ1c2luZXNzIHBhcnRuZXJzIHRvIHRoaW5rIHRoaXMgd2FzIGEgZ2Vu
ZXJpYyBwcm9ibGVtIG9mIHRoZXNlIGNsaWVudCB0eXBlcyBhbmQgbm90IGp1c3QgZGV2ZWxvcGVy
cyBiZWluZyBsYXp5IHRvIHR1cm4gb2ZmIGNvcnMgd2hlbiBkZWJ1Z2dpbmcsDQpiKSB0aGlzIHdh
cyBjb3JyZWN0ZWQgb3INCmMpIGl0J3Mgc3RpbGwgaGFwcGVuaW5nIGFuZCBub29uZSBqdXN0IGRp
ZG4ndCBicm91Z2h0IGl0IHVwDQoNCldoYXQgYXJlIHlvdXIgZXhwZXJpZW5jZXMgd2l0aCBDT1JT
IHNldHVwIG9uIHRoZSBkZXZpY2UgYXV0aG9yaXphdGlvbiBhbmQgdG9rZW4gZW5kcG9pbnRzIGlu
IHJlbGF0aW9uIHRvIGRldmljZSBmbG93IGZvciBTbWFydCBUViwgc2V0LXRvcCBib3hlcyBhbmQg
SGJiVFYgc3RyZWFtIGFwcHMgKGV4Y2x1ZGluZyB0dk9TIGFuZCBBbmRyb2lkVFYpLg0KDQpCZXN0
LA0KRmlsaXANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_CE3FD122907B482088D2BF8EF74BE1CFmitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgaGF2ZSBub3Qgc2VlbiB0aGlzIGFzIGEgcmVx
dWlyZW1lbnQsIGJ1dCB0aGUgZGV2aWNlcyB0aGF0IEnigJl2ZSB3b3JrZWQgb24gd2VyZSBub3Qg
aW1wbGVtZW50ZWQgb3IgY29uc3RyYWluZWQgaW4gdGhlIHNhbWUgd2F5IHRoYXQgeW91cnMgd2Vy
ZS4gVGhpcyBzZWVtcyBsaWtlIGl0IGlzIGEgZGV0YWlsIG9mIHRoYXQgZW52aXJvbm1lbnQuIFRo
YXQgc2FpZCwgdGhlIGRldmljZSBncmFudCBzcGVjIGRvZXNu4oCZdCBwcmVjbHVkZSB0aGUgdXNl
IG9mDQogQ09SUyBvbiB0aGUgZGV2aWNlIGVuZHBvaW50IGJ5IGJlaW5nIHNpbGVudCBhYm91dCBp
dC4gSSBkb27igJl0IHNlZSBoYXJtIGluIG1lbnRpb25pbmcgQ09SUyBpbiB0aGlzIGRyYWZ0LCBi
dXQgSSB3b3VsZCBkZWZlciB0byBvdGhlcnMgd2l0aCBtb3JlIGRpcmVjdCBleHBlcmllbmNlIGlu
IGRldmljZSBpbXBsZW1lbnRhdGlvbi4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0
ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48
YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh
c3M9IiI+T24gQXByIDUsIDIwMTksIGF0IDE6MTMgUE0sIEZpbGlwIFNrb2thbiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnBhbnZhLmlwQGdtYWlsLmNvbSIgY2xhc3M9IiI+cGFudmEuaXBAZ21haWwuY29t
PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp
bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFz
cz0iIj5IZWxsbyAqLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+SSByZWNhbGwgaW1wbGVtZW50aW5nIGFuIGVhcmx5IGRyYWZ0IG9mIHRo
aXMgZmxvdyBmZXcgeWVhcnMgYWdvIGZvciBhIGNsaWVudCBsYW5kc2NhcGUgY29tcG9zZWQgcHJp
bWFyaWx5IG9mIG9sZGVyIHNldC10b3AgYm94ZXMsIG9sZCBhbmQgbmV3IFRWIG1vZGVscyBvZiB2
YXJpb3VzIGJyYW5kcyAoTEcsIFNhbXN1bmcsIFNvbnkpIGFuZCBhbHNvIEhiYlRWIHN0YW5kYXJk
cyAxLjUgYW5kIDIuMC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPkkgcmVtZW1iZXIgaGF2aW5nIHRvIHNldCB1cCBDT1JTIG9uIGJvdGgg
dGhlIGRldmljZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMgKHVuaGVhcmQgb2Yg
YXQgdGhlIHRpbWUhKSBmb3IgdGhlIHNha2Ugb2YgdGhlc2UgY2xpZW50cy4uPGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj5UaGUgcmVhc29uIHRoZXkgcmVxdWlyZWQgQ09SUyBpcyB0aGF0IHRoZXNlIHdlcmUgaW1w
bGVtZW50ZWQgdXNpbmcsIG1vc3RseSBwcm9wcmlldGFyeSwgeGh0bWwvaHRtbDUgYmFzZWQgc2Fu
ZGJveGVzIHJ1bm5pbmcgb24gdGhvc2UgZGV2aWNlcy4gVGhlIEFQSXMgZGV2ZWxvcGVycyB3ZXJl
IGdpdmVuIHdlcmUgamF2YXNjcmlwdCBvbmVzLCBtb3JlIHNwZWNpZmljYWxseSB0aGUgaHR0cCBj
bGllbnQgd2FzIG9idmlvdXNseQ0KIFhNTEh0dHBSZXF1ZXN0IGFuZCB0aGUgd2hvbGUgYXBwIHdo
ZW4gYmVpbmcgZGV2ZWxvcGVkIHdhcyBkZWJ1Z2dlZCBpbiBhIHJlZ3VsYXIgYnJvd3Nlci48L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNp
bmNlIHRoZSBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1lbnRpb24gQ09SUyBhbnl3aGVyZSBJIHdv
bmRlciBpZjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hKSBJIHdhcyBkZWNlaXZlZCBieSBvdXIgYnVz
aW5lc3MgcGFydG5lcnMgdG8gdGhpbmsgdGhpcyB3YXMgYSBnZW5lcmljIHByb2JsZW0gb2YgdGhl
c2UgY2xpZW50IHR5cGVzIGFuZCBub3QganVzdCBkZXZlbG9wZXJzIGJlaW5nIGxhenkgdG8gdHVy
biBvZmYgY29ycyB3aGVuIGRlYnVnZ2luZyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YikgdGhpcyB3
YXMgY29ycmVjdGVkIG9yPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmMpIGl0J3Mgc3RpbGwgaGFwcGVu
aW5nIGFuZCBub29uZSBqdXN0IGRpZG4ndCBicm91Z2h0IGl0IHVwPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaGF0IGFyZSB5b3VyIGV4
cGVyaWVuY2VzIHdpdGggQ09SUyBzZXR1cCBvbiB0aGUgZGV2aWNlIGF1dGhvcml6YXRpb24gYW5k
IHRva2VuIGVuZHBvaW50cyBpbiByZWxhdGlvbiB0byBkZXZpY2UgZmxvdyBmb3IgU21hcnQgVFYs
IHNldC10b3AgYm94ZXMgYW5kIEhiYlRWIHN0cmVhbSBhcHBzIChleGNsdWRpbmcgdHZPUyBhbmQg
QW5kcm9pZFRWKS48L2Rpdj4NCjxiciBjbGVhcj0iYWxsIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFp
bD0iZ21haWxfc2lnbmF0dXJlIj5CZXN0LDxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkZpbGlw
PC9iPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNs
YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBp
ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CE3FD122907B482088D2BF8EF74BE1CFmitedu_--


From nobody Tue Apr  9 15:02:56 2019
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 6094C12047D for ; Tue,  9 Apr 2019 15:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ga2fBE8NJUyX for ; Tue,  9 Apr 2019 15:02:50 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4871D120496 for ; Tue,  9 Apr 2019 15:02:50 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5100EB80458; Tue,  9 Apr 2019 15:02:46 -0700 (PDT)
To: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: collinsauve@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20190409220246.5100EB80458@rfc-editor.org>
Date: Tue,  9 Apr 2019 15:02:46 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Technical Errata Reported] RFC7636 (5687)
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, 09 Apr 2019 22:02:55 -0000

The following errata report has been submitted for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5687

--------------------------------------
Type: Technical
Reported by: Collin Sauve 

Section: 5

Original Text
-------------
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Corrected Text
--------------
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Notes
-----
The code_verifier is not sent in the authorization request.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7636 (draft-ietf-oauth-spop-15)
--------------------------------------
Title               : Proof Key for Code Exchange by OAuth Public Clients
Publication Date    : September 2015
Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Apr  9 16:05:53 2019
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 DCCC4120479 for ; Tue,  9 Apr 2019 16:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level: 
X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 J01tN0e4egY5 for ; Tue,  9 Apr 2019 16:05:48 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-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 B1844120476 for ; Tue,  9 Apr 2019 16:05:48 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id x132so241833itf.2 for ; Tue, 09 Apr 2019 16:05:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JpBsn1cmsJxhQHBpvxUSBLh8xMR/1TwjFg9qN6Mj5UE=; b=iDR5gxtA8grdIDRQV0t0CWFc6kbJUJazOy41z2AivVxabUXfB0pg9aoCQ8AI9q6TnL r63uIU5d4/fcUG2ZuVhKLr6w/hkvbhnn56rLP/bPgeWj1xgNmIrdI3v5vEWVTMYA+Z38 OanM7t2t5H+F9Rs33ftxO/Jq6ae0SMY/nzvTo=
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=JpBsn1cmsJxhQHBpvxUSBLh8xMR/1TwjFg9qN6Mj5UE=; b=mzjc2yAnpHuvkbKMpJRmmZow2FLtSL+bMBAwnDXE2RA0TxrSOxtkNdNWkN+vCyowbX tWYTZ2nlM5Tw1KK/zPALoLAQR7iR1TkQX9TGQYWt8P8Yd8bWnICz2Q1WTUeEM8q8QAz2 cQRD3GMZXeaELW9mcvjllgm8EIeLiT+09N9NwmZXxzVwEIqPuvCMJm3dnSM2Z251R92l z2L3DHmMFOQr2ZVz8yUNF5L7rNqSXF3Nv9tyK65vuRGPJFDRcnRBBop+UD4SGzZuZjHs Tsp+Rbn3NuuiaeF/KU2EyIhJIS2bwzMJErq0zVW5kGgWZR963gNb/p8ewycM1DUgUU8Q RO+g==
X-Gm-Message-State: APjAAAWzubJiKeMbezRqqIKJPTympYVZlKZDI5uQRmeJ2NqRujXIt1WO SNb0SrtcYs5KPPMH3w+YSh+8W1RTfndDaIYHR1CfVUkxGF3oRRieiDFqT5KE0chULKogVN557Pj 5/xqeQyURJc5MbA==
X-Google-Smtp-Source: APXvYqwSsc7FsV4Csjkb5UBrsOFcq0YchIR6vxuHBXykW5hUwVjocORVMSM6sp/aqsiqyIzGWGTifHVr9P9zMVSYHPs=
X-Received: by 2002:a24:d9d0:: with SMTP id p199mr854492itg.104.1554851147725;  Tue, 09 Apr 2019 16:05:47 -0700 (PDT)
MIME-Version: 1.0
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com> <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu>
In-Reply-To: <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu>
From: Brian Campbell 
Date: Tue, 9 Apr 2019 17:05:21 -0600
Message-ID: 
To: Justin Richer 
Cc: Phil Hunt ,  George Fletcher , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000056d898058620fe6e"
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 09 Apr 2019 23:05:52 -0000

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

The thought/intent is that it's really about proof-of-possession rather
than protecting the request. So the signature is over a minimal set of
information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer  wrote:

> Corollary to this, are there thoughts of header protection under this
> method, and the associated issue of header modification?
>
> =E2=80=94 Justin
>
> On Apr 8, 2019, at 7:23 PM, Phil Hunt  wrote:
>
> Question. One of the issues that Justin Richer=E2=80=99s signing draft tr=
ied to
> address was url modification by tls terminators/load balencers/proxies/ap=
i
> gateways etc.
>
> How do you see this issue in dpop? Is it a problem?
>
> Phil
>
> On Apr 3, 2019, at 9:01 AM, George Fletcher <
> gffletch=3D40aol.com@dmarc.ietf.org> wrote:
>
> Perfect! Thank you! A couple comments on version 01...
>
>    POST /token HTTP/1.1
>    Host: server.example.com
>    Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
>    DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>
>    grant_type=3Dauthorization_code
>    &code=3DSplxlOBeZQQYbYS6WxSbIA
>    &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>    (remainder of JWK omitted for brevity)
>
>
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding
> header...
>
> Also, there is no discussion of the DPoP-Binding header outside of the
> token request, but I suspect that is the desired way to communicate the
> DPoP-Proof to the RS.
>
> Possibly an example in the session for presenting the token to the RS
> would help.
>
> Thanks,
> George
>
> On 4/3/19 11:39 AM, Daniel Fett wrote:
>
> This is fixed in -01:
>
> https://tools.ietf.org/html/draft-fett-oauth-dpop-01
> 
>
> -Daniel
>
> Am 03.04.19 um 17:28 schrieb George Fletcher:
>
> A quick question regarding...
>
>    o  "http_uri": The HTTP URI used for the request, without query and
>       fragment parts (REQUIRED).
>
>
> Is 'without' supposed to be 'with' ? The example shows the http_uri *with=
*
> the query parameters :)
>
> On 3/28/19 6:17 AM, Daniel Fett wrote:
>
> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> 
>
> Abstract
>
>    This document defines a sender-constraint mechanism for OAuth 2.0
>    access tokens and refresh tokens utilizing an application-level
>    proof-of-possession mechanism based on public/private key pairs.
>
>
> Thanks for the feedback I received so far from John, Mike, Torsten, and
> others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
> 
>
> - Daniel
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th 
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn=
E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DeQpusEFY7fROXNfEJmh0Q=
zkejgdgaVnILpbm2q8x9II&s=3D8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=3D
>
> _______________________________________________
> 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._

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


The thought/intent is that it's really about proof-of-=
possession rather than protecting the request. So the signature is over a m=
inimal set of information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer =
<jricher@mit.edu> wrote:






Corollary to this, are there thoughts of header protection under this metho=
d, and the associated issue of header modification?







=E2=80=94 Justin












Question.
 One of the issues that Justin Richer=E2=80=99s signing draft tried to addr=
ess was url modification by tls terminators/load balencers/proxies/api gate=
ways etc.=C2=A0








How do you see this issue in dpop? Is it a problem?=C2=A0




Phil




On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=3D40aol.com@dmarc.i=
etf.org> wrote:








Perfect! Thank you! A couple comments on version 01...




   POST /token HTTP/1.1
   Host: server.ex=
ample.com
   Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=3Dauthorization_code
   &code=3DSplxlOBeZQQYbYS6WxSbIA
   &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)



I believe the "(remainder of JWK..." should be moved to the DPoP-=
Binding header...



Also, there is no discussion of the DPoP-Binding header outside of the toke=
n request, but I suspect that is the desired way to communicate the DPoP-Pr=
oof to the RS.



Possibly an example in the session for presenting the token to the RS would=
 help.



Thanks,

George




On 4/3/19 11:39 AM, Daniel Fett wrote:






This is fixed in -01:







https://tools.ietf.org/html/draft-fett-oauth-dpop-01=








-Daniel









Am 03.04.19 um 17:28 schrieb George Fletcher:





A quick question regarding...



   o  "http_uri": The HTTP URI used for the request, without =
query and
      fragment parts (REQUIRED).



Is 'without' supposed to be 'with' ? The example shows the =
http_uri *with* the query parameters :)




On 3/28/19 6:17 AM, Daniel Fett wrote:






Hi all,


I published the first version of the DPoP draft at=C2=
=A0https://tools.ietf.org/html/draft-fett-oauth-dpop-00<=
/p>

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.





Thanks for the feedback I received so far from John, Mike, Torsten, and =
others during today's session or before!


If you find any errors I would welcome if you open an issue in the GitHu=
b repository at=C2=A0https://github.com/webhamster/draft-dp=
op


- Daniel =C2=A0=C2=A0=C2=A0








_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://w=
ww.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.
--00000000000056d898058620fe6e--


From nobody Tue Apr  9 16:06:15 2019
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 9FD1C1205E3 for ; Tue,  9 Apr 2019 16:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 mX3SVz0_rAvO for ; Tue,  9 Apr 2019 16:06:09 -0700 (PDT)
Received: from mail-it1-x12a.google.com (mail-it1-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 6E220120482 for ; Tue,  9 Apr 2019 16:06:09 -0700 (PDT)
Received: by mail-it1-x12a.google.com with SMTP id s3so251710itk.1 for ; Tue, 09 Apr 2019 16:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wVtz5Kg3B3W/tQ1AbOzVqdc4Ejc02Q7FH9dmc+wkyZc=; b=CuOhzwwndJpj4oRt+SfPfwyCt+TBa8IuY3swxhYfRwBgPbgHF6ov4QhT8Q+JZYcEYF a8IdbtKrbMdYSs+FLVwlpZync/VmJ9giN6xxFuKMWYxbjZnOSpFkjn4QAE7NXTvD43vL SCHT+ANDt2tcg720VYtiGccSsU85CEO7A/gFY=
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=wVtz5Kg3B3W/tQ1AbOzVqdc4Ejc02Q7FH9dmc+wkyZc=; b=FvydaKsRgL0VWeJqEbcnCAzXnCy7ILGxCQ6IYfxVBWYvJlGFX0hSp4kDViILey6L68 d2P0Poqi0BbIvGDKvBTTgKfeOmN5XROaZL8tTXEbs/r8UTDwPraFF/qgGivykMZ5d8CW AEaQY882O01dAIHwPjHJrb/GL4nnVPL6Re4Uq6c2emqHVS2he5ZeOjYiWlNSIt3Wuros upS5XD2s+Hu+jTk0NVGbcpPLNuMavYBbpfpC/Q6MTX6nS9GQpEdr2TlMgF9NwvTzoJHO dmPsLLOYLgxXSTXkyMrkACHGzOUN01MaYNXsW7PsQ7ObAOlkXvEXsY1ibAbXbNZifGPU B3qQ==
X-Gm-Message-State: APjAAAVo+pKbYy1Kp0y3ejBkoQJCPzuxE2/WR56zNHiHAAAnO2MrnUI4 P0culQvgMQnw3WwhdKM6zgQUGDb6m7HhSPVx3Xtg5CE80zM8JicwR79FFEc3rfC1uY23WEGKrS/ 7nhxmswTElPFtaA==
X-Google-Smtp-Source: APXvYqyoauZOdXNqKZlPcSBaOn1Y2+ilNMiFiSarH2Wu77FkDfO1ZJ3177R3In2wgJxF7udEnM8DOAiyeXu6JADx/F8=
X-Received: by 2002:a02:c643:: with SMTP id k3mr28667615jan.19.1554851168369;  Tue, 09 Apr 2019 16:06:08 -0700 (PDT)
MIME-Version: 1.0
References: <220488FB-C7EB-42A3-85D6-BD3756786550@mit.edu>  <42790363-5D79-411C-BE4E-D99A90E36951@mit.edu>   <7435DB60-3DD1-443A-89E0-9F524B0B2548@mit.edu>
In-Reply-To: <7435DB60-3DD1-443A-89E0-9F524B0B2548@mit.edu>
From: Brian Campbell 
Date: Tue, 9 Apr 2019 17:05:42 -0600
Message-ID: 
To: Justin Richer 
Cc: Filip Skokan , oauth 
Content-Type: multipart/alternative; boundary="00000000000091d5f3058620ffbb"
Archived-At: 
Subject: Re: [OAUTH-WG] MTLS and SAN
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, 09 Apr 2019 23:06:14 -0000

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

Thanks Justin.

On Mon, Apr 8, 2019 at 5:49 PM Justin Richer  wrote:

> Thanks for the clarifications everyone. Since I didn=E2=80=99t catch the
> one-and-only-one sentiment when reading the updates, I would recommend
> altering the text as follows in =C2=A72.1:
>
>    The PKI (public key infrastructure) method of mutual TLS OAuth client
>    authentication adheres to the way in which X.509 certificates are
>    traditionally used for authentication.  It relies on a *single *subjec=
t
>    distinguished name (DN) or a *single* subject alternative name (SAN) *=
* to authenticate the client. *The client=E2=80=99s certifica=
te chain is validated [RFC5280] and only one name value of any type is used=
 for each client.*
>    The TLS handshake is utilized to validate the client's possession of
>    the private key corresponding to the public key in the certificate
>    and to validate the corresponding certificate chain.  The client is
>    successfully authenticated if the subject information in the
>    certificate matches the *single *expected subject configured or regist=
ered for
>    that particular client (note that a predictable treatment of DN
>    values, such as the distinguishedNameMatch rule from [RFC4517 ], is
>    needed in comparing the certificate's subject DN to the client's
>    registered DN).  Revocation checking is possible with the PKI method
>    but if and how to check a certificate's revocation status is a
>    deployment decision at the discretion of the authorization server.
>    Clients can rotate their X.509 certificates without the need to
>    modify the respective authentication data at the authorization server
>    by obtaining a new certificate with the same subject from a trusted
>    certificate authority (CA).
>
>
>
> I think the listing of methods is clear enough as it is =E2=80=94 but my =
problem
> was that I read the above paragraph, then jumped right into the list belo=
w
> for the exact fields without reading its own introductory paragraph as we=
ll.
>
> =E2=80=94 Justin
>
> On Apr 8, 2019, at 1:54 PM, Brian Campbell 
> wrote:
>
> Yes, the intent is that the client be configured (dynamically or
> statically or however that comes to be) with one and only one expected
> subject, which also includes the location in the certificate that subject
> will be. And that is checked against at authentication time.
>
> As the writer of the questionable text in question, it does seem pretty
> clear to me as it is now. But as the writer, I'm also probably not well
> positioned to see how it could be made more clearer. So if either of you
> gentlemen have concrete text suggestions to help there, please send em fo=
r
> consideration.
>
> On Thu, Apr 4, 2019 at 2:55 PM Filip Skokan  wrote:
>
>> Yes.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:
>>
>>> Thank you, I did miss that text. This should be called out more
>>> explicitly in =C2=A72.1, perhaps by specifying that it is only one fiel=
d. This
>>> still doesn=E2=80=99t set precedence, but it implies that it=E2=80=99s =
an error for a
>>> client to have more than one field set of the available options. Is tha=
t
>>> your read on this as well?
>>>
>>> =E2=80=94 Justin
>>>
>>> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>>>
>>> Justin, I had the exact same question off list and believe draft 13
>>> clarified this.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>>>
>>> A client using the "tls_client_auth" authentication method MUST use
>>> exactly one of the below metadata parameters to indicate the certificat=
e
>>> subject value that the authorization server is to expect when
>>> authenticating the respective client.
>>>
>>> Then it lists the different dn/san properties.
>>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>>>
>>>> We=E2=80=99ve just started implementation of SAN-based certificate
>>>> authentication, based on the changes in version -13 of the draft. I be=
lieve
>>>> this addition is a bit unclear, due to it being added so late in the
>>>> document process.
>>>>
>>>> My question is how does an AS determine whether to DN or SAN for
>>>> certificate checking? Corollary, are these mutually exclusive or can t=
hey
>>>> be used together? Currently, the specification text lists DN and SAN a=
s an
>>>> =E2=80=9Cor=E2=80=9D with no indication whether this is an inclusive o=
r exclusive =E2=80=9Cor=E2=80=9D, and
>>>> what to do when there=E2=80=99s overlap.
>>>>
>>>> This has implications both for the implementation of the server
>>>> processing the request as well as the client metadata model, since the
>>>> client fields are all in parallel to each other. I can see a few ways =
of
>>>> handling this.
>>>>
>>>>
>>>> 1) One of the fields takes precedence over the other. Say for example
>>>> you choose the DN field: if it=E2=80=99s set, then you do DN matching =
and ignore
>>>> the SAN fields entirely, both in the cert and in the client=E2=80=99s =
registration.
>>>> Inverse is true if you choose the SAN fields over the DN but the princ=
iple
>>>> is the same. We should be explicit if there=E2=80=99s an intended prec=
edence
>>>> between these two, and even more explicit if the DN and SAN are at equ=
al
>>>> level and the AS gets to choose. We also need to be clear if it=E2=80=
=99s an error
>>>> condition if both are set simultaneously, like the way that jwks and
>>>> jwks_uri are mutually exclusive.
>>>> 2) You set an explicit switch in your client model that says whether t=
o
>>>> use the DN or the SAN fields in comparison, and your code branches bas=
ed on
>>>> that to either DN or SAN processing. This could also be added as an
>>>> explicit client metadata field, or it could be an internal detail. If =
an
>>>> internal detail, we should be explicit about there not being a predefi=
ned
>>>> precedence between the fields.
>>>> 3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s
>>>> set in the client, and at least one field MUST be set.
>>>>
>>>>
>>>> What=E2=80=99s the intended behavior for implementers, and should we b=
e more
>>>> explicit about this? We are starting our implementation with (1) pendi=
ng
>>>> the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are
>>>> implementing this in their systems.
>>>>
>>>> Thanks,
>>>> =E2=80=94 Justin
>>>>
>>>> _______________________________________________
>>>> 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.*
>
>
>

--=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._

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


Thanks Justin. 

On Mon, Apr 8, 2019 at 5:49 PM Justin R=
icher <jricher@mit.edu> wrote:=







Thanks for the clarifications everyone. Since I didn=E2=80=99t catch the on=
e-and-only-one sentiment when reading the updates, I would recommend alteri=
ng the text as follows in =C2=A72.1:






   The PKI (public key i=
nfrastructure) method of mutual TLS OAuth client
   authentication adheres to the way in which X.509 certificates are
   traditionally used for authentication.  It relies on a single sub=
ject
   distinguished name (DN) or a single subject alternative name (SAN=
) <deleted text> to authenticate the client. The client=E2=
=80=99s certificate chain is validated [RFC5280] and only one name value of=
 any type is used for each client.
   The TLS handshake is utilized to validate the client's possession of
   the private key corresponding to the public key in the certificate
   and to validate the corresponding certificate chain.  The client is
   successfully authenticated if the subject information in the
   certificate matches the single expected subject configured or reg=
istered for
   that particular client (note that a predictable treatment of DN
   values, such as the distinguishedNameMatch rule from [RFC451=
7], is
   needed in comparing the certificate's subject DN to the client's
   registered DN).  Revocation checking is possible with the PKI method
   but if and how to check a certificate's revocation status is a
   deployment decision at the discretion of the authorization server.
   Clients can rotate their X.509 certificates without the need to
   modify the respective authentication data at the authorization server
   by obtaining a new certificate with the same subject from a trusted
   certificate authority (CA).















I think the listing of methods is clear enough as it is =E2=80=94 but =
my problem was that I read the above paragraph, then jumped right into the =
list below for the exact fields without reading its own introductory paragr=
aph as well.








=E2=80=94 Justin









On Apr 8, 2019, at 1:54 PM, Brian Campbell <bcampbell@pingidentity.com>=
 wrote:








Yes, the intent is that the client be configured (dynamically or stati=
cally or however that comes to be) with one and only one expected subject, =
which also includes the location in the certificate that subject will be. A=
nd that is checked against
 at authentication time. 









As the writer of the questionable text in question, it does seem prett=
y clear to me as it is now. But as the writer, I'm also probably not we=
ll positioned to see how it could be made more clearer. So if either of you=
 gentlemen have concrete text
 suggestions to help there, please send em for consideration. 










On Thu, Apr 4, 2019 at 2:55 PM Filip =
Skokan <panva.ip=
@gmail.com> wrote:






Yes.







S pozdravem,

Filip Skokan














On Thu, 4 Apr 2019 at 22:36, Justin R=
icher <jricher@mit.=
edu> wrote:






Thank you, I did miss that text. This should be called out more explic=
itly in =C2=A72.1, perhaps by specifying that it is only one field. This st=
ill doesn=E2=80=99t set precedence, but it implies that it=E2=80=99s an err=
or for a client to have more than one field
 set of the available options. Is that your read on this as well?







=E2=80=94 Justin









On Apr 4, 2019, at 4:23 PM, Filip Skokan <panva.ip@gmail.com> wrote:










Justin, I had the exact same question off list and believe=
 draft 13 clarified this.












A client using the=C2=A0"tls_client_auth" authentication met=
hod MUST use exactly one of the below metadata parameters to indicate the c=
ertificate subject value that the authorization server is to expect when au=
thenticating the respective client.









Then it lists the different dn/san properties.










S pozdravem,

Filip Skokan




















On Thu, 4 Apr 2019 at 22:20, Justin R=
icher <jricher@mit.=
edu> wrote:






We=E2=80=99ve just started implementation of SAN-based certificate aut=
hentication, based on the changes in version -13 of the draft. I believe th=
is addition is a bit unclear, due to it being added so late in the document=
 process.=C2=A0






My question is how does an AS determine whether to DN or SAN for certi=
ficate checking? Corollary, are these mutually exclusive or can they be use=
d together?=C2=A0Currently, the specification text lists DN and SAN as an =
=E2=80=9Cor=E2=80=9D with no indication whether
 this is an inclusive or exclusive =E2=80=9Cor=E2=80=9D, and what to do whe=
n there=E2=80=99s overlap.=C2=A0






This has implications both for the implementation of the server proces=
sing the request as well as the client metadata model, since the client fie=
lds are all in parallel to each other. I can see a few ways of handling thi=
s.











1) One of the fields takes precedence over the other. Say for example =
you choose the DN field: if it=E2=80=99s set, then you do DN matching and i=
gnore the SAN fields entirely, both in the cert and in the client=E2=80=99s=
 registration. Inverse is true if you choose
 the SAN fields over the DN but the principle is the same. We should be exp=
licit if there=E2=80=99s an intended precedence between these two, and even=
 more explicit if the DN and SAN are at equal level and the AS gets to choo=
se. We also need to be clear if it=E2=80=99s an
 error condition if both are set simultaneously, like the way that jwks and=
 jwks_uri are mutually exclusive.=C2=A0


2) You set an explicit switch in your client model that says whether t=
o use the DN or the SAN fields in comparison, and your code branches based =
on that to either DN or SAN processing. This could also be added as an expl=
icit client metadata field,
 or it could be an internal detail. If an internal detail, we should be exp=
licit about there not being a predefined precedence between the fields.=C2=
=A0


3) If it=E2=80=99s allowable to use them together, you match everythin=
g that=E2=80=99s set in the client, and at least one field MUST be set.











What=E2=80=99s the intended behavior for implementers, and should we b=
e more explicit about this? We are starting our implementation with (1) pen=
ding the outcome of this thread, and I=E2=80=99d be curious to know how oth=
ers are implementing this in their systems.=C2=A0







Thanks,





=E2=80=94 Justin













_______________________________________________

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 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 this=
 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.

















<=
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.
--00000000000091d5f3058620ffbb--


From nobody Tue Apr  9 19:36:43 2019
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 7777112000E for ; Tue,  9 Apr 2019 19:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 atcwDHQ19uMc for ; Tue,  9 Apr 2019 19:36:39 -0700 (PDT)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 347E2120091 for ; Tue,  9 Apr 2019 19:36:39 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x3A2aajP017830; Tue, 9 Apr 2019 22:36:36 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 9 Apr 2019 22:35:59 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 9 Apr 2019 22:36:35 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 9 Apr 2019 22:36:35 -0400
From: Justin Richer 
To: Brian Campbell 
CC: Phil Hunt , George Fletcher , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] draft-fett-oauth-dpop-00
Thread-Index: AQHU5U95oChNewkbE0yijBoT2SQXPqYq3CgAgAADNQCAAAYXAIAIVykAgAAExACAAYh3gIAAOwWA
Date: Wed, 10 Apr 2019 02:36:35 +0000
Message-ID: 
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com> <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_C9ED70E2FB984CE2B973394853831441mitedu_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 10 Apr 2019 02:36:42 -0000

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

VGhlbiB3aHkgaW5jbHVkZSB0aGUgcmVxdWVzdCBhdCBhbGw/IFNpbXBsZXIgdG8ganVzdCBzaWdu
IGEgbm9uY2UgYW5kIHNlbmQgdGhvc2UsIHRoZW4uDQoNCuKAlCBKdXN0aW4NCg0KT24gQXByIDks
IDIwMTksIGF0IDc6MDUgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCg0KVGhlIHRo
b3VnaHQvaW50ZW50IGlzIHRoYXQgaXQncyByZWFsbHkgYWJvdXQgcHJvb2Ytb2YtcG9zc2Vzc2lv
biByYXRoZXIgdGhhbiBwcm90ZWN0aW5nIHRoZSByZXF1ZXN0LiBTbyB0aGUgc2lnbmF0dXJlIGlz
IG92ZXIgYSBtaW5pbWFsIHNldCBvZiBpbmZvcm1hdGlvbi4NCg0KT24gTW9uLCBBcHIgOCwgMjAx
OSBhdCA1OjQxIFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hl
ckBtaXQuZWR1Pj4gd3JvdGU6DQpDb3JvbGxhcnkgdG8gdGhpcywgYXJlIHRoZXJlIHRob3VnaHRz
IG9mIGhlYWRlciBwcm90ZWN0aW9uIHVuZGVyIHRoaXMgbWV0aG9kLCBhbmQgdGhlIGFzc29jaWF0
ZWQgaXNzdWUgb2YgaGVhZGVyIG1vZGlmaWNhdGlvbj8NCg0K4oCUIEp1c3Rpbg0KDQpPbiBBcHIg
OCwgMjAxOSwgYXQgNzoyMyBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KUXVlc3Rpb24uIE9uZSBvZiB0aGUg
aXNzdWVzIHRoYXQgSnVzdGluIFJpY2hlcuKAmXMgc2lnbmluZyBkcmFmdCB0cmllZCB0byBhZGRy
ZXNzIHdhcyB1cmwgbW9kaWZpY2F0aW9uIGJ5IHRscyB0ZXJtaW5hdG9ycy9sb2FkIGJhbGVuY2Vy
cy9wcm94aWVzL2FwaSBnYXRld2F5cyBldGMuDQoNCkhvdyBkbyB5b3Ugc2VlIHRoaXMgaXNzdWUg
aW4gZHBvcD8gSXMgaXQgYSBwcm9ibGVtPw0KDQpQaGlsDQoNCk9uIEFwciAzLCAyMDE5LCBhdCA5
OjAxIEFNLCBHZW9yZ2UgRmxldGNoZXIgPGdmZmxldGNoPTQwYW9sLmNvbUBkbWFyYy5pZXRmLm9y
ZzxtYWlsdG86Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNClBl
cmZlY3QhIFRoYW5rIHlvdSEgQSBjb3VwbGUgY29tbWVudHMgb24gdmVyc2lvbiAwMS4uLg0KDQoN
CiAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xDQogICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb208aHR0
cDovL3NlcnZlci5leGFtcGxlLmNvbS8+DQogICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gt
d3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04DQogICBEUG9QLUJpbmRpbmc6IGV5Smhi
R2NpT2lKU1UwRXhYelVpIC4uLg0KDQogICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZQ0K
ICAgJmNvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQQ0KICAgJnJlZGlyZWN0X3VyaT1odHRwcyUz
QSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYg0KICAgKHJlbWFpbmRlciBvZiBKV0sg
b21pdHRlZCBmb3IgYnJldml0eSkNCg0KSSBiZWxpZXZlIHRoZSAiKHJlbWFpbmRlciBvZiBKV0su
Li4iIHNob3VsZCBiZSBtb3ZlZCB0byB0aGUgRFBvUC1CaW5kaW5nIGhlYWRlci4uLg0KDQpBbHNv
LCB0aGVyZSBpcyBubyBkaXNjdXNzaW9uIG9mIHRoZSBEUG9QLUJpbmRpbmcgaGVhZGVyIG91dHNp
ZGUgb2YgdGhlIHRva2VuIHJlcXVlc3QsIGJ1dCBJIHN1c3BlY3QgdGhhdCBpcyB0aGUgZGVzaXJl
ZCB3YXkgdG8gY29tbXVuaWNhdGUgdGhlIERQb1AtUHJvb2YgdG8gdGhlIFJTLg0KDQpQb3NzaWJs
eSBhbiBleGFtcGxlIGluIHRoZSBzZXNzaW9uIGZvciBwcmVzZW50aW5nIHRoZSB0b2tlbiB0byB0
aGUgUlMgd291bGQgaGVscC4NCg0KVGhhbmtzLA0KR2VvcmdlDQoNCk9uIDQvMy8xOSAxMTozOSBB
TSwgRGFuaWVsIEZldHQgd3JvdGU6DQpUaGlzIGlzIGZpeGVkIGluIC0wMToNCg0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMTxodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0
bWxfZHJhZnQtMkRmZXR0LTJEb2F1dGgtMkRkcG9wLTJEMDEmZD1Ed01EYVEmYz1Sb1AxWXVtQ1hD
Z2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0
eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPWVRcHVzRUZZN2ZST1hOZkVKbWgwUXprZWpnZGdhVm5J
THBibTJxOHg5SUkmcz1URWE1VmdiM3JBenhiSXVhdkIxbE42NWZua1R4S29NcDdGMnJ3MUFqdUVZ
JmU9Pg0KDQotRGFuaWVsDQoNCkFtIDAzLjA0LjE5IHVtIDE3OjI4IHNjaHJpZWIgR2VvcmdlIEZs
ZXRjaGVyOg0KQSBxdWljayBxdWVzdGlvbiByZWdhcmRpbmcuLi4NCg0KDQogICBvICAiaHR0cF91
cmkiOiBUaGUgSFRUUCBVUkkgdXNlZCBmb3IgdGhlIHJlcXVlc3QsIHdpdGhvdXQgcXVlcnkgYW5k
DQogICAgICBmcmFnbWVudCBwYXJ0cyAoUkVRVUlSRUQpLg0KDQpJcyAnd2l0aG91dCcgc3VwcG9z
ZWQgdG8gYmUgJ3dpdGgnID8gVGhlIGV4YW1wbGUgc2hvd3MgdGhlIGh0dHBfdXJpICp3aXRoKiB0
aGUgcXVlcnkgcGFyYW1ldGVycyA6KQ0KDQpPbiAzLzI4LzE5IDY6MTcgQU0sIERhbmllbCBGZXR0
IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkkgcHVibGlzaGVkIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRo
ZSBEUG9QIGRyYWZ0IGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mZXR0LW9h
dXRoLWRwb3AtMDA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEZmV0dC0yRG9hdXRoLTJEZHBvcC0y
RDAwJmQ9RHdNRGFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0pu
RSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1lUXB1c0VG
WTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJnM9ZWVNR0tacTVSODZkdjBYZ3JC
c0lpanp1SThPelFxbkUtdm1VRVo4MzZoWSZlPT4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1
bWVudCBkZWZpbmVzIGEgc2VuZGVyLWNvbnN0cmFpbnQgbWVjaGFuaXNtIGZvciBPQXV0aCAyLjAN
CiAgIGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2ggdG9rZW5zIHV0aWxpemluZyBhbiBhcHBsaWNh
dGlvbi1sZXZlbA0KICAgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBtZWNoYW5pc20gYmFzZWQgb24gcHVi
bGljL3ByaXZhdGUga2V5IHBhaXJzLg0KDQoNCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgSSBy
ZWNlaXZlZCBzbyBmYXIgZnJvbSBKb2huLCBNaWtlLCBUb3JzdGVuLCBhbmQgb3RoZXJzIGR1cmlu
ZyB0b2RheSdzIHNlc3Npb24gb3IgYmVmb3JlIQ0KDQpJZiB5b3UgZmluZCBhbnkgZXJyb3JzIEkg
d291bGQgd2VsY29tZSBpZiB5b3Ugb3BlbiBhbiBpc3N1ZSBpbiB0aGUgR2l0SHViIHJlcG9zaXRv
cnkgYXQgaHR0cHM6Ly9naXRodWIuY29tL3dlYmhhbXN0ZXIvZHJhZnQtZHBvcDxodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fd2Vi
aGFtc3Rlcl9kcmFmdC0yRGRwb3AmZD1Ed01EYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhC
djdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj
TE40S1pOQSZtPWVRcHVzRUZZN2ZST1hOZkVKbWgwUXprZWpnZGdhVm5JTHBibTJxOHg5SUkmcz1S
UjN1ODJJaE43d2hyOExnWE1XTTJmV043RUtINkdPLUJzLUhSeEV3S0hFJmU9Pg0KDQotIERhbmll
bA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t
YWlsbWFuX2xpc3RpbmZvX29hdXRoJmQ9RHdNRGFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4
QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM
Y0xONEtaTkEmbT1lUXB1c0VGWTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJnM9
OExEdmZUWUVTaTFmRGVSSzdtUXJIRmVvOW9rb0o0TlRaVTRPSHllUkpXayZlPT4NCg0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v
cmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4
UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB
STFhTGNMTjRLWk5BJm09ZVFwdXNFRlk3ZlJPWE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJ
SSZzPThMRHZmVFlFU2kxZkRlUks3bVFySEZlbzlva29KNE5UWlU0T0h5ZVJKV2smZT0NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1h
eSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNv
bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlz
dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu
ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg
bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu
ayB5b3UuDQoNCg==

--_000_C9ED70E2FB984CE2B973394853831441mitedu_
Content-Type: text/html; charset="utf-8"
Content-ID: <66FD85BF511EB64CA3A56B2241222028@exchange.mit.edu>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoZW4gd2h5IGluY2x1ZGUgdGhlIHJlcXVlc3Qg
YXQgYWxsPyBTaW1wbGVyIHRvIGp1c3Qgc2lnbiBhIG5vbmNlIGFuZCBzZW5kIHRob3NlLCB0aGVu
Lg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls
ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz
OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsi
Pg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgOSwgMjAxOSwg
YXQgNzowNSBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbSIgY2xhc3M9IiI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+
Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+VGhlIHRob3VnaHQvaW50
ZW50IGlzIHRoYXQgaXQncyByZWFsbHkgYWJvdXQgcHJvb2Ytb2YtcG9zc2Vzc2lvbiByYXRoZXIg
dGhhbiBwcm90ZWN0aW5nIHRoZSByZXF1ZXN0LiBTbyB0aGUgc2lnbmF0dXJlIGlzIG92ZXIgYSBt
aW5pbWFsIHNldCBvZiBpbmZvcm1hdGlvbi48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz
cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJn
bWFpbF9hdHRyIj5PbiBNb24sIEFwciA4LCAyMDE5IGF0IDU6NDEgUE0gSnVzdGluIFJpY2hlciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz
PSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4
IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm
dDoxZXgiPg0KPGRpdiBjbGFzcz0iIj5Db3JvbGxhcnkgdG8gdGhpcywgYXJlIHRoZXJlIHRob3Vn
aHRzIG9mIGhlYWRlciBwcm90ZWN0aW9uIHVuZGVyIHRoaXMgbWV0aG9kLCBhbmQgdGhlIGFzc29j
aWF0ZWQgaXNzdWUgb2YgaGVhZGVyIG1vZGlmaWNhdGlvbj8NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246
IG5vbmU7IiBjbGFzcz0iIj4NCuKAlCBKdXN0aW48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9IiI+T24gQXByIDgsIDIwMTksIGF0IDc6MjMgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+
cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iZ21h
aWwtbV8tNDgyNDA5NzUyNjcwNTMwMzM3MmdtYWlsLW1fLTU4Mjk2OTE0NDcyMDQ5MDMxMzNBcHBs
ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh
cmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1h
bDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3do
aXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lO2Zs
b2F0Om5vbmU7ZGlzcGxheTppbmxpbmUiIGNsYXNzPSIiPlF1ZXN0aW9uLg0KIE9uZSBvZiB0aGUg
aXNzdWVzIHRoYXQgSnVzdGluIFJpY2hlcuKAmXMgc2lnbmluZyBkcmFmdCB0cmllZCB0byBhZGRy
ZXNzIHdhcyB1cmwgbW9kaWZpY2F0aW9uIGJ5IHRscyB0ZXJtaW5hdG9ycy9sb2FkIGJhbGVuY2Vy
cy9wcm94aWVzL2FwaSBnYXRld2F5cyBldGMuJm5ic3A7PC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQt
dmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7
d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUi
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls
eTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50
LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4
dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z
cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9
IiI+DQpIb3cgZG8geW91IHNlZSB0aGlzIGlzc3VlIGluIGRwb3A/IElzIGl0IGEgcHJvYmxlbT8m
bmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i
Ij5QaGlsPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpPbiBB
cHIgMywgMjAxOSwgYXQgOTowMSBBTSwgR2VvcmdlIEZsZXRjaGVyICZsdDs8YSBocmVmPSJtYWls
dG86Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh
c3M9IiI+Z2ZmbGV0Y2g9NDBhb2wuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlBlcmZlY3QhIFRoYW5rIHlvdSEg
QSBjb3VwbGUgY29tbWVudHMgb24gdmVyc2lvbiAwMS4uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCjxwcmUgY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01
ODI5NjkxNDQ3MjA0OTAzMTMzbmV3cGFnZSI+ICAgUE9TVCAvdG9rZW4gSFRUUC8xLjENCiAgIEhv
c3Q6IDxhIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayIg
Y2xhc3M9IiI+c2VydmVyLmV4YW1wbGUuY29tPC9hPg0KICAgQ29udGVudC1UeXBlOiBhcHBsaWNh
dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOA0KICAgRFBvUC1CaW5kaW5n
OiBleUpoYkdjaU9pSlNVMEV4WHpVaSAuLi4NCg0KICAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9u
X2NvZGUNCiAgICZhbXA7Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBDQogICAmYW1wO3JlZGly
ZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYg0KICAgKHJl
bWFpbmRlciBvZiBKV0sgb21pdHRlZCBmb3IgYnJldml0eSk8L3ByZT4NCjxiciBjbGFzcz0iIj4N
CkkgYmVsaWV2ZSB0aGUgJnF1b3Q7KHJlbWFpbmRlciBvZiBKV0suLi4mcXVvdDsgc2hvdWxkIGJl
IG1vdmVkIHRvIHRoZSBEUG9QLUJpbmRpbmcgaGVhZGVyLi4uPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KQWxzbywgdGhlcmUgaXMgbm8gZGlzY3Vzc2lvbiBvZiB0aGUgRFBvUC1CaW5kaW5n
IGhlYWRlciBvdXRzaWRlIG9mIHRoZSB0b2tlbiByZXF1ZXN0LCBidXQgSSBzdXNwZWN0IHRoYXQg
aXMgdGhlIGRlc2lyZWQgd2F5IHRvIGNvbW11bmljYXRlIHRoZSBEUG9QLVByb29mIHRvIHRoZSBS
Uy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQb3NzaWJseSBhbiBleGFtcGxlIGluIHRo
ZSBzZXNzaW9uIGZvciBwcmVzZW50aW5nIHRoZSB0b2tlbiB0byB0aGUgUlMgd291bGQgaGVscC48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KR2Vvcmdl
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWwtbV8tNDgyNDA5
NzUyNjcwNTMwMzM3MmdtYWlsLW1fLTU4Mjk2OTE0NDcyMDQ5MDMxMzNtb3otY2l0ZS1wcmVmaXgi
Pg0KT24gNC8zLzE5IDExOjM5IEFNLCBEYW5pZWwgRmV0dCB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21h
aWwtbV8tNDgyNDA5NzUyNjcwNTMwMzM3MmdtYWlsLW1fLTU4Mjk2OTE0NDcyMDQ5MDMxMzNtb3ot
Y2l0ZS1wcmVmaXgiPg0KVGhpcyBpcyBmaXhlZCBpbiAtMDE6PC9kaXY+DQo8ZGl2IGNsYXNzPSJn
bWFpbC1tXy00ODI0MDk3NTI2NzA1MzAzMzcyZ21haWwtbV8tNTgyOTY5MTQ0NzIwNDkwMzEzM21v
ei1jaXRlLXByZWZpeCI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls
LW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0OTAzMTMzbW96LWNp
dGUtcHJlZml4Ij4NCjxhIGNsYXNzPSJnbWFpbC1tXy00ODI0MDk3NTI2NzA1MzAzMzcyZ21haWwt
bV8tNTgyOTY5MTQ0NzIwNDkwMzEzM21vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm
Lm9yZ19odG1sX2RyYWZ0LTJEZmV0dC0yRG9hdXRoLTJEZHBvcC0yRDAxJmFtcDtkPUR3TURhUSZh
bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5h
NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209ZVFwdXNFRlk3
ZlJPWE5mRUptaDBRemtlamdkZ2FWbklMcGJtMnE4eDlJSSZhbXA7cz1URWE1VmdiM3JBenhiSXVh
dkIxbE42NWZua1R4S29NcDdGMnJ3MUFqdUVZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mZXR0LW9hdXRoLWRwb3AtMDE8L2E+PC9kaXY+
DQo8ZGl2IGNsYXNzPSJnbWFpbC1tXy00ODI0MDk3NTI2NzA1MzAzMzcyZ21haWwtbV8tNTgyOTY5
MTQ0NzIwNDkwMzEzM21vei1jaXRlLXByZWZpeCI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3
MjA0OTAzMTMzbW96LWNpdGUtcHJlZml4Ij4NCi1EYW5pZWw8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5Njkx
NDQ3MjA0OTAzMTMzbW96LWNpdGUtcHJlZml4Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iZ21haWwtbV8tNDgyNDA5NzUyNjcwNTMwMzM3MmdtYWlsLW1fLTU4Mjk2OTE0NDcy
MDQ5MDMxMzNtb3otY2l0ZS1wcmVmaXgiPg0KQW0gMDMuMDQuMTkgdW0gMTc6Mjggc2NocmllYiBH
ZW9yZ2UgRmxldGNoZXI6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlmIiBj
bGFzcz0iIj5BIHF1aWNrIHF1ZXN0aW9uIHJlZ2FyZGluZy4uLjxiciBjbGFzcz0iIj4NCjwvZm9u
dD48YnIgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJnbWFpbC1tXy00ODI0MDk3NTI2NzA1MzAzMzcy
Z21haWwtbV8tNTgyOTY5MTQ0NzIwNDkwMzEzM25ld3BhZ2UiPiAgIG8gICZxdW90O2h0dHBfdXJp
JnF1b3Q7OiBUaGUgSFRUUCBVUkkgdXNlZCBmb3IgdGhlIHJlcXVlc3QsIHdpdGhvdXQgcXVlcnkg
YW5kDQogICAgICBmcmFnbWVudCBwYXJ0cyAoUkVRVUlSRUQpLjwvcHJlPg0KPGZvbnQgZmFjZT0i
SGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KSXMg
J3dpdGhvdXQnIHN1cHBvc2VkIHRvIGJlICd3aXRoJyA/IFRoZSBleGFtcGxlIHNob3dzIHRoZSBo
dHRwX3VyaSAqd2l0aCogdGhlIHF1ZXJ5IHBhcmFtZXRlcnMgOik8YnIgY2xhc3M9IiI+DQo8L2Zv
bnQ+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWwtbV8tNDgyNDA5NzUyNjcwNTMwMzM3
MmdtYWlsLW1fLTU4Mjk2OTE0NDcyMDQ5MDMxMzNtb3otY2l0ZS1wcmVmaXgiPg0KT24gMy8yOC8x
OSA2OjE3IEFNLCBEYW5pZWwgRmV0dCB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+SGkgYWxsLDwvcD4NCjxw
IGNsYXNzPSIiPkkgcHVibGlzaGVkIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBEUG9QIGRyYWZ0
IGF0PHNwYW4gY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5
NjkxNDQ3MjA0OTAzMTMzQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgY2xh
c3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0OTAz
MTMzbW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRm
ZXR0LTJEb2F1dGgtMkRkcG9wLTJEMDAmYW1wO2Q9RHdNRGFRJmFtcDtjPVJvUDFZdW1DWENnYVdI
dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0
eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1lUXB1c0VGWTdmUk9YTmZFSm1oMFF6a2VqZ2Rn
YVZuSUxwYm0ycTh4OUlJJmFtcDtzPWVlTUdLWnE1Ujg2ZHYwWGdyQnNJaWp6dUk4T3pRcW5FLXZt
VUVaODM2aFkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMDwvYT48L3A+DQo8cHJlIHN0eWxlPSJmb250LXNp
emU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2ZvbnQtc3R5bGU6
bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5v
cm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3Rh
cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d29yZC1zcGFjaW5nOjBweCIg
Y2xhc3M9IiI+QWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2VuZGVyLWNv
bnN0cmFpbnQgbWVjaGFuaXNtIGZvciBPQXV0aCAyLjANCiAgIGFjY2VzcyB0b2tlbnMgYW5kIHJl
ZnJlc2ggdG9rZW5zIHV0aWxpemluZyBhbiBhcHBsaWNhdGlvbi1sZXZlbA0KICAgcHJvb2Ytb2Yt
cG9zc2Vzc2lvbiBtZWNoYW5pc20gYmFzZWQgb24gcHVibGljL3ByaXZhdGUga2V5IHBhaXJzLg0K
PC9wcmU+DQo8YnIgY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01
ODI5NjkxNDQ3MjA0OTAzMTMzQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8cCBjbGFzcz0i
Ij5UaGFua3MgZm9yIHRoZSBmZWVkYmFjayBJIHJlY2VpdmVkIHNvIGZhciBmcm9tIEpvaG4sIE1p
a2UsIFRvcnN0ZW4sIGFuZCBvdGhlcnMgZHVyaW5nIHRvZGF5J3Mgc2Vzc2lvbiBvciBiZWZvcmUh
PC9wPg0KPHAgY2xhc3M9IiI+SWYgeW91IGZpbmQgYW55IGVycm9ycyBJIHdvdWxkIHdlbGNvbWUg
aWYgeW91IG9wZW4gYW4gaXNzdWUgaW4gdGhlIEdpdEh1YiByZXBvc2l0b3J5IGF0PHNwYW4gY2xh
c3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0OTAz
MTMzQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgY2xhc3M9ImdtYWlsLW1f
LTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0OTAzMTMzbW96LXR4dC1s
aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fd2ViaGFtc3Rlcl9kcmFmdC0yRGRwb3AmYW1wO2Q9
RHdNRGFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm
YW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1l
UXB1c0VGWTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxwYm0ycTh4OUlJJmFtcDtzPVJSM3U4Mklo
Tjd3aHI4TGdYTVdNMmZXTjdFS0g2R08tQnMtSFJ4RXdLSEUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly9naXRodWIuY29tL3dlYmhhbXN0ZXIvZHJhZnQtZHBvcDwvYT48L3A+DQo8cCBj
bGFzcz0iIj4tIERhbmllbCAmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwtbV8tNDgyNDA5
NzUyNjcwNTMwMzM3MmdtYWlsLW1fLTU4Mjk2OTE0NDcyMDQ5MDMxMzNBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L3A+DQo8YnIgY2xhc3M9IiI+DQo8
ZmllbGRzZXQgY2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5
NjkxNDQ3MjA0OTAzMTMzbWltZUF0dGFjaG1lbnRIZWFkZXIiPg0KPC9maWVsZHNldD4NCjxwcmUg
Y2xhc3M9ImdtYWlsLW1fLTQ4MjQwOTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0
OTAzMTMzbW96LXF1b3RlLXByZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9ImdtYWlsLW1fLTQ4MjQw
OTc1MjY3MDUzMDMzNzJnbWFpbC1tXy01ODI5NjkxNDQ3MjA0OTAzMTMzbW96LXR4dC1saW5rLWFi
YnJldmlhdGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P
QXV0aEBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJnbWFpbC1tXy00ODI0MDk3NTI2NzA1MzAzMzcy
Z21haWwtbV8tNTgyOTY5MTQ0NzIwNDkwMzEzM21vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0i
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu
aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vYXV0aCZhbXA7ZD1Ed01EYVEmYW1wO2M9Um9QMVl1
bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5x
V055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPWVRcHVzRUZZN2ZST1hOZkVKbWgw
UXprZWpnZGdhVm5JTHBibTJxOHg5SUkmYW1wO3M9OExEdmZUWUVTaTFmRGVSSzdtUXJIRmVvOW9r
b0o0TlRaVTRPSHllUkpXayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9
IiI+PHNwYW4gY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+T0F1dGggbWFpbGlu
ZyBsaXN0PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3Jn
PC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48YSBocmVmPSJodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y
Z19tYWlsbWFuX2xpc3RpbmZvX29hdXRoJmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX
SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj
dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209ZVFwdXNFRlk3ZlJPWE5mRUptaDBRemtlamdk
Z2FWbklMcGJtMnE4eDlJSSZhbXA7cz04TER2ZlRZRVNpMWZEZVJLN21RckhGZW85b2tvSjROVFpV
NE9IeWVSSldrJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdXJsZGVm
ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt
YW5fbGlzdGluZm9fb2F1dGgmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4
UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ
cVBrQUkxYUxjTE40S1pOQSZhbXA7bT1lUXB1c0VGWTdmUk9YTmZFSm1oMFF6a2VqZ2RnYVZuSUxw
Ym0ycTh4OUlJJmFtcDtzPThMRHZmVFlFU2kxZkRlUks3bVFySEZlbzlva29KNE5UWlU0T0h5ZVJK
V2smYW1wO2U9PC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJw
eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6
bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50
OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6
MHB4O3RleHQtZGVjb3JhdGlvbjpub25lO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUiIGNsYXNz
PSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu
PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5
bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0
dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQt
dHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1k
ZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl
dGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpu
b3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWdu
OnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5v
cm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lO2Zsb2F0Om5vbmU7ZGlz
cGxheTppbmxpbmUiIGNsYXNzPSIiPk9BdXRoDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHls
ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFs
O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNp
bmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3Jt
Om5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9u
Om5vbmUiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBzdHlsZT0i
Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv
bnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6
bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5v
bmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiIHRhcmdldD0iX2JsYW5rIiBj
bGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj
YTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3Jt
YWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0
YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1h
bDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHN0eWxlPSJm
b250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9u
dC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpu
b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9u
ZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiIGNs
YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz
cz0iIj4NCk9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9BdXRoQGlldGYub3JnPC9h
PjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNsYXNzPSIi
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8aSBzdHlsZT0ibWFyZ2lu
OjBweDtwYWRkaW5nOjBweDtib3JkZXI6MHB4O291dGxpbmU6MHB4O3ZlcnRpY2FsLWFsaWduOmJh
c2VsaW5lO2JhY2tncm91bmQ6cmdiKDI1NSwyNTUsMjU1KTtmb250LWZhbWlseTpwcm94aW1hLW5v
dmEtemVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3RlbSxzeXN0ZW0tdWksJnF1b3Q7U2Vnb2Ug
VUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxDYW50YXJlbGwsJnF1b3Q7SGVsdmV0
aWNhIE5ldWUmcXVvdDssQXJpYWwsc2Fucy1zZXJpZjtjb2xvcjpyZ2IoODUsODUsODUpIiBjbGFz
cz0iIj48c3BhbiBzdHlsZT0ibWFyZ2luOjBweDtwYWRkaW5nOjBweDtib3JkZXI6MHB4O291dGxp
bmU6MHB4O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO2JhY2tncm91bmQ6dHJhbnNwYXJlbnQ7Zm9u
dC1mYW1pbHk6cHJveGltYS1ub3ZhLXplbmRlc2ssc3lzdGVtLXVpLC1hcHBsZS1zeXN0ZW0sQmxp
bmtNYWNTeXN0ZW1Gb250LCZxdW90O1NlZ29lIFVJJnF1b3Q7LFJvYm90byxPeHlnZW4tU2FucyxV
YnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LEFyaWFsLHNhbnMtc2Vy
aWY7Zm9udC13ZWlnaHQ6NjAwIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5DT05G
SURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk
IHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy
ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5DQogdGhlIHNl
bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55
IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9mb250Pjwv
c3Bhbj48L2k+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C9ED70E2FB984CE2B973394853831441mitedu_--


From nobody Tue Apr  9 20:56:18 2019
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 C59911205CC for ; Tue,  9 Apr 2019 20:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 XDFlzlmIdq9b for ; Tue,  9 Apr 2019 20:56:13 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8DF12022D for ; Tue,  9 Apr 2019 20:56:13 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:744d:4b75:c7bf:3de] (unknown [IPv6:2601:282:202:b210:744d:4b75:c7bf:3de]) by alkaline-solutions.com (Postfix) with ESMTPSA id 4070E3166E; Wed, 10 Apr 2019 03:56:11 +0000 (UTC)
From: David Waite 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E6FF4CF-0D68-43A0-9C60-6D39A2CE76F8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Tue, 9 Apr 2019 21:56:10 -0600
In-Reply-To: 
Cc: Brian Campbell , George Fletcher , "oauth@ietf.org" 
To: Justin Richer 
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com> <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu>  
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 10 Apr 2019 03:56:17 -0000

--Apple-Mail=_0E6FF4CF-0D68-43A0-9C60-6D39A2CE76F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

My understanding:

The proof-of-possession needs to have a limited destination to prevent =
replay against other resources. Similar to resource indicators and to =
distributed OAuth, the client is expected to use a resource URL view of =
the world rather than an access-token-specific audience or scoped view =
of the world. (And method, because thats cheap to do.)

HTTP request signing has a high degree of complexity, and has had =
several iterations each with their own strengths and weaknesses (which I =
know you are intimately familiar with!)

There is nothing currently to prevent other specification(s) adding =
extra key/values corresponding to a header set and hash, query hash, =
body hash, and so on. If that holds true in the final specification, =
then an environment could require those keys to be present, and then =
leverage DPoP for both proof-of-possession and non-repudiation.=20

-DW

> On Apr 9, 2019, at 8:36 PM, Justin Richer  wrote:
>=20
> Then why include the request at all? Simpler to just sign a nonce and =
send those, then.
>=20
> =E2=80=94 Justin
>=20
>> On Apr 9, 2019, at 7:05 PM, Brian Campbell =
> wrote:
>>=20
>> The thought/intent is that it's really about proof-of-possession =
rather than protecting the request. So the signature is over a minimal =
set of information.
>>=20
>> On Mon, Apr 8, 2019 at 5:41 PM Justin Richer > wrote:
>> Corollary to this, are there thoughts of header protection under this =
method, and the associated issue of header modification?
>>=20
>> =E2=80=94 Justin
>>=20
>>> On Apr 8, 2019, at 7:23 PM, Phil Hunt > wrote:
>>>=20
>>> Question. One of the issues that Justin Richer=E2=80=99s signing =
draft tried to address was url modification by tls terminators/load =
balencers/proxies/api gateways etc.=20
>>>=20
>>> How do you see this issue in dpop? Is it a problem?=20
>>>=20
>>> Phil
>>>=20
>>> On Apr 3, 2019, at 9:01 AM, George Fletcher =
> wrote:
>>>=20
>>>> Perfect! Thank you! A couple comments on version 01...
>>>>=20
>>>>    POST /token HTTP/1.1
>>>>    Host: server.example.com 
>>>>    Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
>>>>    DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>>>>=20
>>>>    grant_type=3Dauthorization_code
>>>>    &code=3DSplxlOBeZQQYbYS6WxSbIA
>>>>    &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>>>>    (remainder of JWK omitted for brevity)
>>>>=20
>>>> I believe the "(remainder of JWK..." should be moved to the =
DPoP-Binding header...
>>>>=20
>>>> Also, there is no discussion of the DPoP-Binding header outside of =
the token request, but I suspect that is the desired way to communicate =
the DPoP-Proof to the RS.
>>>>=20
>>>> Possibly an example in the session for presenting the token to the =
RS would help.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 4/3/19 11:39 AM, Daniel Fett wrote:
>>>>> This is fixed in -01:
>>>>>=20
>>>>> https://tools.ietf.org/html/draft-fett-oauth-dpop-01 =

>>>>>=20
>>>>> -Daniel
>>>>>=20
>>>>> Am 03.04.19 um 17:28 schrieb George Fletcher:
>>>>>> A quick question regarding...
>>>>>>=20
>>>>>>    o  "http_uri": The HTTP URI used for the request, without =
query and
>>>>>>       fragment parts (REQUIRED).
>>>>>>=20
>>>>>> Is 'without' supposed to be 'with' ? The example shows the =
http_uri *with* the query parameters :)
>>>>>>=20
>>>>>> On 3/28/19 6:17 AM, Daniel Fett wrote:
>>>>>>> Hi all,
>>>>>>>=20
>>>>>>> I published the first version of the DPoP draft at =
https://tools.ietf.org/html/draft-fett-oauth-dpop-00 =

>>>>>>> Abstract
>>>>>>>=20
>>>>>>>    This document defines a sender-constraint mechanism for OAuth =
2.0
>>>>>>>    access tokens and refresh tokens utilizing an =
application-level
>>>>>>>    proof-of-possession mechanism based on public/private key =
pairs.
>>>>>>>=20
>>>>>>> Thanks for the feedback I received so far from John, Mike, =
Torsten, and others during today's session or before!
>>>>>>>=20
>>>>>>> If you find any errors I would welcome if you open an issue in =
the GitHub repository at https://github.com/webhamster/draft-dpop =

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

>>>>>>=20
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn=
E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DeQpusEFY7fROXNfEJmh0=
QzkejgdgaVnILpbm2q8x9II&s=3D8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=3D=
 =

>>> _______________________________________________
>>> 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 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_0E6FF4CF-0D68-43A0-9C60-6D39A2CE76F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


My understanding:

The proof-of-possession needs to have a =
limited destination to prevent replay against other resources. Similar =
to resource indicators and to distributed OAuth, the client is expected =
to use a resource URL view of the world rather than an =
access-token-specific audience or scoped view of the world. (And method, =
because thats cheap to do.)

HTTP request signing has a high degree of complexity, and =
has had several iterations each with their own strengths and weaknesses =
(which I know you are intimately familiar with!)

There is nothing =
currently to prevent other specification(s) adding extra key/values =
corresponding to a header set and hash, query hash, body hash, and so =
on. If that holds true in the final specification, then an environment =
could require those keys to be present, and then leverage DPoP for both =
proof-of-possession and non-repudiation. 

-DW

On Apr =
9, 2019, at 8:36 PM, Justin Richer <jricher@mit.edu> wrote:







Then why include the request at all? Simpler to just sign a nonce and =
send those, then.







=E2=80=94 Justin









On Apr 9, 2019, at 7:05 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:






The thought/intent is that it's really about =
proof-of-possession rather than protecting the request. So the signature =
is over a minimal set of information.








On Mon, Apr 8, 2019 at 5:41 PM =
Justin Richer <jricher@mit.edu> wrote:






Corollary to this, are there thoughts of header =
protection under this method, and the associated issue of header =
modification?







=E2=80=94 Justin









On Apr 8, 2019, at 7:23 PM, Phil Hunt <phil.hunt@oracle.com> wrote:




Question.
 One of the issues that Justin Richer=E2=80=99s signing draft tried to =
address was url modification by tls terminators/load =
balencers/proxies/api gateways etc. 








How do you see this issue in dpop? Is it a problem? 




Phil




On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:








Perfect! Thank you! A couple comments on =
version 01...




=
   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=3DUTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=3Dauthorization_code
   &code=3DSplxlOBeZQQYbYS6WxSbIA
   &redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)



I believe the "(remainder of JWK..." should be moved to the DPoP-Binding =
header...



Also, there is no discussion of the DPoP-Binding header outside of the =
token request, but I suspect that is the desired way to communicate the =
DPoP-Proof to the RS.



Possibly an example in the session for presenting the token to the RS =
would help.



Thanks,

George





On 4/3/19 11:39 AM, Daniel Fett wrote:







This is fixed in -01:









https://tools.ietf.org/html/draft-fett-oauth-dpop-01=










-Daniel











Am 03.04.19 um 17:28 schrieb George Fletcher:




A quick question regarding...




=
   o  "http_uri": The HTTP URI used for the request, without query and
      fragment parts (REQUIRED).



Is 'without' supposed to be 'with' ? The example shows the http_uri =
*with* the query parameters :)





On 3/28/19 6:17 AM, Daniel Fett wrote:




Hi all,
I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00=



Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.



Thanks for the feedback I received so =
far from John, Mike, Torsten, and others during today's session or =
before!
If you find any errors I would welcome if you =
open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop
- Daniel    










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






















_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh=
8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&a=
mp;m=3DeQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=3D8LDvfTYESi1fDeR=
K7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=3D







_______________________________________________

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.












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

=

--Apple-Mail=_0E6FF4CF-0D68-43A0-9C60-6D39A2CE76F8--


From nobody Tue Apr  9 23:48:26 2019
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 70ED41202B0 for ; Tue,  9 Apr 2019 23:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=thales.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 jWpw5-gbpA5Z for ; Tue,  9 Apr 2019 23:48:21 -0700 (PDT)
Received: from mail.thales.no (mail.thales.no [213.52.79.195]) (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 74D38120071 for ; Tue,  9 Apr 2019 23:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thales.no; i=@thales.no; q=dns/txt; s=s1; t=1554878901; x=1586414901; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ESQ6iShtVsn+RGfq7/vAr6mpIKFA441OqUeNrlw4OWE=; b=Cbuyi5s00VHNS+N0xXsV0d14pnCsGN5avQSMgGxkMZxEB+svvYvfYfrX wMTUPeKT9J+OAi3NE/rvbhZMVjB6YAIQyAYPQJYJq78dje6geYTgM4AGo QAURvflQt9SbXZohA5eV1ZBPn0ypwzJDXqnNR3eTpVelbhttgtSvQ/DOs SeNPFhdsWcAclB8qkJzUPPfZlVcfkxRwXipt3osnCz+dd8dzaBGHMXtAr l0j+gseBExqobm7c3zkZL+JJECFekxuO0XiHIn6gMju91g/v+mWpNVQBe rtchdRzy3Pp6BnJk6lEwg8iv3i2eIaHPjl8aCun6Q7UcI0qenxlIPq+ps w==;
X-IronPort-AV: E=Sophos;i="5.60,332,1549926000";  d="scan'208";a="126718"
x-originating-ip: [213.52.79.195]
From: Lars Wilhelmsen 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaAAclY6AADJx8PA=
Date: Wed, 10 Apr 2019 06:48:16 +0000
Message-ID: <346f3b1237a7460ca69e15ef55bcba70@Thales.no>
References:  
In-Reply-To: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2019 06:48:25 -0000

KzENCg0KTGFycyBXaWxoZWxtc2VuDQpUaGFsZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTmVp
bCBNYWRkZW4NClNlbnQ6IHRpcnNkYWcgOS4gYXByaWwgMjAxOSAxMDo0Mw0KVG86IEhhbm5lcyBU
c2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPg0KQ2M6IG9hdXRoQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZG9wdGlvbjogSldUIFVzYWdlIGlu
IE9BdXRoMiBBY2Nlc3MgVG9rZW5zDQoNCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0
Lg0KDQrigJQgTmVpbA0KDQo+IE9uIDggQXByIDIwMTksIGF0IDE4OjA3LCBIYW5uZXMgVHNjaG9m
ZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+
IA0KPiB0aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgJ0pXVCBVc2FnZSBpbiBP
QXV0aDIgQWNjZXNzIFRva2VucycgIGRvY3VtZW50IGZvbGxvd2luZyB0aGUgcG9zaXRpdmUgZmVl
ZGJhY2sgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGluIFByYWd1ZS4NCj4gDQo+IEhlcmUgaXMg
dGhlIGRvY3VtZW50Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9j
Y2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC0wMA0KPiANCj4gUGxlYXNlIGxldCB1cyBrbm93IGJ5
IEFwcmlsIDIybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZSANCj4gYWRvcHRp
b24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBP
QXV0aCANCj4gd29ya2luZyBncm91cC4NCj4gDQo+IENpYW8NCj4gSGFubmVzICYgUmlmYWF0DQo+
IA0KPiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55
IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu
IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh
bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5
IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5n
IGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K


From nobody Wed Apr 10 04:12:29 2019
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 50C3B120112 for ; Wed, 10 Apr 2019 04:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hm0K0b2pmTLO for ; Wed, 10 Apr 2019 04:12:25 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEEB120131 for ; Wed, 10 Apr 2019 04:12:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=ZG3sTZs1G4OjHKIzQDT9kbLgyGIS96yNgj1XpUkw8pX7N+eCEd7ybECI11bkxWB5IHAekWfPBO+cNnW5JfFFGkFpMvuYFmt6ya/gygm59Z1ORzUvbY9hgJywAO9hmt1uLGaAiyENgcAnCYJYAMI9qPSmHbSgQ2PlGG/P7L4Ypac=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lb0Xevz0iYLtci4x9NQzceokMHLfOXAwW9CKAtzYipU=; b=XCI3lWG/LMfiviWAt7w+Mk7/NB3xq0NyhkFrGU02JxEcGEM1jrWSk69OslqSPFhAwngVbh+A3edesL3KHe88GBgamhOrGZD/gjrZm0sah9rn6g/ytnVmwSLjeh7tWBQK7cMPrChRJtpuKgydr5SxJZE8n2Qm42IKFs3KZkZpvhM=
ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lb0Xevz0iYLtci4x9NQzceokMHLfOXAwW9CKAtzYipU=; b=mbHGZWY7WwfSGSGj6LRB0rUu/cvpCiFulxioxfT1sbVlcJnIrks+YEJlYyDgSyGBOR6xsbSGqf0RRnQPs5Q18ucb4JSax/xSlzTCKPt5pIyOh+01D935S8AEMTaNw4784sNgaCUBrgSpmTst9ZMIr2wg9neznNU0Ns4OTI+NsTo=
Received: from MW2PR00MB0396.namprd00.prod.outlook.com (52.132.148.160) by MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1831.0; Wed, 10 Apr 2019 11:12:22 +0000
Received: from MW2PR00MB0396.namprd00.prod.outlook.com ([fe80::6c8f:347a:7e76:1ea8]) by MW2PR00MB0396.namprd00.prod.outlook.com ([fe80::6c8f:347a:7e76:1ea8%6]) with mapi id 15.20.1832.000; Wed, 10 Apr 2019 11:12:22 +0000
From: Anthony Nadalin 
To: Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaABYNsSg
Date: Wed, 10 Apr 2019 11:12:21 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; 
x-originating-ip: [77.241.229.232]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 40281ace-4c4a-4ef1-1eec-08d6bda56761
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0298; 
x-ms-traffictypediagnostic: MW2PR00MB0298:
x-ms-exchange-purlcount: 2
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(366004)(396003)(346002)(53754006)(13464003)(199004)(189003)(40434004)(71190400001)(71200400001)(8990500004)(10090500001)(22452003)(99286004)(6116002)(3846002)(446003)(7696005)(486006)(11346002)(476003)(186003)(26005)(52536014)(9686003)(76176011)(2501003)(6306002)(6506007)(110136005)(106356001)(68736007)(53936002)(316002)(6436002)(53546011)(2906002)(256004)(5024004)(14444005)(105586002)(7736002)(86362001)(86612001)(229853002)(966005)(81166006)(305945005)(8676002)(81156014)(5660300002)(14454004)(66066001)(97736004)(8936002)(55016002)(102836004)(74316002)(10290500003)(478600001)(25786009)(6246003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0298; H:MW2PR00MB0396.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dS81llPeyJ66zNzI/s969E0n2BKveLjZdEzVTflzMLMCcjjIXKog97p2QE6qBfcnmTzxmo6AFaoMI6kiuikzY+fEDUGyDxGFb8krzQupaIiiYnDI2ayWME1RamCBitqTpvwUMk6gfCAuxGb9LJ7K9Nw6q+A7w8+Rl5KOWytHmO4aT1/TDCKYz09dC1BL80buBdIUJwTIWW0g+1qxA9aqqTGPOm4Tpt2gPmVjAYneJjod9Iq6jDhi/DX2RYTj6kJHglKTQ616c8lyAr9kRb2721pqWUmwszCZDZeByjIqSI3OozZbxFeXAD3y1H/Hc4R/0XgHJmg5dxHIXA+mMT1zDs7F+6iR4ruIP00+S0IhZvDwPvpJBZziOTsFzXFfHc1FAJHib25JJjFAiVePVMIJVbwLF52bXxjqZBcYENPdxno=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 40281ace-4c4a-4ef1-1eec-08d6bda56761
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 11:12:21.9576 (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-Transport-CrossTenantHeadersStamped: MW2PR00MB0298
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2019 11:12:28 -0000

I support adoption of this draft as a working group document with the follo=
wing caveats:

1. These are not to be used as ID Tokens/authentication tokens=20
2. The privacy issues must be addressed=20
3. Needs to be extensible, much like ID-Token, can't be 100% fixed=20


-----Original Message-----
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  d=
ocument following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i=
etf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7C0=
1%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86=
f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2FHC=
RZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0

Please let us know by April 22nd whether you accept / object to the adoptio=
n of this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microsoft=
.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%=
7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDt=
lIUH7tS%2Fw%3D&reserved=3D0


From nobody Wed Apr 10 06:41:28 2019
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 138D712030A for ; Wed, 10 Apr 2019 06:41:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xw2GkjosLUZN for ; Wed, 10 Apr 2019 06:41:24 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197BB12004A for ; Wed, 10 Apr 2019 06:41:23 -0700 (PDT)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 20A90472EE2; Wed, 10 Apr 2019 22:41:23 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 868C14E0046; Wed, 10 Apr 2019 22:41:22 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id x3ADfMls032309; Wed, 10 Apr 2019 22:41:22 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id x3ADfMge032308; Wed, 10 Apr 2019 22:41:22 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x3ADfPiH054454; Wed, 10 Apr 2019 22:41:25 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id x3ADfPrH054453; Wed, 10 Apr 2019 22:41:25 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id x3ADfPYT054450; Wed, 10 Apr 2019 22:41:25 +0900
Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM07PA.cu.nri.co.jp (172.159.253.49) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 10 Apr 2019 22:41:20 +0900
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (104.47.93.52) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 10 Apr 2019 22:41:20 +0900
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com (20.179.173.206) by TYAPR01MB2160.jpnprd01.prod.outlook.com (52.133.178.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.15; Wed, 10 Apr 2019 13:41:19 +0000
Received: from TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::1dee:d017:c562:3a1e]) by TYAPR01MB4413.jpnprd01.prod.outlook.com ([fe80::1dee:d017:c562:3a1e%4]) with mapi id 15.20.1792.009; Wed, 10 Apr 2019 13:41:19 +0000
From: n-sakimura 
To: Anthony Nadalin , "Hannes Tschofenig" , "oauth@ietf.org" 
Thread-Topic: Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaABYNsSgAAUTZqA=
Date: Wed, 10 Apr 2019 13:41:19 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailadviser: 20170719
authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; 
x-originating-ip: [121.119.131.2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b9a0b510-a75f-4ac4-db90-08d6bdba3686
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:TYAPR01MB2160; 
x-ms-traffictypediagnostic: TYAPR01MB2160:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39850400004)(136003)(366004)(376002)(396003)(53754006)(199004)(189003)(13464003)(40434004)(68736007)(105586002)(106356001)(2501003)(86362001)(11346002)(446003)(476003)(99286004)(66066001)(45080400002)(486006)(478600001)(76176011)(229853002)(46636005)(966005)(14454004)(7696005)(6436002)(102836004)(6506007)(74482002)(186003)(71190400001)(53546011)(97736004)(71200400001)(26005)(33656002)(5660300002)(2906002)(110136005)(14444005)(6116002)(256004)(3846002)(5024004)(305945005)(53936002)(6246003)(316002)(6306002)(7736002)(55016002)(25786009)(8676002)(52536014)(81166006)(9686003)(8936002)(81156014)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB2160; H:TYAPR01MB4413.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pJI99W9C1PTEtvYYHBvbZH8WA7lBWt7HiuvllNpVMxpIDc31hiOh/zISdML1TcZlGF05ouapvNYDaxCQAqwXGnDylYpWSw4QB8GhZek1S1R0hHn+z1qa1h1tAsGAqsN8pjiIYYPkUpy3AbJKlMPlM7fBu60w6/1p6zxKgJo/ikrHwl6paelbm5Au+R+iA7CYdJ5dEuBDOgO9lAEMa/HNNXx9KP0klJfv5/HBoEeYt+YayDe+A7dXnUWp5GVB8GVvE8oDhzCm49YaO7txGTYI1zzwQTr/khqgwkwEYUZTF+9SrI0YYdPTNBFs53XdIXLTCAzV1IhrayHLtsdqowqEFCJu1+duimuO20Gj0luLIVCAfisePI32wug1gCabr7YPyqSAZwMucfE36VTnFUZufkFMAOQcJc8oUUft9371GkY=
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b9a0b510-a75f-4ac4-db90-08d6bdba3686
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 13:41:19.5458 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2160
X-OrganizationHeadersPreserved: TYAPR01MB2160.jpnprd01.prod.outlook.com
X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp
X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp
X-OriginatorOrg: cu.nri.co.jp
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2019 13:41:27 -0000

+1=20

For that matter, explicit typing is good and I am a bit ambivalent on the u=
se of `sub`.=20

Also, I need to add the 4th consideration: Although the current privacy con=
sideration is stating about the encryption, it is in relation to the end us=
er exposure. In fact, the by-value access token when involving some PII is =
by definition leaking information and violating the data minimization princ=
iple. This should be clearly delineated. My gut feeling is that it should b=
e encrypted unless it is certain that it does not include sensitive PII as =
judging whether a claim may form a PII is too hard for an average developer=
.=20

-----Original Message-----
From: OAuth  On Behalf Of Anthony Nadalin
Sent: Wednesday, April 10, 2019 8:12 PM
To: Hannes Tschofenig ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Token=
s

I support adoption of this draft as a working group document with the follo=
wing caveats:

1. These are not to be used as ID Tokens/authentication tokens 2. The priva=
cy issues must be addressed 3. Needs to be extensible, much like ID-Token, =
can't be 100% fixed=20


-----Original Message-----
From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  d=
ocument following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i=
etf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7C0=
1%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86=
f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2FHC=
RZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0

Please let us know by April 22nd whether you accept / object to the adoptio=
n of this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microsoft=
.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%=
7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDt=
lIUH7tS%2Fw%3D&reserved=3D0

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


From nobody Wed Apr 10 12:42:20 2019
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 F033312065D for ; Wed, 10 Apr 2019 12:42:09 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5dnghHEyjQGz for ; Wed, 10 Apr 2019 12:42:07 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 5922612060D for ; Wed, 10 Apr 2019 12:42:07 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id g8so2168516pgf.2 for ; Wed, 10 Apr 2019 12:42: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=FXzajt3fp8ivnz0qNQVjJjJg+wvoWsz2il0C3h1mFkU=; b=GkA9xpEioYtBx0g/1Ug8FuoxH7YTuLixOpJm7ofxTO2/NJPGl3+mX5r8CM1HwvI8RE zOTKTLZqud6KLJl8FLrurXD13tnH3Lo79WKMcHAkSxcMzK9GhZpVZOI6JnVt21k0iait a5pD4+uLR/CvAtKvgqHolhXRAV7rQ92yxHMbIQLzokwmP95H6momcDizr4IOz/Lj2I+k z7ycqlqV3sbgMs1RNHovF+J8Gf68Sp+Xdx/6MYc4cdakhlWKgj36mgjECiRKiYu7G5Vu mdgLa92GF2/HVtcdLUZsjfO3WglOzftOg5Z3K4INAhJocCl8T1IyijiNz9sw92PEnI/f Zl9g==
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=FXzajt3fp8ivnz0qNQVjJjJg+wvoWsz2il0C3h1mFkU=; b=nUeiqtyBjto/zMs++vj75jBMEbIXxXL97qtXuYEmojsuf/Gux/+9VjyLduOhHsda1B nhO5JavVDJxUhuLKAFeHgwqTHZBIEzLKkW/D1jcCEbgTc8NSQ3EMClYl4uysJ8t37Yrm 7civudWm49pXgWwUwA9koJsjtRZFCKxEGg+M2lHYnPj0RFb1CrjRf+m/FEf1WFZgb6Rg V5pIPtYWZGmzaefXnIcSvsDVbcJzFSfvuF+eWmkmj9D/lnt5PGuAcWPemuY0EAsfCQvK OhpYHKZZwYT1tsyLV8kYYAZhPWeIu2dg65WQn1Uxy8JuhlSF0zti+ocMJzkcwQkzBs/e xPUA==
X-Gm-Message-State: APjAAAVdSW4lZ/z/siG0LcPia0OH5OkY8XM7WBfJsGjmRJrvOy8gKMHP ufxcjUBWX/a0FDIaTi/dNuX+PCmGDAgL6xo6owQ=
X-Google-Smtp-Source: APXvYqwRNidUPtOQhguTDQ8FAfnKfonWXgb4moS+jcBhqnlYPuLiQVzAKvzoZGfRN3J4fmZwFIYASWfn7PuKGdKSdxM=
X-Received: by 2002:a62:1215:: with SMTP id a21mr44964559pfj.126.1554925326662;  Wed, 10 Apr 2019 12:42:06 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 10 Apr 2019 12:41:55 -0700
Message-ID: 
To: Hannes Tschofenig 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bf84e905863243a6"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2019 19:42:16 -0000

--000000000000bf84e905863243a6
Content-Type: text/plain; charset="UTF-8"

+1

On Mon, Apr 8, 2019 at 10:07 AM Hannes Tschofenig 
wrote:

> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1

On Mon, Apr 8, 2019 at 10:07 AM Hannes Tschofenig &l=
t;Hannes.Tschofenig@arm.com> wrote:
Hi =
all,



this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens=
'=C2=A0 document following the positive feedback at the last IETF meeti=
ng in Prague.



Here is the document:

https://tools.ietf.org/html/draf=
t-bertocci-oauth-access-token-jwt-00



Please let us know by April 22nd whether you accept / object to the

adoption of this document as a starting point for work in the OAuth

working group.



Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are 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.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000bf84e905863243a6--


From nobody Wed Apr 10 13:39:09 2019
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 BC72F1203ED for ; Wed, 10 Apr 2019 13:39:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hUhN8SeEfiH3 for ; Wed, 10 Apr 2019 13:39:04 -0700 (PDT)
Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (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 EFF9212033B for ; Wed, 10 Apr 2019 13:39:03 -0700 (PDT)
Received: by mail-ua1-f41.google.com with SMTP id h4so1256080uaj.9 for ; Wed, 10 Apr 2019 13:39:03 -0700 (PDT)
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=lFNwWtFcu5fbYJqfk1ifXXfJ9O1IrTdAfJLeL9hMQvs=; b=OzWTKCQ+dt/HkZk/0tQZnmkT7HEHkiI+QB4MSkjj6x18uuk6aN4k6av+8VsbdnSOig ueHx+Ibu1Ycvl0rPB3KDshIWWwYaYeVgJNqUn7DRiM/Ikj5q6mluq7ReBVDfXJwJeKwM v8rpLbV8zFMzfX6axtE4zKnJI88WKWIXXeVLlnjk65aM0u/sut0s5XzUWfPoXE2HeCQE 4HJv4WdT2qEEVbVQvcvTfU9dfHkirkazzy3JOzACKnyzVyx3hegr6w6lUj2A2MfA/Yuc u1SJ87j+Al7Rcrc1vX0B1hJ7hDwyqW1auwhjB4trFwYo/6sB9kV77B9WDbaiiQVu0o5R GdCg==
X-Gm-Message-State: APjAAAXuZGARy26IfD/LMC5Ub1myRYvXD/+ZcE+uoVl9CyjX/4o7xo6E rLJHPJctCGCSv8pbj6qq1YY9W9XOvhfwYAq+KwK+e0tv
X-Google-Smtp-Source: APXvYqy+PXZddlrC/ia7eOoZDkY667eDlgqtyoAmOQWrPrSepp8gEToH/D6mRPCEn5YkgrlwyNChxL9Yvq32B1E9MK4=
X-Received: by 2002:ab0:60cd:: with SMTP id g13mr23685442uam.85.1554928742890;  Wed, 10 Apr 2019 13:39:02 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Pedro Igor Silva 
Date: Wed, 10 Apr 2019 17:38:51 -0300
Message-ID: 
To: Anthony Nadalin 
Cc: Hannes Tschofenig , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005f1ce10586330f17"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2019 20:39:08 -0000

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

+1 plus Anthony's caveats.

The draft seems to provide a good reference for implementors by providing
how different ASes are using JWT as the access token format. As well as
providing valuable information about validation and security considerations=
.

Regards.
Pedro Igor

On Wed, Apr 10, 2019 at 8:12 AM Anthony Nadalin  wrote:

> I support adoption of this draft as a working group document with the
> following caveats:
>
> 1. These are not to be used as ID Tokens/authentication tokens
> 2. The privacy issues must be addressed
> 3. Needs to be extensible, much like ID-Token, can't be 100% fixed
>
>
> -----Original Message-----
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, April 8, 2019 10:07 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
>
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prag=
ue.
>
> Here is the document:
>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7=
C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf=
86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2F=
HCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth worki=
ng
> group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microso=
ft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db4=
7%7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCoo=
DtlIUH7tS%2Fw%3D&reserved=3D0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


+1 plus Anthony's caveats.=C2=A0

The draft seems to provide a good reference for im=
plementors by providing how different ASes are using JWT as the access toke=
n format. As well as providing valuable information about validation and se=
curity considerations.

Regards.
Pedro Ig=
or

On Wed, Apr 10, 2019 at 8:12 AM Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org&g=
t; wrote:
I supp=
ort adoption of this draft as a working group document with the following c=
aveats:


1. These are not to be used as ID Tokens/authentication tokens 
2. T=
he privacy issues must be addressed 
3. Needs to be extensible, much lik=
e ID-Token, can't be 100% fixed 




-----Original Message-----
From: OAuth <oauth-bounces@ietf.org> On Behalf=
 Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: oauth@ietf.org
Subject=
: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens


Hi all,


this is the call for adoption of the 'JWT Usage in OAuth2 Access To=
kens'=C2=A0 document following the positive feedback at the last IETF m=
eeting in Prague.


Here is the document:

https://nam06.safelinks.protec=
tion.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocc=
i-oauth-access-token-jwt-00&amp;data=3D02%7C01%7Ctonynad%40microsoft.co=
m%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1=
%7C1%7C636903400616347061&amp;sdata=3DePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBa=
lPoFPKtQ67QTxIRw%3D&amp;reserved=3D0


Please let us know by April 22nd whether you accept / object to the ado=
ption of this document as a starting point for work in the OAuth working gr=
oup.


Ciao
Hannes & Rifaat


IMPORTANT NOTICE: The contents of this email and any attachments are co=
nfidential and may also be privileged. If you are not the intended recipien=
t, please notify the sender immediately and do not disclose the contents to=
 any other person, use it for any purpose, or store or copy the information=
 in any medium. Thank you.


_______________________________________________
OAuth mailing list
OAuth@ietf.org

https://nam06.safelinks.protection.outlook.com/?url=3Dhtt=
ps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=3D02%7C01=
%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f=
141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&amp;sdata=3Dzcxw1IR3=
kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;reserved=3D0


_______________________________________________
OAuth mailing list
OAuth@ietf.org

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




--0000000000005f1ce10586330f17--


From nobody Thu Apr 11 01:30:46 2019
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 265BD120288 for ; Thu, 11 Apr 2019 01:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.608
X-Spam-Level: 
X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 b-57RH3uWOqI for ; Thu, 11 Apr 2019 01:30:42 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 74E1C120287 for ; Thu, 11 Apr 2019 01:30:41 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id k17so1454689wrx.10 for ; Thu, 11 Apr 2019 01:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=subject:to:references:cc:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4sjI7BkbBuPpzZkeyEIKwQsK/iBE0AG9ybnfBEX75A0=; b=dHQNB3F0o7j5GhdXaHJ2uNOXDTYhUNucLdtlrlyvEaoGH5jfU2gbLnQ9CpH3sWzk6M GmOaJVi+vFQc9FGdY/1VknMtd+Xe5//T8vdNSZ78gp4BaDO3NKDzL213v41G0eV3IE9t 3rumkMbjv/46LXpQ5//DJVByPxNj+HknSEY04=
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:cc:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=4sjI7BkbBuPpzZkeyEIKwQsK/iBE0AG9ybnfBEX75A0=; b=cVw38HRL+CjHiR3jbvOlKD41MvXix/neVdaCIyaVO2DI/WpT2ukssRR5fiyQPtiYxm HGHOTOt6xU+TQqVFdj/apmiwaKB/TX7voNBSPbXd36TdSb26xWZRhi/LzZUzBbk6ULdB rjvr+xh1RKky4HegN56EuI217BqEYSJdPYb717x5zRANaR6Zwn+7sUbboee9wyoQKMxC gaySlhgksRTnNpLhVl3zTG55DKwlyz20CBS9cuiF5kt69J4A+FCwTkGM2ItePpf6wTW2 C35/2kym8tTKyV54Q2rpN9NenICSFUWQ3eqWysGe8w+SxxY4b7AUHD/w3DA01jWL+C2Z 7BUw==
X-Gm-Message-State: APjAAAXP+FVQKZj4t+3PQtne3SlfKTtYtEq57RKsL3Uy3BMqPWpA+eAP mko91aVnqAedAZt0MiM3uLjzgPblmFpFq12NFIpLK1oDBIkR7cZHw5axkxTrcMy0e2HzC2dZc1w FNf50HZenITPJVBVwGqWXXCI+mUA+zjhI5WF68IJhbggQu0Tcu+ocnqc5uqowKStAgA==
X-Google-Smtp-Source: APXvYqzXFNrZnCNxfqGyibu0p3oG5GtFfk2f7xugX3itVmnPcKAAalSRcXzty+9+q5YNLIAmMgtjBQ==
X-Received: by 2002:a5d:464f:: with SMTP id j15mr2380638wrs.265.1554971439145;  Thu, 11 Apr 2019 01:30:39 -0700 (PDT)
Received: from ?IPv6:2a00:23c5:4ea6:f700:30e6:de96:9de7:755b? ([2a00:23c5:4ea6:f700:30e6:de96:9de7:755b]) by smtp.gmail.com with ESMTPSA id d4sm31888410wrv.42.2019.04.11.01.30.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 01:30:37 -0700 (PDT)
To: Daniel Fett 
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com>
Cc: oauth@ietf.org
From: Simon Moffatt 
Openpgp: preference=signencrypt
Autocrypt: addr=simon.moffatt@forgerock.com; prefer-encrypt=mutual; keydata= mQINBFpM/n8BEADaxItKbVxF35pwLIskzqD/KnZPVk3B5bUijuHNNCntemEq5QEfHh1b9Ogx As2hw/ZVND6Q97V7NOMithmrP0N4du+66yK+Ejyqfa8yWQPtx1q7OuscIA9YkrO9NJlKgPQL LTDoMP2hpiu+dAcMs1QxJadXjyGGFzCrLzPgOzzyV6NOGpqdSPDYf819XO2fNgcJD5uQ8D9j ULMufQ+J/+kFPTlYqRai1NTO3QxLk3woFkF8TTqslKjcKmwV7jGtSJFCIKA6CRSZjw9WIq9D 5MtDXwsdh9gUJB+KtwnzTLtOp7en+0YH14KgV/RQyy/dkXzhm8YqhufnP2e4JhFK4TmDLoZU otWid8Hkc8tNn1HwTmBxjDgU7kqvkj06RH9SyZFo8Os8ttcQYtWVahclpnJzogJ8qqL1g2VE hTEjaHdAKi8PC5JK7FEXs041fs+bymnRTczej+ZqU0oFrE/kB4n4X6tq/iWg44YAmcEfiGNN aewcI3oNuOm8qgb+0Z9HldVGSpK9W1eHDVGzNsVfLXSI2h15b0aTurfA/MEtIB5AntZLMgJA R7VQmgzlqT/ujEGMRZZIHxOTxOWisyN267NYIHRZ6ODNiGfM9NMt7srTh9vk1IguhynxdEWN S6MwnrbkdKJf3VlAMcOyckn0lXLbBKgoCXsB0zpOeKTmmi3wgwARAQABtCtTaW1vbiBNb2Zm YXR0IDxzaW1vbi5tb2ZmYXR0QGZvcmdlcm9jay5jb20+iQI9BBMBCAAnBQJaTP5/AhsjBQkJ ZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJECJvtLWEryhHkJAQALoR//eJenZoE1SL MNsM0VthhVp7am/5YfcGzkE02h8n96n5R3hJzQaBp9BDdMt2FFWbwEkWaHDujut4rONcWXxh hyfN4uoxzXzqBmcMlemNCaI9IGefGKx6rGEY5PkxAEtCYX2umLbFQGF3ggNOZeIytlK++9Z/ RgYIzKy6yYelxfChAKOd9w9UkuuJ2EfzXcmrFE6DttBBAYIM8qeWe4pVvNqpX1b0cHqkRvYP s+xcbd7qcgMGFOZU3iuBeThJ3Pcy0FncbA+Txr6TZoWChOgqKntlfbDcRbrW7eLig1JFwmm8 Mdt/SbhA4Ry+TyQ7XogsZLNYd4uxF4GVJS4AvYT0cCsDWeUUFonMyvdjJ0b5PlH1NmqKekV0 ey/67RPzGg78ZXdC9R1r+KhDNzd68yb3RCeQ/9eYYHhQ33ShZqhZ8pFOWqy3iuY3MY30kfsg 51ZUBiEZw35GSNBgFmg1sqg37ZSUJLwz89hT1UuwrktHVMxPbBvePr95AY38X+w2JQJvDpli TYu9U4AunxQBdoUMjg2bnIpPxThssTSt6uxMtARi8tItYMVx7hOmJldQQuCELcqkpvqW2uSa Yf3D9tXuEDuBA2b2lQuu2nNgxZe/5biZUoAyBYOKz6ABmZkVFfLh8N5T33UTiAEk9XMclmOd RK97tm+7Zptrv/jNpq3SuQINBFpM/n8BEAC0WEJPdG15JFgQCZtsacXgltd49ybCqb+Az64f JyqardhHVX1YBbzWFrToKq/MORA67KhG1iAr8qvd8z1DM9K3bfm0pSGtziXAhUV7/+XEes5U ZRtYhkezBmAYZjOUmBPISInM/vSBEHzwUTbpJncUfMmZEJEUXTTSh5xoD2YXuTznY8LccpUV BrGP36BH2aBCyzqcRxXov6Tt9e8Y3QT8sbIM/luBDubL8pPcBDw6dul4g77GKUhjTIdlmF9C wq/Ow9EhT5M+U/msTjyIrInPEDAC+uNGMuMtJFAWU1ZollOqu56GXQU/iPvwmYPwcqjkcNxU hgE0+KK7JF3CwI8loilrYiOmTpaKNti00pFj3EEb2M7Im12L56yJqHjAlSXFaXvGca4LOzm/ H1iO4IcHUgj9tj3hI1DFsdimfyzxuLW67uSwoAKHg3lUMR5di34xfg6dclYH7gMI2o31tkpw CAtDFKDCIKQ118Jph/5aQHOw8nAyZodJZ3ZJGP1TBhlitf6R5vYneQchD7JBueMGHwUZzP0Q ByUN8y78M4+pfasEk4TrEOtR41dFSWD/qm5HG1qNay9gqfn4lfCOQUeYK2qplwgYtwdIdITk BRLfKLdhyJHW2C9e8p0C3lmnmgw7SEA22h3bNx6lL5BABfqQDu1H8HXYcTFS8FUTpxku4wAR AQABiQIlBBgBCAAPBQJaTP5/AhsMBQkJZgGAAAoJECJvtLWEryhHf0AP/3Ms+rqgkONi88Sa FSus/EQ1jCv3jOBe+wrBX+vhNr5fEuOD9InxzlCy9VqfTI7wwqFVXSedyE/9h+Lb1FhJBT6a q7iYtzxkMGq0dBd+8V0oZc4BPClGobxTZ5G0CmcheHcqJrCMoj3x2Fs0lN6Tit98Fip4rhxh y1pTam76ejTCTFOWECFHPDy4ez9lHUZjHGZyBIVAAk0joCrb8zRWk2EFqm5/pu7q803cx8mU 6eNljkdXOVpFxneOJe6Mds1livs/1kmjii8Ffls2VkAlydCjpSVrTUjj9UOy2vlRET1UEqB8 qqzcRLqOSEFYwwzBIDYWCL2Mh+Cr5uIHR3qvgbU8+5DZZRLNPaG5prw0vIlBzcVMKAEpK3Hb oZdajUdCov1ZaZJHsbQg5lnY0lAn62kKxC8FeP/qX6O8baa+GTKCAXdfmIU5dP8yZ9ROxqxR vz7OwioE/vFOzffoUQ/Y/4o6K2dzdP/GzwZ6t9ZV0iTio83pZEE2BlkYP+/TRhEpPdDaBmMs 23Q74rw1nXpWEKuQLPFKSciQHqHxSdSVo+sLZwCrTD5sVaTvRfqQpgl+3PK7jdMO+hMBM24I jgA6Iz9gM2S3HQgsJ44Xt5sfy/X+8g4ycLurxO92YuxKaCg9JbPBUictMBqttOFcPbAbdzhf lzTn1OR1F1ZcV9br/vdY
Message-ID: <5064a08b-44d1-8725-9b9a-a198f3c4e245@forgerock.com>
Date: Thu, 11 Apr 2019 09:30:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com>
Content-Type: multipart/alternative; boundary="------------8FDEB88C6D7B716E6A9A4B30"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
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, 11 Apr 2019 08:30:45 -0000

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

Hi Daniel

I couldn't see on the thread if this has already been discussed, so
apologies if it has, but is there any value in checking the PoP JWT
freshness?=C2=A0 Eg validating an *iat* claim=C2=A0 - probably more likel=
y on the RS?

Eg I see the *jti* claim is useful for replay protection (assuming
storage of that on the AS/RS side) do you think it might be good to also
to know how fresh the token is?=C2=A0

I guess this falls under
https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6

Regards

Simon.


On 28/03/2019 10:17, Daniel Fett wrote:
>
> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>
> Abstract
>
>    This document defines a sender-constraint mechanism for OAuth 2.0
>    access tokens and refresh tokens utilizing an application-level
>    proof-of-possession mechanism based on public/private key pairs.
>
> Thanks for the feedback I received so far from John, Mike, Torsten,
> and others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the
> GitHub repository at https://github.com/webhamster/draft-dpop
>
> - Daniel =C2=A0=C2=A0
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--=20
ForgeRock  	*Simon Moffatt* CISSP, CEH
Technical Director - IAM Core | Product Management | ForgeRock
*t* (44) 7903 347 240 =C2=A0|=C2=A0 *e* simon.moffatt@forgerock.com

*twitter* @simonmoffatt =C2=A0|=C2=A0 *web* www.forgerock.com




NOTICE: This message, including any attachments, may contain
confidential information. If you are not the intended recipient, please
advise the sender immediately and destroy all copies of this message and
any attachments. ForgeRock Ltd may monitor email traffic data and also
the content of email transmitted over its network for security purposes.
No employee or agent is authorized to conclude any binding agreement on
behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd
is a limited company registered in England and Wales; its registered
address is 60 Queen Square, Bristol, BS1 4JZ; and its registration
number is 7227664.



Nashville 2018 

--------------8FDEB88C6D7B716E6A9A4B30
Content-Type: multipart/related;
 boundary="------------D7B057AD226DDE3022D85822"


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


  
    
  
  
    
Hi Daniel

    
I couldn't see on the thread if this has already been discussed,
      so apologies if it has, but is there any value in checking the PoP
      JWT freshness?  Eg validating an iat claim  - probably
      more likely on the RS?

    
Eg I see the jti claim is useful for replay protection
      (assuming storage of that on the AS/RS side) do you think it might
      be good to also to know how fresh the token is?  

    

    
I guess this falls under
      https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6

    
Regards

    
Simon.

    


    

    
On 28/03/2019 10:17, Daniel Fett wrote:

    

    

      
      
Hi all,

      
I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00

      
Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.


      

      
Thanks for the feedback I received so far from John, Mike,
        Torsten, and others during today's session or before!

      
If you find any errors I would welcome if you open an issue in
        the GitHub repository at https://github.com/webhamster/draft-dpop

      
- Daniel    

      

      

      

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


    

    
-- 

      
      
      
      

        
          

            ForgeRock
             Simon
                Moffatt CISSP, CEH

              Technical Director - IAM Core | Product Management |
              ForgeRock

              t
              (44) 7903 347 240  |  e simon.moffatt@forgerock.com

              twitter
              @simonmoffatt  |  web www.forgerock.com
            		
          

        
      

      

      

      

        
          

            
              NOTICE: This message, including any attachments, may
              contain confidential information. If you are not the
              intended recipient, please advise the sender immediately
              and destroy all copies of this message and any
              attachments. ForgeRock Ltd may monitor email traffic data
              and also the content of email transmitted over its network
              for security purposes. No employee or agent is authorized
              to conclude any binding agreement on behalf of ForgeRock
              Ltd by means of e-mail communication. ForgeRock Ltd is a
              limited company registered in England and Wales; its
              registered address is 60 Queen Square, Bristol, BS1 4JZ;
              and its registration number is 7227664. 
          

        
      

      

      

      Nashville
          2018
    

  


--------------D7B057AD226DDE3022D85822
Content-Type: image/png;
 name="ForgeRock_retina_email_bw_logo.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="ForgeRock_retina_email_bw_logo.png"

iVBORw0KGgoAAAANSUhEUgAAAXIAAACMCAYAAABhyyLUAAAACXBIWXMAAAsTAAALEwEAmpwY
AAAFFmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iIGlk
PSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9i
ZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMxNDAgNzkuMTYwNDUx
LCAyMDE3LzA1LzA2LTAxOjA4OjIxICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0
dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2Ny
aXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw
LzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgeG1s
bnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4bWxu
czp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9
Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1w
OkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ0MgKE1hY2ludG9zaCkiIHhtcDpDcmVh
dGVEYXRlPSIyMDE3LTEyLTIwVDIzOjQ5OjQwKzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAx
Ny0xMi0yMFQyMzo1MDoxMyswMTowMCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxNy0xMi0yMFQy
Mzo1MDoxMyswMTowMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rvc2hvcDpDb2xvck1v
ZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgeG1wTU06
SW5zdGFuY2VJRD0ieG1wLmlpZDpkZWU5ZDJhMS01OGMwLTQ1NGYtYTNhMS1jZDI0ODY1OTA5
ZDciIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6ZGVlOWQyYTEtNThjMC00NTRmLWEzYTEt
Y2QyNDg2NTkwOWQ3IiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6ZGVlOWQy
YTEtNThjMC00NTRmLWEzYTEtY2QyNDg2NTkwOWQ3Ij4gPHhtcE1NOkhpc3Rvcnk+IDxyZGY6
U2VxPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0iY3JlYXRlZCIgc3RFdnQ6aW5zdGFuY2VJRD0i
eG1wLmlpZDpkZWU5ZDJhMS01OGMwLTQ1NGYtYTNhMS1jZDI0ODY1OTA5ZDciIHN0RXZ0Ondo
ZW49IjIwMTctMTItMjBUMjM6NDk6NDArMDE6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFk
b2JlIFBob3Rvc2hvcCBDQyAoTWFjaW50b3NoKSIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlz
dG9yeT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBh
Y2tldCBlbmQ9InIiPz6hHcrKAAATNElEQVR4nO2d/3HjOBKFn682AIbAieC4ESwngtNGsHQE
J0dgOgLNRCBtBOONQNoIxIvAvAjMi0D3B6WyRhbRDRAgCOl9Vaj5QQDdIKXHFtgAHw6HA1Lh
4eEhtgskfXIACwB/APgLQB3RFzJjktLGpJylkBM3cnyId3H8vxbAlyjekCRISRt/ie0AIYHI
8Vm8z3ma0BdCgsKInNwSBXrhXqAX8iF2AL4G94YkTVLamJSzFHLymQI68T7nVwBNEG/IzZCS
NnJqhaRIAXvxPrEBRZzcGIzISSoUcBfvEx36B5ydB3/IjZOSNjIiJ3OmwHjxPuc7ZBHPFHUI
mRWMyMkcWcGfeJ9oIacbLtELee3RLkmUpLQxKWcp5PdABWAdoN9H9PPjQ2QA3o5/fkEv/OSO
SUkb/xHbAULOyNBH477ZwSziAPB8tI9APhASDAo5mRNLfIipT16E4/nR9okFgDKAH4QEgUJO
5kIO4N8B+t2gj8hNXJvKYVROkoFCTubC+dSGLzrI0XiJ69F3gX6+npDZQyEnc6BEGNH8Dvmh
penBaoibCyHeoZCTOfAcoM8WwDehTgVzimOOn+fOCZklTD8ksakQP93QRId+b5Z2vEskJVLS
RkbkJCYZwkTjO8jphkvopk0yhPGREH8cDodkCrk5agCHAKUU7OYB+iQ3Rmy9symMyEkscsRL
N3RJLWRUTmYLhZzEIma64cKh7xJMRyQzhQ87SQwKAPsA/b5A3vBqj+uvftPQgu/5vBtS0kZG
5CQGIVZNdtClGxYjbOTgzohkhjAiJ1OzAPAjQL++0g0lWjAqvwtS0kZG5GRqQkTjDfylG0p8
99AHIV5hRE6mpEaY7I+vMGeq5Oij8bG0YDR+N6SkjYzIyVRkCJNu+Iow6YbXePTUDyFeoZCT
qVghzAZUT8LxEm7phpfsIN8wCIkCp1bIFOTwM7VxSeh0w3P4+rc7IyVtZEROpiDEplgdwqcb
ntiAIk5mDCNyEpoSwDZAv5p0wz3M29Rq6NBH493IfkhipKSNjMhJaEJE4w106Ya5B1vfIYt4
6cEOIe7E3rWLux/eNEvE293w3YMdzbx+eaybK+qShIitd1baGNsBCvnNksGPmF4WzTTN2pOt
hcLW1sIvkhCx9Y5CTubACmGi8VywW3qyoxHmxUWbUtGGJEJsvaOQk9jkCCPiK4XtU4Q8tpQK
W28Xbd4UbUgixNY7CjmJzQ/4F/F3yAuKKk+21oox1gNtl4q2JAFi6x2FnMSkRJhofCnYzfA5
Qna9YeQKW++G9pnQniRAbL2zKUw/JL7RTH/Y0kJe/LOEv3TDVqizwrBYZ2BUTqYm9p2EEflN
USFMNF4KdnP4SzfMBFuFsq9c6IfMnNh6Z6WNsR2gkN8MGdJPN6wUtrbKvn4o+iIzJrbeUchJ
DGqEicZzwW7pyY7mhmFrq1T0SWZKbL2jkJOpyRFGxFcK29oI2Yfovln2uVf0SWZKbL2jkJOp
+QH/Iv6O6dINfyjGuHTsu1L0TWZIbL2jkJMpKREmGq8Vtm0j5KGSC3YyuM//a25IZIbE1jub
wvRDMpbnAH22kIW8hp/MkBfI6YbPcBfjDExHJKGJfSdhRJ40FcJE4wvBbgY/GTKaaDn3ZCcX
7JCZEVvvrLQxtgMU8mTJ4G9q47xsFbbXnmxVCltbT7bWCltkRsTWOwo5mYIaYaLxQrBbeLLz
phhj6XlspcImmQmx9Y5CTkKTI8ziH03U6itCLhW29p7Ht1XYJDMhtt5RyElo1vAv4u+Q56sX
nmxpBLUKMMYDmI6YDLH1jkJOQlIijMDVCttvnmzlgp0MYX5xHKDbz4XMgNh6Z1N+iX2ySHLs
ADxEsFvDT+bHN8jphkuEE9v82H8dqH9yhzykFOk+PMTQDzIDMviJZDsAX45/DpEj/Jt+NH6Q
yKSkjVwQRFJgBT8R8gtk8Xz2YEciQ5h928mdwoiczJ0cfiLkFn0UbKLEtJklvwJoJrRHLEhJ
GxmRk7nTwc8UxJOizhTR+DndxPbIjUIhJ3OnQz8lMoYdgFehToVpF+x8g/zQlRAVnFohqfAG
96wVaQojQ7/4x7V/WzrwYefsSUkbGZGTVHh0bLeBPA+9xLSbWn0HRZz4JHYiOxcEJccCYRbK
LBS2t5Z9vkO3u2GoxT9DC4JIAsTWO5vCiJzY8op+ztk3mnQ8zQPLczSR7zOmXWlpOwZCZGLf
SRiRJ0mBeMv018q+NAuIQo1jqGwV4yMzIbbeWWljbAco5MmiFVTfUyEZdFMhlWIM2wBjMJVC
4ROZCbH1jkJOpiBDvK1sa6EPTeS7COD72HGRGRFb7yjkZCpqxItc3wzty5HtfZd3cMfD5Iit
dzaFDzvJGGqEWdSyUtQZWiS0gfwwtgbTDcktEftOwog8eSqEiWJLhe0tPke+udAmA9MNiYLY
eseInEzJBmHSETVzypdR+XfIvxBWYLohuTVi30kYkd8EJcJEs0uF7TX089B5ID+HylbhP5kp
sfXOShtjO0AhvxlOguqzaMX5HfNMNywVPpGZElvvKOQkBjnCzD2vFLYXijplAN9MZa3wicyY
2HpnU7j7IfFJjTB7en/B+OyYN0y7u+Gv4Da1SZOSNvJhJ/HJN4RJsxsb3S4xfbphO6E9cucw
Iie+qRBmWuEr3LJjMvh5cbOWFn003k1kjwQiJW1kRE58s0GY91C63hyeMW26oeYFz4R4hRE5
CUGJMKl3j+hvFFpyTLsgZ4f+lwO5AVLSRkbkJAQ7yO/IdGEFu+hak/Hik7HvFiXECQo5CUWI
FY0ZdIuEgP5XwSKAD0NsEGaFKyEinFohIakRLx3xB6YVch8pkmRGpKSNjMhJSL4hzIM/zZTJ
XwHsDvECijiJCCNyEpolwsxVa9IR9wj/Vp4OfTTeBbZDJiYpbUzKWQp5qoRYVdmgz9c2USL8
xlW2mTQkEVLSRk6tkCl4DNBnAXmjrB3CZM+caEARJzOAETmZii387wbYQZ7WyBEul9x1tSlJ
gJS0kRE5mYoQUXkGOR2xRf/Q1TevoIiTmcCInEzJGrp9w23oIO80mMH/fitMN7xxUtJGRuRk
Sp7gP7sjg5yr3qHfkdAXTDcks4IROZmaGmEWCWnmq31kz3RguuFdkJI2MiInU1MjTDSruTn4
2AuFuxuS2cGInMRggX4JvW80Od1jsmda9NE4uQOS0saknKWQ3xIh0hFbyC91KOG+SIjphndE
UtqYlLMU8lsiR5jXrzWQpz4KuGWw7BzakERJShuTcpZCTgiZiJS0kQ87CSEkcSjkhBCSOBRy
QghJHAo5IYQkDoWcEEISh0JOCCGJQyEnhJDEoZATQkjiUMgJISRxKOSEEJI4FHJCCEkcCjkh
hCQOhZwQQhKHQk4IIYlDISeEkMT5JbYDN0KB6y8q2E3qRXwKXD8PDfiey1Bk6M/7JS3CvBvV
RIb5+HJXpCbkFYA/Avb/VVkvB/Bv9K8NK4S6DXpB//P4d1sqjBvz38c/d/B/Y8nRv3/zX5Bf
29Yd7f8F4BV2wr6CfJ5daQA8ebbZAfgPevFq4HbdTVQAfkN/7jPBjx3czrmWBT6ufy7UPfel
HahTwfx5135HAd01/BMf73mt0Y+lQT8WG1txORwOyRT0J/oQsEgU6N/36Nq/y3sqfY75HcAa
41+xlh/7GeOLjR9jzrnmmoS2+Yb+OmbK8Q5Ro7+Grtfehw8nlujH5fv610I7LZrP5zs+hD5H
f83fj+Nax9Y7K22M7UBCQr7yaGcN/Rcq1JhXSvuXLOEuJte+SJXC5tbz2M/LdkKb7+gjWFsK
APvIPoTypbrovxbaaFgrbRdnbUr8fKPMY+sdhdy9XCODvw/uedlDJ+Yhx6z14YTmC+JScsHu
NuA52EawWQvjPaeCvxvneVla+BDSl3f8/BmshfoaHzU2i4t2Gfrvw4+jD/vYemdTmLViJkP/
hS4C9F0c+84C9G3jw1pZdw1d9GzLBvf3IOwZunNZwe7Xmw0r2Il5KF+e4G/uvoLu8/yEz88t
OgCPx7//hn4uPx1i30lmHpGvA9s7oI8CTIQe8wHyT+1QPkhjP7ENOPZtBJsHfI5ELykQJhK3
vfYhfVlfsVULbYaolDYrxXgBILre2ZTUslZMdPCbHbCAXQTa4iOyzKF/kFeg//DWFrZOdJDH
XCr6eUafSXCN4nhcS4OfI6wh+x38ZAW0GBfRNwFs5pCvf4Y+Iq4Hjq9hF/3uzv5eWrRbH9t2
Qh1XX4qBtg2uZwu5UEEXiT/iI0Pltoh9J/EYkQ9FVq68GWydR1U1rn9pc+izDEzRWW1opxlz
jn7eT/Lh2hgAXWRqOg/AxxTO+bkoFb5rfKgt+rFhrM0S8rOVt4G2ldDu/PovBvpYCGM4LyvD
OHz4UuDn6/+O4enKWrDj6l9lGONVYuudlTbGdmCmQl4Z7JzKHrqoO4NOSOuB9rWhjc2YJR+q
K21Khd/a8wB8nIulhd9AmkIO9OM9iddQya60exPaHKA/hwuFD0N+aH2plL5kkJ+11IKtcwro
xrZS+vcTsfWOQj6evcHOSbwyyz4lIX0baFcb2tiMuRDs11farBU+ZxY+uJKqkANy2mp5Ub8Q
6tsIp02fS8d2tr5I1IK9c980Ir52dSS23tkUZq18JoOcpfII+yftUptcYXcMjUObhXDc5Tzc
G7bZD38Ix19hP8/bAHgR6vzLwZeNgy8+KKDL+NrgIxPlpqGQf6YUjm/gJoodgO8jbU9JAfMX
ZYf720vGhcyyfiEcd31AWMN80y2v/F8h9CndHEJQgCL+iVsS8hLyzyzNz+RCsPPnCB83wvF/
juhbYiEc7y7+nQv1TefBNC0hlVKwe8nzBDbG8JtwvL34d2mo21ypb8NGOF5c/Ls01G0QJ/9f
I+KvuCMRB25LyKdiN6JtCzltLQQZ5BTC3cW/C6F+4+bKXVHAPIfcwU4Md86e9PxHOJ5Z9BVr
wUymqNMF9mF2UMg/I0VQY2kD93/JAvLq1Bb2wmxb/57I0Au4FD2+Wvb7PydvPmgt6mYjbcWk
wrj9ZJLjlhYE3SMFhjNXCui/jGOmi+6RPzB8wy8t+pGemRB31og3/TM5FPLP/I2wc6i5x74y
jPe1AfDNoV2B+43Kc4y/jt8w/fnLLOp2gXyYigy9mKezp/gIOLViTzmibQ6zALQj+nahw3AK
YSO0Lfy6clc0cMv4uJYiaIM0bdh57GsOlHDb5TE5bknIdwAeHEp90U8j2JFya01UwvH/jujb
lgZ9tNIMHG+F9iZR+Yrh8/1N4ZcNLwZbQ2VnacMnr+jPTzdwfGdoW2DcL4FKON5c/HtnqFsi
3MN5LR3kz8sKdxB03JKQ+2InHK/g9gHO0L8ezsSrQ78uNDCL+KlOZzi+gNuvE1ObTrCZOt8A
/A7zGBuhj5Wj7RryuoBLGqFPKRMqJB36z7AmzdB5dWcqUMg/00H+AP+A/VP9tdCmVdj1RQHd
zehVOL6C3XkoYY6OdhZ9pUgJ+XxJD54XcFuiL4nutXRCKcWwcvDFBx0+ApEG8jRVAfcbYBrE
3iNgpnutVAY7p7KHTsQyhNs0a49eHK6VtQf/S4Xfe+huCgXkvTGqgbamBUa1wrYLJptrDJ/3
vaHdATpBeRP6OEA/91tiPptmAf31MtWvBVvvuB4MSOf9AMtfkLH1zkobYzswUyEHxm9jm0H/
fst3+N/GNlOMQSMqJkG7PA/XxpBBfx6utZd8qBVjcMHVZmFodyoLwXal6ON0/Yf6KqB/Mcra
ky/lQB/ZsZ/T5/Ed7tvYVgPtCoWPpu/ZJ2LrnU15OApkEjw8PNQY/om4g99UowX6SFpLi48H
hBnsHrC8wByRu465hHyD+x3mKRRNH+c00L1Y4pINhuc7TSKxQ58y6kqL60vXTTZN1wswXzOg
Pz9fYJ4r38PuM7Q7+3sBvWD59qXDz1OE2UDbBtcf+tYwn7sHwzGpLdB/1n8X6gAAUtLG6HeS
GUfkgG5KZGzZCz7UhraaMa8E+5ooRepjbJF82Aa0PXQOTTZrg68n9o52TxTgq96uFRMZPE4F
xdY7m8KHnWYeEfYBZIvwCxZeYB5DBvmXxxPCbld6i9vhStkUJczz3A38vQptiBfoMqUahPGl
gt+HpR10WSwrxE+d9AqF3EwHOU3PlQbmfGJfdBgvKkC49x0+Yrq0yylpIGdTrGCestgg3C5+
0vTQJRuE8WUFv/u67CCvVchgN206eyjkMh2AX+G2jH2IV/Qi3nrs00SD8aIC9F9klxWJpv42
HvubGzXkIGANs5Bt0H/+Wg/+AP3n+Xe4PSQO4csT/AczL5B9LBDuQfn0xJ7bmfkc+SUlxs3X
bmG/iKYW+rNBmrfdQxcd5dBnRAz5XVj4Peaca3yxtVlb+F4ofFgp+6rhPlf9Dr/R7xhfDug/
P/lAv6Z2WkqlH8VQB7H1zqaktmlWi+FFI80E9nfHUqBfql9Ct2/3Dv1Cj8bBZgt/Y36ELBq5
ot8WH9H5Av1y/VLR5hVu58G2vo++TTZby/6fYN7SoFD2VeMjD/t0zjOhzSv6hT2v8Bv5uviy
O/OlHajTws/CsB36z+dvQr0CN7D52/8BhY+9JyJF0ywAAAAASUVORK5CYII=
--------------D7B057AD226DDE3022D85822
Content-Type: image/png;
 name="nashville.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="nashville.png"

iVBORw0KGgoAAAANSUhEUgAAAj8AAADICAIAAACIxhfoAAAACXBIWXMAAAsTAAALEwEAmpwY
AAAMRmlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPD94cGFja2V0IGJlZ2luPSLvu78iIGlk
PSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9i
ZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42LWMxNDAgNzkuMTYwNDUx
LCAyMDE3LzA1LzA2LTAxOjA4OjIxICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0
dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2Ny
aXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw
LzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIgeG1s
bnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4bWxu
czp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9
Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIgeG1s
bnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJl
ZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENDIDIwMTggKE1hY2ludG9z
aCkiIHhtcDpDcmVhdGVEYXRlPSIyMDE5LTAxLTE1VDE0OjUyOjI3LTA4OjAwIiB4bXA6TW9k
aWZ5RGF0ZT0iMjAxOS0wMS0xNlQxMjozNToyNS0wODowMCIgeG1wOk1ldGFkYXRhRGF0ZT0i
MjAxOS0wMS0xNlQxMjozNToyNS0wODowMCIgZGM6Zm9ybWF0PSJpbWFnZS9wbmciIHBob3Rv
c2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJQ0NQcm9maWxlPSJzUkdCIElFQzYxOTY2
LTIuMSIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDphZTUwZmRmZS1kMjhiLTQ5MjItYWU0
MS01YjQ0ZDA3NTllOWUiIHhtcE1NOkRvY3VtZW50SUQ9ImFkb2JlOmRvY2lkOnBob3Rvc2hv
cDpiNDM5OGM0Ny1kNTg5LWI3NDEtOTUyMC1lOThkYzc0ZGViYWYiIHhtcE1NOk9yaWdpbmFs
RG9jdW1lbnRJRD0ieG1wLmRpZDowNWMxYmY3ZC1lY2VjLTRlNDMtYWU1Ni1jNWYzYTFmM2I0
NjYiPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpTZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJj
cmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAuaWlkOjA1YzFiZjdkLWVjZWMtNGU0My1h
ZTU2LWM1ZjNhMWYzYjQ2NiIgc3RFdnQ6d2hlbj0iMjAxOS0wMS0xNVQxNDo1MjoyNy0wODow
MCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENDIDIwMTggKE1hY2lu
dG9zaCkiLz4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNvbnZlcnRlZCIgc3RFdnQ6cGFyYW1l
dGVycz0iZnJvbSBpbWFnZS9wbmcgdG8gYXBwbGljYXRpb24vdm5kLmFkb2JlLnBob3Rvc2hv
cCIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9Inht
cC5paWQ6NTNlOTJmNmMtZWI3MS00MTgxLThjNGMtNDRlNmQ1MDhjYTNkIiBzdEV2dDp3aGVu
PSIyMDE5LTAxLTE2VDEyOjI1OjIzLTA4OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i
ZSBQaG90b3Nob3AgQ0MgMjAxOCAoTWFjaW50b3NoKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8
cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6
MmMwYjJhMzYtZWMzNC00NGQ0LTlkYjUtOGY5Mjk2ZWU3MzEyIiBzdEV2dDp3aGVuPSIyMDE5
LTAxLTE2VDEyOjM1OjI1LTA4OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90
b3Nob3AgQ0MgMjAxOCAoTWFjaW50b3NoKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxp
IHN0RXZ0OmFjdGlvbj0iY29udmVydGVkIiBzdEV2dDpwYXJhbWV0ZXJzPSJmcm9tIGFwcGxp
Y2F0aW9uL3ZuZC5hZG9iZS5waG90b3Nob3AgdG8gaW1hZ2UvcG5nIi8+IDxyZGY6bGkgc3RF
dnQ6YWN0aW9uPSJkZXJpdmVkIiBzdEV2dDpwYXJhbWV0ZXJzPSJjb252ZXJ0ZWQgZnJvbSBh
cHBsaWNhdGlvbi92bmQuYWRvYmUucGhvdG9zaG9wIHRvIGltYWdlL3BuZyIvPiA8cmRmOmxp
IHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6YWU1MGZk
ZmUtZDI4Yi00OTIyLWFlNDEtNWI0NGQwNzU5ZTllIiBzdEV2dDp3aGVuPSIyMDE5LTAxLTE2
VDEyOjM1OjI1LTA4OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag
Q0MgMjAxOCAoTWFjaW50b3NoKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8L3JkZjpTZXE+IDwv
eG1wTU06SGlzdG9yeT4gPHhtcE1NOkluZ3JlZGllbnRzPiA8cmRmOkJhZz4gPHJkZjpsaSBz
dFJlZjpsaW5rRm9ybT0iUmVmZXJlbmNlU3RyZWFtIiBzdFJlZjpmaWxlUGF0aD0iY2xvdWQt
YXNzZXQ6Ly9jYy1hcGktc3RvcmFnZS5hZG9iZS5pby9hc3NldHMvYWRvYmUtbGlicmFyaWVz
L2JlZDRhODU0LTE0ZGMtNDQ0NS05NDVkLTA4N2U4NTQ2ZWVmYztub2RlPTM3MDIxOTBlLTVi
NGMtNDYyMS05ZmU4LWJhNzc4YzNkY2QwZSIgc3RSZWY6RG9jdW1lbnRJRD0idXVpZDpiZjhi
ZmQ1Zi1lOTNkLTNjNDAtOGI3OC04NzllYzE0Y2UzNTAiLz4gPHJkZjpsaSBzdFJlZjpsaW5r
Rm9ybT0iUmVmZXJlbmNlU3RyZWFtIiBzdFJlZjpmaWxlUGF0aD0iY2xvdWQtYXNzZXQ6Ly9j
Yy1hcGktc3RvcmFnZS5hZG9iZS5pby9hc3NldHMvYWRvYmUtbGlicmFyaWVzL2JlZDRhODU0
LTE0ZGMtNDQ0NS05NDVkLTA4N2U4NTQ2ZWVmYztub2RlPTFjMWEzZjlhLTE3ZWUtNDA1OS05
M2VmLTc5YTc1NWMzY2Q3OCIgc3RSZWY6RG9jdW1lbnRJRD0idXVpZDo0YTgxMjg3YS1jZWQ3
LWRhNDUtYTcwZi03MTc5MjZkZGUxYzEiLz4gPC9yZGY6QmFnPiA8L3htcE1NOkluZ3JlZGll
bnRzPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDoyYzBi
MmEzNi1lYzM0LTQ0ZDQtOWRiNS04ZjkyOTZlZTczMTIiIHN0UmVmOmRvY3VtZW50SUQ9Inht
cC5kaWQ6MDVjMWJmN2QtZWNlYy00ZTQzLWFlNTYtYzVmM2ExZjNiNDY2IiBzdFJlZjpvcmln
aW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6MDVjMWJmN2QtZWNlYy00ZTQzLWFlNTYtYzVmM2Ex
ZjNiNDY2Ii8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8
P3hwYWNrZXQgZW5kPSJyIj8+WZGItwACQ/xJREFUeJzs/Wm0Jkl2EAjea+bu3/r2F3tEZuSe
WWtWVqmqVJJKu0DQEtCIFghxoNWHvRtmmu459ABnhuluaHqBw4FWw0w3AjGANDSoUWsrVZVU
UpVKqlW15FqZkREZe7z9vW93d7M7P2y7Zu7fy5TgHPSjPCMj/HO35dq1a3eza9fxbd/7x+Dy
k0LXCAAABICIQAAA5l8E88teAgEIEIAQEADI3Nja9hkCgH2E/s7+i6wxwNA2e0m+FGLUOSCg
hwcttKw48Bes2agPByiBr2raAQByTUfV3MiRop6jlj3kaZ8tQGGjDFLAJ3vV0hEEpIXRWIjd
bCGQG0+C/Bggi08CAO2BapbHU9tpaTWQDTaH2lK+ZYwWOAIEcoNpvzSAMBPpcQiBZLEdhR5f
DmFAgIhEgLgEmjC6t/IweZfQtblJVtabNNUoSW33/84vYjccPJ28TtYcWyieNfiXHsUaoFnD
/6Tf0jB5fWoBeHldRjec1sitNFeTszUgDl5L29TSq2kMyfUE4MmbDBSm2ZbBUqiftEsODmod
ZoAzIIXYq7QvdDwwwmUolrDf9lGbtxTx1YjBnnqxiTPLGkKfRBysbPraF4d5Aeeukq6NbAA2
g5yYMHB6xhzMjDpetURiNW6B1QpFPQPlQwyN+bWB/F2o9yYsNq3F/vIUGdhkjHW0ePfoY/w0
WWGMMUULsgG265A8DJisEFeKAhLCPLimCDxrQM8XAh5ahZaDGtEuGRCsXwtDOgntF6YFGvMV
/STecAI1cQAICNBwFSQ2kIZskazXGIoAm+cUYegAiJjwWEJEi9+lIiyVOm9B4OBpCAlPlrIJ
RGrAE0sNS59u/RFRWF28aODMb1nceV4h4ucCLNsHACTQCYXHTM6rUpZ83UwkbUKMmRTVDcwA
RwqyFRfPHzaoJmbQSAzu0LgnIYdUr16aF5ZVLpkavzAZtAgEwpI36jDGUNJDa1dFKzDk6RmI
yOI2wBOLsTApMaq4uhxfiapoyzBBniCWX4IzPd6x164ZkVg4yT4M5OHfkp8Pt1TtWrCFspUz
50cvf2a16OiNC6BV62IMxBTxKgu5YXyeEv2QBEDMNeLmwJB1YEoQ9LMIHWwdh2E3mKaXBOi1
9SaJ+1opBzWduOXi+Wwy8+jwmfKshPLckzfjbMh5rB9WoxYr5YWbgY44bTfr2EsAaD5MQOFY
nh0uOmj4oBtEHC3TYGzaKWY0QcQYCEa8Lx6gwxcyHmdWuF1hDYxwv0CQdkuQEMNqOYkVXPFw
GjcB8gTgZpVTrlNWE/9JrmVyy8D9F3Vr2AemKo6bLj437pmTbDEarYXpfnGEtrGk1oFELAlA
ujXD3yaVMfrVjoflMxLeJu2cDmdraxrb30ZCHcFxSvMzLIuY/0RqnuMe9jlG6nlYyoRW/IOd
WSe80LJqLl8ptO0AA79w7DrhWiw6MIjVFa43JyoJQ/+uQbecAltp0BuvFRavr+7LUygfjz7c
o5NnywoEvhQGz5cFZCvnrlSz8fhrXxi+73tIZEA6Eb7mh2ihi7DAvG7FqkRTH12ORSZalb+N
nEUOBxHtBt5ivD3A8EDs75gPx5ypVX0DSxDEgfQLFVJStZUiZ0NScZkIt8VtZSQKI0ubD/Nn
0XCKL40hNjRHVngwoorsZGCaUVuT7ibGo7DslADQaCpeBRFx/UhX4FTOe4xvsG2BgGvfVU2R
xjwLzQHE5AOAzGHECwX9nWmFTRiXcc9WovcES9bJiYSBvTFyjruBRu8YvedzzQVtk2e1QeN+
oVN0hXcEgJtYxssaV9CU+co69WrOduvbU+o2eWIEyVu7BEMRRyD6FZJ0s0T9jp44gWPUIwCv
O4BTPMJPjOcFAYE80zfU4XpmXUfUFXNMICQKll4iPxIiAbQl2OYPG+UyHwb/6WUJxqjESGZ6
wj5lapIlk6A8rM/GlBOCQCHWrzyRg65vPC8QE5eYZdye45lnCIggAIRpFHn5lJhTwkbgzSXv
XFfWo8UBxgAQ+8WYlQhVLJwI/J8GejgMCMYotfCby7z3jTIYEEAACOSjCYNLKB8ty0r6tGWR
OJXbCmjZmmmNkAjDQI1hQ0iOxJ01aNBHaIeMDk7XoG0O0YMeisUAsz/xHbrhOK6LbicyTCYh
ErJRukJ+VnxD2OjOkwHDFROanhwxBtmjBjGe06gXYL2wNx5Kh3y3GWiIHJc7uJL7iLKQGU8I
ZIhLIJo5d+2imyzetV82zTXvpyJMDQcAoxuLLT7ExlyzdhmVm5/CAmT/4pPY2sibXS3D+a02
8dZa9ozv9D+i9Q9GXnRfLAy/AXNYhoz83Erx6ORTjQl45ll4ypZAmAcIqxWb3Zs5EqzxeBS8
uOXbYXFjAIA1uoz8IuS2jCSQKLS95/BzorN4Zj+XTZyHNqunYzlYW730yN61F2R/VVx6glTd
ADsaj60vUtRgbHQmddldpEDw6WQl0sdgKxqb19lGyOU6RYUbEJBrLWwge6cJeH9S1I63KaMV
i24EXtcI04ZBsWq7Bws9hq0e3mBoiQI45l9mZrB3EP9jb0Xo1CMtWCVLl1/4HVAa62HULOHB
Be/mbW1zSQctkDSHxDHE1mQCkLeZ4g4oZuBpu8jQxBtPIBQxebVMHaJRlDHMrRVgMV1GjUCs
YwJXMzEiPOAF3Kg8zHxFJSswUDvG6GAkZ9rBYG4xaMMSSzBHvpGAeecCC05I3hyGWXKFmNea
teY4iSN9ZjLYOB6wxjEgGqPDL2PuTqdkMAyB/CaZHYLgq0gqckxGj8K8oEOOE3QBHmOBBbHC
whoiLFqtnNCHULihtcMTQGf1HSyu3QYeHL48GTmEMxPMu1Mw7i/xJEWkxOibsdE2YKndsnch
ddaKQw9GNFAAgGw+OR6ubecrG/2V9ZOvfWG1OxBbF0nVMadDEQN0Gvdpe4pLHuCyAjEb8yQf
ImLcSsC4TgIM+ZKEjiTCKg1WCyGE5lK+GdpO6J04vw7rz0sOpzBFDMpMm1+8wJgR+MpOYLFR
hHtPdj7qoIHegJJoW6vBOht1GDptV3bJCffW7zYnLKgRq+dVughzDe4YjRMxotGmwAhLnZNI
MuowCzG5siaWYqwhTng9OxZEIobXBgkma6RlCKz1JiRNrsq5ZSvDbR0L/xma8vyINerhDsTp
6rR4rjipmL/YLo3zXrgHAWvNkbcvNg5Lesutm4BujBDFRJ7rwNKwi7wKvXBJ1gAk0gn8vHCa
jLehDSq44sihdLCTEUO8Kl/KrDe/OUmhmSQgsGUI0bQEueRfplwl/EYGf1qLIyVdQNHWQOB2
YRGmbRCvFvvmOSwMpVx8suL4gd/zg7I3hKzQs9HR9ZdKDSvPfjsM18EIMAQAEHEsG+dwHCl8
KsM/EVgIJu6hlUN45hBtlDRYf6P3RiNeb4tIOMQLuuLWO4yBmpLGWmwEHpCQwhFATes110pK
Ao3ybBEksAkAJNAIIkGjgwzdxhg1BBu0oLId2MTaiODCNlnFFxl7FH43sJaA39St2NCRNRBt
bvHCbYs6bHIQ40F8wacMtgE/F68R82vFj6vGGcGymW5iuHlhA0UIoBlgYgkm37Rlr3kQi1Wz
7TdnJeF3/3YX00OXtxlx5ZaXbx2QgGcnEJJI/pjVtrfQaCv8MhIJWNyjf7G0VYv0oEtTox8A
sJyJtRNoksJPXjPqkcCEoIZXzMLmN7CcYKIuYuWGEw16BSHZDIkXNhK3if15AS/vmuwoxYm/
MkFK5B2lteivrl55/OjGy5MXf2P47LdS0SWl0JJ3zMrblq4BDCGUY8scIZwKQw4RK89Vh8Dd
kaBFzU77ZXUMTXheh1yGpqFm6CGJn7T25kfVIr+WVUI22eDBCYNsHQlHn+csvJQDEjXbIbNI
si4PjAqnvQQsuHkI9MkHEvXLwMMoyJipYw28RKzeSbymlEIwsb8N120LkjksjbEFamCWH4tA
xQSkBhj8IgCr/7L5aiUMwrgRw8U4OEvol9dqcIPTyieuLVxS7PSrZZ/MgRvNE4BhSzZKHgKn
gdYA34SycQnuMB5yjK43HUyLVOC9xK8xvePk7O+aY0DO+iFeM7y+X1XBeYCtgDBgHdLNsvEs
zyHVt+ysZQeUibcwXhUrNVOgWaeGcWv/yypgSUV+tU5gWEdJAF2iYLpjKGHPheIyjt84WwL9
8jHB/36ptU57Mla52pWodb6yAQSi28+7vcXB/frksNg8D1mBQG57K6L1JltMPAbmCYa/MDnJ
hIwRu/1MLxUQQy9RcFyzT89oheuebTCDd5A4jh9D6LblzSVahoZ+abs3YWMl/GmwVRs84fda
2WB57/4FhpNGYbvS+OuQVeew+Sq+fsPSjXGGFpceLQnvQjDBBBZsj8F4DuLZcX/7CcK2Pwyi
FDB/j4n/J0Ev++OCCdhkISCGSBQ+symorb3zamF7HVEg7yVqDQIMgR0AQMOe4x2dshHdsi6a
M9j29pRJTwD4LVyMADzR+nvhtiUMP03Ry26Eg0Y4LHk8CHafzg7bGkrwliAhRXLr4Jv4XaJM
xHEp4cYvG0/nIm67iWXPVSgm1GRaQ3U2Hods8DhAcFSJLnrGB3HFS2UZ8QRa9UwJ/BM20Wl7
cYOYNp5OXII5aPlp/hFhSAxUvpzbsJVIWwLEJx5/XFX1+uVHh4+8o64qEEKPD/evvQD9jZV3
fwtlBWrNUdCc8kb8NloIqMVzlTZgRS+EM8AEiZxL6wdritjiMuNhtTAUB3PmyT/GUDrxgGGz
naQhTnBLBtWuaC8v70jI+5xS5Y74r2i9xv5yVj7BQ/zA7npwVbM5s7ybRmvtA2l71YaMNiwL
H03OS7GDrm+lU4gReHpJR3BwGkeDJkJPa7Aput4UEj8/yQniQOItvTeHyKRnK7Rm1ZBV2L1L
IIHzt3PFGE+4wVvD3G/h0g69TUcZR0pzHUGEo3AT/oketV3Ei1Kc9iEFZlkL7shEe61lPjJq
a5s/pLhBM3ZPUW12qol1+e1PeysJNt/6V6GYw5uGlitqhKK5JGfLIdo9Pfzgc88uqrqq6tXH
3iU3LtTVAlHUx3v7r7+Yn7kyePs3agIbnN0ivVpi34gJZAKgxukfNhT0/5/uMHFC0mOiKUHc
CBMfToOVh3tvq7essYD8lHvwRpmN3AZzmF5sPBYuOZOwzSWAEPIDpRYHp7FCTIrah6kvATnu
2uFH/i8PDFnSOz9bspxVOVQbmdQs+u+Wx51yhfG3dblsNhMWifHNbxkGjwMnUfgyZfz/NMGV
3CdlGMxLmXazoaS/3z5v+51zuSFRE5ttu92hFoQ9sSYeUixpguXyslmd4vmmNxWa9o4rHimw
/n9MBAOlt8T+j3ZneYF4mG+qwjUHDsvp07TlTtU6o+UtEHZyZQJxddCfLxbTmy/2hZArZ7Su
87XtzYef3L/xStZf6Tz6Lq2V519oW+cbStHaEMAj0ROx5mUVhnoM4vi3HYLzSTq+hwBE3hUJ
HKq4VWR/NxEfuRDZDeMlqdcRiImyoLZFvaIjCGp0gaws2tO+MVVgpA342pSMJYAa8T2W+ChC
cApfNLC4O2/9xPTb1rtPohWdWmh0FfF3LlT/nYirt0Tl6Ow3bIm3IU9oy+VWMgSMb5YBFrWA
gfzNSmV+0pRgMULhmzTeJJLGqxT91No8AnBm7sFt4PcUFbvZe/QWEYiaz1vlZctDtzhD3bcy
/Xxhtr1qophnX7QaHmPrHOHhEkbZZAkT491WaBuyXw7IzJEEnqhH9Ltd4RVnQIbOycTZ2cDY
SEKbESGEMIQg3Cm0gn5VhPrOYcP34RMZhcG7x8cc+Xni8aOvzbyLiXLr5GzLlY2nM6UniCil
LG++2L/6LljZ1HVdbJ7fqKuD68/L4UZ2/mFQVXNBetjRARlwhSl6gIufdBQAybSh00FNaHJS
hcvFxg1jRhxtrYwgoqi4nUg08/u4sVSFJ7d/ZtZAaneyKoG2l6wiXi/is74Zt6wRiFOSHwk2
kBr/E0tYtAATWzEJf4skLQRMJasaY1Q1OdEpgz39QuZ08cqKC5lDcHvhvhNmi0dYNmNJTk0l
dGgG0hp7yfsIE7J0hfgfDjdvNuNJF7Bk/fJX2Ci5rOKSfpmKzwkH0wKJTyBdYzGrCk9i5FrE
c5rmnC7GZNQsC1kmAGzYDpYVhibBshFowUgrKvwxGNMUQYgnFKeI7qDFWckfVO02b26KNNM1
+fphHWmOQgQ/AwKAKMgmvirsukTy8t5DxrNJgct8By79C5O3DsAW3seQ6f72R6rCERpWCTFC
FXgF26ndHBsNvDIjmAlIAsDNja21lSEKAUCbq0NA0bn6LljZJKVAqemd1yaz2ep7vh3yLpJy
zQXidqlobP51dOhLt8LcSJrCJCWgtk2WVH1IavjBJChrwUPzao0qTys1gGTqBnts/IEimamG
yg8xM+PtxysxhjtCTBSlxDeHXIOsdOpydLPUfOr6bUcyRq9FLOSa2tXpikOzfa7ZBDOlIRPY
WmzPmNUEhrcfHcCMC7xFUAEiNYK8ScGJr7XWqQ9b1VN7R/EtYyCttfxIqbVQi4CAJdth7bBF
zxzXdJPFWXWDyOLGW2eKl2SyYxkYwLqg9JnvhomEiC6Xd98CjW/YkxDbx/INU0s9k/uJ55KC
0wdFriNeBlu6CGe62hokAH/ILeonLUzOYluawDkIEdeCbcA7jDAsT4r8O85DS9bzGUCJpuPU
2Y3eewQ+/uhjCFjWVVlVvU5n0OvILF996n26u6KVoro8eu2rqruy8q5vRhv6gJwbO5HLuDHn
ta2s3+EyovBWL2TM4nkB81zE/DSePC4gwhJaxl3Qo92lNm8WMO155YVBYmMuosEl4gqCpr9M
ADfLe/AN6GxoztJvBLAmIiVRBiJMNmRe68WrYdrXb+1ivBUdgG55tWXSDNVO5zJmRhpsAyDC
m0UntQznTaCNAVkaxAJL57et5RYez0VzkLJt7LAd1qTEUjYdvD+no3a5RtJy5G6JRHxTZFAM
xW+HsqgNBkpH56iAnfhtRl68FYnG2ajLoMNeuSaopXd226ZSpE/IggTMqUhpEUzKN1tq5t1t
tmK+EiASjcfxEIoXSyuWOOahjQxdoAhqiABNtYoYdE4RSRwKnjt/eTGfEdDacNDvdQFobdBD
keePPKs7A02gR/t7r32luPD44On3AREAIRGgQOYkRJ/QlHfFJEokQNoGbb2MS6ID2vxvycCC
beplGcM4NQGz/7Z9WCs5L53ITk/7qY3VKj6YxFomhpNBcecJuYWRmN4JGnksRoK9hlh36E6P
brPWGCfAeO5ameTSKw4Nfet8KSAj5t3EhsLLAISdg2jNNIMYWVPN7IVNAKDRiH/P19TyyWwZ
dIuEO50ZvIWLqxScI1Dj+dKLojKcaBvlkBFmqGwo3e+qJNKLGuC96dUKfFPQMaG0tNUlY2l0
xQwPl2epPTJvqZhkP4gViIff0t2bCzNqLQX+8DHGPSJ73VbF3cX4xca47NP4spWWw5zekN9o
i2W/bS3hbYa6wnLnQ9MeDwT41FNvy0EBYlXXZV2XZdXvdnpFLrv91affX2ddrepq7+7BG6/2
n3hP/+rbSNUImkAIJr0c/tiqbvWcRwhgkocViqV+cKe2sBC7PpCNP8ijuEaag+i0xRPLNsDI
NdeY2oY9haFuYsMl+ksyrmbse/wrIIbRQIB1CYG1sNXTGQe6P8YlIuIZgZZ5cBVZbhgTU/PW
2W8ri3eN2S+8oF8tGOYlAQDcTkrQ0dC2cErXlvVGKkbKadsIkEPudIGGoHhzSjtVC+Bi6d/J
1WT9XM6Z561OqMYvSIlwyUiWC8Kl4+Llk4pvKonjuqeINPJLvFGV4cabMykcjSMOywDzMVzR
A8ddbEbCuDIl/7ZISkwgb0Yixg/I9+vcd7wLz+uafZ1+UeOOw/ZmLcQORreEGVQEAMIvbABw
MTVmDNlguDI52h3NFnWtpMQizwlAI3Z0NX31i9nlp8Rws9i+uAFwfOMFIUTnypMUgnJC3AC5
pZt4Zvzl2ETkeOTFmtIukmqWZzMp5HCNAWMeCnDHp1zEIpy6wdUwsKLenSDgYiMETuKSltkB
QDNwQZ7ppqPwraNzPTcsWVeJSaVWSRdjz9PrcvkWA+xhxnip+Mt7+GyO1FjA+qJGYKRn7ONV
ynePWkPVPS3FKUQaB/3iIfCSzWkNHMFLQTNKPwFpDfACrqXPiDZcg4lYSjWNdpg9j2sf2r+j
KzlDw6ebg8SFeJOHRg/CMBuaXMwQo+qxjGgBMpnEWJS1zEK7xtDYkIiv1s75DfEGwhxDwF0s
aVr5QFQVwSbLC+aI/5/AbKUZvFIMSivAPlQQ02JO+oKjXjCfxvRxGkBAbr8ucG/XXUAVpg/t
uBNp1+bnSPDd4CdRlHRYeoERIQH7Ih8CAGQAaCwwpKw7XIHpoRBCSnkync/m8xmUJ+NJr9td
G9TVtd9cffw5NdzsbF3YEOLga18EIXtXnqC6DsBhzHliPPIiGEEWjTOpskRoYxy+5cuyQYcg
HGS0F7fv10DcxxINPfCnsHAM3Z2yOCFySKKrbYNb2P6nnzIK7TCuzlgbZ2rxUiX+hg3T00DE
D00FkTYQ3XIyRU64fgob2LOCEq0gQH+2kA2JZydtx1pyLXnbzrywsVzaCkfmEYszxSVUhwzB
7fy2uWqT+/S0CYOZNcrZR+uFEa2nPTcRwHsIXfHUaM3OHInz0SbtoBO09kk8oXHeoBZ4wvDd
Dac622eDFwdJhlGOx2Zf7SPjDpmo0hKpF+BJcZwacxbiRuxfo0gCXNuH6G3tRHgDAIal09ag
BcGKKkKfN5mBBeah3zAgYqpeQpzYWN2ePkOfYd7DVzC8QSrCy0Cr5DIU+xnTbgbIkRSx8tDI
YABuPRpGlPUuPp7ND+vDo/Fsoeq6UxRK60Gv0ymKyWKx1u9Nbr3Sf/K9CkWxeW6tnB+98vms
v5JvngNV+5FzNHIseKlpZ6CBc0+sGBNjMwUGs7o4sw7NWM0vwno0y3bVxSo0Z83pxcy9BH4v
WviVWGDoiCCIK/TPw0Ju2lPEqjdGgtD21j1sk8kxPEkryLCZsNNQ0XOxJYEVETWzFHnouuDl
ksV6SoMRn+HSO9mK8OTe5EO874Bmp1CEH/Za7mCMoG5lRimkkLaPSaG4YkBO3E66dJtgLYUl
bbAVyJTy26gKGkZAK/m1gpGMFZOnTTjj7vxrzh8EKwkxhpvSnf/mUjAVfuxR3Ei06F1fSdAK
uf+brCm6WtdXAohIOUkiuxNp6p8D2fwTlutCWBE2rp6ipK92dMzMJvYQbCpTE09rlVavABCA
+ZpYkGleFGoAr8PY404O+WBFlwAEJNKAMgwdtRdujnv4PAjeGA2DQgCATCxOzmysdfPs8Hg0
WVSAYjKbH51MlB7lWUYEQ6WqN54vHn22BuyevbJSlcfPf3r9uW/PhutAisvkeCLcgmfG1rLJ
a9nyYaowWnQklNES1BcViEUghhiF0LIPu8CkGWQF21ha6CtW5xJsmFvBfrFoYhbI0+Bcrd21
vPEVOara4OTcga9bapSM6yNfN0nLFLfcLKZP3XBqjsLkgfVTwsYVMxjO4LxrhGdjabbuG2RP
zKaIaC99SjMR0pqEfQpCeGun8Dje4ZsWY56I1vgCr6FEZhjXW1LjYhkozcaJv2SFE9Xzrchh
/qyVzJchwtOJ+cWLNdJbg1OUAysJBNWyzKLxEocOY4w5Ttvc9mQNteI24XnsjGuQC/b8mZUm
4Wwnh9RwWR+YbiyZUMz7jdxqYWslfIc35G+0rM0xQ1+E9Ytov/Bo+3INCod4sgYVITE7k9h/
XiCBu41YKdPg3BNirxFAvuM9Hziz2r+8UZTlYjIvq1rVtRr0+p0iWxn0hUClCMtZPRt3N88B
CoFCLabVfNY9dwXNDlhwC3rG7IcNgyL/oe/8xr/wA99z/d7uzuFJxEn9Sgo83HIEDI+JPURA
/yede1/M3KRfSgyVrFUrkt58Cd933AGy9h1wyJq3BNfSIrJ64ZOTrDTrBJt/MCIaDwqr7cGN
eue5UJMGWgeFbgyI9ivATYnFy4s2cJPyrlqA3M9e+FwvG9hAKIlQkWiiFlhVhxWj2LmOg1sT
w2giJETNJRWi1ylqQk739KWfi3jiGckuRWDLfMSg2RtOCGzg9mEAw77lCV3R6WH+p8cixs26
1vh4PBYbM5Gg2I3U9ZUQdTTWhOQTnDRR2IqpMGpOGRgXWDYd6SIN9NyY9nSwzTY9GXoaEAHL
gE728EmL0ky7nwIBASWCRDR/hPvDpguFLW9e+TWIcYMoAAWCDAXsN6OFfWubkgLtH0QhbLOZ
61cKEAgSXVMJ2A7VRnQZ0aIBiJg/0JXRTlBpIkWgNGhyf7RxaGIiusKpZwTeFL+Rjz/x5CYd
jBf16sa5HKFaTIXMlFbjyXz/6Hg0mUqBWZ4X1SRTZb55oZpNEKEaH2crG7Iz8I6uwLgNst0p
tr/953/o93zw3Z9/5cYTl89dPb/91ddvQUwNfLFGSbi9ShDWcETBvLCn75Cy2qmXwhGPhdO3
zZgOimhiWpmKa9f+BaFBT/ehVRHYkLHjTVpoDPyOt8zqxuvPr1r2siny4uKirSpHQdK2xa9Z
ciamxjEFXjL9uQRRDM0Re3V4TwzwlLUMsZZAc5CJXHN35AiHPIEYpZQzlphxJfwnoABjQPhr
ZG+RuapiwZFOQ4OzpUiDCB5g+OFSPZqMZlNuyiIywMbPBLBWIMMTcvwoeuG7cZPXYN5Ra24k
7leEJ485Tj5BWAJ6IozoxzHn6BHvMO4qmcYYDdHsJ1gIzUAMZYMYlk10MkFeqLiJDJcAJx78
3wIlIlrRBUIkGEQEcOLKsBfH1oK6EsPp3gn3txFjGdp2pLsxfSF7Hs8NALOurHxygkr5n0Th
CYUy5qEmK9K0JvuWeWDJ0Q25Xa6aQDk+YVtgN9oUIyCATAq4u/Guh/B4erBz4ex2LujWzgEi
iJXe5vrKdD4XAAfHo6rXKe++PkTZ2bo8O97r9gaTm69svOMbQ0CIvyh4V7/xHY8/+/hDd3YP
P/b55/+HP/uHP/38a36Gu0W+1u9por3jUa+TS4GT2SKTYmN1uHs8MnGR/W5RZPJ4Msszudrv
ZULsjyaDXlHVejZfIAABbK0ND47HprutteHBaNLJs0VZAcBD57Z2DkfzsrQUxeiLW/HJ2m43
8NHZwLZIkmTRrRkMp84sLQUfNkb0HbcdPePvDEI9gmPITKeafZEhGkb8IB2p8OlzEGOc2JXT
5hfCFtQAAGvKekf5yT1XrjnyuAABSCCnCkS77G5e/GpCiMNtWWfJaBoBoaehHjieW88w8AfL
POFJ4eBpdNqLr0dgc/Vga/n4hpqe1EaB0wBggzJORk8CHKZk2hK/YtqxTziRZsJP93OXQhUX
wZBvKa7a3sayV+CpmA+EmOOwpQsLgE1ARfHb0wBx7SecpFneMgun2zb1P2I2C58LXpLsEkN/
PMR3xP2iyNoxTRAA2vXlJybkO/TSIvxNoMH5+vzzJd/b9K+4S9CPwPoGKSocoSV4D50fkq12
75mkuG4GqposaJxhpqtSwbnt9Ye34Itf292d5NP5fDZfVFU97BVa60VF+b3XtVZAUPSHi72d
8mgvX98GrdjmHTrkoBD4X/zg9wLAj3/kU9/3ofcQwedeef1bn336V778crfI/6c/90eU1i/f
vLd7OPp93/yeTMq/8y8/8vils9/7gXcdjqf/9CO/VmTZn/393/HG/f2/9S9+9oe+84Pvf+bR
56/ffuPB/u9+/zuni/KzL177ta+++tf++O8bdDsf/fzzP/lLv/GX/+j3P/3whY9+7vlOkb16
68Hvev87bz7Y//gXX3jxxh02X+CRym8iJorg9IFAOuC4YCLe7NwTa61txXLKw/gtIoXoH2db
xBe23LmfCCBbi7tuOL/zZG1lL7Je3cD9gCI+zmUFAB+yoSbWkgeSToG8UZhBiygoQCGabUEM
fUPixBhusRCbYi2dLXLIXQp82/MW2Z4ytVYe1yKQYs03FG5uMzPx85bgDAvUTTqfzIjfAUAU
LpEMxDzyh1KiYq0cbrnWuBTaRo+eLfMVGnqLIYmaJWDj9uwYPZIb8Qth1bbpYhFU0KC8JhD+
OcaEl+hAHsQwcEYBlir8HhiC1TOtimslh7GkdayGcAXTXBrMLhoZe4iYhkREvnoymR535Gwo
XlBb9pnOTPLDv2a8k/wLI6JSNtNoJDucwRPdV9dwcaRlrUiQeuhM/1vefekLrx7c3tXdTkdr
lYHqFlkhJSFOHtzsbJzrrW8pgnL/brF5jkijZ39Aftfuh7/rQ2fWVr7wynUi+vC7n/rHP//J
h85u/cU/+D3f91/97XlZXz2//bVb93cOT374uz/0P/zEzy3K6s//ge+qlNo5PNlcHf6p7/t2
APilL7zY6xbvffLhRy+eqZX+1JdfObuxJoWYzBb/0bd/4Dvf+/avXLv5zz/263/rz/zh73ju
7UfjyV/4uz9eK/pv/+QP/Icf/oZf/uKLf++nfhGb6k2ghHBFW/dt7AC5joONE1Sn8o64U0N2
zHaOLNd2mcfZaYNjOs2lwd3t0CIlOFr5aXkeLogpl1z6s03FZifw+DsOZcByvG4FCkAyum/A
cNS5b4bF3jbH7klftFUNfSfMw42O0mdRF+RRQISQfnn1lKu19xS3bVWaI/WNLJEUbwEAdk9O
daK4x/QbItRSvaWLJnktqUhsEt4i5MB2tVsT4Da79UNLGvMVvUVixbenPrIM3ws6pvsTW0cu
hqHlsmqS3QCLZowjONxHUMUSkeMWI9RZGIFAW0GN7Ky1O+/vEeLcgCbSz5lZ6TwQEyJRyJ/D
ukPvMgEXGWFMoNm144FPaKBVVvGfpnz2+Fo1l6trUA+zeZaVk+niq68uxiWA1ut9WdbU7w10
XZdVvajqaaVntS71g0rjysNP7d+5rmcnojsArQPenSfkZDr77//Fz37mhWv/7//bj0xmi+ev
3/nrP/IHAOAPfvgb/vFHPiWF+Nwr11+5dX8yXzx+6VxZ1fOy0kSPXDg77HV+6pOff/LKhZV+
98PvfvrJK+ePx7P1Yf/MxmqRy621lWGv+8KNO+PZ/KFz209eOd8t8geHx5srw8tnt44n02Gv
ezyePnxh+8Lm+v2DIxGjwNBI8uXMBr9wE4YA9ktbhMBWdpuWzcjMc8SIOUUruo1h+Wr+qK9f
nK3My1yNEFvbPrmhcAHXPmQHeisjiKAP6inbxrNXVBsbVVtYWtwlohDltNAL7Jxr+vTA8SB/
TyyzNTQyRQG2uP5aBMMSlhP6j6tTvIQAT2mjBXVpyVMlHp8yXF68VR74e2BoPkUk+2KC1Wpp
HBszsrw1Xsz85pZ0Sy9LmqNoGQVQzR02HqbjdU+TYzktemrjeIzXS3xAJ9sAiJwRy9Dit+/i
YulCNO/NmZRkz4mRfMCTj9sjJjqMOURO2vC3/t5JlPit1aajBO6R0AIrCl2mCouFSCCRF1Ih
a3Eqsfjl1AJfmL0B12s6p6EMgHzf01f351KPd09KoTTu1f0SuxLx6Oi4kKKT5ytZidUR1OOM
ZopgWsFoMtPlvLe+RRrK8XHvzGUjvRDDnCLAt7/nmd/zgXcXefbg8OQ3XnztuaeuPvPwRQD4
Rz//q7uHJ6uD3j/5+U/uHp3cuL/3R77zg49dOvs//sTPLsr6Y1944Ze/9JJA8ZHPfuU/+NCz
O0cnP/qvP1rVdSYlEc3K6jeef+1ffOzT5zfX/tUnPvu+px/5jve+/V/+ymd/9Kc++vD5M//h
t7xvUVav3Lr/D3764xe31vMse+32fU80/g8wEjGX/woGYxZ2KOi21Fvx7/EYbBW3UQt+U7VB
3KyW3bIKH0oP22QWVMTwd7N6ymKioSKi2ZBHTN6wks1N6dAS33PnL8DbtIhOA3VliTWZ9hV6
jHfIbT4qIVemu3l5PO6dNZ9vw0ZFjm5fHdmrCOCYW7QgIcUohFYwnXZstMOrIUZ/RDLMmN6S
LpM2/X26nfnWrnQS446AQSsadNWEB09tqhWrTdxibAEndSOYMXrlUQeYNt7aYxNITh5+vOiC
8QBjwDBqLWnQxOxJACHAxPv5P/6t/5MhSBeqJ0W4N1F/JjRD+KbYW4lkAij8qIFxfyLQztHn
LScNSAAaiMjeBxnmIh20C/wLYg8S0eVsIT94cqc3XYL8xDyyUoeQgmHbMN8iL44vFw3LxlM6
fsnG7afAcZGYDPBD3/sH11eHuHpmNYcRdc9WOw8e7NWqmskedVdguLW188W34Uv9LgIgQf65
nZUvvTHq5rK7srHyyNv2rr+y+dy3yf4KkCabk8p2+ejFMz/2l/8kAPzgX//Rxy6c+Rt/6g8B
wK98+eW//mM/ZQqksjR11zgBzMffpp2lC6C1VPvePbluMJLxxpffVqGt5xTyZRYM76NZoHnY
2be2pPclXTpXOLJOEaOGWlvD9h/JXWildV+++YgzgvYTYK6ERrk9vt1ZHN/bfMY1Foo0VTBq
aSN63o60qOsmGS5FTjB/+Rp/8z7aW/6t1PttXsjmOngNgHuU7KS07nD4Iaf86LcEw5tVpyXF
HNghZQ3E856MK2mTv03oIVlQp1CLF34JVJxoGD8Nxh1CkmEx0C8y96BPTJPCEXviXOhEam8F
o8pUcqaOPzNtqkT2mTsKlthttl3PJsgZVb5NN4RYgPlXyy7y/5AVZF4K+r4gpjVsa8H1TsjQ
g/Ld3/o9spo/vNGjyUF1sncwLY+H58uzj9P2Q7SypbtDAqkPHkxU/7gazKB3rAaERTfL6vmk
u3GGUCyO9/vnH9Jm98s7UhCOx9NOkb/z0cvf8PQjByeT9z51FQD+87//z+ZlBVx+oleOOCU4
e0HETjZmU0eNxCMOT8wCjjip6c+aJMgeeSMk3i2zMDrWxWwiR4YJAK3AiARaTP8kg2oZy5Ix
I8QHBQD5MS/fnRtGO3iY/G6HNDKz+FvgL9xwzHPB7jEBK4aGUPSqcVbPxr0z2FYE2d9L2mgb
Ea/NTTPuA2rrhZMoOM2dobmlj9arMdVvsZ6rjvESWFKgafwJAImQI0p2fE4iZi5W21C1nxpq
QCggzHQT/tMHggDSEA170qyVdtdYFk2kibjB1q6bPSbVmyMyg/WWkETIRDChuCEl2JNMQGZs
KURfPTIR2ixygYCC2BEBe/EEvuZvF25ufxKLR0cuS6wkQQAMphjE0iaUde0jgJclNl2ImzME
oijRFLHJsyKO0Y5nCK3Ty5kGxgsIXZ5Yj7fIDRbPsfEmOTONskt48vK01Hfuj/OVavUidIcS
gUhDXREACNkZDLfWB/2cUAgF+XwkSGSoqzyTi/17aw+/7e4LXyiP97LVLdDKw2wI8R/9zCce
HBz3O8UnvvTSaDbbPRwdj6d2iG645MFKSK/tanKZ5K2biNC4CSMRCC6ulxhHStuIG3flyaIt
7SBuwNyaTvxjStLkt8GNrmTL0HHZCw9iMvQl41nWb1TPWxfc6ImA9opwwk/REbdfeXYKPCXy
0TSyi9m3CBoFksbmaIgyBAXM3gtaXRt2kmfkSvobQPYJPbbsXOOpwFgya61XAtOpFA0QIzPK
d4Xt90vbae0XQQJIgdqprJJRryZUAAigiUQsaQQ6noiM31HceAMAf5ktnCT/ySmLV7hME+C1
fUz9UM3qbwErcXW3ajijtTIGgPnYbZghNxQEuo0acIzfCxsyZiKbJoxaBlfaj8604C0h1xZq
V5QgZM3A4PcLc0ROnpG3zCCEgyVyy2NSczB4AbfWtbemMCoUfmHYUUYHKqCLtIqax9B4g9F5
0uCZJSDx5fpvgrEF7HvJbh5MFwrV9lOy25NagVae4BBBA9UgF9C9tTNelNXaihh08mv359P9
+4PBYKAeDC9cXTlzYXz9pc1nv9l/IQVd80rTT//aFw0cP/PpL6EfsG2fJW1hH3xP0Rkv3BbG
1xAh/gcC+FPCnFs3ruC4NYvGHvsIcbZLqsWGL5Ll1+2rq8HxW34ma50zwkTERA847kL32AY7
q+0JI+mW9+TgspMUwZjsGbQPLF4FTE6kPnAEJBDU+kUlxCFWI8q0i/h1tVvmhj9ieGH6EbFD
Vo1JOY1Mlg7xLb1FH2vq6Doz5099Bk8CjZQwqdPFJLBJcrwy8kWZpgRCgSg8g3EbJALJaOle
2DjZjgJAo3MpLR8bhgEF8RMeYrRi3wRvzP6z5X9L0olpKYE4XL8yuFbAGQ1hUwJdxCCRZWPG
/yZMTqXoyKVpkVgPBBjiqwKFu5uEqbP0SI71M3vITzzFLWh3+gpYed+a6cTdOpkaLyPFKnMJ
w/ttOQwX62I2Bz763LTBgI+1MJdUMbBR9i7+/JtTB3hnTgphWLvx9xQRgLLppXfhjeclEGrF
DvXYQGBEkDK/N5a1kuur3QJmK+trX70te72u1rqsqsntV1cfffedl75Y7t8vti6AVsChQPjh
7/mmi1vrVa3yTP78Z778wvXbAPDY5XN/4JvfWyuvDiIi1qo+mcx2jkZfu3n3+v3dMP0EgPBd
73vHc09enS4qDzu/jGvkJ3/p13cOT77l3U+9/5nHF1UFAL2i+MSXXvz8y68jWML84Nuf+OZ3
PjUry25RfPwLX/3yq2/8R9/xwYvbm1Vdt8hFd3WK/NVb93/m01988sqF3/ONz1a1kkJMZvMf
+9lPdIv8R37vtwkhdPhyTMulFV2/9+CxS+cNgjt58dXX3/ilzz/Pu/yBb//ghe2NqqqzLDsa
T/7ZL36KWPI6v3re/7bHP/j2Jxdl1S3yr9269wu/8Zu8I/axGvj9H37/pTObZa06efa5F1/7
7Euv/t4PvffqhbNlVWeZPDwZ/+THPhWypQCsDfo/8J0fkkIorbtF/nO/9oWbO7t/4vd+p2wb
HVrMFK+8cfuXPv+V5qulTK9NzqHLLoqkORX7IgUoiZlmImupkGj8NGzUL5TwlZe2whGA3lr7
rV6MiYPlnmh4G4FLkQ2UGynhNhBqIAAQTkKbEDJkUAvnDaBEqID3VoU174PANCBoECw3mhAk
iBQJAgRBOYEmkx818Bn/AVwDq3CyzV8Oi0zZMCLQ3BMAgGRsCZYoY9CY7gTfycNEMCQszTeE
frAu3RHGDJb5UqwoIiBhoSW2kQCAJgOuZ9REZFS3cDIxJhSfbDYVTuQzwafDRC47TBm/JUkh
2RISizQPXXJLjkMEIcIQwOXxZTYtJUhEQA0k0EoAYPLFrAbjYgwTgfGoweZhdCkQyMs1iz87
1cLBzIZv8Gx1ADuVUZL8KJUpAWRZli0AQVWIXb/fp93yQoJMwNsvdj/9wt71Ww++7T1XR7VE
mR8enchMbqytqvERTg7WLjx88sYrZ7bOR4fuEQHgD33bN6z0e6a/6/d2X7h+GxEfvXDmd3/g
3bD8+ujnvvr3f+oXZ4sSHfV/67PPvP+Zx06pAgC/9MUXdo9OPvj2J77jubf7h09cOf+Fl183
8CDA+5565Dvea9/uHB59+bWb3//N79tYGZzeMgA8cuHMz/76Fx+7ePa73vdO//Af/dwnekX+
vd/4njetDgD/9Od/9bmnHjm3uW5+fvjZZ37lSy8qpQ26Lm1t/vDv+rAv/OnnX0HmdnY3BIDP
PfnIt7sBXjm3/Quf+aIlMObcNNfv/sbnttdWzL3W9NmXXnvyoYsfeufTvsBHP/vlw5OR7+SJ
hy58zwee9W9/9tc+38ky/qT1Ore59suf/ypTKBvCi1qexY/NK+rX466e9RcH4+62y6Jp/0rS
NL9FrRyTvxu1mpKS8xSrzmH4Ga3WpCnHf7j9AU7qoN3KB5MaWMQr01TJAH34q2E3RnwaFiac
U0UDKifYgHUHftmyEaCtAkqTFigAJHqW4nMaeH4V8FA79dmPKWb9hqV7XzwWAgBNCjsfN2C/
6+EQi8S5pRsUpQr/Ur2Ev/UT1yxshuRyI9ncgABs/hjG2HQu+8oJBSx7Ooz9gXbPCLwAilye
XpzzgbPRUAhhd8LG+Qlt9AcBGuckNRrwoswJ4KTTwPDdrLB/kt8Iwapy4gMcxbriQBA8Zfbb
GW4JMYvUlg9nwJEEJhD6TB8MmehBRq67eWj9IkUAgVJillE5D7uLPhIUQSBooLsn6sHh5Hha
XjtQd0bUH66sra1mWT5flGWtxrdfW9vY0vPpYve2kBlTfQAB9o/HfiizcmEiCsqyhlOv7/6G
d/5Pf/6HMynBnx6bzE6vAgBmd3M0nfOHV85uXb1w1m8WjucL/2o6LxFgMpunDbVdprAx6cw1
ns293vxWrhdv3Pqxn/1l/1NK8e7Hr/rYkQ8/+wwv/E9+9hOeAhHJ/UHECODj8cTmaGyGmgAc
jQLyp4sFAn3m+a/xXq6c2/KuJkR4+PwZPrpb93e95nHKNVtUgN5nZRW0RC6ZB0k4SZzWEgSQ
rOZaqaxe+Oxt/iKQ0cY4/Fv94ZD4wPRY9rZcbnfE3bMbf5/AJtx+vpFbHDHmB/vWKwgBmYBM
gETIbFY6AGs9QC6gEFAI6AgoBGbujwnB8NyYJbZGiSjBpGH1GVRJE2pCl6eOjKIrEDoS+hn0
MuhIyCV0JHQk5gIkorRYCkq3N2UEkAkPMcn0DOQ5og1qCEEiIJB80lGMEcjRnsY3BfRE4elN
ShAeUQhdid0MuxIKQRmSAEI7TDLKhEuDS8Jn/AuZCCPh5KAi8yehiGBaUZBP0R8nzYL5xVL2
KZO1lv3x+QNt7DsiAfpIDU+lEO4tnjzL5ZnNWUCBH5QXwxEd+vxVUXSSI2nAUM12ZqbASwp7
49Iq8qTA5syACIvX0EYuMXNnCXJh792JApQIUqA5VIBhD8hRNgACZiil6PRVOc+FJAIB/Dtr
hIgzJW9MO5sXHjr/9KZY31L7D4oCy0oJIYo8n9c1Tkaz26+cufrk3rUXivUzIi/SvVpGf820
BET0m6++cTSarK/0n3vyEf/88Uvnfvi7v+mf/uKn7E5SVCWZRHtpnRS017e955l/8vO7YUY5
PACzsuKmOE99wZ8vyiqp7rWsyJJnDSRw9nvdz7z4Wq1UJm12p29651Nf+tp1U+bD73mbL/nZ
F1/bPT72knvZV2j8KMI/gQGznbxQEl+/+4CYE//qhbNffe0NT/sPXzjrC9+4+wAA8jyLRtw4
zgEApZfoDhSMDRqG3OhfD7Irj9p+8Sc1OhFAliOZrdaiSMbVBIg3e/qFS+7DwyVNhD00ViAl
D6doa34aAtE8D05zYGE+aNhIcJ4K56CzQW4AiKAIJFHucKMJak3KdRfCdYVpzypYRq6Y/msC
IsssCgEI9pOPaPZX0K59RcaNaQ0LTSEKJ9gjiJk98EMAKJHAfEDSfR/KXJqQCMjnUPGn3Y0L
KEacJi7TMZlkxkEIAVG4TOoA6Dijr+M2Q9z+VsPSYpsy3nAwPt7AqnyouqlBYSE0bCwC6/6K
Dg7bokHU+cosMoUZJcgfskgZ9610jD7y6KFCY89ESwA1+pyrHJtmiBYjdgvLKePo0edQQG4m
Au6TgbetoHB61S/ksGCsCacdJWEEnmsT7ZicZ9ROh2klo707UM4IhJ6NAVGjIDBJjyXKDBAR
tOx05pPx8f5elmeYF7JcrA7780V5eDxCAZtrq2Lv3sb2xW5/OLn92trj76K6Wso4GkpNVav/
5p/869miBMCr57f/mz/1g1urQ/PqP/jQcz/x8U/XSiWY+cRvvvi//cwve/uW3Jcrx9NZK7v5
1mff9uM//ytx3iwAgCLPEOD/+b/+y0wK40Z5x6NX/ss/+v2+wF/7//zk7Z19DycC5FmUVnCl
1x3P5j/yN37UP/n9H37/7/uWbzD3L9649T/+i582pgghLhYlAnziiy981ze8yxT4wNuf+F//
z48tquptVy9f2NrwjfzMr32O551JxtQyRENkjGE3Ux0Zot45PL67d3jpzKZ5+NC5M148IMJV
Jr1evXUXEET8Rcq//y9/9uXrtxM4qrpuhTBS1pZBzo6KAwBKQQR1VSNnKoACdHZ8B1cz6HaB
FK++TFa9KdLccmoesHxLbslE8nFpjQh8fw7Yc3RTo8G63Xy4hLSyipTR4p1TzxlhiGAEIYDJ
UGczrpLd9nVcwOi2vnOz1DMBuQAjlRSQBCLATFCOmCEAoCKy1oDt3MoqcDtAgg2yUvbonhTG
0rJweIlsuJJySoh2WBU2KR8AIgrInCGCjk1rE7yHIPz3tBg3JiebzSNj1Er3OQtEwrBTGSw8
YPzOzYrffARyh5scJUTUoA02CNwLNHBwSQPWu+cEmuY+wKCceYnF6lpPapCLXGh5unIUAo54
EMOIiH0SzC02z+kJiAQXWL6jILYJmLbo89ckGcKiX2wI6Pp0f0IIEsZr08wFueq8BQJQZGfE
NJg4kx15B5XFDDGTu69n80Wd9/Wdr2G9oNkIugMQ0jSGeVcKrGaz0Whczaa5ILmyAQD9TjGf
z1ZWBlKg0rqs6unta2uPvPPB9VeGlx4VnZ5RH5tMw67heFmv9LrzRQlIbzzY/V9+6qN/9Y//
AfNmddB76qGLL1y/nYi8yWx+NJ7AW77Obqy+67GHv3LtZsKXBCIgjGfBJ7lzdMwr3t07PBpF
HWHM2IQUAHQ4mngEH42n/u2irI/j6oDwM5/+vJdew173fU8/9umvvvKtz4aNurt7By96CdG4
UgkMjLob0qpZFwBev3OfSa9tL2O2N9bOrK/5wtfuPAAAEX++ce/o5GgyaW890gRTxr1sLP7G
EKcGqTWSO3rhGKaJJhDYlDNvuYtTLj+lgjEav+RMHHkUyG7lkE+ubhVTY9lIBE1QaXAfmUUv
t2wCBcKgbzrHCxoLxjSFVu03kRSmqCYACOd+jBwiBGUMLwJAEEbUCXAgW1eetMudCOy+k4ti
QAJQwa5w0omAgl4OAqAQIND6djTBQsBckQDoSL+lBNbuszjEWoNw/jEBoJ0dqR3fJQDlq7Ib
y8GcborskVfPg8PQSiwQ6Owd8PZtuPgRMSsOkcgvGjbFjrEiy0ph6hnMeYvKIYrbWLHQWkaB
QaayXUPwgsr95qzfQEQ8qwUiWMFPXsL5CgQgzLaZ38QiP0PJjqlTeomDbA0jZONy79CZ1cC7
RQYzb8WvIwAQgDZRSEAMCuEQyCJvoyR5CLwn9AoQYJavncVBNZ4u+g8/JecjVVcARL1VcbxD
qqb+qiwnenI8WFntbG2trQ4PpqWU4sqZYV3O98ez4+m0yPMsy+bjo+70qL++Obr1tc2n3kt1
2Zw5R7SpaitlyNHx+ZevTeeLfrdjfj9y4cyLN+4kgrDIpNtwTjAel2PXt73nbc9fu5k8pFjD
QICB69dcK73uwbENanBbF0kThpz8ooVuEVxtmQyfI3BkCTcf7L38xp2nH75kyrzz0Yd+/auv
fODtT/ha/+aTn0s64ZQJDRJxyogXQ43MqqwwAbzyxp1vedZ6KS+e2VoZ9EbTGQA8dG7bW1pK
62u37zXsZOh3O5xel/XS+oSWTA2DDZHqRVXNKxIYPzfUSgpPbeRNruZ4GrAxSWNXqOH+mpWU
QACoAZS2GxIZYobQkSgRSk01USaw1kHXcauXFKAiAACzo+vsJMsE0e0TAKEGUqCNMqvcKQJN
nnURoG0qE5ABmY8KarKQCnTS1MotUuZjgEACUCB5ivUkLQA1giTQZn+RKBMgETVRjphLKAQA
gCboSOhKrEIEdziTIoIdSKhBQeTHs9LLHcJleaEDlsAKJ/TzhTYUMCQRQmcROpbiWsAwTXyx
CMbd0YXtcb5M9hSwiy10LN6JmZS1m4vFBLKMs45XQNyFP/dpgDRSXBNwqkQzDTE2wggRNBGh
+5wIgXALn2xvlusbCyGSo46eCYz9GkIikUKBZCqaGzEYpsXqXuCWj2Cdgs+IaOWtJUJwEhr9
6REzrWQI0gbkGyFhWpAIQHYBmnn04jdTilRVImm5f1usrHfOnC/GB2q809tYKbBajI/zXnYz
LzDXeYbDbnE0V6TUxtmLh8ejmjDPs0VZnYwmoHV2+7XVJ5/bvXFNXT4W3UGrpoyYoiPBV6XU
3b3Dxy+fNz83VobIpLe5FrWCcDgumd+o5J3dgzPrq0Wevf/tjxc/nZVVe7TIUoYY71U2Wafb
Y+BRTO3N8Lr/5lc/+/Qf+wPm/smHLv7uD75nddA3P6fzxSd/84WkKXSmSTPtLP+FTnS1ZGNi
Ba7fue+f5Jm8fHb75Ru3AODh88FteHtnbzSZYoPdT2YtvtllIgFiibUcOfbfDGpRL0DSQMxn
TGE0Krc2hxoZSG5Lo+U+anw5uvhDz8ololFAzIf7JFLuGAQCZAIECqWhJloACUAizATkCB1p
XXylgpogF9AR1soBAALSJBRRxZalJyov5mwMHjq3nVex0O4QkONNCJAjSAEAJjQDAECRqDQR
YSHQODB9TjwjAS25Wibm2CgANCIbpUCTbKImZ3UxpOUIKKBUABZ4QssVTdiY5VUSg2sUwcpO
M3aNdgOJADQhAmUCwXFhtP5AgmBphQXvMOZFSTgu6sUS+pAZZxKZN8qnpGWiy7VFbCIIHHIS
h54F2+GWGEgCUSIRBEvQfEEYwhSHxDgUnd2IOAzXKhwA3tYPFYQ3qRgxJyROiRiDcFLSiQ9W
l3EYL7rQYdj+dLwO3dQQq849QegkuB+ONPaiQAxGmAHSR8MHYSqMnocAbslAvLqzRzaznXsz
VVcXc8jLSX3zZcJsVmk5vjkjWKgsG/YlEJXzezsH0+lUDNZI6ZVe/u7Hznziy3fKstKqFlKW
Ss3GJ8XOrc5gZfTG19bf9j6qa4xPqXEfdoJtZG+PWXjh5spAIoBWLDYLNvvFpbVh1u0J0oBC
ExW5PBnPEr8fAHz6q6+858lHHr98fm3Qf/fjVz/30mvYIJdTLgMQMmumUZ74U2TyzlyiwewR
4PMvvbZ/PNpaWwGAqxfO/se/9zv824997it1zSwMv5YMEcRP3Q+HVUZVzXK+wO3dvZPJ1MvL
y2e3Xn7jNlAUsvG1N+6kAwUAgKsXzy3KyptoJsTowcHRwmX/ag522dXAC+a6zGmiM6TF0cnB
/vrWlnchAiCILN6Di9TC1vsmHjz7kwiFQE2ggHTYZLJKhjkalZlkS8I4phCBpEATN5ELqAmF
Mk1Znus9h4bRZ4hdaQMI0XEYTVgT1NrxdC+N/AonIICaCBEyQG03RgitYCNALARkKIwM87HB
AKC0lQrKhlxbhu12fMlrx+bj8QYlbucFwcWXI0uMBBCCSryoMxxZ2UogGP/UFLaRTCPkxRG4
EaLAsNtk2CIJF22BiBLQeLisL9LKCZPMAr2wN3slFJlGwciTgN4QJGdrcUmD7DcyK4RsmiUM
qS6co1iTE/bEN/O8mCTr3DS4RwuJ5iaYc+b542Lg0IiMAIIbM4TgBxJH/xcL0nB6CZN/zPlm
Kd+AjRbx5L11Tsx4Q4ldtnXJUOd7cXEZaPDgDqWF0D9LMNp6U9AN3AQTGi0HRVAChGDz5PrS
ZMUeMa2FALL57h0sq+1ecbgQQ6j2551etzdGyLt50ekgyv26XizeqJXqDoZFUUzm836WLcr6
mUuD2zsrSpMGrZTuZFmvyKY7t9YefdfR0aGaTWTRDaMEBnpDo0cUUiBojUCkta5DVHpHwOTB
PUBZs0j3b3rPOz707NsTK+43Xnj1b/74TyU9vnrrfq20seS+/bm3ff6l13T0ybZ2imCALfWP
sQJtIqW1MLv/uU9/8Y9977eaeymDsfSR3/iiww+GyYrkIwSKczCE0m19JVddq+t3HrzbhXde
vXDWrLiHWLj863fuQ9vwf+T7vltrSkI5/uaP/eTLN24DpHT/pgjxwEPQzlATdmU9vXtdglrZ
Ogtaa4Au1QUtqJ4sWmIsoh5NO0lGc4GW9RgekQnsSehJqAkWChVBTaQJ0fgJBeQmwR2AdJkw
0ORbAMu7EUACdKXlpLW23BwJNEEmMIOQJQ+D9LLB5Z3YOia7+QQANnLB7CwItwleEWoiRVAT
CCSJKF2gnQ+3IwApTO8gNNbkEhd5ZuB5HIJEJJtkw8qAHFG4yA5vfpErr4yIcPs0drAAmXCx
htYcIe/fy9gEGBAMSIZ4EEC6z9UbyDxNeTZnpInxsImg1huWZwyjlBjIxpKgdIRFQLWGOGjQ
vWiYOAkhWXgsjyYzZGHEquPm0m402gLGNwvBYApMD5zBa4J+g6RB2wu52desuoMtsAFhEEMI
tiW+MRSJcesXcnaw6c8JITJU5jGA4LcVgwhE1zlGe40Wagx1AZjLx595J7L7kSbqHQgUmB1s
5wO03VlXAzr8UJzRijskOUKyu8PHL5wXa8c3Xq37o87qle6uUvqwd65bj/qTezmWKu9urmfH
eW910EUh9ybV/rg8mecHJ2p7c2XvpOr2irrWGQJpvT+e1aODwcaZanSQnbsCquGpa2zuAQGM
j+rjQ1C1JphPxroOtepaVWWZ54WIF3zTAdnJs5gCAQC01r/6my/+ke/+JgB479OPAcCYnQYz
tOAbCrKicTkJEQtevt205Fr29uNf+Mof/u5vTiIYP//Sa7tHJ4yknZ7mWmoKSu5JC4ht7zUI
wldv3fXS6/K5bUDYWlvZXlv1RV+7fY9rWPxKRBewyA4ROR5sl461vRmmAHt6kol6oXFjCKsT
tXf3Nmi9fuYcAGI5EeUECGA1pG4Q3pcU+ysSNuScGyjQuq0MuKWOlq4PH/fc09gNymn2xpXB
Vh3TQ923CbU7cgTOJELPtgD8pgFfAoZPSSQAJCKNoMj6TEwNDZABVIRAJBDNISFJCC4Vr2Pq
AM5TpxGkkTQEylnsiqx1QUSarG1hoEKATJr0ByBFRFEUEsUiMO7og6E1+ljncOQQnRAyuqLR
9wWBkCKLtfUgPKwUtJSCLo7OI5BYUxJRUxCxfK6F29ShUMttCcViiTNE7SZJU0o/dlsG0G2/
+YiNcAjBuwc9dWlH/EHqWgowzsl026MGIEaQEDSP6EKPu8AkIr+DU0f80WBvUfkIFYsWHr7o
DMxwtByDGmEEJPqHXlsKyoQ1WF1NFhWiyZ2fc4a49rGFfkhOXFr5DWjFmWuKnIC3zaOd0mxw
5pxeHFN39REoZz3Rrdekmj1M481iX/QzJXqTcbm5JmVV379/96krm9mwczKFRVl+6fk3JmWV
AapZOZnNDseVEFCBnN2+vv3U2uzB7f72eeKI9dSQzgiV80WltHBRsryAFFgA5ajFaTo3AECv
U7gewrU+7H/h5Wuj6Wyl3+sW+TseuzKahZjABJQmdzVItxpoFJHecvEZXfrWvZ7O5p/80ovf
wdJ2AMDPfOrzLfuCjRZb4eR9s18YV7RU8/rdsPV1YWsDEc5urnkTcO/o5P7+4ZvIGnZlMgg0
T7Ww5InntM1hCqqNf5sQTMzq0c490Gr17EVAqcg4JMg4nhDsZznBMFA7XMehox4R0UbvGRpS
BAsFhQQEEx9I5KSXW0kIADVxq4gyt9TJ24kImtCKKxYlT2w/wBt8EGMAvGrJ2SUCEmSuNb6t
IhEqJxqJsNIkpInviHY1vExFb1ggKu2/8m7QY2ITrHGGLqc2MpnELRKK+LxFrBF1molwwDDX
ngPywihQIgggdHuBvi9t2TyANxkdO+OX1z/sYBHBRbIItwNtrGSyNEbm6KvS5Efh/cMaSVM4
CRAPGcjhRzh5Y+Uf2oGTM8uIkRbXovycCtemF2emkLctAmUEV6J9Qn5OPfNE9jdYPu4vB3wI
zEO/Nlhxbc03RzoucZMjA1vLWY0WY24Uno2z4RhxDmC8Ap5oNQEBarfXKF3gD6clYngjBEkA
gC4ixm71mfvgUEXQBNn5e18ggIO5kpKu0u71fVFWdQfK66KfF51DhbnsDOBw93i6N64vL+qD
mR4MhmsrnXn/mQsnr273FrtTQOqvFLrXkS/sypfvV4vdO7CyPXrja2uPvyMiPicGOHtDgBx0
ris0OqgQ3LlX18rPgb+e/9rrH/3Yx4ab24usV89nx/fvntvePKDcYThcg34XBHzupWvf8d53
AMCHn33bjXs7MUgY9KAW0YrI6KRFbMQPkwKJ5y3yfgD8zKc+/23PvcObMq/dvvfyG7cxbqfJ
5dtFl3vBpUgTGF/mtZt3q7rOswwAhv3eSr/HDa/X79xPpJG/Pv7ZL93e2ZPOEDZ7L7d39pba
rEt+thYnkdl/ATKBqEACnOzvzBfzy2e2OkU2q5VPDE8AKkKUnXcRMGKXJgF1BCoNNVlWkrkP
BgLY7BUEQEQKsCLMgARSpe0ACUCiidMDAKi1FSqIIIjAbtgIs7gQ7eFZf8rYgQHu0LATWm7p
M3Xbs1f3jxMPGqDWpiPMBNRugSiT0o0IEbg6SxYVZDbDybEGt3tksm+gT3wATnQBpNvjzu1k
9iZsJ968oHhOffILspzGBjeSY8xolYmWwCK7wYUIbivL/HBBHzbRDDnAZDhXZIq5HSAiECBc
zCA5SeNDTvzSsHOKqM3JOffaSy9h9SQEBE0Ezteq2VT5UBpPd+ZeuFPAwTceOJNTc/h0N5Rz
J8EjVcArBA7J/CQ8mfH66Q6C3kl0MIKNiJ8I9P96j7GnQPQC1AlAgxlnPyG6HJLOHQqIJigX
akJEMlYy+o9kWoezIwiHOBMhYZRT7Y7IeKNWB43RjdrYXovp/cFgFXubB6r72HC2UYi74sow
mzygs/3yOJfFIBfZ0Vcvb1ePP3xRa7EtRq9WvWl/a7L9SH67+2D3Zdkt9hf5JOvmKKbdqj84
gtnJ8NJjB7v3BxceTibEYz+aybquaw1ZBoh1uegUuX87OhmhqnQJxETaS69c+4mf/sj5p985
01jNJndeeh5V9fgTj3cuP6aVanLMX/3NF4z0eu9Tj8apj+x6YMdBWiVUrBAtuVrlH9NlEVnU
BQLc3d2/vbPnd5u+9LXr0OiiJXqwRcQ2pUIsypK3CLOyfOPezuNXLpoHD58/e+Xcti927fbd
ZSP9+Ge/dHd3P7SWDnYpYG/lcq4gJPMVJYFCoBCiHp8c1LO1gkBriJK+RlFwSWOcG2gCKUAC
Ze7QUi5QIlTaLiezhmqChbJcXrBTsUBofYMIBKRN/kUb+4fSKarGWSQQXLCZEXhWEVeMebmI
AeO+C9AGAwms64wIFQARSYEFWp4o3d6AaVMACratY80dpyZlABJREShCJDLbQvassQus8Mj0
WPMh4GTHCv5kVCA2RLTJ6ckgyuSLMp5GU9rTv1llBqk+YMGwVO2UDwxoRx4nRQCEVn/3H7vi
WUjClHuNwI8C0GgYfkINWzeFEYGIhKMAP0UCQSA7yQZm88/ubDnlIEAoEWq3G6rRtq+d/hqJ
W9dRrKMQX07oeuQhFEnEADl55tt0pBpoKRaI/vAWQvqKFQqDCsTonH6orQ8DhbD7ZwR2I5Yc
3olAmeVgj0SQhzZjcUb+LCM5YtMaKIqAtZuy5pvRXrHzZQgg6z31rTMtt9TJ8f3xg/zyRbi+
q6o9NbgsDmeCxqN9pUvRESjyuzv7D1/YVnVOYiiyHI8e7Imtevv99OD1uq4O7u31u53OxvbJ
bEdPjnqH9/trWydvvNomD6ILAVCKXCAiqLpSut5wuTYA4GQ0Iq1JKb5B2+/3SsKj8VRmGSDm
eTGrqvu33ri6tgnDjeZ0fPXaG3vHo+21la21lfcNgvRCa4OiN16bkq8hGBrwxxKj0YIlsyaz
R4SK7fBl3nMX5N2SLhtAQiJ3l8IaXr56666XXt/wticund3ypV69eXfZqLfWVu7t7SdNUoyo
U+D0Sw6YumoeagAUGYAgUgCUScy0EECTw/3JaJRfffi1WXdVqoy8EpmCx2BuWZuFgAyxkJgx
lpA7jBv9DgFQmuhtC5uBthDotEXQhCa0wYRRCLe2EcKGhlmzCOA1Yw3k03v7HXsIaAAX3ubE
nStC7p10X6MnAM2GYBa2diqWsNWZvuW23DMCgCBoyW6eB/z70D3DdngYoYkUQBaAYHQNsyfP
HNfok2WYiTAyQ5E93MZqI7HgOnTeYA+5AO9ac3s5htehFdXex07OeeiwF86VEIBALQD9mXs7
BwTaGK1kXhEA6HA21wLv9lzQhHcLQEAKX0cDUGy7C9gRCGNA2JSMEE5nB8PIgefuXQouxkwQ
gRtWyP4GVti36ZtC42fDcNadZfJlSXJ9uI1DprZhKbYHBBvp6nbZSDiyc1qabUEAKZe2EQDN
skIMXTjVwVquWoNyMonISyNj3dpmyX9U2sdJuhXhh5AN1fHdxboA7Ovpvek5DduPqNdfrS+O
VTnL+tXKtux06qMv3Tmpr486HX2Lems6U2IxJujm5y5nMtdrm+raV6tyj7o9mRU1QVXrkwe3
Np85t7+7y4KeLda5+mYuoVRGdUZaA8lu99yZwElv3tvTQiqUmiV9EALH08ViZ3frzJl+ry+L
AqeT0aI+3N9fX9mMe7Pz/emvvPT93/J+ADDuMv/eacHLXF8cbID4fIavHxZvS8VYYsU3gsWi
SIwFPTcxlrDpCLREeDVgSgTM6+zU1wfe8ZSP7J/NFzfv70TVmmOK709HnZcEaUX3w5C6sGRB
iIBCzCYzJYv9+/ceXHuFpBysrqydPX9/Ot2ejHtrm1qnyaL82kYEsw2XIZSKNIBEu5wkAhFV
hBzTmUlFgKAIayJFAHbRUobozzyBU/oEkDCh9tpuiWmtNaJA9MdynWAOqrYmyxz9mvcKE9no
9uhwCVl2bD0nRITaeccIzIc6vdJg/DNkx2HhpzD9ZFmSmwICQAKNnmWD9cR47kDmG4lWlXbe
c5+hB5wUdAIuUBr5WbYR5Hac5KJauA/FHc2OTQEnQc09agIN2h2Z8t/4QO22OLXtk/wWlAOR
hBU5QQTY3tBydIHhXLy0X1Yjv/eElsX7J/70HhKQNjLTcWVjWvkPmgTJygYF8cQ4+brUEvJT
xpcPK45gNSWf1gsgHGn30tHSEhddFpggjMBvdGFIpIvmBIUm70gPxbzir8FmlhEM0/wsI1kC
s1u5mvwScDu7BMYbSV44UYDf81hgIWAG/uzgeJod7+2OR3mvN7t3/dXp6Jlt1S1ff32+2uku
qNrRGVJ3up5XD/XF5pmz949meryjs1VY21STkcg7WW+IRW/zzHaRZ1nRkVk+qap5uZjff6O/
eVlVZcukMDZGAJXWFWGtkAjf9+539ljCizdu3ZGkJdSSZbcrFyURoSpRaw2Yd3oAB0RiPh5R
nATP9YW/9pWXjfRqvZbx30Qbai8APkKmtUhQn5BXA0hptsHfk5+M+YRLKfclYq8KueCSRBom
1+u37/n7Qa8bnt+5r4z3ta3ybLF4U3EFHhPE7luLhaac/8zF104W1et7u73FSW9lWBM8uHNn
dWMDBZaLeT9GlJVYgVOg0iCAUEIhURN0BOTCbsMoAgHkBYtwDJhcMEaGCIC5xK5w1oBbUU4M
o1mxQqDQYAIiCEgA5Sbjuwuw9rtvRKRcCJUmcN+KAn8a0sYs2M1ttOKHQEFwCJp7tNElhAha
ozZ7cswh71iVFX98T9RfwhIl2qzzcdy5d914xZm1Ediyi3snANSBJrntYknSWxhkUwB60zNw
cm8/+NNnvoC2ICGQURc8cWGAMBy3QuDBqA5m06Cw6Z/QePWEKx8WFRL6w3FAzop1YAtAIm0P
4FnHYAZ2woz+p9gJZTMTPhLP0U/L8mlKL76RBjZiwH/zitXzbkwTH8Hi9cH5LP3ovDLBcvPY
SA2TsjLEyoau/TEAa6yDiT51cktr3zhkCIVgk+dEjpk4sMYWokmibw0v8sYWBDitoBLud1js
niIJNEB2fyxVviY21jrloRqeLbYv3ZPwtHp1vBjOxADm46LTEfl80JlvrnU6eXF2Vb9RFwIA
92+ByKCc6KKvy8XN117d2t7eGGx2Oh2BWNZ6vP9gY/OC3SUAPqR4+gim06kkjQAPX7n0n/4n
f8S/ee36zXt37wNZ142/VlZXzmxudFaG2xsrxXCtry8OhcrzQqtK2MjemDQQrt15cHtn/zLz
jzloIrGTsFrOqdulFwaqXCLe2PNTRBN74Dk/E1dcckXVet3O5uqKcGqP0b8l4v7JqK5TQc67
2D86eXBw5D825i9/0qsVxvNbG4fHo0xyO1hUtToajYAaVVhlNwxLmZ5MvWCXAqb7h2uG12jK
JZ5QXkFH4AKpmpyMDncenLl4ieqFD+qxbMssPABy567AWS0m37kNdpDClwcXSYhOXzYcPEfM
JfJDWn4iDIs1aFEEEilDRIAZodJkPEWoCQFQYObEhnFxhTXJLDMwbquI5MhzHOOWJAeqYLs7
hgjsoZ9k48MZbWDT+AISGa6qyVhuCEGQWPbhQLJxet7xGOYJIGYsfjgagjofiUAAUK5rRYAm
GpyQAHkGAwONdt+ENJ2H8EinPQjEWpN2HjBii00gSOOfxBDAgFZICB4t6SnNH0oTVhWJkjyR
jx8AAogcgwh2mfOH5BQaK0XcAXN0Xlb3HMDONTFkBRJzZkekenra86GwRt8iCgaWm1DbXpiP
oDc49dp1qaOWQQibCdpD4112niTIh8+43JhOxlvPecCwa9zIPPu9twAV++M9DJ6oPAQe1qBZ
WBQQe5/NKl2cvwRS3Htlt7vRRSmPjo/3zj35qLj50rzXeegJebxbKE0ie+HGwSPbueiu9vJs
tV8Msx6RgrnudLKjirqPXc6yPBPlXpZ1e735YpEJMbl7Q8QHtcyS4o/yPPuv/uKfXpSLzY31
Jx69ygv/7z/9C4BIul4oUdZhtr71A+/5yD//B3kmEYXdeNU6y7K/8Xd/9Mv3jmKWi96d8mtf
efkHv+ubEmAwFVjpxdg4RQ/iPvyLuO+o9WbNhjgLUqop9Nx52eh6+uHL/91/9id4nD0iIOLf
/mc/9cLraV7H2PkPr96805ReJmRjmcz+49/33ea70qFNgfvHJ3/9f/nxWrUIS9cCut4JIAgG
JvBQK310cHRxw3ACLSUSCj3c1qRhPhl04HDnwfb586QVkD3zK4UdivkOltkAkMZf5MRPBzET
kLnvXxml0h0ptbzVgJQ5v4eNwIY4P3FgMU48kEZACaQRkpE7RdMnujVSKmw+uyCFIDksHuyZ
TcMgyLMAALsNJW3QHRmWabNHka8b8OrsErPgNFrGSV66AwS+TdHekusPEJ1vzZGBc0KG2SMd
WJBp0q0U5C4spFS6WbPH222OienAFlkdo/Uj2q9eoXtovxmGFm1mtfP9G/L7/06SiCCHyMb9
IDobwG9AQpggxkHRTa7/oIzRH7STSRxgZlmCg8UP3qMrfuFn0E5euslCrrr1FYNVCizMBMCi
b5zlFTBMPKWWPRJgjym5qCLScSNOFbCfx9QNnqmda9XMHDr5pwm0JsUOX6Pp1JuQaPcWKQ5P
01yGMSPaTVDAVNZdW18c7mQyg7xTH++vduXZvhgfj89l5SN4d7ozzcqTqR7d2xuPZ2WtitFo
pha6HJVZPs8EaURcVFfXUUwgk9VwFe/cgylCVevRbI5iH3QLU4tSISA++85nmmU++quf+bmP
/5rsD9T0RK6cqZnCI6VcHbZ8DVnKvFwsUvnh2MevP59KL4jZdIQnCxtnCC2iDv1YlvB7LtIa
7TfEWdqIDwL2cs1yf38Jge6gW3TlWdZoHcKqRALCG3fvfzPLbQ8ASukbLFy+tdl44xAAYHXQ
MhdM6nvNMbxA4I8ABC4ms/FoIjYBETWRFIBAJeaDtTNzkY8X42JyPBufrA/XJFJX2hSCmqAi
AoAMoQYonApp0lLkArsZSstAPEdDgWAObyGC9HvX1r9hWLw7+u9eAjgvh8Gj2zXpZSgULLT1
MlEQcp65WJmkIy9OmIyWnMquc/uP9npN4ObGcGOnfcn73Ih7/wCUBoGYoTe2Qj++MNeOzUee
jIfTx1l41RgtFBjyS0HSbNsdhLNcVqia09l2P95maELHLkN1u+xMYJtDjd/wd7xVsk+LeNnj
XFLk4/mQyQOyx7fBCh2XTDICG23wiJ9Ja7G7jBVWwjCGGgsLNmeRIcuUjLCzQJE3z3pmDb6D
SuCnw0gLhweMeokkoq2p48cIRupbbNTk82ome4fBVc50nThxHgtPJEdjyiEyNOU+KQDaZCxD
e7gFrTbg0SXdtHudwxMz+RpGeqn7NzpqjojbVE5Lmo3n3dVBqcXXsPfIYLyztz/IcXWtc3lL
XbmwnQnIZtMHuIKDQV3O5p2NDTrJaLYoF8ej6dqgM5nNt3tQ9QpAzKTIhLh08YKftJVe1wy3
321huP4aT6b/6mc+8o/+j18iFEJkFYhCiHPbm6dUMVev251NZxurgZmu9LtmcSDgvd2DxHm4
NugHzoGAAN0iAqzIMm5XAcCQbRENe13B9FJ0bfoCZzbWLA06+vTBYoYdnmWmz/pwEMtGRkKc
8QOstUmL5CoyiQBnN9ZY+31uoQHCtVv3klqHo/FoMuVPkmwgrVe/2xFRJER0RfpjtH9uiRsB
MoHjk9FkUQNmZhHkEgAISc1F3h+uz4teKbLFosolruTYlTb8mgCEgoooZF4gQIRuZtez+zxx
5JNAgMxmHwCzk0Q2SMzmMie3JO0ZSfD7cpwj29F1JGZCLJQ2A4GQUigs5iU83cgJitozDy0r
sMfbJEIhrRgOA7GhiYGnAHNqIQTd35h9Ku7as2T/B5yWDQEVAMzYwsCEY18QuRn1bD4MJiAK
uYvASQwEADCpnEA7g8hwUmEZtGXrwm8Yxu5HH/XgczDa2Ajvngu5lMgD7K2laFqYUAQ2LmDj
oqQihZa9FHIbPH5jzuPLZ5Cwlb07xHsfg+c2ecXiIPx0aICa0CVDcUCizQoINie97Y9VJ78e
yCkhsQpi5JazU/3BdnDH9yJh7M48OPyTY3FRemIMGWRcz+5kpEQg0jbLRmhZe8kNVv8J4AEA
QLa6MpDdMyfZcANHNJrmV5/p1qNBPd8vtud6532Xb98WV1W1n+Xq3v7R5jArin53Ou8RLnQJ
x7cPtOxJdWGQXbpwBoHyTjZflOuFWu0U09mi1tX/46/91YsPPZIN1wbnLv3m164TgAR6/fXr
//pnf0ETzaezhZJCK5KSiGaL8uatO8/f2Jkc7kJ3kGfZnHKNhQLxr37u459+/lWplMwkldPd
w2Os5+vnL+eDIQAg4mjn/sd+9VOzGj/2+a9eu/PADO/5199Ap/8DwD/417/w9keveBS8dOO2
30E21xv3dn7iFz/pf+4encSCA7567cZPfNRue5d1vSgjUw8Afv0rL+27j6rsHR07mkO0jAe9
4kCI/+wXfnnNGZHXbt3jWicnYE/u5uZTX37h/sGb5MJ4494OAPzEL/7Kumv/9dioQoBb9x/8
5Ec+4T/0DAAm2jAsD4SD45N/9fFPLu8LAWi+KLXSwBZwUoILeMtHLBuwSWiQYHfvoPY5MzRm
0tq9pPUY8pW+mHb7rx3NBgcnjz0stNbGYlBEJoQJEXLLes1pf/vdIG2NJIt54TRxMj5DAgKt
CMyOQi4AGbJ9BISyEYOxWRBi8Mhsg5kPFmu3keNLGt+gPRLD6oPbx/YcxLNQnowgd4e3wq67
10PdrhV3UjlUmzgVG4nHv6SFERBGMPDZcq5X8GyUIa1NR7Emg/N2CQDhUiREpTlLts2CHxF4
PLgFErgwEDlXapQh0F0uSsLPHTGoQnc+OpGc+I8xFomuoPIzCeekgN3BwhB34tUOQmebEDs7
zOHVFMgD2LR7Q8oDR27FNA+/G1Fdu2jAyAPJMrL7ziVw+y0ZV9B00OwTu6l3/mYA90SDVYOQ
LRXzLTEyh+cMAdvqTmMwmDd2FNNIEO3eGFNxLY7Jq4BMu4IIZMA/9EM/orv93qA/PT6s59OV
fn+uRQfUQ93p4XixWpQVSAl46/7Bnb3x1a1C9FdvjPKLm91S9OY15f2VNVldkQe/+fy1QVds
nL14dHD4cP/w+l650VVZ0fnIy5WUcvX85e13fqCzuoGku1Bn8xMFWCBNjid7izzXZSnyXFeL
qpSqgsEmzEZFrw+Lk7JYrY92itWNTC8WsodVVXSKycH9m/fud6naePLda2fOIoCQ8sG1V/bv
3dk4c+bx594vpSTndmtx92EgUsZXI94USCXsyLa4DRvr02E9pR5b11jrzvfr5ypskDZ4g+/a
q6R86QZRyKv6wSBrIWkqGQXEXRuqJb4/DpyzNwZ46pNEeoXlbNgdiroqP/e5r/T17LufycZH
9WBY3z6Gn35VZJnUAIRYIBQSxgq2u/L7vvW9JCSR9ZtlwoaqS3d6yWbRRbMFYiwYbUSbS75n
HpJTFe05SjNA4XyPZhlpVgy5iGFjMIeBTI/mW5HkOJSpKEIucCvKLLey6qqfQctb3SlstAOx
bKWF67kMOv6Ll4FWyQZrWMJFq9b7iyimV3R/u5QZwc4LvilWnfFxt3+BRkWwwBn1IBwRA6uy
xJw2IilPttwv6iR0w0vPRuLPrTfZXNx4gB68OGqSrA9YAAAWBx9WG9j14Fv2eCAGMPfCkWtW
O5Qj8CpxOLtbfb4Fs6HLzR4vbn1HSYxJwvS9GOECG1x1dIHyybaOg8OYsDaBk2qMy2hSHlpy
hAQA5huIvryPjOfnr808OFQE2ghZKymIZN9pluvZjZ0pltMiz0Dmx6rsUbW9Iu4X5x901Zl8
sT27IUleWO+tnb24Mugd7dyTa1vdy1fk5Lg73JSzEVBXV0ePXtoouv1xBRXh9er8YHNxVMGC
isHmFBdTPZ/M9ne665ukQJIWABnKTADqugAAXQkUknQOFWKdS10iCUFCgBRqJqEjRSFkX6AG
kRdZnWdaq+P5YlWVGohIZ1rnmSyyYnx4dOe1Vx56+u1I7vhQIE1yfhEAdJwT4sut8wRRnlAT
7hExYlPRSYykQiB7AhnOPKL/XzlHPNmgaXRKOzi/Q2OHBJ14jSQvX1bAfvK1Ft35CGbGW+2/
cY/NLZoIltBGoxyDDw2WLPoIUOBkPFnMy15HaNezQJA2CQIBQAkiU3qQiYNp9frNu488ehWU
ymXQLAigdqHQZM/hErrPl2hAReSCzk15h2q3XH38g6bAidiSD8sMEShYQWH1GqYPSJpQuWyk
ZuI0AAKFb9IyLsIZo8MwGtvF5i/HsHR9ZhAEIPclRR4TweQJgDehYlbj/jGyFMEFs4DjOGhF
XVMSONGIgROSTcPqj+FabpjWQ28j+gesRfc395L7Nrz8I1aFt46IkstatgXolleo5PsiN+rw
GSM3GRRLl4BRkxqKsYMggSgCzIsxCMKPzRKTIuTPhBHHBqL1QYLXoLUdrDsHHWmWZEz/kFHE
+IqZOAFixzgYqOg+nYPRpFi+wwDlTAZNH4GwdHjnb2yST7TxR+TSu7jWAzKcmAPlehGWQ1j3
sjYhpNGqg6yH9Tsvr50Mn5qIwfG1F65cPHdWTOZS9rB6rj9Tst8bD2g2m6m8X59osbq+0oeD
+XS+0JNJVYHsdGRvKHFXa713NNre3LijiB76hvHuG7Px/VLj96/Uq3IqsjI/fmFwfwwy61IN
5QIRMwHT6ajUQpImyqQmpWulVbY41qhEmZEuscpKMdWLUa4rQglKC5XXcHK4PqsW87Xqje7x
MZHOpZjL0Un/EPNcHD5/9s5YGoeYECDYSQnlrV63fJjfDBBAa6bAEAgJgn2QHhG0iqx0KZlx
BoAISoW1iwAiY8skPEYEJEKtgtYGqKUMvJDvcDCCAGAwcJYK8YUChHDjdbAJm97FSj2ilpga
6Q/d2g1VaiTf4gMBgFzXt1YvvLT+cPS0TZDZlhknMhrE0eHxQoHSgHVZYC0qXVWZINBKmzQA
kvQccKhVlskXr999+NK5otPVWuuQLcnZEXbpoz/GhH6pE9UESltkgJsF4cMkXGyFCTR3jDaw
FKd/ON7joxgINKDSNkN87b9w7KeNSxHGKrV/7VYxAWYIUqA/MWpotSaotBMMRu74DQY2UrI8
0ua2QDYA32kyO4wbgteRI5bnhL2r6MIZQ66faJaJzbtX5N10BOHkL3a6iDcSIPWBNc26vDAf
mg4lucrl1AmrQTkwPbhugsGSjYsBhWCiYqwLMJHsBIP5+Bkjk2Q/ic+XtkkdE8ML0AVmC7MH
aacJIST3skattltDKEOcEKCLVuW8SpPNcAEs+AXA+/e8II6ARUANpAi5rPJqOgBHPQ9odNUd
Yn3uFqOjmGP79it0QSMz2QOMKA0N+5wmvHUiyrTWZQXnj18crz40Buof38i3ekWxqmXvSJyb
1eIheNAtsvlR9epJdn7/ha2tDaXlAmQlOoOzl0FKQVRN1P39UafoHE7q9Z4cZxIfema090Bm
+Z8aTNfXTJTaIRwcwrKLe2rNl7xq9ze6e3OVAALAxnDchcnd8GrD3Rx+ZWlHX7/4JSRNRnS0
C1IACHH2MlSl3r8PAgAzsX0e8pymEzrcEVvngVDv3QWJgJnYPAd5Bu4w30vlkZFeCWfxn0A0
P71E8IwAAECro4Ojjbw831XFZJSRhkpcGtAPPCIWNX7poHuz7Bn9baGxI/XBjF5/487bn358
ocCvfB82Zriw1qTdV5e0W2Dovh5SawD2KRCTepXxD7vLIqLvZXhrC7UGMqHexNwsRBWhFECW
H4EQIM3pn7AUPTMMXIKzQrAnAcgnoTD5q0zEHSHUZM9YkTXJI4U/vuUsFzza7QFtpv1Il/Ap
biE0RHEL6ILpU6OGXYJJGx8TzwUFIwvSABgSoBD731RLZFNLj5i+agHKcjz7I8G6yVqZikUW
cwEemU5iBbFEzlIz9WsWw0kNUMjGlftmwcsS649wmrbXawVijmAMbMvHiYQwsS4IAEy/Dqgw
sAa5RCb/BSogTeS24yEoHz6vFAPbqUcYxBXHHNpsn9EaYRMlTMZq4/2TbrBu9OA/YO30hMgS
COgFcNk9zCauOcuiNGZ5p7i2c3J/uvuBJxYnQh6qlYM9nEuSdEJiokhc6CpRL6bzkqC/eunR
4907Il8fnD13PJ+CVkJKQkQhH3/oTC2681KPjqt6PukMVjDvANGRlusyOrD89et3yiUEjY/F
YFD84P9dXH6k/twnyl/4l9Afdn/kP5ePPF19+herT/y83j+Uj17p/vm/Vv7ST+vXX+n+yF+S
jz1Tf+bj5S/9DPZWwEXPz7JOw8Yyl18bAHxpuZ9CiPF4elUevOPJo6JTHZwMD9XGSj7bWFkU
1Vxr8eh0srvAEfZyoBpQaihy8cIbDx6+dL43GGitCZ1eT0BGSdQ2MVLOHTtg9orBpHQSIW+h
fYte43NsTNeVFhlfmujYNjmTRDGeCwCk+VoGECSCzhjS0VmksB0nIsjQGEwuXaLVz0MsAzjx
E1a4Czn0hqFhKT53H8c/RlzeHu41mTuA8wzXEUScKCgcPgoXeUnXOeOW1nfHIpzDK3Dncx1q
vPURMzAGGbnumqA6bktsiFF9x4XbavpRMFnPDBQvruw7n1SeWH+GaysAbWPnQusU+VB4BwFU
twNkvGQ+S6SbTVsTwR7wCKqGJzZkwAj7NdH482kuhM8B4VSQlJysiuac1Y4K2fk5YoOxVhQG
aR10ALPT7M9/k5tqDMm9nGfSuw657AvAe9cxOplLBBoh6+Ds3HBle31j0jkj1iSNDq6sqLvQ
2Z8ClKOM6jlURXewtZJd6A9GdXV2Y3hzd3R07eVqNgOAzsrquqwzXd45mk3nx2fPX1AkJZDM
izODAqrwQeSvX7/jrtkMJAz/7k+Jh9+ud28Uv+uPgUBx9enuD/0Xev9W8T0/PP2b/4m6fb/3
p/5y9u5vqZ//TOf3/4nO7/vTevdG8d1/VGz95dk//VFxxh+HSBTXKEre/+vZqH+MiOOTcZ/K
he7slJcqmu3CkLSEevVodv/2qKMnx3WtdAcVAAJWBAPSoxJeev3mc+96xpwCNMxCxEm50DlP
zBIl8kvIpo418sw7WAzvEHY7CcF8ACVaTjaS3jQuADUCkMmt4NoDK/vMNjffRfdDJmrh0PwT
zE4xNYWdcmrvTd45V58x3IBbpigI/8JxOrI8iwyQ/MQYF4BMZKKzzKIZdrIK4uPGToq4Ghh+
cCeWk1vhxC141CUixr3FAGXsZova9dychaMwDR4iY5SiFnTatzfUggLhqRxDSB6Qdp4jG3Fq
+bIlhOgjoAYrQePhy8Rw5rCQ7Idv7ByRmz0vSDwagx7A4ksFc72F+UOULsAd+VzEkhiBUPBT
gwTOng5HifmEMNlmSc3JpyRtBzjB7cLQ4j48MiI1wrYpnIvb7BcIpEzIXg7V69Pu1sbqWbxz
Tck7Y7y0enh2vXe/eGg4ujddu0DzoyLfuT9aDLDGXhcl5oOVuqz0dLxWH2BezOpFWenVfudk
Mh/28r3Dnaw7uLImF1OVlw1q/Pr1O+OiyUi+4znx8NvLf/MPJn/jz258RvX+3H+L6+eqX/nX
k7/6h9c/WXZ/8M/qw7vZu78FgOTFS53f96erj///Rv+XH9z8zGHnh/7L+b/6x1DXxvziAqmh
/rIoArTrJkgyhNHxcbmQSqu14mgqcY3Umhhvi+PVIT3Uq790T9QzqjEzC0iiWM+pB+Urd/Yf
unw8XFtXqgZnlCBSBkBg84r5LS7SJkc4AIDJDQhOqgmEWoezUGHv2WREjJapd4wgGX8joQnO
oGBhxMFYXGKwtsImCn9s99zJqqqWD0YRegRhh4SHZjmdIFLnWSxCYE3ogHLCEpyJYP4iBPCf
J0EA5lHlzA4hYTjkmJErgmD4Puc/wLr0OjexpoMG78CyELhIH6+H+EpBQsVSDH0jnNW7y2gD
cQrdRikfPuUUIDdQPmgACnF0QZI6kU8Mh36+ENyZChEEdlIGwKU5NohBDBONjombszs8NTA6
DcjsemqHXxv1AwDmIB2DH4PmwsQzUIaGziOcCCZ1nfx2R/X9kQWK5sKA7TU5aWfR0YAbtqc5
nisnFGC0ZW4kYCYkVoCjmsY7R3s1bnRBdga3qb8G9ZX5tX4XvzYZXML6eDy7dphf6FRAWqn+
YH1rRc/WC1A0ONSdCz11tpzPdLaWZzeORkIu+oc3Qc8RQJ6WQvnr17/PC9c2aO/B+C9+b/WZ
X8qe+3YAAdUY4Jy+c1fvVTTagfWrJ3/w/b0/91d6f/K/xuEKAOjpmPZBz8a4cR431ulkis55
mBhfTRU3kW1k8h7V1eHx+PEODnJVQyYQpYAaO1M4f3+yf+NQZPUko7qgWgJpLTKh5kqCqkHV
z3/t+vvf+y63ZNzZXaubo08t4TchTCCicRXawCcEx9DBRe65DW0AoUijj+kkIs/VyWWN8Fw3
sgmcfeOFkv3qCoVTnxYTTux5DNr1bI0twzl8pKyNtjFdRE1FqEa3KRXNBeMqdghB2HrJZ24i
eRU4jJPdABAH5SUT7X+w2G4r27hcJGYrg8U/gBs7azx8nyUJHYzluh+TkzmuU+3kNZcPqShj
P8IZcIcbD7TWEd/3B7od7zYbVABELtjdfNzZS0qj8ZCXNH6mrH7jvmqCYEP1zMwLQC9EPbRc
ejOcO6wZGWYoQlj1DtzZOE1oz0oyeQBO6THLgsj5CQBM7IaXdmji4QDBqXF2etl2rma0o/0a
8dnOXHcCbWykcJBnAhBQsV1dHZ+1N71rgOwg3x7mew89+bQQ0KVq+uCmGG49Dke1LpHkaFY+
Im/3MlCd/P0XMuitYznLDqb5G1/ZGuCtB7om1FU1Wytv7Y4KCZ3heq/f03q20t8Uiw7UX9/x
+h185TmVi8Uv/EL+nncM/87/CeV0/uP/fe8v/UMwH0ctZ1Bs0YxosQAAdesNvXen830/Is9d
FFuX9e4bQR11Row1KdjhDrb0wxMMh2HFaDQqy2q3EgeLnl69KHGXSJHIq6xL4mhM+VBPFpUS
PcgRNOkeinWhxaC71sc7D+7fvL7y8GOPa1XnCNId0iJ/9gAA/IJkB1q1jYYIej/aDRvL78w+
Rw2CNAj3LUW0K9CtVafmMmXcsiCBkCOarTVlYgWJI4Kc0mrVVveOyP6fmDVIQAIQkTLLgOzy
ZxoD5/gtl3MI+kg7IpcWyTVCrGRbC/7YjtfV38IJCq7EYGg8sFmCIOLMc5Z+IsIaRv+mkhKc
YDeKDBNXwoPMWxOBONFbD84cIJ941zBwvzkKzvjw3RvXtKGxTEAuQCIod/yOXNJhQ0XmVAY/
io4untCNyr5lcsvHHwbdhQ0I0KbujRednxuMtKXQa0hiEYlzpluCd2OilV6RpgBgKNy7x20n
woltCh/r8jugADZlpQEE/TC90SoAUDg9ktGic2OSwyoRQYajfdSLxa1XFdW1wEzqo/19leN2
Vg/FeHeO93oXHhfjPK+UqsqyXO11VjrVyvkLR7KXwyGsncsO7mVi77HzKyLLD2dQ0+Kw7rz+
YPL4oM4zgfXXba/fqRcRHR0U739u+A8/jjI7/sHngMreXwISGjLA/iqNjrEALDoAQIeH4z/z
Hf2//KPY7ep7r+PaNijlOR+CyfLueHFDYkFQ48JPiTiZzJWqMNO1EjXJHiKhJFBQL3KgXCsp
BCkNmhQACKiVGhF2CDYwv3BufXR0QKrOBWZIYHaPnCiqCCptcnnYnENW8rjtJQqrjhDtyRK/
x6IBgHSUutzp/iaZBvFNJwCAYBxIx5TNessRtU1Ha60i5y4ib08FYctcU85XRIhovmArjA3I
Nn4812OqgmVEkWnCTQlnOnreAU5bjyctSgptGRmbQi6ZuExjOncMo2s2jYT0kS8Y12M1WROM
hfruHT91Xlxf3Qh+1p91P0agG7UG7XYncCxakkB7gMFcigC0/aSITW5LhOgOFxpx5ZUnp+iA
U9r8kRQ2Rj99VkEBDEDEePY3bCoIENNF56Us8joMDc6bHakgZLO3WGkivOcBANz+rptI8pZi
LO3sE0QUxOeUUQibaDsKyzaIndqIhLrkUpZ0JhARsqPumbOzO7R2Zq4AB4PO9MF0Jhfz+ky/
enG+3uvJs91KAY2mi5s7x1v9g/75c3tVNn8w7et9Qfpk/2QolViHO0flYjG6cP7Mfg2SqpNy
XnW1BK1U45MlX79+h1xVBVj3/8r/jP312d/7v+qbr2Tv/yYAkOfPi7Mr0NvQX/sKzMCcEsPN
s8U7v7H65L+Z/aO/t/HJe7CY08EBDtZ9Y/6rfZZvBi0dXLIIAH/uhxCAEKjbyRAkaepg2dMP
CEoAyKFcg51uD7YuiWs7+psv4/bqyXEpP3fYW0CGCEj66OCwNxgUK50CKRMoWAIho7pJAGnd
TQhgP77udWEjggKXIn+u3XoiJSLoCkmgEH7nHEKaH7Pd5bRX2zPXTcmKKwREkggZgBQmmTkq
H0Ni6wSFO7nQ8zurMaflMJJSHoC4eaaxA5BPVecvcn0xBsdkexMsXisEPThzJbzmcouCOG6x
qHhvfAMFnVhKZV5UDcFsCApz5+cl4thRj37bD1nD6ESoYpIcAbIUV5QJzJAQ0eQeYy7lMEpe
yYlXn20n4AX8vMRYi0YXFY8G4hvHuD8f6hiJefuI0yolk+RdfH51MEJiEsTOE98+Tex2Xy0i
zkRuMUyThzcZKlFj8EBAkCmQBAiz8aLCxXjUgZO67m7h+OBwcut4JvuDNZi/a6sqcon54PLF
tXvHZU/NL9ODqRzWdT3c2BQiK8UuAWyt9Y4nZa/XF6oebl7qZAc4PVry3auvX//+LxqfyCfe
IZ/+IAB0f+Sv9P6z/678xX9e/eI/yb/nj6++6wMAsPg//jfSIDpdAKCTPfndP5B/6Ps7f+jP
4vr56d/5C7QocSXk7nHbxUgUEqfyVDc2FQWhclWkgFyKC53pI4P5RqfSqKeQA4KCbCHPnqjD
m3u6QHr2SnF4UvYLvKwXN3FDGscmwcnxCQHkAjJhvpscEtgggjRHyd3iJ0JF9nsNmpwpBhDU
XmIcxwY4kZTCfpzDevTdforLg4CIRC7I3dgrdrGZTG4mvQtlaL7S4pJuABGBQpcQBiBZ0o7D
ksk+5ezC1KoAFvIH1vhDx5zs1guwxgNXiownxLh3XhgazNRpJcRU6Faew/T6oMGHDTMmF+2k
OTzwtmIOz0uzjpy0MAp8DC+1CLDksYMkiNXMCXLhPjvpixFRhiAgzDkPnwnmQjyAMMVMtlE7
2pvjC2YLe+fqtlVm7/ktYYRkLrYC5XgziMsc1oklcJNjhYcR+RFi9DO5WlqlABg4HAMvAE1q
JCCAbP/2zdV+SXgynyqR5WWh1zvirKTPvXK8+tDTa1euCiHq8q7cvfmeq2s43NjQk4Ny9ujl
zROV76jVsrumy4WYHV0+u6qV7mjxYP9EyWL18iN4ohZHO4BiqfL29evf64X9AU2m07/1Z0Ar
7K9Cnusbr1bPf7bz2kvyyqPVpz9a/cYn5OOXy1/7iLp3Xd+6Ofmv/9PO931aXn2i+of/r+pT
HxNb5xK10B5FQqsAk4vY1v47VQQSIQcgIIlYCNzsiItnZ3NFd8edTu+yxCMgpUjOxUoFoztz
uJBXZY0nlaxKNV2UuquzTNaVqkkDka5rRZQBENlTydJvZzmHu/epeK0e3E2y2MAxd7shkRud
mxBAo/2YlmOSthUE53Ii4U/5kD2haQuZjTOlAd3RNL8xQI7heN4BjgMKRP5V+4b6ynaMAFgx
xr4SV2AksfiQieED2XM+t4HZMSZCkH5TJGnZANYi1XjT7KET+u2QJoCldltDlw85dHndgEPi
j9m8s2AKIZrat+uHKx0xe3Uoc7gJpleiENipj1vHVoQuQ0oyy3Fx3wW0/bRg4tJXbT98B40k
zBCoIqpFsV3IbjVrIoQkJdaYueKP7dlK2cVn3rGijzvjE7p8UWndh7k8vFsPz118+ty5Ynr8
4CU9PLvanc26+Ss78+7OjXNbGyNd/OZ48zLtrNP43slBWWxgJm8e1ovJyYXttd72xUE1GQMU
EqnI12btHy38+vXv/+r2aHS0+Df/3D/A3gCK7vz/+z+DJsgLsXkGsky9/lr9lS+IzbOImX2V
5WLjDMjwGfBePdc2wsqqpY7vIwBINKc4DWnaOtrk1RV4dyJXOlhr0RFSIBRI0n2hQwghUCDS
1dVqMofX9oVWSmgpUCAKrRQQKaWUFIqMG8fzSrKRxM7yMnBKswtBgGSNQvNJlFpb5x+B4WGI
KKgGImW2/X3MgrcqARCR7yUrgcK04j+b5E6eIriPC4MTXRbhNnUGOtZmkiVirBWE+XGd2W1t
c28toIRFQYtN0cIB7VaG5x2cG0eCMwptj8VkeiE0QAiKdTj2mwJjBF1iBxKYL6eEmQWwBpbn
in6aeY/g+HJw5vF2vQHkFRSPIm9CoSVY32wqKHiKrjA7GJWzmhyZBk0R0gBsjtOvz/uBJxcb
WruEYyVTUD02W+Qf+zcB3IEPDIfEuvcnHVPVhw1kmeiy7zD6eJlO9pJNIYqn2M0pZKO93UzM
+1QuZvN+Ljay+RGRHmysiNkY+ou9a09sT+uqenAwvnZ3+vDF7dXFQs9rMT18VWxcyCaPDcaT
2XGuaZDpK5c2jqfVeHLcwcVwfF+U40rDl3FwBio9WJezw+m8nszmRZ5lnV5vOESgutaAAFqD
kECktQYAKSWxICCtlJAZWVeIBiF1OZ9MJr1Bv+j2lVKT4+Msz7vDIQAtptO6rgEgz4veykoL
vloVBo55ai30Vq/fbr1/2y74akRWzjvuWqkZAGDjoUhZQoCtq1Gh/lk45wpvPdxsJNPqjeF5
2wahRpKR8WE5PTrVGgBqIk00U1QTnOtXNcqaCKkmAJAyk7WBWgioNSkFL5z0q4UCNaolzBRJ
9+kfpRQphVhIJHPCBoVQNriQtKrni1LVquh187wAMHkdBSBkCM5WQ0SSAkErqqaIglRVwFRX
up6P9fpllLnfqBYuCs5H83JUg812in6wwobOW0EJpL2sAbf1B+ZgGaLNqZOGFJBjh55RoE8t
4mY4zaccMw6NnCgiuchFO2HKv9J7zj44k01CD7ldexqL5ZeLNGQavTNaTOYQhm2m4BMbGpdt
XhLZ1gRawosNIOJbsk6rCKuBb2c6nagJOnn2bY0ty4Gjz0mjx0yUi8XfoBvgUv4Rax7c6o5a
4SqL1xveRNal8CBzW3A7iJplA3dBN/H+rZ8nctA5WD02mggNZx4oRhSylsxThGxxuNu7uJ5N
52fVvlSY0UgAvfjGfrfXoenhlpDX98srversev89nWFvsEKLUS/Xl1dgrid79UBV+bu7r8x0
/6TbOxqNVge98bzsCVos5krmEujHikdPjo/Onn18Rb9+43j8hZeurfY7GxfOPnHl2bWVwd7h
XIlcqnmdDVS1qKu5JtHr96WuKixAVxqomox6q2u6ViBzqWYqH8z27sgtXN0+iwJ3D05uTW9u
baxevvC4Irj1+vXd3fsoxdbZc08+/h7UUTROtMJjRaGJ9lY9JWmHnKZmle5mN61qyaltvtW3
QSOybNBAIhEytJ8LERg+8GEzpLl9GwQQfu8kUf/eDAxkQ2Ko9QvcZ6tIMe93CSQiESkNpYKj
sdxclQoIhEAhoVKlgkxmiEIBghBSgkZRC9QESlM3kxmKDkjzHe0MVFeC1oCIZVldv7N39979
qqwrpRZlXVa10Gqzn/d7xVNvf7K/sU2qJsNgCAFt6Hwms+7Jq3Lvi9DpgKqQFOlqNpV7MFw7
NwSqEWNmZKQTMxMQMBPhlCUCkPsIixU1pqD7jLvX6IUN/iBzeoac+WYRxtcs+ffmnZ0BX5RL
FCcQHJe3k4UBFgD2SVvbXiuP49p1/IxxeggBJeaGJy71ATUQNQJMVmvWbmC4cQJZMwAeBApM
eHi0e03OSzjTV9SzWwWOXC1CuERpRQMwg48XjXFjmwroCRwjbtgBnPabyJvGKksZgpMhUQih
p9CGQZNMRcKfmMarLY5cI3zCI7B8jRSmQDyUwJFcPoIfncIVoYq82wbdgqLs3Lnt/uaGWoyK
tW1BiuZaLWYbPbEhT1a35NG0f1JRid0MytWiOhntn98YiGN45fbofL/eyCebg2xfbRRIk9mi
XqhOoUqQA6ymh4fbKzUK0VWLvFCL/furOXU7Ra9XVFrPR8eT4+ONQaGBCKiqK5FrQapAXWtV
oCJQXakVKRKiJCKALMMKUSlZg5BZ1jt7ATvdcjy+/sorlx57bPPSlVLV969fm5ycCCkQBZG2
RMwiVi12IrYbYToorfEMR4oPRreBoS+/8NSfyatUq0LefIP2DUf07whqm0YFBIBEysynGpEy
BOU+KWtC3LSnK2zhW019LRppgCpQsfktbRdETpP2NYTnqQTK3uOcMgTQiqSugWrEvsCqs3gg
5fyRHlWLSlG2KhYzAftIWzn0JCkC0iARhYAQTUH0q1+69rU7B3o+JSks8wOSAKqaZwejcvaV
d77rsWJlU3R65qOW6MoAEKqZEAvsmIzzAqArsSalAAWgUHWNWSaE/WAyacUPIyEaq8slePA5
R6PE3PacK0YUFE21K4CWetMpsKsXo3Z0IISIjGNZa6szj6N7xbcZOCF4d43njJxht+1dBREC
7qvBkerGbUD7oMmiQ1iHAB/CznANFrvximuePGPYaFmcHvgl20Yt5YMHkRpr1ENIURX7VliY
kW8BhcCmJf3xdpggSCWiEy1h3uKQh2R7Lm0nCLgGCFZcaQ4DA8RfTDEKTzzf9IczIruz9aIg
B5315/viupIXlNnoZLRGs4OjSb148ORq/eJuOcz0Zn9aa7g5BixWUBLm1fH+7EtvHF/aHmz0
s2kFG+fOkKxzLCdad+RKWc7PDCox7GtC0OW0onGtRpkaZFgtlND1ycloa4OyTGyvDedlXc5n
u/funLt4LpNICEogClQgQMi6UiVkgCBEjkLPtdAgFEitUUuRIWYoKtKqVqLQIpM1ZNVsDiIX
AAstprO52S/RtfJE01gzLZdfZowTtykLbzmGMlq3b6FwpMgsEa7gVoAvmY7L9mqC61ARKAIp
3NdybZZPt3QYibQu8BbgIyBbtFquYxIQIshG24gkEIUROVJmCB2pzg/KXnV9oSWIdQDK1FgI
emgFdgkrBY+tVPMKFvP8285PSE2/cNA/mmsf4y4Rq8XiSy/ffG1var8QZKUmgTkvDFBk2c7+
5NaXfmN48cLmo8/l3T6QFgwmlfUyBNCgEYFqkUuRCSkESlT7d2jn+ZnuLkQfO4N8sN7fPCtt
iiwirT0mXVqdRDFPhVOMZodJdFMSmvAlhVXFbI2YmwN/7qVerPUwU4BzWp9D1r+LQW97HsBO
LmqSbkyi2Bg+hZDr6Gyyv/cSiI+U6XVLgPHnqllXXvqczkNtUQxHxzzCmxpd+hN95eStn1LP
k/2o6ZSRUFw5emNCVyku2i7dOF1EUmEZi/KQ+YGHnJ1cxXE0ywBEdnrCDTQeOrhsMM3eNViP
RWiSANjxuXAhQLamJyM4Q721iyvySIv1K5c3Jnduw5rOeyaFfFmqio63hvmjD13odnu3j0+I
8Kw+rufzXeieUDFUoyfX6t3xYu9wdPXSls66gxz3laQMyoXuFBIgJ5VrWmRApJXMxUKpo929
stIiK6YVAklBggAFohAgBUjQNREQ9XNCUa8UWmvKc00ViK4+OqYc6q6oNSgBWqtK6DloEAgo
cwlaq9qk+DIKj6H4poRI7ttpnU3xEq/0sowDUeyUYyctakt827YSmUijhjDmtXxRv76V2VVE
EM4gM/sx5MjKe/Mo6btNm+U3hjuiNwK4CHSKJhFoIIkojcllfZeWi0mqhrN7a8NFLnFeyjme
RZzPFWjMNV7J1e7zhypfqEfX4ea8dzKjXj7VeXZUQodmuiJ7qp80oJhMpl96/T4Ug7osAQU6
8YygBYAE0loRwLU9XCn3tq7MZCYrAiGFlDITghaH1WxU5CtYrCzqQVUerxYjzASCyne+9ODl
l5Qqn7jYVYsHh7swu0dH/TPd7YsrG5sLyvLeEIVw434TxogAybckbT2OXALH5eMDNWyiY4Um
KoD+n0R9ZRfF7USvYzm1bDxtNN+QXgiceh0rdEq4Fa9OgPHGo3URsd63Apt/FSvrSZ2IdcZN
MZlBYUiJ5UBhrpLK4RAvOGEGbhs/0u8MMsyta4hY40sGS5aGCIL0s5YSBaFN1E44AaLwAhPE
AHAjPA6LNYs3Yl2pN4vRQcTtYt03HZbv3pl5wQynxs4GAhBkN48rqqaX8nm2WByXiCevvXQ0
0wMCPJR5JohA5hrr0QLXCnpjZwe7q4Aq63bzlZ6uZFasDvKzenq7I8fPXN1elOrkaNwpFutP
vLPAcbZ7uKiFrKq17UuZHAmozpw5Uy2m1Wrn/s7++Ph4uLYmhCDQnZ4uQQNBjrDaA1VqygFr
lEVej0W3yKpKZ5msVZbLLMukhqyiTAkCEFopBCBE1ArVHLMOAepaEZGX8lxuLRE2DO+BI6Dj
LMjZO0uK1NqEOwYb/C4YjuykdVIdxB1oT2SBfxvTA4Zs1rwghppm38t8vR5cyhlAAIkGLtDh
0z7oqZ7iphKoGXbsT07BTF8AMAmctO3OO3JJSDjZ7e5/5aDuFgs5muneajdH1ccqEwCYSQlS
AiASYaWhBFmQ6GS03oE7QihSQqBSalHWBHA0KbHb76iZKseZEIIUaiURCLBTyLc/cRkBp/NF
tagk0uzetfuj6f2RHgz6W4NOTx0e7dxfLKpisCLlqMjnvQLKrl7ZKrrHr0yrWbmYlf2rN+fi
sfXxVqeqFDwYTUYP3oDD63tjXH/kXVuXL+tqAY216Lk2cikUuAqFyYgmNWLnGLuq0MkeVilO
l2D/aeftTW6GposlosCbIJTWi0gxVps42YNbCDHA0ZBj/a+5qAIxWlYdDYeCXpnQJLTNSMzG
G+Xcz8g96AwY16mbSeLn7TiE/Kdlwy7NYujVpbAAv/y4MHTtYjSXdoQUTQcxQcsAX+7sS3+Q
Z3R8kG6R+4lF73oKB8JPCTRx1Rq/sKmwsFnjTJbXS7dPCLM66wy7eaXrBcBge/PeVA47s7pc
iJWtTrcgAiy6qI/q0cG13SkpJYVU9XyUr69sbW7sXx9Xo6yzXuYrne7JaFZ1ivzCepGj3Lnz
+vpmTxF0M9JZtj6UvVrq7Y2VM+fuPv/5MsNFuZiPjja31pGEqlAImWU5EVKlZZarqq4py6Gq
INMoFkpoTUhY19QBAgIBJAVlSHmeCxSAmUAUnQ6IAnSNAHVd14tF0e2ZWcEIDzFGWRB0A5nh
b748PCZTyWOQGnpKeYXwS9k5GLhq6e5MdzFraLsMT+AfZY9oPoBnG9AxF9QEwnycEGzAmVsU
XP9rIU8EQPtBJqanOR6FDHjuZzX7YGj2MwAQYVojqbzUUmhCUAVUEupMdDJBgCSk6GeaMiyk
KlSeCyTSiKiUpqoGIikLpfUrL744HA5u7Z2sD+T03r6YjwG1ABDCZMgWUmQdKjXBsAPUKXRV
Pdg7npRqOimreTXeVY+sHD9+DpRYXVRUqbqqy8WUDmZqfUvOKj3XK5cuKJDzvUnxhdv5Zpc6
GYpCDgSoWg86YqO6nY1E1d2O8N+8KLJN2ueU2gtw4cHVGk9pnu85fsVZsqWCWHnn3IdFnwTt
LQHH1fehe24SEwgDAUcnvVrQshQNsc+vuS/DDNWwYuKeuLCJhhRJoVATedWGBIlWBX/iirYI
MEoftAwrniz/DJsMx/1NADZb+xI6C8UbHM8qEI2KYWOMa0yR6grpbKHviuusEN0nagT/9Aum
Ba2WZOGOzri3XB62TBMW3f7D3fpwqo/KLgi9vrFWHe3p9bXFeNTpD+rF/GQ8urdfLqr63IXz
hydTXVdwsrtb0xkURT0B3ROgdkblzhTX+lDN1bYcDc4+NhwCVHKcbUpdZQIqwrpWvbWNtWGx
Mwdd65PDo4uPZLVCAkEgiKg2viatSddZrqhcIHSErqRQWs0z6JSkCFSlqI8V6JxUiXpB1EWq
gEBqJaQATaCVVkorxTelUxkT1MHE9YfJHecXLo6Lz0SYhtYTfEnXPP7Kh0W1Qdggw5arXWll
Lvu0zUBPBOQOz/rjmVy7ifemI5pPAjfapH4wxQzT8Ado3If4EACGBeadqtSZOVoliSQSkAKN
GVUCtKprCZQLnWc6V6LUeqKyewsqujmNpubI13g8ff6Va7u7x+Vsuhif5BJNglytFCJKiQCa
FpNyvsgkAEC327s9mkvS+Zkz+mQ+Gy2qtf7aFr5+Yz4t9Uo/g7q+uFmsbXQrTYWozw5LodWt
k/mXD/uqgidAnBngTAmodQcAM7mzu786nw2f2Kjd52MZLnygNsssiLwAu3cB2qdItwjDTdrg
AiMOOG64ND3XCHZh83KUHQkqrg5yRQ0pcKjToWd8i/yTJrtnpZtFEgnd6CMAEZpq5d0A6D13
fmWwmgRx7DuvGZlkMURLOgoytGWw8c+QfYr/s4RXeLXGcn8/dgqmEzM1I2MuAslxxVjXwRAR
CAA+RyiBWdrJxCSAkq1CGJYDhKDUEHZC7LQfg4W8NE0HnRXDwVOr1aAuD7AQuiaAw4OToV7s
3bnX6eblbLZVgCJSIl/ZWJtCF3CW5XlPjc/X8xMYPJjgoNx/ZLDodbtrq9snew9mC9ld2Vgb
v97Pu5319b37D6qjneONyxtFN9dCIA77vZ15rUnPRifl9EQWfU2lgFpAjVoJ0EIQkepIqICE
EAIhE1IhapELqTErZJaDyBTkGokASWsCFEIgaF0uMJMgJJICUmBPwzkMYyyLIrQ3Fx7F3Dma
Iyf8EhWHS75kyXGVCqExFYkvxZRnWxpeEKcxxPEQrB3WOMDv/45Er2lau6NHaPOwmQyc5tsH
Yc154BtbEZwpG+e45zq2WfQfK3Kp3oSAicLxPBdokqYDIKIQmsypKEK/+6uAiKqapBSktapq
TahJC4G6JiGyB7duPri33x8OUYiqVtJksRaoFBHpfgay182yjgYATQuiTr/74M7uiigECQWw
O5G7J53RYlHVIlvgybjuDvM1BKFgOq0Wc3jtaHgIAxIgBGkNikgpMjmKiaCsZaZwyPT0mCaI
kZzRwdGeyg2xooyY7JRTMseexXhRgy19ec5HEKwqaw0H3gWhN9Z6I3wgmnSuckUNhQbj/bdW
gUT8jptmp2wYWuamGf+KdL6lVyPsyFdD9jf52FtA/zFFsK9cPaLUYAhCjjMM/6RVuHo14s0i
vxjukDGOWBGP1QAAu+o5cjGo1l6kNrWbBEHk9jh4X2EwaCkYHCtlQY8uy41hs5Yt+MaMdsZk
u/WC81EQMOxo8CcpCADjcz0IQNnVbLSKdDC8Uszub52/AFJmEqobL6x1V4crQzy8P6TJWAoN
stZVfTLPsgylHs3p7tHk7Eq5OjhznG/uyOnh5Npo55ror2XD9RGoTTzqd2i0WIxL6sh8//aN
fDUXgy2JlOcZQl0rtZjPxuPZ+tlhjVJKKYsCqlIrXeQd3all1qmyQolcCEkoAFGjFAjm8wUE
KBEyJFF0EKVEKRFEp095l+oFoHDpiuyUthnSLeTl3SheYp1u+kS4jHiD5w68vu/Rh1p5vSJd
C7GuYaWGM6laJFMMT1IoODMxKpZWJAJtvikMAOyD3ElhTLEZMQQE+4EJ+0fYTkMCHjSNEwFW
GkEKIhRIuZ6Brgm6RNTTBwjlw/16OlOlFn1UK1BTpguhukKrrJAogEATKV3L7mD76ur86Kg6
OcIsr6oqQ9Hp5AtVSgBp0v0sZtBfkd2sOtrrDVbXBycZaC2yidI1ZK8fdW7sqLW+HPZEJkUh
CbQWAk7mUGtxojoI1QBI5tlaB1YKQqBZBYLssWutyH4BnZI5M3cUM1IiAFIKAF24h5XxfE4Z
q/VarCUVjIs5HuCTI/OZ8pMbEXIikPzMBXpgsYBOnae4eiQq21m1u0vEGDluBAz+doafNuh5
c/PyOMO4yrKmvHwyf6GNGPW82ExmfJSE5dfFuLGkYc7/EyiQl8BQhq8g4EcZli1XDNLST2Us
0potpCcmEoJphxj8HKLbYLAdagKEcBRSM8pyqnfidiWLAi/mIB4FgD+MnwCTAKWBMAMQ087m
or8p9c26WgjZU5UGFHIxWe2q/gBn+YXJ0Uzqnf2D6era6iCXJ5N6nq13Lj+8QDWsT6Q+3Nmb
7Z/MhyurQuL8+HAdjw/ySxvZmeOd62v94aySiFLIbDGdVGW1JvOaZlVdzWfT6XyxBpnJRIoI
WpMAQqrrsso7la7Kolci1BLqDMoc1ULPBHW0qoWuMlErqKlaKJ0D1SgIdY1IiAhImjTY26CC
gEVTKzoslq3MCaFRvCJiXJEtFyco7WPPcSJajiSNmywOFoZKaQV4c53N1yB2H9ge+MiR9lox
lhqbhUw2UvzT5+jjqwgM4/ONaJdUwh19ISGQEAaZEqA7uerSriY8wUGOVGCpkXKgjqCacLOj
ilrtkBjI+uqg+sougD3pSqqsx+Wks75dLeaImAlBAolIoIm9NTG4WpHWSoOkQS87rPThtCyP
J1ub22QAE6gBD6aUQTXMM20+ByhoUgulhZ4ez2udD/q6m9UoJdbDQvekypGEVGWtiy4B+zg6
owSwamjMwUlr0O7TYaZ80J4dJ7c8jM0CT3zAmnPsgQKFxhPnLwFEKELrJv2H1aW4caFY1BIA
JMKXT75/RuGNV8vsXfuRIgqQu790G2m29OboLBV4hjXG7jL3IuYAXGFknN7hPnDMsG5ZJkiK
lgA2BXT0ky1n1jal5RJkcO4dH8rjg7bGT7JA3WwkjL9FHEZgEy8VoObrXrNHZEvHWhdrjm/k
vznnQnccjkfEmXFwZZzhhrKHejPCBdY1IqrRUVWVoHRPV0VVlieLe7N6BjXWlSJ9+ezGhfNn
9dH9SU4FKpRiWqrRSGVignW1srJaVhUQrHfkVn/19rS8c6yGIMZzpSpVYQVUKKUmk9GwD5mQ
6ytDQDE92BVXLqBQpEqtKyKlSRNRrc3UCK1BE9QkNAgNGYEEzIpMKo1aS5B5BthTcymEsbek
rgG0FJnWQFoLMvnEvWob8Mi1zlSRYuuYT01DmPm3XnNlznW/8JEt/4Z+3TKr7AhI5CRki8XX
xbQx+3ci5+IYEGziwZbx7j+2EyY4ruL+ACLXf0r2ln4Dgm3SIwQgqAlyKTZ7VKkaAQ7ncnWw
JiUJDUQ0zc7lNL0xHaOqL/fqnUVxZ5Stiumk7twZF1JCJgRpLQBRYq4UkpJS2EWFAoA0AWki
JE1Y1lppUFoLEEJKrAEQNUFVVyRzBagRZSY04N1xNcjExbIGyEyaxZ1jtch6MOjUoEnDcSWG
JU51XqusC7WQWCpczXBopp/pu46VRodyAIC0dh/YoiDvLeguIjlYyYyLeN2ABT2np0SjCfVz
Yr5tSQIqVZYAtcwA9QJogboEVACEugaQhAVgXxdnPbDNLR/GFNEN04suQw5oZRNZnuSVqdCY
d2SewvbbHqdM1eDE8XAmGpzG4Cgv3iJOJTARDwakyL8V9RWdHG62k0BMEZTNXiMuQW7vigc8
kvVS2GXjhuiiepsBJWxG2ocayoQSXsxQ/DAWdLHUQ2iQhgcMIOUvCWOMuHGgaf93C2EwhcOB
m43m5fqDrwzEzdEcD6b3j2fqkVW5Usx3FsUbe9OiWwip8jwfFtmFLi12bp8d4n4vB62nx0eH
x9MzPZJr5+rpZHF4s6Dy/Nr6vQP94HC0siLPDMX9o0JK0e3mdY11VdeKSGspRSZktygk0sn+
bjkve52egkwTKQAUpEAiZgRYayEBgFCSJkCBWqISoAUoVVdSqBpUl0o516gVCCGlBFmAnoPN
OE586Gipm8B/qtSRKV8cnj/zvCQWreFAZSDpRPNK4zYaMhCSl6mY8f8wTSp0BMyPFAueICHD
mm3v0fK+BumZOHa352T+CEDhehJpj0Yst3x7idOez5jAWSsaRU7guJSLShUSZjX1QaKQArXN
YIRgPv6nCKREDSQQa4IFCkSNAklrENDJcpnpGREKYRgAaY3u4IsUolJY1QBIUgAgnpwsqMjA
BAeRjb0EQCnRapZCVqq2/Ezhnb3pxuUVzHOhaoGQISFCJs2H0rFUuNC00Ah2z8TvscdsHRyt
kUYiUFqbbBpEIstcOa7pNBRqpgfEM+dYQEQzfKZQ1g+QjpFK0HMJFYAGpV2iRysBUfmGurrY
JsiAfH5tdJ60qAty+5Vs3O5NsGsa2o2nnHjpeQYf+Tc803OqY3BhRd2xOl6Bj0S/sS0tMBEg
ECM0wMNBgLQc83U22XhjgsDuIDdlNWH0xvvkGHNRYSTEoFrSW9tjajxqQqzjlikqG9TX1va5
OhzHKQXcIFMfvEaDPnCZ4ZgQMLLCo+Nz7l8EgOwLt6sr68VjG+N+V4xmvc2hEkQ3T7DoYGdl
dW3YA6XOFqVA8fL9Y6jVhfWtSblYLUhNjuuTk2KwMdrf6+h5r9u5srVZ0KLuw0pn9d5JfXvn
aG9UQmcwmJbFoJN18iFkdUeTqEDAxmqv1+vu7J+cHB51zm6iqAWVGWhFtapKUAukTECdYQWg
BVYASlCNoIlqAAJQiABKLRSJuqLJoVjbRl1RXSIKEAKUEqDdBoz5zzMACl5BS/Z8ydi4g9R8
8dsOnDWgFWqRdUvWc+1tcPsNDTNLGDcRNvFd5+xdg+OnF5tiLgpbCJo1Fc6Hxg2ar9C6+ECg
6JOPkDpgPZ2Dq2UuE/fhN2uDueYUZCDQBCiBhFgogVBLiYgAWqEUZlPT9msSWRAAaSDURJrs
4WspRVVrIUWpawKS9su2RIapkjkdgJo0kEAiTTYDfLcjFSLaRItEZpcOEQi00kCkUe6cqMcu
CQASAhEx17qoSqF1txCbeb1eqAdzrZVGpI1OPat0R2SKSIMmHVISAKImf5QGPCZJawAthADS
QNqyJVWDAyNWRplCRQQYPUTwgekRG2Y6GCJKSQ9A7wNKQELSIAQQgVagiIh0DaRB1UJQJQSK
AmV2rLIVjYJLLHIQpQKLWwoBiGD4tDHXqA1DiSFfe6xgcynIUROrS4l8pPhxeMX0NlwmUhK+
jz6DSngSyQPWKYZ/GvhIhbi9WCZBX89LMK4qxEXSMTUbbuvPxVYQH070P38bWFEo7hWllo5i
SIEikcXNyXQESRNuWIzu25lPNt2/84X72Y2B+NDTWxsd3Rfzr96nDKgjRJbRaG/nwlo3R8xE
mRed1XNbJ7Pj2aLaPjfoVPN6KlbXVs4VQuvhfP/+fDoaDvM6XzlajPJeLzvziDh5cVhQB3sl
5p08U5itr23OHtxaWd88mFYnFeRFZ3q8T2fWgRSAFoIAdCb//8T9Z6xtWZoYhn1hrR1Ouvne
l+tV6q6qjuzp4QzJIYdhSEmwHEgCEgnKtiDaAgT+EExbli04AJYhGAIhWzAhAbLMH5JtwIAJ
yqRpkRTTDDlkD4dD9nTurlwv33fTSTustb7v84994n23uslf3qi675x91l57hS+nhd6RIRMx
IiN5wAxJDZkoA3TsvAAaZQJxr5/HRtrxdLh/y7sMCUEiWLagvwQm3SKup49LUr8tUy3xbctL
tGFEX15dz5sxdkuPx/VNXPi7cfHY2la+7m+hD68p9qrJZsG5La65uo/rv2uuZauRw6s/3yC+
r3lexx3RMYE5WiKP6jIQcc0+XzFLLmLul9MEAFtobOswKVwuFgACA2B31jABIyAzgmrH1aDz
VjlDt+yaECEBEJF3zMwSmy51AYk1RbPUnahindqmujT9mKmaVwOBhTZuvdzXEQ1MzFSFyKsY
ESGThdhxiMuKJ1UxGlWZd8NBhqC1QMHUGF6oL4IRoWckJCDzDEU3HyAkICJT0SSSkvcOiAwJ
ic3MUgRVMEFYhrelZMyLY1pwcXLzliyPaEvn9hIy8dVdeCVxeEHq2GpMLYRGY9TYiKgoxwAp
oBqmBFUtSbDfYwXcKVSSAibvfyMvBnbyc8r54kBNgE2St0HgbEOlWeU12wIGt2nSBlF6ldvB
+rnrv+Cyr/WDKyTC612s4HDpSVzd3vLZwGZX1/jNYvTXlcNVI7NrM7024FcfvPEbbs34FQqy
OEDmumL3KpXHreduWPHNRTNYajI3dHvtz9YrNge+xaDXy3yDinbdYPuzr83mW2Ger5iwEcDl
3l3NZ8dvvHUeshjDW3fkVl++ezF4PMc7u+XerhtLBj0H1cWX7+T57iDM9XCmJpL3R8f5gKYv
X1L/qM+o7RUdjEg0Xh0UNm3qePYoJqO8RzLN0/QgdzPqx5BEbXBw3JuF6WRaJZ2dn8Nbbxn5
BWWjiOyYnRoikoEhEXa+KxUEBE2AhpY8JZuP68nVxflFORjsvvk2MoHP0cC6cHk1Xjy5KZss
SQGu5YilyNSNYMW6utbX3V0b+7jqb0GUcX1rDcCd4GBbDTYfXrZZCxub1OkmRHjlFYt3wCo4
+xrI2PIZM7v2+8LRQs4hksVUP/nw5ZMndTY6vnXc75U7owHiIoJzma7RMdcFkOL2K7q7CKBb
AutNM+i8PoZqqEZAqkAJOAAZUg4KYIWDeZJpA4cFFR6bCLMaRJWYgFBVM0JdKItK3J2lYZ2O
0fXfFQVWNcSu3r41MRK6zh2jZozQheiz92leI4KptgnGjR/tIDPWVZvt7HGvcBpdaiDorJ6r
pDoiEU2Ik9FoSIcXl5D3zezJJ59dnl/VdeNT+8UDY+8xy7no+/4QD+6xzyQmNe0UPovJHBM6
jQkIybkVMV3v9BLAcFNvwBsAaiV5df8R4dXH37t49mHVQu6dY2ySibKZ81nWK0jAAKHsubJE
Q/LOMSUVTFHB5k6jUQZqG5TOVirLmiau8naWkLz80bbgdOvfjbyfbTZwLSUKl1i5oqmrTuxV
uojr/18pALhN9V9hPq+ytI3Wi0mgbTVbqY1LlfQ6V77W9cZIXhV28ZVBLmcJ1/StbV6EaHpD
d9stt7jzNRPv1r0b6dzqPm7SqVdWbuvzT0X8n3Jt8mpcAtOmnWgNVwgGzpW73zg57Of4MpY7
Hh7z23vF7Kv4ODen/gT3j3nepjgtHZ/NmjR5dDIqFGjeyG4ZU9u8mMPoeNBWF0ejYoAQ5nPv
XEMl4kQ4YwSUcDzKpE1n4+altXdvD7WLYWbX1Riv59N2XhVZjhbZMGpUiQiBzTmKpEwgYAIg
DCEhkEYARBBTY0fOZG932O9nFiqQQG1FzGakICYJwcgMaMW+1uuO6+VZ4QxuoNbCJ7LCh83M
yo192eCLiBsWwnXbbc5layTb2Njl9lznVZ8ruKwY77pP2+jXtjtc9r8S0wzXfgAAABt/9qE0
8zvHvnr646vPrj6q/YvHj/q94hd/9y/0+n0wJVyC7vKia1LW6rLlsm7cX0xs05mjpmAG6AgY
0ii3gV5RhMaOAXnQPifT1/s6ZzsTt+tTfygfn0sG6a2BPLoENEYEJFSDGGIxsC4TmtAMCMkQ
kTrV28xEiLBLMquq1o/Kha5nQNRlx5uJghkSqigyVslpcqYpijXTsV6e3xq0bwxbF8QRNIZ7
niaNAjsw0wt6efUiUPlk5odcP7tUI7eX6+VFEDEAJU2alXY0vvXgXr8/MANA0hAtRvUOACBF
8B42jpuCpQPyGgFAAENbbsQqunphQtzad7TQpBiViPt9l2XUB9QknOXoc+fADJOSARpgEAXJ
Sgc7ZSPCk1SwdaEvK5Be7eGKDNs6+O5GCvoqE9iCkRtbbaU1Lb9uS1wbCtdGIOCq9h/atSVb
v2QDd1eohmuE2Wy4ge0LTqjXjsm5NvTrKPBTyPY2cV/KA7ha15XE0g1DV8/czN62ePHNr70x
wGLj303+dBML36ZEqzXCjb34qUqWbXR+zXTzCkm9/nkJbFtjUQMA9879/fHLJ//we4+Ob929
//aDp5e1vfWuuP5u/WmVxjt+UBzv98fTdq7Dgh3iTmFV0Fv7Lid5oVxkJCkouSY2j14+e3A0
RHHz+RRicidD4ks0OL2Yuywf616rdhiSAtZ1awbeuSRqoZnOZsXenpoCkiQRNTMT7XJXCZAV
kIgUMuJk6JzLYoyCnoiKoiiKcrh3yM6xzwwRdVFBQkVpUQB8EatDyyxj3eDpm7ux8Rc2KP1q
zRbhxrDRZvk4rnB42+h3Daxe4UwrdWbLqbDVYBP1XuUW17AP1mHW9irMXTv9EAEQUWOc/Pgf
37nX13gc835WVFjBsF+wcx9/+NFXvvZe1ymtVmS9OJ+Lo3Z92q8Gr6EBDDItUJg0iUMiZUYB
Aajdvid41l7WrSGmRvh5RVFBAOcJxUCSmBkBgGkIqSR0mUMDMzMTXATmm3XeLE1+Z18U0CQb
7CAxIiwsjQZG2HEyMwUlQwXgVigkZlZElGoOsd3blZN+CsoiFM0RYpEhIHhGBBPAWYr3+rJX
2vMJTNokvXzuslaiqRIYRpy/OEOi+6/dZZ8h5SoRACREUGHvyDuAzq1HKw/YNYTuIo9Wh490
OtiG7NVdugzfMvDAnnJPZQGiSUVFkYkFWdpkaqIqSSxWKqHcHRkDkIFZUPbdkmwQ+iVv2GA8
m1rZFqAt/t1M6roOK5uAvSZhN3V4jVF1+LbVo4HBZu0yWAHoFpZ3eLbyyW60237tepK2/Ipw
AwhvPXhDoNyNLbdvrHB3A//R9HOxa8nurtmEPlf1W/y8LT2v/WywpmVb/sbrXdkrH7r1XDxs
G9rj57Cxaxtzbfe7a2XSufnRBT1evck9v6zKYme39+zs+ZPqZBijbz/9Xnv3YdxFOX8+OPte
TkMMc3F8u5eZAYLmmGKIFWh/tD8a3a7rpp8N44vp4O4barPm9HR34JXoxfMnISZJOGAllLqN
bdLJeFa1MKnmMaQ8zz1jSLGaNwlY1RlxI5ApqyIBkZFDZoeEHcp2MYcYwRDMYRS26bwx8wfz
atDZYlwGJpaSqpoJLagUQOecWjIK7lZxWeNhafRYWtWWlt1rlW+2BN6Nld02Qryy9LgZinF9
e3D1d/uXrR28CR7wps+viuqvtFwD0SIoAxXAykHZup3Zufjce4cpSd1Gb9Y0NYHZ6kgDvDbR
G9iubdxeMa0buDIQgGVkTUSkbNrATtnDrMQqMZKRU3K14DTCXmat0lmgHGI0fNE4SI2pErKp
EeLuwZ4vcgQzFQQG6MIOoWNmqqCq5B1KAlNw3AWkMKKaxSTcCeuI0MU6mZouvKRM0B/0UNoQ
wzy584bn0T25DGUBLvM5m3dcK8Qg3hOTZWwqFgSmrRz5vM5LKhIahiAqiYnOzs9m8+rhw/v7
t04QCo3JYkRjLgtkWtrkFJGu0RBc6hereA1YMbCOkCy2Yb0jqGCAoiABmtbMQBQIpammvk8I
SAToHYBWs3mMNhypX1F4NbP1sSoGN7Cp5b5v8wJAXOtqW1xghQdLIvSKJHYDAmwAThccdT0n
27bbX4O1Jb9bEfuNVbrGNjc+r6np2iq4behbg/n2q165lq/fptZrXrPq5hpN2RrSDe9Zxx5v
zABfbbf+tMV/NgnFOgZ/OftrrHx7MMs5LO/iTQTgZ183sMPrkgQArPw4N/bvOO+VA3/nrfd2
W8hKf7RXDmDmzj/IYzNTX7WU0RydY1sWUEAGwnGikdfxeBbqhkDI0x4jpyuN7WA4eHE1GVK7
u+d3c+gX+fNnuFcmkJbZT+rYREBIORn7bLeXh+ismeaUhM1IPapnaTSZRrRA4FkTaTCLaGSW
ENAsmSmoqiRAME1RWgBFCxBqY9/xHdPU4d0iRgOXq/GKDQJWsVwAtmEy3zQ7b4g61874wg1+
tlaPr/28BoHrwTP/TNeSQW7J2NcadN3fdPMGVke40EQRgRhBoa0TFw6XMQIIQJ3tbWk7uk6/
tswja6pwQ2T1Egdxqx81g4uWcyAVEzMwZVSHqtSVw5eMjBeV8IHJwIzAMiIBRQUg7nxXhXee
MUGX7Q6ghghoXeQIGgBLm1urSIZgpgjIhIxopqraFZTqkgu9p06m6SaHppcX451hlvd64CyA
gKME0TEwmRiogkiXgIHSGQnMklRmmhFojFEikmPHiwg+g4vLcVEWR/fuWeq8r6RJNSV2rpvn
ktau/PYLwWYVd7QBtYuVXpwwtiE5LKimYohgYNrTPHdiLlYVkHrnJEUDTtGaFtrIsQ1JTIwB
Ac3YtItz2ZJWVqR4a4OvgdyaFuNyHLghqK9ZxKrg0MqY9PmIsdQX1qGJN3nxb1ZAlpro5jQ2
P2yRz02U2cwAW01/gxP8jIiENZ5s9rBgHrpGiSU33xwjbndzA0OGjaa2TAbbeK2tFg1Xv77S
zSZVWW7O2lYLsJI/cEO36u5vEriV0rs0AqwX7tqFG6v4z0QGN0SkxUWERF2FG1dVc3M74Idc
vWwmU+Psh0+fNuZ7jnaPj37rtBp5O+nL/t7og0dXKaaT4/2qSUR1ZOPZhAuOCebS5EP/3Z98
+M7rJ20Dt/sGys/Pnt3ZKxigLDLvNEMqGMFxnMVBj01UNBUsc5N6PnVo6NgQmLBwCHlm3rMx
sENmQIdsyBmoAvvM+yCI7Ckry+EohZCXfULKfO7zQmI0FQQDVQTrsgCX8IObJW9uOGlyVazA
NsOK1pDcbajoMoZuY0e3qPZ2QBgCwla8xE1I9jPY0k/Xq9aItQlWKyvouszggm8hojFCMkAE
R13mkzrCZi4df29jNNMYclNZxFhvD9A2XOO2tUDbo1wB8nLFNvFIAQkNCZwAARAtaB3RInje
ERoooXpaeC8dioKllKjIwMRE22qe9fLq8sIRgKojIMLMgaYFBdX5hUvDxsr27BnvHOa9UkWI
QM0cwCrKvdPkkiYzNuu+GphJUtF4MbPMjNn1PTpEx5gUyIxIRAENERIDEwOBkiqoGDgil0RD
SGCKhEz0xr3+8ZFk8RMPCRnmM4sNogzc4U5saoitgGNP2WAPgQA6PYywq7hlsDgTG2yDaS2+
rvRcs85WTimZibADNGZIBsxMYpAEJTkxAIIUazTJcu8IaaHfUTQqurCXTaB+RSzfgIUt0rmS
mJeRtjdIVytDNC4Y3M+4tuH/VfR5RWy/oekyEBhsQ2BdkYONb0tWeL3PjV9/+mWwojmf36Db
x43XvILOuLq/2OWNMa9msnxs6xAsBECkZX3IJbvftJ2sKNh2IMcSz1cR14v7tDGyTR65OcfN
bNTPm/xNgsrP2P3FXAhVxGbz2Ysz77G8c8cd9nn/4QNurj6YvmwUS9Tz8/Npa4Neb/f4SHp7
01g/yNrYNjEpZ8XVtD4a5bOsT9yMYDKfSdsAt+P+wRtv3h5JCpnPzy/rPIO6ocKVwdCTIQIR
MRg7ct7n/SE5DAIP7wxne+7Hz0JsGl/0kYAQCdEjEkECIFQmA4tkkTCZBVSKFkGjhzZYzFCA
rJlNLbUIqghApKooKkm7IHS8xqjWwQNbdntcioiAq8I525uwEkjWrGulSy+BtQtyM1u7s23B
CU3XdYA2w/VxKZ2aGW7YNz+Pma0waOs+vioJrlgX0EKXsiWHMEIwMAcAiApGTAggokXBMwIA
KzLnvBM1NaUVZ96mBN1arsnGisFt0rgNAdc27iCAghESIogimKqKIQPEhdGRnaMu7JSImUjF
gBiJAAwlJQ+YkjjPV6fnV1fTvMjBNIoyEeEiXaF7nygAgCpUs2lRDouyQDBPCGaEhrgQcfLM
lRlP2rbbQTUjhF6Zq0RNSYSiYRSLYmK2gyigDICASoCwKEzFCK8zHDm6jeZUHWlDYKqAikCc
4mt7PuPZ/KOXFhMJP5m6nZ5x6/Q5vHj5IuuVWZGXezu8+8vQXNDkY3QluNzQATpAZ+SM/OJY
BiIDWh3evtQZF5ujat6jc0pEziNnmAIYqKloagnAzCQSIxqBgIguEhYQjFGvVai7Dm+bm7q5
5de/fQ797jBoLRFtvcW2P7+KidtQdkPftv1148ua/+F1XFq5rq6HqW/3+zm/vjrCDXnXukog
m7xn/cxmBOYWe95wK3X8FrZWdqW5bZCjxVOIEqR9/JPhaw+Fsk251rbWZ4mKNwglZltrf11w
+DwOjutO119/lmzyU1YbkNhMU9vUv/1DO784n0x3yHb+4C8lx46JKbZVI1/5pT+Qe7v88Ed7
t+72r14OT+55hvvHR9n0ec8HIV8W2rQp946JfZyM8vT9MDgf128eF0e3dgCxSene/ujx1PIy
z1BG/bxVEkv9HBl0l6UcDOeUz+e1gTlUNSOfDwvxOgnzaV54BFRJDLGJgXOHKmwJDNCSydKH
YkCLAnFk4ETC9PIK0G6/9w4Ra1sBEhoAOV0Ij7rShpdq1cZqLllQx1YW1hkz081K4LaUUTb8
vSuIWSVC2RoZCbvC7Z2qgauWAJ1fANS6oq5oaKrW3Wrnk3y0uwDadWcGC6sRrpjs1i5vw+7G
nDa5SSebgy2OWl5gIcGGPGZKuJgkgoWQkEhVVRWvp4kZLB/rMGK1JhuekkXLVQT0FkFBQIAu
xB0JQc17ZEtOmxZUjTjNyao9L7nhZaWMeuDlHAHBBk4sZwHJiDTFzJEZtFFcQYtiuQCiEJLJ
QlxAVTFV55CJoJOkCAEMCcxQRdUMTG/tD4vcX00r6xLFAIkAVJmWGwyLHtWsETMwMiNmNQBT
pIWJ80r0LFkfDMAkysJ6iciIvX7WfvLy/PmFATqEgunwC7eHtw5Mo01Cf3/oM1/0vKFMPv1B
hk18/Klx5nJHjoiAvOPMITE5j8wAKNle6N1d1cWwDUnaOpWNSA1TsrYlAwitRRGL4+58bVEj
S70CZrWZGYGBCnQHDCxk+ZVcd52NbXzf2PKfQq7slV83QPfzbi/Z3DW0W5N1uPnOlvKC26Pb
AMTtES7TBLd7vTbhV0mtbQ5g0WKbw3UZGtenv3BMYLfUax62HOtClbGV9fgVTryySm5PhAir
qrLqJeNrsuK3tnzHBhO/xsxwdds2XrBstEWAXq1+tzSqbPJU216TG8xdm8SYEJFMZPUUErbz
OcZ4dXpBjx6fo2uTZDu9i6cvRnt7ToDzeLXbU778iYSUod073v9senZ5+nRn+LafPuun84gk
Lv/Jk6vbIz25f+cnH6a7/fl+zgAuJGnEJi0SJnI9NQshpcSzkHwORcYJ/WTGmaU8BwfRg2YM
YOoIwEFQmlWmotV0Ojg4dkzEDjlDDsSZkRg45zOjDMyMvKE4ZnWeMCkSsFNRUyuyzJFzPiv6
g7ZqQBMgmMkiAXjFfdZbs0aZlTa0FG5sDRod5+sCPjomthJ4loazriPVDkSWULEZcdvBQfcZ
sXsBbcbRd8nOtMj5XVk3loaVBUYts0Y3NhthVcdjU7vE9a+bMLIxIgPpDtNCQANCQEQkBLAU
QicMpqRZdw6eiS2M8htBLBtCW5dfvFTCupEjdlUHzdCsY2G4yQOXrDhzmGMqMiCgDCpu5jXs
AwLGOQKxaYEAZk7lFtQ9r34SylDXiXt9cxTMW8N860STqc+aKSERtFFFDVhDDlcNTtvFeX6E
aGC0KCmCTCQGUYEMREDVxtNaAUzNANXAxMA0qRCtkNqCJFEwsdBF7aqidQnVYEthp2KaIFwK
F4VXoEFhbz3Iyl6GIC43e/9y9gyRCBnIY6YhThoiw9wdDA6ZEQjNrLTzyfPz9vFVUGYCBWQG
BWMi9GzOswND6N17jd+4e2MAKC4pEJJNZxGhdd6lBCoapSYwAFNgAOiV7nCPGFWMl88BISos
YjcX4L8tl2yi0PraCEy8gYXdNM4VTG0ziwUdtHUdmhXsbTjMVo2X5HXV6sa/cOOoXhnjKj1k
a8awwp/Nyaw/b01rk2yvEaMb9rIY88az6ynDxiteedH606aIuv1uBEOE2FT9PFNyaArW5bfY
K2FXtrk4r75tJZlsignXt++m0a2knRXJ2ubM3c4uAoMBEJ0zM6nqMJ2V+7tEbGaIKCF9+lvf
23/7tdmHn9KsSrWMhiwWKdRm5hD12ccfzi4uRNPDN26Vg6OM8HxcpdDQ3cNUHiagojfEZK/d
P7n98NbV2Tlb848+nXvsvXvMGbqdQX+3oB5FZK6aMCocOahRGk1VEznzgKyKDtEzS1z4IhxC
XFRbQEKoZ3OkhXG/YzkOpVEBi2YJlUyNFJIEiZJioxJIW69N7t3+raO9WwfSTEG1o7zMZGYg
CVWX9ecQNsn7dgrkcumXQcHL1UeAzYSKBeFdh2KthAxb6kYA3SO2lKTWdAXNDDpuuE7YWbxt
GSnahV7TCt432NVKLdwAh67HjsTY6piiFXAs+1jVv4AtpLeFTRUAjBDCfCpV6JeenAOIwGzk
IFS0nNXab7cE824RO4MTMZmBJOlSg6urC48KzpMvfZGDSbc7pgLskLiD7mFmlkyU5gFKV5b9
PZi1ppb8yPV7Z08enbe829butNIqjNDMIE7mGeIDQotABHPHb47YZQxO4AAB1Qw1qWlLZH/7
kf/OTKICggIBAoEK02K/hl5PdqXncMDz3QPyVFzWCoYqEGNKSUzEBIAAAUUhxQTA/cJnDjyh
GCZBMDWgtHSFLoVPmM/r80kzGvUPd3hXZ+2LmNpYzRNO6giWomSKBXP94fmFTHMHhmSA3mME
KnNUn7kws057wqUA0KnOTUqaAKEOyY2acrkVC9iWCOyAnAEhkZrulJknnldpNo1Fgd5jUThT
qtoAho7MZvUUabTfW2bxAYKl+YRcL8Voj79jg30+eoMkEoIRb9Krz5Ol17xtk6JtNXn12gpv
6vgHrhBhLZDbOrlxTb67GNMbZPubXr2UZxf3t/jm8outkNw2f7xmNtxmrFu3bbPz9SsW8t3G
iFYSwHX+98qXJUG4OT5/hZdoACmScwbUca/lY7pwNyLARqja5qDh+pps78jPvnALGsHWD27o
ZGAd2UQAlJTio8fNjz+5en52693X6eTAxAiBCGfjSV74xz/8cHhxph4Gx3vZ0d7u4WH/5Dgh
OAAY7e+d0FWeDw/v7V9Mklj25q1+tFFq5i/rk76zUW4XiUpomrNxinKyU5xX8bJ1u46/fi9v
tFXsMWI9nh7s7cyupJk1BUM/5zz3zlEK0gphDFq7ufmYxLsQEYwcAnh2VQIezzTMDVhjAxol
1SYMlnhRoVeRKWNWR847iR4wMHsknNVt9P3d+VzRI8XYtqKqasvgQlvGH+tGcj7aNqyu5YHN
21vBqOsAu2viYQd6uDx22QBsUeFwqW4B2Io5dX3TgvBvoJ6ZWjufUF6Q4yXULPjMOmp0U/G2
lTmxewsa2vLYkE3BR9cTWoLmGoSWvmNVa6bj49dfz3x2dXplZoCYFYWLEzQl0KVAuo5ss4X9
E9lxXbcvX56fnY1n8xoBiHl+dflwoPsDzorClZmlhKbzmJzPy7d+BzCDqamNo+PEIqBgSRAQ
HFrOnaMUiVCAHADGBGaqAISGKIvwQlTBBNCcR7fr46BoIrWcn8DYpgmCJYejBF8ewD5qr65q
6Hcnc3fZXUnhbh++cdJq7vgAfVaC0elp+uzU7Q/gzYNQONsr6Mt3XJSUZ36vl/YPDgqPo/0j
7fVodibiU9JHn5yFqKZdSSdMnBwYE87n7WQeYtJ8bgcfnEURAFCDncKVntFDzsiERDjihTFZ
TSlCUkgBgoZBFg1cd95CV2BGu6w7QEVQAmQGgM1T+xCUpdV2igBUDAwoCRwOKXN0OCzm2ss4
d+yYuWn1cjyrm+n+iNKl7o+8z1oAA3SEYHW4uni/2LvM0himT5yMQ1Pl6TIf5mn4eixO0NIS
cT43zwlhcVYcgimibbDG7VZbEUG2LumypOrryIbNV60ZBC7B+ibesk1wt8MIt0pwL5STjd+X
b1tbVPDVikU3X0t021SOth/EhfiJrxgUt69NZF1PfN3b8t8u5Ma0O4RVUYMvCjC4gfcimoiZ
keMlTgNsOgKX/a6WBdbS9tYcN4V4uCm53tZLsRr4kmQRpBDjvMI2NL/xT55NIuR8lVIeEjtO
KRlSFpo7HG89OMTDIivL/MtfTqrQhKTK0jpV2ynk6K0H7LnFwvvELb73tS9/+/sfnl5Vewf4
FPYPzXq5e3FZX56PH+7lZwkOh8XxyGrLDB2TBUXv6PV7J2agF2MzBUtRpG4iOpoFaKrmaNd5
7+M8tWJZTLXFZOL71Cs8IoT5BIDAFUSMLndZSb5HDMw5+oguB0VkT2jEnpwQogAbAAEpMroM
kNh5X/RlPkcQUNngYYAblrWNAKnOGr2plNhGrM1adloj01LAXlX2IwDcOpjINg0pa3axvaWr
Ple5l0jQjM9dr1/u7IFId2+BoAt53jZtlavOEVYTWHpaETfAaKGzLf8CYBePbl1AZoc8imzk
VVEkeTJCAFMTBVNTMaXVzLohLQ2l2DThydOzx4+ftSZm6NFZCgXEwz4d7BUHWarb2fNTAVNz
fqZYODt6/kQMsl6v3DsUIDYBYkZCBCbt3I1myQgJIUMNSdEZEqgAmpgIGJhjU+Wl0gqOklJt
fm75sapVAobU52/sRIymjmhyfgr8lBBMYkj9HPb67mCfq52i7HvLMUqixEj0lS+9sV9Mcxxn
R6+VPv2eu22MWe8AgXPI9uHi+9BGwAo4NtNEWQYISaGXw9EhObY8s7tH/u98Ry5mVnrmUM+a
NDx0RG5R3RGNiTvpo1EBs93OVICGQB0wmZkCVYY9sh5DVwHSALQ7EBCXNmUT0xVFR0C2eiIf
/n2PUZNCPtBaTnJwrGo4nSWlHmZ5UihACdJOSXtlX0PTtAoRQm3AFsUTQuYi9KDE83xg2j/2
uQO9IgLDCDKxWCjntnGi2UrnX0hxCADorc7tDB2DRMV+i3tqaAvjhW4EYW8VtNtMSYQ1J4MN
LFz9eqOGt4Ugr7CzDaK/RAjY1Bfsetttu+hWMNeNbHv7pm7d2Hpmc93WCuuWVrX9z2qyC6Pb
Zj9E8/MrX2RZrzQRAHIWXZan9QHea4nWFomQAsDXMyJe4U+rql6rLV5NZql466tlEXDr29YU
V6tOzp1/9KiaN6PLy1mbROLxTpl7dY7YMaTWRCg2Mq9tOJy/OD9+8/Wz9z/pXV0M3+iNjguU
4MrcfTrzV72jfqjnmudxggRTKb/2xdfb6fjM4n6PIMbxvHr04uqtu3vDfnb+ZHowyEsPFiWE
hMxMyM4xogAQ8XDYd6CsmOW5Yz+ZNVFpXMlOnkyIzIKxw5QjMAJlfGevrNuY2tYXBSIgKKqA
RtPWlCwFdqBJ1GUmAZIziSCBpWJtXZ71rXVuh6xBBdTIqEYEamoCIrDIW+88VrRGgMUxiUgb
a7tkcmhbTrKlQ8tAF6f50dJX1plnl3rJoqsunmsrCnBDKuw4iC2BFRfCDxKXI8ddXeEORG2D
Cy3SQLcQeaWWLUqpLyXUVZg/rDwHKEs7IS2JBy0lKyRWdLNabxEyE1MnZCIyWgQRNbLt2nYL
HslEbRs+++ypIGbDggAc8eU8DHLO0/QM5OM0YuVZbAalC1ERoA46/uj9SZTbRwfv7B8DEqCB
IhGYCaKBiSMjjWk+3h/1hgPSHT+uKkNj56BqsrxIAuQJkoTxTCXRrmcKu7l35gcQGHIZGIQE
KJIU1BC9maakQQiC4qx5cJS988V+VcG45s8eAzWX06v6qoJZawld4WBvoP1nT5MCkRR5AR8l
lw9JTx3MSeqizPIyBwBKYKC5s4L08DDrVr9k+YWTqvfezsuJ1FXaL3r98WyRxGu6gj9TI8/I
KLXBMgoUDAgREBxDHYwRPCGg4iJwDZfnuoCBaU7amY5VCSMjTsaPvI8lMxDNJxdXL+tBQbAH
kBXMxBS8T5Kaqmp6Obs8I18G7lMLdDjisqdJzNQAsyIrmcSsahMSpwh57qo6SZIiPvf0Qnbe
TW60qH28gntMrI2qLE8DDQ1UKqYpxjhGPHW9AbnMcS5uuBGNvQlVGyTvOj/ZIKyrAgPbpBG2
UpuWdsjrTGb5ZttElBtUnwUG2YqAL0sSbzDbzfAHWCE2bKguy3q76znezPW2JoKbX9bjXgnj
iz+2/ExEQPT0u+8//Pn3KPNqyGiYl+AIddXThkvfGYgRdZRqm8GuGgFscNL1xnRFbFbW3M12
uEqnh2Uc3Fo1W/omybCTe1Tg6jKr6vbx00Hm9o52+ncOR++8B0UmIeRkV6cXkyenfDmpXlzt
1NGq70EVHIIdP5DBoJkmFwQ9Qxhfqjau6LfJLIkSeAeT8yYm/tFpY7H9ubf2vnh/33t+cjY/
GPDTq3Y2CcWof3ZZv33kBgMOQT99Ou33ihCC9zidN85nTdOUBez3EKN4NiLnUYAlmmWOdnMS
EURtolzOQzW56I9K0GCxNm3AMkYhTGiR0RErEhIhIDCTGiAz+sx7VzWhns8IkAlUoqqCoRho
JxwuA9YBwVQ2AMlwGUyBS7/8tihkG5Y5ABUj7k6RMgPoTj8k6vpY5DUvgu6SLcMzcLWPANtx
Fa/IUwDk2FQRzBaH227Kesv01Q3xDZcgAUtH3jVRDhC2GB4sayMhIIJ2ihcCGyDiIAew7vCQ
zr9iXaRFUnO2bYwEQ8TZvH7x4mxa1cVuaY6tK96ghlk2baaZAM+TG2pSw5AE1DsCNTBzZpGz
xmUIZmIqllIiJhEEaYtMVSZmqpMptZIjo7NqZ4cHg1InUjmgkVsis3tY5ibkjIssxlCIFghi
fdhDi+It6Z4ak3pQtT3y3zjsOe8aLXplpgFLj+NxnFd2UviL2MwCVm0kqqctTGfo6IKIVQFh
bGoGZ8yYjAHAu5Z9FcWOB/TzO5X3mlQ17pCnTv3YZclKK/vexHu1dmxd6MiS8S83ZXFECy+2
jTruhtaVQIHuY8e21vIDgnXlGT1ZAkF0PPsMw/vKlFvMD3rpMkhS8o4Ysp4TIFBDEESTFMCE
SZltVsHplTs+BlWTaJiDwcLJZwqiYITMtIRDQ1BNMZJTT8uia8vLABnnZ2eXn/7QgLrRqoF3
voP8mFJZOPYTMyuGO71bA4QNwvgKh7Jt1Ni6BYsyd6vrGuNZ2QNv1L5g49aGiWL797UahBsd
Lj/cxHpw81/bGsSiqzVHtk0U3u5sSw2FVYr6gglcq0G3YguACIO9wXc++kTr5u0/9DvBMYGi
zwg3cqVXz3cJ8dzRsoWJB1cdQQelm27u9QLjomqJrdTEFdVZG2WXK0HrH5aadjcdFUkNhpid
XeyA6F4/K5zu9rNkTz54dInPvnD1PGvr+um8zwiEs2m66mWPKsyHu58Ch+9J/K0nCuyapn34
YHh85wSffzgnmzc0uaqMcNZEHmajlH/07ErnV4hHBPH5eXV7vzd0+fzF1e7IsXPj+fx96j0k
PcgVEFR1t19AmIBp4QAJCUCB8jJnhKqN5DyZH5HsFQCg6DNz2XsPq09O66Zu0OWOPXDufAGU
ESekjMij85AQ0BObdRJDBxXGEtvZZOogPWSHBpwVEAFUTNUkgimhrbXVaz7dLlysYwxrgFlK
EQDL8woBAWA2pX7fmgZEICUB4OHQaNnnBt9YBEktdapXUNPWoLLYXF0UVzCLIeaScBkqsora
h83BrxnV6s7qPVvyKi6LhWxOTmHL6NDBKDs0SbTQPQ0RQhtUVU1TiuAyW5xEtZitczip6s8u
L5g8MUBSM0BiAmTUSWpHgxyZ9kquTVLpmZEIFUDFBLRIOpsEBFBVsuCM+i7DENtHEzGOUQhR
E/Ti+DHs91HUpbPYu1+fW0xzLHqYLnFwSy+e9u9BOYjTyHM7nr44S/19nk+1KDmwzy/7t7mE
TJrh5PkYR7s4VSiLcJWKw5Rg+ujUyJ9fxikeWQ3jaStCphKTdExEicwSLPVmJjJDNSXCto3Y
ghhcBpWBaiutIc/BCEWQEqcEUBvnhAQxbZuPYMM2hkhEttCRFRSXAq1tVJVYbpWtt1dkEcMB
XWK+pPj8ch44iVmOuQcDALb7dzySI0dGwAwiUTUiaUqpV7gEMJ8Hix5URSKZqgqaGXYliw2J
QxU6D2teZABGDoiAEcESmILKempGKmqqPncIxghAlAQQQE0dIiIc7gEAiO/cLevq9K9eK7Fv
i75fU6FWLGa1TNdYwQaMLwl+1/jzgju2nsYNi8km69weAKypPi7fsGA2mwIfLGNSr3e3ZBcr
Dvk5zNxWBGHN/lZ/kbGZTPuz6U528sHf+tbD3/kVdg5chiJr6+Va00RQARVg3iwytBgIbvOr
Gya+qSCu42wWM7ZrrTbIL8AiwI2MZ5PTHz92l5MUkjG6ImuuGs34WXt5eXSYGYMOriy0jmXa
xjyfKKYkTZUcaYHONAtt7XzmKVloAlIRmpBb6nutBYcO93s747l84fU7PIYmyQfPJ+XuaDQs
Hj9tezlFMQs2txzEJ3RBww8/vXjvtb1InBv0CweIIaSiKEWTihhYwqQ+E3SIyWe+Dck5EvYC
ru8oNJVJQFCQSBYgVWSNJTBNKC1otGCkSQwJFCVQmhMEz6wxek8UZ2QeQmPaFWnt9AyFzTys
DahZr/lK9LgmIHR3zXQ+Q5Vweg693A+GmGXQLxYVzpfxPOuSOKuubCuK3TagdZMLrbYXCVNS
DmFxZgdgd8jiNtqsIXYDFNf2xWsEcvGsrh19mxAPsMR5pe7weAUUgUVhDmIkErEYE+cr3at7
BA0Weq2YATBTR9YoNHUfIrtk0p1olcg0RvGAmmBRfBlVoxAlMz0csqvQMhYwS9IEQlQS9Tkb
ikJ+YIEkTTEflBlq6WWCEJzpns0QERXRjEzRjJl3rM0YBygerVZr2+gYJLY7ag4jWDTzwDKt
IgQ6AlBDBq2jDQAdqAikpE0Qx0CEGQEvMgtVkoopkKkC4yLXwKGqwfuXPGu5Fryb9ZFQDYcU
dgBzAENS6eRYW+/2eosMukM3kbrjCWyVlwHYxcmogS6OQF3JVEvRputSjR0Bc1G4oOBQEMg5
JifSJpeZShdcswZGNMs8gSlKSIq+N3AOYlBrkmnq8KHLQfQZMnfZFISMyIZiCgq0DlFay/Xd
BzUTFYNgymS2stGZgaGIAog52UBCXNLWNTxv0D/cYjWbFBZgcfbYmr2vqwHgFjdbxiNsouPq
9QtMhc1rA49xo+2aHy5v2QY7gpWmt6qxvGBEuAyssSVHxPWPm6/chpBt9Wy55QgAQFvRWAaI
DNPZ13p52B39xt/6zVC3994+wI5ArfZoSYPQrPOAkKmuln01K1su9YpVwlonWwIgbra+TlWu
T2QFId1uE9TN/O9+ez6tsyybmasVVD3t79RIrY/N42f/xGhwvA9goW0NhIMFMCTOM19XTdNU
/f7A5YXLHXqPVYg6a1tkr0ggbnIxHMZ42YTW2rlvZ/WdW/rw9l7/YL+qZ6Dx1m65w20N8vZB
7jwVDhzSl968zSCG9HLmDgb+YqYPTgZlr2yqOQA4R8IMAESIRJ3L3QAJbRygToASFqcnS0uQ
UMWjmSlDVzOUwZDIoaGj7tBbRmBwfnhwsLs3qKfz/OCWY2QEVVm49xd6zGZpdVsU3Vls51pm
gnVVlU3wNpxfJCzm9aw8OaSd3e4EXtwE3JUjwhZZh0s83gawJQbZEmc6qFiOQUEFrQO4LjMJ
DIE2gGAVyrggHJ20syiQvtDTlsraq/ixArcFGcQNuV4BUzIVU4bFFFQRtEoQoxbW2fwRF2mV
i0O1HGeOM1VNKYHz0aIRFkCEwI4I0QCBCMiRRxUFVWZm9uhSPbtq5rMqUBZxHoC9QqBDnGle
2HA/nl3KrG4uZ/OdIxITrGhfZpdzm7da9riuQ2/UzuburvR7DGVPYgynlfk8NK05nySh49u3
+j7jNAV9/KRXgNVVL9dUh+Ehu16Gj+a5b0PwCiqICiSGZlhHY0FCE9XCgyfyhMlTN31BRAAy
RSIzTIo/GZMaENiRsQPsrLGqoLI4YYSu0aKFxLEk62oL6/OCyGLnMEUAXGZZdaaapSa9DsDr
zt46//gHRTgNKXeDsnDkrTatDQl5IKCmoQu2WRsEAJIamKGCmUuikgxNbGE37kR1BeuiQhAY
liV7wQxUkgHTwhS2do/g4kjSLqPOMk9k2Dbgc5+XJmDOMzNCFzhKXShroliDiRkqZ93wFphl
CiZgSqBgBmaaAjaTLk0NervS2zfON7WTlaJGAOsKSZv0c2VvXIWCYHfwyQ14skafjbiRlUq4
QC/bVlKWXGLJtDfzRzfYwyZ52QrR2KI7G/rKsoMFR7HUTjkrcCN1wYB683mZZ5+djW/l7vZX
39aPf8T9odx9ACltLMHqAQVVUF3IopvW1aWEsOJ2Sxa24XdfDWwl+a+aLNjs9cmsFhTBgsr3
MRuXLoByijNVGM+d47LX4xQhI76a6zSrku7GKIMsCPTB1WaZzwb3DhHZ+wyZXea9Ey0Ixpzv
DPqxamJsM+YfP7749KzeHQ18r0jl0awFlJSuLmfz+vbe8NOz+u6elcwlZVHBUsLST6bjg90S
jNoo51ehVddG8Qrd2X9JrNYEecaoaGLkVYTIGZJzjAgxGnLmHAEyO4+LYrvsvEP2TAZEiGBi
RAjARKSxeXn6UoqRkgsh9ZiNnKIqkoKqGiNQZz/bjJnovF+wmdu+EPpsc6FX8Hd0jxR28hJ7
fYlpsVW2hnqDRXHy5ZdNRWwhWnaydVcmdgWqHWzb4s3c2bg1CWAX+GqIXYbYQm5cvnCZ97sW
eDbgHFeiKWxE965Ach1/vxpjN5eu/IQZEAIRKAET1QYiCqCL6r0rXmsGBjFKlKCmZhZCNDMm
N/Xsil3vECFMk5GhEqkhIAkIpmAJK+AZZzHFJiEBpi4UPKbGUqOU+j2qL1PymdkMssK5UNXn
5+39JjmkGrIeVBc8uC3nLy/nYy4IaTqev1anF3R4HOI4ZR5cXs9fPJnt7pWz55Pb0/Dc3Tmp
q+du91b1/Opsklx2XFnT68vkQnt7waRJMGnMFIioi+RpkgGoy1DNkohDIkJC8EwKwIyi0J3k
LF2UrVqXtIxkRACm3MlHtO15WZqJQRQzotxptbDmLuFpxacWFGIr1LTbOANAQwSN4fn7P76z
GyfzMBw5VxZZjoB9domo1ORifNlBm4ASqQB0Z1V3oOLZQt3GOrJjP1BQSwDOISMY2iKIXxwC
gAoQAqHpMgMdDEwX0McO2JF3xjwKsawaACS1BuB06sdZ2XoPDPkMQTBh5fMP7g+muQZINTOa
kbHDzlAgCmDd0UZdDNdSyenO3jYgwnTGcrvdfRtU1lRyKYQiICIt0zK3CO5iBVfpYiutdklb
N9SuLdTZWP1VKvPyIVz/sqQoi8a42cuKJW3GPa5Z10IkXWGyLdjjuqcu6hjMZDanAaHPlmFo
CKo2nkiRtecXX7t/REe7T77f8POz3Xv3dVmHZTH1TmI2MxFgXS7C1mRtsYyLazm/V2vRbU0T
t3taqfqby9vRDsp8ezhqnl1EVQvBvMPMUxOGpYsxpqKIvhkQYJZFhEFvkPkC8hIvrsgVojCf
zxBsMOi7s6upMyqQUwj1RK+m2jc1x9jrffm9kUf39CyeP3t03Lul4M+DvHN//8l5Or8c43R2
6+6D7z6ZVkZvHg2GBb+cNL3SBYM7I/BcmmoKjaXMO76cxdIjZi6pAiASBsEoMCBVUCIGpDZE
hgCqpLVKNMLOqm5pDpwAuENvFRFFTcFSLe1kMOjXMfmMyALKTGODKSFyh6BUV+Iy6OoDwULl
WStYK9DpTNK6No+BwfIMsAWBh9RCzIBp/WinmeESQZb8wFbi6PqHJVDAgiqtNnQdRYSIALKI
4F8GIy8BusPCRb00WMt8a0/pBmStmBggrN0nsOR6sEazFaoykYiJGDLI4gCZxetTFFRR6erV
dDFFaGjjySSECJiQiR2zLxxzapOlGLWdgzovd3eH80ZfNO14Hg2JYjOb1FHMFb4/6otIVyYK
kUEUEBiVSTkj13OUxnWR3YlnBDrp7Y3288J67urFQJM5ez0+k4L2R1k+yBChT3ku2WvpBTno
QQSztj883nNlj/L9skjuYXqGObyuZ5iB7AyxyPryYkSTyyIPSZXMJLWtAkIS5UU2G2aMahai
GWJSS2qqJg5ExAl1LnUx6uitKJABGOpKGQEAAEJayDYbezQdFKmXa9KdydTD4khlWIXMgeEi
db9L3dhOPVxIRKDAUF19+a0d8v2jI1DDGCOAQyQTVgNkcL1+jC2bIYCKGRrwgiEieCJE8oOd
HHtFSBTrWJZoM9Egec/NmxhbsFj7nMUzO9BlASkEJZMOEFWBzx6jpHI+OY5tlsRZREJykETL
ZFbFASgDcBf0D5ZzCqyKpEqA6pk7Swo6yg5Kysh0Ba+d4LTUZhSsW5044cmn2rsFxLhOcDEA
xDCH+owAoH9LOYfFMaiwpMAr/r8iCQtuoUDQheFtqkpLSrzamtUmLBpsi4iwJA5Lp/P1Hzd0
4CX73EoMWDe+zlUATBXMogIlQVaixdhRESezhulwVu998cGPP3te9UaFOf+jD/pvP9SlzL3W
n7RjhLru/JpStR7otZs3XK8qrkt+tpA7NjtApDLPvv6VN37EfPZirEWPVavQ+sI/yN2zZxfN
/s7+wQE7biaXRT+bTmfjydnw7sns6sLPp7a3e/rsWb9XDgcPXZ65vJ+ffOG1+tNPzifN3m5G
s0Y9nezvwnyiWTHsyRfu9Y93+7/98eXRa0eD3WL62dm8Tce5Q3b7O6NCsFd4Rnj3/i6AOuMw
Tz/85OL+UY+ycjgCQsodiGrVtJwRIKqpM+kEVYeJCREwpkTSqkSVpAa0LHaFREgM4DtC74DZ
sXPOuPDFsDca1ReToigkJUKXed8GlaSqIiIWIyMGyFATIMSmpTxD4s21XCxsh5O4sqXZylNg
CKCGYNoJTraCS7QVS8EOpVZRv8uSUlsWg4VV/obNRgBVIuRFlCAuQvCXVshlfjMgbDGulfYE
WzXEtpSuVz3U2HW5QiNTJIrm6sgI/HSGVYLMwADEEEEJURfek7WZIKmxc0VeAliKschcigHR
gJ1zRe6sis1EJJiNuH52NkPvdgqISeo6+hhJgml3eoepmJqqogQ1BAUO8wTQy6qzT3ceFBn6
+fjluD6Z1aZFlR0Ork7PhvfvzD+aT5smD3nmryZtWTWXvYNRfVkXe4RaVrPxPCpzMwtlFc8P
7x6Mn42L/VHzUupKENvWYjmkcCWYGjBXZL0oRKxd3qepmO3msJubmRqQGnblDx2T6IKDiEIM
C3qotnR4IzGCIyIkEdnQwmHVdP/tfX6wC42Ef/oYXoaOBq7c+mt83yaIi7ubaRZmxNjVDiF2
ZAGJkEjTomYL+hxVwRp2JBGAQDWZQJMca/7a0HTceANrJMcWUkJzXaokT+sdwNpyR1LXV/Hc
9fqEjZiRsTF/wr4wKsB5iPbyh/+0nldXFSblr/Q1MX5naqI4yLCSmJJOgv7ioTvI8XuTdNbY
0OM42L2dInk3m04Oh/02K8kUU3pw4Lz3YAaq0qUYkIFhV4wNnWNEcg5Yc5g2cKurMrMK6SOi
tppVF4+GOfTyEoxgEXqzlDo3PVULadIAzBImKJPrAaKR264MsBZC16reBkK9itGru3bDvTUa
2kK+vLFvu/4kgpqZahMi58qdWx8MibQJOK9q1R2VZtD7+DuPbj+8fee9Bx/8xb/5GqN7/TWL
cdmLAaCpoCmq3jzy7fX5qdc14rJtJOgSyzrfDRECpJSu5hGJM+9v3z2cTMP4YgLeO4Td/d1n
WX7Zm5aGbjBgSFECm0uFyyZiVZ31fFanpg1FmRMjgjlEJjCItREPd3oaSR2F0PzgkSO38859
oDGWu7cGpXt4aweTPv/08mDod3Z3e0c7swRfvF02VU2kQfnT09ndk/0IxHnx9l0jX0zqNK1T
G/F8LpljHpQGiCKehXwhQUQBwTwTMoQmKmbkC+SMEYFdl03inCAy09I9hIrEXX2palYbgJW9
mEybBsCcz4DVunO/RK2axIp4uKsxUWxgPpdb92jpoFpwrVfMBWtJDzuRDtE6iVpAERf5zMuK
HQabGWMrowLCys6+NFdvFBNavtCWBpikau1s6naGaKtiHWsJEWClRW1LhbBU22zLUb3hpu56
2qzB0wmbsgi2BAQVMTytgGrsoWN2nrpjOYiItKu/ZaDQpRp1Jsau0i2qaRIxwMvJJEyn/dEO
sWpbN6A5W6lmTXUxbsqBM8Cg4nM0IOcgRIlBDFBEVAEdoOqllmGSaNKGWQL2J4gNkKEjsUmT
dsUYXINZATiD3Mi1YhIEyM1aTUpXyRfgK/MppUx02ogrbBZ01+AKiyG7S+z1XFHVcSahD27M
fYdXaILlYP/ouNe2kmQ8nppp5sj7bGCzW/2AiMToPHlCJGzTshQIGBr8wx81k6SEUDWpbpMD
9VmIAk/rinw7rcwUvoKW4Yol2UyxPa05QqxlOtW6DgYoBoZIBH2yux672HuFbcl1Q8WAlQDD
RF0hYYIsyzpiwb5rZR0zk2j1VcOGAFVVR0oagQgqQFazkBojx6IASkhJLRpCTEggyCEKWvK7
mWQ9YAA1mswMEahVaow4nc8cWJ7lu92BZ4Qt5b1BLi7bd9VJaEwBOCsdBLOT0g+8DTxEw0zT
gO18UKBW/VjnOz1FH1/Op6cgpY8KbYhtgP0dTslSFEMaDAuPsDOE+bQtdwpiZ6q2DJ7qEAoN
yiDETPEUWl1kfC4V4SWDWBpQulp7qmDmTF2jQIVSL/TuKvJSUVvjoerCXrJ84TYN3/i6tots
s6Y1GsI179IqqupzeIZ1OZoEooyrikFoBpgEU1LRcth7OW0mZ5P7X35r8tmLHz2/oO/85OGg
jwf71jnAuqe6MxRMr49rZS1a3t76eZtVLYkZrNvh9sPL4htdsiM7fvr06kcfPptM62Eve/ON
E/Z4ctA7vZhJ5gi0reYTVY8GTQVl7pkRpBGdM+ylGCAUhYttIyKjXuEzdLXyVe3nH1zGOiGD
pITB56w9l0Tj5EyR+OUMbu16hNA2DSiX/WEVoZpcvH5YyFxn48k8utu3Dovc122oEhegF1dN
P4+c9Xq5O5/MCQTQhbrK8gJUHYKEAAq/Mn32WqoTQCpFbsno/d/4r8vDJylDRBDuuBdbtJSA
uxUhleR8lFh5m3uSe7dPilm4fefYmmpvOLhzfDgYREB+8fJckRrwjUKRFcYKRYnDfQBQtf39
A8esW15cvLy8SCkt1ZkVb+kA1UQUkxjj0dHxIigQN54GIKar8VUIYRuQodPWcat9ByYKCASk
EvfK/le/+YvD/vDk9p3+oI8AMaXJ5GoynXzyycefPvp4MhnDIudnLd0sOSUy897uPgJ27KXz
u7Gjej6fzmfQCfbLQrzdcPO8GI2GIgoAzNTO2sOxPHjttbpp5mcvAPDe/fv37h7tDAbHRycH
B/uSVM0QaTy+ShLJCAljDCklACDnQcQhAmI5HLx++07TBk2xP8xcXt/mUZG7pm1Pnz5CFO+z
h6/faxs72D/K9sRNG2LnM65fvHj8+CIjLAZ5288NbDS4+969N9ERnQ8Obj0YTHKMuj86qGYv
DgYexzjKkPvOM+Cud43tDTM3o2GBSgWe2+GAeznkA5/V7gtvPNi78oPBybDq76GLg9HeeNDP
+o+ePXFI0jYX1RSyEkzbplaVQJy5GKXSRhwCoPZzSOL6o2E2vFVwAkByAuR/7+9iJGKHqvD+
J/Oes7LAr7x39/Rp3e/l4zG8vJKdPBbLnK7J8yek6fzTl/pECWGaOEHsZchMbdDDe3t7V23W
mgkC2kaY2VZi7JpWAICaSgQw8pyiIDEyaYrkGJ3TpgVEdqjTtrmKc6SepyzFsbEylawpKGSU
WzqPaoQnOSXFStBUcoKoEMicIoppFACN4CWZXnkPlaUJoI+TKiudy6zXAxZpEyZytwjQGkcy
dQUXZemJqjGINAAzxKIkIUopQYYxusJk6A1AlNko64FU09T2XOdiUyPrTpkjQqQiR0QQRY0x
Xp5jlnOWrzRWM2GHw+MBEj8/q1NMhOgYQjJmmtbayzml5DLnwAA7Ew+pmKk8uNuzkICUsAFT
WNW2XTIlUwt1lff764zoa7i+/XVDmVq7NV/RZ5auBlvaMZdEYrXFK4e1ipgpqUhsHTt0TlJU
AFe10MZeTHj76OWnz3ccM8An3/re8f2j49/785ff+eHBN3IrujIcANBVHF0erbNd/GrFgxa6
04bAveLHK71sdejXasxrlra0snb5tIioYhfTICIZa1XVF2dTduyLvJjVd187aupwMZ1Fx22R
N0212/f57r7bG+6Tc7tNXvZ2HBe9Yh+z8eSyLDNwmYMUcgy37u+2z2aQZSjYjHVa64MDBDIV
ayZya2hR+fn5bNrIL3zp7rNpykhjGz54JlHMVAliSno0cmrms6yeVbf3S894WUtMcmvIF4oi
rYAnMPY8KF2MbQ70O9ur9cQdQFudlU6iuMwhCHTGOOdVBLvTLIhMyDEzOUT/la//wv/43/p3
Vkd4LGHBiOijTz791/6Nf9PyQWYqi7B57OLGiOjf/jP/9mg4vFay7D/8P/65J0+f4FJ3WXnK
AHCReIf0zjvv/en/4f8IbroQ8e//g7/3V/7qf7WEal2cstKpaZ19ETtZDxERkMD0d/+uX/r5
n/uF27fv3NgnAPzS7/7lEMIPfvjdX/3Vv/Xs+VMEgGVQ4sIMALCzs/8//Z/8L18dz3f+yW/+
53/hPyOf5WXBoa6ffoqjfa3mTdP8kT/+p/7Yv/KnNlegW7f/85//83/jg58owP/uf/vvffMb
X1+c3rLR59/7tb/93/yNv0oIJEqIeVmgmYj2BiPxGaT2X/0X/9i//j/4Nza0WzMDIvpLf+n/
9h/87//9FOXLX/7yf/F//4sbIzUAQKS/95f/y9P/7M81ijGm1KZc6z/55/+fd9/92rIAcWec
paaa/wd//PeMn31GIdRewqztF/nFXIpodPqMrKFWAElFr+bBiKpa7u3s/9l//z/O8mI5qm4q
+NF3fvM//Df/REgRjQjMYrg6v3CMOWPOiT17xLt7tL9HMYEEYU9vff13/lv/m/9ks5+tibxq
VNrcEUAA+Av/sz8h739/VMdYwGh32H50Bj7Ler7nLHk92B24uUEMuPJYrv5dZIl2tQ6WnaoZ
ATnXGbTJuw642DsANAX0LoxjNWGjPudjSGZdQCGD40VoaEIgtRxNCZkRkiECZsxkPsuaaZ0U
APByBj86c63YN4c1po+SQjCYAQ9MiKEB9irBOWREnZNBHawVy/ZG/ZNdmc7mBnmGRxnecmRI
pGrGBnYvS5DnipSCesKkgWPCoFAOEBHRVLsjW5ARxKBNhmxtQq7r5tk/4d3D3ptfWZwx2vmJ
EZRzdtSEmASZyMiiIrBrQ5PnPgpqgmDQdc4MISohAHlwDkyss9zgspKILZO/1DQlk66U9gp6
cfvDwrhhKzF1qe9swcIS8pePoK7weaF1I8AimXh5kCUQshhG4D7niGwKEqKYuNkckmSIU+fq
Jy927txtHj+dn52/89/9/TuHe8929k//zm8c/crvMec6BmZdzTGz1cms64Gs76zD4Tcd6Juq
WFJF6E4Sgk12vmpPgE2U6XTcL3zR71cRcu/67K7m8fz8or+zm0z9Tv/w5OhHP/5sHpMBTppm
PqkevvGF/ePetI1G7vDASUpFVpiZd27osyQa2tYNS7/fJ55XLplINFBG7OVWN5z7ZFRkBYPW
z1+8NIAv3N8fT2sT9GjHfSHnMB/t5NZUk1q1Gs9eu73/eJp2ehQaqkJCdIAwDxKUHGlXk41M
CaDI/BdjdQ29P4L8o3a3eiJHO7OT40ESUhHvfVRhMNHk2CkIoyACSlBVgNVxX8slRQSANx6+
9qUvfcmkRmucVGneFBmdzVC5t7u3UxbFquXGg7QMDO5gD2nhg+qQyEz0i29/8adkOr73znv/
+f/1/8LsVMQhDHuZIvksMwBYFAq3LlZV5uPD2/f/+3/6z9y9e//zeltdWZZ9/Ws/9/Wv/dxf
/2t/5e/86n+zEeW/oOmMeOOosiz/yW9//+6Bzw4PwtkzmF48f9x7Nm5R7RfOLq+tQPeZmZOh
c/zBBx9+8xtfXx8OsrwevPZ6B6IkUceXOxjIUt3G53ObteGkz1/70pe7xdzuGN7/4Q8y1Dzj
nUFve7RLFYKLfnWJWd8yZxn2mzbvDRZd4bpl0et7hqGJqeSog2HukGFQ6oUre4UThKRGxAjD
wueesHCcKMuL7VFB1xWCiUgi8kTETI5F7LVD/vn3yken9k/et9OpACkRosm8pi8vprTVz3oi
nwsa6yuwU4y7lKSR/FJfy0zUUCKAm2cZD8mGfDZXAHRohIyZI1BNAF0YnioidcFCncdHk3Q0
UlUQjQhgEXFH9Ysr18xItKhN+96/fpvHIZyeqqPCxEwVnBCCaoC8YSekATBA7JHkDuZJYxsP
dkZqMEHCGMYzmbcqPcOi8JIcoOMMY2QHjtglEUOiBeHLnJkKV2318ZOOlMVEouYcAYAnl3tS
UyDKVZABmMABtopExIZmZebAjJjRjJM6kBRSHYGQPKqJZQ4JzYwQaWVC1KTkCLwjglBb2SMg
JBKTlsgBsYKgkXVBQwYGlNQcKpgCOUgCAoaqK+611CPMTGLsCuFu860lGK/r+gCsgqvWxjhY
trfthxcuig2ryhKiFrrf2q0hUcxQkprvIgetjam8mqCp3x09fnzRBDs+GdQ/fP/uN97dv3dn
/vjlR7/xHXf3sPedH/befdvyEk3NZAFKKyPnUsVcfl4PI4kCgHe8NTYEBKzrBJoGw/5GcFhX
sg4X82fnnM4bObuc373tLEUkQvRVM+/lrgrgMu/L/uMX1XDvsAaq51Wv3zs+ea0c7lZ1YwrI
iACECBININVBidg5CMHFpI/P0p7vDbWpE3Lmk6iipSQeGvUODFxWfOFB9tnzuXN4djm9fXL4
8cuWXba3tzdutarHClkvw97R0WUVCu9SAAQb9suzcdsGdT5rU4XeIbFj8mQisdLs7TS9htjf
0T459/zxs+Zycmv/IQOpBOQ+pAaJQJRYNEbMyTSaNG11nf9tXv/SH/6Dv/bX/j9owjYBTGXh
zz+dv7jSn/v6e03beu+vtVdR64rEdhUGbRFqimSEQKAI9tabb/+UN+7vHxz3s0effVpmnDnI
Q3s6kcHesT+4pQpg5kB2rn4c6+b23Xv/+r/zv87L/k/p7dXrX/gX/9s+L//q//cv4wJDFqEm
SW9uH9s2hADJxi9Pj9tJ6xwndeTAu7Dw4l6/kuFl8lmv/9vf+gd/4l/54682ODw4RABRc0h9
kno2BTBG2y9c5jIwu3v/tZtHM3n2y197E8AevH504+9tXU38SJGhCSHZKe6G5ob9bdtmHuB7
of+ua8bTlF42pZPppDpuw4exd6vwRpyKwa368cvLahiLdtY8KDSG4LPsWlfzNhKiigbUaYg7
A2RyRuY8Zpl5MuX8k1n2IsDdgd4epqFzuYRXh/TPd4nirMq6KJtaRozsoFH9OPj+ICt7MFZ7
ku27zO1NnqW94c4X+5fPp3raDisVAB6W1kaJsojTUWMiypwZMHqTJMJEkKJOZ+rnV64VIiyY
BFssD7NsF6bjlvIQNefEWQZZxhLPx9BmvTKzc2PhhnRWWMoIU5654chUsamgkZ87cVXE59Eg
0j7rfm4J1YGBYFIAsxwgOEaARpHACC3LTEUimmeKgAjgQQ2NhLjHXVojsDNE1AhdcWaGLIeX
VxVko51ePg0+Kcwn5ylMsyyvoz08cLePD3zJZ22qZjP/4klspmU5KIZ7lPURIDTy9LMLg+Jk
b584fvsnL8jqvWGoZI98wZzlOYASsrsc1/NpPeh55u6s0giIdXDCRMQdx4KVyxqMqCu23Bk/
rvm2oMtUo+6sUiDrjvpk3lDGcGX33YjfshSFeBkaDV2nS4aAS5aIi1SFXlngwpCEzFRdBXjZ
Hue+cXT52WnvzYfzsymAv/3V91IVn/3qb2I/+8qv/NL88al9+wf+a18WwxQjmBmIGUgS7Fzc
HdtBjKILjmvGTE2bRGHQd7a2xGB39q/3PkZoW8EulYKwaUIbZDgokfDFy2lVN3s7Peeys2eP
P/vhJ0ENTVDT4dEe750kdSc7vZQ4uQREe6Bl2cvJBrnXJoQ2praFGHzZB4CUREwRqZ3PYwxN
XbmdUW/EITSNck4iDp06qusqQeazvql6hMsmOyhx3k4uX778HW8dvgxI7F7M02dnzwa7u/d7
dBGLTP3k8vxklIt3n54pYN5ezge9IvOuTYpgdRO4VwIiEjjveuberq9zr9O9w4xdyUGaRsER
IiIjM7oMCA3EyBsCkCfySiX76/Ro8/pDv//3/f2//lcB0BJMJ+niMtSNiNo1g+Gaqlw9l/k5
lSMAhxvKrxkAAyo6ym7fuv3TSdPv+cY7f/mzHz0cURIoPDy70otnj+6F08bvpb3XSaoeR+vR
n/x3/+N/XtbVXX/wD/zKJ9/9zZ/89rdMxCQBYuYwy9obGyMhALXqhJz6PLMwQnfZaCtdPtkN
1/nldDyZ7Wn1o9/8TVNFuq5k9AfD/YOjq6sLMyPm4f5BSqL1pD862DXcGQ2Oj09e7fby7Pnk
4gzIg62s5dcvBauiAEGYV6Sfl1wCCAhH9++2Etzx6Tnug2mcsy8H99/KXk6djpkhMBLYwGM/
p0wcQXujVsSEAAaqGWqZk5ipqqhKcuOX8OTK1DREYYDx3PZy8JmldDPw/LNf3hM5WhWs6ExE
DiHLSBRFwDl0mjKzCvyLib78/rht7eGgN4cAeX4GhLO0wxTBxTaODgqZ4+yi3h2wL1y8HIeL
mWdUAwJmdlpAzT2LUdHBVatXp4wwblKT4OGOqrQ+Rs94f9diqhdFavpEQCKuRKjZvZSBip7s
Fd4TgOazum2arPR8egaI6B0nQTBicIKEUKgBQFesCh2xGJk6MzbrzptihWQASCYQLTECUg8Y
SYi9M1VtBQ1fXILBrOrPBoULCtJWPdKLeRClZ2d2NRvfvt3/4LS9mk7jowtHsV+4/dH+4Oi1
+ezC6qvzi/mgP7TWLqbx/Rf1wSBkhZ7PJqfTZrdfDAf7IBVT++jpuEl6MHDvPtiBpAAsUSTi
VWjqMEYI89mUkI5u3UfyqBoDTC5r76jIXOeGAFA0EDPUzieAAmAEoqJ1QybU7y9cW2YAXf3V
jroYgDFRjKmEiWk/Ue6YRFXahrKiKwGuIl0Icggxz7O2iVeTFqAteuKzzIER+Q8QgUaDqtop
PByfXP6Df7z71v2Xk5j/8McXL8+OfuX3vzydn87a0ZOLk/Td0/sPJAmZElNUitIldJj3Dok1
BUBCIgM0iY7RO2eKV5MoklYeAVoU2pUoAi5DABEDorYNl+cXvdwRu2kVHNPpy8u7d4+Ho+HZ
xcW0aW/v9w6HPWGYVZM62IcvPusfnnC/byqaYDAYaAqX87ELczP1sXLSVHInCfTyok0pgc2n
k/n4IjStO72cWT679849uUptmpOnoesb2rMrddY4T/0iZ4Igcd7GvZ1BlrnxZUOWRi5dZlkU
GkufMTVNSALk/CzE/mBwNZkPelmMoU06qaUSypnqIOgkZzLV+2kysLSJ1WPki6xnId4Z8POX
EpOy45SARcCsOz8JwMASWkKLFiqEz6HBAACwMxp98d13f/Dt33p+Om/rVDdRKC+8X5f53r6G
/XqvfPm80r0i89pcxtKVg4WTSVEE7x/f+pm06f7bX5k3/6+rGcSkO/2MmCosx4HPp+HZ888K
lk/znf/WH/1XRwc3kPjuEpGUUp7nn9fgj/2pP/2f/OZfzJ1XR4T4Yh5+8vHNLUPUDOGswgaw
NvferkpyUWOS9HlxTaK6C20u4ery4tOPPnr41luvtrl168752dnk6soRzafzmJLFUDWnAPru
O7//xm4//eBHodUuakTkxiZAiEXPEWCWkRbUNDdrh4B4+8tfPwnzlNoy/zDPDCATzHd285cq
0yfnNGvqWTjaKc1ARNqq6oqFvNqTSUIzkdQGZEJCSUlSEud8Fa1H7Z1CZ0TBwJM+P0u3TnoX
cl1l/+e9ZrP2LPC8jkEX5+w4BGQuinB1lcaXbuTogV4VSp8lOZLZUemhcI6SDXxyAJeT6GKd
c5YpJaol6YsrQD6/VOew7PnIvm1j5jTfHwZxLncggbNBlucGgKmxWfLKRkQ5OcMAEFWBHOd5
FaVACIYIiQEcUwHxTnbKoBLcvGWNiS16JA9qRGSATUJDBMjVADEoCLHzNmsNxHpAfe40BjVi
BRiHMI0SBAY5XlzUO6V5gsOCQbNqFjJnmSdNqma3++ozf1nrdDrzXOxluF9Cv8Fnc2yCMtm8
ghjBDAqXxQQXc7A4e/riu+QUERxSbOOH83A2b5m8KJ5P24sKgeRiNt+bQIwNoKmhgDurKGo2
mdOLq3o2q8uePBtXzy4vHYuIhDruPp0cn5ygRDakol9mfgwB0YhdgZprO66RGQRAyJkmRUpq
WYqkaR/iPPGkMuqCLgC4i6BSMzPHmJXZrdvZ+GKiiT+dQCHRWZxS3kmoycBlOTrfBkHCFFqQ
pED9NrmiTFFymzV5+p6H92YOjw4mp5eU6rg7qH/yydX3fwRvv32V9OLTj29dXD67vLqMdemo
/+CNFCRJBMLSFyElJFfVlRnMZ3NmFhP2NK1eGihC1itG/czvlIPcUxuMmOZNSAa5zTLQFJ3P
+sH1ghp58mXPFYUzOUZBwqTk8/Lx1dMxeM6tGAwGe/1pFbQJjdA0qbEvgZvQkmHBXlNskAuw
JClnF8EpgJoqgVqiGHezbJD3oOg7MXCOc5dmJuzZOW5m4XI8a6I/GmUqKfdeWnGeT3Z75LMP
n833B/2zqVNAx2imlxXEajwYDvPMnV3N9/b2pvNKVeez+mBU9nNX1QmRZnXteqVn7PxJX4iT
a1j9PmdmmjEOhsV8ltfzeX+QS2wTqwigoUmkJCwVJgIJ2s4lfA6BW14/9wu/+L1v/9MYQBT7
hUut7gxL/nypHrpTtKuL0M5fzAb3Hg66VBBTJUhf+spXfiZt+sKXv5mRZqTOQ8YpQ/i0OfzE
hvO6jpokJTD7C3/0v3fjs9/97vf+5q/+6scffTjsl7u7Oz/3td/xB3/lD7/abPfg+LWv/vKP
f+vXzTQZ/J0Pm7ce3qzNtCldtQlCVfQHnXaGCKWDMvejvrvxkR5BHlszBNMffvc7N3Iv5t50
VscoqCJxzgB7Pc49A9E33v3ijd1++v4PYOEjvll0AAA24OlU2F2OWz9vb6Ux3tQSATKXmpSM
0p23X4+t5EWmKfDOzr3AH1xVZen6BGFY7mM+Hk8uzqtPD3ZuDKVwElNSUYhRiLkgVQDvHWr0
MtaIO8x7PQ++oMGovbrs7xz3yvLGwf+zX6UHT3IFbgwojXqHjLDLoA0ksCKDOMdxq4WHYd8R
58pgYKjiwCCm+3tgkJlKTHFQEkgCMgHCjEmCP/5C7kDqKZk4ljidqzFbIh5Jbd4hDkdnbU7h
sjcaTPPe1Tgd58lzXbdQZtx3RqDOOUS2mFJM5JDayKACkmqzKFwyKNfnVYGgWcZBu5htJjYQ
NHNgGGEA1IDMVBrjAmCQe1H4/lX1dNY6j2YgNfQyLDwZwaxp0OSTSeyh5hkwgSgQJ+C0W/Sa
JmfCSXTzFG/100iKRljMUsRRMfDkj/oUm0YBRajIedSHlIBd4tGOcmaqqY5tLSHq20d5FWAS
USVlRZEou6hj5rzz9uGloytqpTTJeIrEsLezY4iqGktR1ZfnZ8yYou2M1LthMhIRdhrZzSIY
iDKzgZm0SXJnA1aPWs9akqTaB1HsjiVyTtVQLYkYgKlmOcda5621Tf38RZ1r2skh2Wx36Fkj
GGKKFZWuq5fiNcttEokJCk+zUD07u5i1reX6MZWcMH304ejhfkpN+6PPzodl72T38Ytn9+vm
8Orig0FG+8PfOR7Pz168TFTV06KX9YpRNZ8ouOeXZ0zgKesVvqrnszYmCkQEGlzV5C599e6t
/X7PdosXZ/LixQsgPt4vNFSTaSj95c7xQ1f05/OaCcvSg1AdgSSmEGJTZQYDAUc8n6d2hxAx
CiJgzl6FQoghCmoKNTZt6xE0RjOpE85qHewaABpxnhWaJEqsNcWmcgiExIRGzFI1wjwZxyzX
Htm0Vq917fMQnGHuHV1OqyJzmc8A2pLifp9rApEwjpyX+aOnF+/eKRWpZBmDZLk/rbRoYq9w
OHdGPiSZBSFUK+zddN2l8T6XYMkTeEbOynre7A7zCOQRAcF3hQ2MCB0AM1JbxZ9ZKvqrX/3a
QS7lyTCl5IiSgpr1wsUrZ2IDAJgIpJSq2fmsImnryMtQQbKm4jD+6le/9jNp02Dn4MFb7zYv
f6TJkmJWFPXVy7p9Fk2TGID9gd/3S8PBDTbD737/h3/mz/4vDvYHz5+f3zk+2D86+Pa3/qHX
+vf+kf/Oq43f+/lf/vg7vw6GHonJFf7zbHE0rRODQVaKJxUdjkopB/282t272eiapxZMFdAU
vvft3/6X/ugfe7XN7v7BX/sbv77b51v7pWK+m+E3bwuyAcC7X7yZez366EfaldJH+LwMSa9x
SNL6rDfwTgdWixHf1NBiqpt6Mr64OjwouG3qyyaph88+ylju3RoAwKIu1/g0PXpZN3i1d3Dj
GyfCH81dTBJM8wyDaIyaAELKNeWsdvTWW3t3X3/24io0czccQeYH+/s3dvWjf/qtH/zd/6qx
7JOxGmBGAMuT5RwBADBol6VYPf2oRzJyNBO3vwvkuCz9ntRnc6hai8FyBkQUwEFBNMhBLCYz
EEFMeeEpKJAEMOe1y/QSc2TADpK50S7v9skZRNCL86tnP26lRVG7TL2czMwjn13xoZM+NGke
xpfxoB8TRI/YtAij3uD4LncW1RCqZ88HDlvHdTI2o4wFFZhcLwOHEM1y8t05k131qQBzxaYF
czqL8byNxBjmdqfn7wJeNOn5PKhiG6zMkQCC2EVrfQbn06ROFxWmXEukvqcm+aZVb+ZcnWWe
2FkUojKg2+/n4yAEqMmGFEdDzjz3nXesIcZPps3MUo64R07rs6jFpG48S1MbAw2017PU8+Yy
jtFlziDY80kbHeq4wtaAyBMLWsbEiCURKRG6pIrBWk0AGOZXL59dKaIsYrvQuow7ACJUw6Dq
fXcMCRngs7EB17ioVQPKXcUxM1MkTmRtVU1OtTXnPO3u9Dyz9+jRlIARCCkpOBMjz2QapxeT
ic9HTZ1Nq8nL6VVScJSphLjnswnujwr/+u6z7zyXej65e3Jx9vRegC+19a+ZNgfDpPZprV98
8eLbAAIJamzbFwRAGecZJtGmDSIkioikKYum3qEqThv71gdPBzn3Mj8q9toYDdrZtAoJ521T
BW/nz27fvTfY8een1ThF5918XjkyTSmlVDp92Yyj2cFu7gkiIKGqGpo66tLtUJI2STpDpqqa
gCjMW+sZIoLUE1B1PmuY67yNEp2CMeLFi/qHH02rNr55R8DlCTABpOh7EusQrubapMGz89m8
Cd98c/9CbFqHy3p6Ve7vH+8PekW/rZq22dsbZTlXMVCx20vTyXjWKhK73V7+4rIyR6ELazU7
tHSkW66agPTtGkofqARDRsqauoltPwRlbAEZEcEEUjAVTK2p1m0rn+e9WV5Znr/5xXf/7q//
2qMX81kTk5gYFIX/d2+yXk1mbtqOUnTl8KAs/APNMiDqKouWo+H9t27fuR7X/lv/+B+9+ebb
u3t7mzff+co3/9Hf+AmYJAV2WdL5rK6RGAgJ6ff+7l+8caj/0Z/7P43PXkKq5nV6Po2XNmlP
x//zf+//8Hd+3x8piuJa4+O7r/Ucxu5gZIO2vZkheO8k7xOaAgtodOWLqyi5zeft1dX8xkdU
xAA9k/P24Q++c2Obd9/5ogOhpG3twXFMWo2DhqAqRw/efLV9Xc2ePvoQFgXDgehz2BfBOeRN
IJ23gfujr/489Uc3NENwpWXmj0dHVx/88OPvf3L73snx22988q3faqHY3x9Ul3Ms9c57R9Oi
XwHcVX/33gm+EjwJAEA0OuwfVy7PnAGIJufhZMcdDdDt3XntVh8E09kzn3Q8GyfwvhxEuln3
+vgnP/7W3/yvH4/DD15qr8zvlDKkGCgHjUA+hmgpeVR2mIE6cOeBsn7hnbGj3PtZUx/2uV9y
fSr9Qu/tejCdq6TcFc5rGxGsbcWTuRAU0C/iCFhFwRQSQEqE1p6eQtVHBktQX9YNDrl0TRO8
g4ZEBNtKs35mxeEEbT6NtdLzSk9KU6HzRm/vGj//DExVFBF3GAywJAC0CFhFg8bIWXsxA4l5
36MYARBxMsgAfjzP378E4jQYBkaNjGRQKzxt45/bzSF3sDO8eesBYAiw9aMBuI3PzfJzAAiw
MN8uYTgt/yLACBaOVRWoAWC2qCpTAIACzNZv6OS3HOBm2eb/f5cC3OzIXl4lAEwX7uMtaWoK
JcAJQRrDewiwDxABFgaqPws9gBXda/5X1zv9HIP+4qew/XkOSzz4l892azCnaVKNs5dwcHL/
YJQRAEhAx8hYG6SEL+tEgx6C+X7hnANMjggIA7lkhmSIqkDzCBiTBzVVAzUVZDUwk+i9gOei
T/UkoWrZHzokeP5igqdUtfyTT8+slTfvHUymidhHds/G8vaOb2JqWjna7eHEXTZQS1CEl9N0
2M+LXu8nnz45Ozv/xjv3+oVrmnow3LXxZQpyMMqaBFWbCqsIYuckdGgZ84P2uuL1cTaoplZI
ArN5sNFo+JOPfvKDD573y0HTNm+/fnT3pBdiQs+iGEITo4HK5wXObV7f+KU/9Ff/9t89n4bh
YPTg9m12znuHdIPdTIdvQ9V/uAdogqZDhJC0TfAiwGW03//VG+jyX/l//6U/8Sf/tWvc60tf
+8Y//lv/jxhQgJDQEXW8F9SA4OGDG0LkQ9v+5Hvfr0Qyzl9Y9ul5e1il0awyw3/0W//09/2e
33WtfTY8/uGk35W+nWpz9jlxcEVR3HvrbWnryZPP9vbzqYPRrmPCbDDY6d/sVxvtlAd7+eGI
X7+TqZ7PJxf90XVt487dO3/47YPe5ePSVUkNkjafaeZp9+TO/q0bEteeffJdCC923SJwqwfH
N746Fbv+ja/jxYurlDTLd3vu1Xh9AACDau4QHIJAnj+ahfbRxf5Be/Jmr22rnTK4o1EbGkJ3
+MUHh1901QxejG8mms5nBblvfuGW9Hcck0c5cpd5QUh51RK5LD69OP3sI1/oHmCRZeHxy/bO
zYMf7fWKo8HDA4ZBc/ZyLqaNUpFJTFyJodrObm8S85K1iW0EVzU1thqFMw3nM3UJPwxyZ4Dh
ap4N8Goehh6zoe9PJpakMEMwJ5aGvZZyUUEzREQgJWMgAQICljR59CRFzZwBQJWc8yQimXee
MbbCxKlJOYck5jIcZtgM89f6CKFGgMEwoyJLcVEzEFXqOuYoAQCBES0rUIgMMThU831EZiCD
CPBi3jLBRPo+l2FWVa0ogHdoBHm2oIuV2hMzQkCDoJaW9RozAiY0gDoCk1FXxR8oKYoBAng0
QCNEQkgKrUBS6PlF5TVRBF5E5XkyNVA16moImUVTNWCkxUmM0GUNQlLrfE9MlgSbBIvUDIQo
FpMhANEigXhh41HLvQewkJIBIKLjLu9Ru9OSeHFug8nySBZanCK8+F+WlSy6SMUu0n+ZUAar
2nIbJQeMCKNGWSR7dXZ3XOSAASDgchkNDIyQXVZ65DZWbagcFYh7ALXqFBYlWAvAwnRqNnRc
gUUDMxAF74gJYle+gLokcVgkyCIScRMiUZf4gwBACG867RP0i/x0cuUcgtD5s1N6cdUr+7nD
kpHBWIEIQ2hzYqQi96S1jnVWq6gxCWSGZGjWHdwBKok0KXGMAiamKTTR1NAU8x3izGeGdoWE
2rbOkTurrAmJsFUJRJYkTWZ1XlhwcjFNZpbaulE39P5oz02rcLjfL7ybB+Ni0C+yNmoEFolP
X87uDMH3LHEPqBpXrSIXqtPoolGTFBg9YUjyephcizv7KBskqSZV6pWmJr0id0ASGt+LxSC/
vGoKT72yTM6XOXu2zJtG6OU/Leawu979+jeLu185LCbD3PteoYot8o0qm06e2eWTx/OqcFaL
n44nUeFlgJJ0HsI3/tS/fK19COG3fvMf/cof+Reu3X/ny1/P8wK0JkAizJzLmZHA+8w5vnO8
B69c08lkPp9F9mqKeYFRZkoDl8/n07PLy1fbH926/WSGFWANGLIiZDcrBClJPb40SUA46NF4
evEyFEo+RXljfLOo9doJf+1NL4CzYKzt0w+///bv+L3X2iDiN999+J1f++Q04o6HSYQ9jxOl
t95894aiigC/8fd/81vfHh8OXBJVhZqaV9sAgCt6VPTGNHhxNTs5yQHCTSUhQVUff/zUUbWz
txun7cnhUd/zxfwoTZ77wk/EjVt2yfx4ypePDcqzq5BSfmOgqVA2693pC83PrkqIPndSxPNL
8qSMQg6wKN2to55cZUAFtxDaHbhZZ3XW9nNNQXMU77gWSGR1bUEwqYLayGSgkz6JeJpV1T7b
GfBODpxMC4+z9nKeAFwbDNGdTeCkB/3SY+YU28wBoA9qLstYW2SwhGBAJo4BxNgBe7ZkRRAl
dAxmOAvKxIxgKEWWeQJFGnoiJEB1jlFUEj5pXB+ynR69rGwPuQedgoyQtGmFkcgrmwoQKFoC
n2GZuU+mOGl1J7NZ62oLrbTJwLMclCqqbbIgUCgAmHOYxADgk6T/aRv2C7AE8wCfzKUVKzM8
zOmgB02iJ5eKbL3CYwIWdARlnmUOM9TasnnLGXDK3DxyJX6k8zI7qxOLDZwUrLFEc65tJZzO
TMTd3zNS/OGlJtP7gxIRPJMZV1FzrwCSERKJmvmMPhz7aQRzMMidmU3mAAZVI00yYiQHiACi
b9w53BkNvv/Bx2LKDgGB0Uzc7mi/accxhV12t0u+FDlvzSFJhP0eGeitw2M0/eDZ2MiFhIiY
Z1mWF68PUpHB+1c42N0hs8Fw2DRtmF5mo4PT07Oyl4vER6cfMRFoJGImAsKkTIyEiKZtxHlr
pTcPEIR2hoe/+CadndX1ZX3azH8O7aU036EsOuwRvwH0RbJfreq4lz0gOYzZj5w/r5p5A4Oe
DXzyTOdzNrDMaRQUdYgQVfuFb4ISqyc2xNBa4fA/OravFxajmIEmqLszXUWduLoNlWdQ7Tsk
kSNrBxjP5+NadfegR+aQMnS9Q5R+PYNHjcscO1ZYnGFhCPP9vcplIaRsKGWvb5L1C2tDdX46
uXz5omkCsXNBEoLknkNCU0tJmFCBnp/PB3s9VY0ibQizANaGT59f3TseoHOV0KOr6p4oI+wP
PLfRUnrj3hGGsSS9nFUxpnnQ3UEeE5yfXbZiTZJepoCwm/EXw3XF+H3fz3zLFhxC7pQJ7p7s
37uzRwj7uz3HOJ7U1bSKNVWkbWh2R/7JVUzhZyffENE777zzvb/+a59++lmoZ5qSdyg3WQ6f
PX3844+eP3nxYu/ooLGiOn0y7GdXwfZKj5n/yte/fq3948ePm5iePn5y7X7Z699+7d3HH3wn
KKt6zjMoy7zXcy5zKPxKDDoA9Eej/u27p0+eWwjkh85wnrAu96xuf/0f/uPb+3soQYDYMYOJ
wbOnz2ZXFxfgAtII+ejzbHESRmnivKfjvdas5YOgULWq5up4o0sJTif63c9CKenhYQF19ezb
v/Eq9wKA47fftV//u2eVjTKqwU4ymszh1he+dGOff+1b3zl3w8uUN02NKgfhc1xuEHb0LNuF
g8GocHL26LG0N+jWiHDgL56fjrENDPnR3mh/b/D8Mr3/iN5+437b2PMXLw92hqVH93zMNBtP
4vHhrZsjRWK7D1VPsCfzeVV99HGcDYsY67f3sygQkrQHDy57D15eFfd2nWLt8pm5m2MO2xY/
fBwLjxzlclaD6W5m9/aKDy5ijKHvgZWqJB4xL7LcJzPzhBkBatgxcUWa9HCY20WyRoEdlTlf
1pwGu3nWRkze+STqUF2MwKSI8P8j7b3jL7uu+tBV9t6n3Ppr0zWjGc1IsiVbsiy5496wIQRs
0gyhPIfy8h4JCQkkPBJCGnzy+KQ5PEIIkAAJSSjuBhsX3G1ZlqxeRnX6r956yi5rvT/uWJY1
VwlJ1j8zv3P2Pefce87Za6+1vuv7lYTKEi8LNSVRULEEgJSU6ohBxCmgogqkhIicks4DlBko
QJkbjWKcybntGiwsrmSSYcKkpCoKGsSoRBWbxLepRjMPEDx2CFs1O8lK2zw6JYkVYeMYpo1a
G3KLGx0qnWBUVUWCKE/LOoBEjRFF1DDkDAu2jr06XTU0MenAIZIV6A6LqiDJbclZZ6adcQt1
oOCgQXKO8kKK1E6aSWzFGu3ko9BQxrRTMRGUmWwMsGo0KhQZ7O/wuIG5T6hUOmVKCDqtU+6w
XyTfkmVBiLXnxlPOYA04Q90cfcA6pwu7vk1iGa1FIRAGZhuSGmJMqCiNCCNYl7Wt8b6dZ7rT
JgVuolgyUc2lmpDUpKJjwBSJ2WhAw1Ba9koXWnu4sKINI+RxE2ZnM8g7stuVYMvKa5xI3xIP
XTxShqCwVWeNJqd+v0kdR09M0QsPHJgYrWHERHGa2eHDO/NrOvmbQv2F2Xh71VkQG/TlZI86
eADTkRWD5KeiswRvOXTwcdw+uzlFlo0CB7nccU7PTyAAEEFKqTAUFWZRkAUBfEwIIkm98mKl
ulm3CIoJm5QiiKoabDpsBiavYkwqXrWJOEpYdQoDCsMVW+ZaeRDcQ72g0Qafec0BTNICMQMs
CLMjR1xn6OOCbRoBtK0f297e3N2b+cb3cm1bMETcKcvprPZx8QJASkIAFoNh2LcxREBMcVq1
hWXrrDM0nTeGuSwdStM0LUmM0TuDl8bVio1FxzjmjVV65Hw7mzcbeacoMNY6yIoEmEK4znj+
5rnkjClqtogoKWpsADCJaBKfkJDObda9jqtrURUiVNWQSMk9dmH0vPmS9LB+E9s6AMBrX37L
e37pl1e65cF9/SzPxy0sRaAdPXr4kbM7g/0HexsbMp52rrkGRPcDEJtrTx5fX19/1vgHHnzI
R3r0sSVw9UPX3vbF2+8F5u7AZuD7HAxDk9JEtJYlp86z7FtfdfMn/ugPt0NycdonJEguEXXL
P/6jP/7aFz9XSDVtxRqC5KfzNsaY59mtB8ypg9mdZ+IrTy6v/6HEyXg7t6RoHzs93d/XnWlg
5hMbOMDx0o9castzsi+ef+gqrrqOLj5019JhB0/e0LF8pIOFgxVUQ9i3eujk868cGUL4yu13
kDFl5jKLFtJw0F1+tURZDnmJ4glNimGRubliGOL61fu6BzoQE0C+4cuH7764tVeXBLvnzgFA
j2g+VrYwzDyB5qqrOlsKdOxicwTP6iQKM6V4undVL4dTZa0sSaxxqai3Jm2nzEqlOEprLtuY
9Y4svfiopJgZZ4ydPXphbFlNH3ndtT64WBWWC5sXWXfeRkAgYmI5yrV6DClljQfm0pkVJ5nK
Rke2CIkIEHEym4cwEjXYFFZpYILyIk/GZACRHEsQEAEyMYbKgyhZpiiKAEkxRojIkwotcxvk
0jQOIlpEV4JGQIBehhhjXSFa0yaKQrnBaSVWqY1aANaqrdBuS5OgvoVegpny3EvwQgiQUqsw
qrAOgAyOxZEaJZPQkLQCiuDM5Wd+gdRgRAYwBMYAJe05jkn3dWiYZSlZtETabZPZTq6ZWDXg
DKwNtGPFUqsQCyf3PzkOsS1yMgiQQEGmXjiTSxMeoO7v64pFEls3sNaRqcdRLYf7pCpzj/MY
VjriI8ySFCWYyEzcdTppUwiwPdIoOuiyYx72LRt94lJLiJo0Jg1JgShGVRJrqfUqqo0KIIoo
qNZBQGzusm5BzrIkGuToDE7nlS3sRs9ZNjstgOpK13b7vQdPX2xCKk1cgb1pNdN22xWAwNNx
LQjTWjKer+ftCkcbokV5wVqs0OyNZWBkkONqjvduUxtlWMixQZpEnggDqE3+kQj7uh0EPw9p
hfGlNt/I8HbvqYj7TXiyZm247+HRh8/vuyb3ZdsEDi141KtWeJDhmZmudKiDupZFw/rVLXhq
FHoFr2Z6qCObE5g0oEIAkBGLpCBqbaeup8ocjJ3GAE3VZzLGbrfQmA7BLAucMe6MvFDeRmgF
vIDP8tgxU1Bf12F7byWkaDiLelXtbR5BgYnapplPt0d7F3d29gih4zBGiF6NiHSKfDZvq/kU
EZKoMdzpFKPJLGPs9odFQSuDQiUZ5uuOrm/vzfb3ea2Ua248Muh1d3d2DKaTxw6UpXON5EUx
r5puafvGn9hXRC625vHUVQc296azKrZCeeZuxmenwh6yXWMYgEJoUAXZAGEEioqZJQ1RFNia
ENICkipICoxk2mWtow8/chqJrz154uktL7v1lpNHD1+6cK6eI7KTqEsLKhcrnEVYVAmt5W63
9LUHQFG5+fnPu3L8gw8/khQfeXyJ97r2Bbecm/8HYlwvqEk0btBBQErIZj5bnnr64e/7Xv/5
9713txy44FSPD9KRLsCslrY23XVOqY3jKBit660hJGgtG5sspxBS+Ry9YQoQfNNzOVkA9cOC
E5h+Yff3m9ws+QUAQIJ3frZvtXykknWB81956B0x8BUBR+/wtfdOXKUwqGGW0r6Mz7S0cmJJ
7PXQQw/vbG6S5ekYBaCX2a1LF5ae2pAgqaIiAVqwLEu9lypo5OQL9G1sKxCoPXrlbqYCYEU8
6iHX7MzbwsiZCjqGMrM8TSqAe8EMDYRsyDrLynU3NNQdRgKfcnaU2B2OHQGqUQmgTrE1z5Gk
FcqzPPgYBV589cplaAob5sBARWYA7HjuFZQyA6qqmEGKigEg6YJC7+tsjgBJQFVyq/lqN1QQ
oo5b3zTpcGF6MF3psKYEMSmTgJ23wUeEYENA30pC6S5agwmbSnNrgB1GRkFpU9OoA24RwybE
FsfiQ4BYY2nBZWm1Q53CpDa0amJMbiEYCUYUmBCTYoJ+bi5enO7MYlkWIfqMrYAH4hijhBQZ
2qCOuFDoMAnr2Sqmr1NSCEIdoWtVFTPOaoFeQZp4t6nyDNn1grg6ABjDBrokBzqA6FNoGdoS
AFNs2T52PlTeM2sbAR2mBGhoVqeuVbKxdCCCdUOrXW28GiOHBnJJDbMGlaSCBLNWxg3Mvdm/
mjTARke6XXIBrcWqkqpJApq5FFQBgEmTT3VCZI0xAaIxtBDIClGBEJEACMCGSLkx/cKVDjfr
6FspDK45NsRZVloLLMgMq2v9mKTXcVleXuzliC1Mnmqq2bQxzpqSxZMASquaGVrNa0i6V6XA
pmsBJRkL+9egbvGxirqGDuaRUQeFOKtgsJsZ0Hhq3Z+dygVjbnb9QTs9EvLSwcdnlcnhgJFZ
gGNq1pO7s5mn1XxlxIPc1KBVLSlCRFl3sG+ddhuIwVeqh/t6uKQzO8gJ1nMxEPoFjxtczL6z
usGU+jnVKXSQLZs2inDZstuMDbXeAhR5Vrd+bzrTFFb2b1R7tQ/euoxNZqzpFAXU1QxCi7SG
gHk+mVQqCUE1hnk9rWY7072zMdQdS6x0zZD36jBHNCpinWl98CECgIhKksxZRYzBgxkI+CLP
EwIat7mz1+0WRZErSp7nnbKYt3WnMJ2CDfN6z1RN1S2LJgpyqn0bZTbISkQShUkVrENJ6fpn
wn4AAOAO6VoiUUmSQJVAkJEQp3VqorRN20ZBAERqW8/MQlSqEqEuq7Jsbm7ddd+Dz/ReAPDn
vvPtv/Wf/gsx7Wxt+eegcaiFkishJFXwPk7GVZ5bUUDiF71wSVRx+vQjQHBpc/vipUsH9n9T
9/H111/f7ffn81qR2NrpdKKTESLuW+1Pdy4tPfvGieu//5//1oVf+Gf3nD5bsrKEpknik2En
84l1tP9wFw0HJAI1BrTItvbConrchOXfaDqdC9is7E93dgpr9ipWoUt7cv+Tcf3G3aUfoXYK
1U5vtXCQIsilWf34ww+dfP6Nzxp26Pg182ylnowawAQ48bhx9Oj+I0sAKXffdVc2GHYKN5uO
CmeHw47Jl19tEkhRaVG4DgDP0ReGAOqBUDUKUe69H5i0raFr6WJNHUQkXe/ok2Nl5+pJNIi6
zAsCQBLFFDkniC0AHi1mPZtNWw0iqFOoJcUotU8p5SwiEkOiA+XSQ8UklyYeSV2A3JoWuJ9B
1aQNR1aLboYh6tYsbHStKgRFFPAKAhQlsSUhFARGkKQxiKhYZmGwRgtHbUw5gaEUAgORVUJM
gKqK4znuzbgOlFnsW1AQl1sjXkRj0iQAAggxc2iJGHXfis1YFdRZaliMp6knC+Io9ArbsYqz
tDel7YZR9Fgvc9bNW/LKvSw9vhsu7DUpK7embSLrirKdbtfRWzKGWdUzUEniA9aow0yBtQZi
phgFAGKEqGoIALEw0IccqDw3iRZnVaAtLyv5+MAwP3Vs4OftrG4dJ466udNMmpi5eLDXByo2
d+tR5dnEjqMFhVMQsKjdDEdTzRgh4WROtcdRS8bGag6EOOzDub3UKqWoEkEU8wz3aqA9Ywwg
wflRGs/AWrSWACFGANCyDPO5+lYzxss4BtUUhQF9ADAASirAzCoRiIx1RZaxc+Ds/sIw28KS
oXjx4vkqbpHlbqcrMa6zHDxydDKe3HfvnaNpE6Q6gL7oZFbRq3okUfKRtitoRKBMqDQLFJS8
xZJshoqEpSPEOK64YMptmgCNZhhDPHKQFaS07Uuu8iFRNem/MA6g295b1Z6wZ9EYs7/Fbsu3
N81Wbtg3o32HOzvtqN0blrA5ozayInQMmstaFRgFjnTTG6/mRmjuw1adhl27MVhxNAXQftE9
NpgMs4iYHt1zdUi77SYUgwD7oqJHytXvzNqpYirLrLuCHLo631HjiEBAW68K/vTjKKGb55Wx
CQ0Zk4BU9OyT94+nW5aF0Kag/QxBcdJEYzlDMDEGU+QhpqSiSIu0myECMiSBQUXEsKlDuLQX
61m7MuzFlHbncbJX32BCSpIZvrTbbqxwjJoZIsOzWchzYsQDG+Wk0ofPz33bRgGreiLNOvxN
C+FLYB8K+TUB2eSNekRUAcPGWFY2wGQtOOcYFxgeRYAsN4O+QwBeRpa6sjK8/favpnd/H/M3
Sjtvecub//N/e6+xZvv8DtlsOVFSqPscq1A3o5YlGYiiFhTYmltufnaf8ryqHj79mAi0rT99
+vSzvFeeZTfecMPnvvCFpm0BaePgAWZGhZcetbOHPwuwpIULAE7cePMv/8Z//J3f/s+/+5//
0yNPPE6EYrP5tNroZ71+8ern72eMGFNUVCYEbXbSU7sYJY0nyzOHR646+q1ve/twdXU+HVdt
NMxEAMSzOrzkla9Z+pFhmb1gw4EEjH7gZH8Hzj/wtSu9lzHmqpPXnr73ToxJiUyUq04swWQC
wIXTj6z2Bv2CO1YkVfN6T/H40pF7DVeeellaSDQBL4WALPBVVlKF7Nn0Tag3uikJ5wQJuM+x
yCB3fO1GiRb25SIgUZaCFyFjONQlIMyxnQetzj7Rd62oBDCOUCUaS9RQHVLRNeQjk4XJ8oxr
mI/HuyPODANUUYmFGVOS3LoDa/0ok9G0YmLLCiCMwIzGcpvIOEwWpgGv6tkOph1AMmiInDFs
KRtts0/SAgJ2rYqLBNrUIbdBVOdtmLTacTGzxlmfc4wxZa4HbQKITJAAiViibDa+rUKOjbBz
xoGK42QLrIQywjIlAxBatSFuzWjS2t0G+rkjlxDVUmBSi/HaDZpLZxS5FowibYqq0nrJB92V
XulDzAgLCjdd6yjQnY/4jaFcs+HOb8e9KgGAQdTIbDAIzNQyu40S9nWVlbYDgMOtSeslVPNY
VUERjux3820vRmwBO3OO1DbJT+rAi5ZPgKgYgzoLbYON5906GYN7FXkBREmROx3MLbdV6uXJ
JzMNMA8gPlmkWVBmqCfKBCPPUcAYiQEyR8bhrA7dwqZAPohBVlUmkATiUwoxJWyCUgK25Jzp
d8qtndH+/cPrrj/a7XSLIiMyRKhIQCxJH9sajWc7RnRc7QJoC/zY1vZ4Op/N68xlmUq/z4rQ
yXCzoXnQ1Qy2Z+ncGDpOgsuHBRzopXMzjR5pwl0Du/PIKJ2MRm1DmdutsQ5CKM6Is1bjuGnk
TI29XLLOZJzWoo+VUsZYe1hRw1E/UVWXRLFV9jqBePCq4zeca5qyqjyMasgMGNY2aFIk1N0Z
dTM92kvTGFLGVbRn5uqocagAcI0bJxRELQxcvcJblY1tttNO2a3MxtODZdXPtNv6IYYzbeys
ZiYFaZujg8HhHjw00VFojh8I7VVuZ4vFFSHGqtdbDUlNVqc0b2pFjEriIYoRiR0nlUD0SqqG
TKYiTesBEImSgio0IYaYUmgKTgAEiKHx3X2DDBoBnNe+n/PuJIiCj6nrcDRr13q5ZWojtU1j
DZJxSedPXhivrvQbH5MPlkyK8bbus3EWD3HXgWzOQcACMBJFYRAUgdonQevnjSQhYwCUENhg
5ZNBRKY6LMkIrQyH4/H4q1+757Zbbn564zXHrz50+OCZs+c2BkWZ50unxUvnn5zvnN/okrOa
ZTRtip22TBJuvv7afu/ZkOtHH3ucjc07tLWz++BDD7/qla981oDbbr359CP3+hAjQNEpF5oo
puDHPvuR9kf/flYuJzlk5nf95e9511/+ng9/4EPvf+8ffPlLX77+UHHTtX2ypcxa72NUmnhu
olpGwc6s1cNruSuXt9Bec+21//Cf/eLSXc9lB2x4ShtDWhkzD6ZjZeuhOwHedeXIE6dOfe3u
OzOBBpAlPf+GJclVAHj4a3fSbGdr7psUkgIiTJvlebwEOK9ipnHB7QZEz8VISRalLsN8amhq
chZLfZaA7kgv9Sz5mGoxqqFgMDmT4ELVb+kZJ8BOUosuN+28jecSZgqJYDjs+KZCzr0RA2E7
FQOogs3QLOcoue01b/zx7krWKUCgiVFEDSGpAlFZWgg++pjIfuEjv7/56F0EkhsgFRBAVYnq
ABkyBY26AE9JG5Jwspi8iCGNAuPIPUY1adyiWlaVxHhgHeuKkqB1gEKZTbkBHzACMQOjaYMX
YyS5thnvxYqIV0O3k3eqOpBP88aBSyG2G337xHaz2i0em9KlShnI5bp6qBSfeA6SwJmsp0IM
TdL1Yu3JS7Wf1yGZOqRB04IzB9d7oMAgs5lElbWV8qrVIitpdTBd7SoAZJb2DQa5oc26KvKi
ZN2t9mYY+4wdB1WCzGBQeHSnaZIYhvaCqCIkSVFHrV5qowJMPFjUTgfsDFBw2kLhqBWZ1Tit
IYIGiUVuDCpRtAAhqCE7j6GOKkBAkIh4gdEnCAqcdK8RRMoNeVDvJXeMYjDheAwhErIGWRBi
83RaX9RtITKZZaTVYfd5zz9e5OV99z25sX9jbd+qpkXSN4ooAiDR1vmL8+k0xdi0MWkyjOcu
nAeLgkxM86rtZhIENufc67D3wobmCSYecsbcwNlZvdfSoQ6uGrxUq4Q0grDXxNyYzMs8hImP
ZWYQwCcd5pxbDm3rBUWRUZs2QWecz3v7XFUYPdY4G9PnQzwXxIIIURQMly5hf4VqmxeWtPU+
dp3d3yFR3JzRuXGc5XhiiOJoNk8AYV8PcyOP7+4GKQB4HqaGMFq9ONV9ZbOSw5m56Tvq0d7J
A1BQcuRXyma1s0HTDWKCabKk+1xbkL9+0GEq5/WlE8dip9c5t6e7tcZ6NFKfdjbzOs9tUVUz
xKTCzhrWuL9jVnvm4e0mpGSIuQl140NKEkNMIkgYZhOrKnXNEpBsCsGAzNt46uDw/Nb46MGV
MiOfce7cxWaKhZaZc1nmQ2yTrHfsfBrGsxBjWh10VFUJM0uEqAo34RUUG65cZZ2JKqlq89j5
PWTe35vG0BbqbfTdjqoxbQJVjEkGhZUYFsKVS7k2jGFk+pPPfO6Z3gsA3vKG1/3qf/htUrXP
we3bNr4g/4bbBtRtwMpD98n8ySmQvOLGJbzy99z34HQ6Q5tng7WzZ564csCLX/SiD/zeb84V
fLrcdqdK7SRh7j75W//6rT/0U0uv4Wl727e//W3f/vYnTj9016ff//hdHw4htZEnMZ+2WgU1
bOoolnSlJIuAyzkp/lfMkoAxXqCfgwf24h5/6N6lI09ee22qfQWaGMZSXXPd9VeO2dveevTx
06Pog4aQJGNMCj48B8YEYHtrd8K+cHZvPEfito3LR6oSwCyUnQwM1JOG7tySwz3Z5HTdgB8Y
y0ahT8xgo8AmgiNGfa6udvSiuUOJjEwAWjWBGAIl1UQiPull5UfFKPocwigAAIeuPnno6iWs
Ws+yracevXT6a8Sm9bGCrPEBjMk0obOb07rvWCOkmIJgFbFtxDP7JvVyUkkXprG2sNIz80Dz
CWvyuUUvNJlhZtEmCkGbKvVsmrb23I4vUtXJylE1aSkDhXnwABh8zK3v297qgEMlHXYl+0mV
HMMw04fPtY0WKgqUJjXOt2uHMq85yxAJMuYTq3az5mTtaLdVpGDzA/s2utaWnQIwtvP5vIn3
np+sFPKig7mqx6JnwaEK+KCgI5lpACXZ8j4kYYQgEBByBGegVGQCJgEPswYuVsEadAlWCsIA
4wkh8lwSqM6CIkFmCYAmlRIxG3RWo4/WoUHwrQQJ6LDjbBAMiQQxSDKXtVcWRTgMUROgSZpU
M2ZGbFtNAQA5ySJ2YkQ0AAnUGM47JRheXV/v9fud3BVlXnS6mtL6vtUscxI8qBACXe4qo+Tr
S2eeKjPb622ISEo6nk5CbCgRMZCBNqAXHFVsGQvkU2voEETo2hVSwEcnzW4rKQEgrubiWq6C
qsaQwKdk42I9CGsdRE2bM91Bc43hvb1WCTCpT7g7hZVuO2LdVxcnSrqg/rNNKLrFjV18fNQq
ZtdZd20bd1L0+9aHk81rjh/tHeycPXvmib1Z38GRrvQtTT15we1KLdk6+HmrbFb3Hz3I4SmA
MK7xUA8ZuJPhjkch2x0e9gBFOLee+5nXNqood7F9Xl+f9LnNXUmSm6quNVHbxZizJoGDK95E
M2pj0/hiYO380Z7ANav4lC03W9POK0ZlxMwQKuwraa/ODJKJXoE47zh0LIBsXYejgRhBUYMk
6317eKWsjb3zwccPbfSNzSbVLOutzLGY1M2uM20Ik9lE1M2rul/ac1ujPrVl5i5sT/avD0lS
TFpYPJqlA/BNGOgK6P6UN23cm+5ESdtbFZB3zu3t+JwhtyZJy0ZHs1lMSkRRcWVYApCQjTHp
sgpWjLGeTj/18U/+zR/70WdON2950xt+9T/857rxRX/5XH/bdScvPZmm8zl5Q5Y18kpB3czc
ekXaEADuf/DBynvwAYhvv+OrMUbzzavyq49f0zbS1C1FIGtDDNayn8cHZ/iZX/udI7e96cYX
vfh/ONldffK6q0/+rb3t7/njD33gg+9/39betA2x9aFXZDY2DmQPURQVn5PS93/Wdmp9dM+v
5mbcwDylc7N4at7sXjx/ZRvy8VOn5tAm1ZSk8f7EyWuvPNrj992bNE18JUlVIM+dRInP0WIe
26YROwuUJb44Cf1eHpfdX1XYnVAIsFOJBxehc7Etxr7uRqobvsBmr/I5ZzuVf3TP7DZUGMja
5V4nJJnOkjq6NK9XMg5gxXCTYgCuAlMykjgptiJRJEaieayeo8T4p7TdSbVZc92a6TyxMRil
6HfaxocWx/PY9TT3oMTbja+BqgVmOUCnAYNm18PeiC5WEIV8SqTQtRRFKi+EOq1Tm3SQ4bAN
0TdTyM+NdxxUbdLVfcOd0SQpG7ZlUVRgHpuaS54msxpYpnOvQhdmMk0uRL3uxPrzV3qgfvvi
9iO7utKxszrkwllgw9QKb9fUAHXWBwveHGKyjkzHxka8xKBNI82lJt291/SMcjVSxhgUBmUC
bTT6hIsqQCJUBKNqAMa1ZgY7GTCBJRSFWSMiVLc4F5o2gkCC2l7uwyHLUHsVlUEHOVAMZAmx
IFWIUXLLWcZtCkZBvZGIbGyZZ+xj07TE2MbU+iQIi3WUBYLLrc8KDGjQRzGOytz4BCkyI4II
MVlnyyzbmc6qSaqnWmS2Y1Yl6eZTF7sn1or+KggYAkQGFUBFw1cfO3Tu/OZ4PCPLzKSaRMgo
Jq+iwIxK3LEUVJOm9a4xKiFhmGtmpGs0R9pr4jRoldgwZoA+2MxIk0SBAejIwHWM7lZkMTJZ
AJnMYsaAgE9uJ0PUi7QHTZ2yrvK92AZ2RnEGbkhwk80HKPc0syzrnrrhxs0vh2ye7d8Yrq8f
vvMrn9ucz2ZeHRk2PA3QNmoZNwoSdBfqYjhYZbkAEEpLzBCg66hpYdBEON7zT46DkflepW2C
lZwhFYWRY+ZSqM1WaCL6x0fScd0IEdEPHGUIuUu90tywVty5Bf087e/qekmDQjqZ5229d7O1
jIOem3hFVkKbxJg2JPTNxko3qoCaXuYme5MKXHBoWCzKhc2dvZ3to+uHAsqkib3JdDbvSQyj
xscJjKczCFQ4YrXrw4ytYUJHNJk3bPOEPGqxbtp2ukeDlev42QD3e1I2qlJKqW2qJkKdGEwx
aUJuXAewIGZiIPZGE4Nh433Yit3+oD92NmXV8NASKSkVCbNt7QzuuftrL7zpRU9vP3zo4Itf
cP2nPzeiUC+fWoypxNz3WK4xkXXWcrcQC3rdDUugdPfe92AK4mOwxu3sTB5//PFTp74pRGPm
a5//ws//yaeoBWilnxcEYXDgyCOPPzWq2r/+f/7Vf/Ur/+75fwraXwBYWT/43d/3Q69/+3f+
9q/96kfe93uWoJ5MoiFwRpR2Z3XaejYQ5n/Zzs31rq1w3UauZC5Mmyd3KmtXH3zg/ldc4b1O
njqZ8rJpGpF08OBVR48dvfJoD957d91K0wgBqGoTNKTEdrmv9fPqwvmpNYYMq9jxJC2VIxHV
s5szsW7UyCTEjjNTcaI6i1BH3vKmVTMJRMbuJN4LsQTK2uWZQ1GaxWwWIInutVBHQBUEqgR3
L85LUqE5CBDhzEs3MynpznOQcv0prVaaSFYnqFIYsAhQBOMlSQyaVB11C5tUV7o9m2VtVVU+
KXATACVlCDGFSY0+pQVH3l6QjJJDZNCcQy83w67rOjtLnp3zTa8NsU26N/GD/rpGCTGGZByh
A6nrGGMSX+UERNLv5RsuZ0QO1Ww3VD60Ec/TYNRY1JY9kdeYfBPqeawbQQGKSRU0s2Watry3
g4jzeuQlJVIAPTeDQY5dAwlUEgBAFLgwFceoAICAiAbBIRgGwxBE5wENYwqSG+zmtDtjFHCE
kxZFAZQIgLElisMumDkDqG80RjFkJCEhdItSkoqCkuTkMGIEikk0Jh99G2NQkaiqSkxI5AAY
wNlFCzAAABMmRWZiJmNURCufiAgJfOvb4Fa7nelsOlV1hlcPr5e5iVGZkfFp3RNYyN4smDEO
HNrX7fUfePDRyWwWUlJkhSiqGpEZBiYd7LMPadbqMNK8EmdsZrTMFATWMzupYJIiGIzAKpg8
IYFhHjhNqpogBJiLqopF6BZlnlFGsjeFtYIzls2ZEoqwO2PEtrTh80u+6RAd81oK7oTmc22t
ZefqOZ7bSjEfunNPTref3P+CVx0ZbtxzYepFHUEmagmDok/JkHHRrTiB7TOaebDgGFVtibFN
4OJOB8E21T4Sl8HmVDNmn0xS9qI+hC7EyswYwSp7pGmgHqdRlRqDIeIowrbka/vW9rnN1aJp
okqNlvxGSXmnG9raS9xtdc+jKs8m0aQYMVQWY2zrXll0rYZ6tjvX1qfxPHnvDUmMqQ0yHNJL
bzo1G+1BivtWytnufHzhsZwBNZV53iQ+v1uNGjnq+rtV2N2Z15rP2tCF3rhJPamNdm6+gmTh
S20GGSuoF2xFfAzGJuesy0rU2IpmbFrMPAQfowMIImcevJuMFUBU3Dx3ZsmUBDpudjKp3vvh
Dz3TewHA2970hifuv39zb1uXdSvfc/qxx04/ATESaANUN2Gjm73hjW/MsmfTDI5GI+Pra48c
EDaIKMGfOXv+Wd4LAF548y0f/NAftREsJIeSVB/fnFRRrbFB5Eff/e4f/9t/68++451/yolv
bX3jx/7233nVt7z6F/7eTxFAECGi0uAMdd7+b0smft0EiV2206i1gMauDvrjhHffffcrXvfG
Z43s9XoHDhy958HTBHrddc+GdSzs/rvvDklDkzJGVU0MIODMctje1MuZiS/Y37yv6HXsLGK2
TA4AFcjX43mTaWrbGE0xHHS3LpHRFEOUiE3rZ8xDR5OqbnwwgKTLwz0FEOsciDOWxGfj+Sz4
lYwbEVLtMJiMprO4kpElHObSGjPM/rdiLza27BT9fjnd1f1pTAQNzmWtd3B1g7ljcgtkJcT5
3sVqd4uNFrmCsYIZW3apPj9pRtFa1qjxQlMnpJMbK42fXt0tcjC2dHOP89q3QlDN+qbICzP3
yeV89bF9EML2xS1kOL6f+wWkiCIOEIENqjhHIcSUAAHY6ZmJ2fG5IqbkHaed2W4U38aaQZwD
H2UeUAQM46yZRlFV2TdcNTl3CGdtbKO2UatWQ9CkEC57L22jVgthGAUFMExBAFQtoyGVpEBo
CFUgqlaqEqEkZxm8JAOWCYEAUppNNSYFpaalKOrcZXIlRI1JCFFAmxiNBcsEgIYpaRSCpJhU
GC9r0xCBIxzkOBcIXpmQiVJUY9AZMEhglDABKiIQLQiClAkc86Ds7FsfOOdAI4oyIYHKQsZJ
YcH0BAoxhLy0N9/yvCefuHBpc7tuW0EkBkDt55SEctYoxJnsRRjvpWGOzqmg7VhyGezrGzC6
U0OooHA4KLlXwJN7cdqoNeAQkuBaycdWYXusEWzyMbS6N6ehJWOwjbJTszBH7jwI8oJi5WU6
6c2bC2C+mPemmo6u9va5Dszm47MXDx9cofNPDIzT7TNdmqx3M8ftE3vCAQghswYA6wj7O7pW
Bi+6aGiJiS0mn0IbEQESoFUpLW61a7XWQwMFYxXUt6KAEQxiuVBFcIToZVLFhokZ9lpVysbc
I5k3bT1nqJM2FfQdDEs5dPBIBU7qS221I0KGcNAlo0hpQd3PNsSkjqoQA9io0rRxaxbKLLNZ
6QwXDu97fHvVtv0DK4+M/ebedD6fzer68GpnTLxXC2c9r/T4ThSFzBIT7OsVnSzO5zRqqe/j
8903+QwFeKq3rwk89WFu+2CkXOGmmqQ2er8I1wma6GBWYioghUbbEHtO9vUktPUkmr5ZRmap
EpqJ0fChD/zXn/wbP/FM3/Oyl7/0PX/vb4/ny8EADrFw1mQWYsyJDTES3HrbbVeOfOD+B7d3
dmOMUVFVEfSOr9zx+tc9G8V366232TZk1ujKISw6IOn8bK40cMOiSUKGfu5f/vsP/slXfuQH
v/fWm5ezVFxpt7z8lT//b/7d3/jhHwyNLxlWHblhXi0jrf9fs7Wcrx1mFoVZmW3ocYHp0v13
Lh38vJMnv/bVOz3Ijc9bcv1t2z78wAMpCYpYa501ZW5BzNAt9yVNCJPZzOXgRc+PqYn0XCzM
oW0HK8NeVlyaJpMV4dLZ+XxuIY9tnGOL0Q8JEKExMG/BWLNaLMcc5hZPDYRZqwiTltdyWCud
lZQZV3ZticGUWevTxoppA9V1nAV36MD/lkKKsa6tmwBRQVcHWYWweuRql/Nkry5zGs/qlV51
YRod1mWX1lbcpAoXp6nTz+eR6xSmsa3amFkDYDesMcSr4AbFMMSIpvA1MOJKgWulWhNd5lFD
XbsEaQiXsgL3Xe3ynMgCqkCbWBQJFZRAGdQ4UgG0pmmjb3Rv5glVALfGlxhrZmQGJcuCjBqC
WsMaICgkodLB6mAwnSWN07UO7c0xgnZzXC/N3MtOJQBgCQ92WFQV0VkMQb3AOMKshRiQQDPQ
pGidaT2EhA5AkX0EEBSwAhBFEPm1r3lLElVIRASASXV3Z+fhhx8MIcyb0EQpM04CESCzaAxT
QssaAxgAAWBCAmBERSgYC4urBYAHHwkJXvua1x45fJUx9MlPfmxvZyuIICISMqMmQNUkkQgW
/IWWGJJqUokxeWlqn5KKCOg39JYXTcwpqrO2rirfRudMEgkxWWVn7bgFVmAVce6Vr3utI1Dh
xx55dLy7lbOu9uXmV7394jhORzsP3PM1JMoQrlnley6F4OWq/XhkFboOjJG9OQ36RVObWU1J
tE4qiAeHxahVEe3a1kPn/qgvQ/eAsQ+UA0LcEL8P1VZtZrLe5qVy7+JZDtlUiqce3enVuSsc
lMMiJ+BGQh1mgJwVQ0Fpoy85LFAHO3XKLQWlkrBKzFYbz87mGwV2AeaNiKJho0oqYb0DU+Zz
0zgWtKhNEBFsASRSZkzX1rmi982OpItzspxygwSmTWTTaJJWIJWkjaMIbC15I4pezaBjMbOg
Ootxf78M8xi87w9ME6mJfne0szXtuwE9tT17strtrR+cNGkeoojvZmZQWGtgbWhcjltzWOvT
bEpTBS80mvlVclFT3TYvzTvPapC9L+V3bM3AZPV8XhSlr2fGZcN9xxCZxbdNveqqdl6PxmNj
gS1HzA2blMgwX6iRGcLS2U2Foz88zHqd+Zc/98lvef23Pr1nZW3t9a876b7yAC+rg6wXsbOi
G6VVgbMTua9JqHTLi2+5cuQXb7/z8XPbFsE40phQ4Atf+sqVw06cOH7wyKEzFy5cvHDRU97r
Dw72bDUZXxjP+sNuPaoPFGH39Jd/8sc/v3/fkXf9pT//pre+1T23KOXTdvza63/s7/z9f/gz
fzchzRK0yt3i2dHhws6fO/v+3/+Dbpkzas5YNz6z1M1Mpn792hfd+JJXXPmRzEhK9cm+YdJR
296+Wb3q2Orjjz5azedl59k+8vprr4ttMJm74XlL+uEeuv/+hy9cqkMEICBWRUyxm9nJeHme
s3B2Jedex+45skAhpbRsmSEAd54+e2DfZG1lZe5Rdd7T1HO0WljDeGqFztTZesed32umPkVA
H2L1HJW2EOLe3rTMaXPuL9TIpn9gvW+Yh5k8ujlb7RQ42hEJ3aI7nWPTwqieP3Xh2bCjhU3H
o53NC3mWKSCoxiRIxMyGISb1IWTOAfHuzs5uC23dgulMd/DQOqYm7j65NR5N2LpObi9cgnmd
nIG6sR0jTURG10zmOVICWuv2sxwyg11nW9EmRkdy1ZAsJ4GZgIgqofokQSQ3Js+sqNcETQ3e
KHEjYqsml5TKgpwjVdIkKWmGQqwClHcpz91+Na2jEpKztNo/tu7aJ7YuzNs4C8knLjK0Blov
zhpM2rbUywREmxbqeep0AAh9wLnX1Y4OCpxeTg2oXfR6MBBC4TAlqLyyIihiYiDhhCFQzhg8
NCIJk2WnoKJRAJJqE9N7fumXr/z9t7a2fvxv/vVPfe5zxpEgEmHB6AxYAgtQWGgBOamBBZee
MkNSWikxY+gYmAYABRX97u96x2tf83oAePSRhy5cuDhvFAAIAURBQaL41iNAZnh9bf2nf/af
AcDu7s5P/s2fmEyaug5JFAEX/JwioqpsjCrM58323o4PbQKQpElEAUZe+xZCwDaEGOGag+s/
/Y/+7eLr/OGH3vfP/9HPKIeVTufv/cIvAcDnPv3Hf/cnfhhILrU6rzUGQdR5C6NWplFCYASA
kp7aTbtzRebdRjouQzACNWFByh3wnuGRglfVXNVRx/mwTabyXS+2mnqNZ48f7UdzYfvSytz2
Bt2A3XYiQ8WQ0lpvsGPNbjUuyBdWk+goYjAIDAHdNCJAqsWRtiaaeVRu677TGOKkicFS5rA0
TMSjRvo5GLKtV4+thMYY9AmRuI0avFdpo+DQuX5uRm2oE6JXlxEZNjGG0CYfxkLBlqsUTRul
aRWRwE+amPJOf5rsaD45v71zdGM4m449ZrOmvbjnW9fu378vNd1Ht1tBzgyLy1IMzHavTmXf
bG5Nap/6nQNNkKr1NkR22TQog1qEl5TPnok+2+bT2XQwtBrDbDIy1sW6su382Krtw/ZWjJlo
A5wPijwvRthhgQ6ZjNrx9Px6NxJFhOWYNImQWZNZ/NAHfv+Z3gsAXvNt3/XBz/6ULJsWp1JN
6/pgh3xodyucVP551x46df0SIPgn/vBDMttqkfZ1YYTFtE1/8vnP7+yN1laGzxr5sle99Nx/
+904r0IcHVx1Nw6zJufNnerkifULm82hle6Qmq+Mqo989o5PfP6OG4794uve/JbXv/ENr3gO
FZWn7XVvfstv/vqvnX3i0R3R8bzJw/bSYQ8/+NBP/4N/9IJj+zsGOgRfO7N9YqNzfKV7IA/5
zW9Z6r12ox+BnPN8uLDbURqmz49LH+X++x+49bZbnzX4hS+8wTlrjLvhxiWx14P33rPS71gX
DxJfd9VanVI7a+fzyutyDAUR9Xt5kEh1dWz/ig/W8jJ8jWq3cG3CnUlVFp0I2ETwyhGYUepk
aq8zB0wYo+bGdAwiLD9jFHhygnlNZSeDRFNBnLU2Ky42NNPOisEqXJKQnjw/94KZy70iPoe2
6Wf++A8/8nv/vpk3T53bliTjYGfJ7u/zRpFmLXQyjCHWEafJ7s3b0NSKzRyhbWy+dbE0JnM9
RoQASbUkZJCsxI6BwoAxihgtSysYptq0secop3ZW+bgQLKaEnFDBAiqAiAKJqE7qIEGYIAIS
YAjKQKAYU0DAxmvwqhTzTC7uMgIOe2ycjdNFIAAd0szgoAuj5Iwztxy/6tLI331uMwE3IWWG
FsgEwcYZncw1Js1YvdEoEANS5CSYalbD5CMAiKIP1ggpUFJqIqAmCIQBQkwppWgNAqqIMegR
yAKpOvY+AapG1aTP8cIDbGxs/Nv/71de/upXbY/2kCBjzA11GUqrDKKKbNQiRGJQcEZ9Uibo
ZmKBkmBKYBCUib4OY45J61ZFwTBaJrhc5DNtE1hw0OtedWzfsauPA0Cn2z10dGOhYns5XSiL
0hoDKJGp5nOXdSK0W7tRkmhKZAGEp57QSIwQopY5188ABL36dW/8uZ/96eij2sv5KkIsnUka
XKYzoRKdapoqNqMIIN0cSkvjNt+aVWOv1mgAaiOhcZANjUYR36ZEzDvSdut2v0RfhH4N+biO
DmcZjUwWd3dmrI9TGkz58Nky5jEvOEJZCU1TPLl+/IHxRcJms4V1FxrIBBoAqAX3gnVIEZmV
2mmLxkSQcZuLGABMEupgrJU2wjyZiZok3hiXNEvqU4AkCuAXqdfooyEW1GkboyAB7jYx81Lk
6GyfIVO7ahG89xG7BhDyTrk7m5w5ezHvdPcDj0a7RloGMcySgis61pqNDnRttFkJUBe2GUu5
J2rZjJuwXYuqXqrIcpl16FIFAW1KKQXvBXKrRafX7Vz7QvtsjokvhALi7nyyR8zMtmdQWr9O
l64v1Seae7vRo1bs6ZHJynJN00NPbpvU8P6DZaewzZwQS7Mk9mKE1VxDSE+cTw+e/aNqPis7
3yDWO37jmwP+7Gg8Wl19Nm9hQljvsmPg3Jza72YRX/riF18Jyk8pgcv2X3MtqrZKPctDlUrg
qfMXrvRez3vhLd33/t7Bg/su0eqTTfPEg/ONgleLMlV7+8v0xK47fSHUkA8ODsetfu2Js2d+
67d+/bd/52Uvf9kPfO+73viG1z7HqwoA8M6/9K5/9g9+FkEVYLmSCEBeFEQmSgxKPkGv5EBx
FsMjM3jl+nJRoxCkSZ3TdfZYw0G0KbLKy7qBB++/70rvdeMNN/TXDmRZcfz41Vce6o6777oq
wz2vjTOrufEBL1hoMsed5d1pQSAgJ0l7LZzemfdt/znavaA1Bl3fOANZ5hCmbYvGtjFZps25
ZKDzKiTFA72inzFpmoelyxVAxER+K3Cn5gPD/sTjMAuo0+3abnTd1lzXVw5duLh5sOt6eeGs
oZhjtjxzmFLYGbVbW+O9UZXnuYWQia9nvFtBjWY0x7mPZAyTDApnO5khyA1ljKXFjEU1EqlB
QIAEoWmiIe11wKJKEiHxCUY1zxpIom1EZCQiVPAC80TEAIAqFAKIKqAaRABsIwAoIAICMaao
UUVBFUAEE3BMWAWTEBWIOJ3fYQoJMMxS42OaqOvlPPN6NknPQMfCjYcOjVudNqnXKc/vbZ0d
7RgCS6iBNS3eFU0tobelMaSwO+PMupgCQIiJ9iZGVQmwSVLH5EgEpBZVAmQFkqRQFmRYnKIP
iKKq0MsUgKctCsEzdWXf+rqbJpPZi2+55ef/xa93Ot1Op/Mdb339B97/B0E0Z13NIbfqGL3o
eA6OkUgtoBclhIyxdIACgpBEJCECMsDP/PTfQjSV16atJalFZESTABQJiJroQ+Cocd6Oty73
rUuSzTPbqqCyIDtUiYt/ARVEdKEp3kjl20iWgcHXXgUQqWnVB3UOTCbPJF8ty86rXvv6j378
A6OvN420UUd1IhYJok7RYmghqaQklrHyWLcWShd0JypolJBiQwkQWNCRUmjI5UJ5G/aesvi8
xpqqEYPttQeHJ4535u3unbd351P3glsGT2Aw80Iw7+RjERHoFdk8aGja0q2f95VDDWHquQwL
0a9i2EIKSJLC6uBA4mnwTUiSRKNobs08Qpdhp6EYNdhyy7PYws8jmn5AkRCEDCTZ1+vtjDdd
1hVpLrYuhWgJnYGaiipoY4pRIlKDqqHZgdQoZCb4Zrp1oWBY67oaydosY+gb3p373AAiR7ZJ
OeN0sA+ff2o2v3ThFS+8Zj6NTQQBaUP0vgU0HYugaXtSHTjUz6xxWQ7E1maAFIFuHnR638zW
82Sg0/PATHl3BZLvs3b7K7sXRlUTyLrxtFV2h9fc5hS2GmjGfqOU0qKxrtq7RKUilznUpV2y
NldAYBrN5pNaDJtPffwjb/sz3/303rWNAy9/7ds2Ny+eOP7s7pydWZxX7YmVPpEbT8QAPP/F
S4peiPg7/+k3jWH6Olu8ql5JDbywV7zyFe8p8uuKUG/tmCyL/X6I7cXxfG8UQ/CKU3AuS57b
hhNIYU3Zcd3VL93x1fvuf+hVL73lp//OTx48dHDpdPmiF9+KoDnDHDFzyzvYEGB9pavAXiCA
73bdJKX5fBrF3LaMpxgAMjQutR64UiDAEjwSGILT9y/p+trYt89Zc/TYEk0vAPj4Zz832a00
Yu7wC49viqjNuzGJPlf3FduZdphzH2Rnsxm42i8D1yjA+e3d7qRaX1vfnjQrpbFJBvsPSjOf
TPZ6nRJExz60IbDLp+NGNB1b2Vj6dSPQ4PgLes0o7e1lGCGqz8sG7fDAcKODn/vqQ+frhtGs
7T/c72deYDr250fLs5CzWs6enzhj9q3vdyxBdMO6zLAlQMJZwko4CiQVglQasagiDUGKqimA
aAyiCMhIUQRROoaqQKhCSKiQBKoEAZQJFNEDAKIhFIWqJRQV1SSLzCEwchI1xEFAVJNiEiC2
TBySKiAhiWgSQQQCJFJmvjAx87oyrqgjisg8yCSEuvEIMmnjhLCfcdlwAkqAtQ8KedetEgoh
kANJUM9ZQgc0iylGEUKt2+SMJBAAUJUIrSVghm4GfSOiOvKkgRDVkhrC0mrPRQTYrcihGgsZ
Qy/DeauuxIxp/gyCgq5J0fiH7/vSFz/z0Te89bsAYP/G6mqRAGj/vn3f/+7/+4abX9LtD7a3
t/7oQx987+/8B0jRGcQE73zX97/9O97R7fU+9Yfvf/iBu1/6La+vA/6n3/7tpx556Du//R2n
rn++KvzH3/iNR594wjD/hb/wF978lrcePHRQkjz+2GP/5T/+1uc//dmXv+yVb3jrmxaX0ev3
/+pf+xuf/sSnPv2JTw5XVn7wR/7KbS9/aa/f39vd/eQff+I3f+0/qqhP8e/93D9OIA89evqL
X/70T//kz1jr3vxtb0uBrUUmBQH85tfi297+7R/4yHvhaWYiVM5TW6ti9gM/+Fde/7q37984
UNXz++6769/+u3/x4L2PXfe8k//X//XjdT2+/Stf/P3f/a8O4d0/9GOHjxxBhI9++IOf+NhH
Tdv+7Z/56/3BUJv0Oz//z1fq5qnCylObk93JsdtetFqU41mdIq6tbKx4rKs6GwVyihoLK5Gg
nW3lZTnIbVCuUxdkIZYGyfQQYgBUjJdmiloa6yjjFL01ptspkm/rtpUYjSQTZpntHjt2qp3X
O5PqqbHPrGNE58ykqqOktW5nNpWj+9a293bLsr87Hg16HUaatOlAPhlPdso8G0mdUnKWjHWZ
KcuBQxZftRpFLDKgIlESEKLMGrbuwiTOLyW0WRvThUncqgQkJQkG1bBpvJSc5k1rMXWNzIpy
/cCR7e2d4OdMcGC4ckvYhG+eYD9bM5m8OyhJU9diOdjoVo924KmazJcfkZgETLO1XnZL6hWu
qibU73ScccYQ2uAnnZwlaLMMUQ2gIYpxHBJ6gQ+873ef6b0A4Fu/9R1luUyuUHHWqBK5wlw6
O9qaTl9w25IMHhF1OstRc1fa/v37Dxw61vOXDo9rwZjrzFpMmd2qUiBXEuSWQpSyLPZGY6Vo
NYxHO9E3k8Z/5cu3/92//3O/+PP/eHVtSbCyb/9+W3b9bOQYy+I5dM4Qes4KaBVTTN4wNEFQ
IkBKz+FCVp0yaUGRFRWwimpRQfihe+9UEbxC3uW6a66+7uQSjqgzZ862LantCjYHD9oLs8Hm
5jkQda4r6TnyvRLZMCiDgjLsCaTnYKRcYZiPdrlDHGdnn0oHNlY2jhytyZw7ex67A3RZA+08
1Id6vce3xo0PZROXxl6K9MRWXSomb8+em49mjYaLa2urAffu8b4NkRXI8OkzO1sFEaXGxxMn
l1OKDDv2mv25s4wIkhIQjlvtOHAGmyis0QgokCqkFKsoKNGHxjksLKckMWmIAqSIyESGKAaq
IiKwaCImIqxAooiINAkZMARNmhLCLvCUAImjkggqsMBlqIGIioBeBnCrISVDklQ1kWERVF0o
I6JoUoXCuXnrKw9oMiEn2tYilqkoO8xGrG3ZIDIa0wCWw9W8G4hN9HNFCrHpdgdFKC/ubCcV
IjAAwxIK50e1AJRMWuQeFpQ5iHWARtALZCy5kZzFGSoMgMC8BaN83bpr2qgqQaRj0npuu5md
tN94bhMoMfBl0UYAgGo6tkz7963/i3//3tX1yzqiw9X1k9c+79jVx/7FP/57lum7v+f73/1j
f2ux6x3f+1dGuzvD1TUAuP0Ln8kmZ1/zLa980ctfDQD33PFZNOmHfvivvuGN3xDwW9+3cetL
X/KPfu5nbrjhhjd+61sXG4uiePt3fHsbq71665/8k19cX99YbF9bXzt57akbb7nh1379l2NM
3/Yd3w4Ajz766I+8+939/uDc+XPWKqMws7E4r1NKl1+ura1LGxv7X/7K1670BtPm8mpJVWMM
huDn/99//ZrXXj71KqwdOXz0la943be97W07W9M3vP61AHD1sWO/+9/+c17w937fD3R7fQAw
1nzh9i+Awp//i99njHngrruajM9NfedCtZmkGe+tX3OsrdpWcW3zolMMlmRYbO3OVoKpKUbU
zJgRS4PRRW8lArOxxlACgJU8IJgAHMWIUgI0qCmmYHpB43atuS07w5XJZLfRDmgAzM9f2Op3
e5qq9dV1kjYCsyYfvaG+xFZVY/RtCAOWlHxm88La8WxW9NwMoVdmzDqfz44d3GeIGBBzCy1L
EkyihBjBJIHdVle7xjDbrKiFbEKDeuyaa6P4bre7A6ko+izzJ85eAlscPaxra2sHXdaoaaKn
YgC4K0n6vWHZ7b+sOf2st/0zlRtP97qOD63tC1nnIJ8/tX5x2+Wb49QGCVHyrhk1OCwJQbsm
DgsbHW43spqn9QF1CM9U6uOytbmCEsYEjFCH+MlPfma0t/dM+ePXvfq1S/W9XJmLNTvTerWB
pO3h648ePb6cu+9/yl58621f+eP3NwLT6fylt7zgne/4Tt/6nSaSsYyJDRp2n/rjT37i059x
mTYyjymBNTFgiu35J574lX/3qz/1U3/7ysMy85Ej++65Zzcpri/nswVVmPg6RxIBSdSmpCqZ
WfC3LvdeBnFBEpdhilwoaAhSomxe3Dz35KNHjj+7K+DWm543PLik0+uuu+9D4PXOChiYeM2Y
9g0PhVAT4upwOUIytPNqfiEDh+iKomgjyLJ6FSHedFW+t1Ndmk5tRiBpp2rl3FmI0SvNvOSF
pW6/04WI0RZwfm+0Wy2HWiTRzaee7BauWzglU3QHa9x2OFwU1yuKYUdVUlJhwjbIgTUYGszd
cocaRabeg1cRVYCkqgBNK4ToUwopIRIicUopxSBiyOSWASAACAEiFc6klEKSNqU6KBI6Jkfk
U0oSNEFUTAqiIIJEJIQpUVTYbRfVBQXUhYg3ERAqYuSFqne6LLQOkMALIimg+rDoSEopIQAb
RIB5hT60zmgIHGJCQmc7ruga4yRFNCbFQCCakiNNIRipDWWdDAAErEkhzFJIHAVREZwRlyVF
iEQAoABTD1EwASmAAjgDPRszvtwbhSox4pFOPhVIDAc7NEEzaQRRO5l0nAHBlWfoKQgAKOw/
eOjFL30tAKjqw1+7gxS+/Z3/x8J1/bdf+9cf+8MP/rWf+fkbXvCit3/HO//Tr/7rMB2/413f
v/j4x9/7W01Tv+3Pv3vx53rXyiqXX++IGKx0jp069vo3vBkAtrc3f/XX3rN//8Ef+L4fRcS3
vv3tn/z0R3/393/7nd/1LgCYV/P3f/B3z50/+13v/O6F6/r4J//wy7d//rvf8T0nr7n25S97
1Sc//dFLX9dVuOaaawCgquZ7e7uOMXMcgkoCEuKv5we+/KXPveKVr11ZWX39G771Dz/6wctf
VqCt8bbbXrJwXbff8aWf+dmf+HPv/N4f/L4f6nZ73/+D/8c//oV/du7c+cOHD11zzbWkYXWw
b+G6AODaa59nDF9z8sSCUeGR+x8888hjWac4npU2zS514u5DD5WjqlQMoz1/0y186RztbmJh
g9eMuGmlNjrLCV0GMWnbhjqAiOQRGKidEKtjYmZFAjQkCNYmYq+u9skxO+vQ9dNCDlrTNECq
Y50ckBFw3bJMoW1bbxxEpsLKbl2vrF9dt+PB8AAZd35nc9/+o7PZXmdwaNpUSJ319bVLOzsG
ARRp2uo4sKgAonO2Sr6N6kNKoW3rytqcUnugixfH81kdNvrdZDghd3sruyGWZdHpD3caeeqJ
bWtMf2V1Zzrv9PvWZcDALt9oR0fsN82VY6FRuXKVTbVgadM1xekDblsoYxMzhwIyD0CaHV/J
9xp10nrFKNDLYQKGaK4p7DUosmBkWWKjWexlYDIuDWcIn/n4R779nX/p6b2IaJax1TVV/NrF
SdPGLvPjk+rbX/W2pQf/n7VbX3Lbx/7gdzK2tpvfdMP1b/vuv3jlmM3trY9/4RNTaWPE3HDO
kpCUZqPx7JOf2v2bf/PHrV0iihhZG6Q2yiQsT2clVUGuPCAoIyKwZbAEkhYSS0ts5FEVfRSH
KQQR6BiAJLGTw0P3fe1K7/XiV752ZTi48jh33vdwSw6ix/aiZcdsey5BUWCKJi7XiMldlhl3
bKWnklcxZHRlpLcwnYdmkppuvz/xXTOIp47tXzdmmmBw5KrHnzozu3BRmABghloFXe/0B3l/
6YPCTCeuPphbLgyqphiTocJZzkfBex8UAVDJtClZm7bnUmRduyxZDQBVCDvzmgkAkYkWkGki
VFEFNMYu2owMGwsGFtURVSJMSeomiqo1DIQxSgJkNEmgEmyIkXJR9SkgXO7zJUtRhQiNMSqK
hITIoojKzElhkUIERU2YJAEAEqoKISZR0EQLVXlARCK2QTQmRjZo2JquqDprOXgyGagY9ZAk
A09iFAKjxgTJh9YHH5JKQqIkC8WQiKjOoBcAUAStPIoAyALMAF6ACDISJiAER2AQLRAgJEyg
PHTu0KDXFOhDbIJkmesZTFEANSi2Xil9Y6H2L3/595n58NHjRCySfuPf/L/bFy8aU9768tcB
QAj+Y7/76z6E2z/x/hte8CIkes0rX7Z99pGVtQ0A2L7w1Kff+yui8LwXvvjE828BgF6OUwdP
V5DZuLW1jUU54KmzT17cvHBx8+LpRx8u8iKmeOHChdFovPBevm1v/8oXAeC7v/MvAYCqfvRj
H/LBf+nLnz15zbUAcOLqk2fOPvX0Zf/iv/z59/yb9/gQ2BB4MMyakFGTXl5S+5D+8MMf+ovv
+t63vf073vfh9y02IsK01pe88vWLP3/t1//91+56aHv3PT/4fT8EAK957bf8q1/65w8/9ODh
w4eKouyu718/chIARBIRH7v6xOpweMOpy9wIt3/hc7abO6/b0qznxYD6UIWQYgzt5mzCTzy+
vra+d/p0b1BMtFnTcpaxlJ1hViJCIrSul2wORAbPALTOmZRElUUNsTWLEqZ4q1UHdCVDY/Ik
jS1FlAQNMgNZk/dSr5jP5kV3iJpSDDZhjB4Ao6/JdROxWgZAD1QOrgpaFF3XzWxIPVFRRc3I
gLG5swxp5jXEJIiTuvb1LMSQUoxiC237nVLmUyOtlaZJkqMXsYcOX9WPeyNpDqwPiShJSsTb
W9taDFP0F598TIn6w1VgfomOnvWqf762U+Hu2sGjcv4G+1Wb5WAyVbIOMweWZOLNhdbptpk2
qU3aimnFXWryxMbiaDZPSODsc81ugADdbjeqjyEA6Iff//vP9F7PZbGJRuCpcdP61Ib0smVp
w/8Fu/nW22YRVJsgPGuWtxVPqqn3tUNk1aGzFnQWgKGK0V+4ONrZ2TpwBdUFAIQ2WGp63WWB
JAAAiGoQJFAEBFIE0ESWXM9i9hxAj6ggaJrogyZAjX7Uum5muY565x13vuHbnt1b/ebXf8tS
qc977r6bJSbQto4EtYIPMTmDucGqWV7JyzqDjYOnWqa2DS1EtLCUV1AB56nfAjGtFqurWT3N
y8IjCncsmoxHrpuQCAFUU9kxKsHZ7DnEViTjABKqVkGBEGdeLl6YZsZawhCjqqhq8L6zgmo4
1e3QLn/mcmsGhVXQpCoKhKhJQkhJJYkoIoAgoLUGkVVVBARIBQAc2UxjggRVUMRMFEwSYIwA
kKQsHKLmpPh1cI4oKLAkTQlEFZNYUmc4SAIVBgUQJVQVEQCFmJIqEJIgIBlBVDbGWGCLzDmT
Qxu9Jw1oHIkXEWfJGM6sWkMhpsbXIcTxbG/etG0bYhIgNMxZZqy11hAhESJHbr0nBUcQFQyS
Y7V20cILBmGtWKhhgUWDYBhRVEk0pCggGTImenInxqSkUgchTIC4KP6lBG2M+TNWcVdfc93T
/3/4/nsffvC+wfoGFcWRY8cBoK3mr3nTm4jtVccviyWdPHVNgZd5dnY3z2bWAMDuhccX3qtw
LCZXvLyuTci7e5dEhIhedNOtdV1/+Suff88v/yKIAgI8Az6iC++ssLa2AQAhhlOnng+gw5XL
wKh+f0hfZyIdj8f/8pf+VTUPbMEa8m0MRiyzRNknl4+oin/wB+/7i+/63pe/7BXDwb6vb9S6
jldddfXiz8ceeUIVLm5dms9nnU73qiNHV7rmyYfuhte/HgCuOXH99dc/HwDuvuuOF958qzHm
1NWnTh2/zOX2yIMPlBslpsCXZHN7dH1/eDo10xSPxXBTUWzvXTKH90Wbj7fGB4e9jChDOLdz
YWgwCQRBY6jYOOL2n+BmF0I7PHIqVLupnYXATWTHwfZXkw/RS0gqGnMR5uQ0AKolVkBVSPWE
VIvU4nwKQCtrB7vrB0UlRSFcYDZlQZsCkrLgJ0IAssFNFQFSCGD6+48ZmxowbtbUWZZv5NC1
TJa5dN2i6BRZkRWWqWPdFFemnld7xRpiErB+st+mth5d1Yetpr00k/7Bg/uOHm39/apqXZ6V
Ws9G1XinmU9vfd6zYVq304ZZ2b+Szh3Up9iAUMZonSUfsA3eEnczvVjjpan3bQOui+gnLSWk
nk6aEOdBRLHMzHOR9pR50evvH893NewymXvuueP8ubOHDi9XxX3aLi+EW69JVeBVr3jVf3/8
n9L6g+GpF77oq1/+PJjOuF7uvQ5vrHXQJJFOwc7AeBIjoImSkhmUrlMuKbPFEOrJudy1k5qy
ZU3bAKAAMYElSKptUmuAAWMEITbLuZPACzZNy5qQjCgYCPV8NOI1sPHRB7925fillMeTyfSe
e+9W0YRBmFLjQ4y55Yxo0sD8Obh3vZ9ouzUWRGFDpV/e7gUAMIq9zWDk4q6x0zifTCaTJHGx
vO9leeYMgKgKQTQUfQzCtBRTEwWmLRqiRT9cbtnHSCkwAygzIrIBwMxqU7cRMc90Wa4aAEBj
gOQBAJBRIUQRVVFIyvHriDpD1ERsQwIkQAwqmbUSUojBoObOMClrQkIgZQQiRLYiIUQVxZgi
ABISEyIqMxJGVbUEBSOjUNIYxTA1AnVSQUYkJGOdYWuNzRDJEXpgScpSezUpRYpzIlNiyqwi
JiGoW4/JtyFe2pzXra99jClaYxQgc7bTyY01bFhVU5IqeJ8SEWRZ7lNAaHKDbdSVjPeVtNrL
kwRYyDwidSizaGYhMpk2UGJR1RQASEtDIerFtrEmqaaSTBsUGboZo4ICJlAAyZ+xevj9f/tP
K7BHr33hq1/35utvvOmn/+m//umf/GHIi8Uz2R2svOvHf+GZ98iUQ9O7XJSq6ybZPoDWzdPN
aEVrBpEuu0chquvqk3/ysTe87i2I+MqXv/qVL3/11vbmJz710c9/8TMKIM9I1y8grXmeA4Cz
7t0/8KPPPG/Z6Zw7cxlxPZ1NfZ1UNEVEQZeRj9K0IWf7jUdU8Y47v3L+/PlDhw591599x2Jb
CFq1qdu9XAGZV7UhYoDxZNTpdI2xpckfe+juxd4X3/DC666/DgAeeOCe4cra1cevOXrwqqNX
Xw0Au1tb5849pRwOHr7KrZXn73voiVCdyPMvaLs7zA5Huaqt3KWzMBiWqlPC28PkZMoKlE0f
W9HEKIBy6eG089jsQAYWJBt2BgcgBd+2PBuH+WZhw+bZi92MBv2ej07QRjIhJk3eQCLwiGIs
M3UNVsxYWKvig2+MtWxYkTAlUDCM4luT6sHsApjO3OajEBEJiEjbgVw01xYzKBmgg4c6sNBO
WhAkQwmw6GEQ0Nn+jJJsa1AQUVhowcqh/bDa6zy2t3p6OwRnF2vwZjauxttorLOGELK2ujH7
pgkuAZ7pbbzYnN4PZ0atVbLMjMSw0HQgAkLU6CjtjMaa4qGD3ZjZrCgne0+NwojIzlryPu3P
CjJLu3TRGWzqcWhjG9DZxLb56Ec/9P0/8MPLJ56vW/CJKesOhm1VX3340KFDh68cc/tXbv+9
3/2djeGQIAkYUczIL+Rw6qY6ft3Nb//O77nyUzfdcssXvvRpDc2TF3eWnvpFt7xEIPkkqdEY
U4hIRvZmwAgvuv5Urz+88iPb2xf39i5NK27UdZ8jICBEJCSMoIgmZ8MG6gSxUYiyPANGhCGl
JNKxVkUbVW2rZgJ2LX/k9EOj3e3hFZ0GV9p99z+YEXuoJTYITK6fd/IiK1pRV7hyZYmIJQA4
dE2ljaACglYICsugJQjQgfZImSR3qDEfDhQlJjCEzrIhSeoVobRk2BjCWeAZyFI/GGOcziad
zGQsIrpTc+V5vddF0CjiLBJqCu16nxjdQxem5HrPwY8PMUmrLqJLPhEhAAkAGS8pzRsLpBJT
N4+ilEQRg2HOLSNEprTQi6ySIqIqS7zcsSWL+hFdLk1ZRAUADQRGRENURYxRAhFmpmTqZNxY
JmMLa50YRUBiZtu0nqVthEm8wwbBOUgWQ0YGSQhAUhNj2pm2k1k9a8K8bg1T7gwzlbkrOzkv
HKZKSAlAfWoloE9RkiAhI+dZ0e/2ptOUWUkJo7Q9ZiPkvUWAeeOhCzHpdB4tiWICim1Y8M6n
FGito8OMLsy0SWqMEIBlygw6B6sdo4pJ2MekSfrlN4KvR778xzvZ+pfuv+/U9TccPHi41x9c
8/ybnzhzOUfX1NXnP/lhZfv1KEkff+xxosszhqD1pquAkS9viVQ2tiNfz6grEAC+7wO/9/gT
j77uNW+65sQpANhY3/fn3/k9vV7/Ix/94DOWVos+L00pGWNijB/9+EdgwfkLgIgPPPhANX+6
8oqAGaJXUQXodXg8hRA0JAnh8hGRAUjf9/73/eiP/Og7v+u7FhuZcWXNPd0b0+24Ms8kKXwd
2ZTb/IlHH/LeO+eOXn318ROnAODR+x9YHW5cffya62984YHDhwHg/ru/VqfqqkPXWC32zp63
g9752V4P2pvWuneGaof1mODJrdEJY7eg/vIsTC10JR3sZk+AWGQgSKgKiUlEAgDd8+Bn9w8O
DYYb3f7qam+Y/P7op+e3Hz909DCPPdhE/W6ndIQm+KCSlFwEgyQQGuMgt0oIrZ/HSw9nTMwm
Ue46w6I7QGOjn4XxZjUfAYzAkgcA20GRGBvLwUz3zlz+/Z++D6qL26Ffvyt6mctdLw9EWFTf
MpPVlK5eXRkM1p+cZTveB98yo8vzmBIgW+des1E+a9F7P/ay+smD/XNBEIjIsiiqEADGpD6h
UXCGsqij6bzMMyRz4uoj9WyOMieSNkIUNs6ocXvVkqBDQUf1PDEDO8oHIVW+aT744T/4H3qv
waA8emyje3DQhO5rbnzR0jG//R///Wc/9vsKLmT7HWqX2xhn1uS5aRgDZh9e6r1uu+3WX/mN
FUbeqWNKia9owr3pphdff9NLTp++XyJYaJihAQdRSivf++4fW3oljz1y/2oBWZYnwH3ry70X
M60UNglG3zgXiaCtPRlOEZqwPK5pEtQ+FkUR0gL/hgnAxdpQlAQP3HvXy1/9bMLDK+0rd9w5
rlsAK+pAExKBkk1grM2QnqvjVBUc60pJBmUBkMuXaWkhwqn9tqolCa8MO96ntvHElBQtIyHM
AzRBB5k6g0zkY5uaBpbFcQSKZNHkg64rjcq4BpkVyoCYQBkYkW2WERlFWel5a8HL8uhZwUTJ
oOindkdUAAVUkoYEkLnIRJSxCKiIY0rKMWrySQEXKBkEYURniFmcJUBQVUQTkrZRkqAqtmEB
uGAQMMZx5szCUWUZI2SENssyTYXW263Nmdp6EkWADMbWsVpQy2AYozQhxHkT9mZ13fqm8T6m
zJA1BgiKwpaF63YyBDRMCBhSJNAUI6PCApWCCsyOTMAESKBQZKXLShmN61acIZNgbxpGqDpu
MkOzJsD+bkjipUWgzKAjdqxBNKgIaM9RUgiiC3QHIpQMvY7pdU1uCRSioCqDsnkGTQ7nObJl
m2/vbB88eBgA+oMVePLJtm2yLA8hfOhjH1Gi0uWra+sAsLe7vbZxWUU27/YbyhSgM7y8GvNs
PbtnyrU767rd3tlzZ/6/X/mX3W7/Na9+/ete/UYAeNlLXvmRP/ogfLP7AoUQfJZlMcUPfeT9
Cppl2fr6vkvnNh977LHdnctS5ghgczRsglcDBJFyS9qKYXw6Ay8ibZve9773/eiP/OhVV12G
RFkLnVKr+WTxZ1l2OlmWkgwGQwBo27ZjcGtvfP/999588y0nT1534sRJAHjg/vs31g/A2+HY
1VcfOX4cAO782p1rG4d7prN79mz0fqeatAXcB/AtMVtNlDu3CuYroT18zfGz2zqf7lljzifZ
p3Aoz/YgAikDCLAAEBIApHZ24cJDly6dzoreYLBvODiQ5d0jJ64drG3M9naNetfuzebzGL1l
awxZkyG6pIUCieDMR1aPGB3FKBA9KIxStRXGBWV9RpeoqLL1LM9Xc41+Op5OYlIEo4BGJCIC
AhIoIiARIQIuVu0IgEzIBEEgKUXR3CAjiILB5HI9fb4+deTisOewR35vFkNILit6q94HUaXk
37yRL8BBT9snt6dfvVTFA3rzYTZEMQBnhMxAKBqZWDQZpswQswspTedN28SqmVZNDUjj8Twq
5Xm2uVenZQthRGjFoc8zpyEFhwxQnn7o3kcffXQB+Hku23fwxKSKHFdtkje9+a1Lx0y2tyL1
1PVNsZJSCGRyFxDLBBRSjNA/e+7ckcPPDtpuvumWfv9gJDsZ1Y888tj11y8RDPuVX/qVv/7X
/9bjp78ync0kEpJ0Df3UT/z0G9/89qVX8ief+tA0qMI8KUEzWf6VJKpMDWpLNK1bxtqgtK0C
OeuWwEAAoE3qRSVKwdiGyGzZuE6hItB6/crtX/nTeK9773swt5YQEEGSIsbSICYPHi1T1yx3
X70cT6zaXsGGoMyYQDOzJN3nsvwfvOc/pCiiykwii/LOIlEAl/8DQKBf/fynf/fX3sOqz9sY
0LLM4fNvfOHv/Jf/pqqLJS3BAn4NX09AXMYaEMIHfuvXPvL+PxjNyT5HvfAtf+Y7bn3FKwC/
PgfpN65nYZdX4oB33fXVX/gn/9AYNYSG2RokRBHRIEwsoikoqiYlEQ2iXjkJo2FXWmJDxgAa
RZMbYmvqCHVIfa0yJzamPterbt7nfNLCHouwxhQcSdWE3fGsbn3TBh8SgOaZ9VGK3A76Reks
MxFSaSmkhACZMXtVS4s2ZxFD6BgdISE1oglJBEnRWmlCnLapnk0FyPvUVKFwQKpEiAhE2sQF
6zwQgWFiAkMIAAiQYlpAE5MggDrmiMBIhYGugUFpe71sEYEbUFQU/Samk5QNRC0iNM3lalae
FQowmU42srzT7Zmi0/rm5ttetoBX/PKv/Iunnnp80Zp57PhJKjsq6drrLxNMJyL55kL6NSdO
/egP/TUA+M3f/rUv3/HF3/uD//rCG29eW10vy47qN24uLjJWoKPxqNvt5Vledrrz+fTmF774
+971gwDw//w/P/WZ2fTp0ZaS64C3tshs9Ng2ISk75572XilpSnrvffc9c8qKScOcn3ryMi/5
iWNXP/XwAytra51OBwCeePwxB6GexbvvvPPmm295wQtvIqKU0vmz5849/iQAPP/FL170pz76
yIMu4d65875qLsxGtSObMGL6cjV/dae/1Y2f99NtExG0d+w688iXiXDOUAncYO2n25hgQaQP
T7cpZGwSC6HGON7dGu1uPuZcuTLcx6naf+iAsU401PORzHZ9PZ3P54aaPHdF1jAaZZvABR20
IUUAlJahRfCEAKG2yVc+VbMgUcuyu7p+KiuPH/B1HG3HyW7NYnrD/RoDEgFbJZPaRm1hIKii
hQioo7mft8Yyr+XxiW3pd/K1QqsmdEwzwJAA2+BhujkcmJMrZXXkwIW9qSoaV8TgM5ZXdp7t
Yf54FMaV/5NHQub6w4IKlr5VQSBERipyO5kng0ris7IDmkSh0+vsTnYTOQleANCaLC9D05hl
s1sS8BHTfN62kOKsWxgRi4zv++D7/8Zf+/GlU8/l5yNgrOnCdKoML75piXbJZDLZOn9xZXBE
KdO8dGjEj0M1Ds22NTaSadvR3XfecaX3KsvihmP7H7jvgd29nQ+/733XX/8TVx58Y2Pjt3/7
N/7kU39819e+OhpNjh09/oY3vPGqo0skYABgNpu+90Mf9dI10gbJTFyezYtJp61YRmAk0RA9
EIpIZgzxco1gkQRAApgUIrL4tt/BIos+mTrSl2//8n/nB7x80hjvvfcua4JjJkJQKAnzoljJ
e+MmzoN2l5XxAMAZLpztFRlqcM+pqwyIuLFMGedKa8ab1x/OQbW74paqaRdFcfLk/1hSEgCG
+w8pu8LkAsuJKPuDlf5gZemuZ5n3rTWkCjFpE6QBiElQ1TAjJiYqFhMZWWszh2QFEqhyJgok
sZvpqEogTfSejGJQ0tjJ4tVd280qApm3Mp1MzuyFc6O2an3jI6oYwyFJkdlOka0MrDGEAJYv
a3p0DS+4EdacDYKqCKStIUMIzFGiZXQEPYuWYeQxAPsEnOJqaZNPZyJUTTOO2rQhJrWaOsyM
aAiJtJW0cAqLW2AICUEUokAQIAJnKCZ1DL2MU6KMuTCQExhXiutqjMiKGhVoQXr7jftrByl+
U3G0LDsA8MgjD22s7yOiN73xbXd89UuvesXrAEBEzpw9U9X14088euL4ybLs/N2f+jlVHT7z
rn3TI6d7e5cDple96rVPnX1qY31jMXhraxPhGy5zOFx58xu/9aGHHnjo4QeOHL4KAN7ypm/9
/Bc++7pXvwEAVPWBhx+8ePEbTEOG2aIKEwGoEiA6x0m+QQfDxM6YBPFDH37fj/3ff2OxkYAZ
3e1f/OIP/MC7AeB7/vJfPvPoA2/9s39usfezn/5MtwAfw3133QkAC0f11JNPdLjYfPzJp7eo
6taZi1THejY/Mx83OaGFyghYnll5UP0spXFGHcnP7Zx7wepLs6xb+fqo6R8GXpF0EO0lECLg
xbJm8XuROMSgKgiIBKq1nzYXp9ubT/a6q92Vff3h/u7w4HDtKkltrKe+GjWT7b3p2BA7a3Nn
CiImQqKgRUhZTAlDMOANCSbVFL33jHG+eTrvDExCVu2ZzBw6aVBiRV1DKMAqOJbMgR3idI/X
jASUMIkTTH5/By3GE6sUNCWg83M6NZBFzJaUvG9xvrPS4ecf7tmyd3F3rJI0hRtd3fnmnNYj
dXy8TgIx7/TvvGhW1t2prqwQC5KPSMYShTJ3wYeoVM1nRETD4XQ8r6tgTBY15oXGlEaTUe7M
c6n0KmqyJbrMFnlIweY5WfijT3zsv++95jG2zXi96F/7ghuGgyXtzPfeffelWW1td77zsLGF
doZos4kOq+SGNPWx9cp3PXD/277tz1z52Ztue8mnv3yXuu6//Z33/ciP/dWyWE449JrXvvE1
r/0fBzf/9B//3fFknmy/h5UnJ+65iM/VECioxCBJEFQBlaT1sW2frVazMCJehN3M4AgyFwGk
TsoKyHr/A/e1bZv9d6mET59+dD4duawgaywRq1gUQTPxMm2j0LIVBwAAND5Oqzr4RlQYlek5
m9L+lDbZ29udNAoQngvW8qc3Pz8ygBh9hs/FtPentd3d3VmdFlEaEhNbY5mZGRRM7qwBgBKD
ahoH7pfczmYkIYAnVBIfoxYiKYkjaWb+/NbE+9A5VDzss7M7lWNtg54deSRgNi4zq4PCWsNM
jIgAjMgIjOCjFiAAgISlkTZoZqmwWIgKmaRocu1yRMY9FSbISboGFSkZAlafEIKsZRoIN+cy
Damp5m1S/nrIFVUAVJIAKKMAAAISkkFgpCgYVABwETkLIDOuMKuwY2ZURIi2C24IFAAXnQci
l6OcyxaMk9QCwGx+mfe51+sD6Mc/+Ue3vOi2PM/f+Pq3vvH1l5Mon/ncp+bzOQB+4EO//3/+
yI9bYwf9off+oYcfuO7apR3oeOHShcceO33ixMnjx0789E/+7GKrqn74Dz+wKKJsbl3at7Ef
Ef/M27/zw2w+/qmPvfQlr+h2um987Zvf+No3L8Z/4Uuf297aytzlxSIC1HUCY4jYgDG5UQIg
SCDy9NNOhMZlBj726T/4hvcymbrO5+648+57vvbCF9x084tu/S/v/9hi18WLF3/zN379xcdc
Enn4wW9w4jz5yCPOt4997auj3d3h6ioAnH/s8ercZl1NzthJezAjRuVF8hoY8HQKr07FmHBP
xdfTndnsaPfIyua5deIHQmPn4bqB2xIEgUTf8PQi6BBZTZMSIDAhkEECRJxVO5Nq88LmQ2Vn
OBgcGPb3d8ph0V/rrh2pJlt+Pmlmo/m4Noay1PQzzPKhsgnKUYxP3VpJJAFNEnMgCL5NaZOq
Wtpki0K3z5hWHRuDkHKZqSRjnJWUyK2krVasmnJgRVDGDWmUtY5UkWstcxoRAQAuMvRI0Nbj
CM7DgZXSKQwvzTznnW/Jnl0k+OS4jWGi6BBT7X1/nmzHJLAxLfqRzP9P3n+H25ZVZcL4CHPO
FXY86ca6dStBFRQ5I5jA0EaM3So2gtraorZt22prq/3Z+onaCigY2gRiAFFAsFFUFETJqahI
xVtVN5+80wozjPH9sc459xSUdv+e/vO3qp7nnnP2CnOvvdd853jHO94RpEa2QMKMQKxEdRvP
PHA+IvR6x+eLS1ZmMWoMSRzG9CjrcwVAJmOUdJ7EkusDIROfvbB12x13PfHmR/dKAIDYtNPZ
YjOMvvxxT3nUHT561/mH/TFpFPkaJxXsVF69IS6M84pBcFGlD3/81kc99ulPf9rudMaIcTJ5
+Q/86Ot/61f/uWH8b7e3v+3Nf/gHb2SDTkNwsGpnp+nio+5pGPsOYuRGCGhBaFSNCqrCP1fv
1SvyYS8r+zlDE6IkyedVKgcDkBhDszPzd99995Oe9KR/YXifuvVTMYSQEhv2qg5VDQcRAjAE
Q+s5PXp30KVCT6/CuIeQGBEMS/bo8eH/6eacHllVJBytPPqb/T/fVGLwXSbv/6o7JQAg297S
EUUDEpNov+yFmEIIucxaidCGjGVom4GTAVnvNUJqJdWLSd16Aun38nvPbtaNP7rUU6Tz67vW
0NkdMhwRYGWQH8v41FGuEk3a1DGqrQ8oCpAaHxCp75iM6VtC1ahQWM4NVE10FkuLKBDYWGcx
g15aAEVI4BNaUsuw61VBDIJjgpBIQRSJOiMPUVBmcgzGSBMhgIoq4p5HHCJkxIgSFbxAUoWu
oyMgIhrEvjOakJCASFwWi6G4AZgEqgAIncOYysc+9D4EFOIge51IPnXrJzoCDQGIaGt789Wv
+YUXfuGXnj59bVmUOzvbH/34h//p/e/tRnHmzAM//ws//YQnPJmZb/nUx5/1zOd26BVCBIR7
7vt0XdcAMJ1NEOE3f/dXv+SFX/H4x908GIxiCGfPPfye9737vvvv6T7K1//B73zRF37JYDhq
2+bCxXOTye4vveoVX/rFX3bdtTcURTmZ7H7ikx9919/+1dLyoCj43e9+l83y9fXL1hbzRcwd
OBabKQM3bUgSo/o/f/vbFODW224rl5aZqwcfuvQHb/rTpfEYQe5/4IEjR0/O54vv+Q8/+LJv
+aYXfOELlpaXp9PJRz/ykV9/za/4et6GJZ/gvjMP/NEfvCHPs8Jld3z4w7P1jS2GP/zj1x+9
6tQo75/5xCdle3N9KKnXs4BRk+754YMqLhTOaXpydO/RNlcanr/vcYP+3SzvTnMl08uK0004
nuM5UYqQRFQQAEwCQbSEBRsBAFRFENAEKig+Jd+02/Xswua5vuuNypXx6Mho6UgxOl6OT2gK
bT3zix2arM+qDUw7c1lGSP2s6rECuWid5IMgSz7htm9NnJmEjm0dxU4umgHXmhbSUa4IDiKo
1jDIoBrIDoRpsCgMQTECNVE357K2QoFApcuvIgB4wdbXvtpaj3S5lqmXoCiqzzn2mfmY9+zW
TDSfN75tyyLb2qHNAlaWXVLOMw5B0JVtE7wmSWKMbb1ftH57e6ccDCm31vQhNqpNkeO4zJce
NYJRWCwiVhPKh8J99abERebSLJZv+cv3/QvoFXxigCI3z3vWo8/Od912y9C2Ze5mG+cMSjk6
kqKHZtNhE5If94+vDLKH7vxkVVXlZ5Fjz3zGU59w+vjF9YsJ6PaPf+QNr3vDS172kn9uJP/C
9uY/+eOf+fH/fHJpCTmuV7O+sVHiIPtnnatarzElwMCmYC4IkaKkEPXRSqkAAEQKUvWtJ9dG
UkBNExAiIga1xt1+223/MnrdesstyExMFgQJjOGEHAGvzm3f4Ok1uXrt0VNuoJpiqlphAkRt
5J/zQ/w/3VKSah6J0Lj4GazQ/6+bAikwUdcc6v9qU6Dc2XntOdZGA/lUkFoILE2hLUrQ2K6s
yLyh+x6uFj65zC6Ezl7aVoVeYVej1D6wZS+aOTy6OsgMFzmfGBdlxikKEyZliySh9SEioPfe
ORtT9CEoKIvjgoaODGErmDOWDAsCi2oYDZPGNpNE0rRBhJDZqgIxRsSFF2btVMIRNJGjIjua
j8PGpm9rBXIGM2LLighBYklWUUQQADKiZeaZQB0hKRBwzmJISwOWkIQhCqCJ7Ox4BfvDVA7E
uC5A27tzgKDyx298HSApkSJ3ucQHH3rgwQcfOHyTL126+EdvfP1+r5Ir0X6v13/RV309AFy4
cO7v3/M3ALC2byi1s7MJAP/wj39/+DxN07zjnW95xzvfcviPByz02bMPve4Nv6UA+zpt2Nxc
/6M3/n6Xfu3WOUR46vTVSeRt7/wzZnvp/CXH4CnUbfKJ6ySucJwVDilJ+ulffCWQBWXXWzOy
QJi96rW/Igmh3k0xZvkQjalq+ZVXv/J/vvKVanxijV7bmFZHq7sh25mFgXW/8Zpf3dndOmGL
JcvNyLjB4I9+/3fXsp4JHOrFxSWqnEVBVSgwN0JV9GwsqubMD2kaA/8rpGmbQqrvPnb9AzOC
rQczC23AT0d5jOgumAWkgxqUnknbCVpVVCFkUMX9m94hnFVjDDLRgFqtLpybrV++7Mre2Ngi
y/v9clgUA2czTKsznwrIIrCPi7reNFghVyEmSDzqF+JsbGyMvGhDGzB5MpuNZZsHO7AkeZpH
BaGcNKKoN0NPJVUb67u1yXm1NBd3fdVGArVZ6TWCBgBUUWuhRc64HaZJleL5zYkqPianq8wj
0GU7yB0hJVXpWk37cG7mB/nw1FUOyCBwFfy0wZR4skh1QPVtO5lAqAfDUZ5lxBpDnWKChAIy
Hq0cWTvy2bPDtddeB26ptKE36uflEnFOntFkS3blk7d8DOCfVR6OSxN8++yrl5//7EcXHM7W
z98wdt7v9AaIpg/QBgrJmWqRrCONDZcliF6+fPHaz7KYstZ+4Vd++R/90R/njD6FV7/yFz70
4Q/+yI/+6DWP5s7+qNv999/3m6951Z+/4615jlxEERjkOQJGlTk8us/h8RNXgx2VgwKhIrJJ
shg8gE+yJ1X67G0wKA0BANZRkyQVQYnJ18CgIebG3XPnbf/yOD99770REENMhESUImQsywwU
46Va2ciyf3QAWD22Ml6Gfg87Ra4ALB99dG39/+E2WD42a7FudUFk7P++cdq/sNnx0R1zBBRN
Mfy/OQ8AnDi6AvPNASpC9DFdvLhTNx5ETqwN7zxz2YeYosZrCw90y7mFYVgZFOxslrvMGmeJ
DZ0+sZwZAwCM2HfMqHUbJ43MW4kx9vKsn6EzYEFUEwKYzJSFk4g1SRLJGC1KaSE3XKUrUhcg
ClEMi7ZNjMBJ2gQRxGboBBgxKiYAi9rRnorMq8ezslcQgbMbF8/3nWOVDMSB9BFmYnuGo0ja
q1bGZWO0xUVMhk3uKKVgWC1HCwY1r8Wxc9RfopUj6Jxap7CXG9J9BEJAVd5XBu4N/WBhoodq
fvZf38MVBUDApqmf9MSn5HmhqkvLywD4tKc+EwAuXDx/eePylQPhyuk/Y+vOfjCaLijcP/2+
5F07CdzeH1Q1xZRSnE227rzz3p3ZjBCjqrV9UwyLsiBoYgihacnloq1vGuZiIVXyE2NHGECa
ymWlzKZ5lucgTZBlDYnMhVYBEBVtVs4atbagkHoLf0254re2dvs9KZarmT89XAoXNjKUqTUp
H/anPqVo2KDCfHe3yN2J666a7VTN7sxPtj9O9K9Weg/OqjtnzTG7tHL06OyeOxpDKBCz7Mjx
/Prt9rbcGgJEAQBBEVUE6LxxCJgUGFAgIQKTAoJhJgKjiQDGNs3FzyYbSVVVLFHfun5R5uXI
usGg6JnxKgCGdh6bWbuYYDMFbEOoCWsmJKbIKXcERCZnmYtrxZawC5oADGtIgAGdcGkhnpsm
VOg7ODu3pYknnHpwNmMNNUDoOmyXNjVeM8bC6TzYoj9Gk337EQB4hCfQB6YtMqEkY/D0NdeW
mb3zvvsXARvNNCkknrYwbVWS1gnZZlmmvpcT6OrSWNBKakojRelCiDG5tqpuv+vut/z52yU2
lkRVYtRGzGR3fqQsfCu9OIHdeQy9YBjDLMjmQ+fwta967clTJ/cquQE651kyNsVw8aEHQgoz
X73zr/4mBN81l4OO1yCeTGd3nbtg0ozanaqNKe2Cyfpr19tmixc7yUNN04Vf+Da86pd+8XOe
//lMmgBUIakwomW6cPa++c62MaxEOcE//v1ff/Sf/vpffcXXfsELv/gpT3v6yr655+FNRDbW
L330Ix/6q79613ve/a6gUS0FDJOGmLBNIaORM3B2/fzb3/4WRhKFlOKeMw/g/fff7wxn0PpY
zZpQmAGmENtaWv3A+967Mu6rKBFyZ42HhACfvu1jzHGYEQdISYmcJAuQDJEHLp39xEc+9M63
/gmSbUJSFUNoCJIiI5K127PqoXPnCKHxIcuzmEAkjQ2eLjCo3WnTVcsu81vvfddf1FGHDgyp
NQgAonLPLR9YTLWZpRDFJ1WAv3vb65fXjhNhSKhJjQG7r1eLe/owUdGtCnKLudEQVaSzogAA
uPeOT13ckqKgfpz+w1+8iZmNwTwjhv0W7qBddxliWJ/CrqeOnXLGGGYFor1+T/jx2++fQb+k
+NCZB//qr/5auhlMIqSQ2HbFJYgIEgAAkAgUQUG18w3oDN0toyp87JO33PnA2bpujy/30Nh7
Ht5gQmuImHxSJM5zrIQGuX3syRERR0QiGpUZEhECMFvQjIAQkGhgQQQCdfaGyISgiqgGoLRc
EhBiAsgzNgXWFmIUQnYMlroSJVXAmMTHlBKFts0z1BR9QmZKSClJBtpRuF4Qu4xUEmOJs8wu
LduiEICVpOBD4RyIZL6x1aQw6tQ4Qk+aFAGiIlmXjyykgpEQU4rB24wVNTcZkqHewJSZ6Q8w
LxQ7G7i9mmA8BEyPtG7+bIT5jL8o7oMMAKQU/uRP//DF3/wyY8znf+4Luz02tzZ+/w9/W0U/
A7wOcBFxX2HY6Uk/85qdPvUALz9zFAgYY5juTNhw2c91B4iy8dKw7A06SkMVFTChU4mhqbJy
aGw2cAOA48jUnD+vVTCpsXU1oMkSptIaJN2ZtZcqCQBA1D+iMp+2i3lFeuns9pPzvqBseJwu
Jkf6I2lrMLA7WdRJNtvWDgu0BAEEFQpYXR5leX+KbX5iddPNQorvg/CsXvGwwu65h9auvd4+
5jjMF08ge3yN7ttdLHuxzi9AFQwAEvCIKQECYBIJGglJEFHBIHFXDqIqoh5JEzIgRiJBMcDA
PRAT29luM53tAGCWD8rF1fnwSJ733XCQDY+rhOirUE1iPYnVPLYhiBjSjAO+6POepsWyNbQs
lwFoR3oN9UdUkQRPWTT9sHO+mu3upvK6tSL42jG0iSYtxdjeeDTVjawMoJ+5Se1zq6rlPTvu
bAVXHT1+E8kYtY1htvvQYjFjNp+YtBuMPqjFfLB8ZNAb33PXbeMy+7xnPlEBrMFq0S4qv6iq
1rd5VpzZnC/axlm3tnpMkC3KGM7Fxu/MZnUyvd4SAM4TDM3OkoXdRdqcp6kH60pJzmA4sRoX
rczCsqCNKakIW1MOl1SkWUw2zj7Exub9QWhbYwxbu3rs2M7ldUC0WS4p+fkuGQJFNgaI+8Nx
SqmkBcUqgtMYqmivP75S8Ozy7naMbtEEYwVQo6e2VjaMBE0bkCHPsJ8RoiuK8SAvACFnSNK2
3jdRgLAse1edvmqwvFYUhbMQE4jozuZk/fzDly6d3Zk3PuqgdIvKR9JBgcaiISqJUI0iI7dM
rgrAoCqpicknQhB2/RCFcaESJGW57QHKpGmbeRiPBxijiiwVLqADBMQWkFDiOPPjHmxNnVdI
XEKUNoYEySihK434XFtx/a3dmSHJDWbWFNZI9Fs0qjlHRO99UzcDi2s5TLz6CCdLHuXZThWz
PA2dzoMq4lIJltUQhcYbkPHYElPwbAzkFgAxJhUFBfr0Os4qXxoY5bTwKQi0AaetEMJKDnXS
ucejA1wrJcuwLMhmZrJRr3u3ZJqrllEEtnb9rNYzc/Pkq/LlPDZeAUhUb98yS5leM4ZbL+kd
G7FwbtDrIVsgs1YAAFVi2igIYBhLbVLrN8VFQCSEFF2qElsVJUyMYCCBakjSet/4mBvs59nt
Zy5WbfAhXrU6yJy7/8I2EyrAUr9wzuwsGmeMM7w8yFW173gpp5KVmWYBW6GqTUG1NByTMJFx
1mgYWsgNIFEUEIWFT4xoGWNKANTLrSFuQuj8b+sYnSVrUFLyQWJSBBgWhojmAUSkT2l7kQYO
+zn0cm7qIArG2igpxVSWuQIlVSXamsfCogLmRSamXLnpJrY2JZHW+9mMAKGrR7t0UULrOQfC
NkbI8lfZi2eo+H1zIgHUomw5VA0TASSwltkBoclzso6shfzRA+X9qEpRD4c5BwjSBTu4V+xw
pSXTZwpOh4PhjTfeXJa9JOnShQv3n7lXZN+KcR9wDgni91DskYLEzwIp3Y/I9DDSASISY9v4
3Z1d3/j5orr3wQfbJhJS2R8MRkdSDC4rrMtDSoDkMmed6/y9unKN+uyZ5oF78uMn+qdOOyKR
ZnP3/oioNYZzMx1Yf6R8zlXXVPXOx85tFpk9MdejtZzXuD1yuXUrtZRNmBR6QZFmbSKAYWYK
C1GTCAJef/y6ekb9cdnWWw+cfcBYExQeLzAG/FDdnLz56eWiPjp5YHRqeNvFcP99F57cK8yS
vb00v3sEn5rBCy5xAgkisSvQ7uJyBYukqkkVQBFJVXNMFkHBhABpEWDojECuhJiEFBB9ZxEF
ksjl5ajsL5f9pbwYZq5EZk0htYtqa8PXc2NBY2OmrQ5guxbQAU6iu+jzx/R3UhIvJLEegK85
SWauyzHDdlBCTHpufeuuC3V/PB73eGyRUJtIIXLpYhRV1RDimJvLvZV7F7FhWw37l3Y/HqpF
2ygasmxzayBU6+en3iezVESllFKI4kWVGNkKRLLWGhPmMXP5fOcy5/35YopZfXKQUm6kls3p
zBK0MayuMIhmlpiEWYWCpLTSh8LBZpXV1SImwW4lZe20WnSaqKXlPqg6B1zkSMpENk6PrORI
RpHBZHj8KLHFLrrsataIcvD9tBsxbxItu96AZhBmZe8kAY5Wy6ZpIGxB7hcU0fWWR/35Yh6V
Dbag4hwvlelkz0eB9UVbWskzUglMaEJ15tO3zlO7aNRmECOgQgHWAMzawATHlrhpQ92ko2sm
MxQ01SEWzi2XSIhBsiaKj9Fxyo0xZOdePYAiIqJPiGiYACgQOhFrLVoikMSQAHJgYzHWQQnm
BFnG1mLD0JJmRmWQY+21xTzFEEBygymyQcwYFJAJWrTHCgsi27M6BB1kBjSq+OQ1shrBo6Vb
CC4hJID7Z/DEFb5qCEXhMqvWJEh62WOMujMHRLjrcnSspcUQYREg7K9oDUhKVAXZ9rTs5Hjh
M+uqCDcehd1p/bGLifumz+rIpDruzsLWNNyxGa8bK4lphOsaZx7XF/rgRpg4sQabkFrBjWmo
HS0aLFlvXMl2pVRglJRbm6fpbpVm2stJmRSTRkgqmGlFIhBVJTLb6OuqruumrZr26rXhpApn
LmyoQhId97LVpcGiCQBgjGmCAKVemTvLxnCZmcyawaDMDBtEH0JuqLQmRFnEBAxVm8rC2ILq
IJbQElmDGYtB7Fmkrr0JI4mWBrvP2DKiLfOyZCKTEqim0ELwCIlQmfdq8ERFVYmIUBDUkg6c
9gtTOEIE40wSEIWUQAATEJIhBCTs5UoIiljkDEurZBwgISFnLsMB7DF6qgoYYg4SgSBGdgbm
F5ENjMakmqsgoi0KFUACsg6YAYksAzJ0Y9RHBYu9SEw7gOpiqn2w2vtvD0h0n8zDz7bhnM6m
H/3YB2Hff2EfpRAOSMZDYdjhcSA8YlwHJX0I2snXDl/qYMeUtK6aum5CE6q6KTIX2jZG730W
Wx9EgALaDABUxfsYRZlIFRCRgJIC9/tBNfVGrWqz3XpYntbb3EgxKIJRmsssZrOZ2hpXTHGi
pHk7mVj2k2YtRyc61/BwImhTnpmUs7Qh1ZFzw0lHgyG55d6KiTA5v3WOVJIPbugeJPOcRq4t
Snj4vics2Yskf3/LphhGx2dC/PzgLgJ3k2IEUSAkHJZjYprPZzE2BBgl7U+eHQkBQahz70yY
ABLGRKIKBi1GFEBGAlBCUJDUVNvNYnv9Ehjjimy4Mj7eH64a4/LRkSZRPl5iBqMgpcWkuN26
OfQeW2zPFhq5HNhYUhvE5CxcOCYwBIyQAKZVNIadcxmHrp4xt6lphYh6BjIDi7o9f2njqTe5
VAykCsL5ieueObv8yRns7uyK2lDP2xA1+JRESRUJUQCJMJHLTIxRazBMmTMppphkt64Lhbqa
Dyg6ppWhmYfgYhMjxMSs4Awai1sLKpACkCtpra8xaWbUDg2gVQBRQMTOHZUNYSJj2Rgig4Rg
sCt2R4UI4BE9Y1sHjQrQ+Y0SgWICVAw5RS+W61kNcwceA436WmaL9TYFSYKpN4AYKxEdlmyR
t2aARsdlHrl3vqXYVpOqbrrZysHuQslkR0ejFKdNWKSAKlAaJtFpHYqCF01q2shkjq84RokS
ETFjJEpBtOcAkEXZkYiigiZNbYhgWKUB1Yxl5NgSAKSZl06fk0IqCGLUXR8geEA42ccmQhOD
D4YKWB7iZsUxShM1w+RT7DvaDqqoScExgerQiSBF4DrqrE4FUwJ43EgrD4uyFMSbV/XinCTo
7iwCiii0Pj64A9OagCAlyAwiwDzkbYKS46l+WnKggJsVGITNRpDoKcfApHh+BtZyK5RbAiJk
ubaMH79s7tvihc/7JW41QJSu6oc7tgoF9KkY9bFh3PBRJF1uhkS0MtDtgBut3NBfbDTZJLki
B0HYDnjExKUS64U4FotpZ1adD5UxdM0SgaS6DYs2tIpsBxcuX57VTeujM3TDNScns/q+h88R
oipYRh9VAYmJGIApiZRl5gwb5sIZa6jIXJYZRgwhRdW+tTlhDD4CkLARVhUiRNXcskVA5m5a
VgVn0JE4BMugCqJAoIrQ9cBkggSMxhhCQ0qSAARREyQiYURmJARJEAWRwBnIhIQkdwZVeoXJ
c1YFqyYlqeooAJkz1hljrQAwinMmRAXEQd/G8ViRdQ85CKzr+joDKPR6mBQAjCpqImdgDsiE
ZYEiiITEAAlEgEiRsTO9P6gEPyj2OxQAASoeIg0fgRR4JduF2nGFezCGcCgqOgws+0ccHNvB
3ZUs2aGoa+9UuHepwxzh/ig66eTeyPGR1xRVk5n+oOedV5AiP3r8yNp0Nm0DiUREFlEAJGOR
DVtnmLpaA1UlZmTu3fA4VQ2XLxTD8fLxY0fLx9z30MeqrfW8KH0W3AKqxOsaiqE56TKsm4kz
bsQrExq0iTI8N3QIagw5ZO8Uswx9kjZCzsPVo+Vwqao3Hnr47mSUlrPUhGZSGTafqOXzRwWv
4e6xa+679cF2epbzzDC3hOs+ndY9qV8USkmPn7zh5OmbZtPJHbd9gHmvrzSgMqIqJpDuVkdF
0UQASMQWre+K0RWZpDMlREBEJVYFQrAIEuO0uTzZvVy6/rC3UhbDzqaebWZU4VLtROD4Su8q
mUxangbJpFVWIfQJNmdiWEurSRgsbMzl6mMra3apD7PTy3F9AkSYWwQkH8HlWFgkxHsvT9eG
9rrT+CD0sPIqdrD2NB8+4eqdeZViiBIUCTRpl2ECRGuNMRyDTiZirRUBQlWtgw99I9rOQxsW
zE3Ii0wzgLGjnUUCiQVRFBjm3CdA0DqmFQe1l76hU33Z9mGnBgCybACBUB11/ZOIQUDR+wSg
ALGj2EXBIAycU/VVW/lO6o1QmIxEQWJFaFFJhBiIUz/XDKejIjUJnRFjKSpnzLU0S7YWoTrK
wBEID9mrbhqkCpOndHyAxLIIiBhHpY+iKWjP0qyRnKmwqipxDhs7sciJ0SJIHQI0yAzjPnYV
FZ1HQohpHriOeUoQAgUJTRJNzpjGQDwxMAVLEyGKsFCfZKExJapScoxGW1AdOlNS6hXqnMwW
cbHAzZYanwSiT3hyIDvzelS6ApNNECRN5pUlTSJVkC0/252ASCKrauHylKatiII15oFNzC3u
tskxGsbC4VX5ci/Dxw137532ATMvyiDEMAAouRnkWyoolG1LYRiWDDBCz1Rg81i7qLDt9USP
SGXaprFt+zaLAob4SA9CEhSRlAYukkIyUhgC0NIm0jSyhnDfSgMgRxgUMcuNKAggqIYACnr9
yMeQFm14eGc6yAjQ3fXA7lYVFz4alx1fXVpisoOVtWWTOZtSqAGKPo+Gg6quu4LQLDdj7GXW
OGcMISMcGfeTJNxLDGhG2M+ytqqNiiXqsTrSKGoQjCHHeLD8ZwRiYqYE2C1iHYElMHu7KELX
AA2JkRAIgQiBlFQsKKOIJoXIqIxoDDKhYVQFiuosF5klA6im5xBBrTVZZrqV8t50zabfM0Vu
kSmpMrEItkHJ5SbvJ5sJ7EkWEGhvnY0AopplnVslADIodtZoiGoOyU2VgGFPtfxZ4dEjO7Hv
4dUVKDtQcRySaBxQiFdOho8GXfuX+4w4qYvSFA6cJFAPn+zgXwQ4uEGHDj94+UBxt/+axrZN
bWirGgCPnzxmDFWL+qqrjl+6tP3A2e3+eMlkhXUGkZWIEXQvbY1EhGy6FGF+9GR4+IHZhbPF
kaer5dNXP/li/cl2fd1kGfYyRW5DezXZocpZ38wdFYFKNtaE22KbNENURtrz/FPolWzzVFVc
5qN29+KFC3cmE8CgKJiisMGGi5Md0Icsre3qrWE+PHXVPG57wGGDVyUcl3jEGoYIAATio6kW
+tADD2ysP5RSzWxAFRA75pARTeeUkiT4SBmgoAFVhYikREaFknoUAAIVEUgCRHtimKSp+yAq
P6v8zO5y5vrtbGvUXzZ1G5YsnRih051Lc1XORjYhSAxKDAXFIqNz0xhiyh0zswojyHh5qdne
PbfrpnUkpsKyaALEKF0OnBPqbRcWy4PNYwO6KHkW2giWrnpaSp+czze6En9iiikxUecSBoiG
KfhWU0wxVk0DoJmTzEZUlQi5oSZCG3WUU2Eo1LpUoNQxt4gCW7MURUrDkJIK7rZSLJFPaV4l
TZBlpq5DVLCGvCAArgzEWV2fYxKW7pFVSaAKSABtHVU1iHRrKy+aLEXVqMEhOTJEtp/xdatt
jKlVXARgCzHpZIHDDDONPmKmEFUAgFmmUS7OfRSILfcd+Agt64BQQ9Kkk9ns6rEb9IDAnNeY
c0cZ4/Gh62fw8FY4Mcoa31jB3YBBuanToLBLufQc3rtj6sBJcCF9UUBRoiRkyeSqbRIqHDLC
pEp5RmJ0exJSG8rMWkZEGBheLtCwACiBLvdgZ4KTgEvjNF9wEIqKQFrm3CRacaoaeyyopjXl
svPGYrIuoskz2wosBM624IwZOSSi9YSnMg2GTwyUGXquQcCSsGfDgH0To4iUJlkjTdu6FEWS
IVHSJw7bpGqM9jNRgV5pluzk4i5gLJ55PJGGrvvo89cWEgRUO0pMUwLiE8eCADIoY4KkIUEK
wKyIlAQESAAXlSbFINImrJpwYdcv5zpr4fLmzvosTtpUx/Skq5dmVXhgfeqVmOnmq1fLzPpQ
LfV7TEYUkIykhI5XlgZlYTJrDBMhjopCUmpFfRAmTAKk6hgYKXe8WlpjcRogBSCDBtWAAkFK
iggGISCQagTsbAWRu37GQAiWwewDREeXddwYAXaGidblttd3hiwqaEopYcvISBqNQSIEJUKM
SXLHzjEJEoKzMJsBMlpLqkqoAJBFy5kpS2MNqiQLCoTeEzNQPoh2kNDst2beZ9B0Py7pWCBR
AdiLqw4IuT2w2eP98IDqezSAeQQy4KO9ip/1Ejz6S/hIpLuy6aG99MqRSvu5NdyHS91/Hwfq
woMd9kNFRbwCpXvBmsbgq2oukpZXV3r9vqpmeZFlGQBe2Fg4lxGzxgiWEDCJKiARSYqgIiIS
E0lKIZijJ/2D97aLKs9yY4ul5asvr28YJTAmAfQrOdLrtZImmUlJMjZlaB4coEZHk9Yu5wQY
Q+DSlozLvaJqdXm0Ot24fOHeu6m0/ZWxNFGbpCGE6LNRjpbuc+ZoZq6l3fX8FK+VJydwsmqP
X5U/bGAx9flK598hTbt44J5PWMtZbm1uOmfAg69oUEHVnMmTYI5RVUUcaNS9ar8IhNLZUydR
RSBQlaDdko0UiBCRQFFAYxIVP50+vD47b46vjpDtemJO0WRJ/WxQsEU1rADkSHMWh9Aoz70g
wTjj5ZyJecsTkU4aDAlX+2iYDKfO/AIBCDEhfvyh+rrVrZW1tf7Qbc1CG+3qySftbn5gNl10
/SGZ1TAzk3ZeJgjc1eUDGiRnDAREQJtRQkGBYc9EQ5szaYNsTv3y0J1azRxREqmq5BPUPkqC
OsTVkZl7Xe5xVck8qQEpjPooSXBrlq5ds0s93pgmp7xIIoAiKkkMM4AKQoAoXSN3BURmkzFm
xGigw2dC0EkdPn05XbOaSNJ0RssjaFqaNWi0y13pznyP7iidktNJqxkSaxLRGGA7wRyh8mma
0iJCZrJrVuxO1Y4slTldmkRS8CGMSjfK+OQA7l3HRYQywyCIrFctqTPqU4AQJttBFaowWbQJ
OqcZh+PlBZFqgt0KfNTlPqUko4F3muYLQvU90knASlKT4rGhCSGVBbaRAMK0Saa2BceeARLM
UIcGp96ToRGLYbhYp9ZDFWNUXi1p0CvGOXzqYtUuAhscG17BlJEC49hwkfzI5IQpUObipZ5E
X+MoXc5CAoQcyBD1OLC1zrIBDUAINK+kZ3QeUJMKQAgWCB3jdgV1q0ahDTroUc5qWXOrZWnB
sqoioEnh/G66sCOrfTgysIapDlq1qarjtI7r83TzieKWh+t5VW8t0m6Ttpv0rOtWqggXt5tF
gs4zYnvhE6AHZgJGrOvakTIitHNRiEmCSIyp8lEkDYrcEUcVHyKCJklJkYlItcxsaR2DtCH1
LfYdRomd6SyAgojQXggjIoFAFVJX47SnZRMGNAhMQKAInYZLQTtBXrfcQkBGJmS2jl3mCJkg
UoxIiBBI0JiutxYRkRV1jowhEGRCIPBJofM3VbScRDErLGEJmUvaoiRRI4kVVZlDNhZX7vWk
2Rdv7kUr3Y+IqApEXQpM9rFNugfqMITIo0DVgVvkI5jDw3izHzwdMHz4CJh7BF+4b8P+GZzf
lb0/G4cO0mgHJzkUIB7QjXvm5YcZzO6977GHe6kI7PXLThVSliURSlSVlGIYDYfLS/2tyQIR
bV46ctyNgwGJGI2kyMZgV8KSfETGcjB/6P5iNEKbkXXWuQZ8bvpLJvbL/jgr7p3vepGrR0uD
2exCQTPLbDAmkAVrbBk1gpAoeF4tr0/WnH/gntgGg9isT4SUMsMFW1uSISJIgHd5+Vyu6zYM
drJj9Wx8dfnJ3epcz4xRrQIAROWikH7ZhytGKKoABIBMHZdqkACpT2YWgk9ikIgUERKqJiAE
5q7pXZfXSISE3GlntFuX7X2pACWK1F4EfZZM8vV2NXcMJ8a5KpBjAapDNIohiSGZtskYYwUj
kIIaw8Qy2zpXDpZZZ4aiT3BpxstFSpJaH9tgkVARmU0j/NBWtdbfBLPUUmkp5MxX3/TMiw/c
tb1xma1FQeeYO3tgwLZpQxsyazPrmrqy1oJiE9UnwQQ+qleNCPNW6kaM4YWXnpBPQgqDguet
IGDZYwZgSzuLtD2LqJgQli31C7g4g0uzpElzxjZolpOgagoQDaElZ1dGY99UVUwK4EhyA20A
BfIxgtRONWMMIRKCqhTM2srGNoyKcdU2l8+0gDjMVBDznI4UOK8EECPLtodZFAX0oD1DztDc
CytFkFahbzlCumdj3tQlErBJjeJDW8lQiknOT9PRkfnQmXmVYGXUBwFMyuTu36XVIa2V9akl
Jc6aVqppMGClixdZ2gDO4PEBr8/iSp9zxod2o0xTVesw5+0qRVAPtFWlIlfEeNUyrU+lAagU
cguzWlb74AO0IRHyMAeXq8QUEuQZLBf1Uo6b01hY7rM2tZ6vZdFGBu0x9ikuZWAx5tb4mCTW
BmwMtaHMmsDqN6YYo84b9UGGjhZKo4KGDnanYTe4JsrOfOZ9rCP6CJnBUc5kBBV8xH9Y12mT
CouM2jN6tE9LBaz06P331qeXGRWqJqmk3Vq2G7zt4XRi7IYZre/4fo63XmzbBEkhd/jgbjuv
426rAJg5s115QBRjl0p2hhqfYtI848ccHxCgClRNs2haor3IIQlIt9QWWCrsUulyw62iT6n1
0SfO2eSGovfDPMsNxBRCTLWPUwZLqKKiauCAb0MAFdCQ9iApJlVWA2iYATDDRAiGUQVEoFPh
K3RVRaJkyFhkyy6z/RG5jFRIFTSBMRBrSpEYu3iHCBXQGCNACqqAIWlSChF8REK1CAAaEoX+
OGUlhRpkQaIqqMZ4dpr1ley+Fgr1ACCu0G4Hcz8eWBPqfiXHAfWHhzDnMN2m+igQ8wgKT6/8
eyXKuYJUj4A+PEQU4iNZvSvyENxPcR1+ER656SNHeNCP6wCrVBFQ98Ub+6AORGYwHAIoIoIq
MRIZBLCWjiwPzp9/0JU9CMFmCYiQVLscBjKQUyAFYDJkcgmtENi8v3P/PeNrbxBJhRu6oQsx
9VWtzdarxfp8sbI07gtMkC/kLDMgVuscbMcwmydDWSp9kmoMSm1qJqOjIxlhrTEaJEIk6r4k
opoELOoW6YdivHnrIVPC2Zw/tdVsN6EYZwsvIQpkdC2Ysw5SDIQE2LVm7W4swm4sclv1FLwW
O74Y2RmbnK22LfkoGTMSMXSGTRIEAZGBOkGvYhIVhUN3GUCVCCBXY4xoMpPKFwaHhUkpFizO
AEJcAD68K5MmtlETskBU7WI3uDSXS9PAZNlBpj4lANDLc8gMrTqYBWm872pkkkhmTCtwz8Xm
KfnkWN8kzbDxWpbFk57Fd31ya/MCWc6cybjjnMURAuOgdJIUIwe2NuPGx7ZRS1AU5EEnszRg
9IwJNSoGr5504CgjKEsDUY/0adqKJehZfHCa6qhLPW6DWCZD0HopGJsII0OQdDfGJMlZJ+AU
YGc2Behk2spZG1Ii4SoygW+DzgIZwySxW1GM+zRv46VdHffmznIV9EgfBxnOAwxKSBFqB7VI
1QIIIIEjMIAxQkuSSHYbaHwAFUQEAwQ69WmYm42FTBrvY6qC+iRIaBzOFnE87gUghZQgyzi7
VOlGMHc93FyzqusLc/VyeGiWAoBzUOSUoratquC987g2MuOSmWBnEY3la4+ZlZIu7sh8Lpsz
34qUauetXtqVjPHsxVQL3LTCddJG0+5CdprocnvV0MSki6gtYJiqFxiWPCq5Fpq18ex00sZE
+dBRKFl3FpAZGWXCkt2/7bcrbgF3F3JkCS7O7fF+MJk2XkU1Ap+ZSW7jpIZR4JXCnJ/Us1YL
pNLw6oh2F5CStgmdo16OTWUcm5NjZE1BuW7TmUrumbQDC/MqYoiM4AiYcdbgHRebbhl/mfDy
NAwy2mqBEPsZ+ajOshX32OWscJZQQZKzfHxcIJEIXJr4BGoxMaiIhiSGGAmiQM8gAuaGmKgV
TN6v5HB0uQhRt2opmEIUS0yEw8IJ6yBjAg3E8wZ8Uh/FWIZuUYrIjIyooBokyF5ym0RVVZMQ
iCMBBYuiAIQsoKLaVZFBZ/yhmqIHgIQRCLnXJ+sgCUBCZKNRkmcURJZ9TQEAChAoJgFAVIEo
2rHEqFqygkAQClkfsxLRpAgGVY1D55Jh4Uxgb1m938fq8BQDVwIsPcgEgQLsJfr3MwV7GHYI
Rx5FIAj7Sah9FnLv7NL58+1dpXtfAkoHSKrQNUwDfMRpD4HdHne5N5pHKEUE9+D18On3qdEO
rz+DiLyCiwe04pUaMCLuziUCRNB9cDHE6FtizPLMOIcqqgkSqCbFhMYh0d4yJSUyDmPUJJj3
JMSdM/ebXk9SOnb8cVu7O75uoG3PaT1YHi5745rq4rzihl0TxXsmasGbcWEMWpT+8dWsf2I6
u+T9TkBMFiABIzLxHpgjIWJK6YZZO8jMRdcfcKiufuwtt92BCw8sroqrl1XWEAB4q33Kdacv
ymJjtpW6LnRRVBQA08InRQckTWratu/dDeOxL4bn7rvPKiiaiEAAIhhCl2IBTaiEtNc0Ag6x
zt06AIH3vwWCZql0u9HcPc9aoSVqHzNsDUGbdJRT4EGWrbjhal3Vzcb9TVOBGQJG1+sVg6XJ
1iUfUxQlgF6COmJMaF3molUMgKgASGgRZxFuP9c8/Yad1XJlQ51qqIWufcLTzadp/eJZi1qa
7nPWgJFJknhR7TsKzhrm1HokZEMpQgKZphByFoSrlkybwAo0tRaokPSqFe6P6OJmkgZAwVoc
5ASNpKhKMGs1CVyz6gY5MSqLAGEbdD4XZ4NFYEIPDEjGmIzVYLhhWX2iezYQ0ZRFXrKo0saC
BBRUo4GhY2RKhNaYIyP7uJXIFGdBy4FQhChIAacLHGZQR2VEJKhFxgXNIiyawIgKGEAzRBaY
1E0bLBP5KA4RuFPuYOvVhzRvWiRlphiVOHcZV0E3puDVKMLFiUpUEJFEbZOaKpY525wgo9pD
ZmBtRE+4KjuzngpDucNrjnDVp1p1cy5tSs6YsxNZLSmo7FSp6qEH9KLO4SqZwkJSfeCyv3bF
5QjrC1h4CJCOj6iq4NPrXm3BZDj4ZbfQAMbw1OtykW/V/tKs6VuTYmpCMKTzNp1ZyNFlmHvt
Z9wgj1mbKIWJMaRzPmmUqwcmCROQhTgqQBTrpPNkZ00vw7aA0Cfq5+bCXE8MaFHLTBSTPPmo
OTEkAfBR66CZVYDswlxKi8s9o4iZpRMrVFgmIlS9diU3hoHYR0lJRKEKOqnFaIwKhDwsGCWm
KIbUIAKSNTSLvFxgSum6leU1o5/YDrtNnYLOWwlRZm1yhlISILIAw8zajAipjYlADSMAWEZD
yAQeFBBKou4ZTRraqIJqmF0nwQBxJBmKANBeDKMK0qX1RUFVGTUpCudc9sk4KErJ+mIsqFCK
QMRIMQY0tM8zAmEnVGFUEUVSSIqqKoqdTziogEIUUHZiMkBWslEVgJUpEeq+vbheQa4DA8jP
5PEOS8zlyj6HEA72GLbPwqy9jfbgC3FfJA+CB5VeB3FWh8pp/8z70NMdcQUp98O1A8n94fQW
7Hc+of1BkO7XO+8P8IBW3IMq/ay3efj3Dsr3tC0ICND180HEpLq0NCzz7flkt+gP84KMcypC
nWIBlPYtO5JClNh1a/XeZ6Oldv3y7r33ZIzEpleMs+m5y01k406sHOH17bSoTlL8dN1gxllg
LKhd7gOj7qaiNcXomqpehDCPiqrAQIaJAEjBIBb5cHnpRJZlvq23z1+e+aZXyWYbjw5nJ/uj
SdKsyI6I4yLWWAPAg7vT1U/e+bQbrzJrqx/ZCTFBO90NojEFAEytDEzhm8WsjTvTauCTsbur
jqWJq/P2fGEbJFBJLElT15cAUTvN4n58qx1/SIiIkFRAEAFU1CyCJtAlF0FhyL6KGJWraqG9
k7h8bDwYhDaG6vJa2pqPr66LZZmvD5ZPNs1iwIJEC69RNKSIgCFhv8xqJRDf0fFtVGZg5o25
3HqmefL101gsi7D6uIh48nHPQCZK9cCBIiqAWuPbKK1mmU0evTXEREQgmDyqIeLUKNRVLJgm
tZDCUp93Ki1EC6aMYXmIF7exjSAxOYsG4Ia1bH3HU6NNSmRxWNJShss57Va6XUvpMPRMU/l5
03QiH2cpALSgDWuV2e0mLOYASP0sHl2hYc6zOc5aZYIRoCXpFyYzemwQj/Uwxnh2HmuEozlW
NTJjBljmiKolohKPCgghhgSiRJQYO8GBYJIstyZplhlmiikRotZ7T0CIyRgigp3d4ByxhXM7
C8OoQA5lslBjuG4wRumY45TQIlpHIpA5kiAPbYULE5zXmhmcLWRzqv0MLcJqnzOD5yZxNvPD
krZ9YoBjS8YrnN/1xHDDWpYYMsYosj1Px1ZABURl2sRZi7mzs0ocG0SoEx4f8lGXM3jPmkRL
MnfvVhPvrxoYh2mUoSG1JNeu8WSRhgZjjMsGGGEXwXC+E+NWndacy0y2XYU2aj831kAQM49S
CaW2JvR1lGkthVVUuDTVoZXTJdZJJ03arrAOUkeJCTKDg5xuWjXDwuQZn1zKBLCN6hM0Ub1o
iklARAMq9Bz5KBt1agNZS0bFGFgtTOuBrHpFjSkRO4K57NHwglCwoEYGbRS17WpLiUAZJCQw
Lqt8dBAmrXpFAxFBHauIRkk+ShJoE2QhJQUgjopJlQksw5BBgigIKZNhTSqd9DykoCoKKUkU
2ZtQXZEfPZmPlslZdi4hgyooChlkq8CqlDr/1CuTOXXpNlBVURVEAFGICqarGO08z5GAjCIC
sXR8JV5ZDF+Zrw+SWXsTOXYw2fFoV+hBBZFD8cq+BwbAARLpIR3fAYrhIczrDE32rnIF4vAA
sQ5lqg4lvq5gDUInxT4EM1cGonuB1T527QVquBdEXrnsAYjBfnLy4IcurpOuaedBg+V9dlIP
CtFAFYkHo8Hy8rC6tMOGFTR6j0RsqDPSjkk67YuKiAAay8YSAvjaWDO9eHHY7136+EeGVz92
4kM1my4vj3uzRQtxmoNlHo/yEFLrg0HIalVQSdggwsWLSEHmwSiAQqmhJM2ZMwJVldlO3JjN
ASc+tsSD3D04n/vQ3hC3nlPKnZo7Z51iNJqjAuC1x4cryeeLyyW4GyuZCC4cTENqYlqkiCQL
H8UqlDyV5KfTMrTrCYq8ENGQ9ZO1ItIRt1FSUjG89w1D2vtMmAARUlIASLGbgVASGC+JNEpU
AJjGPS4ayEK9YcLOfBNRE8Z2XXtNNcN6QQBbZ++88Vj/xsevve+udcfJIBjCmJRREGKMdBC4
K4JHBgVj8MI0Fufqa6+a1/lQEbVNdcS165+yHC8UNgmwiIgGwORIjAYQb7AICbNehmKaplJS
S5iC+KhBZDdpr0RlgMTWZjc+4ckP3Hvn5mbDhMGnk1effu5znnn+oQfuu/u2IyObEVzds9v5
yRtPLcf1O33Qx9z8tK1KP/TxjzhCb/gxNz2WyDx0/90rQ6OiiybWAYrVU09bW9n9p0/kVk/2
iLE0x26K526T6H2S/pi/4itedO9Oe+9H/mqlZzbmcm437Qpce5xJqKk1CcwbaaMAY0p6dr29
dtkFkEszCaLOgIju+RsBEElK2NTRFggIUZWZWh+dIyAscyOAbG0UI8kgYkwiKdm8JMZQ1wjC
ZFFjSuJKcs6kpItasoiqcGbuU4IjA3Pz6Wx9Nw1L9F7X57EVWBu5I6o7izQsGFRLSxlAP6PN
KY9zMKiE6hWnlS6VphVdBLi0k9oIJ0bGIlVBjvRAk68Mo/pG6Hif1itNyQDC0MITVt3ayKRW
c0o5IwJeXmhPsW9gq8EeQwWsjOset1uTwJ2Zx37AwjqEdmMuk0aCRh9T23pGqC0NHAwL6pEs
Gtmc6zboBcak6hgIQQEZwVnOMypzUzpyDieNtFGigo/KnUtRFJ+65QoAICNFxYwkGs4NiFDX
jDGBWkYRjAC5QYiJkGMUg7A5mzeMCx9tnoHLfFKDkBMWliTQvEmhanerapzJ5gIEMGftsRiG
GGKK2ARRABWcNYkJrSMmKAAQYW1IPdWdiQhAEg0+gSRMyWo0oA1gBPI+gYJBRElm0Ouduh4t
Ex54z+1hBKqiSurKSbte9PuhXrek3ZNcKIhC55SUFEMUiF3yRjudBewZ99F+oHEIu/bm6EOF
ToeotkfuCAcZsgM82FNJ4BU46FbdB8703WuE+4HWFYLucPFX99oB0XclV7IPlIejsSuBIT2C
qVTYi7S6qiPo2oAcRGGHjgPYR1zdy3Yd7NRdnOHgbiDs9atHICDYK1Tbg0UiXFkqL6xPJYmy
oiUgViBFjD6klJzLkoA/95Are6gJZpNm/WIl0rbt6OhRrGtWgcklnG2c6tvYzHdmu1EggRKz
0+CQMKbCZBxdXTfzelEl0aYy1jpABTXWhuC9y1LCnbolSEOWPkNm4UShRWoxLmDZopj7t3cL
djc0TV3jJMMEnQMCjMMilvZDRNtVBMKIkhjUgVQtqLqerUFay5jIt0mLUZhMVdqWsWVMSZSF
EVWFSBEZCRC1M21JUbvvrCimKL4JApBiFFG1BCJmxzOwQ0INraTQMfDG5mZwBEyp2/el2LJx
CVOW5eVweWf97FVL/SOj3j2X5vMgqBCTJKAI4CP4jk3vHg8FkIiECTqrQHh4qylys7KaR81Q
E/gQ1c56p7e1PpZVwUdJQTDlRvMM6phC8uPCAsBWZbJ+xgZTTG0UkRiCEGEVQOZyfMh1tvoz
v/cXP/LSrz1/5sNtm37oh/7Ld3zfj+xub46XV//uHX/wqlf8sIjmJf3of/6J533uF37f1948
bfTXX/OmXm/wshe/6CMf+aBieuWrXnXsyJGv+eLng0o/x9yaeZR/++9+8Eu+/GtvvuHqseP1
STpx/VW/96fv/KIXvPDuO2574k2Ped2b39wfDFS1bV7xqz/8LZ/euDMpoMCl7dR3e1/2fkk7
tRLg00r75WWe5fTGrTkhEuDjC35OPy8MlogV6PtmzSd2fN3qS9f6ywWvGFbRs4v4njpc8ikk
FZGUhDRQJEA45Ug0nUu5kDOZaxdeBG4eFwJy524VAxnG4LWpEwGwJWvg2cezL8nyZgU2Qnqv
b0+NDHj83CwTa2dL+tEYgsKwpNM1XZ9Zez28d9pUUb9+qRdJ/yE2rg85w5cNe7NMfv9CpQqz
ufQZLaVF0h7Fa5xZ6eOFRhXoxHI+85p8yizlZOYoRV4k1ZV+FiFTXyUMleDOQoHx4bm2MRGz
9/6Zz3r2s57xtF959atFhJB8SpYJQb75X3/N2trqm9/wu4btv/nO//COt//FvXfcaQhsZzbh
aFBy31HpeKnkwpKCNkEWvlsrUExQh8TEK5lBhDqAqAZhK6Jkm1YA7Vqe6kpdJ9/tYg8VVExB
FaAgCaycFACIKYFebgQQnHVgbavwzGc+40lPffpb3/DbDUoTE2FyIN4oKAFojArW+JggdYWo
EAEZVFQdYWFQEnqARujIkHwFXighuph83TgEkoQdbQhMCCZ2oAvUuXowK1DHgulBoggQFBhJ
AEkxdd2xBJAx6J47hCgkAUVIQKLYAVhIiLqPBQr7qsJDYHHAiu2zd9rll1S75hN7cYg+Yrrf
P3APXHA/i3SABAfo0J1qn2xTAEh6Jbg6iKlg7w3v20N99vUOYw0CKhz0pdI9SHtkTmxPBdPR
lN0N7VBn792IdG0e9y7TZWcOAsY9gDyEdntvGTu5xn5kRoBAAEBIzByV66rKihJAUkoHDCoD
kGFjSCVViwXddzdmmQKYwVI5HI56g+n6pdnk3l4om9lknmA9IqgO2Kz1uC+JLSYFDeIKThTX
Y7qUC9penuURQkgtENXT2k8nOVFyRTKoRhmhAdkE37VTOx5kDSV5vUT2PPNqcfyZun1hZ/7p
0tmQfFQAmLVwQXzPsivcFmJH6yEiOccZpCo4Z6xhyXhY2CH2Ju3cJBMBcsM1KoKgCJKCctNE
AY1BEEhFk0qMEQQTqSYhQwDKCC4jRrS5M4kMAIIgkAUAVUFUAfb1DNIWpKSmiApKgKLz6TYQ
nZ20D+22oppbVpEoAIg+JsPkrO4sIu9pbiQmJBTLJKIZg/fp3gvzzxm65Yy3xIiqhFjV+tH1
7FlH4aibdc9XyjAmzyC9Xn50eTTb3bjU1kXPZP21VM2L0tTzyXx3gYQx6HDANx5h7wAAHAt4
ffqzvvg7vu9HfvYnvv+97/rTpz37eb/4a285d+6hP//D1wKgVd/WVRI1DBfPPnjDTU/8mm/4
5r/5h39EBQht8vWJMWzV2jdoLIc51rWvqqpNcm4ijYeyDgBQQFju2T/587fvbFz6L9/43EUr
v/aOD/z077/nmz73OKtmqndv+lNj0yPcbNN6myRpUv2J68cFIQC8f+EfrP281WeuFt9/6koP
zO881n/ZXZvvaZufvHZ0+LH73qTfevf2HROPjDEFQBzn2SuuGbxgOQOAC036bw+HD3h3bTZ4
1Wl+ct8AwK2z8N23bV6YJxXt1g2QoGf4lLFfud9T5q83GszphWX2HUd6ALCb5GOXd7xXFv1P
x4cDRgC4de59TC8c5gPGMdMfbFQvHGRf38tlAK9fr72aRVTLbA0t2fSUnH/4WO99Vfu70whk
Ms4m9Zys+5wv+ldf+5Lv/rn/+NLZYjFCOXL9E77t+3/4lf/9J849ePusFShGP//rr/ulX/rl
H/iPP/DWt7z1DW94w1d/9Vd/20u/7bW/8qrCQmYUkQCgjfq9/+E/Pv7mJ/7+b/9Wysv/+KM/
vr61df6huwcZL5c8yDm3mBn0UURh3qb1eWgjACIhAjAS9SzlmbNMgFgHmXpwEHOTDTggG5Na
MdhGNQAOQUgjQEzJWgLAq2+49j/8+P9z9TXXphhf99u/9XdvfSMTsgiIWkSjCWLLWf7CL/7S
L/+Gb3nnG1/HbPpO2ZjCMoCa0DBqCokJJWEQdQhdHRhj12sYUYUgRTVRERmSaBAggz5Gk8Qw
i0rqbAtQERILdmS7CANg1++ms/reZ7r21k8JGdgiqYLEhExdT6eUBAztxzKKoppUEFREI6AC
K5m9yEmvgKHuYYR+hhvGQfmu7DOAV8KrfUQ5GeYvX//kPwcvh5HmX35Z/7d7PMohB0VbB4df
idD+t0M5pEw8uAt7L+MjEfMQm7l/ab0SEsL+2fbfByCij2F+jWdex853+gqkKhJH79PRVtfG
ZK0reil4Mi3AJsJGOhZl2EdoTcHMLtXR2bzBlCR2T40KuAQILEyBEYAACCEoCKgFQE09jQUS
qAJaOsz+dv84UUIQRAYFxFoujVZzWOMWlZKeLhAAtkSrzE1SOr6oXWYvk1UEEPWqfaRUOl+H
HqDUqWnqHd1x415TzzSnmIAIRdJ02jJCYqpTgBBBFJKSY0ZgBkA1SK7njEHjiPigNwsaTUGh
JVWD0AnXEUDjXMNelE9REqAqNnEhqkjUlaEl1cajYzSGfZKYxLKGKLNGXadPACC2gAiIPiRG
q6i7i/b+i9Vjr7YxH+yCQYg2pZkPH76UP3stHjWBjFGUeZOqRSJZzO0xXxZ5dTml6MgMxmVI
CaJtGA1gUJl5WbRwzRGjInkhbdKXvvxH77n70//rz95082n7kQ/800f/6a9e/F0/+kuv+ZWj
uZKkEHxIMLDoDH/yQ3//hCc+RYAKFU1RYji1THYOEGDaikMKIYbgi5x3F+GqkT3Sd6raVjNB
Xl5d+3cv/jfTiST1v/OK733JD72qn7uTg7jd6HJwl7clJ53UMGkkqR51tiCskpaMT83sbVut
gE6TAsDbN6r/dmbyVcvFz9ww/vHTo3dfri616VjGL/zEpVmi1zx2/OyR+7rV4tZtzwT9vmlb
+e/X9l+wlP3h5eqBRfip60a/ej09647436/LntyH//Fw5VR+4HT/1TevvviTGxG0M5iQqLOY
7r7YwnK/e3p7nu6r9fipvbaNW0mOlpghLCsOGFvVDPEJmdn06fVbi+8/0n9ybv9AzA1gAeBV
l6vxkDXAvNFlJ185Ml86LFYMAcCOh5nHI0OetWG3RUBz4dL6dU98xsnrb373+95/bCjPef4X
POUZz7r5mc974yc/0SR90Ze+4Lmf8zk7l//j9sZ69LU1MNleb9u27zomXOat1K0WBi+dP18W
ZQI6vuQA4HjhbzqaLfdMEt2pYhUhJkAkUEE2jOwsiIJhNkwCJKoxwdbMDx3vttpjNAidpJCS
N5BSaoNqbtk5YrbClgkd4smrr/kff/C222+95V1vffPJU1fnWe4IJCXFrnCYrYolJKvVZCvF
yOIt47DIisGgZ6gNkhlTGmjbNrc4BQgxFaZLZJAldaAgMTUakwAlVGJCUGmAFdiloCiKnV4d
435JVac6BMQkarueQx3jQV13wP1JVFTIYTliaAtqBLMQIoGIqGVKsleXA8QKXbF+Ak0JIHU8
IaCo4B65eEijsU+aXZmV9dA0rqpXKL4rc3su8fp2938LGP//uOUAkB79JQfgAIAAEsAUDrfG
swCj7vn1AAB9BAgAcChtB58F9Idb5nUzwb/cuBUf+YMAVNDDw5QqNQK5yNidb8Ooagvx7aBM
CqSSiJJjCTLbmJFqA2gt5wtZNM1wdSX6uHlpXiPZ3DUcM3XLealZi1a7wkXELgrWA70MChrE
pJ1URk0bhAiZHbBlUGx2kA2Wy9bazBAiMuqI6tIIsGmjVrUfOGYWVVk0sD73TcQkWkP5wNbs
1LI7vpJfvlztEwJJwQDwqF+OM61C1ubl5tTT2enJozB2vWQYNa3EsOX1lo3sVJat4fTCVtxa
SAywKlWcx8y68cpJQzjOYGPX9zKTW+6XBIpDNIOSFiGtz6MCBEktwdWnr/vjP3oDMy6N4Bo2
n/zI3zzz+V+W1D600fikCNAzWFcyWjn6pt959de+5OX/4du+8V1v/zNrwDAYxrrVKsi8xnm7
35eIsJe7a5b4umUCgEWCWd0CwFOe86w/+8M7Ro4+9sGPv/9rPxcYN0k2ZykKppynXr2gF2y9
PmFoAeBtl6sXn+h9/ij/3YdnDJAxAUAdtVX9s436Z24YX52bkrgVBYBZLbEwb91onz1yS0wp
iigwYW5wxdDFNv30fbtE+J9OD/uMj8fq+f1RI/DmRR6r+Q+chmeP7GOP9B7arUNUUHCWADQq
AsCZOl5XmMcN3foiPHVgW9GMEBXP7rqmDs8YWwB438R/0Th79qh441bSBhaia4avyfInl84r
/O0ONFBgCpZBRFgxKUySjJgaASHOLT+4XTc+5Rnd8qlbUow3Pfvz3//B9+VOrr7+MQDwnGc/
4y/egBzgK7/6a84++MDuhTO/99pf3lg/f6RHhgAAmMBHLQw99dlPvenmJ33w7/6yme84a/q9
/Jq1AgDOnT03Pnb6pqc++71/+65JM8sMJSVCJIxf8pXfWBbl3/zlO6rZjACJ3OnHPvHWj3/0
qU95WvTN+XvvWB0PvuTLv6qZbH/0/e/zzRyRFOH5X/n1icyb/+RPAckCEkBMSizf9O++22XZ
z/zI9497WYZ6/8XdE8u5Y9Ri9emf87ka/Pv+11vZGjBCezEPloUjLNeue8wLPu95EtOHPvwh
P9luzt3Xc5AjTbPhl3/FV8Wmedefv8VoYI1Ly6vHrjp1+y2fePJznjc8cqx54G8VfK2ECUg0
kgaRru2LqCYA0U6VBanzmgtBYgJLoIqCh3NDqiquR6unbdzN2kuC5JwDkdqrASFNgqQIKUlh
MbfIpIZBlcUtRbPnprGvi98nCg8aWh2eBg/9sh+fPWLi/MFTX/iZOz8C2g7yRFdEEVeSaI+Y
TA+HMVeusl8PfZi4w8OT72dGbAdVYLiXu1K8wiseDCHtD4MOhV8JIClApyY4BOqIYBEsA8Je
HrEjP7uZvqNLVa/cG0IgolBX991xd9UGVxRkrSQAJDaW2ADy5pm7YrXTEZnHb3pKM59n/T7n
pariYrL1yY8cPXlaMWFdHT9xOj7mWgCaTdYfOn9n1ValZNfO/fYSb3stZyGURgoGhaQooiFF
rVJeqw5NylgmDUfFQa4GVbUT+K1VccB0Oaeaib2Mp4ty+aQZLKc7bkvsTC8POxMxCBGNW+LS
xlXDk5m7tF774JNQL3emIHKVbdGg6dLGGooyzwKzikUMksB7kzMbAMO5LdUG3mv103HsuL8g
IgVM+y6WqGh6Rb8YH4H+Wtu0sHE3ZSUfvakcrgwLywwCJDuXhnHLYloa2ph0c30nN6hK/cFg
bmPrUxBkMlWE3Sks9dA4W1qz9+gAMFJubWcEMCRolVovdz58cVKFJ572o0EBlGmSVd9eWJj7
2+XL4Oqd+9rWA/K0TQEiAElUL2EnGZuVVuZHTbsyspcXsjsNS/1MFKdeESC2rQAUZXnpwvnd
eXr4YR71YLZ5CQCODI+keN5HBQXfKDFmeXHLrfc+9uP/+C3/9jvOfOgd3fNYBfWiCy9R+dQy
FRkCgI96ZEDrPq1FBYCnXrc82Tj71j9780/+9M/f+ISn/uavvvrTZ+9bLt3WzCtpk8QgjEqe
VFp78C0kpecu5QDwrrl/Xp09behyiyFgSntPWPTyFWs9AFhvExHmjADgFVD5K9ZyAPjgjkdV
RgoeBPQ7b99Ooox4Td/0Ge+uwrxuAEYXvSCbq4+Ma5GC4HSPgcrz8zQa5ItFE9tYZhYA7mtk
1emzx26RpZOO72jijZlBpAtzc1UmT+zlAPCOXXhMqdflbHrDs0HeuIPfuQI/csI5hDdcah/a
rtGYRdXceCS7ei17d+P/16X2a8fF1w3ciWX+4quHSrS6yM5uYdXC0TI+cNenPucLvujtv/NL
g9HykeMn/uR3XvOCr/z6NkUmfuqzn/u633gNArzjPR/85Z/+kb/809/vZYQAw4IZ6d//0E++
+Du/78y9d33pv/qy6268+eyZ+9ZK2pyFne3NF73k5S7LHvu4J/7gf/vFb/83L7r/nruaBI+5
8XGv/a3X13WdUnr5j/70f/7+7/rg3797yZmff+Vr7779lud+wRf97H/5weTrn/+ff1hX89F4
CV/583//zrf2esOf+50/8t4ba7/hpd/96h962cfuOV8Ff/VqMR666eZ9APC4JzzhtltvNyhJ
4mBgjx8/+c0/9MtFWZT94de87Hv++/d+6+XNjSYhAHg7zPPssU94xn/9iZ+q6lpUXvId//7X
fuO1H3nd3RLjcz/vi7//Fa+5dO5slmXf/kM//mPf/k0P33vXNY+96b++9vUf/Nu/vObxTz55
9elq9p//n+94UXbpslEh0KQwj6AAUcVgZ7qvgOiccdYikyvzg6lcuhqLg+cdNLDD0qXI7ABU
QaKB2LSMGh1IQgUAVu92FsaZvMhQJXHZZEfE9ROZTt8N+5YaBzixDyuPUEF0Srr9+fxKMusg
zfVIKT0cPh7300h4kGI7dNaDYw4j0CFtiAKAyh787Y1LD9bs+6XICPsykf2L7nNQXRqwM9Q7
sPbtcDg9Qr3YFSrsiSqjHGIfFRQgIJi9G4ZdRV4HXUx70ss9X00ABCQEErXloBgO5xcuSNd6
gBmRFBQ0MoOo1LUfjga+jQBK1hATsyGJvL3hVWJWjHqFbt99cbGzJNeAxv5w9TH5s+954KOy
aCetSgLOjbectmptYho6TYmQnLEKYpiErSLguICYzG4jg1xzUhVIQBIXxnVk26KWeXK9yfZq
0mJUzGaLet6OCVwSjGiDs8GJD9XMzxYeULLMYtAsRe/DaJgLhQSUmJuE4GE+3xmNl05m/Z26
rpqwmAbMUuA2EAbHNmfbWaiDMmPXJISRFGjfmEwAwJw6eRoQQRfKPq0eAc4AIs8uxmkKoiIS
Y6iAYwKzEywBU18aBaAM89l8EhIiABKVGI4O2SctOS1nnaWNoqSMMGPMLLZRc4MFqwgHSRu7
u9OxWet5NIOIeQmyllJM9fnUz47d8Lj20xZ8m+KdlyuDbIwbZrrRapjPJs3EiDQJoqLJeFaL
BWyzqNCt1gERe1ZnrTy8lewOXv34AABXLeWSjAokgQGjMQgApjd60x++/kXf+r1VkPl0ury8
slGlnToS0OoQLHfNaQAU5pUs93FSCwAMS7M6dN/7Pd/1qdtu/ZEf+bF//Y3/5p/+6X0/8L3/
ftZeso7qIMtDM2l03gA7kEYkwfPHDgBun4R71+I1hbnG2VvbmEAA4OuOlV99pCwYAeAXH5yl
/fqRf3zOsZKJEd6y0fz5VlvkjgkEQEBbUUT49ZuWXrCcz5K+/P7t7U5LKhIWs6w3CiAFQFRT
crp5bBSpKbLLSJEsAFQAZ4JcX5iPtQ4Abm3h8TkYhCeOldE+vW8A4M5G76nlGsdHNX6ijm9Y
xG9bHvQIFOA3H5y0bTQSM0x1E9podubeR0g9BwAitFtJgqSKO21WRTcG+ORHPvyvv+PlU3Mk
v/ELjM3e+cd/8HUv+e5rbnjs2TMP9QfDv33Hn5bdKsGHkEA7iQ/i877wi1/8nd/3w//um2/5
8D889vFPeO0b//rsQ2eMNT5Jvz88ftXp7//Ob93e3HjH33/oF371t772Sz4XAf/wzW+/9ZZP
fO+3/uvM0I/99M+++jd+70XPevxist0f9J/9eS/43hd/4z9+6MPv+eBHZvPFt33Vl0RJq0tj
kPRTv/Tapmn+/bd8HTP/8Tvf/T0//cpv+uZv2WjbE2RaMe//iz/i4bU/95rf+8AHPvDqX/7F
6eXbNuemPrv5cz/83dVksw3pTf9wx7/9Tz/1cz/yfWgyQMyPnETjXvGKX7jjnnt+8dd/AxH+
3bd8yw983w988x/9dpD0Q6/87be97jd/93/8bK76c29+56/+2bu+8OZrbr/3gaLX768c+c6v
+RJP5p9uv/8lP/yKu77r24nYWic+Nm0CAEEkQkXMMssEWeZMr8+EpuwTYVJ9pM1DBzR7qoZA
2dwsgypqRImaaQQFSUQCEkGc8CK3DLYXwKrJks0D2n1Jwt7sLQcT/yFgecTv+4B0QB1ewYkO
TeUR+38mDwmHD/+MiA4QDlUUH3rh0KX3AsMDpNkvEdiXQ3ax8WEAO5BAHugGFfdPgfvJvQOl
JMpBDHrw3hW666iqAIhCSJBg/z1At4JHkj3qdV+xgoyqCEqIIkW/bwhAQUSJFQmJuQsNRZEM
hxCLvCfBpySSVBFptohVw9YGiW5eZaduqBeb87MP9U9fF2O0Nj+2ds3lxd2RICqkJKgAywVt
V1jF1LOd0IWRgBUJ2DAIqiNYJtitgTKwhAgROQIkUAElluCjN7AZcKW3lqaTnTaZcmgQ500r
Z85IClESImW5K3uWIXovbWoDYz5wVZQUMDODnpWqbpsICVRVmaFXOGdBVEuLszbNFt4bRiZT
WJeTscZZC5C6lYMopKTd3aGelaHTsYvLBRwb5ScGcKKXjhbxSCGlTYbEWbQcl0o8OeYTIz4x
tlcvu2tWzOlh6mfkuT9cPpmXQyJYKbWX0aDEY30YMi5ZzGnfNFjFEYhAEwRVmVkRNmZ1WzcY
JgzeMPczXSvTCa69GZztPX640n/ctXRsyfQKvmp1kMqT5Ip5NT2/05zZ9VtNWvhkHU7qtL6Q
qgUAmNSQPMTghz17rGcmLUxaWTSsIpbaaewaEcCZnXhpGlX12lMnL589v5hNb7z5qZOtywng
7G6ctRqCTJq0vkjdbECsANomndQRAB7c1t0aGPFXf+U115w6+R0v+7bnPOe5f/GXf5vITpsE
gCHg9iJx1nV9occPTE74qSoSw3u3GgB4xsBlCJYIAGZR71yEd6zXL719573bPjfUaV4eqNPt
dQKAExmvFGQtIRIjEiITGkMPt3JXFXLCbz8+ePJy1j1O1WzS1PO9L35v+YdPFn98Q/nG67O3
Pa584iirMQGAB7w3xKMGbzSmEXjY7+X3NwNfrqhHcGcl0ya9b6sGgBugnU/nk3n19ssVAPzd
VrPQNMy5NNpzWLXh1oer8zthfR7njQCA9/Dgenb3xd49lwfOlKv93Jjs/e/7RwAwxjzpac9c
v3jh/t1mOt19xjOf87TnPq9azM9fvkzGAQARMWNMGlNENi99+X/+9O2f+sAH3h/B3nnnXR/8
h3cfO3GqicBZYZ175x/+xk1H8Rk3Hf3LN7/+5KmrR5ae++zPcVn28pe9JIpOvf7a//uTAPAl
X/dNQbQoe//zl37unts/1bf4vr/5y+sf89iXfs/3LfWLejFfHg+f8pznf/LjH3v2l3z1C7/y
azYvX7rhic9oEgTRS/O4sYi+kf/6Yz/2rS/7jtHS0pvf8udf/NVf//BWe+bS7u7W+gu+7tu+
+fv+a7WYj5dXAAkNAwCM157ynOcR0S/8+m9289vvvelNAPCsF3zR573o61KMf/KbryxyGxV+
+DtekuX5ketvvDRdAMBP/tiP7NTtbFH93Tvf+rinPafIefXIcm9pCQyb3BaDsj8o8vFodGR1
fOz4+Nix/traYGlpuLZarq3KgUhPda+CS0EOfgVNgA3alpznojU9T1k0Rev6rR167td2ucWi
oV5rR40dze3YU7ZXL7qvONS9al898FTaxxTovnsHGTk9hEZ7ykFV1UMueIcwSfUKD6lwcKDK
IYRT3ZcwCz4C6A5vuB+GPfIP3QF45X84+Jm6/1VRFUFA5cpo9tp1CGpX+NO9pf1D9k91eIzd
FUUhCsQEQTQkCAliAp+0idomDQJRNIkmkSgQBEKE1kvvyPGTj38yEHvfdjgoMUpK3a131ojK
zvaWrz1IJ8wB3to0khjQVDOzmG/leTx+dXv+rJ/sIpGoLC2dGA+PR01RJIh2Ld3SOAefSLpm
zkJMhISgpEokTKTOwriERaQoiNAA+ZCaFNsUBCBzeZkPWeL67s5Wmyzzbtts+aaViADW2l6Z
lQOrILOq3VWclTzJwC47NiZT08/FxmlqZiGmmJKiEpJlLHO2FnoFE0OR2YG1sfbiY5j7aquZ
bVXTWYzJeWGfJMSECp1mySBqJ5QnAEmRDSMKEwBxA9xKMGAAoLDQsxFSNEQI6qwxEDJriFQE
FS2SnbfNuJfapi1tHGdwbIC7gStRSbFpkzAjQAICiIRERBcrXFqvbzopoFN2Y2d52JWhV835
2LtDHnfj4qHCzgOaOQwasIjUG9qiSFWliyqp6ld85Td96tZb7r/nnr4oIm7UfO9GXCwW/aUj
uaPtJvUz6i2tAcBstt1qp8yC9Sadm4IqjAbF2OEtH/qHJ37Bv5F2qgpB1GWkQXwAAWU2XcZh
1sI8aDb2ALCod0Yrx77p277qV1/7a00b3vmX7/jyL/2cv/m7j77wiz7nAx98PwOIahuBBH0L
SPzMsQOAG3P+vRuXjlkCgM9dKf74cpsAAeBdW+0vPTRXwCigiCCaEwLAyx9ujXM/dURfOLJf
PsrfeKlRgSwnifL5Y5cAX3s5vPLs4i1PWn7xaukDAAARnDwy2lw0DnIACG37N5R9fF51dU61
4VO56x7s9+6kbxjgVy/ZT83jBzZbWLM+6ZnN+ZctO4Dsuhx/+3p3zBEAfO6Se8vl2UrBGyEB
wKUYM6PTOkbRzGDf4cKHfkbTRisvADDM5bnLiyqRR+6iKEyg8+16PvnOb3jB6WNL73/v38+r
+p7bb3nCU591/eOfeustn1Q0yZQAsIjoIwCSpFRmbu3osQ/943uHhhHBFUMDAoiXd6bj8QgA
EmisawvSM6CqbYLTNzxGVaumZtUAslnr7vb28VOnOz/oje1dj1wOBr/3P399tqi/5Tu/5xu+
9WU/8/0vkfkWEj3mcTdf9/gnZoaqEN/x52+rgoBCHQVBHYmovPu97/2HD37oJ370h1/xC7/4
xLe/7eTJE7/2uj++dOnyJz/2ke2tTRERZEAGALXZqVOnkoio0r5RQlXX19z0uP5waXvjcjke
xmoxmbZhOgGA66+7dmP9MgDYLOs6zvkQ62oxGBS9pVHgnoQYfWvzwmSZyVxECya3ZeacVTKR
GIyV/ZTMvlUEXiHLEAAgACckBSQQAxKNAWQANZqQSYmjLRa2D3YpASZAuZLo6UAIDiHLQcHS
IRg5oAERr9j27qWVrvwKV9JU+7HQIwHokTHYPjQeCsT21CkHrKUevMVD7N6hsAiuuL4fcIyH
tYYHgdrBwQd8JHY1tAd9nK+cBfYA7vDI9ijIA0eP/Xjzysn14HKIBJ1FXIf6JCkbL+e9je31
i8YYlxkgQuIusVbVbZ47hdRU03w0VhD0HqoZMKqoq2uzfGLhsoSan7h2+sD9Szc/URQNY3+4
thXPtCIRFBANEhDCKMMq4sAQATFp53tHICIiCghqQccubSyoTQtFO+plWGSJNISYmunGVpJk
nANbFigs6gkhcyLcAsRC2ZhISaIaJQnBgmpqBXxGCK0YNolQEY0hRDAElABFu18ZmAUKh0i5
j7KoakBkZwFod9GazJmM2ECHxQBqdnZ2NSUmNIgEygigQghJUiPYRhVRAPUELUVNAUCdMQhg
MVK+hAioCdkAZ1vzSWYDZ8VKXvcdLpXJRr40SzFJ7cWziaEts8zYDvCBmO/ZMWt9vzREIjZm
lDkaAKhGretLTXGnPWXxwa1oMsyKXm4d71x+AJLmlrlkSfqaX/vN//aT/+XMA/du7ewCQFmU
i4Bnzz58w+OfVoE6khNDfvIznlXX9fn1hQJYBkZYzflcnQDBoQjoX//Z77/4+38SIc7ms6N9
M2+lBpy3qgrM7FzmRVsPuaXWB0T8+J0PPf0pz/wvP/HTb3jDb8dk2kYeOnMeAIgMKxIgETqU
tgEvKbfm2cMMABZJb8jNLCkAPG1gE+DUCwD0CduoiGAM+yiE1D0NxxnOzKoH+vkLR2Y1t4MB
hZBSSoboVY8dAsAzPr7rDG17gZy3gtSixxzbzOWGLIIAZMP+nYkW8zSk5sHtJi/zGwsFgJz4
Y5vzcKqwiB/ZaR7YnAD0VfX4QJ49QABYJHlMaeZJAOBJA8ug5yuPyzkAZIRIyrxXaGoMxoAx
oWUsHQHAzjxutL7MuDDUNZoLQSXq/be8//O/6fvOP3j/n77lbevbu+/5u7998bf/ewV8wxte
1z9ywoYWAEZFPhytjHJrjXncifHWxbPPes7zewht285oMFw+kmJaG/fPbWwBwIWd+hMPbJ0c
GGRW1SxzH/rgBxHxmmuuefjMAyoilI+Xl++45SMnT6wCQN7rF5ZOnVgxhj/8N2953zv++Cdf
8/r/+quv/+6vfQEA/MHrf++d7/3HpX4xmVcpaRABQoM4dsAghrFrPvkHb/6z737ZS1Xhp17x
qpTkh77nZVHkpsfddOr09V6om9VF9M777meipfF4ZzIhgMy5sijuuP/s6srii190Ml8+WrtF
uDR/7uc8EwDmF+87tjwGgJNr42a3tFnXOwOoNzLjNXX9ga+bqsLeksudcZY4V2PJsAcUYugm
wv1AaZ9c68aCe6ESgOwjkCgGZCUmVQCKSEQogEnBJ8yRgu5pyT6bpDuMV/gIv1vcj/0Oze+f
ceQVcLjyp70eyYdNNw5fa18jsleB9Rmj0D0rej305wO1pR6c7ODAK0XF+ln7AMK+J8j+UFR1
T8RBnUajw8p9G5Hu5qoeuiFdnRMgAiZIeIDlh+/l/gD2+Ma9v4sCdM4DxEBGkEAVY0QVTckZ
AhG2DAyG2Bg2i3mGMjlyHLa2zHReH3NY9p1KwoGGOH3wgfL0Y5JqSgKACQAJGKm7jWqQGHEa
zHIBKJIUQVOKoiAgCEzKxrhIsVnsiqH+LKbpJIG2TZOPxtY6p2m4djRMJ7N6Ph6PdyDtao0x
2jyPkjJPKro87LKsBFE1pogRkoiAx4BIimjIACgTtSkxaeOVSQ1SiMIMayPrAyBTXQVN4qcL
BZUseSZyBh31Mnvy5GPMg/fcA11SkZD2PhABxRBj1zs8iSAAEXamWyoaVVB1kJkbblrqlT22
Vo3zVdoJth/s8RJB1TAyq9XuS5BEABkHeVb7YF3ZJUktSZt4veVhaLs533Avt13hP2hdXww5
Da53eY2ICkRsY4vVItlOEIOwu7v7/Oc9/6//5PVf8OVfhYjnHz6TZ/Qbv/6aX/uN33nczc+4
69aPFqunvvpfv+T3f/OXiYgIbNbrj5Z8o46xLHtFmS/1+YHbPgSpufEpz/2nv/urDHA7QRAQ
BBX423f/1Td+00tf+IIve+dfvsun9P/+3M8CQKj8XXfcDgDf+V0/8OpX/ZIqvuIXfwUAPvSB
D8cWXvJtL109euwXf/4VIUmIslraFy5nAPCye3Yuemq9/P3TllYtHclNSwQAfUvdg2otAhlQ
GBoEAFK1TENnAKBH2LYemdEYMulNl5tvOpr/zxv7Z6r47KGNCp9wow9MmxeO7Q8u4QANAPyv
zVqPXue929icb2MvSr0+bc+jgbViALozXTxc9a/v2Q9uVSklALCMp4+PvnJoAeC77p3dt1sZ
hr94ytETGT95lL13t84YAYAV2qiOsF/Sbq0pwTjnnUYzx8u5AQCrcNe5Nu013AIC6BgSfMvb
fupVX37P3Xc/fOGSs/yWv3jXj//M/wCAD9555sgTngtn7wCA0XCQZcWg13N5oYv5O3/rF37w
tX/64u/7T+/96//1pOe98KYnPfX2T358bTTans8AwGVZlLS6dmQwGhHRoKB7P33nHbfe8ud/
857v+bZv3tyZ/O4b/mjjwsPt2fdff3IAACeW+kcyKaV63gu/bntr60O33dcbLm1s7Xzy3OxN
b3rTr/3O6+V7X37h/MMrR0489PDZO+64kwhGDlZLfcoXfcNNL7r6L//m77AcvPaVv3zLLbcQ
qAKsrB29/jH/H1v/Gmvblq2HQe3Rex+POed67r324zzqnKpTdW/VddUNuiHmh4MIUZQEEBFg
OUFICCsySAGBHbiKI3BQMLEJtrCjEBHFIXEUkFBkCELB4o+JTRyI7evn9S3fep9TZ++z3+s1
5xyP3ntrjR99jDHnruulc/Zee605xujj1b72tfa11r718aff+N2/5x/5zb/xVwNbXVVl0MMP
fvLTL54//1P/0v/iX/7X/g00/Rf+uf/Bi9dvfvD69sevr/+7Xfcv/al/+9/63//pDz/45I/+
m3/2+7/xl29evvr4l74LAB88OIn7q96drs8uT87OYXU6cqPo/OnF6uwCXAAXzFWAhAYRSy/w
pY74YKPnb6a6r4UNwKSHmMQMOnERFGMDUyCRlEsDw+PyJoAjE33gX6QTNr5fy1SMP5ZjvG+y
f+G7hZYgHcnt32NFBy723hmWxBUe49l8blNOaQGIApHTccqZH/jccvlK/ylYSFnhTDgJLgr9
msqdzaZeV4jHSDyHNuetGEjnvpRzsBNnUctCjsvRysdUKKXkQg2AmqMjNkRCx0TonSkQmaSR
EURN9vv9ow9i06qZXJ7vLs+JkdEBoj36sP/5T9LPf3b66WemwHV7+fDpi9svyiQt2huA4kmg
u5he7tMgNbNhAPBOgZRgyHlIaeyzJH96yuwg5ZNHH1rs4vaOPSliP6bq0YcnH35Dt2+/eP08
MVKsEbOAAEPcDiCSgnpPCEqgZaB96fClYmJZszabDfuWYBRTE1CzFHPjg5mlKJ1KQqgqNvVd
N4pmds4kmVKW7KR68MF3iE6cYwIwVSNAVXVMgA4A2JOqiajBVCUORGJGjhwYmA2iCNY4KF3a
rFn7UI8CDiKDUmm1iKwAZEKIKcYPvnb57NV1P8bS1xkBGO2md8+yPbkcarcn9s75GkrcG6Ub
X0qlYV3JICpIVNV13+0FjABilj/867/+b/6ZP/Pd//ivPf7goz//f/l3ztObsILv/+X/x//9
P/j3/v0/9+dfPP/ywcNHf+Uv/r/+3L/1J9cVj1GfP3vxwx/86Mc3qa7w5bPPvd57B2/3+hf+
/H/45Gvf+uJnP03J+kHRAwg4hL/4F//C/+nf/3f+7L/3f/7yy583TbPZnPyB3//PnK4DyfDr
//wf+hP/uz/1e3/ffzuEcHZ29s/8079vHFJb0z/13/q93/ld3/2Tf+JfJQMA/djDVux10tcJ
xBTR/vzb8b/yoPpWBe/G/DbpyygK4ByIqQIw0OeDrBjf7se7aL95S//lTUs5ZcOc1DtmrP/o
T+8I7Pc9an5t7b4f9T8a9FufPfqNaKvrF//EmQOA/+Bl/z//wd3lzefom4iOnNfV1drj1ro3
yd5mTOT+45t0EvhntNo8OHuX4SfJc8Te5FaxfnD5aeW+/+zm//Zi908/XX+jcX/pBnqwt0lu
VRuPpAhojjF4fHrmTyNmga3ITdaXozFjwIkPlGkDQPST3/xr129f/8Zf/n83le8lPXv+7Kc/
+cn1zc3f/s/+kycffPzNM3/z7u32/g40X1+/u371lQP97b/1N//t/+X/+L/z6//KP/xf/W/8
1b/8l/7Df/ffuPzg01VVXfl4/fZNlYYHTQPU3lzf3r59dVr7zz548Pv/m//kH/vX/8z/5l/7
P+SUfvT3vv+n/8g/9+jE+RTvb97u3ryArn+5iw8++qX/2n/vH/+v393/5vd/+3/0P/mDb3bD
/+wP/4vbrv9f/6/+6Ha7FdU/+sf+2Pe//32P+KS1xomq/SP/2D/xT/5Tv9fM/sJf/Ev/wj//
Byvn/vgf+fV/+V/903/0T/7rf+Ov/Kd/4T/6v/pQO7Lbm+t3N7fFbv6Lf/xP/KH//j/7P/0D
v9/UfvSzz//U//HPjsAA9If/lT/+B//AP/s//EO/Dip/6f/55/7d/+0fScbBu9vrd70GPLli
rq9vbp8/fybNmfgWiazZKDHODYSUWEqh1gwbBV2Owm6z/OBAaSYV4mLNF5oxWVIkcM7ImyGY
zlK8iTUcpBtHEPYeZM0/hTlihguizL9b9ojL9nMB9CF4t1C5Ix4EM5WcBw7j3NviOF54IIIT
7OIMC8vyjrjitJjD780Kh53AaznDJRW3tMM6ZLoWsLP3CqwOo2IOMyxnZch87SbrR4hTv2EF
yXF/+25/dyfcr9br081aTbvdfb/fNw4FlZlRs3IIoZFHLTrG7VZF9YOP6PycU0YkU0WE+qOv
7370W9XdDTqfVR9sntw/e5ncADXDzYiMuK7RQb7e9pJd1bRbyinGoRcRrCpkF5pmXZ+5auWY
+v22ale5ctvx7vTiJHUpDt3bN69Pzh988PRTdu2XL74/hMQjWMyK4CuGvV7fRCI6XbnaYzbN
IpWfBmkXxpzG7VjDqq4kKxKJaFZMIgowgo3RAqGChdqFVb27pZw1x4yEoW4+/vQ7RCHHAb/z
2deZyNRSyqWkPOVMhHXwSxu48oZoVoPS41wQwFT+c9/+VKuzm8i+aZJZvHnh8+5rZ+6s2v32
y/zk1DI0P3yHZDlmG8TOT84+OIOfvdrvY0Swk3WbxVrCFvbffITnp62rT8CfCLicpE94P/KL
nl9rRSDQ71xdv/nh37q7eQvEjtAheCKH4MkcGpG1KzhfuY0DNkiKt52sa3rdyZud7fbqyZKY
CTiGixP3K088mBnifW/7qIXi33U6qI2mt6OZmGNynruthABNi8PeTEpGgdSAq7rfDapqoOSc
r/zZ2imQZDCzbTeerUIA2McUHHrEbVJRBcAodrfrgnOV4ySaVAkLrZ1ehpzFVJmmBgqEUNd1
CQ81dTUMsfJ09eBkVa8vahgy5voi1PyrH4a//rd/9uLtjYm9GENAEYunDz+oqw2inV9c7u/f
xbFnppqRUn9aQ02qamgaY+zHaGr7IQLimPWmz6NiRRAYAfHxhl/udV0pGpLBfQRErD3Wnm56
E6pOLy9s6HXYnbp8vln5hx+KUZ+Nxu7d66/edikb/spl/WKfthgqxm6/zYC+WbdV87senWCO
lcM+aVb96OF6Y7sxqsScY+pTfJU2FyElvzo7adz+9V6r2oGogauJYNwPSfXswcXnX77qjS4u
HqDEfugdc+sA+u2rwXVjZkAk/0b5zsihAlK379PYr9crUWsqd9KEd/ddyooILcM/+ln9YO2Y
4De+zLeDvh2xT1I5Oqn9J6e8DrAdoc+w8pDUYsyrqw/C17+nIoX4qJEClDABmBYhQrHYlcbz
/Yu0v8sxpgxA3PEaOfizc6lbzRkAnHPsHCKQ6RSQAjIAKeN3DcCKVmPhRkdBrMUQ4yxxmz8z
R9OOQ4AGYLdf/DTU1cmTD00n9JpIlc2Bx+UQhQjhQuneByo42ve0yQEzlmaI7wPfxJcWhCOA
I+SddqFm08iTA6/6xSOBThvarBNccOjvF5w8RDLxqHvV/MNDkFDnGJ/Z3CL4AF84jbN6Pzpa
3vRCtfRwzY8ZWyHHCAimkIb+y9/+vqgiMZFrmrpen9xev335w793sq7N1DkOTbN68lmzOSMi
cJy225u/+p9c/cqvuMcfxDStzwDI+XR/m29eI3L31bPL7/4Dtz/60VBFax3cxcoxYzXcb8f7
ewGrXMiqo9rpxXl7chaqCiQBYgbA0GLTUmiAnQ53b5/9pHFOUgqVbzYXnYWL8wslf7+///mz
3+ylIyEw4HWgCC6ac85rjyYeKefcOjeMyqx15Ye9KeQqhKdnpz9++zowKxCoGtgglkDHZKdt
pURGhpwpEUS+7wbXrj765u8yI0Jg510cUwgODHyYZg4hOjAQUUBMWc3Me0YAH1y58jkXMR6N
SaoWDbmMcPDsLNP9YCcVEaJYib9NNyv4cN8Nj842be12KS0OY2CoiLtR3D6e8R4R2a3BuRrU
LAMo9vZKawsNqwB5BKyZTgOdVlTONooN0TYtidp+1He3RgBNhVntq7fx3VYFoa3xk3MXGG/2
Oo6w8ahglcfbne2TPjxHA7rb2kljPsN+Z2xgCOxARJ0HR6YZJEEAyGaE4gCZudmsMQ+fnNh2
tN9+vW+xDg4BXJckpySjjoj3fWq8M5FdLrPWEIlUVczu+3ExC8yEpfM3ovcMxgTARCF4VXXM
p2fnbdMGR2r86GJ90kCy6Jzj0SfkMuLgH/uHv/s3fta9utnuX7yrPPngNSfI+yzp1bM7MwXL
eYyJZM2p63RrsBtzFJxmZAAZUVYNiJUnyegImMkQx2wGoEZDxIoU0DxjytBF7ZJWZ+vzX/7d
dz//4fUXP7Sn33bnD9J+vw0nflMHd9vnFzdjNoAhEoXWrx+GuqX99ebRh6kfLz/8RG6/hOsv
T6oqCShYF7Xj0zZoGzoXyUZ+ikjmmS3oYOxPAvdDyimnPpla7KOC9rU/27Rn7JuAOcF606Dm
2O23Sb+8GTrRqq5C4F0WdcSl2Hfyvw0BNGez0slAGcmTEUKZG1IxPFxRFfC6x/tchrBABzZm
GJM5xKwghkY0FwqXuNRUr+oWG11ohIGgu1s/9dX5eH/vIRuQCWOooqsAGByDqk7dQhHIzc1k
sWDWYkwXQ0uw1MbOFrhIK5baJUA6xN8OW0+pAjVu1uxdVoWZ2RDaewJ1W7I4C1Yc/718HcjR
bNBnAvZeI/pf2MlyHwwABRfKNfEbWT6py+RkmPeH88CtKUh4VJz2/qGOJZLz5SrwhkfxRluu
khWJ3xRKLeiox1ev5FKW+SvzPiYZ4/R9qVt471ItZ4PzqkJVffzt74DB689/1g/jq69efP07
5+cX59dVJaLOERKB5jgMvhFiQOJyvRAMVCRlckzEZEYgfHJy++XPXn/x05P1Sbq9McdVYnuX
JWsE1dQR2Obysj07G7tO2UtOq/UGqwabhkJQ5EmagGgGqqIpUmhde5JuvlrV7mRTeXcllhjV
GX7to+9d3351u3+rOcGgSpZaVrM0AkaEKK3nTpJ6NLNuSCmhmNYBiAGDi1k9GhNl1cozqnkm
75yqEQoroaFxbJ4+XT/+hooCqqru371xznGMCQyc4yzqHREhUQn5WBFt5iQAIGJFgFc4QRa5
3Y+/8oHfDeP9tmM0iDsmHqVMkUMEYKbGQVJAFdKcxH7+Cs7WNUJv89Mc0Na134/5vM19t6/B
GIzdBpxDEEIhMNnDawg51FRVlnMIbhXgqrV9xts7OT2BzkHbmIpBhlUF973eby04JMBNTfuo
pzWJWm9wM8ja08mJ++pevvbQqdmmBlB8fatNg+cVY6cEwAYSwXvLCllBFRt2Fyf05c2ICL5p
DTHHkdYXn3z0nWe/9VeGLGp6tx9FVJGyaFTtRyREAxiGMq8NS2oYAZhYRZlwygAgIKHKJNRF
KaWMtGrck4uzJw9OP3x03rQr55wP6BwreIfJOyAwMdac9/uUVa9v4gcb/uTpN04vH/61v/43
u/s7LfLp4isgEhEh7An7AI2HbtBdsmRwsfZfO29/68VdKVg5DVgzrQMxQRYsJZZqmFWTQcu4
riBm7Ad1BN2QXE5f/r2/025Ozr/2zctf+geyAt3/ZoPJnz4c435V10/PrtzmAu6fte3lxbd/
9+1XX7rVydk3vxvvruvT8/H6uRN706knZIMs8KInh/zZylGo+9TvozrTs9hvb0eHpqJv7yMA
uOBVxLJmT9vtPjRrVNlt77okWdE090PcJnwdc1I79yoGZc7V4i8T4jR3FQDMisleOVh7StnM
UNUu114NzjSvPH1xDzWZI0hiAFh5QtBA4Fcn9fpUtcTDEREnoYSBTipzm+uIQAwk6yAO6pMY
R1OF4IwZYhRAIAdTd3hEnMZ5IAATTE11Z9u60AiZQamEueY44aJjAATQ46DXsV7QwJDEIAmQ
TNEdAGNDWtJaEw07sKf55H4BEeZ/L3Tn8Nf89Z6WcfrjPXwrDHXGa53TUAcMOu6Ke4SPNl8B
Per0cdx2/rCQo8+Xn6odGKVZcbnR7DC17AhyZiQr0cT3AHnanR3RYS0s8BCvhXk5014mcgzo
mzb3XdfvJOe+2+VxNLMQQkUSc0YFBE7DPqXz1HXExMMeEIxczEBEAQlEtO9jt0t9N9zcOOdF
9f75l+C8xOib+uzREwCAnNGxa9fYrJoQAADJGRYVOqoIilDOCiiaDYDYEwKlDrQlDv2Q/ThC
hf1+PD05RVAd49Xl1y4uP3j54odd7JicZVEHtGrNW36zE8ntBfqWbdS+myoT2AMCpgyG4BCG
mB1zG3xQ0JS7bb9Zt5rUFEaJ9YMnm0ffzKKImMbYXb/meu2cc8QEBuMYTSGpKFgpKkImZmYi
QCiDzEWKQwqIyMxdN7ReG2fPX78FE+/cOrCUe4NopoFNDdGKGNwYbExpNzBNM3vQTB1jIOXT
dbZhHMTxQMgAQG7tmCtTM30k2QZ7E7H94Fsb2uW7N64JuSbt7PQEDGzl0ZIR0NkaRSxFRMSL
QK/2WhM0La8BZLQxGSTrRL//In54ykNn7IAclQnR9522p27ICgBIkMRkCxkMCaNYH+ONwX6U
UWWFwXtnSdPbN6+ak692OasA2DYKlSAgIhFmM0YkAHYcfDWMA0zlONO7QDDJT5iYCL3n4Jzz
3jvvmJnofOV/7ZcuV21tBkCdJBlGHAft+pxFb+6jqu278fo+DlH6MYOZI/ulr19+91e//eD3
fPf/+1f+9vXdPaCLktdnDzAPsduPAlkkTo0BsQ4UzFJKb7aw9iiGe1UEGJIxizkeswJCFsqi
wiZiWUkjxlxGP5N3nHa368uHzcVV2t9rzhQa/vib/t1Lq1v39GOX975eu6ef1T+l2I8Qqvbi
Yd7dqWQV05xNjZ1LChmMne+wAtUIfJMcubDtt5/fplO2amW7XgNqIAAARRyTqIGRG831A1hO
YtCPccg6CnQxOwIAk8KuZg3ewRgCIBEyWRZCcAQ1o/e49hi4SK1NVZHCaJXEWwK4qF3tkBAE
2QEIOmZSVd5c8MlFkasU9w6kxAlNzQ4SC5xrLnOeC4ygtH4xJJOsRd+GqApZFRGJkBEAQQTF
DBfF3QEOjuz6HIkCnFnJXGw8SwnngcR4ZGXBXN0AkkxmdnpASyckWDjFYqcXLrEg1UGGMWse
8cikHwPA8aWAI3s+2f3DZ6eTgfl9OWqJq0cnXr6Z24sc0SlaFjrt7heEHjAHMY/gdcryQQn7
TR9HW67u4YNYWmrgPNzF7PBZg4nnLsBs09yV5agwh0FhNgYgmsD5T3711yxL///7T+/vbre3
1/1+5zeNmYmU2WZZzUIVqrpKmgBg/+WX1EWQvN/dj9v7GMck4kNoTs+vPvhw/+rF5tETjRER
/Mmpee+aFTYtOm8AmjOAIdHk95iJCAISkQCAJFHLKfqgCKapw/EWAINHU1HJAJBy8iH0Q5dj
753/9ONfffHuy9dvPicyiGjMzC483OAoAEmjqLFvaBiy86EfMwGcVqzIlK1LqV21nnG377NC
1YY+dlnMkNZXn66uPhlTdOz6+9ux21Gz5tW5y0kAgR1VdQADEWUzMFNTUouSicgHRkKP5D0B
YhyzihJSP/R3+9hnujh/DN4Je2/DePu6i8ZTTNoGZZXpRiFiIBvHSEhZBQAICcyi4QqrLg5i
IcRI3DMYApFbO4cV2ImIGVg/vMGm+vQf4me/8fL1i7db5oylmXBg3PVSMd3sDcCyYJ/hBvVu
mMoyggNESMm2oyJCzCZDFTNcnfPQQyB7dp2TghqKAQEOUY2AkFgsiSniOOQ8qYiMiHwI+3Ec
Rb96/bwUEBKzZwcIOUZVtckHB1Ft283jDz7+4ic/QGL2gdkhkSfSnNh7R1h7t26bNrBDawMz
mTPRHNniy5/+7Pm7eDeyZgGklC1GFUDvmZm8Q++wrtzDU3+6atetXze+rdBvf9R2cLpedd2+
S4nQnIwq6WuPTu73wxjHkhtRLYNCrGbYj5kRDG1VU44mZhtPHi2BFkVPP+aVozFZZEi5hN4M
AIKD1cWDB1//tprdP7tuHj7xAbQ94XcvdXuDZw/g7MqJALGRE+lFlEJF7UZTtP1W12syqBgZ
KYmqahZTQAUcpKQDNYtFBvVux5WJXDiIjMZ+JxjFBFAULeE42j7nbhiHmBCQmVIWJrLjYUwl
ZVSYUMnvIAEKmG0c1DXtR6odIOCYLGUjwsgrc21MIpIvVtR4RLB9dpkZXNAQONR0di5czdbJ
lqZHYEbFBZ9zIAY2G2QkYiNEQGM25MWIlBEhgKAGqEaFIYIhgCPgBSQOZviokOk9I1uyRBOH
KqcLS++IKRcFBkBVbYAyB7wAwBBMCmWxwlYX1Dsc5b2mGLZsXUw4FxQ7ZiZHq/sdUDJD6tFR
dNab2wQA08dUbW4baIWe0jRzcpI7logjTTuZ9q8GvMT3ZuA6cNP3Bp3MscoZW5aM17SrJTg5
T6KZCSpM3aPev0M2s8D5EDZrIA8XxqY4owEgO37x+U/PHzygk03sO2TSLDGm9iScnp9pGgFs
FO1V7eYmbremgs5tHj1ZhQA5g2ZCIu9Pv/6NarXBqqamNUCdGhgiM0pWdi6lLDqdtU0gqgDF
m1Ry2DaNIZv0pmqakAJUrZq+ffWsXZ+ICCKIZGcmklnlg8efNaF99vlvJsy+qVMaDYA3ASRQ
kqpBZva7vm5a5JTBAKDfRzQTs3037FWHpFUbxENz9TUXTogr8s3Q7X2o+t02xpF8Re0Jsndj
TGoWvGNG59g7j0wAIFlENMesuXT0MHbsHCNa8G7IEdFAdNcNYq1JRiKTFIkFXcxGBGal2RJU
oe5jQhMDNNeYJJjjKITEmLhab1q4H7UNuB08Y6wMHRIiMbfA2HhVMwWF0d7E1j/9z8PdXx2v
XwDz3WAEZmbrinZRhgSOYTdoUmACAIwCUYXS9GY7RlGrPV53SdmSWd8BII4J74a4G6RtKYJl
MVDsReqmzt2omkXVzHyoKteQr5JYvVozBTNYn3sLAZnbEBxgt70TEefY+cCOmYN3HKrw9ONP
mckRB40t26ZCj4lMEIxMxnSvSYlUR9nHJAp9VFWJgmLwvW+dfPrRuh9NBU2BgD0TIgEQIqWk
MemYrBvjl6+6bsgXm3Wfxm03dCllUULsuz2hvbpJlYcxTxmFMVqXjckI6DSQJxGDpqY3N5kA
sxkaeYdoto/qCFQBzFK2pMZEdfBMtq435x//sinQ6sSvmhKoVAU8v4KbN7q5gNDAzRszVXQi
WdWIyTUtqFapFwBHmhQETdQYgcACyKAmRh7MEyQVM1LnX+dUoW+IbhDZh3eig0hGdARxtPss
oEI6x0DUDFFKIgrBLzE4A0F0WLpSGBMJWGB4ssZthwyECJWjpLAd5LxFV1V0+mjIirqv2oqD
Aw4BHFLwdQ3E7AOGUFoMqqEozKXCxU7NpOXYXiMCgQIguzkvAoY8rRXAsPTEMwNAQQNjhOkW
HER9E4dBQAVbuInhwdAbzGQToRj043bwBxAqbeYXEDQQM53mN06WbRlJ/DuBB6ZAoh1YyMw/
luDdzELADrqMw+WYbfyBktmMHeWbKap+9POSVS/tloiAZnCY9lAkDIiEU/iu8B2YuwyroYG5
afgWHKN6uWL2OxAI5nEni3Jkvq+4wBPPLXrnWdQ2kX5cRJVTIPkXWPME+2YIUFdhB/Dow4/f
/fxn2/123VYGttlsqspLGkzVEB0jALq2bc4uLA5htaJQAROtN+o8hoDOu1AVqbxu7+P3/y59
/TO5eABZyDGolgQ8IKqqDxUSluQ2IqkpuioOXZQ8jlvY3TChY8yi21HX9UW74ZTSvtuv6obY
ZRFRIFHrdpcnD9pv/55nn//W3d0rV1UErFl6EU7aK5voSm3U7WpzoYai1omsg3/QNGPMSY0r
ziv38PEvszvVnFRzGjt2rtvepZic81S1gI4InfNc7kNKompMiEi+9IJ07BybmoiIGgJCiWsA
IJgnbAjSMLbtut8Pjrl2iM4NrgIghGwGnsyj9eOI5Ig9qKWcCQ0QFcxMAck7XNOwT+uqamoe
++z3UQFGQHQl3M+td9haoeMCY/8mNWe//Lu7H//1/evnnjErEGIUyICGMCQwgtpjEmMEh4CK
BFh5UMMxqiMIgTybafrqbQKjylM3akqSUu4HFERmQgMT2Vx9EN+86fe7VeMUqF6tfLNGJEBw
ziEiqHrnywR0UUOw1dXj2Q0TkYimlvL1y3eIjKqkqQpSh3y/Bcdgan22MVlWSALOISEpQBQQ
haw+i3gG6dL+tUTFrDQk6CMO0foE+9Huh7wbJYplsZQleP7e15/e4/qv/vjnOLn6oAZdEgTY
jnZaF3+4uGBKCgaqhiKgao2fpmQ1HoPDMYMZotko5ggQIRA4gmiUkdGQfTh9+o0cU7q50SEq
1ykmrAURc3PKb1/K/Y21G0zPJSUxU1UzEwBCVCSualWrnascJINuiKQu1GCmYk40p+wlTXZi
yAAGCZHqAINGoB5sMABAUYhaRDEgkzjtkGIpRklUp1JwUwMQQwR88vjR2cXF29evNpzBrbyT
1qsCeIIo0Ec5a8g04/ps40Pa3gEANq0RB/aOnAEgULFdNjUKMncIuNmcbrHJrM7BqEOMiXjm
RGWs0IIfBxqkUFK6YIbIgFjS9VAsps4kY+IV77Od5QrAjKaEaIVylVowBSsTZXWuv10oGprq
/K+pEmwaYH2Igy2E6T1IM5j6Yhi8H1uz5X68/zWToqPt5x8WFDGdaq4PIcx5h0ggYnO9MSAt
CDVz3SNWV/456TYRZIoR4szwpn3YsoLlAs6DORZtvxnIfFVndC9aD1g6dZXtZv08IgJNkd2j
Jc17m1krNJUnwjiOVx9/8uijD1/99IcmyTnnzCSNKnn/6jWkEQjT0DPq6Te/Bc4BMbKDSa9g
gCQ5AzEFyj/5cf/spyu05uJSmyrHrGJE6J0DYpGcc0TCYdiNw34YdjF2OXYpdjmNKhkNSUhH
58F5x5AHrs9CVd/f3jR1U9VNEiH2KScjwtjXzJ9+9r0vf/xbN8MbaBzuE5FBU4MQIpqlIcru
zauL00sm7lN2Rpb7IaqqhvPThx9+18RZHpAY0SHSsLsf+h7ZZ/KOeHN6cnV15VZNZQYiIqIA
pqKENuSspsF7YmSi4H3xYmLKCCBqAIhEUeXN7f7bj66Gzikzh6DMVK2AbgmTGoIpEoMPoAlV
CTFLRHZLvUWZjR1o1Gye866XrMLok4wwRER0yAjsuDKwBkqfQrGhf53q5rNfU6T9858zokMg
MM9GBEiwCvT46uRnL7YKhOzQB0kRZEByJddUB0wZgREdKWBkJocnzIhE7AyImZEQDFy1Ormw
04tL550nNrNpaIJmk6wiktOQUhoHnJLnlnMW0dJQJGfRKdc1DR0ggJ2j56jBu+A4CYpBFkUi
xw40MEIWGVRTGmMcVI2Z/z8/Hor+zaZBgpOTy4zMWDm3acK64rNVdXW66i18/9lXTGiKzCiq
gWFdUxLoBhlFzxpypNuBskyxoyxy10+dtIZceodCEhBVMxyzmQERjNkiEgMaoppVm7PV1VM+
fzTevKVQjzev+ttrUxBDF4JrWjx7CPc3srlwzNbvjVxZP1pRauEQWmcWxYLByuPoqXJomDvD
rFAG0StQTZMxP63oPoojOK/xNi3pfSv2AgDMdDLIiy2cjRcthbUICODQ2PFqs6qq6urhVaVx
dMzrEOwtW2ybkLI2ARhBVAmQqhUrADtjVwbdlQrQxSirQRYTA7Vp1F9x9Be1+sF6G0y94IvX
g1w+OhdjLUBQnPQyFQUAMZuxTuM25jDhIYs0CR1ni/9eWmiKkE6Bo4VmAYAejKjCHEuEWXxh
AGKAYCUMSDNmvoc673ORIyH7AdCWD8z2vGD+dN4zA7QFsWj5fPmMgYKpTdfmWJdBOAUY1Up3
FwOZFnWk1Jjk6XZgcqAKBiBgBXWQZjI+tcKyQz345EtML90SdJVF1jGvp3gOy9MIE1tb6KqZ
QbZ5+zn8OCPxFHAGwPbJJ/b81c9/+tPTp19jTVmREczEJDGzqQ13b3Myz15M9vvuFJCqRlPq
79+5Zu18DWZmmsZBANyA+c1r8A2/fkk/+5F889uWY9dtRVNOcYj7OG5j6kUTYUI1RGAANKgI
64BZnJrFZG+GnUd+ev4AOQz9PoTGV3VWbVab/vpNxT5UraaYRAGUNH782e9avXv54kd/TyC5
R6cZvCqgZyQW9NLvdW2mJtl6kAQ8KLTNyYOv/WpORhABKIuqWhaIGZrT89OHj32oUVIVfNxt
3Tgm7zh4p85ULWMGAM3CSCIyRmXmKjgAJEbn2dSQYIx5SIIAuhsIra6qXQIABPZutbHoAEwU
2mAVA0jqJQGSaV68pXL7CKfQhMcIQHe9trXtIq8rziJ9H1skRiLHnh2hESqVzHs/vst18/Vf
PcsZ4siekdh5x86jD86Hvmk3p0y+8lXlQlBJ989+vr+93ZwGct7AWA0MiIr6DFVVRcpboioi
Yjmb2e7dS1EBs33OACaiKiLlwwCipqamk7VkIiYEAGIEIDUkppUHJFfV7X53TwigmhRiRgdA
AjFGM0siTHi2okTgJM+vlXlHnz3e9IP0UQAgOGTipNAEXlc+eLdpwqoOTeUdsYGdtv43fvzm
N3/+MwEpcxYMkJx3JJ6scWh+k5L2pud1/cFJuL/fr89O32mzffM8Dh0bbUcLSIymamMGz5hE
04TYaAoDOhBh55qLR6dPP7MUwVW8uUCikw8/NQBVkaFHRKoktacujpqThhbGLgOmnNSMrHQu
UPCVGYxGrUGXtA6VI/WYr5XUzKNWnLjFmHifBEwCoycAsKjgCQmxuLEEgISYzZBtGfQ3h+Bs
hjmebDuAmqBWVbU5Obu4ephjJFPKMff7E7nzFqvGScqtk0JM0Yyd42ZtpZi3ZPenP9EAFDAp
RJk8dUZktAW6DoG8ch0RgdCkeOMERFg6hM0xrMXWHQEEmIGoZQAqeul5nwagRQEEBpN63mZY
NSqBUwBEQ5wLyA1KN6JifAsakZWIyKHFodlBID5LjXBeE87G2uC9nNCR3wCmVq4DzCeyqG5/
4eO2aBUnGF6ioDPezBRn2klZB+JMhWbJxoIJS3kZAhAaGhAWz3sqOdBZtDI1HMymM1Ga3Ye5
YmwGHlXQ+eflQEuhAkz38oDYU24TZ1iesfDImZl+UtZjE1czADQOdVuPw/jmbof726vWtyGE
pknj6OMIrhITX7k6rAgsEfRvXwR8FEVTGodhuzp7nLrrGAdEt1ptxlfPYeiJMEDW67dxv99v
b37yxV9HpLpai41gQwg+OHLkTcsAGFMDVcuiokBEBDKKjiZfvP7iwyffXG2uRKZmTL6qQqgl
jYnQu4oJVE0tU+ofPnh8evrg+bMf3Q63SIAiGHtQxRSpqoQZNdDqRLwf1apNffXhN0QVwXKW
/fYWq5VvNlS5y4sHp5s2jyNKVLW3r191/d4lEUCMWcCsqrzzHhGIufQ3LC2+xjS1HC1uDhEx
k4gx0zimXTfWVdjnMlY852yGfnExatZujBnYARJxjJkJiKcYepn8W55KUW3bVUopKwnUwfVZ
bRjGlpDICW52ycVsg2A2XLGiDoZ89a1fQVNmImYFuo/YG2f2EREJs6oAeEMXqrNvfKd+9+rd
Fz/a3d8SYFbRLMScRXJOkqVkIA+5UwQwExVEYuLJUCA6ZgAwInbcOq7rBlVQkxG3jipMY46q
eUw2RE1qvkwvVTNJGdnEBAwJyVeuWoneEpMNg6+qCB50DJtLAOi6naRMAGOGVRPOTqh12AbH
iECuFzKA83Xl0W57fRfzF9f7r2/0ftP+8C6vHn087K9Nsqk2Dz5cP/xoePfluL/J7JvNVQBM
YxyJv/H4Ap7/rFmf5vWHHNr7L39AEh1ScAgGIcCYQKQ4GahMAkgq6NDXm/XZg/rJ101MRbvr
N65uhnevWxfCySUx+fUpTpiBqmrbO6vXsL1W5BJYsZkekXMGkARGNTEgUjBwrqgW1IE6QANN
YogowPsYCZEJdlFksQgGhsjs2DRPdZswG5xJUlOqmhDmekZQYnd2cbk6O1eDerUyAGbntrdt
/iqPBpYZkqgk4ZwTqTICMpiRTtoLnBTpCGqYxKJY1smkqhKRMR7cd0ScZGxFp1ZU9RNdmMJm
M7odAkqTjZ7QyABAFZQmyCx4JcVjJ5xECjNSIBZiBYhQGrQCoGpJeR4OSTMkEJVGeDNyHRPA
kg2ZOcYi+ZsCnAgLZ5lgcjntWZmAhSEdK9fneufJA1igBoDmMlGaqJkVB+X9cVrzro446PSL
A8GdgpS6NM89MFWQ+T5OVXqFNul0CxeCtUBscVZKg9hyMDpSy1iJRuJ0pnMo0tCMShZ2Oiec
GRwW3IRJWTM5E8XyyNCdNfw2kgCoqnO+roJ3jCqaM3ANAHncpyqEytcEqb8Z32km13qfc+7u
7oeuQ0uxv93fXrc397XIKhADw911SMldPP6G+wfNpAmrr178YNdHFkDUnNXUnGO06eJ75sqj
gjEBMyY1gPHzn/+d9frRkyff9KHRrCnn84sHd3fXMY7jMHjmZrVG8JKTxaGqm69/83svX3z+
8s0zI+LN2t7dqGkEHJI4FyygDP1mffrk42+oGBLkmPf398YezTSPTx5dNXW1vX4rmhFIVImo
qmoXvFe1nBUJuiGJaAgueAdMCOAcm5moQcoIqAY5SxUYGRGMCEWk6/qHD9qb/ZDHQRNHsRS8
AsZsWT0xCfoxJ3O+IqpDmZ07BdgZgUmLFsgRnDf5dcYmyN1QPWpjVdk4aN+PLbGqXXcXnXAJ
EzHhKRthAkSHDIhj1ttBYgICYBiISMkBsREmIwWsgl89+citVp//7b92/eolEpkhEUyGxLQi
A0JEykaiBogIdro+7/shjj0hOCbP7BB7xcr7qqqC91V7Fvt7EA+Ie6pHMnBAFhve5dz74N3q
zFxrw/3Jo6+T9zEnsNzdvKH1maQUzh76upY3z6qTS64aHbv26ddyzBXR/s3zmxefP7vp6nY1
DH17cdX6hwBEGCywcXCAGIfU3wGGBw9hc4J/95rd5UnVrrE9kRz7t8/zGG3YC3hxLcVtsISI
vaUMfNNe7fDF7V13+njju5P1k0/xzRennAejXcphStcDADimBOiICO30/GHdriH28fqlkm+v
Phh3d3F7yyHsvvq5Ob959JhDNb2ralav8d0LefwJxwGIy89o8uJLNQ8Ss6mJTe1QValC3Zts
M+8BabQ3XT6pmRDuR6k9mUJWS3bwtw1gc3rWD+k+RiQ2FQMgmHVoUDqd4dzewMCA2Z0/uKzX
awIwMzE1YFe3SrXgIBlUISuYgV+tpyghTJ1OEZAZREEAzSyLJbGkIHMPQcUp4ziltGaLe/C7
EZGQFIEWOnScApnMG02GvJzCnB+bWRECZJlqlcBMEKakymx1EWDCNAMFKEpgkenVKw2ncA55
zXdkIgqKoEXYMAODTUbZSgixqMrnuAMYIJoxQWFvCyEzKdV1E3d0U/cwoCXqOF8YtUU3MaF2
0vlCwAHfj5Yz0+tDEcSBgcGMn2oLQzWdpIlTdddh6tZhJZNDZBN8wpwlnqUfR7XhOkcdF+pZ
jrXIdsruitbEjnpXleUvrAznsrDpwAYvfvxbeXsNfjPBqqqq5CwCBHGQcSg7FFURc85JHN+8
fJENzCIKKgASqeZv1KdxyLLvVxxOHUbNkPPr3/pb27MHv/wr3y3YOQ73Q//OTBSoFPBM3ZQM
VBUITJGJkF1wVCGZcYvO+cCkTV1fv36ZBrq8ehKYxtgPfb9Nsdqtzs4vvQuimlNikqdPPtms
z7569uNeshFWJ6coSVXZxEE+e/jkweOPx6EHsBSl7zpkT6HanJxcPngIkrbX95KTGohGy1lN
SM05761YcYMYk6jkjKimquyZiAgxOCpdV7NmROYiAUZwhKS6v79/ePUwKQwpkSf2daIxCXbR
wCAwqJl3vgq+YYsZTKJOj5QFJgIQhdKRSs3O2tDH9PIe1uxbllBhTjp0g+Pho2p8LU/uRkIq
NxsVySGMiveD7TKqYWmQTQBgxjkp5vJqyki7nrwPVXP+2X/hH+2e/fb2i9/a94mJkgKjhXrt
1hepu4/7m320KFbeshT7umm5bsgF55yptJdP3O529ejr6IIhAJInQjOLHa/ODQAR/f1Lun2+
7Z4Lkl9fYL3RLWa38qEKIZsK725k3LMLKY4lO5i6O3b+wSffBqSblz+qNxd9v3OhHschnD1s
mrNwetV+9E3QovZWmDpJ0tnJpQ57W69/oBybPdtd6neAvj49lzjG3bubz9/WZw8JNI49ia2f
fJ1v3gxvvrp+88q4ysPdsNtm0fbxJ/Twafrhf9ZQvo9w3wOYZcOkAKb16UV7fhV3dxQq4LC7
/bnr9yeffAerxu5vNScjzXm0cd9dO6xaDgHAADTXK1e1tt9Z1dh+m1XBTEtuAQHASMEV0WA2
M4lawg7GCB5zMscIfda1ksMyc0TLlEOHNjVRBTSVk4sHG9/GlMd+R2ameY4rTZYlKaKiFD5g
WoVQNausc8c58mqWgcbmKtFa2LFlsKzMUJ0AkuiiHkQ1KyIXMROFIVtSUytTdGFqVDAbqpLs
BFtqio1K9It4Yl5TwAnRCsMoz/DUvgGLNFGn+oRie3VSBxRVheF8GNKp08UxAS1LEcBsqnN+
CI5MJyM4LupzpAmJjAyUsPRnshkhbJIWHEKLdqRrLyaeCoguuZ+COLM0P2bj+Rh8FFJc4nhS
pBBoYJBnurZgAxaMnfO+Cx+FmT9NQ4zL4SZhOxqAzNliKLx0jnnC5EgtKz2cXYGiUu+6nEJx
gMpup0ArIUGJVpvMSHW4/rq4L7NEdL49y6jOGdDKRTA0yFkUmJwrusqcZbcbPdYYNsPNtWME
s7quTk83dV2lJLs49DxSMaQ1MABBBsZLDWe2uQ64hnHF9jpDNnl7/TYZ5NgTeyC8evxp3a7f
vft5HveSIxAgMrvgq9r7xvs21Ct23oyYHQAhOSYmYiA20/OHV/c378ahjzGS8w8fnY3j0Pfd
fr9t12dVCAigajIOq3r1S7/8a3fb6+sf/N2Y4uXVpXU7Qvzw4284asZuh8z9EMe+h9CcnJw+
fPwE0xB31zllUZMciyAH0DSlHHvXj2MdgvcMAADiLQCgiBCCZk0mhFBXvqhxg3PBO0JKKacY
GREB+n4YkgI5ZAYkZMroR4EhQ8xIRAYAJjlZxirncTIWAGbGCIyWBFSx8WYKgVMPAMhdNk6I
SCo2xHy2IrLtI89ij3YJEUsYAXcJ3vUaFQGACWV6UwAIGYABirUCVcgSxzTudkiuOfu0Ndf9
6G+BCRhGQ/Ab8CdWO+071/rWwDN2u/ucY/vw41Ctw+o0dbv64Ycy9iTKq3M1KYENJDIVSzQF
Vwg9lGGLJFxlDoYODQHVNBoFZK7WZ7vdltRIx/7mGsCMOOUcY9xdv+7ur2O/lTgaECCNXbc6
X0scJUZJUXLub99y067Or8AEUZGHOz3nIs4u3ceZyFXV6UPJUYcdbN+oSkrKQ7e7fauAKvn2
q5+A5Hp9evf8x251rt0ON5dy9dnw4reLV54Uopp3LlShOn0Qc+6HrmJfX5yYr4w9+nrc3gFg
/fCDHMeUXlse0/6uv37XnJ1x3ZiZieSTS3zz3Np1HjoVs2nY/FSYowTIFHjiXlIm+JmpGYNk
oDFPznAqUirDJCpiwc+cBQAAU5bV5Xm1PhGVvHjsaDilI2wQ0DyZ4E2gKniuajUkKBpIAzMh
11WnGVsITWURiREUCUWMbekdBTonPLJCkhJlB0+TPpsRaLatWGp+cSq2pSnSBkilwcdUgGSz
+qPMr5r0faXZLKLMjEAAzFDK0c1KpY5bUlvv2eNDdyKDwiN1FsIBgBJiacE95ZPNAIynrJTh
pDCy2cyjKMz4AqAmC70pHGsKioHN+YXFME+me1YKKoAKMIGICQDz3BLYjgAerCxjonpz8yox
hTleZ1PuChZMKslDXcQa83Y2I/1MiGACZDgc67BMm7NiMwiRTeUlpXW+Lb3vih+AEAB4br84
x8XnfoYzxuMcST32KwAOF6f8hTZDmSqCXpysX49gOQ29REusN/WDCnzTj/uY8+nm5PR0w+xT
itXO2agSEIok1eCpeB2yY1MAb66hsSAwNfXFBx9ZvSoj3MAgZ1mfXK1PHqkkkQRgznlVIOeR
eBK0FkdAzcxyzpLyKH0/7CWP++2dY26a1erswW57Y8Ttydnpgycpp77rh5gcqvfB+ToOOzbb
rM7j+vTd/eub67eXoW2aVYIwjh2TG8cYx+jq1YNHT87Pz8bdjYx9zkm0jJWfXD0DA/ZA2Xnm
0gCNmFxbo6GZDmMqKU8VAcQhFjE9YOURAci8dzEJALBz+27su8H5OkoiZiKKGcQohOa2946A
CEFQAMYsiMhMZhPK4JxvjcYrUlFUtXXNIVZdjpXA3YB/8zl+58pWVfaOKd8+qeiZXvWCiLAd
7U2nCmiIXHJ0U3c4QDMCZVCvaiaoQiZomUxAs+0zo3P1Ku7uAAAoUHMKZm51Ru1pTZTHfd7f
Urevzh6Fy49zTuP+vj69MuTh9nV1eiWay1NpaJMqy8B0mgnebx623QvPECWP21veMHQ7vzrn
zblzHgx8qPb7H/Tba2RHIYBqGnu5e0MA+5uX7IOvNkxu3O9cVVsa9u+enTz5Rtzd37/8KSIJ
oDfBi8cOcuDh1Z13LgMRGOSxS92dpLG/feNDlff3HCqRTDk6pPH6Zd7fm6/MBfIh3b4WO5Xd
rXdB00hxcOuLrj5P+5fEjKFuQsUuuFCN+ztAJEIwG3b3Aozs7r76wp+cM/s8DgpQX1zlbpeH
XRr7Km9ociRNXQAXtO+01CwvNhAmLxnmblaigGB+ukm4z5jJQAsYmJo1nswsA543lAyGsgFM
iXbzVWjXcehVVHM0mxtN4KQsz6II5pzfNE1V1aVvlAAQFW0GqkGqTrNXMxCoiJlMKospKaIx
AhMogCmqWbZJIm8ADOBoIhOmYDS3aypwUBqn0RwXm1I+BFO8zWBqNo5zX4cDLhdeZlg+AGVl
xXSWEgE/SzGOpYDFwdeZpmiJtc6oMkfGyhpVdEq+MZojIAQuxdE0zQQpAwxNJvJwmBYGsABD
+WIEQ5BZPbk0y8DS6ldBzZhADBnBCEUKgE9NJ2XhUwCMhxBhibmVep255RXIhBcTPANOYU8E
IIS5+mBqMWxHG4K9hyELp5x53Uyxy0gUm3yggspFaV9yjQZAAFlKoVFh2LhcGZg9EjyOGU7c
bZGMHhQsE25NAVGKMQ39HtyZmsWUCdRiN25fPlg/rriJd7TvRwA0VVVlRBjVshlQvfbs+Cms
V0NCYEWt0BitlxwY+emHH3z7e5LFpGT6EQAsSnkamFzRyTKh5dLMQIkxpTwOuxT7rt913X2M
ncmY0iiaU1ZU6rfbD7/xvapqECHG2HXdycnZatUOw5hE8zgGA+crJkpplBQ/+Ox37bPom5dj
P0g7GkDf91GgWW0++PiTVeDtzZusasgxJyMyCklyGjszUI0SOyR2BKhqY0zMDgkBzDn2wYGV
+pglJmBMlJMYmKjWVbDppcIx513X+82G8xSjTcZJ4bQNtyM2gQ2yazaahjGnyjlRK8K8clO7
zCuOe1m15jz0YOhIzqoUlfooracHm/puGJOSJQ2BON08qd2z/uLtXq979WgOTVVZzUEZ5i1o
ApZRBUzmGpbJJIgBmDIRo3LdaLd3oa4ffZNCw4BqKinmoRvu3+U4+M0DAb776scm4tvVOOzS
9auqaVyzNtFDFhsU1EAyxAhI6B0AZGqNnAPa378LxGgC5NBVGKrh+oV2d8gluWiAbKiAuHn4
ITnPXeOcE1WJQx47DhUgsq8lJZWMLlgazYyI4+4+Dnt8eOnWRkgqaqpctcP2ncQeoZe9qGbU
kNzKlCRGzVFwNCC3WjUPPwztZry/9t7bzVfu4ilnVanh7DFt78L6DNoTCnXa3Sq6+vwSwIbt
raSRUy9xdFXD3kMcs+6HsatOLqk58c1Khx17D8xT5gvARODkAt++yClJHDRnYEYAKsJDs32y
TVYD9IQIcMa5N0Qwj3rqoUv2cOUCYyC4bOnNLo9JZ2s7mStDSHHIIuuHT32o7t6+6ra3FqPB
FCQCJDVTMO94fXbZnm3Wl5dApKYKKGKOEAlESqUOZbOMTAJsAGK9CRE5KlJ4VLBsJlKSH7Mx
mp8znWJ/SFDqyWe4sklaeCwWBwQzmnJIswCgmLSlG++S7sKintfFdoMDAAOeImaztZ9NdKlq
KiUWSSeuNmeXJjoQxRacKMWfDhHRCgCoTeBPc0DPZn5gc9MrgGOyVSpNJpk7Ls2yYKp/ErMk
ZcFAAmrGiAZaMs0wEdzSI7boX6YaFbVDmdRRnskWE5V1olsFaXBqYmlQHjIwXMoqClLNwsYD
J7IJPGfK9N4VLRdc59igHjqQg5t7f8BUlTxxv7LUZbjlDFe4aCYPFHXJt4GBoZpl1X2MyoYI
Wa1q2kQp7gc+d9KPgDjGNI49EY1jTFkfXDxhz0y0Pr84efTB6uc/9/quH0RVaxMDHU0rdHJx
CcRkxdk9+AdmqqIig4io5ZxjjH1MvaQ+pXHMveSxyBDFoMAbYHEsAdDu71/2+0+qqhKVULcw
duPYEzlf1yxeYkw5i2jwoQzglVFYM1Y1xE6y9n0nRpuHj58+fcoStzc3+2EUQDFIohI1yV1K
W5M87m+zRNAsCRwzdsOoCsyAYCJaLAsgeMeOSM1ERMqQZYQsygQp5SxC5BRAFW7u9w9OUSWl
UZA8U76P1tZWOQeISM7IAQfNScxMc8mfg+nK6WmDcaSVG5METwAIYrAJQzLfjdA6+S9+mv/u
V7SNdNlozoaean135eNtx2eSTYXM5v63YJOiuTiJCGCiBmaIpqpDzPd9tNWlhrXe3wz9IK5u
HnxC60sEkBRh+0oU+t1NHntV5XoFmsa7t+Hsoankfp+7u/WDJ7ZUkuL0DoFkMNPSo8WdmJm4
Nimor52NhIbNxgAIybr7/u4dxK3zlTDXVT2OMaZYnV7WDz/JsbM3z1KMpKBmzcUjAIi72zT0
SDf+9Ip8HfttGvaqGsceJOPppSNnYMjsm1ZUXNVqHDSNJpF8IyJ+fQ71Rnc3YE0aOt1vOTTj
fku+SZIVUNGBmke0GGl1Vp89oNBCaNAFW52R4+rkgQx7oq0i6rAlBFBh9kBE1ZpDA+Rk7HTs
Ajtij8RL6hrMwAepmqHvRGU2EUvqXI2dImY1T5OzkY2iQDYIpAOCQxC1fdR9NEBMCtedGJJj
RlQDIySq16JG3vvTS97uXL9HHyTn0pONmU0yMZHzrmmry6caOGkRJ5kCqhoI6FxxnLUk2FBM
Xc6CmgxFTUu1pWFx5GdraGpgirpkaApfxJlnTQxwMqww9bCAsq8S2jxY5DkPtES1zApATw7f
1NunqOQmuodzEmsSBKqaKIiCqEpRvE7NUcEmrQEseJsnFlfemCnoSBOGlZcIdFEVIiztJCZi
ZxOXo6WF0iHzVtJpczys0GxAmVsllaDOHKlTJpxzmcA6yTrfFzvAQU00vYE2FWMdMGeK6yIa
L8YADup1nNkYHL6xSed6cEIAZmI0Qd80NneBHMAJ6ixNRNaKO0JLs8iZ5k54WZyV47ilHWBt
RjcDhOb84XD/jhCZ6eNf+vaLv/c367pi5G7c9cMwSUmXzZHM4PzinEJtqmDEHNhXhkAt9TGF
/ZBMDDAAdCnl2Ms4pDRKjjmPOY9D7GMco4waBzAxyGIKpiWPyKW0EaGUdrCaAjBiESeBJ1Vg
xO7uNV88vXvx+ebqA65rBhyGTgZcn5wzURoG0dwNmUSGbh9f/nz19ANqVjZsU783cI8++uTy
4cNhe3Ozu88iQ7ztxq2apTR6qvvtGxl7xAqiOu9DfRqq2ikgETOTgcWkTJiTIFhWqavKwBDR
OUdFJq6l+U7xZUkUEE0Md91wqWqSEZm9lyzbDLwbPz6vumiV9zmNBCjsRbN3HiHTJAnTijUR
OTKRHIEqZwZIKCu2JH47UPD5wcq+/5qerO2jEyNUDuRkl0cWg1LxQ1NDaCUwMh2ygAmYEmgU
A4D9mCoPz8fGNh9haNiv8Oy08mvYvjXXaByBHPU3qd+mccg5S86gmvs9e4+OwWz96OsqWcd9
kUjPjyOYiI17RiTI5pz2A+y3kjrbvnXMtDoVeZdTrpqVmYILw80LdJ6gHe6vEVBSciEgqj9/
ZJLrzWW/OhlvXpEPGGpwIff3XDe52wHh/s0Xqd8hO/Q1sevefOHaExkHrhsAAEkGpLEnZCRC
FwAMQ02i4/YGiV2zUTDJ2cZBxn7c34Iq+0q7ewq15JiHvTthGDRltbyt21MDXD/8sLt9k7st
I0DsGMnXLZJXoDjswsklkHf1hpg1DUDsV2v0tc0DdqeXUgQ357g6setXKhmIl+48QFCBeLIu
AYCKAGVSVQeCALcjBaZdVDVbVe62VwVtFQZRz1M2HgGAGUMjCqCK3q+vnoS6SkM3BZbMRMQT
Bue4buqLq44CCDgzT8qEi/0tNS4l1uSoqM1IyJW8iBioGFMRJQDM+IKlwK/YpTmLI2pTxYkA
Mi7BIlhYzyRdRygHtckRKm6iKIiazKExg1kkIpYNzIzAmNDMsgLiRL+0NDnDCYNFSw3TXFdb
9oYLK1iWMyFZFhA0VwgLlqSdIYBOuscJK3UCqqWIeLLBE+7iQdu+hDcnvjIX9y4IpwZF8FLC
d1R0V4gGRrYI1w/OYsH7UiQ61SbPtn+y5DAnjwDBLB+gbgrzz4gHAMWW2YxhNmcqp9OZZ+iW
eOAh3VX2fIjtzh7MAm22qPTnHNiElxO6HsrClqAoTM73tJ/m6qPtiy9yTJn7t1/emEqOCTya
5H7frU4uiIrqk6aMnekw7DSPxC6ncfez+9bCmqjdnDSmcX8zijIgI9w9//GP7n6MOZvmkgjG
OY1qhoGJCQCBgZlYBcRUDR0ST6dgikVkp87QexQFZDTVd9c/bS6edLHb/vg3z68+Wp0/ZA5k
Evf3rl75pnV5FNH99na/vdtcPkBfDd1tMFXg9uLhyXp9/fLZGMeTy0cvn//k9asfEgOKIyXf
6unJ45qbut2EUDGR88FMnfcFmWwYI1IZoQEpqSgMYyylvCGEKcrhkIiKt5iGUcEEQAHSOEiO
TVMPCZjJFIlon3WfYR8tlQfPhJiTZiJ2qIQQGINzZgnBAkuXYKBVsF15n1IWNki8+eKa2qBZ
9Idv9OmZT5Ipqwk8XItneXcXVSEbmNp+1NMakkA/WuXIMxmSAXqmi7V/Myo2p7R5iKZoquRg
89i3F+WRYrC8e7vf3cYsCmRmCGoqphRW56vHXydfj/uX4fSh0dyCeH4utd8iZE43Y7dDpCQK
sZPtK1G12GfVtLsBVRgjhJVfna1OH0p3P2yvg3dYb1K/Rd+E9QX60F2/BDN2Pvd7NUI/5H7X
nF0Cc3//ziRzqOurjyRG8gGJ61D5PFgi8A3EEUJDoYZ+H1Znqd8pErInR2k7qKmrH3BO4eFH
4/a6jD7WPAIzh4bYsavGfq/DYDmi975u8u6G6hWx91UrY4+ojr2kiK7ClHXY5QHYVdXpJYXA
ofLrjakC0RT/mgTZOJkWYv/wI9nfTrZqjrqaqoaG2RlkA0SyTozRECQrdoZniNsoFWMbmCh3
o44pXzSuSyYyGRvnHfnKSmZGxNcNuauQooqAKTJbFu/Ye4cuKPGgAGAskNA8IyMktSQ25WIR
3DxdC2ZuJEcMY9JTzFMCaM452RS7mrYrusQye9QRLia7PD2qlsSK+7VU0cpMNEQtiWVdvHbM
qlmhqF5K72m2UmFWioKBicrVyGrZQMT0YMYPRvZgRKdlL5wFSyQwg+V5OAsB0jS5zLIaOmRC
AktWprxbgVhYnNq5SGuGLsx6IDM6Q4Ue/eRoFNbUeMnmxBzhIZC48K3SqYrmcrFpus2U6DpQ
I4CZvc4hEjzucYVz3dV8AXC6CHaUkzqK6cGhBcp7Y8+m3R4QsUQoD/Sz/HQJ0c0h4ukZWGBs
uo8TCVRRA8s5Sbe7G7ar4OrK3wy7YTfUbh/qxnAa7uOJwanz7u7+7f04hCqI5q6P5+urB6sL
qDZxe5NzGg1rwgRyo30azRfSAoSgg+oU84Ap5MpTxBUcowOOYkNSX+T0BDilJ0FMESAV/0Us
S97dvVo9/OD5D/5a/7Pt6f3ji6efuLqVGLv7GzHbnF0O+3fduxcXj6+YQHa3aqhimCOa3N++
3W3viD2JXp4/WjlXt3Xwdagax4zEZqWPRM45FwfBTdEAwKaqzAwRY4yihlRCJKpm3TCWB6Gp
AlHJ3UNdhZgEFIgopTwMY6hX+e5dLu14kZPifcw6KX0ZTBkwIw3jWNXsEBAxgkcSNdhlTxaB
XNa24r0CJqU+2dOz7RtqovCnD5wDRALPOCStvX3yQD3lD07ys2v66s4BYVujMVUOzwNeD5AA
TY0dIiMSclYCMpFpvl2R2VKY3zRRrsRMNSM5rurq7BHXa1AzYtecdNdfydivH3+9GKjyEpAK
Xn+BsRuiIKLZW948NkYhZtdkycTO+UDVKnc7DJLHPYcL6XY29q7eEAJVTY4DuErBed9ofmWS
kb3mqCoOQCXnFJGcpQQGbnWqKRKY7G+rdhMY4e1Ptb3U9swjA7FvTxBp3N7A2BskMgMmrld+
fWpIgIwuIHvJ/XD/NlQtIXKzVknmKzGw7TU5D2ayvTMzDHUae/IVqGp/73yFJgiQunuQ7KpW
h10OFbcn6JwBAM+iDJ0tyNKEWzKtT9tv/RqwK/KWubEEUoq5lGpOSi/NhgCYTUeDt1GKH3vT
p6wAQI6pJagc3O3n2G1pIlbsJSKAsXNEBIAlTIai5NhymuzilFY/zHTXaYYZQBG+g+lxu8I5
NnfoVIulCn1yfaeOG2YG4LHw82KLkBQQwNgcIQEOWUs7VJmatEx4ZVNUbTKhCpANss7t6Gfn
fXKTFYSMtHQURS1nKVLaZJStClQUAnmIh5lZaekLBgBkB3G/TRCHapZkYmcFjD0vjIccGxgk
sSRmAHmKKCLM+TBnRT8EWpIWOhd+wazfAFjafByRkBlzlrDk3DnwqPUUzGL7Al1TWUtBMi4K
SVwqkucuwcuO58Lk4n8cHxjhoOlYIo0wb35QKx4WOrG+mWmXQOUCURMezzs8eA/LD2CGzjmI
CzBpDuetkKEkWbyPsTfVdXApOJHRciwrc+wcs5o64uImdttBo1pNiQy5Shn6m3ejaAIMYG8q
fh3AAeHcJwgRTWBI6rikHY0QDJFpvk+AAbnXvEuZCYMjLH0UAZeTKNECZLp+9/MPP/kHKdQx
xZu3zyXGq699hhz6/TalmPquXq0Ictbsq7qpPLUbvX8HIpazW60QMee0u33brjaPvvYN1WzT
ewGqqppVTUVnRg5ujDnn7L0LofRmg1B555wZSNFYE6ecVY0ZUxJDUFVmDp6JpuiySN7d3z89
O++cpX5v5IldlLSPsgresrDDrMigjghMPQETVgxZKakDFAbso13Uu5vx5MJH77J36KT66dvh
fuhO1qsPNkNFOggSY4VsIGJE4EPFyKTkEIHBNpU9PYOfvsU+6c0o5BipqJQVkLACKRqiiRMg
gMxhfrb1g6a7URUAdM6Tb9DVaJr67f7V5zkn50MaO3aBnCtenKo4U+uumRtVZQLNQ47Rxk6H
Xk8uq8uP2Sztb8E0Z5HU97evXGi4XqNZ1Z4QISDF/R1IQuL6/Enc38btrWs2pFnHSL5SyZoz
eg9CGqMMHRB6wqpuYL/NVeOILA7mG5NM7H2zFsk5jSZZJSM6DA26GiTlNOZhl7u9maD3rtmw
CwCq3X0CQucJLKzOhtvXAsDEztTyiBwQEXwFedCx52bjq4bZY1VTvRFViSNXNdDcnW5xaYup
WSwTItarQ94fAEqch112J4TvqEymMPRoqsagBBQIEAGJguPGq0gx0Jp1NjkIkrNKRp49+YPT
XGrDSubTkJ0BqCiAIaIisiuGBpfIYYnlpCLzIAQ0Vcg4Kd0VAAyRgKGUN5lBUflPzxUTGoOZ
iYIYZC3OEgYjJcgiM05AVM0Ck7htAcEJSKBcCpk1C4vrXzY3AFAQOopPHTGEolHQaT022+oi
vJyyVbPvb0vXRFzYipVujVMWEBGSqhgQgs/meVrtkDVJAUgANF7Ek2akWL7JWsSE03mp2ixU
MS1dgnEymuXxKB8tQhgzy7OxP/qa7ytNa527zQHjZFDLZCI8IP6BB02+zryfBU1m4Dn82Arc
zc/ytIwZb3R+vMrPDg2ijlyFI+yC5dPLg2+TS2KLiwAGNIcv2fmLz753/8X3E1HuswxD13UX
l2e72CdLpY2OIYopKpZ4LCNJUiLPjWXLJ9QIN8iUUtcbgg/q+IZSn5QBEEs7OHAMFWMGy9mI
0TFgyQEblLgtgSmqYwQgmd5pdDSNIBAF1KmDK6qDnHN3/+DR17Z3r/Mwbu/fph+Plx98/fT8
stvv8tgP2xtAiCkJoOEd1ZaTMgto3u+2wzCEqgmhMrWYc86ChAaoWZBQRab5vWblW5dFkIiQ
THVM2XuPiEhECGTk2JW3K2dhxNJqXkUQMWdQVSJGRGY3dDtEXZ+e38URAX1owDeGgI5k7BAE
XIWgXjWpeIZA6FFrEgVyhJ+/ur/f9/uh3edEjx5cwjWhndUxuDCYY7RXOx5HeX3Xf/PJmi1e
rJCZFMCIStttQrhay1mjMfu24ssVZoJooAiAbkijiVZQRO00D/M+hMRBjdqLumnj2EHYqOTc
3VEaAUxi5FC3l0/T/hrAkHhyNsAUMIW1+ZarDcmYYyf7a+WG8zBI5n6X718LBcjJhVqtH989
59DC5pLPriRFI2eh8WesFCTF7vplWJ0AOjMAlVJgT0SgylWrsTektL3mUDXnVxr7sdtKu5Hm
ylcn3lfd/g5SRARA8s0aiGOoU3dvBqFe5XHI4x5NpN+DJmSHgJKjArCvsogzRXbOV2516ro7
rlr2NTGBqmuCeZ87k71wvdI4+PUZugpyBDOuVhqH1DE3a6PDG76gGC7/1jkxdDzVz+y6Oh3F
Vrtt5VJWBLK9QBQzw43TinDlyQyywknFWSwJEEEXNaU59QQmamxTA/sjQ3cwIwJgRxViZkBg
UaFwkSx2yDkBlHkLRa1HYNmmivq5XxrI5MyjqJUK62ICHSEAEVoSiGJFT58EPSvNurty9KSW
5/mUJWslRYQxCTqKvG3KSQDANDMWAK00TzIV0EOzIiOwpAfrPDWeF0OcpiQvCFnSPUu1LCN6
PCjLYQJILCQvmy3WPwMOCRBB1ASmoQo8t7qiWXi3NIKUgxxxKXm2Q/OJ8ov3KtMWyjKJ9Y8g
Zt4Ey3lNmCFH7KrAaok38jKWGoHnWulpeXOk94j3TH8vFsHm8CYefg9LWJGON1/u6ZLrLYeb
guZT4yyYgXS5oWXPXNjlLDqZPmjoqgaRGtIeDL3v+qHd961b327vot85R6W1umNngFkFFAMG
8CoDAKBRqC9PALo3odre3jWOTWGMqY/gGUrFP9WkjXcOkBENci5NKSZeO0WzEQvFD54UQEQB
0RN5KGFtBELHBmACeLq+DJS5qpoHj+7u3txbHHP35Q//zub04smnvwyr9f7+hkqAG6zvdlWO
/qRyKLJ72bsTQCbnxTcpR+xHNCXimPPQdVW7UQ5mMsWQHZiBQ0DvGLE4pJhzGcCkITh2DBNK
kwMwA+dgHBMxg81nKMLAYDZ0XY4x1E04u6rYtcgGiOzS/s6NMWbxnggdUU6JPIFjDA43de5S
QIF1TUP96b3lj852rYvXcXPh79RsHeDx2o1jd7Hmnfdf3vln1/J2K/+lb1HptTyNGFT78AE+
OqE+e8n+hBwF53t6O9heoNQv7PdbUDWVMrBgSthOD7JZETevH5+h32dRcugbCo3m5DYPXbMm
F7BI6UyXiISpKlfmVuOwJ/YATp23cYjDICJEnMdO+tfoKjq5SrtbkJz2t259nuNQMogIBqGm
eh1379L2ukdM3T2x0xwtJ0DUlACnMZ6QIxFhTjZ0no1YWWO+fdansQeUoUPnXdX61SkihfaE
Qo3kZdwDMTJxqHTokAgE0BREbBxctWJfZ0DnnGtOJxsdWt9uKLRmgojAvrySpaUssQckFSXf
mGQEpdCCmUou4TQ78K7DWw+z92rz+7n8MhPeUa3RvCkAnAZNRddntmIwsYcr3o0qkh2jI7jr
RgDKCiWmaAClyfKhJ8QhoFfAAGcRwZEfDgYAKZsi6kHjV0LpZY6tqaFCqTM3nUef6NLQDwBK
KwSzPB/UkakJASpAEkuqapgJhixLsgcBCS1P9W0ACBmg5MXSXKuEs8EtMFOql2jmMTQxPyiu
aKlmiwZJphMgPApywjQSfdHuLwy59N1QMKPJoBcEPWpcdOAHJSxbliQ6S/dwQmgmXNrpT77K
kdQB55zSASBhganfiSB2HK07YklHi5/v5uExm4NZMFMxmqALFeeRZzZXos0yToBFmzFtvOTP
fqFpycQ7ZsXJbARwOuBSaTw/CbOw8Lgn8XsACb+TmOHUZt7ATCWNYz92OcV2tc4xqqs+/Ow7
V2r9zVfdq5dgQIhZtcxVcEyGEruE6nKW7AGtu7t9t9/ebRx6yWiCSiAZEIFQ0UAtZVEDInSE
iCBiTGiAGaYMrqoBAxLK7IbkrMDIhJ4QGbJamTJJaNv7V3d3bwA0iqqAqYopeNxev4nd7vHX
v1O3m/1t0eUQM4XADtQzCtHq0afoK0eYU8qSUNkQ1UAMlRwxg1kUo6ZWBVBhMBeCN7MkCmrM
NJbptiLOsSYBAMdUB69zfzCAKXpiqimJ944IDVByHrr9uq6JAvnABlkFDMhXPlRj3oMkYI9g
LtSVl0Do0NYhq8n1jp5chFrdTV+ftr2j/Z1d3sqpdDdXZ8gw7pNdkX7xJn3zycVNp9+78MxD
eXSKWXp0Rh9d+XHMRR7plNizC6Fp8Ku9bQVX4YSZ+mFcXqhJImw0PVxzbxtEMFMjV54fDLVb
nQGAqAA7ADAz1IxpNPZmqvvbnKICJ1EcR8Ixd9uUs9tciIIpIKAAQE6oVp0/Rl8BkOxvuV6r
ahYBAGSHiCpJ0ihDD+yICZgJSAtXjj2UTn0GhBC7LXjykEuyJQ0j+oqIuH3k2g1XKyBCAO8C
rM+Sr1SSZyfDbkg3SAxESGxmNu5hbEDFOY8uUN2WvrwYKgMyJHOefbBSd2OgknXssQ2mJiDo
Wot7ohN0HomNDt25j15XnEMj75m2915iNUAS5KSaxNYQGJXQxKZpv0OypBDMbnsbMlz30mVp
PWUoiR1FYJM88xTDmWZNdujYwsHBLEkJji1u/7xBMY+HxvoGRdOaEbDcUgPAqW2gzkE2KCiC
kHLRE5dCK1C1PK9lgqVfsMtzMS/MnKDUIh2rW0qXQl3kdgioVupV5uYOiybeFsxbUPZgQRc6
cxwqBDCdm1SZIaEswDY1WCiXttQU4EIfFw/QZr1J4RbzdZwDaHY4tUleeHg8jnjJzJUXTfv8
q/nvqTfxQV04NYSfg3KT3EIBCydDAABCK2Fehmn+4rznKUUKy1Watp4AzUBn6zCj3rxcOyxc
56jv4Szw+Nn++8BVuaF2fPrLJeH5EQVEVzdx7BExxejYJQo3t3uQtL/pEJCZkXiygsxAghmd
hXrVovdDHN88f/bqzWuXc+UcI4DC5vz045N17OO7d6+5IkCwUYQRAlUePWASK3O/zEo/FEhJ
VRE8SXn2EJmnx74Uooma4pRHTgKiGQ2QERmIUbOKiq/80O0+//7fuPrwE0YyAyRUsyzmHRKC
D46a1pDASlt0b74G0xJMUStad/QM3sSQ9mMP7J1zXFzQbJJVi+i2qYOKZjUzFcdQBSghFKIq
+OLcpZgN5tKqEmVI0RGypZyQnUNmAyTn2VfEvQGIqQuVxB2hBYdF8VmzrIMB0gp3GKqSSnhY
3T0fLmpvZrvgoKlX+2F/cbZ5d7d/fLk5q5KnyWMxA0f29AE5ZwbojJIgKSAjOmTvnMPnHe6B
zx5+VO1u3vYZyc1zucssIARAUEKAjJQVoDknUMs5j7naPNA5TzPbYYKcLfZqe1qdQ3um+2vJ
ySSZZBRRMGrWbnOR9ls14vbcJMf7txoHAHKri7S7gRTdSW3sJSckynEYtzeSIrnKbYKMPTAD
kaZEzpkZEjrvSZJM88KmdAKIMWQCgDFxvbY8IJyxr2BWv7EPBpiGnaRh2F4bGLLThKFuICUG
JRNIA6Hl+7eWM7F3zYZDo6YgmdiZoaakaUQADA0jQmgkZWBWRAwtVy346tA4w+ZS2MWIzX/i
8Wt6wDksBsk51zL1aPcJkxBbiuLeRteavNlnIrjaVAh5H0XMBKDPCgiutDUCM6RSpEKw5DHm
buhzPRNMmZ/CZCcSk+dY1NH/sETL1IqGTOca1KlahwAEEcHEDnZIDfIxZiwTm+xwALS58Gg+
eZjbvJZ2iIoFmI5tOgBCUcYjAJOZTfVkolYEFgutOc6sFAawTDyZocUIplFdSzBTDPIE/CgT
OJXny44JE5TA3xFtOuBu8RL0qF7tsPZJXo9H6Ln89oDkB1nf1MF2umzLT8tLP+8Zp2dticPN
XBsW1EQEk/kWM9rSddemUKoVsoVzYrBgz1I9t+S3Fr4138jDwuEXvCMEmjeaIju43OhZ4LD0
X8LZvwM4IJqBGTDxxYefjbu/IZJFcghh3/Wv33yf4s6RPXr8VGNfhIrFQxLVuqqGMa5W7aMP
v7Z79fLl55+3hJF8r7ZC7FS3BiebsxRiP/Rd3BKRdEIVGQEQOEZ2XE5Zi6CWAAmzGmZlR2pW
mocVJyKbqUJpIeaIoDS1cAQAKgZqTGgOybBu2+r0fHu7ffvyy0cPzqhIAtViymRAQI5Qc9Ti
MuRkKmRCRFwSzFY5ppxLeJ5L2YQjcOWi81zRlXNGYCIyUyaISUVw6EdCVNOqCsu9Y+YQimSR
AMwI+2G4RHDexWTTs4pI7MhXTJxFHHtwTagt+D4SOIZnt+BIL2p82W0etmPjogIRyI/f6Pby
6S/TF2DApJuQbrbytYfjTtZvb2/D5al30dFS6mM1R2IKJzWMNQ+UsqAAqCEbO6cGX9ylXcyX
Dx/jdv/2bm+A87RCXPIAijiGlYXRJFkcsFkTgEomtlLEAoaGiCYaO6xWlkczkxzVgFxlLuiw
A2SuziUNXK1yvzfNMgy8OgMDknF49wwIgTyvzw3mqhWz3G/zsDNkJg7BC0oeh2zOsgCRC8FX
NZLj3KtBjKPlLJKUGMycAaMgEvjGry6oaqfuNnOUpcxRTDkiMVUtqLD3od5gDaQJ1DhUksn6
HeRRVdV5rFbAnPutCxWYEREgKhiwR2JrTowHdoF8Db7RSUZreGQ47fAuv2eq5rf/F39jIs4S
lQkUszUghFQaRSEi2P2QECY1FC/tkUrkELBAks327ODBYhnAaEdWTedap9IYs+CK0fuznYo1
PNisYyM6Wer5nHARGkxPCb23H4SZB5jNNUew5P8ml37qu4/vHeeYphlMtl9nTYcZ5IIyutRU
mc2JpIVVqM2WU0vQaKJdczANbJZqz+1uJ/Y2BycXIHnP9Zhe8pl4HDl4U6HWEUGZxYZzOHSp
zp5hvrDcAvTzpZoR7fgyLk7QHCE+cKa/z4O2QDmW21X6OSkAyBwhpPlJs2NB6SLEWJBsYXJH
N2mBNDy0R3hPEF+Ww3MmaVnTQvXI5jtbRgPMl7E8P1MRIaJpcctKSzPl4L0PMY2SE5eiPzNQ
qesGkIe+B1WqmzfrlhCBuWrqzvlujFsd7959ebo+b1ft0O+5InfCkjIkEEbHwEAEIKCOANQI
0JeaRcCpOoWmJzAnsbmqzxSy6YRJYCIqYmCgIgT86cfffHDxCABSludfPc9pR8xHLBSzmmSF
NDJ7duyd57YuDXIZNEUzSaDBO0eqEzc2BTM3DiMxe+9KNMJ7B94BAHsYx0jMjtk7MoMxaRYt
QmFDcM4BQooZAYgJEfb7fRzjBGalOxqRqpD3IdRpvyVQzSMBIGhJYPhAf+X56h/60NZeDCCw
AFCMcbR2Q9rwgGoIEAWaev3Vu+0vXfDffHHy4s27i6e8GIQQ0AXWlHVvtCG2CkgsCZqh2Mu3
9y/e9qOG6uSUMl6enILC6/sdgAFNjeawvPKl3WN7YsMO6w06r2mEqTvPkSWSJPtbNEUO0m+R
2a0vpb+ToZOxd+2JxsGtNlYmf/ig/T1IJB/azSdpd6eipInXtaSBhFSy5mgqxF7GAcjymJyZ
mUjKLjQq4hC9r0VEfItIYXWabl+LAFYrcF4kOch8+iQbYmjIV2UC0cSKVc0MfO3qTSFPFgeL
vVtfACCY4LhHXzH2SA6INOecRnSVASi5HIewrsF7E8kK6ALkpP0OQ4PNmiZ2LyXyXl61mXot
7+lcFjdXsx7Zo/kdN0TEbDRm7aK2Qc1AgRyCoc6KcvCMnrBLkz9rCwwakA8HCW8RGi23zKZD
GR75yBO026GjYLnNtpjHw+s12a7ihuPMaxZcmQ2mHf4uVSI4G8Ajo3oY1ViuxlI/O8nOFlup
v5D4sSNLPLOZQg2WFu/Hqym22GzW180WE/DAj4/pmk7dh5eMV7kty41cDj6Dd0EiPFKaz0ef
UpFwOF88grfy5zJWxabK5tnvKR85EljOf5aXFCYF6xxcfP8e/X2/bGFvhlMa0w5wgYeiREPA
WeoyLb6McZmuQSFTuHQqnHeLpR4QAGzCvAV9J3XMUWHG8kW4JPyOfL3iY+FUZgILGiJKThPC
mpaPpZg0RzCvWnxrBTT2dRz7Z89/5JumWzWWjZyxS5LHFLNaGvZDP3bBeVeTZsHKwUglSSgy
3y9CAlQwV8ajIGSwLEpUmtrB0u9ZAdXEVE2AmJkgiRB6Jk5pvHr67fX6cu0oiTJSzoPGfbfv
6jpweQzEfBMYFRDbQOV9MCAkGmMyEWIaxiHGZEihak0lCzjvnPPM7HIWBhSdCwicw/l2IUIV
fPHUxhgBKGfxTEkEmIiViFyJawESYhzGse/96gRTmlCBiNAB1C7U1HcpRkD27DxZJgCEj86y
QBWz7BM8dtCw3nbYBv/dRz3B3913mSpkhFXQu8EnqEHG7z3233912o27dQ0GYArBoXOoEfI+
M3WuQTAfELpBfvbl/dv7RMDf+vDxzkLKev74sZlZHN/2JaA7RRBKbxdEVGSs10gBEJyrAGZP
vcSNEHXsJfZEbNTLuA/nT4BI+/u8v+e6RXIUgonm7TuLgxH580fa3efu1kz82aPU3RmASkJT
TclM87C3NGqK7D0Rak4ZwACYgLw39v7kAtnr9p2IVJdPMDSx26Fk4MrYAweoGz77QId92t1Q
1ZY2zItOHQmZPOIp+grZ4eoUVNFVJcMB7amZAhIBqKpxwnolKQEAOq8iqoZqQGjMQAAcUEYO
NftQuLWaK6/xomFbzBDM5nZmKWaTCTgkB4qdVQBBlw08I0CJp6NqrthXjJ4wibnZy+RZOmgA
iGSATB6YbYrE2GJ9ZwNjAIgHvMHDMgqsTUkiWxZZkiow2+GZScDc5WcOpB2BxnI6c6LNlg0R
AKabcmTZj0wgHV2N0mzJlozUFCE7bKTy/uHeX8SC0AsMw0wmEAEUZIqaz4VUWvJ2UxbNYJL6
2RxGg9kjmG/pTDSPb/Vyr2F2Cgq4GcxXGQCmEMa8G5ufjhkMDpb/cH72i98dP0nzOt/7DSwR
XphA7z3S/D7W2UToJnQ7ZMum53Z2tparOvsZsxNmgGgo08Va/B44uvhHT9GMtkvbDzs658X/
WigdIDD5upE4KphzziCVE3QA69o7ZgEsY20IKUscBo0pDVl1ewNGkAnIqLI8ivOuChTM5zFr
VhmEvCMm2jAqqKkA4lQgiGV0HRsCQAYAMzUD1VxK4NUIERhF9PLk6uzkfEzy4vWzLHZ29sGj
hx8zu932bV1fIFgf09jdWRoqj4AEFHLK7INzzkTUxDtG4jLCWU0EFNUkZ0DKWUpbtJwzUpSU
kACxDcyg6pxzRMiIQ4yuClxaaRToqqoSBIhjVDWiZbIJEMA4lpMCx1RCBWqWkwQkA0BygFA6
L6Bz5JzzIcYRNKPzjOgIwKwb4UG9jxl+dt3UZPVKXtzRN64YIRvoLnJVGYMFEgRbNxVh52D3
q48DKKkqMSDCOOTudqw8AVDeJuSRG5O9f/ai77uxDZyB37z8ch8h+9V9MjHZrFpNt++6UX1V
qvMAZxBDBHKzWPcoK2FzFMZXfPYk794aMZKX7U3u7/OwJ3ZqhiqECKk3DlkSx4HbMzBwVStp
tDSwC8hOttdACKExEctR48C+CqcPrL9lpBxHZldVAUI1dJ1ISt2dqaiBiOrdWyCvWWzsHLQA
Br0ZvCzjdtL+xq3ObU7SLLEQZGZqSyMJnAfVokE5WWuUJKOvyEr7mY5DDWDoqylwgYS+MslE
jNSiC/OoSZj/nN732fHE+Q1fZFQLX/oFw1fqimw7RM35wcq1TvZmbwF7watK0SQw1Q72UTeB
Wk8yY85s+4lCA3PNVrFbhzDUkZN+CAK+Vxla/pwzEtNCC0zZYYuJKxxc/2nLGVzwaF+LMV7A
r1jumYi8Z0GxINBkE6cqqxmxUI9SRROaHey1FfZQnIH39XdTnmm+/RNXWaYJq8I0GMUKZE4d
b80OZO6Qnluq6I4PsEDEdIzlmhVMhdl9+B03feHps4DFlj0uV8amZcOyq6OE1/xowaHa7XhN
R07DIZh9LAFZrrXBwUM53OP5MDMnXILwhMsyjsBpPkSJ2P4CdCEAos3+7/yBibRN4WcrAbmj
520O7gIih7YdczLTLFOajMihJIBSlpfNTEUAgQhTjJIzmSPvFbNihoSucuwpxSgRkVmSQMNc
eRkVFBQ0j4oMBsShlE+BGSTTwcAbZ5Bk2bFr20uu1t4FUFPNq/VJ8IGHvvEhrLlhl/nkdHWi
Egn1ol3f3L6QLIgkZuP+bm9ILvigeYwi4hwXtYJkJadiAKpGjOwByFDMIKUsklUEiQ0AmFSy
SBYVE+FHDx4yMYDFLKAgqqaWJJdxt8WzUzMiIgIiErXgiIlKiVzKucRdEUnNqrpu1uuURA2Q
yRAQqQww1rEfxxERCd3jVTaJjiFlHTOsa2g9rWtUyYR22iIYeoej1WSqaoTWeH3dhcZnT4Yg
U94QwXm476wfZFOblmcgGVfw9g53HTPq+eXZwwfn3b4zs5yl33e7MY3ArccGcp+yzkNVZt8H
ixe0OERTJGMOuQA7JNaxRzOuV3l3HW9f+WYT1md52FmOrmrRxIDJVyhJczIkJOZ6VXZOvpZx
r0BcrzSPJjn3W5NIodEURbKZ+vU5hDVoJiI1iMOeqxYAddxLHMzMZHKJXFUBqKVRzZDYJKOr
gNzBJNhsXGbXcPH6DObKKyQINbArVQHkAjlPzjN7mNvxITP7itgh8aJgODY6eOAcEx5M1t5s
ZjvH9gnm93QCkd3tu/393abik5pj1l2Ehm0TgBCHMYnZmKFPejvq/WgGwCXYTeSatn7wAbpq
4SzFjMwG/ciQHAyO/SJteu+jhw1mEDqc5sJDln/j4arCbAwXtJv2owtXmP/To5bnxdyLLXkm
MDA1KNXMB+ZzZG3L91M/jxkBl48t1Kn8EOdWIDq1nC/bmhVV4RyHlKMisPk2HkiWHd+7GV1s
DnQt3sMv3uEjUcOMM7/wgb//l723jf2ObeeYLx7dnxlzj/yH/39hV9YcN3Kk86gDVzdJUaKO
ifU4PLM/wf//D+zTvm44ZrwRnpU0Eq8+ANSR6QegADQ59nYwGGg06kbll2clrsdtzllrcNXf
6tonWMD+BRuyGcDE8Iiu7/UyLVpqk5kDKOtbzg2Z1ndR1k51yVrDJN/qtGcmfWbM6fDtt9if
phAO9E0SgHC2zjTOn/uh6SpEFJlT3xHCkJSM0ZxVIEEWBGKTgxh219d3tvIBU+v3YAisWnLj
MZCSUePYusaKKgGSrYxpfHvDbhfiuL+6u33/n9bs3t/+6Wb/rrF1W3WN8XvfXHfdcHo+PP7e
OTFsQ0gGg6ReRWIah9OzqgzjiMb57g2aKoVR8zjJU84wEatqU1lX1+KuVafVYRFJKeY8uaaJ
SEZiQFTJCIjGiSTJ2VhnRWQcsnOOiZgxhEiI09nsAMBMlXcymU8UplMI0mT/VXGGJ7+NKa7i
eHy+zu+JMIqgKBpCQiBjmzb3rRn6nNI5HZMyEQ5RPrwzXw/m63N6vw+IeH+EfT0l9oNfvoR9
k+97/K9fj3/9c/3nW7j28fdT9eP1OUQ1NB0DBFPg96/f1HLat4DkJEN6hJpd17G/+6DAj9+e
KwZTkU+CTn1rTshP6tzu6ocUvj88HYbI0xn7Rb0OxeukhOyvfkoQk2rWFGU4puEEOdr2yrY3
kkaDQNYaYwUxn5+tb1Pq2Tqo9qA5h4GsRwAZTpLFVg0hQ71jX0NOOfSQI4Ky4SwhKxKQAqN1
cnpkImQH6YxExjtJCRFyjuxrQgK2KgqaZTia3c1k0tRFmT+TOly277wry/GhCAhzEtGZN0Ra
4iMUcApKXbY1AhZV0qwBfKFG20odAAA4MZ/4ghRMZZYABuBml5+/nKM8DirAUz6tcwJHMHk3
PQ7pFKcTCOdhITNbW+3fkm9Fis95WcfFNlL8JBaqpqCzsL0hlmXEKwWbibfOKrfVrj67CE5z
gFvqs1BBXYBr0VfNJqgLV36VkltrYbpn8vYCXTf6tcXnbxmQqKLqZMAta64zoS3SZCGYc328
cmfbtdt6jYBCQd11kS9IewErBYBlejYPLFM7f91oTVez0FLjK+ZmDv4tz6z9wvJGv4w+WEK+
1jtlRDhXp0v+rmU4U19Wi6ZuW18aXnbEdHMWpzbyYHFe3QwAQIqPo4ISTqa3uZll0Rc0KyY5
QABiGA5PIpmmZZ1CWdgIoEgWBCQkYmJDKAgDIFlLu301xJRiHM6nq/bm7d3Hqtn/32//u+v2
b+9+EIXnhy83+92Y8veHb3fvPkFOp9MhnJ/byipAEnG+Vr93vjIIBuHx6bauO2P9mbwOD/uq
08oSyFkD5XN4zP1w/zg+5adx17x11ipg6g/GECO+2VUhxKq5BeaxP0t/tCRgjEM9DGfssetM
zhnQgGrKeU6dnKY8dEoIY38cz0e/u2G2gDBnqEgEqlXTGWYKMbKZFe9jiIyISEmyKoQYu6Zi
JubJw0G9tzJlbgdIMaQkosrEPMVyn/sYRrYVDAnRISCIAGSyjqrGO388jcQmKRhAUfjtUe5P
8ccb+n6Sm3Y+V44Bvxzyf//9+a9/aZzrMpjPT/HTta95rBr/cJAs8u6KZkUPAjOOGf7nM7zr
xg+36C3mFHf1Oe92gdzz0xCSOEOQ8k8f63bfDWKeRvUB7pWw3X1q6/uvX78/noENEs02sELe
JsFk0viggsZeY685g2YkNO0eJjdPRDh+ZybQLHHM44nTANaxqzCeQXbgKgojsVGRPJwAUDUp
qKSIAGicQUj90V29A0mgqnEQkdwfNSdmIN9qTmk4Gd+oCCEIIiFi6iUHZUPsyDdsLFZ7cJUu
p4hrseotG/oVYSn6n/mf6oI0ayRnoQ3F1j993TL+y9bFFReL2KHTBl5hTVf6UYog2CoIOsNM
lPLkmwtBSETGqKIqKn1Sw5PFV2XKCVl3vHtT7OULrdGVDOsFW63LaHWlyDizyIWbh01Nr6Zt
uZAV3y/uLx25kDkWLZsW7FzgbtYRTpO1IWllsleauMRXbddwrXi7MIVkTjR0Bq6V25hGuyDp
BroVXgx4qW+dkSXZyDy49RusGjtc5eppwuHS12KKbi5FcU0HvVE7r5UuE1GOzlwHvG0eNtO1
xdvytl6u0PygzEaypZtrmys4lZVZxbYl8m2pastAlVktHM50Ctq81EqlykV/uLSupeL++DCv
2LSTRWYHMlFEdtYQgkqWeXOIZEWFyvv67fv+fLp7/76rG0LNt7feIoV775vg7dg/O0Ods42V
qvUVx98e/sHVzhgbQjBZnu5PzftPJFFUUv/8eHq6urqCnM7n09i4pIlUpgxk5374/PjQx+EM
AV23r7xqbOspuozOp2M/pH48Glcp2xxH6x0bhyQmgWgGUBHJSSb3RWKCKRBaJeQUxjD2fRTQ
IYTx6frmjbE2pWSsN9ZKDPzDx4/WGmYzHbyUUnLWTlpBEQVQa0yKSVVjTMw8+emzYQTIInly
2aDJKxtFctW0VdsNQwQinHKOTmp5RhmHnJO17m0DJGMfpPKusuApKbnfD1AZaGtG0L996Rsr
t1dNV+Ff3lUf9/Tcyy/f8o9v4LGHUcxNPdNLwzAGuD/mkPQw6BjyVctEoKqexfh0ivK3z9JW
5qdP9s21F51cLtGAUJZz1IRmf9WRyrkfAFZ347J/FraxGHhDr5rJt+Q7JIOIRIw5UNUhG1DN
/QHyyNMP1R7YaU4aA7K1uzcynCSnctwUSBxBMhlLrs5hRFtx9wYB0/lAiGxYxh4BbXstKiBx
Ij2aesjRGIOaYYrH9K29+US7WzSu0K7tJp43p25Y/w2zi1oM6nr5B5s6Fuq1/FSsNQt0vWA9
AXRFEJjFE9WNWFFgEwEAiHw47WlsKosIz0ENoTdgSPsQVWHMEHIhYogKYJyz+7fcXF1Q88to
syJMXz7xspuwLQMvh79ABuplOSzCayGuGxT/Fx99df0KjV48viLvH9cy3ygv6tzhF09snCnL
L8UMs/IZC8FWvdgIfzisBXqWVmeSvXnxVkqvC0MD2wXZVLqgBr5oCTeToC/vw9LzovqVi8K6
wKAWaFhhbrvB526+ehemtvGyysuVwFffdL2e/QimKdCiTIfpWjYqWS2umMtcShrD8QkBJi0v
V52IQjwbhF3bEUG7awAUiaNICAFVm/317ac/7a9vDPPx/jdDQfsHzVHjwAT9+fT961fGXHvb
9z1oZqYchiQByCVRaw2yOR37mNL3+4eUpR+G2B9VEyqEMCDk45gPx8MpHo/D02kYn05HNqhJ
UorjcAx9LwIZzTnI8+E0jCmnlELwu2uo9iDCqAy6rxpEdM6rqndsfGW7OwRMaQzjKfSn4+GA
qpIlZBn743g6qErddVfXt45NCEMKwRhrQWc1q8boABWBiVEUKe+abrLlZhGBjGQAgKwBUGbT
WpdFxhCtMbO7TcKcoiGsaq9s5mjwScVnKmi7lIKKIFk0PiNddy4mGGJuPEM2v367//mja7wT
GH/+obFVJ5A6GxHdLw/51+cQ/64/f2hJSCkWYwyiydahkoDmc5J/POh/vDMA1hI2MP700X57
kDetvbmpxgRuyqOekYksg0vyLeek9u7TXV37r98fdTaXYBG4AGYZDwERLCtm0Nm3VAEJmECR
FY2TwFC3kAbQjIBZBK1TQkhRRLjdsWWqa2fNJCMjGzEMkhCAXM1pD4TWGW33rBHZMNvErKAI
GUmp7eYjS9BpGI01RIzWq6np6oNWO111/H/wmWWwLbu9XE3b7YWh6OVHN4+vtWzq0yK7FX64
lCukS180OxOQieKa1r25q0Ny1hjFugIFqBzWLEPXiEDkNFCJMUEg1frte3v7CQBLQt9lKHhJ
pAqdmxF6axpZ+/gCmjaTVFj1i0GXwW4dxWDT7GUtl6BVIPgl6vz7ckvxy/7p5c1NiFJ5/BUy
Q3HMW6Fx6ViZwEvN5eVibotcjknXn+APer/Fute//SGavwCO7f1V7t+IkYt3+uQzus0y9/9w
Cps2XqD1hWlz8aiAgvHFYn4JtOXVmP1XX8H860Fh+VMAROxuP6Sn3zUFUAMixhli1Fw7RuOs
Y/bEwJQVkvPcoSEAjOPjZ7vb3XQNpquhP3vvo+TjIA2b0+HJ7W6G2EOfyPrTkI/nb86yun0A
AyopRm/59vZKsqZzxhz2rZfGqoj3ROhilCjHYziITrmHqKlrQJhSKiQQQyzkkSuHqa2bkWPK
AsSA1HinmDRm42vJuSauKq/eMkGMOR9+V0BAYzRlyaTCqE1Tcczk36bhuWs7ZjaSzqeDZql9
9U+V5A65Hm5IuQAAAABJRU5ErkJggg==
--------------D7B057AD226DDE3022D85822--

--------------8FDEB88C6D7B716E6A9A4B30--


From nobody Thu Apr 11 04:36:13 2019
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 E68A912011D for ; Thu, 11 Apr 2019 04:36:11 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pbbVRcbVGWsL for ; Thu, 11 Apr 2019 04:36:10 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 33B7E120048 for ; Thu, 11 Apr 2019 04:36:10 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id i21so4561438oib.11 for ; Thu, 11 Apr 2019 04:36: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; bh=qJF6cTbeO6lTVkXl14kMrP+PTU8HxH26ptvETL3Q6VY=; b=jz9SiX/EHux0cF1luGftdZlxfegrh2tOxKysm43aSnDTWmKiFj+SrqExsG0jy/Z5dd Z1qoDB3KQizdZXALfC5vxuET9U+Vlg2ZbYvQpi7CLMinXC7bbJszIyxGRLdHDCTkefVn lzuw4XhVOfqBOSdOD6hNXR122dnbLtPLWRKrpcA5SyPUx2A5/HhtUEXA/yx9R/P7WDX/ sxUDel4BMbOIKlqwhpBVVL1nuBpWuYSYDJvwON+onJRmVnxIDz7C6V3tHh86tgHaH/m3 5CoFRb/qNFjrj7TbCOfPlXxr/chPXj+78Zspr+bZmRT2AjLXem3PfXe2Zvfvz2vsMu0u kejg==
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=qJF6cTbeO6lTVkXl14kMrP+PTU8HxH26ptvETL3Q6VY=; b=JOOtKXRRdKoZBCPh1tpAO0Ww58clP5xHylvJNIwPYC2Y8bQxr16UFNLozU0u94tb9g oFRvFhk15dK5Zl7NwnMBTZ0honVr9GSbAuJG9Cdoce2ks+C6oWp+A71eA+TZhIt44mpE 0EUa8Cj9uOmJpPyPAUGidYCvzbaYkDft4/5vjhCW6jaNkn02mZLd0HGYAMBx1UcFHXb1 mjYbt0M5lJRNsb2oWVhsSB6WEOKG6IR7R2kvjQ8MKqg3nxtdS/2GxY7yfSdeyv5bK5oE yu28AQJh5VWMb2KmJIDR5bAsiFO/iRwlOx7stV5aS3akDhDc0gKkScdd7X3YG+5y6pxs uzNg==
X-Gm-Message-State: APjAAAV7ipIcxNuWH3JRa3AhcRtoYkkLdfl5PA2/xjNByc3+lRTJHzNP hm+6tWcubH/HnPMK60fphRPRb28m8uAMGVxLdN8N
X-Google-Smtp-Source: APXvYqzkp8Wo5TxD87FSliin/7/DGx2+NBkaxDi18bOZMa5V4hba16TMAIrW2zjPTAgwkVhE5/5/vTYZfKiYtG15BXg=
X-Received: by 2002:aca:aa91:: with SMTP id t139mr6167923oie.174.1554982569151;  Thu, 11 Apr 2019 04:36:09 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan 
Date: Thu, 11 Apr 2019 13:35:58 +0200
Message-ID: 
To: oauth , Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary="000000000000aa929005863f9786"
Archived-At: 
Subject: [OAUTH-WG] on PKCE for CSRF prevention instead of 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: Thu, 11 Apr 2019 11:36:12 -0000

--000000000000aa929005863f9786
Content-Type: text/plain; charset="UTF-8"

In Prague we've seen and talked about this point from Torsten's deck



> Use PKCE for CSRF prevention instead of state parameter
>
>    - PKCE is mandatory now and can fulfill this additional task
>    - Simplifies recommendations and makes state available again for
>    original purpose (carry client transaction data)
>
>
While PKCE is now the suggested countermeasure to some attacks and is to be
used by Clients it's not yet mandatory to be implemented by the AS and the
client has no way of knowing for sure if it's implemented (due to how PKCE
is defined as backwards compatible to clients when AS is missing its
support).

Since at no point in time does the client receive anything from the AS
suggesting that PKCE is in effect, is this a wise recommendation to make in
the current form? Some might interpret this as if they don't need state to
carry any client transaction data they might as well just use PKCE and omit
state altogether altho the server does not support PKCE.

S pozdravem,
*Filip Skokan*

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


In Prague we've seen and talked =
about this point from Torsten's deck
=C2=A0
Use PKCE for CSRF prevention instead of state parameter
    <=
li>PKCE is mandatory now and can fulfill this additional task
  • Simpl=
ifies recommendations and makes state available again for original purpose =
(carry client transaction data)

W=
hile PKCE is now the suggested countermeasure to some attacks and is to be =
used by Clients it's not yet mandatory to be implemented by the AS and =
the client has no way of knowing for sure if it's implemented (due to h=
ow PKCE is defined as backwards compatible to clients when AS is missing it=
s support).

Since at no point in time does the cli=
ent receive anything from the AS suggesting that PKCE is in effect, is this=
 a wise recommendation to make in the current form? Some might interpret th=
is as if they don't need state to carry any client transaction data the=
y might as well just use PKCE and omit state altogether altho the server do=
es not support PKCE.
=C2=A0
S pozdravem=
,
Filip Skokan


--000000000000aa929005863f9786--


From nobody Thu Apr 11 05:27:47 2019
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 391571201C7 for ; Thu, 11 Apr 2019 05:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=yes.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 CLRgTGYfXvL6 for ; Thu, 11 Apr 2019 05:27:42 -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 2652D120048 for ; Thu, 11 Apr 2019 05:27:42 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id a184so6482330wma.2 for ; Thu, 11 Apr 2019 05:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Bk6D5TxtbnEpJrPJfw0D24RGBRTKoy2xIt2z6FD3k/0=; b=tL/bMdJ1MiOzvvs9hdFwBRRzp9ITBL0CPTlhyXQB3KVRYo1dNGXjaboVvboItecT7b 2kN4hAEGOAaGjzsPVU85DNvqcGw/mddgnb0mG+iHSirNxws4QAjvhygYFUj4XTWoBveu daM3usxH/TBmTUbrRI+58FJFyoJjRnNCgCbekVrtKw6EjPlX0a5mhhtlUiUs6sF6YFMc 9BAuW3QyQKenkqiuJFdK8Lu6HA1AXs9nbPwdbsGcIJk/Q0R7IJx/L/YK+OEJwt7Nw1gr 2ZsJU+e/KY9sXnaXZZxHR81+8gO8VZAvpE6wv61dE2ptrBljROZhEwTwFwMRCfk7Ond3 OMNw==
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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Bk6D5TxtbnEpJrPJfw0D24RGBRTKoy2xIt2z6FD3k/0=; b=fSn5XNixGBL5HQ7h+Zgkk8n4zXgE7r0oZi5geeuJ7nG6C7dZuyqgAk4olh8d2CLpnu METKCJQCfqdFxnRlUWWkXxe2a5u2u6b3TkqU0P8d83AhTLXyCKGguYVlpnDYLU1GW4Uo NbaSftC71GszhzpN2d9wx/6jLI6v2RdCAsj12RD/Gqo5DCX3hCO8RNJUbc9Hf2k5p7kD k8We4w+TTQFNuSfc7sapSgQKsEJ98I0f5sscl90G3JqQnqe0NE9moHU4vf1lbaob4Ksz 77V5o4x+s+4KGhsRVm2b/1NcY7oWI9m/HAjWwI9VjNyJo0sMjdiWZLBl7jO6vQ5EGyCB LJLA==
X-Gm-Message-State: APjAAAWM59dRdm7fZc31Smw4W/upsc/MXuUtCxZ+HmBW7PRDDTmV8Oqv sG3P8L9g8dj0jPb+O9Ieguy/GCCt6Yw=
X-Google-Smtp-Source: APXvYqxMJZ+UjkND8qNPsmquF+7rarcTbSyoyLCDQwRIvO3FADpBTnmIRUtPfiDN85NXst6V8Ds/HA==
X-Received: by 2002:a1c:658a:: with SMTP id z132mr6569962wmb.92.1554985660128;  Thu, 11 Apr 2019 05:27:40 -0700 (PDT)
Received: from ?IPv6:2003:c1:4f3b:1400:5065:45ab:802c:3ea5? (p200300C14F3B1400506545AB802C3EA5.dip0.t-ipconnect.de. [2003:c1:4f3b:1400:5065:45ab:802c:3ea5]) by smtp.gmail.com with ESMTPSA id r16sm27861160wrx.37.2019.04.11.05.27.38 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 05:27:39 -0700 (PDT)
To: oauth@ietf.org
References: 
From: Daniel Fett 
Message-ID: <08ab4caa-922f-c8f3-67ed-56e10611946e@yes.com>
Date: Thu, 11 Apr 2019 14:27:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DB0849387CD93429E77957B7"
Content-Language: de-DE
Archived-At: 
Subject: Re: [OAUTH-WG] on PKCE for CSRF prevention instead of 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: Thu, 11 Apr 2019 12:27:45 -0000

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

Hi Filip,

This is an important point that you raise here. In an ideal world, the
client would be able to learn whether the AS supports PKCE or not.

My proposal for a normative text would be this:

---
If PKCE [@RFC7636] is used by the client and the authorization server
supports PKCE, clients MAY opt to not use state for protection against
Cross-Site Request Forgery, as such protection is provided by PKCE. In
this case, state MAY be used again for its original purpose, namely
transporting data about the application state of the client.

It is important to note that:

 * 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].
 * There is no defined mechanism for clients to detect whether an
authorization server supports PKCE or not. Clients that use PKCE despite
the authorization server not supporting it will not receive any
indication of the lack of support for PKCE. If the authorization server
does not support PKCE, state MUST be used for CSRF protection.
---

- Daniel


Am 11.04.19 um 13:35 schrieb Filip Skokan:
> In Prague we've seen and talked about this point from Torsten's deck
> 
>  
>
>     Use PKCE for CSRF prevention instead of state parameter
>
>       * PKCE is mandatory now and can fulfill this additional task
>       * Simplifies recommendations and makes state available again for
>         original purpose (carry client transaction data)
>
>
> While PKCE is now the suggested countermeasure to some attacks and is
> to be used by Clients it's not yet mandatory to be implemented by the
> AS and the client has no way of knowing for sure if it's implemented
> (due to how PKCE is defined as backwards compatible to clients when AS
> is missing its support).
>
> Since at no point in time does the client receive anything from the AS
> suggesting that PKCE is in effect, is this a wise recommendation to
> make in the current form? Some might interpret this as if they don't
> need state to carry any client transaction data they might as well
> just use PKCE and omit state altogether altho the server does not
> support PKCE.
>  
> S pozdravem,
> *Filip Skokan*
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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


  
    
  
  
    
Hi Filip,

    


    

    
This is an important point that you
      raise here. In an ideal world, the client would be able to learn
      whether the AS supports PKCE or not.

    

    


    

    
My proposal for a normative text would
      be this:

    


    

    
---

    

    
If PKCE [@RFC7636] is used by the
      client and the authorization server supports PKCE, clients MAY opt
      to not use state for protection against Cross-Site Request
      Forgery, as such protection is provided by PKCE. In this case,
      state MAY be used again for its original purpose, namely
      transporting data about the application state of the client.

      

      It is important to note that:

      

       * 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].

       * There is no defined mechanism for clients to detect whether an
      authorization server supports PKCE or not. Clients that use PKCE
      despite the authorization server not supporting it will not
      receive any indication of the lack of support for PKCE. If the
      authorization server does not support PKCE, state MUST be used for
      CSRF protection.

    
---

    


    

    
- Daniel

    

    


    

    


    

    
Am 11.04.19 um 13:35 schrieb Filip
      Skokan:

    

    

      
      

        

          
In Prague we've seen and talked about this point from
            Torsten's deck

          
 

          
Use PKCE for CSRF
            prevention instead of state parameter
            
    
              
  • PKCE is mandatory now and can fulfill this additional
                task
    • 
              
  • Simplifies recommendations and makes state available
                again for original purpose (carry client transaction
                data)
    • 
            

          

          


          

          
While PKCE is now the suggested countermeasure to some
            attacks and is to be used by Clients it's not yet mandatory
            to be implemented by the AS and the client has no way of
            knowing for sure if it's implemented (due to how PKCE is
            defined as backwards compatible to clients when AS is
            missing its support).

          


          

          
Since at no point in time does the client receive
            anything from the AS suggesting that PKCE is in effect, is
            this a wise recommendation to make in the current form? Some
            might interpret this as if they don't need state to carry
            any client transaction data they might as well just use PKCE
            and omit state altogether altho the server does not support
            PKCE.

          
 

          

          

            
S
              pozdravem,

              Filip Skokan

          

        

      

      

      

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


    

    


    

  


--------------DB0849387CD93429E77957B7--


From saschapreibisch@gmail.com  Wed Apr 10 10:39:41 2019
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 941871200EB for ; Wed, 10 Apr 2019 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level: 
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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 3xWf0UVevJlp for ; Wed, 10 Apr 2019 10:39:39 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-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 1BC1012027E for ; Wed, 10 Apr 2019 10:39:39 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id z17so113213itc.1 for ; Wed, 10 Apr 2019 10:39:39 -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=s9+NmX+qnQGU6WJoluDTy434l5xyWIBLg3cLKrq2RLE=; b=MI7WXQGRlzOK3ltPeAa6eZPNmHPALTFQvS6o1LbC4WLIeA59bbn1O9EXmmfO0piZmU pxeN7r4pmM0NTi17ljxMcABPwxecjwinlS5mDiVQrcIaupwt/mxX9mjIah2bRJ0Aw4IQ GpJMvqLPsW6RtFz5Xo4z3zhLgcO09mq3MzkqhiuyAKOsHu/6rZ0NZa28B3Q+PH/F3LY+ S30FBBwwtm8FwW/a16sChTWzULXvH2pEG689IPJk58kaLHvm3P1v9vH7QclYPQ31L4RP Pms/u/2q2g+7SKfn2xK5nwAMF9fgV7SqFWyK0Ta5X3P33vfZJogevz7fxj3Z1UyAELUa zphQ==
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=s9+NmX+qnQGU6WJoluDTy434l5xyWIBLg3cLKrq2RLE=; b=ra7kmXc8+I4M2ddB/sw8/UcjkvHUnMKdbL9GLskxULhZ1EMWDNAtlobMArWpFeC1ir /Kc291kWSqAzkiEytOMap9vjoaHGQMLq0KIuaEKdGblfSBIEJSkNTuLDPn2Lvk8fYduU Wob5Bs3BIBCTDDUNAn9kCoYp/9ig0a16EYOfMjK9cpN3mgxgp/SJ6dc85JLlfiemcbgW pSqnshu++HFwDsV0wlC3/YHG3VO48D/JSV3XkfVlE3cYXLjcW1Faw1NcTtB5dD72K9n8 hYXlEtwBfeaNFl4v/gtW34ryCajW0ynJLm81/jGd5ssVCuAVMY5ym0ynb0qWsjfmF8zG ruuQ==
X-Gm-Message-State: APjAAAVZjs6CnGphwPWt5nV3AjCG1mha3M7zUYwo6fdxqvb6IMLIukwr yP+hU+3zKUGypYEPdqdBA8jin6BWotASaftek+CuPw==
X-Google-Smtp-Source: APXvYqzHWcu+9McyiSLVjZO6JGq7aBg9s5n8KziCKx+vbYmiLKY6mOpxnRQVCZkInrtcxxzdwQoC793Uq+8SJuQE5MY=
X-Received: by 2002:a05:660c:490:: with SMTP id a16mr4122641itk.76.1554917977882;  Wed, 10 Apr 2019 10:39:37 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Sascha Preibisch 
Date: Wed, 10 Apr 2019 10:39:25 -0700
Message-ID: 
To: oauth@ietf.org, n-sakimura@nri.co.jp
Cc: Anthony Nadalin ,  Hannes Tschofenig 
Content-Type: multipart/alternative; boundary="000000000000ba05120586308df1"
Archived-At: 
X-Mailman-Approved-At: Thu, 11 Apr 2019 10:55:49 -0700
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2019 17:51:19 -0000

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

I am late in the game, but not too late I hope.

I would like to see 'aud' be the requesting client_id. For identifying the
the target resource, a 'resource' claim should be introduced. I am also
suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
validation process will show if it is an access_token or not.

Last but not least, 'aud' (as resource identifier) should not be required.
Requiring that, and the requested resource in the the token request, will
require existing clients to be updated. Introducing jwt access_token should
be transparent to clients.

Thanks,
Sascha


On Wed., Apr. 10, 2019, 06:41 n-sakimura,  wrote:

> +1
>
> For that matter, explicit typing is good and I am a bit ambivalent on the
> use of `sub`.
>
> Also, I need to add the 4th consideration: Although the current privacy
> consideration is stating about the encryption, it is in relation to the e=
nd
> user exposure. In fact, the by-value access token when involving some PII
> is by definition leaking information and violating the data minimization
> principle. This should be clearly delineated. My gut feeling is that it
> should be encrypted unless it is certain that it does not include sensiti=
ve
> PII as judging whether a claim may form a PII is too hard for an average
> developer.
>
> -----Original Message-----
> From: OAuth  On Behalf Of Anthony Nadalin
> Sent: Wednesday, April 10, 2019 8:12 PM
> To: Hannes Tschofenig ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
>
> I support adoption of this draft as a working group document with the
> following caveats:
>
> 1. These are not to be used as ID Tokens/authentication tokens 2. The
> privacy issues must be addressed 3. Needs to be extensible, much like
> ID-Token, can't be 100% fixed
>
>
> -----Original Message-----
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, April 8, 2019 10:07 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
>
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prag=
ue.
>
> Here is the document:
>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7=
C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf=
86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2F=
HCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth worki=
ng
> group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microso=
ft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db4=
7%7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCoo=
DtlIUH7tS%2Fw%3D&reserved=3D0
>
> _______________________________________________
> 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
>

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


I am late in the game, but not too late I hope.

I would like to see 'aud' =
be the requesting client_id. For identifying the the target resource, a =
9;resource' claim should be introduced. I am also suggesting to not int=
roduce 'typ: at+jwt'. It is simply a jwt and the validation process=
 will show if it is an access_token or not.

Last but not least, 'aud' (as resource identifi=
er) should not be required. Requiring that, and the requested resource in t=
he the token request, will require existing clients to be updated. Introduc=
ing jwt access_token should be transparent to clients.

Thanks,
Sascha
<=
br>
On =
Wed., Apr. 10, 2019, 06:41 n-sakimura, <n-sakimura@nri.co.jp> w=
rote:
+1 



For that matter, explicit typing is good and I am a bit ambivalent on the u=
se of `sub`. 



Also, I need to add the 4th consideration: Although the current privacy con=
sideration is stating about the encryption, it is in relation to the end us=
er exposure. In fact, the by-value access token when involving some PII is =
by definition leaking information and violating the data minimization princ=
iple. This should be clearly delineated. My gut feeling is that it should b=
e encrypted unless it is certain that it does not include sensitive PII as =
judging whether a claim may form a PII is too hard for an average developer=
. 



-----Original Message-----

From: OAuth <oauth-bounces@ietf.org> On Behalf Of =
Anthony Nadalin

Sent: Wednesday, April 10, 2019 8:12 PM

To: Hannes Tschofenig <Hannes.Tschofenig@arm.com&=
gt;; oauth@ietf.org

Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Token=
s



I support adoption of this draft as a working group document with the follo=
wing caveats:



1. These are not to be used as ID Tokens/authentication tokens 2. The priva=
cy issues must be addressed 3. Needs to be extensible, much like ID-Token, =
can't be 100% fixed 





-----Original Message-----

From: OAuth <oauth-bounces@ietf.org> On Behalf Of =
Hannes Tschofenig

Sent: Monday, April 8, 2019 10:07 AM

To: oauth@ietf.org

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


Hi all,



this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens=
'=C2=A0 document following the positive feedback at the last IETF meeti=
ng in Prague.



Here is the document:

https://=
nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%=
2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&amp;data=3D02%7C01%7C=
tonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141=
af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=3DePmwaD%2FHC=
RZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=3D0



Please let us know by April 22nd whether you accept / object to the adoptio=
n of this document as a starting point for work in the OAuth working group.=




Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are 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.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://nam06.safelinks.protection.=
outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&=
amp;amp;data=3D02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6=
bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&am=
p;amp;sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;rese=
rved=3D0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listin=
fo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listin=
fo/oauth




--000000000000ba05120586308df1--


From nobody Thu Apr 11 13:21:20 2019
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 DEB6B12031C; Thu, 11 Apr 2019 13:21:12 -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.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <155501407282.13752.2789851176225236692@ietfa.amsl.com>
Date: Thu, 11 Apr 2019 13:21:12 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-14.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: Thu, 11 Apr 2019 20:21:13 -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 Mutual TLS Client Authentication and Certificate-Bound Access Tokens
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
	Filename        : draft-ietf-oauth-mtls-14.txt
	Pages           : 30
	Date            : 2019-04-11

Abstract:
   This document describes OAuth client authentication and certificate-
   bound access and refresh tokens using mutual Transport Layer Security
   (TLS) authentication with X.509 certificates.  OAuth clients are
   provided a mechanism for authentication to the authorization server
   using mutual TLS, based on either self-signed certificates or public
   key infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-14
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Apr 11 13:32:28 2019
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 7089D120435 for ; Thu, 11 Apr 2019 13:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 mTg3UsoSj1YG for ; Thu, 11 Apr 2019 13:32:24 -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 4129612041E for ; Thu, 11 Apr 2019 13:32:24 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id v4so6561768ioj.5 for ; Thu, 11 Apr 2019 13:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZkniZzsdyZF9v9F0Sxx8HE8LyxF6fShp1apf88rXE+k=; b=khoLuX2tuDRlDNDbyzcDk+Ygz3wlQAG4W6Ex5dQAuUpuJGWgkkRQHMaNvIM2a9Tk6J Ysk3FBdmAS/9eTYrbY2yzDOYL7EXxchQJX7UkqvBhPNTHGzjv2z+Ig1u4iuuChYW2630 FMqkVK5p9PJpL2xVdaIAW3jjnr5AgNvR1O0YQ=
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=ZkniZzsdyZF9v9F0Sxx8HE8LyxF6fShp1apf88rXE+k=; b=ev8yIgpz0xEgyYW2XsVdVntw54+Nauq0DDI2kyyt3llOZ898siBxh0I/Ck8M5zbOyD uCIQOXMOdvp5z8WQ8UnAt5iIWA50AB21WMJtNF8cPTZipN0ddVkALcze+3TYkSwCbhGs 1lllyDxUdksoB6KlKacKvQDljSCiwbIcm8igpuSiIY57NHCrsEvmXvJ4mwOQVtm9H/EI lNhLz7hq94fyW7aKNYRQ2xZKjsVY1T30jmqH8D6kDUtkRxxcxaUHgzNyAZO5E1I5xU2S s07H5fUzJiFHNZo28HJVpfCeeWODLHh+NQDXEqm19RjjXAM7o4+bU+5FgC015AmyfmuW N7wg==
X-Gm-Message-State: APjAAAX4QLHTfDI7CGzVBjAslnaVgIcdN+VtUTEHrSwPHGAB6i03ux6Y VAjFFrbl3LiKVZ2PpDchcN/KL6Si3rThyY6qzXDOfpEeHxBwNsrSFhna8DI0sD+YiUKBdQlr33x fdDt5FsJi+udAT0rM7TbAVg==
X-Google-Smtp-Source: APXvYqwWtaPpxmuJe+VCKs/HVj7HyPyvhYaS3eLTNPb0VvdD2X4ZcK6+hbapALhNSOwmE6hWmXnx/yw17S0H+0t7MwM=
X-Received: by 2002:a6b:3b46:: with SMTP id i67mr32238114ioa.67.1555014743027;  Thu, 11 Apr 2019 13:32:23 -0700 (PDT)
MIME-Version: 1.0
References: <155501407282.13752.2789851176225236692@ietfa.amsl.com>
In-Reply-To: <155501407282.13752.2789851176225236692@ietfa.amsl.com>
From: Brian Campbell 
Date: Thu, 11 Apr 2019 14:31:56 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000610c4d05864715fd"
Archived-At: 
Subject: [OAUTH-WG] draft-ietf-oauth-mtls-14
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, 11 Apr 2019 20:32:27 -0000

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

Draft -14 of "OAuth 2.0 Mutual TLS Client Authentication and
Certificate-Bound Access Tokens" has been published. The changes in -14
(listed below) are editorial only and aim to provide some additional
clarity around some recent small points of confusion and discussion.

draft-ietf-oauth-mtls-14
   o  Editorial clarifications around there being only a single subject
      registered/configured per client for the tls_client_auth method.
   o  Add a brief explanation about how, with tls_client_auth and
      self_signed_tls_client_auth, refresh tokens are certificate-bound
      indirectly via the client authentication.
   o  Add mention of refresh tokens in the abstract.

---------- Forwarded message ---------
From: 
Date: Thu, Apr 11, 2019 at 2:21 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-14.txt
To: 
Cc: 



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 Mutual TLS Client Authentication and
Certificate-Bound Access Tokens
        Authors         : Brian Campbell
                          John Bradley
                          Nat Sakimura
                          Torsten Lodderstedt
        Filename        : draft-ietf-oauth-mtls-14.txt
        Pages           : 30
        Date            : 2019-04-11

Abstract:
   This document describes OAuth client authentication and certificate-
   bound access and refresh tokens using mutual Transport Layer Security
   (TLS) authentication with X.509 certificates.  OAuth clients are
   provided a mechanism for authentication to the authorization server
   using mutual TLS, based on either self-signed certificates or public
   key infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-14
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-14


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

--=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._

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


Draft -14 of "OAuth 2.0 Mutual TLS Client=20
Authentication and Certificate-Bound Access Tokens" has been published=
.=20
The changes in -14 (listed below) are editorial only and aim to provide som=
e additional clarity around some recent small points of confusion and discu=
ssion. 

draft-ietf-oauth-mtls-14
=C2=A0=C2=
=A0 o=C2=A0 Editorial clarifications around there being only a single subje=
ct
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 registered/configured per client for t=
he tls_client_auth method.
=C2=A0=C2=A0 o=C2=A0 Add a brief explanation =
about how, with tls_client_auth and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 self_=
signed_tls_client_auth, refresh tokens are certificate-bound
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 indirectly via the client authentication.
=C2=A0=
=C2=A0 o=C2=A0 Add mention of refresh tokens in the abstract.

=

----------=
 Forwarded message ---------
From: <internet-drafts@ietf.org>
Dat=
e: Thu, Apr 11, 2019 at 2:21 PM
Subject: [OAUTH-WG] I-D Action: draft-ie=
tf-oauth-mtls-14.txt
To:  <i=
-d-announce@ietf.org>
Cc:  <=
oauth@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol WG of the IETF.=




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access To=
kens

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria=
n Campbell

=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 John Bradley

=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 Nat Sakimura

=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 Torsten Lodderstedt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-mtls-14.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 30

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2019-04-11



Abstract:

=C2=A0 =C2=A0This document describes OAuth client authentication and certif=
icate-

=C2=A0 =C2=A0bound access and refresh tokens using mutual Transport Layer S=
ecurity

=C2=A0 =C2=A0(TLS) authentication with X.509 certificates.=C2=A0 OAuth clie=
nts are

=C2=A0 =C2=A0provided a mechanism for authentication to the authorization s=
erver

=C2=A0 =C2=A0using mutual TLS, based on either self-signed certificates or =
public

=C2=A0 =C2=A0key infrastructure (PKI).=C2=A0 OAuth authorization servers ar=
e provided a

=C2=A0 =C2=A0mechanism for binding access tokens to a client's mutual T=
LS

=C2=A0 =C2=A0certificate, and OAuth protected resources are provided a meth=
od for

=C2=A0 =C2=A0ensuring that such an access token presented to it was issued =
to the

=C2=A0 =C2=A0client presenting the token.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-o=
auth-mtls/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-oauth-mtl=
s-14

https://datatracker.ietf.org/doc/html/=
draft-ietf-oauth-mtls-14



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraf=
t-ietf-oauth-mtls-14





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.
--000000000000610c4d05864715fd--


From nobody Fri Apr 12 04:34:35 2019
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 2918312049A for ; Fri, 12 Apr 2019 04:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7d0WCQ9cP3g for ; Fri, 12 Apr 2019 04:34:24 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 E4FF81204B4 for ; Fri, 12 Apr 2019 04:34:23 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id j10so8103449otq.0 for ; Fri, 12 Apr 2019 04:34:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r85+u9zzJ355RnZ90UoTv896O3Kd8y6JRm4Rf7p7pmA=; b=dxE3ZRsKz2XAOBMA+9TIx6g4cj8So3985v0egVEi+Z9ulEwrqF/oV8T7TBO5ArQLl8 NflRmhF/S/BpTge4LsvjXTDwqppHj9PP5A+FBt+ktmNM3GYAR3Yzrj/daYFhgj2Fw3y0 WBc2Qd8n9w36uYh1n4bVImNf00AVB+jo9/Es6AKupfTmQlac0uQ31d3QoIrIcw6whSPL r6ji2R77VQFoWXWA2PmFR2YWDhUTbtXRkwbvUqOy+71Zvr3VRowyFxF2uqbhBhe/T3tr 3O5w/oeTqvuwMp07MRbOlQygeOL/JTFZ1TL/0C09dtIcgBXGMiH4VvcuEzQ5lyC5GPlE 8uXQ==
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=r85+u9zzJ355RnZ90UoTv896O3Kd8y6JRm4Rf7p7pmA=; b=AUtyZzo+BFLYtYmDvG9Prec+U6Xy87PicSpe44Gb734ObFTLLI9FmdX1mDRbz8GerH iTAVZ5EMz67pHopspzy2o6LVlVSw32XFdCWH1KFlytSvWjJ78HROfGkEBm5JTuoF6GFW WRrpT32KrbpOMzaHDCRvMEPp8vOLDgFH2WwT05CA13BvCNnLvLAm+QyWrEtNb+sTWfB9 DCJxlWeWNn086hhg/OvMYRRBc9hPx7h2Ww4eNVP8sTL2uflzG35Ae4GnwHxYG7DT4cLL RGUdpIdAemLgqRxxwJP1ZctQZkOpJdvB9OUAHtEegG+mqAYMXH4/z6jpBjjqRDW2SkJ0 gTdA==
X-Gm-Message-State: APjAAAWoVIfYiNrmsy5GaGpRgznlc7w1jPUjiV+dnZUjWsqugcZYOK7N /fiBkaEF5H1+iyQDuefwGkYwiwcQMrAnhVctkeTlww==
X-Google-Smtp-Source: APXvYqyOh8d5R47jxGca351m8FYiLm3nS3XscCnbUS7F3kS+2qIbfc5S+GkEB8Y7m2TDtMHT4MWvCT6P7APVyTGYw+E=
X-Received: by 2002:a05:6830:144c:: with SMTP id w12mr24326252otp.192.1555068862852;  Fri, 12 Apr 2019 04:34:22 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: =?UTF-8?Q?Dag_Helge_=C3=98sterhagen?= 
Date: Fri, 12 Apr 2019 13:34:12 +0200
Message-ID: 
To: Sascha Preibisch 
Cc: oauth@ietf.org, n-sakimura@nri.co.jp,  Anthony Nadalin 
Content-Type: multipart/alternative; boundary="0000000000002c0777058653af33"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2019 11:34:33 -0000

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

I agree on "I am also suggesting to not introduce 'typ: at+jwt'".

Both regarding practical considerations and RFC7519 (5.1):

"This is intended for use by the JWT application
when values that are not JWTs could also be present in an application
data structure that can contain a JWT object; the application can use
this value to disambiguate among the different kinds of objects that
might be present.  It will typically not be used by applications when

it is already known that the object is a JWT"

Introducing the "+"-pattern for typ will probably lead to unintended usage
in the future.

/dag






tor. 11. apr. 2019 kl. 19:56 skrev Sascha Preibisch <
saschapreibisch@gmail.com>:

> I am late in the game, but not too late I hope.
>
> I would like to see 'aud' be the requesting client_id. For identifying th=
e
> the target resource, a 'resource' claim should be introduced. I am also
> suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
> validation process will show if it is an access_token or not.
>
> Last but not least, 'aud' (as resource identifier) should not be required=
.
> Requiring that, and the requested resource in the the token request, will
> require existing clients to be updated. Introducing jwt access_token shou=
ld
> be transparent to clients.
>
> Thanks,
> Sascha
>
>
> On Wed., Apr. 10, 2019, 06:41 n-sakimura,  > wrote:
>
>> +1
>>
>> For that matter, explicit typing is good and I am a bit ambivalent on th=
e
>> use of `sub`.
>>
>> Also, I need to add the 4th consideration: Although the current privacy
>> consideration is stating about the encryption, it is in relation to the =
end
>> user exposure. In fact, the by-value access token when involving some PI=
I
>> is by definition leaking information and violating the data minimization
>> principle. This should be clearly delineated. My gut feeling is that it
>> should be encrypted unless it is certain that it does not include sensit=
ive
>> PII as judging whether a claim may form a PII is too hard for an average
>> developer..
>>
>> -----Original Message-----
>> From: OAuth  On Behalf Of Anthony Nadalin
>> Sent: Wednesday, April 10, 2019 8:12 PM
>> To: Hannes Tschofenig ; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
>> Tokens
>>
>> I support adoption of this draft as a working group document with the
>> following caveats:
>>
>> 1. These are not to be used as ID Tokens/authentication tokens 2. The
>> privacy issues must be addressed 3. Needs to be extensible, much like
>> ID-Token, can't be 100% fixed
>>
>>
>> -----Original Message-----
>> From: OAuth  On Behalf Of Hannes Tschofenig
>> Sent: Monday, April 8, 2019 10:07 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
>>
>> Hi all,
>>
>> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
>> document following the positive feedback at the last IETF meeting in Pra=
gue.
>>
>> Here is the document:
>>
>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftool=
s.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%=
7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988b=
f86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2=
FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0
>>
>> Please let us know by April 22nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth work=
ing
>> group.
>>
>> Ciao
>> Hannes & Rifaat
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy t=
he
>> information in any medium. Thank you.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>>
>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.=
ietf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40micros=
oft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db=
47%7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCo=
oDtlIUH7tS%2Fw%3D&reserved=3D0
>>
>> _______________________________________________
>> 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
>

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


I agree on "I am =
also suggesting to not introduce 'typ: at+jwt'".
Both regarding practical considerations and RFC7519 (5.1):

"This is intended for use by the JWT app=
lication
when values that are not JWTs could also be present in an application
data structure that can contain a JWT object; the application can use
this value to disambiguate among the different kinds of objects that
might be present.  It will typically not be used by applications when=C2=A0=

it is already known that the object is a JW=
T"=C2=A0

Introducing the "+"-pattern for typ=C2=A0will probably lead to unintende=
d usage in the future.
=


/dag=C2=A0


=





tor. 11. apr. 2019 kl. 1=
9:56 skrev Sascha Preibisch <saschapreibisch@gmail.com>:
I am late in the game, but not =
too late I hope.

I would like =
to see 'aud' be the requesting client_id. For identifying the the t=
arget resource, a 'resource' claim should be introduced. I am also =
suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and t=
he validation process will show if it is an access_token or not.

Last but not least, 'aud' =
(as resource identifier) should not be required. Requiring that, and the re=
quested resource in the the token request, will require existing clients to=
 be updated. Introducing jwt access_token should be transparent to clients.=


Thanks,
Sascha


On Wed., Apr. 10, 2019, 06:41 n-sakimura, <n-sa=
kimura@nri.co.jp> wrote:
+1 



For that matter, explicit typing is good and I am a bit ambivalent on the u=
se of `sub`. 



Also, I need to add the 4th consideration: Although the current privacy con=
sideration is stating about the encryption, it is in relation to the end us=
er exposure. In fact, the by-value access token when involving some PII is =
by definition leaking information and violating the data minimization princ=
iple. This should be clearly delineated. My gut feeling is that it should b=
e encrypted unless it is certain that it does not include sensitive PII as =
judging whether a claim may form a PII is too hard for an average developer=
.. 



-----Original Message-----

From: OAuth <oauth-bounces@ietf.org> On Behalf Of =
Anthony Nadalin

Sent: Wednesday, April 10, 2019 8:12 PM

To: Hannes Tschofenig <Hannes.Tschofenig@arm.com&=
gt;; oauth@ietf.org

Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Token=
s



I support adoption of this draft as a working group document with the follo=
wing caveats:



1. These are not to be used as ID Tokens/authentication tokens 2. The priva=
cy issues must be addressed 3. Needs to be extensible, much like ID-Token, =
can't be 100% fixed 





-----Original Message-----

From: OAuth <oauth-bounces@ietf.org> On Behalf Of =
Hannes Tschofenig

Sent: Monday, April 8, 2019 10:07 AM

To: oauth@ietf.org

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


Hi all,



this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens=
'=C2=A0 document following the positive feedback at the last IETF meeti=
ng in Prague.



Here is the document:

https://=
nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%=
2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&amp;data=3D02%7C01%7C=
tonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141=
af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=3DePmwaD%2FHC=
RZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=3D0



Please let us know by April 22nd whether you accept / object to the adoptio=
n of this document as a starting point for work in the OAuth working group.=




Ciao

Hannes & Rifaat



IMPORTANT NOTICE: The contents of this email and any attachments are 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.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://nam06.safelinks.protection.=
outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&=
amp;amp;data=3D02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6=
bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&am=
p;amp;sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;rese=
rved=3D0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listin=
fo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listin=
fo/oauth



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000002c0777058653af33--


From nobody Fri Apr 12 11:31:53 2019
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 1548E120136 for ; Fri, 12 Apr 2019 11:31:51 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 43rABVMuBjPL for ; Fri, 12 Apr 2019 11:31:49 -0700 (PDT)
Received: from mail-it1-x133.google.com (mail-it1-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 A35701203D3 for ; Fri, 12 Apr 2019 11:31:48 -0700 (PDT)
Received: by mail-it1-x133.google.com with SMTP id y134so17392166itc.5 for ; Fri, 12 Apr 2019 11:31:48 -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=goY797bNh+PtyjCdeYLVESMhjxIfzlgDPKVLX4xFmZ4=; b=gaStvCHldhwUfIaKwxx6WxiD19Wirza04Wx/Nh9reM3hq59uqWpcrWLt2Ph7L1auRn xwu8b6N8ofpTwYI5SSeYkdeVzELsgdLBz2ACMX96QOxiQpMeimgmdoCFWiv5R+59squX 9XIbIP3P+whizfp0miq4sVtfCtqic/FFijlBovN0Kwdk7Dr/Twkvq7RvyLx7F0s3PfI0 IPvewD/8xrGOHEmqGlIYEW503DtqiYpQFsT9C1luBge0urnbcOKMBVw9FfQ+RGHhzAZE EFaySOtBMOtOUbEGq9Q+WKCdeHnnVR/kyNm17q/Mbts53xopbnyVhX1xOix+zAyo+7fo lcZw==
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=goY797bNh+PtyjCdeYLVESMhjxIfzlgDPKVLX4xFmZ4=; b=ogvJwJAvMT62isOf3gKeTpG96gtWf4biVSybkQBVbBRp+T0LBv1zb++fFQgDW+Ef8H EFflXCZ39Ye+c0gG2EAXSI3QNujv0ipUQ9WsHu2qL+orCvIrO8sxcKZz92rGUP2IP2qE 9UHpf81WzRo5ub9ZjESPILImkI5KcWAcQyyO8aLesVs/mBmFxi1Q726oTzLpqs7mycll vBx1zY7VaCeG4n1m2x5+ed5f6cRYDNX+orfT0bxwtXkMjhV8bwsw4jSS10Ehvf3Dtil+ HgJYSqGtyDjWKe+iRRXN/vGEU0W1n3+s68Q4Fd9ig18oMxyJkno+X1oIDoMncyG2fdk4 KO9A==
X-Gm-Message-State: APjAAAVSIbOxadiS9FML1xapPnzdx/ReSohL4r/Rmnx7s8qee4wkHoxm OHyZd0R6Onx8mL73fre4rIYbxC07GIDzvxD39RwEz6l3WX0=
X-Google-Smtp-Source: APXvYqxJTaXftyTzdUUNJkqrH4p6coBFy+U17b4XzmgvYxN0l0EWdmVI1a9CHriO96MPXe2Q39JrJp3PDwnms9rIE8k=
X-Received: by 2002:a24:e501:: with SMTP id g1mr13339462iti.22.1555093907820;  Fri, 12 Apr 2019 11:31:47 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Fri, 12 Apr 2019 14:31:37 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000f7e1a40586598308"
Archived-At: 
Subject: [OAUTH-WG] IETF104 OAuth WG 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: Fri, 12 Apr 2019 18:31:51 -0000

--000000000000f7e1a40586598308
Content-Type: text/plain; charset="UTF-8"

All,


Thanks to Tony Nadalin for taking the minutes for the OAuth sessions:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-oauth-00

Please, take a look and let us know if you have any comments.

Regards,
 Rifaat & Hannes

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


All,


Th=
anks to Tony Nadalin for taking the minutes for the OAuth sessions:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-=
oauth-00

Please, take a look and let us kn=
ow if you have any comments.

Regards,
=
=C2=A0Rifaat & Hannes



--000000000000f7e1a40586598308--


From nobody Sat Apr 13 09:29:41 2019
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 9EA731207D6 for ; Sat, 13 Apr 2019 09:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 lp2PFuj51GRP for ; Sat, 13 Apr 2019 09:29:35 -0700 (PDT)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 4BA5F1207D4 for ; Sat, 13 Apr 2019 09:29:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FgAACbDbJc/xoBYJlmGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYFiBSpochIoCox/jBYlfog7jyOBZwsFGAsMhD4ChXcjOBM?= =?us-ascii?q?BAwEBCgEBAQECAgJpHAyCeDEcPgEBAQEBAVACRCwBAQEDAQEBG1ECAgcFBwQ?= =?us-ascii?q?CAQgRBAEBAS4hBgsdCAEBBA4FDoMUAYFpAw0OAQ+tGIVHgjYNghEKBoEygUy?= =?us-ascii?q?IX4ECHYFYPiZrJwwTghc1PoIaRwEBgS4BEgEmJQyDA4ImA4pUKodOhnWMOzY?= =?us-ascii?q?DBAICgSpbgnmCFIh6R4NJGoIIKoVxgzuJFZNYjFGBZiINWHFxRQoFJQFVHYE?= =?us-ascii?q?mKYMuAQKHXIU/PwEBMQGOIQ0XB4EEgSEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2FgAACbDbJc/xoBYJlmGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?YFiBSpochIoCox/jBYlfog7jyOBZwsFGAsMhD4ChXcjOBMBAwEBCgEBAQECA?= =?us-ascii?q?gJpHAyCeDEcPgEBAQEBAVACRCwBAQEDAQEBG1ECAgcFBwQCAQgRBAEBAS4hB?= =?us-ascii?q?gsdCAEBBA4FDoMUAYFpAw0OAQ+tGIVHgjYNghEKBoEygUyIX4ECHYFYPiZrJ?= =?us-ascii?q?wwTghc1PoIaRwEBgS4BEgEmJQyDA4ImA4pUKodOhnWMOzYDBAICgSpbgnmCF?= =?us-ascii?q?Ih6R4NJGoIIKoVxgzuJFZNYjFGBZiINWHFxRQoFJQFVHYEmKYMuAQKHXIU/P?= =?us-ascii?q?wEBMQGOIQ0XB4EEgSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,345,1549926000";  d="asc'?scan'208";a="10341973"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2019 18:29:29 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAABMDbJcfRBhWMBmGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYFiBYESgQQoCox/jBYlfog7jyOBZwsFGAuESgKGGTgTAQM?= =?us-ascii?q?BAQoBAgECFAEBFjojDIVKAQEBAwEBARtRAgIHBQcEAgEIEQQBAQEuIQYLHQg?= =?us-ascii?q?BAQQOBQ6DFAGBaQMNDw+tF4VHgjYNghEKBoEygUyIX4ECgXU+JmsnDBOCFzU?= =?us-ascii?q?+ghpHAQGBLgESASYlDIMDgiYDilQqh06GdYw7NgMEAgKBKluCeYIUiHpHg0k?= =?us-ascii?q?agggqhXGDO4kVk1iMUYFmIA5YcXFFCgUlAVUdgSYpgy4BAodchT8/AQIwAY4?= =?us-ascii?q?hDRcHgQSBIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,345,1549926000";  d="asc'?scan'208";a="40623957"
Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/AES256-SHA; 13 Apr 2019 18:29:28 +0200
Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP11EXC.ads.fraunhofer.de ([10.80.232.42]) with mapi id 14.03.0435.000; Sat, 13 Apr 2019 18:29:28 +0200
From: "Schanzenbach, Martin" 
To: Sascha Preibisch 
CC: IETF oauth WG 
Thread-Topic: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaABYNsSgAAUTZqAABFDkgACUbkKA
Date: Sat, 13 Apr 2019 16:29:27 +0000
Message-ID: <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.233.50]
x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24546.004
x-tm-as-result: No--39.349500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/signed; boundary="Apple-Mail=_0536A2FC-CA74-486A-92AD-AE40574FF9E2"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Apr 2019 16:29:39 -0000

--Apple-Mail=_0536A2FC-CA74-486A-92AD-AE40574FF9E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 10. Apr 2019, at 19:39, Sascha Preibisch =
 wrote:
>=20
> I am late in the game, but not too late I hope.
>=20
> I would like to see 'aud' be the requesting client_id. For identifying =
the the target resource, a 'resource' claim should be introduced. I am =
also suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and =
the validation process will show if it is an access_token or not.

"aud =3D client_id" would mean that, by definition, the JWT must not be =
presented to any other entity than the client. This makes only sense for =
the ID Token in OIDC I think.  OTOH, defining a JWT which can be =
presented by the client to the RS is the whole point of this draft.
Also, the reason why it makes sense to introduce a new type is that an =
OIDC ID Token _could_ be mistaken for an AT (which it isn't).
IMO it might even make sense to encourage the OIDC spec to change to =
jwt+id or something by extending the JWT spec.

I also support the adoption.

>=20
> Last but not least, 'aud' (as resource identifier) should not be =
required. Requiring that, and the requested resource in the the token =
request, will require existing clients to be updated. Introducing jwt =
access_token should be transparent to clients.
>=20
> Thanks,
> Sascha
>=20
>=20
> On Wed., Apr. 10, 2019, 06:41 n-sakimura,  =
wrote:
> +1
>=20
> For that matter, explicit typing is good and I am a bit ambivalent on =
the use of `sub`.
>=20
> Also, I need to add the 4th consideration: Although the current =
privacy consideration is stating about the encryption, it is in relation =
to the end user exposure. In fact, the by-value access token when =
involving some PII is by definition leaking information and violating =
the data minimization principle. This should be clearly delineated. My =
gut feeling is that it should be encrypted unless it is certain that it =
does not include sensitive PII as judging whether a claim may form a PII =
is too hard for an average developer..
>=20
> -----Original Message-----
> From: OAuth  On Behalf Of Anthony Nadalin
> Sent: Wednesday, April 10, 2019 8:12 PM
> To: Hannes Tschofenig ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access =
Tokens
>=20
> I support adoption of this draft as a working group document with the =
following caveats:
>=20
> 1. These are not to be used as ID Tokens/authentication tokens 2. The =
privacy issues must be addressed 3. Needs to be extensible, much like =
ID-Token, can't be 100% fixed
>=20
>=20
> -----Original Message-----
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, April 8, 2019 10:07 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access =
Tokens
>=20
> Hi all,
>=20
> this is the call for adoption of the 'JWT Usage in OAuth2 Access =
Tokens'  document following the positive feedback at the last IETF =
meeting in Prague.
>=20
> Here is the document:
> =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.=
ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7=
C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988b=
f86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%=
2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0
>=20
> Please let us know by April 22nd whether you accept / object to the =
adoption of this document as a starting point for work in the OAuth =
working group.
>=20
> Ciao
> Hannes & Rifaat
>=20
> IMPORTANT NOTICE: The contents of this email and any attachments are =
confidential and may also be privileged. If you are not the intended =
recipient, please notify the sender immediately and do not disclose the =
contents to any other person, use it for any purpose, or store or copy =
the information in any medium. Thank you.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> =
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microso=
ft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db=
47%7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUC=
ooDtlIUH7tS%2Fw%3D&reserved=3D0
>=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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Martin Schanzenbach
Fraunhofer AISEC
Department Service & Application Security
Parkring 4, 85748 Garching near Munich (Germany)
Tel: +49 89 3229986-193
martin.schanzenbach@aisec.fraunhofer.de
GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0


--Apple-Mail=_0536A2FC-CA74-486A-92AD-AE40574FF9E2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlyyDmcACgkQhDNRMeo9
q/C74BAAtZi/EAjGfpXO+YvBhn1x9kZWu7+EWjwC4oD+NwCrmEl6W6WEtQNQFbKR
Na+fyAiIaSTW1mv/BL4oaaIrXo4Hq7wcYjkkNNpL0V6ENxFE+Ph0yCj6sNE7LxwC
3n5+huaft3xErkKQ6t0BabDbum+4Z/VSdFOJu93f2UqKwJh81R38v0u7Lje9HLI+
GdsOts87RT39OnltkXG0RgZYr+hKCpryoXv56Dvz972qA/L3vqyvor8jmhKH0xNo
eTA38PUu4vm562xknULlOqvXCTyRqN4xjUt7Uz5bd6kcksBMx546BpqufqKxKN8Y
xTB9l7hdQ8zoe9BOGMs21MibUBOrQLuMlwklvMzObgqOIUUv8VJX/I2IMk7SDvC3
OmIPFYCQWZXQUuxOLMebhjE0EEpCsih0+vcSBmDiQ3+H5dn6smayKTt5pFckXXL0
66Ci9EBod9MyxA3EkiVK05QMNeCSVFdOblHpO1TlNJ0a3cPsZwJpMz/AjF31MqTd
walL0a6AF4GVSTbWuJdsnU4MHhEjnvqx6SLvqX+zzKXXvFQ4ah20xUUTxw0V2Mz9
6OS4eYl9DgPnH2+Lz49Hztw7+KidUL6dJLorro+8nb+8GZ4k3jja1oNj+8zN30KP
lQwwPu7IucR+CYyMdAOhEenXuqfSSwsdlST5Go8/RvY/LSIv908=
=8UaR
-----END PGP SIGNATURE-----

--Apple-Mail=_0536A2FC-CA74-486A-92AD-AE40574FF9E2--


From nobody Sat Apr 13 14:05:22 2019
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 99E61120311; Sat, 13 Apr 2019 14:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxqzCnyB6nIa; Sat, 13 Apr 2019 14:05:11 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 5C897120043; Sat, 13 Apr 2019 14:05:08 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id q16so15412232wmj.3; Sat, 13 Apr 2019 14:05:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BQWtcDtOwkUWPssxJJd3zjpPsn+G/xDjo5VQjhtkWwI=; b=ZxZie4z7V482XnFry/iSY4CeYUrd8/NbKrTjdtbhmF56c4CiM+XbxcPd9IUnNj9u3t x/KwTBI8Go0muGugbeBCB5lmLhVr1IHyT3aU057/TNvPTKFGmtrGnJ+EHcU68Y5/IWoh B1nA8fYLNhsn0KK9JG9f7xZPeWK+lIpXMkrAh64ZMMqXxRvq3X8DdcIsEs2b8TjJazvH H6c95pUQim1KTnoNOY1TcKhMbatEBJGxsWGAeYRVcAeyvqlTx1OVKEkU4CIi2gs8K7PY iG771ARgIsRBDwg0wk92sN/dB2UXuPQFkPx30AqGSglDp8uA4AeQVsa4nhqS3LpnHRXr V31g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BQWtcDtOwkUWPssxJJd3zjpPsn+G/xDjo5VQjhtkWwI=; b=kbhV6R/W0pu2SFGFQjhf41oGHegH/UanLv28IZDVq+k0mqXD30X6UFVDlRaAcZwDAK ZluoeC69iVXqkJFWlZ8RG6NAXfNQCgnpYwSBnuClPUGJ7Rrb9Wl0y/7N+JS+LUru3XZM jDNa9hXnFGp/Q2ikb6xEkFVGTtrfkCnUBeG4JVseiKpP4g8yLtw+aUoF0AiNDknV8SIX nLnonT05taEbSucIpOV2iEgCH4fvnTCDyXvtVlYEhrZAKxW1PE74/ixv7wWRublC31uM IXfI5ZZk6yLrYRkWMb7hSdvqfYt0uMTGKe9eZ291BSh6lu/Q+AZ21niK6VOeJpj6nPwT 5oag==
X-Gm-Message-State: APjAAAUIH80h6yIFOGCdyKW8+JaG7ptQwdEhysoYk5X653u0rOLjYViQ Tbke5Zf8mcySpiRRgIZfxg/Gf/fY
X-Google-Smtp-Source: APXvYqzSlBVgEnU3xDBlDnmbeHn9nBo7s2st6I+pthiNfx4K00lzqhGFCd56uCvf5/TScE6TjdpIQA==
X-Received: by 2002:a7b:c115:: with SMTP id w21mr15737910wmi.55.1555189506553;  Sat, 13 Apr 2019 14:05:06 -0700 (PDT)
Received: from [10.0.0.147] (bzq-109-66-94-12.red.bezeqint.net. [109.66.94.12]) by smtp.gmail.com with ESMTPSA id o15sm41237604wrj.59.2019.04.13.14.05.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Apr 2019 14:05:05 -0700 (PDT)
To: Brian Carpenter , gen-art@ietf.org
Cc: draft-ietf-oauth-jwt-bcp.all@ietf.org, oauth@ietf.org
References: <155397908561.3942.9798054943934320825@ietfa.amsl.com>
From: Yaron Sheffer 
Message-ID: <13c5e6c9-ee7f-b43c-2c4b-a7ec51de7e88@gmail.com>
Date: Sun, 14 Apr 2019 00:05:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <155397908561.3942.9798054943934320825@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-jwt-bcp-04
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, 13 Apr 2019 21:05:14 -0000

Hi Brian,

Thank you for your review!

Your comments are addressed by the following commit: 
https://github.com/yaronf/I-D/commit/d00674b352f6e1323da8c5b6600f1f0d7e9b64b1

Please let us know if any issues remain.

Best,
	Yaron

On 30/03/2019 23:51, Brian Carpenter via Datatracker wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-oauth-jwt-bcp-04
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-oauth-jwt-bcp-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-03-31
> IETF LC End Date: 2019-04-08
> IESG Telechat date:
> 
> Summary: Ready with (minor) issues
> --------
> 
> Minor issues:
> -------------
> 
>> 2.3.  Multiplicity of JSON encodings
>>
>>    Previous versions of the JSON format [RFC8259] allowed several
>>    different character encodings: UTF-8, UTF-16 and UTF-32.  This is not
>>    the case anymore, with the latest standard only allowing UTF-8.
>>    However older implementations may result in the JWT being
>>    misinterpreted by its recipient.
> 
> Why is that a security issue?
> 
>> 3.6.  Avoid Length-Dependent Encryption Inputs
> ...
>>   ...It is
>>   RECOMMENDED to avoid any compression of data before encryption since
>>   such compression often reveals information about the plaintext.
> 
> I'd like a citation for that, because it isn't intuitive. (And compression
> after encryption is pointless, of course.)
> 
>> 3.10.  Do Not Trust Received Claims
> 
> Both the recommendations in this section seem imprecise. Maybe there
> should be some hints about the verification processes.
> 


From nobody Sun Apr 14 09:04:52 2019
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 3D9BA1200D7 for ; Sun, 14 Apr 2019 09:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0Zeh23gBmuEB for ; Sun, 14 Apr 2019 09:04:48 -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 E9CA11200DF for ; Sun, 14 Apr 2019 09:04:47 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3EG4b0k009510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Apr 2019 12:04:39 -0400
Date: Sun, 14 Apr 2019 11:04:37 -0500
From: Benjamin Kaduk 
To: RFC Errata System 
Cc: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com, rdd@cert.org, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com, collinsauve@gmail.com, oauth@ietf.org
Message-ID: <20190414160436.GD10547@kduck.mit.edu>
References: <20190409220246.5100EB80458@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190409220246.5100EB80458@rfc-editor.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (5687)
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, 14 Apr 2019 16:04:50 -0000

This looks correct to me, so I'll mark it as verified.

-Ben

On Tue, Apr 09, 2019 at 03:02:46PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7636,
> "Proof Key for Code Exchange by OAuth Public Clients".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5687
> 
> --------------------------------------
> Type: Technical
> Reported by: Collin Sauve 
> 
> Section: 5
> 
> Original Text
> -------------
> Server implementations of this specification MAY accept OAuth2.0
> clients that do not implement this extension.  If the "code_verifier"
> is not received from the client in the Authorization Request, servers
> supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
> protocol without this extension.
> 
> As the OAuth 2.0 [RFC6749] server responses are unchanged by this
> specification, client implementations of this specification do not
> need to know if the server has implemented this specification or not
> and SHOULD send the additional parameters as defined in Section 4 to
> all servers.
> 
> 
> Corrected Text
> --------------
> Server implementations of this specification MAY accept OAuth2.0
> clients that do not implement this extension.  If the "code_challenge"
> is not received from the client in the Authorization Request, servers
> supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
> protocol without this extension.
> 
> As the OAuth 2.0 [RFC6749] server responses are unchanged by this
> specification, client implementations of this specification do not
> need to know if the server has implemented this specification or not
> and SHOULD send the additional parameters as defined in Section 4 to
> all servers.
> 
> 
> Notes
> -----
> The code_verifier is not sent in the authorization request.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7636 (draft-ietf-oauth-spop-15)
> --------------------------------------
> Title               : Proof Key for Code Exchange by OAuth Public Clients
> Publication Date    : September 2015
> Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


From nobody Sun Apr 14 09:06:00 2019
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 21B201200E6; Sun, 14 Apr 2019 09:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5AdDS9NxjAm2; Sun, 14 Apr 2019 09:05:57 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869671200DF; Sun, 14 Apr 2019 09:05:57 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 13BA1B8063D; Sun, 14 Apr 2019 09:05:56 -0700 (PDT)
To: collinsauve@gmail.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: kaduk@mit.edu, iesg@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20190414160556.13BA1B8063D@rfc-editor.org>
Date: Sun, 14 Apr 2019 09:05:56 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Errata Verified] RFC7636 (5687)
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, 14 Apr 2019 16:05:59 -0000

The following errata report has been verified for RFC7636,
"Proof Key for Code Exchange by OAuth Public Clients". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5687

--------------------------------------
Status: Verified
Type: Technical

Reported by: Collin Sauve 
Date Reported: 2019-04-09
Verified by: Benjamin Kaduk (IESG)

Section: 5

Original Text
-------------
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Corrected Text
--------------
Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.


Notes
-----
The code_verifier is not sent in the authorization request.

--------------------------------------
RFC7636 (draft-ietf-oauth-spop-15)
--------------------------------------
Title               : Proof Key for Code Exchange by OAuth Public Clients
Publication Date    : September 2015
Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Apr 15 09:21:27 2019
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 A625D1203AA for ; Mon, 15 Apr 2019 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wOIp1ol2OeY for ; Mon, 15 Apr 2019 09:21:23 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1E01203A4 for ; Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id y10so27603694itc.1 for ; Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9vQar4S8xD941gw11gByKYu/1WGYO+zwSYJi9N4iA7Y=; b=Xxjq2Ubsp1lA81+QSmUltos9fHXo5GIClEqs+cZPw2JvK+xO1XtGK2aTaCZZSdauel mQevLSGhUBua+00cRhTI4T0z0ottWiL8I46eYihfXTuAJSTiVPZO1jjSpn5zglSgWzpA Sa1d4eRYyAYOFyXFwXV1dVW9TtQR+EOuoPc8bSTmlTx/5Lzfwj0nZXvdVZw3kmPY/ZTI vFqyK2QfrGeqDp7ohd2atkiL7jV/OS9lbSHmy1a9IW54j6NnhDmQLv4KbMZ53IwWdbz+ jozPIzDbObj2cgddFSoK6HOBkrT9JmAkzk8mlBwX2yNoWICYKjuO3A+SBfptfZVRaY8l oLog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9vQar4S8xD941gw11gByKYu/1WGYO+zwSYJi9N4iA7Y=; b=ROYTdmguH7EBm4OU0Ew36xMM0Xw27ul/JQRbkGSV4FBvB7nL84yY8VeyiJLcNBort0 c4TAdb+7TF7RTTuJp/OXx4jRla1Oqo5eqXzN7iQfLTp9K0l2hdB65BL7n1iI+navlNII BKWN+8qYFgk5wRJpQ1zbsM3alC+g7ahLAq1m30VCfDK1ZecJvk9//vauEcSvr1cciEwF Z2kfebWMrRZLLvoPloUrLViXk1sI8nsoS8HsbhJAUbSSdXgJaStA5xjbAAdli8Cdkj1r hEbKXN7uyMEr+SlTz9fpXCMyJ1CGgRgTzBS5EKbn7WfO0495xyAP6WWlJ+n2bpd1nb0c LQjQ==
X-Gm-Message-State: APjAAAUyZ5TectZj4RvxFKPxwYoQx+xkq8SYWILMp6pVnw3CB3eJ3jds R9+2IyH/2oVwV/l+iT9WU+i89FKPnffvSEhh7FR3y1aa
X-Google-Smtp-Source: APXvYqyN3Zs9QyEQ1WzDMwREFBnbRPVNJmrKk3SOL34mC6r8Zl7cl3ZtxAPH2vAfc4mGPf7eTSwv2Zp4quwpf0AvdH8=
X-Received: by 2002:a05:6638:258:: with SMTP id w24mr53052304jaq.85.1555345282097;  Mon, 15 Apr 2019 09:21:22 -0700 (PDT)
MIME-Version: 1.0
References:     <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>
In-Reply-To: <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>
From: Sascha Preibisch 
Date: Mon, 15 Apr 2019 09:20:20 -0700
Message-ID: 
To: "Schanzenbach, Martin" 
Cc: IETF oauth WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2019 16:21:26 -0000

Thanks, Martin!

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

Thanks,
Sascha

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


From nobody Tue Apr 16 01:13:41 2019
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 C6D3F12034F for ; Tue, 16 Apr 2019 01:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 yxIP1_HhMh1D for ; Tue, 16 Apr 2019 01:13:36 -0700 (PDT)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 86650120150 for ; Tue, 16 Apr 2019 01:13:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FEAADJjbVc/xmnZsBmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYFnKmhyEigKjH+MGSV+iDuPI4FnCwUYCwyEPgKGAyM?= =?us-ascii?q?4EwEDAQEKAQEBAQICAmkcDIJ4MRw+AQEBAQEBUAJELAEBAQMBAQEbUQICBwU?= =?us-ascii?q?HBAIBCBEEAQEBLiEGCx0IAgQOBQ6DFAGBaQMNDw+ocIVHgkANghEKBoEygUy?= =?us-ascii?q?IX4ECHYFYPiZrJwwTghc1PoIaRwEBgS4BEgEJHSUMgwOCJgOKVCqHTpMwNgM?= =?us-ascii?q?EAgKBK1uCeYIUhR+DW0eDSRuCCCqFcYM7iRWTWIxRgWYiDVhxcUUKBSUBVR2?= =?us-ascii?q?BJimDLgECh1yFPz8BATEBjiENFweBBIEhAQE?=
X-IPAS-Result: =?us-ascii?q?A2FEAADJjbVc/xmnZsBmGQEBAQEBAQEBAQEBAQcBAQEBA?= =?us-ascii?q?QGBZYFnKmhyEigKjH+MGSV+iDuPI4FnCwUYCwyEPgKGAyM4EwEDAQEKAQEBA?= =?us-ascii?q?QICAmkcDIJ4MRw+AQEBAQEBUAJELAEBAQMBAQEbUQICBwUHBAIBCBEEAQEBL?= =?us-ascii?q?iEGCx0IAgQOBQ6DFAGBaQMNDw+ocIVHgkANghEKBoEygUyIX4ECHYFYPiZrJ?= =?us-ascii?q?wwTghc1PoIaRwEBgS4BEgEJHSUMgwOCJgOKVCqHTpMwNgMEAgKBK1uCeYIUh?= =?us-ascii?q?R+DW0eDSRuCCCqFcYM7iRWTWIxRgWYiDVhxcUUKBSUBVR2BJimDLgECh1yFP?= =?us-ascii?q?z8BATEBjiENFweBBIEhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,357,1549926000";  d="asc'?scan'208";a="10380762"
Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2019 10:13:30 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAACBjbVcfRBhWMBmGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYFngRJRIRIoCox/jBklfog7jyOBZwsFGAuESgKGJTgTAQM?= =?us-ascii?q?BAQoBAgECFAEBFjojDIVKAQEBAwEBARtRAgIHBQcEAgEIEQQBAQEuIQYLHQg?= =?us-ascii?q?CBA4FDoMUAYFpAw0PD6hwhUeCQA2CEQoGgTKBTIhfgQKBdT4maycME4IXNT6?= =?us-ascii?q?CGkcBAYEuARIBCR0lDIMDgiYDilQqh06TMDYDBAICgStbgnmCFIUfg1tHg0k?= =?us-ascii?q?bgggqhXGDO4kVk1iMUYFmIA5YcXFFCgUlAVUdgSYpgy4BAodchT8/AQIwAY4?= =?us-ascii?q?hDRcHgQSBIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,357,1549926000";  d="asc'?scan'208";a="42441191"
Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP12EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/AES256-SHA; 16 Apr 2019 10:13:28 +0200
Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP12EXC.ads.fraunhofer.de ([10.80.232.43]) with mapi id 14.03.0435.000; Tue, 16 Apr 2019 10:13:27 +0200
From: "Schanzenbach, Martin" 
To: Sascha Preibisch 
CC: IETF oauth WG 
Thread-Topic: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
Thread-Index: AdTuLScSpXb+JyqRQxyWjNeRvoJpaABYNsSgAAUTZqAABFDkgACUbkKAAGRDswAAIUlhAA==
Date: Tue, 16 Apr 2019 08:13:26 +0000
Message-ID: <86A18436-0DD9-4269-A5E5-4279C269C55B@aisec.fraunhofer.de>
References:     <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.80.233.51]
x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24552.002
x-tm-as-result: No--45.272500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/signed; boundary="Apple-Mail=_72396242-37B8-4007-AA9F-16690C9E41C3"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Apr 2019 08:13:40 -0000

--Apple-Mail=_72396242-37B8-4007-AA9F-16690C9E41C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 15. Apr 2019, at 18:20, Sascha Preibisch =
 wrote:
>=20
> Thanks, Martin!
>=20
> I understand. I just think it is difficult to get this adopted if
> clients now have to include the target resource in their request in
> order to place that into the 'aud' field. Unless the client has
> somehow registered its intended protected resources beforehand the
> authorization server cannot set an appropriate value if it was not
> passed in as a request parameter.

Yes, I think this is how it was supposed to work anyway even without =
JWTs. The client uses the "scope" parameter to indicate what it needs =
access to.
The AS needs to make a decision in accordance with the RO what access =
token to issue (i.e. which RS to grant access to).
The scope does not need to be the full RS URI. It is domain-specific =
what RSes a scope parameter maps to. Nothing the spec can do here, =
really.

BR
Martin

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


Martin Schanzenbach
Fraunhofer AISEC
Department Service & Application Security
Parkring 4, 85748 Garching near Munich (Germany)
Tel: +49 89 3229986-193
martin.schanzenbach@aisec.fraunhofer.de
GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0


--Apple-Mail=_72396242-37B8-4007-AA9F-16690C9E41C3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAly1jqYACgkQhDNRMeo9
q/AQvQ//SBmd1tKaVohuyI+QuVLiwPLZXHCbLpq6XUO45wqGBx32EjHoJHthiPym
p8T8CLVqRmMzfsPWAIh25+Y8fijB86gGl9UdkepCfBusY2f30459KRsDSsBDUU+H
A8KLLt9x3aiWPO72ZDmAKBO7gVWy2nTIW615NjWpMyJG0CSPTAkhYdNi2ZFrznid
qNO9f01UeiPXnPLQUJ5iIzQID2N4ieR8X8t0+jpjdVfOAuQMKEHtGl2dtrtxtLz1
SO0TGpBk6FbH++9iAnQDJI/xM1EvNpZFuXOEbs3gPeNMAxVWWdc5+44OqeLDOgqT
GhKPmm9Fzo15RH0LYqw9TEKpwVZ5bO5//W2jkuuKf6Ba/V3nTsnVWNDRqs0s9E4q
nvPHs1oyyh4bGQu/ykq4TLL6k9/9xcWJ1ecKNlgAO/Jn2DUbuyJRV4wlTiR5SnBe
4uLVkmYU4hYrYn314+gqoGG32afv+v9vmuznEBTqVdcpS2B8AyFEjrgdZkX35zXD
4AorTe7M1zubgSSnvvazAd1hv5IIZHe1toETi82TSAF61nSoyXcWZgT+yXBPGApG
F4jkp6b9vMtsO7fRQG2UrMP35mkkcQJ7NiVL9+LdLlrmhtYNgVclIvL0tjA06bgK
4ez5yATefqCHvu1TT5bpOM5PCwR8w0VBtvRsrMSTPj3CfAVBShM=
=63Y3
-----END PGP SIGNATURE-----

--Apple-Mail=_72396242-37B8-4007-AA9F-16690C9E41C3--


From nobody Tue Apr 16 02:46:16 2019
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 D2601120163; Tue, 16 Apr 2019 02:46:09 -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.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <155540796975.4600.954927954403497616@ietfa.amsl.com>
Date: Tue, 16 Apr 2019 02:46:09 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bcp-05.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: Tue, 16 Apr 2019 09:46:10 -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 Best Current Practices
        Authors         : Yaron Sheffer
                          Dick Hardt
                          Michael B. Jones
	Filename        : draft-ietf-oauth-jwt-bcp-05.txt
	Pages           : 15
	Date            : 2019-04-16

Abstract:
   JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
   tokens that contain a set of claims that can be signed and/or
   encrypted.  JWTs are being widely used and deployed as a simple
   security token format in numerous protocols and applications, both in
   the area of digital identity, and in other application areas.  The
   goal of this Best Current Practices document is to provide actionable
   guidance leading to secure implementation and deployment of JWTs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-05


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 Tue Apr 16 02:47:43 2019
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 144AC120359 for ; Tue, 16 Apr 2019 02:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AmiG1warR8RR for ; Tue, 16 Apr 2019 02:47:38 -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 A5D58120163 for ; Tue, 16 Apr 2019 02:47:37 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id j9so26063358wrn.6 for ; Tue, 16 Apr 2019 02:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Rd8u9RwZnoauWo+h6ZiX75YrbEqgoF8RZFsRLkw5IQw=; b=NvU4YHy9Vpe0ryIJK4vUymetXDUrBmNkmAKQHxVDv+Z4bZ8MBF2kji5/Nj1KOvtreD 4bnlrj4ynUs4Pa2xJNa1XoZFB6YXMrNxwrf3t93auL+ZHT6yriQn+jQArBbmPpHp1FMf vrsv5HdYTs27MUhxa4fdHyUJ34mdLxe38MPWBW3tW7JRCVSIa74z1FEH2KyJDZ3UD+Gg QOGnxbF1WZmWIOvDc1bPF02IT3dKQXiDvMiKxF/5xYm3xayZfoxDyJpRgmj3oayE9xLB DpKOw3piwhFSG/vZIYrN1CZ8+cpIspclk6z5JOTLcR5P1gDzwtaqhKLwxRV0pCOlFKeg wTIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Rd8u9RwZnoauWo+h6ZiX75YrbEqgoF8RZFsRLkw5IQw=; b=DYCpkjUGN4qMEDJkH2Yi+cyGqDAKc9+8V7Osb/Y0PA3j4nGVvP5MjCiUGSIaJ152GZ 6WoPNe1mGr15g+YeAvjXtMsXyoCSd52k29gB8fKLK9SXr0x70zvB45XURg9Oxbdju1su d7Qrbo1JQykQCd4yvm4DBhrhWuR5iSzzp+4EtZTT3DCFBi2cx8TNnP0ZtAx7TNqNsUyZ 26k6jnfspfFcHu9qSdenTFEoxDRVnHugwHpOJvGzvQwz2gabUA2UwSlzjCpEe0aAO/Kc HTkj7wdbnMk18OVduqv7b/esfqHfqQ9A9fSCvda5CxdyU+3ADE8CgLAgQ0PMJ1+dbzOc SHDg==
X-Gm-Message-State: APjAAAXNmWzr/nN3k9gP8ph/MRgW2nAQf5+5dWNlH8ASDq/SHKF2eTF8 ZnQL6vZeHlcd7kOVt+V1oFH5Wegh
X-Google-Smtp-Source: APXvYqwRF4FKGwsjCl9dX1OqeD91vwueSps53u8upOSQ5DfJ5TjiYR3+NFIJA9BXPI1N75HRqBX8BA==
X-Received: by 2002:a5d:4e82:: with SMTP id e2mr18568477wru.164.1555408055990;  Tue, 16 Apr 2019 02:47:35 -0700 (PDT)
Received: from [172.18.129.84] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id d3sm42749934wmf.46.2019.04.16.02.47.35 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 02:47:35 -0700 (PDT)
References: <155540797001.4600.8993819539718772895.idtracker@ietfa.amsl.com>
To: oauth 
From: Yaron Sheffer 
X-Forwarded-Message-Id: <155540797001.4600.8993819539718772895.idtracker@ietfa.amsl.com>
Message-ID: 
Date: Tue, 16 Apr 2019 12:47:34 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <155540797001.4600.8993819539718772895.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-jwt-bcp-05.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, 16 Apr 2019 09:47:40 -0000

This version addresses Genart comments. Thanks to Brian Carpenter for 
his review!

	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-oauth-jwt-bcp-05.txt
Date: Tue, 16 Apr 2019 02:46:10 -0700
From: internet-drafts@ietf.org
To: Michael B. Jones , Dick Hardt 
, Yaron Sheffer , Michael 
Jones 


A new version of I-D, draft-ietf-oauth-jwt-bcp-05.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-ietf-oauth-jwt-bcp
Revision:	05
Title:		JSON Web Token Best Current Practices
Document date:	2019-04-16
Group:		oauth
Pages:		15
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bcp-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-05
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bcp-05

Abstract:
    JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
    tokens that contain a set of claims that can be signed and/or
    encrypted.  JWTs are being widely used and deployed as a simple
    security token format in numerous protocols and applications, both in
    the area of digital identity, and in other application areas.  The
    goal of this Best Current Practices document is to provide actionable
    guidance leading to secure implementation and deployment of JWTs.

 


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.

The IETF Secretariat


From nobody Tue Apr 16 20:09:43 2019
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 ADC2E1202F0 for ; Tue, 16 Apr 2019 20:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 U2U_rqO2bDqF for ; Tue, 16 Apr 2019 20:09:40 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0: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 277E21202EF for ; Tue, 16 Apr 2019 20:09:40 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id v84so18827000oif.4 for ; Tue, 16 Apr 2019 20:09:40 -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=l4otrKuihccXO0QpXr02h8uouOs/gzHVdpVYjMwTDIg=; b=qenhxxuK0ZJzfeCncKvtqVh6cIPtO+Ry6wiQa1W4W2HJN1M4uktMHeVTVg3plQ7ia8 ljyk6I2LvGUM+8mLRp16y3qBaMBDvPRdSdhaViD8rkIOF/CbjqHEauuyMqEPqH8P2ves xxOuOPBUhb56eTQUeIPk6/6oB5x6Nrr4kBajQsB1QqL11s+i0ewoo4WkD4aBwzc7+UUx w5DSD+yq2xTu8MNnuHNMBi4dWEdWlYUdKWQmjE6ZnRVRu7+kME1kyoEXDoC6yojKnoaJ ZiANOUFqNwtsfowT9981nU+YFvuBA3pFYEipYto2JBU4pwYbJ3a1egqTu2jiDBajO4bv Wq6w==
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=l4otrKuihccXO0QpXr02h8uouOs/gzHVdpVYjMwTDIg=; b=ADie/wWkuFELX+idWCg+nwjTy0ctCN5+gU81LdSbxURBwVdxDwvC/kfutyjFfQ/mFq gVJ2Ui9C4pbmRTwEqQlO+/qKCYNlBfIYkJFnaIYDD783QnYX5w+pI0ZBCqjvkb4nhAci y2uaqFLX0IeTRmZrYqsMiqzaYjdjR0WgX16L6lU9nB1pKNVxRg2BoKyiLyuyNeDqTlNm vUygsH4BFyriJnZLm8N5RmK5GyLGTnwbVV4z2kJJ1FdkETkTK+6ZZVnPR37Wdl7f1+0b d3aiUeWkEqe5PZt1bLOYg0NXOTzY1xmTejBIxMzYiWoZ98nbtnxpZ2kQ/AKAP+EUUmFA hacg==
X-Gm-Message-State: APjAAAUmrJqOwBMq2qf+eXF91bIx5ddkfAA5LzB11iEFo/wy0t3As4xb y18zFn1oJtbJUeuwANawvwA0KbHyoRy9TyqETKMp
X-Google-Smtp-Source: APXvYqwdA9K3lzD/i1Y5/4eEYMd49nEcKmRLqecGwomK5o1/rkxgIsE18Go1ff5IJCRWSRCHQz/RAtvTK1Zskuhn9ts=
X-Received: by 2002:aca:f511:: with SMTP id t17mr25212897oih.115.1555470579322;  Tue, 16 Apr 2019 20:09:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:9872:0:0:0:0:0 with HTTP; Tue, 16 Apr 2019 20:09:38 -0700 (PDT)
Received: by 2002:a4a:9872:0:0:0:0:0 with HTTP; Tue, 16 Apr 2019 20:09:38 -0700 (PDT)
From: Wendy Irene Haas 
Date: Tue, 16 Apr 2019 20:09:38 -0700
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056d32c0586b1371f"
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: Wed, 17 Apr 2019 03:09:42 -0000

--00000000000056d32c0586b1371f
Content-Type: text/plain; charset="UTF-8"

tls_client_auth_subject_dn An [RFC4514] string representation of the
expected subject distinguished name of the certificate, which the OAuth
client will use in mutual TLS authentication. tls_client_auth_san_dns A
string containing the value of an expected dNSName SAN entry in the
certificate, which the OAuth client will use in mutual TLS authentication.
tls_client_auth_san_uri A string containing the value of an expected
uniformResourceIdentifier SAN entry in the certificate, which the OAuth
client will use in mutual TLS authentication. tls_client_auth_san_ip A
string representation of an IP address in either dotted decimal notation
(for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in
[RFC4291] section 2.2) that is expected to be present as an iPAddress SAN
entry in the certificate, which the OAuth client will use in mutual TLS
authentication.

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


tls_client_auth_subject_dn An [RFC4514] string representatio=
n of the expected subject distinguished name of the certificate, which the =
OAuth client will use in mutual TLS authentication. tls_client_auth_san_dns=
 A string containing the value of an expected dNSName SAN entry in the cert=
ificate, which the OAuth client will use in mutual TLS authentication. tls_=
client_auth_san_uri A string containing the value of an expected uniformRes=
ourceIdentifier SAN entry in the certificate, which the OAuth client will u=
se in mutual TLS authentication. tls_client_auth_san_ip A string representa=
tion of an IP address in either dotted decimal notation (for IPv4) or colon=
-delimited hexadecimal (for IPv6, as defined in [RFC4291] section 2.2) that=
 is expected to be present as an iPAddress SAN entry in the certificate, wh=
ich the OAuth client will use in mutual TLS authentication.


--00000000000056d32c0586b1371f--


From nobody Sat Apr 20 11:21:34 2019
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 92E12120159 for ; Sat, 20 Apr 2019 11:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tfM0BOkPHitS for ; Sat, 20 Apr 2019 11:21:30 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (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 ECE3D12013B for ; Sat, 20 Apr 2019 11:21:29 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hHucB-0000Eg-4C for oauth@ietf.org; Sat, 20 Apr 2019 20:21:27 +0200
From: Torsten Lodderstedt 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
Date: Sat, 20 Apr 2019 20:21:26 +0200
To: oauth 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Apr 2019 18:21:33 -0000

Hi all,=20

I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20

I look forward to getting your feedback.

kind regards,
Torsten.=20=


From nobody Sun Apr 21 13:41:26 2019
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 CC5D6120196 for ; Sun, 21 Apr 2019 13:41:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SYhh2b7CmFY0 for ; Sun, 21 Apr 2019 13:41:23 -0700 (PDT)
Received: from p3plsmtpa11-06.prod.phx3.secureserver.net (p3plsmtpa11-06.prod.phx3.secureserver.net [68.178.252.107]) (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 DBDFA120110 for ; Sun, 21 Apr 2019 13:41:22 -0700 (PDT)
Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id IJH6hM0hpyD5JIJH7hmcvk; Sun, 21 Apr 2019 13:41:22 -0700
To: oauth@ietf.org
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <7bca0d14-8644-ef2b-c33a-bd874fe8fb6c@connect2id.com>
Date: Sun, 21 Apr 2019 23:41:20 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070107050606080600080507"
X-CMAE-Envelope: MS4wfB/Mo1twZODdo5R1PAU8JAEqYOx4tbMhco27BwAsn5WpcwiG108URJ3P9qlHwU7IYO3hc8NHzAMN4Cs/JUqQV4v7G6+Q8aC9/3Z7hvIXrPXNZd6moSxF XrIDTyt90g70jd440sdCyuMWVEvQBlQbAS9ieOY1Cxyp9W48P7jlnuKv
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Apr 2019 20:41:25 -0000

This is a cryptographically signed message in MIME format.

--------------ms070107050606080600080507
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

The proposed structured_scope fits nicely into the JSON object format of
the request object.

At present for similar cases we recommend developers to encode the scope
value into a URI with query string parameters, e.g.

https://scopes.myapp.com/sign?credentialID=3Dqes_eidas&documentDigests.ha=
sh=3DsTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI&documentDigests.label=3D=
Mobile%20Subscription%20Contract&hashAlgorithmOID=3D2.16.840.1.101.3.4.2.=
1

On 20/04/2019 21:21, Torsten Lodderstedt wrote:
> Hi all,=20
>
> I just published an article about the subject at: https://medium.com/oa=
uth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2=
326e2038948 =20
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.=20



--------------ms070107050606080600080507
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
CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw
MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0
MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT
8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19
sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg
ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X
HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4
PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv
bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy
MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw
T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw
AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv
Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB
CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF
1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ
6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx
mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk
/sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4
MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MjEyMDQxMjBaMC8GCSqGSIb3DQEJ
BDEiBCDD/mfXw29P1yoQIFRnVSkU9UBg5ubX25QHhxYNGhJ8jzBsBgkqhkiG9w0BCQ8xXzBd
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx
gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq
hkiG9w0BAQEFAASCAQAbl49+zRLVdJciwobdnOSj2pNR3KnI6J5sGq/ysUuwvPu9y2l/WYKA
vddhIaMDFtVeAVXx2bXeuN63xYkTMqmeaEH5ySn7SGJ7DpoHntY6WLq1NzKPy+u5q7M28z4D
rQmEhqjfjnpuONZX93JQCGO/E2WDfexdMWxTqnNPW2DMYNB3jY8uI5LCqZXJxjds3ZpE44y5
7d9qafeaeCBhQ73uGBQRnVgM84t2uR/CSFyD7MG1ExPpp3EJBVsBUVsAOCIFbbHrAuDxKKBx
/I8Rot3UOg7x4BvAkNt8v/8VYXm/dFxDRMDTs0Gbmj7JASjDAoQTINMljhyW1jUJyq2jpw+W
AAAAAAAA
--------------ms070107050606080600080507--


From nobody Mon Apr 22 01:15:33 2019
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 E47401200EF for ; Mon, 22 Apr 2019 01:15:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 HV0cRKpJGijA for ; Mon, 22 Apr 2019 01:15:30 -0700 (PDT)
Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (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 5B7AD1200DB for ; Mon, 22 Apr 2019 01:15:30 -0700 (PDT)
Received: from [192.168.0.105] ([94.155.17.204]) by :SMTPAUTH: with ESMTPSA id IU6qhAFTHW2KVIU6rhJW6G; Mon, 22 Apr 2019 01:15:29 -0700
To: OAuth@ietf.org
From: Vladimir Dzhuvinov 
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>
Date: Mon, 22 Apr 2019 11:15:27 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050100010802030503050802"
X-CMAE-Envelope: MS4wfMdzPmf0H0b262aQkrXN3F9L5rEq4gTpvFbsG7B9gCwrV6GRWWrlQ+eEFYgW5tKUiKXWiLn880BffOdunHU6Rm9vssTbklpGKS1ZWIgrYRLU1sALOIOV ee42mrLSA2gZh1OnNnsHFdf6RKCGNzZkPTJqqyNPbxWvJ7UCg7CzI/SL
Archived-At: 
Subject: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 22 Apr 2019 08:15:32 -0000

This is a cryptographically signed message in MIME format.

--------------ms050100010802030503050802
Content-Type: multipart/alternative;
 boundary="------------48F2D56D05983A9BC5CDD3E2"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------48F2D56D05983A9BC5CDD3E2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4

How should multi-valued request params be expressed in the JWT claims
set? As values in a JSON array?

     {
      "iss": "s6BhdRkqt3",
      "aud": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" ]
     }

Apart from custom params, the resource indicators spec also suggests
that such situations can occur:

https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#secti=
on-2

Thanks,

Vladimir


--------------48F2D56D05983A9BC5CDD3E2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
https://tools.ietf.org/html/dr=
aft-ietf-oauth-jwsreq-17#section-4

    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" ]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.iet=
f.org/html/draft-ietf-oauth-resource-indicators-02#section-2

    

    
Thanks,

    
Vladimir

  


--------------48F2D56D05983A9BC5CDD3E2--

--------------ms050100010802030503050802
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
CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw
MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0
MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT
8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19
sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg
ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X
HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4
PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv
bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy
MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw
T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw
AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv
Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB
CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF
1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ
6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx
mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk
/sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4
MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MjIwODE1MjdaMC8GCSqGSIb3DQEJ
BDEiBCB02x2RlXtogCD0n7bb6R+EmZy31zfN55Z2VnxuMZv3dDBsBgkqhkiG9w0BCQ8xXzBd
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx
gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq
hkiG9w0BAQEFAASCAQBTBW2ZJpiE+98x91TNAIGmebgvPekUe1gMIRd2rFkb0VhkIIDBgquA
Yc8drSBmr77Zm8q5uFFghCYFmWd1zTfFs3tf4vLjEjLLqcKyN4E1iZ33txDoLpx76K4cuuAx
vBcITrkdVYV11ipBUmDMGnHxrghzYJcWTPUk6/AphXbOV5+NYAqj1sFC9Fhtawthx29DwbN9
vpcjIyhhfPDWyMnnKnWxifYlSM2yvyg7ZvywFUsOkvC/LWsE7WfJQju5dTYAtKUQfsOoegl0
joq+0Zff7Ss5wCFuDmK051EpLQEqiogjL1Jy5AKf0wILc7QK8TXpkyblJ9BvYCe1bcBIzoHq
AAAAAAAA
--------------ms050100010802030503050802--


From nobody Mon Apr 22 01:38:47 2019
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 9427D120059 for ; Mon, 22 Apr 2019 01:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level: 
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4_UZ6_W_l0A for ; Mon, 22 Apr 2019 01:38:43 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0: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 0D2AC120043 for ; Mon, 22 Apr 2019 01:38:42 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id v7so7968308oie.8 for ; Mon, 22 Apr 2019 01:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=glvGZQg8Q/uEQuQrxiOjy1NCYpSr8om7vh1CzjcNDLU=; b=cHj0mNf7YNr1ZWBe2UjDthl1VyoinPghVYW/BQF/RMvfuA0XIkA+V5ijP75AJJgdX5 crMQrJVe2HOVbyVSt5ji+Kz1o8/lxhErPX2IJfPAaMFgp0gafTdF7Vt1SkLc7bFH01AB e3dw3zKHzpY5XuJ3j64bYwQSm0Wki9VNqOL6dyE0qqX/PYR/D2wVUe4gE+2Xbs6Xf/4L 0kJ7tSSfSY68TI+ymEew1Ci19yvRCWgXi5CwzhQFo8DpLgMRBLwpYEr8DFbB/g4vrx8R AZSCA2ZanoATmQZqRhbnEgfANpN0+WL+GG8MrUM/akn3lRLCGVCsqirwD2g1aHCD0Ju1 9u/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=glvGZQg8Q/uEQuQrxiOjy1NCYpSr8om7vh1CzjcNDLU=; b=Z7bqEnQTlw5uD0ixA2zIOxAKY+d3aznjn/MyHe6VgD4eRaTz2JV5c+Ull2dAiI73ED oFgL47SANfwzUx+7GO7tHzrsRPg0Ih/6a0+Xk6TB5iyBDL/bn0kaGl3IvX+wvaSeJhrN h/FtV1NLOiz30P5E2mR/McrLyNbDhXLS3y0gYfrVb4/5u7jf6RLpCmXqjhw6lQR8gHCn +3uu/UfEgpntmptGoSTlPYOEvIGXfNCJS+Vz1eFCtJak/HInXm2nI284Ywo6XGsuZcs+ bZco1+7W+MFJSkE6964sETnpUdCrbq+2tnRGGf/PiDUK3o0q9ttARz9oekuqnstmR2Xs s07A==
X-Gm-Message-State: APjAAAXkFAH4iYHpQ5fn/pKWQj8Gok3L5pqVlihUzx6QaqLz1XhRc7TY OKK5p24Xry4bHOUv+/EkkB37kkwdjnUGKD4nhIlnMN9r2u8=
X-Google-Smtp-Source: APXvYqwXQx6XgZ9gvGIZZZ0Uxf7/+ef6OFYf1k2TasybiJlv6R3m50k9S+AxHSEyrWmmf2B8dnPz7+YZJEuc35iuzaw=
X-Received: by 2002:aca:df55:: with SMTP id w82mr9638190oig.113.1555922322003;  Mon, 22 Apr 2019 01:38:42 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Steinar Noem 
Date: Mon, 22 Apr 2019 10:38:31 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000004d2cee05871a656c"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 08:38:45 -0000

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

Hi Torsten, thank you for writing this clarifying article :)

In the health sector in Norway we are facing similar challenges regarding
the need for contextual information.
At the time, our planned solution is to package this information as custom
claims in request objects - e.g.: =E2=80=9Chelse:client/claims/xxxx=E2=80=
=9D, but after
reading your article I realize that the structured scope approach makes a
lot more sense and, as you stated in the article, pushing the request
objects mitigates the issues with request-size and complexity on the client
side.
In our case we may also have a requirement to encrypt the pushed request
object due to potential sensitive content.

- Steinar


l=C3=B8r. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <
torsten@lodderstedt.net>:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

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


Hi Torsten, thank you for writing this clarifying ar=
ticle :)

In the health s=
ector in Norway we are facing similar challenges regarding the need for con=
textual information.
At the time, our planned soluti=
on is to package this information as custom claims in request objects - e.g=
.: =E2=80=9Chelse:client/claims/xxxx=E2=80=9D, but after reading your artic=
le I realize that the structured scope approach makes a lot more sense and,=
 as you stated in the article, pushing the request objects mitigates the is=
sues with request-size and complexity on the client side.
In our case we may also have a requirement to encrypt the pushe=
d request object due to potential sensitive content.

- Steinar


l=C3=
=B8r. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <torsten@lodderstedt.net>:
Hi all, 



I just published an article about the subject at: https://medium.com/o=
auth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948=C2=A0 



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
<=
div style=3D"color:rgb(80,0,80)">Vennli=
g hilsen

Steinar Noem
Partner Udelt AS
Systemutv=
ikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@u=
delt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.=
udelt.no=C2=A0|=C2=A0


--0000000000004d2cee05871a656c--


From nobody Mon Apr 22 04:43:13 2019
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 432FE120033 for ; Mon, 22 Apr 2019 04:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 FnVeH5sTVizt for ; Mon, 22 Apr 2019 04:43:09 -0700 (PDT)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 456A5120167 for ; Mon, 22 Apr 2019 04:43:09 -0700 (PDT)
Received: by mail-it1-x131.google.com with SMTP id a190so17365430ite.4 for ; Mon, 22 Apr 2019 04:43:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vGeGcvgzR7YVNcQK/s2T2V915J6xU4bsry2IQYGA5pE=; b=W2kgiXxbrPPi6OwAeYGrjE0RowQ8/qGvQY3qBzaITa4ixZaSG38Bk6O85bdLwHPNgj 9hb30MeBl2HKgZy2hvEcn1QDaxQo9w4TbWup6wDHuCGs8N60DRC22g192SoIP3K0kknC cum6UBTa3MeoapoIm1likqZdHBOzJHO/PDqDs=
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=vGeGcvgzR7YVNcQK/s2T2V915J6xU4bsry2IQYGA5pE=; b=lAzoR1dZcfURj+/HsbKDAzfmNQe/zKqVcqzJEVWlmdEG1D9MFNuZoMNJQVzHKawxx0 oR0ckgaCK4t0iYwUoL0CbwVlW88fLqQmTlUZPTGAaFEs9f/HbObagDrCM87g5cooEdzu v57mXhq3PtdlkJ/FTKWXyQKKKeNHqsjISY+mZOL+sb35jOYHnWRwW+mTw3a/t1eRNmp1 1GmUW4esvvKij2WTpS6v+qQeSkdYWs0DCS9fZRHQkuq+84FIKSvkdn3tp4i1uaksZl1h HD+LnAbWCQGw16cfl9dR5jIfhGD5vaZWdiFYjV7dX3m4f8t+6YS9NLdkreVkWw3m4hA1 sKtA==
X-Gm-Message-State: APjAAAUyzOAd0bgeqD3gRKJy15FgmfY54eQAjVeT2+0jE2/JZDAyRLvW GIrNF31sWzsNHD5qx3ifJyLzYsuobZnW3AJaPsH2qx+i+VyW6EtWnWeLymZWwlIbu3goYpuTTi6 12mTlMQRiTlDscK9Vxhc=
X-Google-Smtp-Source: APXvYqyxKdkW2TvZ6LTWg7NOQtgWA0YEauROfM1lNcmlCbFzPffe7HIeEH+e3OhcVsrfCrf85qC6sBYb1lgNGGhKXGA=
X-Received: by 2002:a02:6411:: with SMTP id t17mr4475856jac.90.1555933388400;  Mon, 22 Apr 2019 04:43:08 -0700 (PDT)
MIME-Version: 1.0
References: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>
In-Reply-To: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>
From: Brian Campbell 
Date: Mon, 22 Apr 2019 05:42:42 -0600
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000e90c5005871cf8be"
Archived-At: 
Subject: Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 22 Apr 2019 11:43:11 -0000

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

FWIW, the second paragraph of resource indicators, section 2.1

says to use a JSON array via the following text:

   For authorization requests sent as a JWTs, such as when using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq
],
a single
   "resource" parameter value is represented as a JSON string while
   multiple values are represented as an array of strings.


On Mon, Apr 22, 2019 at 2:15 AM Vladimir Dzhuvinov 
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>
> How should multi-valued request params be expressed in the JWT claims set=
?
> As values in a JSON array?
>
>      {
>       "iss": "s6BhdRkqt3",
>       "aud": "https://server.example.com" ,
>       "response_type": "code id_token",
>       "client_id": "s6BhdRkqt3",
>       "redirect_uri": "https://client.example.org/cb" ,
>       "scope": "openid",
>       "state": "af0ifjsldkj",
>       "some-query-param": [ "val-1", "val-2" ]
>      }
>
> Apart from custom params, the resource indicators spec also suggests that
> such situations can occur:
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#secti=
on-2
>
> Thanks,
>
> Vladimir
> _______________________________________________
> 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._

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


FWIW, the second paragraph of resource indicators, section 2.1 says to use a JSON array via the=
 following text:

   For authorization requests sent as a JWTs, such as w=
hen using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
   "resource" parameter value is represented as a JSON string whi=
le
   multiple values are represented as an array of strings.

On Mo=
n, Apr 22, 2019 at 2:15 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20

   =20
 =20
  

    
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section=
-4

    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https=
://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" =
]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.ietf.org/html/draft-ietf-oauth-reso=
urce-indicators-02#section-2

    

    
Thanks,

    
Vladimir

  


_______________________________________________

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.
--000000000000e90c5005871cf8be--


From nobody Mon Apr 22 06:52:32 2019
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 F06EE120033 for ; Mon, 22 Apr 2019 06:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snLCTS6XKEab for ; Mon, 22 Apr 2019 06:52:29 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 4130B12001B for ; Mon, 22 Apr 2019 06:52:29 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id c16so9652401otn.4 for ; Mon, 22 Apr 2019 06:52:29 -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=AqzmM3TepIkU+WG71QTF5am5tAAg9GUYd6hyGQhE4/k=; b=REB/WYHoX1To0DWcmUwqKk9tagA87V0qgTj9ti6nxELjn5Ph6jb8uiYz9Sb+viByV+ aT4D7WmHFJ7HOB1a4rE114RVrRSIMT+2vXbjn516X8emj+1uKZpaDkEtPHTrN7SmHJWy /KIB7DgJ6fQGPwDEQVI7gJgXzpTQNJXqHwSME7khn0iXPOhUWXnTxlDNhpiBVTam91PU ofA3hwScgdpNBqbNhE9GqeGFPNNf/kwtc/zfUHUlDb0BtxsZLNdFg224FDrtC25P6Ckt hBlKwEJBKDNj4Q+ONg7q4pk1MwWi4K2gGskoTnG/Mm5Z6p8w7fDy84wjNkB+YBbQ2T2g QQCQ==
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=AqzmM3TepIkU+WG71QTF5am5tAAg9GUYd6hyGQhE4/k=; b=Ad4PNOyLN5dbiSh03X5FMzz/N10FyMXKAXiHMZ8xjJi1VvOKr8UfsuN1w4Z6SXVsMR l0+KGFLwzXAvyX66Mi5rRCBHxpRwFlBlzqOyDeAEODDsCQndG2L23NC/YZP3SeoYOlec EhbiePqAjH44wdZZb/fBgQAG5U1YHLCznD3wusJB7n0YDFZwlLts+M1egOA5GYRiYizy Bqp0741xGpZVOFqQtQZGenDTr+Ij3C/bYA/VE8lwCviUqO2JqPMIehwZYHo0S5BSuRfi WBMILCbOUsmoKNnRTX3C1aE2Kq6Qhu5+K/JEvU77q8fiyFK7wVRtf8SWfonDttw5eR+U WCtw==
X-Gm-Message-State: APjAAAUbLvGpmivhfB8/ZWqSvzFFwhANK1Umlho0T1oVTmuUomYJ0Roi NAvNvAcdsFN0GPjexeOj7ytGdvYEpIRhaBRBMcI=
X-Google-Smtp-Source: APXvYqzhGKVf75almI6huOoYpmtZ3YWXBfWIym9RlP+j2gszqTwWGc/9fDG1Zr7+0y87wilTEXM7mxGWNgGMRcndmKs=
X-Received: by 2002:a9d:67:: with SMTP id 94mr11877360ota.238.1555941148313; Mon, 22 Apr 2019 06:52:28 -0700 (PDT)
MIME-Version: 1.0
References: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>
In-Reply-To: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>
From: Thomas Broyer 
Date: Mon, 22 Apr 2019 15:52:17 +0200
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: "" 
Content-Type: multipart/alternative; boundary="0000000000006fce5d05871ec7f3"
Archived-At: 
Subject: Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 22 Apr 2019 13:52:31 -0000

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

RFC6749 makes it clear that =E2=80=9CRequest and response parameters MUST N=
OT be
included more than once.=E2=80=9D
So:
 * multi-valued request params shouldn't exist ("scope" is a single string
value with a specific format, as a space-separated list of scopes)
 * resource indicators draft violates RFC6749 by explicitly allowing
multiple "resource" params; and RFC6749-compliant server is free to reject
such a request with an invalid_request error, meaning that resource
indicators breaks interoperability (clients can only send multi resource
params to servers they know won't reject them with invalid_request as
they're allowed to by RC6749).
One could interpret that stance in RFC6749 as applying only to those params
defined in this spec, but it's not explicitly said, so it could be
interpreted as applying to any parameter, including extensions (like
resource indicators) or unrecognized (and therefore ignored) parameters.

On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov 
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>
> How should multi-valued request params be expressed in the JWT claims set=
?
> As values in a JSON array?
>
>      {
>       "iss": "s6BhdRkqt3",
>       "aud": "https://server.example.com" ,
>       "response_type": "code id_token",
>       "client_id": "s6BhdRkqt3",
>       "redirect_uri": "https://client.example.org/cb" ,
>       "scope": "openid",
>       "state": "af0ifjsldkj",
>       "some-query-param": [ "val-1", "val-2" ]
>      }
>
> Apart from custom params, the resource indicators spec also suggests that
> such situations can occur:
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#secti=
on-2
>
> Thanks,
>
> Vladimir
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


--=20
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/ 

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


RFC6749 makes it clear that =E2=80=9CRequ=
est and response parameters MUST NOT be included more than once.=E2=80=9D
So:
=C2=A0* multi-valued request params shouldn't ex=
ist ("scope" is a single string value with a specific format, as =
a space-separated list of scopes)
=C2=A0* resource indicators dra=
ft violates RFC6749 by explicitly allowing multiple "resource" pa=
rams; and RFC6749-compliant server is free to reject such a request with an=
 invalid_request error, meaning that resource indicators breaks interoperab=
ility (clients can only send multi resource params to servers they know won=
't reject them with invalid_request as they're allowed to by RC6749=
).
One could interpret that stance in RFC6749 as applying only to=
 those params defined in this spec, but it's not explicitly said, so it=
 could be interpreted as applying to any parameter, including extensions (l=
ike resource indicators) or unrecognized (and therefore ignored) parameters=
.

On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20

   =20
 =20
  

    
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section=
-4

    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https=
://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" =
]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.ietf.org/html/draft-ietf-oauth-reso=
urce-indicators-02#section-2

    

    
Thanks,

    
Vladimir

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/


--0000000000006fce5d05871ec7f3--


From nobody Mon Apr 22 07:35:07 2019
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 4332012004E for ; Mon, 22 Apr 2019 07:35:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 92sV3oSHEsOQ for ; Mon, 22 Apr 2019 07:35:03 -0700 (PDT)
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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 CFB80120004 for ; Mon, 22 Apr 2019 07:35:02 -0700 (PDT)
Received: by mail-vs1-f53.google.com with SMTP id e2so6305368vsc.13 for ; Mon, 22 Apr 2019 07:35:02 -0700 (PDT)
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=sN7W30FS9cBYOdJ0Rv0F9KtsNuJcS/cnlbPrHrKZc5E=; b=iccgn1jkkXDWVD6aSBa7WLiSXIUQoTLCAO9qiUFF82Om60uXmrmmau3XnV1z/eZxp7 CRnKw9M7nclt4xinb5M7g6wUOA4DdKeSXMOo0i3opOHpW1wwgxHagmQZdpSz6t0pBTuQ SthlMN1HKb+XgO2HgUvt5qWPyIOSRb1nt7KaPrWwYI5MogzIb+DuS0pXVoz+cPm8ER+2 tqALbFgMZFicsi0hdhjV/Hc+zu6MxBXtE5AswnDbyID3tcpRSZCuPERGCOY22nG0C3Pt a2qvhIKU8V9VtLdUZmJW6eBcxrBjrsxEO+dEJu8ZSI+TkXNkJWvmWzts7ANxMSe2n3gG k3+Q==
X-Gm-Message-State: APjAAAVNuHxXksBmmYyBZ0Uu8O8FlKwIEW1gDHxP21PYsmlpZtgQhpSG ckGFmhR8LsG+GO1mmscPrqBlFDGcq1oPJKXmfJL2Mhwe77s=
X-Google-Smtp-Source: APXvYqwq5UaGs+7HySFZBL51PoFuGQdfYAoiOFk/k52K4wVTvKHtnJY0u86gMfjMak3FsvOZvPFPVEDWbq5lta1F2S4=
X-Received: by 2002:a67:ef8d:: with SMTP id r13mr10184427vsp.6.1555943701309;  Mon, 22 Apr 2019 07:35:01 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 11:34:50 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000009b834405871f5f19"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 14:35:05 -0000

--0000000000009b834405871f5f19
Content-Type: text/plain; charset="UTF-8"

Hi Torsten,

Great article, thanks for sharing it.

We have been working on a solution for fine-grained authorization using
OAuth2 but specific for first-party applications where the granted
permissions/scopes depend on the policies associated with the
resources/scopes a client is trying to access. We don't have extensions to
the authorization endpoint but a specific grant type for this purpose on
the token endpoint.

The solution is similar to the Lodging Intent Pattern but also based on
specific parts of UMA and ACE.

Basically, when a client first tries to access a protected resource the RS
will respond with all the information the client needs to obtain a valid
token from the AS. The information returned by the RS can be a
signed/encrypted JWT or just a reference that later the AS can use to
actually fetch the information. With this information in hands, clients can
then approach the AS in order to obtain an access token with the
permissions to access the protected resource.

The general idea is to empower RSs so that they can communicate to the AS
how access to their resources should be granted as well as decoupling
clients and RSs so that clients don't need to know the constraints imposed
by the RS to their protected resources (e.g. scopes).

I've started to write a document with this idea in mind and I'm happy to
share it with you and see what you think.

Best regards.
Pedro Igor

On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
wrote:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Hi Tors=
ten,

Great article, thanks for=C2=A0sharing it.

We have been working on a solution for fine-grained author=
ization using OAuth2 but specific for first-party applications where the gr=
anted permissions/scopes depend on the policies associated with the resourc=
es/scopes a client is trying to access. We don't have extensions to the=
 authorization endpoint but a specific grant type for this purpose on the t=
oken endpoint.

The solution is similar to the=C2=
=A0Lodging Intent Pattern but also based on specific parts of UMA and ACE.<=
/div>

Basically, when a client first tries to access a p=
rotected resource the RS will respond with all the information the client n=
eeds to obtain a valid token from the AS. The information returned by the R=
S can be a signed/encrypted JWT or just a reference that later the AS can u=
se to actually fetch the information. With this information in hands, clien=
ts can then approach the AS in order to obtain an access token with the per=
missions to access the protected resource.

The gen=
eral idea is to empower RSs so that they can communicate to the AS how acce=
ss to their resources should be granted as well as decoupling clients and R=
Ss so that clients don't need to know the constraints imposed by the RS=
 to their protected resources (e.g. scopes).=C2=A0

I've started to write a document with this idea in mind and I'm ha=
ppy to share it with you and see what you think.

B=
est regards.
Pedro Igor

On Sat, Apr 20, 20=
19 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all, 



I just published an article about the subject at: https://medium.com/o=
auth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948=C2=A0 



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000009b834405871f5f19--


From nobody Mon Apr 22 08:39:14 2019
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 C0B381200F7 for ; Mon, 22 Apr 2019 08:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 pmAwAz3zprjV for ; Mon, 22 Apr 2019 08:39:05 -0700 (PDT)
Received: from mail-it1-x133.google.com (mail-it1-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 31729120052 for ; Mon, 22 Apr 2019 08:39:05 -0700 (PDT)
Received: by mail-it1-x133.google.com with SMTP id u65so18809015itc.2 for ; Mon, 22 Apr 2019 08:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UKjKQHZfCAqfmYF03S4KToU64qz0BXjUaDSTSaTVHuk=; b=LYseQtKvke0rHBqM/qoKOLGF/5pmhneXBQpE5iDYk3k9DzHkQ26xwy0HihR1yeM/zq rw83JZNOANj0bG8nCLeDcdoiD2rD/eevQuny6kY6jGmMK+Ys8bKTEOjecuMyfMYwPvMg ebvO1UkEY9/8FsssYle9rMc5BdRlg58+yX66E=
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=UKjKQHZfCAqfmYF03S4KToU64qz0BXjUaDSTSaTVHuk=; b=jy2/PNZPOetcbsclg18JAxB0tl+OJZ6QTHiHTTvk+xgFFrVj2rqZFhhQHe/Q9r0nb7 u08reyYSxo9a0T7wDQMUzh9p4CqXkWOJlLQ8yN+8iW4gYYsfy4n5hnmydeUN6nbcQPOL DVIfLfMAGYtACYQ1m4r8/sTN6ytbP4dMye/adYNgL1a1OmIdU18fLCbGeRVG/KO2fJjO XtisS9mI0zXnN0EaVPRKJ+x4I4cv1h13PIHMhbzNidPMSFFTfQm90sBDZIHfCxS3AYPZ IkQcKaxrgDjwVbvCctVAwNwSGKi1C2TivEElkV0F+nd2Y4brpu/4Fw+7AtFQC2bK+4EZ 0qug==
X-Gm-Message-State: APjAAAWZd3KZy+GvXZp/JqsRhisZ4hf4lSDdkrbxKpowA9ZzWWGkkYSh 6XfjjGUl03M3vO+hN+MYSeN78QKuZpxcy2RInime8eoZL4zxSMyNlrYrs0WS48KTwlflUcGFS5y stSbVvAsoMJbO+Q==
X-Google-Smtp-Source: APXvYqx0K/FipSfDYb6uiqyqnjgSCfjQ3vgJcc9ICCzwrPlCjL9VUzKYcmx+8shguJ7NARQvASuWT06dFOqwBJImbp0=
X-Received: by 2002:a24:6b4a:: with SMTP id v71mr13740038itc.174.1555947544323;  Mon, 22 Apr 2019 08:39:04 -0700 (PDT)
MIME-Version: 1.0
References: <87199072-428b-035b-8072-311735c08e6a@connect2id.com> 
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 22 Apr 2019 09:38:38 -0600
Message-ID: 
To: Thomas Broyer 
Cc: Vladimir Dzhuvinov , "" 
Content-Type: multipart/alternative; boundary="000000000000ab4d7f05872044e7"
Archived-At: 
Subject: Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 22 Apr 2019 15:39:08 -0000

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

My interpretation of RFC6749's =E2=80=9CRequest and response parameters MUS=
T NOT be
included more than once" is that it is applicable only to the parameters
defined therein. Which (conveniently but defensibly) allows for extensions
like resource indicators and token exchange to have multiple instances of a
parameter value without having to invent some new scheme to encode or
delimit multiple values.

On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer  wrote:

> RFC6749 makes it clear that =E2=80=9CRequest and response parameters MUST=
 NOT be
> included more than once.=E2=80=9D
> So:
>  * multi-valued request params shouldn't exist ("scope" is a single strin=
g
> value with a specific format, as a space-separated list of scopes)
>  * resource indicators draft violates RFC6749 by explicitly allowing
> multiple "resource" params; and RFC6749-compliant server is free to rejec=
t
> such a request with an invalid_request error, meaning that resource
> indicators breaks interoperability (clients can only send multi resource
> params to servers they know won't reject them with invalid_request as
> they're allowed to by RC6749).
> One could interpret that stance in RFC6749 as applying only to those
> params defined in this spec, but it's not explicitly said, so it could be
> interpreted as applying to any parameter, including extensions (like
> resource indicators) or unrecognized (and therefore ignored) parameters..
>
> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
> vladimir@connect2id.com> wrote:
>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>>
>> How should multi-valued request params be expressed in the JWT claims
>> set? As values in a JSON array?
>>
>>      {
>>       "iss": "s6BhdRkqt3",
>>       "aud": "https://server.example.com" ,
>>       "response_type": "code id_token",
>>       "client_id": "s6BhdRkqt3",
>>       "redirect_uri": "https://client.example.org/cb" ,
>>       "scope": "openid",
>>       "state": "af0ifjsldkj",
>>       "some-query-param": [ "val-1", "val-2" ]
>>      }
>>
>> Apart from custom params, the resource indicators spec also suggests tha=
t
>> such situations can occur:
>>
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#sect=
ion-2
>>
>> Thanks,
>>
>> Vladimir
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Thomas Broyer
> /t=C9=94.ma.b=CA=81wa.je/ 
> _______________________________________________
> 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._

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


My interpretation of RFC6749's =E2=80=9CRequest and re=
sponse parameters MUST NOT be included more than once" is that it is a=
pplicable only to the parameters defined therein. Which (conveniently but d=
efensibly) allows for extensions like resource indicators and token exchang=
e to have multiple instances of a parameter value without having to invent =
some new scheme to encode or delimit multiple values.=C2=A0 

<=
div class=3D"gmail_quote">
On Mon, Apr=
 22, 2019 at 7:52 AM Thomas Broyer <t.broyer@gmail.com> wrote:
RFC6749 makes it clea=
r that =E2=80=9CRequest and response parameters MUST NOT be included more t=
han once.=E2=80=9D
So:
=C2=A0* multi-valued request par=
ams shouldn't exist ("scope" is a single string value with a =
specific format, as a space-separated list of scopes)
=C2=A0* res=
ource indicators draft violates RFC6749 by explicitly allowing multiple &qu=
ot;resource" params; and RFC6749-compliant server is free to reject su=
ch a request with an invalid_request error, meaning that resource indicator=
s breaks interoperability (clients can only send multi resource params to s=
ervers they know won't reject them with invalid_request as they're =
allowed to by RC6749).
One could interpret that stance in RFC6749=
 as applying only to those params defined in this spec, but it's not ex=
plicitly said, so it could be interpreted as applying to any parameter, inc=
luding extensions (like resource indicators) or unrecognized (and therefore=
 ignored) parameters..

On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzh=
uvinov <vla=
dimir@connect2id.com> wrote:

 =20

   =20
 =20
  

    
https://tools.ietf.org/html/draft-ie=
tf-oauth-jwsreq-17#section-4

    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" =
]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.ietf.org/=
html/draft-ietf-oauth-resource-indicators-02#section-2

    

    
Thanks,

    
Vladimir

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




-- 
Thomas Broyer
/t<=
a href=3D"http://xn--nna.ma.xn--bwa-xxb.je/" target=3D"_blank">=C9=94.ma.b=
=CA=81wa.je/

_______________________________________________

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.
--000000000000ab4d7f05872044e7--


From nobody Mon Apr 22 08:53:31 2019
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 BE11E12011B for ; Mon, 22 Apr 2019 08:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zzObl1_SxUr for ; Mon, 22 Apr 2019 08:53:27 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 E9D5C120113 for ; Mon, 22 Apr 2019 08:53:26 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id f23so851619otl.9 for ; Mon, 22 Apr 2019 08:53:26 -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=kIFlpoiMXOr2qcGV3g+r3OpFdQSr970dINBUGCWZaJQ=; b=NNmORv24tsmPwGvr+M/nN+vTwvvePQ70Xsm2xSuwYYpR2z81zIyCARt8F+lAbm3iBB TV15oWyKfzR6FcfwtKNhA2YEcG1YzKu/i1El6NhCsRK/JEWtwMcywQV2R0F6DTEQzN6F NCMBifOnS7BLynYrl6c3iBs6hHSFqfD2l00Mp811IMYY1xwRpCNZLAprIR7O2Z1ldCxh 0b32bo3pU1mEbRzafxh6rFET79Mr1d5wEDzO1Qh0FvMS7EIkkXE+EtxMZKTaRNvXegAA sfRJLO5ApMhg5w4FJ+9leY7xCWvh1R81yUribJ/XR3+LR5y4LJ23vi21P2QSuc/4fDZl 9hng==
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=kIFlpoiMXOr2qcGV3g+r3OpFdQSr970dINBUGCWZaJQ=; b=h/a7fwQdslpcMgi2rdV/U3K0PMYkXB1bTF8CZaTJ3FSPOzEqX2Fq64TqAdAXqi01Em SDh/I8LrMV/crwvIPrA4PvmHL2i5c2IVt7Q69ksbBpQF+05ZV9BYVZb8FrPGUjmrFPVg Oid9ZNodFxdYS8o84axbEwNOpqek1Rj+53BMU2JLwv5V8jiSbzC3lbm7SpQI8Nekkw4B oRsIMy+7hH8Tu3hvhzSO/ANiuPov3byokQqsf5jpsquBsBvz+5wz5NouV8QhX7Fc8R7X zXy1kQ9AEWGdacNduDuOYMW57eblkE+kTAlTT75vGOC1qkhxsuDrtFKXffkzXdWbPH8m Bnqg==
X-Gm-Message-State: APjAAAWqRKWV0oDYojJAtQrqeCKV7nzzxHc6EgdDJQovWOzQ6rsdx4zD JT8lOqgG/7xAMmCrpqnYSBiY/NkCmsomkIZ1V7w=
X-Google-Smtp-Source: APXvYqwtkwsHRWtB3vWdV8P9hd9vXuyve6g88OPg0bG0JAWotO07GOvnnaYmmkRB5LMSpkxFt0jOsTi5m/F42ceVX5k=
X-Received: by 2002:a9d:7d95:: with SMTP id j21mr588212otn.141.1555948406019;  Mon, 22 Apr 2019 08:53:26 -0700 (PDT)
MIME-Version: 1.0
References: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>  
In-Reply-To: 
From: Thomas Broyer 
Date: Mon, 22 Apr 2019 17:53:14 +0200
Message-ID: 
To: Brian Campbell 
Cc: Vladimir Dzhuvinov , "" 
Content-Type: multipart/alternative; boundary="000000000000079b770587207857"
Archived-At: 
Subject: Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 22 Apr 2019 15:53:30 -0000

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

And the root issue is that it *is* subject to interpretation.

Parameters sent without a value MUST be treated as if they were
   omitted from the request.  The authorization server MUST ignore
   unrecognized request parameters.  Request and response parameters
   MUST NOT be included more than once.


The first sentence clearly applies to all parameters, whether recognized or=
 not.

It's unfortunately not clear to what the third applies, but BECAUSE it
can be understood as applying to unrecognized parameters as well, I
think it SHOULD be interpreted that way (until an errata clarifies the
situation)


Le lun. 22 avr. 2019 17:39, Brian Campbell  a
=C3=A9crit :

> My interpretation of RFC6749's =E2=80=9CRequest and response parameters M=
UST NOT
> be included more than once" is that it is applicable only to the paramete=
rs
> defined therein. Which (conveniently but defensibly) allows for extension=
s
> like resource indicators and token exchange to have multiple instances of=
 a
> parameter value without having to invent some new scheme to encode or
> delimit multiple values.
>
> On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer  wrote:
>
>> RFC6749 makes it clear that =E2=80=9CRequest and response parameters MUS=
T NOT be
>> included more than once.=E2=80=9D
>> So:
>>  * multi-valued request params shouldn't exist ("scope" is a single
>> string value with a specific format, as a space-separated list of scopes=
)
>>  * resource indicators draft violates RFC6749 by explicitly allowing
>> multiple "resource" params; and RFC6749-compliant server is free to reje=
ct
>> such a request with an invalid_request error, meaning that resource
>> indicators breaks interoperability (clients can only send multi resource
>> params to servers they know won't reject them with invalid_request as
>> they're allowed to by RC6749).
>> One could interpret that stance in RFC6749 as applying only to those
>> params defined in this spec, but it's not explicitly said, so it could b=
e
>> interpreted as applying to any parameter, including extensions (like
>> resource indicators) or unrecognized (and therefore ignored) parameters.=
.
>>
>> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>>>
>>> How should multi-valued request params be expressed in the JWT claims
>>> set? As values in a JSON array?
>>>
>>>      {
>>>       "iss": "s6BhdRkqt3",
>>>       "aud": "https://server.example.com" ,
>>>       "response_type": "code id_token",
>>>       "client_id": "s6BhdRkqt3",
>>>       "redirect_uri": "https://client.example.org/cb" ,
>>>       "scope": "openid",
>>>       "state": "af0ifjsldkj",
>>>       "some-query-param": [ "val-1", "val-2" ]
>>>      }
>>>
>>> Apart from custom params, the resource indicators spec also suggests
>>> that such situations can occur:
>>>
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#sec=
tion-2
>>>
>>> Thanks,
>>>
>>> Vladimir
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>> Thomas Broyer
>> /t=C9=94.ma.b=CA=81wa.je/ 
>> _______________________________________________
>> 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.*

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


And the root issue is that it *is* subject to interpretat=
ion.

Parameters sent without a value =
MUST be treated as if they were
   omitted from the request.  The authorization server MUST ignore
   unrecognized request parameters.  Request and response parameters
   MUST NOT be included more than once.

The first sentence clearly applies to all parameters, =
whether recognized or not.
It's unfortunately not clear to what the third applies, but BECAUS=
E it can be understood as applying to unrecognized parameters as well, I th=
ink it SHOULD be interpreted that way (until an errata clarifies the situat=
ion)

Le lun. 22 avr. 2019 17:39, Brian Campbell <bcampbell@pingidentity.com> a =C3=
=A9crit=C2=A0:
My =
interpretation of RFC6749's =E2=80=9CRequest and response parameters MU=
ST NOT be included more than once" is that it is applicable only to th=
e parameters defined therein. Which (conveniently but defensibly) allows fo=
r extensions like resource indicators and token exchange to have multiple i=
nstances of a parameter value without having to invent some new scheme to e=
ncode or delimit multiple values.=C2=A0 

On Mon, Apr 22, 2019 at 7:52 AM=
 Thomas Broyer <t.broyer@gmail.com> wrote:
RFC6=
749 makes it clear that =E2=80=9CRequest and response parameters MUST NOT b=
e included more than once.=E2=80=9D
So:
=C2=A0* multi-v=
alued request params shouldn't exist ("scope" is a single str=
ing value with a specific format, as a space-separated list of scopes)
=C2=A0* resource indicators draft violates RFC6749 by explicitly allo=
wing multiple "resource" params; and RFC6749-compliant server is =
free to reject such a request with an invalid_request error, meaning that r=
esource indicators breaks interoperability (clients can only send multi res=
ource params to servers they know won't reject them with invalid_reques=
t as they're allowed to by RC6749).
One could interpret that =
stance in RFC6749 as applying only to those params defined in this spec, bu=
t it's not explicitly said, so it could be interpreted as applying to a=
ny parameter, including extensions (like resource indicators) or unrecogniz=
ed (and therefore ignored) parameters..

On Mon, Apr 22, 2019 at 10:15 =
AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20

   =20
 =20
  

    
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https://serv=
er.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "=
https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" =
]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.ietf.org/html/draft-ietf-oauth-resource-indi=
cators-02#section-2

    

    
Thanks,

    
Vladimir

  


_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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




-- 
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/

_______________________________________________

OAuth mailing list

OAut=
h@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.


--000000000000079b770587207857--


From nobody Mon Apr 22 09:11:07 2019
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 AF8DE12009E for ; Mon, 22 Apr 2019 09:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.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 lFg444pxQZiW for ; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540F9120077 for ; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id t20so607802otl.5 for ; Mon, 22 Apr 2019 09:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7F40M1y7vwWpvCnocluvjoMFX9J3CZPFRiAzN7bwJR4=; b=lUqx+PZZS7iRcCf9cRN2Y9cQ8FKOBw9M0PgQ1hPVB0icDvfX6bXwGC3/rdYdmfXb1Y 6g1I0e+O7tEeBoa4XYsNQeVxkLyqgLnhyKYrqI0SXBmCBkGL/rb0/yQHqRAzHcBk1moz zPD5eV4PyjBDVJQz3MzsJBfe5vX4Xzk1D84Jn5Qv3k3C1viBc4MiFtKBp9vMiYlS6PTT QhCCTogcfCM3k1GzydgTPeV67NQNu15B+h4BNgeV9QhECIaSSPlsxJ31hixb0Z1GeMBU rvjYA5xqawwMXlFee1cdbGOY6wD28DFVR6mUGbmNWKEBzZHLfrbJMoKHenUKpixsbxqT rp7A==
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=7F40M1y7vwWpvCnocluvjoMFX9J3CZPFRiAzN7bwJR4=; b=UrcVpcWMZl7SW4xpAXpwbYrLJPJumt6Ga4dj2wWqfot+HcszFmWO/BlPudtbo6ZWWj 7VxzT72r7+6A+F+av7DOsNcM5wx5bKofqO3eXqfBnymmlBSG25A8b6GEHotcRO3zc3dN CcSYQeiVtA4+YhFz2G4ERwlM+zZeiQb3bzR4++JFzhCsHHXOcpHFh5ac7pJEGtU4zzEw 5PUmtHumhCaJ3xqxQZJyQRuBHSOtjj2NW2L1G5AuGo7BjIf5XqQVDx+iDFCqOaQg4nPN WQAVXuOUzZ3M23BK6AglU93jrtRwtQdhq51qZYZ4v+/ZT/vRV6aFJHZVKWtwiR4Q8f55 8p3A==
X-Gm-Message-State: APjAAAXBs9mG6n2dq3/oNPlLxiCnjf/qPpQ2PLZcmVYfgH0+MHUvENfl bw+wVn624lS75IAqiUQI6g2jEflZtmk=
X-Google-Smtp-Source: APXvYqy7z2ZWr9/y91iV1Nk3/U3X+BaYDzvmLZOQbIrCSh//tq6b0xX+ZgT22QmLn9LPzT0tTIFvGQ==
X-Received: by 2002:a9d:12a2:: with SMTP id g31mr13144593otg.174.1555949460987;  Mon, 22 Apr 2019 09:11:00 -0700 (PDT)
Received: from [10.233.85.132] (mobile-166-137-219-069.mycingular.net. [166.137.219.69]) by smtp.gmail.com with ESMTPSA id z12sm5622408otp.2.2019.04.22.09.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Apr 2019 09:10:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-63316A54-7CDB-47CD-8E9A-5BC0C3194676
Mime-Version: 1.0 (1.0)
From: Jim Manico 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: 
Date: Mon, 22 Apr 2019 11:10:58 -0500
Cc: Torsten Lodderstedt , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Pedro Igor Silva 
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:11:06 -0000

--Apple-Mail-63316A54-7CDB-47CD-8E9A-5BC0C3194676
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Have you looked at other standards that address find grained access control l=
ike NIST ABAC or XACML? This is a somewhat solved issue and I wonder if prev=
ious work can be leveraged.=20

A basic string =E2=80=9Cscope=E2=80=9D is certainly not enough to represent a=
nd transport complex authorization policy. I would imagine that something cl=
oser to XACML would work.

--
Jim Manico
@Manicode

> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  wrote:
>=20
> Hi Torsten,
>=20
> Great article, thanks for sharing it.
>=20
> We have been working on a solution for fine-grained authorization using OA=
uth2 but specific for first-party applications where the granted permissions=
/scopes depend on the policies associated with the resources/scopes a client=
 is trying to access. We don't have extensions to the authorization endpoint=
 but a specific grant type for this purpose on the token endpoint.
>=20
> The solution is similar to the Lodging Intent Pattern but also based on sp=
ecific parts of UMA and ACE.
>=20
> Basically, when a client first tries to access a protected resource the RS=
 will respond with all the information the client needs to obtain a valid to=
ken from the AS. The information returned by the RS can be a signed/encrypte=
d JWT or just a reference that later the AS can use to actually fetch the in=
formation. With this information in hands, clients can then approach the AS i=
n order to obtain an access token with the permissions to access the protect=
ed resource.
>=20
> The general idea is to empower RSs so that they can communicate to the AS h=
ow access to their resources should be granted as well as decoupling clients=
 and RSs so that clients don't need to know the constraints imposed by the R=
S to their protected resources (e.g. scopes).=20
>=20
> I've started to write a document with this idea in mind and I'm happy to s=
hare it with you and see what you think.
>=20
> Best regards.
> Pedro Igor
>=20
>> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt  wrote:
>> Hi all,=20
>>=20
>> I just published an article about the subject at: https://medium.com/oaut=
h-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2=
038948 =20
>>=20
>> I look forward to getting your feedback.
>>=20
>> kind regards,
>> 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-63316A54-7CDB-47CD-8E9A-5BC0C3194676
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Have you looked at other standards that add=
ress find grained access control like NIST ABAC or XACML? This is a somewhat=
 solved issue and I wonder if previous work can be leveraged. 

=

A basic string =E2=80=9Cscope=E2=80=9D is certainly not enough to=
 represent and transport complex authorization policy. I would imagine that s=
omething closer to XACML would work.

--
Jim Manico
@Manicode
Hi Torsten,

Great article, thanks for sharing i=
t.

We have been working on a solution for fine-grai=
ned authorization using OAuth2 but specific for first-party applications whe=
re the granted permissions/scopes depend on the policies associated with the=
 resources/scopes a client is trying to access. We don't have extensions to t=
he authorization endpoint but a specific grant type for this purpose on the t=
oken endpoint.

The solution is similar to the =
Lodging Intent Pattern but also based on specific parts of UMA and ACE.

Basically, when a client first tries to access a protec=
ted resource the RS will respond with all the information the client needs t=
o obtain a valid token from the AS. The information returned by the RS can b=
e a signed/encrypted JWT or just a reference that later the AS can use to ac=
tually fetch the information. With this information in hands, clients can th=
en approach the AS in order to obtain an access token with the permissions t=
o access the protected resource.

The general idea i=
s to empower RSs so that they can communicate to the AS how access to their r=
esources should be granted as well as decoupling clients and RSs so that cli=
ents don't need to know the constraints imposed by the RS to their protected=
 resources (e.g. scopes). 

I've started to wri=
te a document with this idea in mind and I'm happy to share it with you and s=
ee what you think.

Best regards.
Pedro Ig=
or

On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt=
 <torsten@lodderstedt.net=
> wrote:
Hi all=
, 



I just published an article about the subject at: https://medium.com/oau=
th-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e=
2038948  



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




________=
_______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.=
ietf.org/mailman/listinfo/oauth
=

--Apple-Mail-63316A54-7CDB-47CD-8E9A-5BC0C3194676--


From nobody Mon Apr 22 09:20:07 2019
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 B807A120132 for ; Mon, 22 Apr 2019 09:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWH_nYvK-5w4 for ; Mon, 22 Apr 2019 09:20:01 -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 7652B12012B for ; Mon, 22 Apr 2019 09:20:01 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id s7so9926686iom.12 for ; Mon, 22 Apr 2019 09:20:01 -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=9GzMFV0f3hkV+1Kf2am1kLVLcYySiJB7Y2LHpGZ6ZDQ=; b=QqWU1B40BUsdD5LocJm/dAmukbaAxvEIgTDlMKNAS8x3NwCvSi1cOljcq3D9OOtPzO aqguqxXzAw2J1KddafW/w3pE1irfiP5t8545efA0ki630CDjZTdUIN0Svd0vJEGRgiuK JQTgsaBLckH5FALpJUNpJ4Pp4xkmtqhSiif8vcRCyDC4wOxnViAPys1TCor4ZEdhJFrF 865e/z8VLFGO2YcwFpZ8k/teNnZzvppSGt2esP/BejN9JrD7RgkVW5l/S9bjYJ7TpOMI 6n++NRlqeFiPy9KyjUrtj82HfNcPRvtir09QqBPFks0Fg2xg7wq4hMXqUguEb95AZV1S WKBg==
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=9GzMFV0f3hkV+1Kf2am1kLVLcYySiJB7Y2LHpGZ6ZDQ=; b=ncBe5QCeh7aaCMx/ANUT+rudL+mTKCdOCHt2iw3Yof1AuCU9Io0FfgjoJVxvc6QkFb jmuJMpJhT55r2q60S+aIkZgVVJeQoeC6p37chh0TBqQJfzw1O37scGwg8IQrODBV9+JK m3eRgiSBUBSevKeO5cPhh78aTvHnxJXAwgxzUcCvDAJVskFBfbdDE4Np0OI7SRbAId0B WPTQ6yLzX+j22D8VUVDvaKUW+ALrxgmBy/DOyFO7K9WPotbuaKobAe9zYTND43+BhvKt xjvN2BWeUaRVJPehOnVIWlBSl9cbDj0IxrsckLe6+7a6giqHf7kP5nbM0Qj1ROtJSZdL LsIA==
X-Gm-Message-State: APjAAAVUJYHym9hRtYBha8BfhKbuCMlI2whxtsx6zC4W9eSaJ4KsAMkH duSr/YEPdGD7IjPreGTjjsnHAFUhq58ARryghwM=
X-Google-Smtp-Source: APXvYqxCBSB2BrYlGCGDiuz/XuJBvQ4k2vfxWb1/k+SC2t1simY1T8t/4KTWP61Ipy47Ek4DE/FEK1JUeCG5FF8C3vc=
X-Received: by 2002:a6b:f704:: with SMTP id k4mr14125674iog.0.1555950000758; Mon, 22 Apr 2019 09:20:00 -0700 (PDT)
MIME-Version: 1.0
References:     <47065036-68B7-4A21-864D-2D7DE23EF08F@aisec.fraunhofer.de>  <86A18436-0DD9-4269-A5E5-4279C269C55B@aisec.fraunhofer.de>
In-Reply-To: <86A18436-0DD9-4269-A5E5-4279C269C55B@aisec.fraunhofer.de>
From: Rifaat Shekh-Yusef 
Date: Mon, 22 Apr 2019 12:19:49 -0400
Message-ID: 
To: "Schanzenbach, Martin" 
Cc: Sascha Preibisch , IETF oauth WG 
Content-Type: multipart/alternative; boundary="000000000000156213058720d7a4"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:20:05 -0000

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

Thanks you all for your comments.

Based on this feedback, we think that there is good support for this to
become a WG document.


*Vittorio*,

Please, go ahead and submit a new WG draft.

Regards,
 Rifaat & Hannes



On Tue, Apr 16, 2019 at 4:13 AM Schanzenbach, Martin <
martin.schanzenbach@aisec.fraunhofer.de> wrote:

>
>
> > On 15. Apr 2019, at 18:20, Sascha Preibisch 
> wrote:
> >
> > Thanks, Martin!
> >
> > I understand. I just think it is difficult to get this adopted if
> > clients now have to include the target resource in their request in
> > order to place that into the 'aud' field. Unless the client has
> > somehow registered its intended protected resources beforehand the
> > authorization server cannot set an appropriate value if it was not
> > passed in as a request parameter.
>
> Yes, I think this is how it was supposed to work anyway even without JWTs=
.
> The client uses the "scope" parameter to indicate what it needs access to=
.
> The AS needs to make a decision in accordance with the RO what access
> token to issue (i.e. which RS to grant access to).
> The scope does not need to be the full RS URI. It is domain-specific what
> RSes a scope parameter maps to. Nothing the spec can do here, really.
>
> BR
> Martin
>
> >
> > Thanks,
> > Sascha
> >
> > Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin
> > :
> >>
> >>
> >>
> >>> On 10. Apr 2019, at 19:39, Sascha Preibisch 
> wrote:
> >>>
> >>> I am late in the game, but not too late I hope.
> >>>
> >>> I would like to see 'aud' be the requesting client_id. For identifyin=
g
> the the target resource, a 'resource' claim should be introduced. I am al=
so
> suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
> validation process will show if it is an access_token or not.
> >>
> >> "aud =3D client_id" would mean that, by definition, the JWT must not b=
e
> presented to any other entity than the client. This makes only sense for
> the ID Token in OIDC I think.  OTOH, defining a JWT which can be presente=
d
> by the client to the RS is the whole point of this draft.
> >> Also, the reason why it makes sense to introduce a new type is that an
> OIDC ID Token _could_ be mistaken for an AT (which it isn't).
> >> IMO it might even make sense to encourage the OIDC spec to change to
> jwt+id or something by extending the JWT spec.
> >>
> >> I also support the adoption.
> >>
> >>>
> >>> Last but not least, 'aud' (as resource identifier) should not be
> required. Requiring that, and the requested resource in the the token
> request, will require existing clients to be updated. Introducing jwt
> access_token should be transparent to clients.
> >>>
> >>> Thanks,
> >>> Sascha
> >>>
> >>>
> >>> On Wed., Apr. 10, 2019, 06:41 n-sakimura, 
> wrote:
> >>> +1
> >>>
> >>> For that matter, explicit typing is good and I am a bit ambivalent on
> the use of `sub`.
> >>>
> >>> Also, I need to add the 4th consideration: Although the current
> privacy consideration is stating about the encryption, it is in relation =
to
> the end user exposure. In fact, the by-value access token when involving
> some PII is by definition leaking information and violating the data
> minimization principle. This should be clearly delineated. My gut feeling
> is that it should be encrypted unless it is certain that it does not
> include sensitive PII as judging whether a claim may form a PII is too ha=
rd
> for an average developer..
> >>>
> >>> -----Original Message-----
> >>> From: OAuth  On Behalf Of Anthony Nadalin
> >>> Sent: Wednesday, April 10, 2019 8:12 PM
> >>> To: Hannes Tschofenig ; oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
> >>>
> >>> I support adoption of this draft as a working group document with the
> following caveats:
> >>>
> >>> 1. These are not to be used as ID Tokens/authentication tokens 2. The
> privacy issues must be addressed 3. Needs to be extensible, much like
> ID-Token, can't be 100% fixed
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: OAuth  On Behalf Of Hannes Tschofenig
> >>> Sent: Monday, April 8, 2019 10:07 AM
> >>> To: oauth@ietf.org
> >>> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
> >>>
> >>> Hi all,
> >>>
> >>> this is the call for adoption of the 'JWT Usage in OAuth2 Access
> Tokens'  document following the positive feedback at the last IETF meetin=
g
> in Prague.
> >>>
> >>> Here is the document:
> >>>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=3D02%7=
C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf=
86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=3DePmwaD%2F=
HCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=3D0
> >>>
> >>> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth worki=
ng
> group.
> >>>
> >>> Ciao
> >>> Hannes & Rifaat
> >>>
> >>> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>>
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Foauth&data=3D02%7C01%7Ctonynad%40microso=
ft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db4=
7%7C1%7C1%7C636903400616357060&sdata=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCoo=
DtlIUH7tS%2Fw%3D&reserved=3D0
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >> Martin Schanzenbach
> >> Fraunhofer AISEC
> >> Department Service & Application Security
> >> Parkring 4, 85748 Garching near Munich (Germany)
> >> Tel: +49 89 3229986-193
> >> martin.schanzenbach@aisec.fraunhofer.de
> >> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
> >>
>
>
> Martin Schanzenbach
> Fraunhofer AISEC
> Department Service & Application Security
> Parkring 4, 85748 Garching near Munich (Germany)
> Tel: +49 89 3229986-193
> martin.schanzenbach@aisec.fraunhofer.de
> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Thanks you all for your comments.

Based=
 on this feedback, we think that there is good support for this to become a=
 WG document.


Vittorio,

Please, go ahead and submit a new WG draft.
=

Regards,
=C2=A0Rifaat & Hannes

<=
/div>


On Tue, Apr 16, 2019 at 4:13 AM Schanzenbach, Martin &l=
t;martin.schanze=
nbach@aisec.fraunhofer.de> wrote:




> On 15. Apr 2019, at 18:20, Sascha Preibisch <saschapreibisch@gmail.com> =
wrote:

> 

> Thanks, Martin!

> 

> I understand. I just think it is difficult to get this adopted if

> clients now have to include the target resource in their request in
> order to place that into the 'aud' field. Unless the client ha=
s

> somehow registered its intended protected resources beforehand the

> authorization server cannot set an appropriate value if it was not

> passed in as a request parameter.



Yes, I think this is how it was supposed to work anyway even without JWTs. =
The client uses the "scope" parameter to indicate what it needs a=
ccess to.

The AS needs to make a decision in accordance with the RO what access token=
 to issue (i.e. which RS to grant access to).

The scope does not need to be the full RS URI. It is domain-specific what R=
Ses a scope parameter maps to. Nothing the spec can do here, really.



BR

Martin



> 

> Thanks,

> Sascha

> 

> Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin

> <martin.schanzenbach@aisec.fraunhofer.de>:

>> 

>> 

>> 

>>> On 10. Apr 2019, at 19:39, Sascha Preibisch <saschapreibisch@gmail.com<=
/a>> wrote:

>>> 

>>> I am late in the game, but not too late I hope.

>>> 

>>> I would like to see 'aud' be the requesting client_id.=
 For identifying the the target resource, a 'resource' claim should=
 be introduced. I am also suggesting to not introduce 'typ: at+jwt'=
. It is simply a jwt and the validation process will show if it is an acces=
s_token or not.

>> 

>> "aud =3D client_id" would mean that, by definition, the =
JWT must not be presented to any other entity than the client. This makes o=
nly sense for the ID Token in OIDC I think.=C2=A0 OTOH, defining a JWT whic=
h can be presented by the client to the RS is the whole point of this draft=
.

>> Also, the reason why it makes sense to introduce a new type is tha=
t an OIDC ID Token _could_ be mistaken for an AT (which it isn't).

>> IMO it might even make sense to encourage the OIDC spec to change =
to jwt+id or something by extending the JWT spec.

>> 

>> I also support the adoption.

>> 

>>> 

>>> Last but not least, 'aud' (as resource identifier) sho=
uld not be required. Requiring that, and the requested resource in the the =
token request, will require existing clients to be updated. Introducing jwt=
 access_token should be transparent to clients.

>>> 

>>> Thanks,

>>> Sascha

>>> 

>>> 

>>> On Wed., Apr. 10, 2019, 06:41 n-sakimura, <n-sakimura@nri.co.jp> wrot=
e:

>>> +1

>>> 

>>> For that matter, explicit typing is good and I am a bit ambiva=
lent on the use of `sub`.

>>> 

>>> Also, I need to add the 4th consideration: Although the curren=
t privacy consideration is stating about the encryption, it is in relation =
to the end user exposure. In fact, the by-value access token when involving=
 some PII is by definition leaking information and violating the data minim=
ization principle. This should be clearly delineated. My gut feeling is tha=
t it should be encrypted unless it is certain that it does not include sens=
itive PII as judging whether a claim may form a PII is too hard for an aver=
age developer..

>>> 

>>> -----Original Message-----

>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Anthony Nadalin
>>> Sent: Wednesday, April 10, 2019 8:12 PM

>>> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; oauth@ietf.org

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

>>> 

>>> I support adoption of this draft as a working group document w=
ith the following caveats:

>>> 

>>> 1. These are not to be used as ID Tokens/authentication tokens=
 2. The privacy issues must be addressed 3. Needs to be extensible, much li=
ke ID-Token, can't be 100% fixed

>>> 

>>> 

>>> -----Original Message-----

>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig=


>>> Sent: Monday, April 8, 2019 10:07 AM

>>> To: oauth@=
ietf.org

>>> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Acc=
ess Tokens

>>> 

>>> Hi all,

>>> 

>>> this is the call for adoption of the 'JWT Usage in OAuth2 =
Access Tokens'=C2=A0 document following the positive feedback at the la=
st IETF meeting in Prague.

>>> 

>>> Here is the document:

>>> https://nam06.saf=
elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2F=
draft-bertocci-oauth-access-token-jwt-00&amp;data=3D02%7C01%7Ctonynad%4=
0microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7=
cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=3DePmwaD%2FHCRZhRx%2Fw=
Zbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=3D0

>>> 

>>> Please let us know by April 22nd whether you accept / object t=
o the adoption of this document as a starting point for work in the OAuth w=
orking group.

>>> 

>>> Ciao

>>> Hannes & Rifaat

>>> 

>>> IMPORTANT NOTICE: The contents of this email and any attachmen=
ts are confidential and may also be privileged. If you are not the intended=
 recipient, please notify the sender immediately and do not disclose the co=
ntents to any other person, use it for any purpose, or store or copy the in=
formation in any medium. Thank you.

>>> 

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://nam06.safelinks.protection.outlook.c=
om/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;d=
ata=3D02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%=
7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&amp;sda=
ta=3Dzcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;reserved=3D0<=
/a>

>>> 

>>> _______________________________________________

>>> 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<=
/a>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

>> 

>> 

>> Martin Schanzenbach

>> Fraunhofer AISEC

>> Department Service & Application Security

>> Parkring 4, 85748 Garching near Munich (Germany)

>> Tel: +49 89 3229986-193

>> martin.schanzenbach@aisec.fraunhofer.de

>> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0

>> 





Martin Schanzenbach

Fraunhofer AISEC

Department Service & Application Security

Parkring 4, 85748 Garching near Munich (Germany)

Tel: +49 89 3229986-193

martin.schanzenbach@aisec.fraunhofer.de

GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000156213058720d7a4--


From nobody Mon Apr 22 09:29:21 2019
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 AC6C4120132 for ; Mon, 22 Apr 2019 09:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qDnMai6STept for ; Mon, 22 Apr 2019 09:29:18 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) (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 0A5C2120052 for ; Mon, 22 Apr 2019 09:29:17 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIbog-0008It-Nj; Mon, 22 Apr 2019 18:29:14 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Mon, 22 Apr 2019 18:29:13 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Steinar Noem 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:29:21 -0000

HI Steinar,

> On 22. Apr 2019, at 10:38, Steinar Noem  wrote:
>=20
> Hi Torsten, thank you for writing this clarifying article :)

Pleasure :-)

>=20
> In the health sector in Norway we are facing similar challenges =
regarding the need for contextual information.
> At the time, our planned solution is to package this information as =
custom claims in request objects - e.g.: =E2=80=9Chelse:client/claims/xxxx=
=E2=80=9D,

and do not forget: claims in a request object means you force your =
client and AS to turn on OpenID Connect for your requests (scope openid, =
ID Token, ...) even if you =E2=80=9Cjust=E2=80=9D want to authorise API =
access.=20

> but after reading your article I realize that the structured scope =
approach makes a lot more sense and, as you stated in the article, =
pushing the request objects mitigates the issues with request-size and =
complexity on the client side.
> In our case we may also have a requirement to encrypt the pushed =
request object due to potential sensitive content.

TLS is not enough?

kind regards,
Torsten.=20

>=20
> - Steinar
>=20
>=20
> l=C3=B8r. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt =
:
> Hi all,=20
>=20
> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20
>=20
> I look forward to getting your feedback.
>=20
> kind regards,
> Torsten.=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> --=20
> Vennlig hilsen
>=20
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
> =20
> | steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |=20=



From nobody Mon Apr 22 09:30:45 2019
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 1E7411200A0 for ; Mon, 22 Apr 2019 09:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXeIwMnFQwn0 for ; Mon, 22 Apr 2019 09:30:41 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-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 3F528120052 for ; Mon, 22 Apr 2019 09:30:41 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id k64so19073119itb.5 for ; Mon, 22 Apr 2019 09:30:41 -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=gJhL7kM9HbnwSy246oTP7XYNaFsPfJH1UrT4+cEBmWc=; b=S2FPEseIglDYqzL73UFsoD7ZwRl+WxQZUJz0HyFc6gs+PLmzDfYxzDDFnxIzsMO3Wh uEy0HCPUDa2eIiLx1f4HXHxHdR46gMMxv4OsaSLeAEvfykakP5YolpMqV/xew9ED7tH6 LnKt/6sZmL3bT9lf18SDGkaKLR/b1svPNf7te7M0lc2WxPTxseQUM4g5t/X5UMT9Mevf 4S/I0JJhSA44BapeNiQ/CsQLCL039pxVZsj/7t43nH2/vOOM2LfwVHUHkekg4h9O7WBd MBcPZWFKabXFfYmk6NZCqYitTrglXgkhooFJK0fK+l2jilp+gNI6u7oIC4RzdZQJua4o PRFg==
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=gJhL7kM9HbnwSy246oTP7XYNaFsPfJH1UrT4+cEBmWc=; b=O9yWaQUi3rruQ46PD8YyaU+gN4Q0310wMWV+Sh1PgsxSqSK0GOgAjLgad9h3yt4/ra t6wBySSG1d6vkVNDVZxTle+tfXwEdCZUeVElXxWE2cfJDuMqfQ9wf4bSUJBq2rI3F96i k/eRGAUz9b+QmGYm1PRUCdwXAgl2BYyE0T27dXVuS10MTZqO1d5oDxRuzGUBRtvuTv3R EbtBXyw/PYhgkXCZlZd5S+ab02u1mppQE1xd4lAPCD7tZfuAc1QttG2flvIpSoGfcBFj HwPm+IGe5d8xFAjfGad4yTyGH8jNZNIqBHNlhn5r2hal+1Nh4G1hxYCFoRzZqsIiNuhh Ii0w==
X-Gm-Message-State: APjAAAVm7fA3PE5hQ7Xf6wJdd27uWd0Cle1Z+A53TyZLZGk6YZV6qep8 L44pED08xEmWVCQtoAq9V7N3Mt2KyiFcwVaMXyQXDCkF
X-Google-Smtp-Source: APXvYqwZsFcOg6JypOmpDeAGMemkFRySjZkUvtd3WSxcQzN5qYwpwXW4cuse6APUE8w5uLVHn5of1aPjkj9KFtPtqUc=
X-Received: by 2002:a24:4614:: with SMTP id j20mr12851756itb.72.1555950640390;  Mon, 22 Apr 2019 09:30:40 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Mon, 22 Apr 2019 12:30:29 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000356d69058720fd4b"
Archived-At: 
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-jwt-introspection-response-02
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, 22 Apr 2019 16:30:43 -0000

--000000000000356d69058720fd4b
Content-Type: text/plain; charset="UTF-8"

All,

We have not received any comment during this WGLC, so we assume that WG
agrees with moving this forward.

Regards,
 Rifaat

On Mon, Apr 8, 2019 at 2:05 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> As discussed during the meeting in Prague, we are starting a WGLC on the *JWT
> Response for OAuth Token Introspection* document:
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
>
> Please, review the document and provide feedback on any issues you see
> with the document.
>
> The WGLC will end April 22nd, 2019.
>
> Regards,
>  Rifaat and Hannes
>

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


All,

We have not received an=
y comment during this WGLC, so we assume that WG agrees with moving this=C2=
=A0forward.

Regards,
=C2=A0Rifaat

On Mon, Apr 8, 2019 at 2:05 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

As discussed during the meeting in Pr=
ague, we are starting a WGLC on the JWT Response for OAuth Token Introsp=
ection document:
https://dat=
atracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

Please, review the document and provide feedback on an=
y issues you see with the document.

The WGLC will =
end April 22nd, 2019.

Regards,
=C2=A0Rif=
aat and Hannes




--000000000000356d69058720fd4b--


From nobody Mon Apr 22 09:33:58 2019
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 495D41200A0 for ; Mon, 22 Apr 2019 09:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pZMcSnIeIqcN for ; Mon, 22 Apr 2019 09:33:54 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524EE120129 for ; Mon, 22 Apr 2019 09:33:54 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIbt9-0000XU-H2; Mon, 22 Apr 2019 18:33:51 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Mon, 22 Apr 2019 18:33:50 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Pedro Igor Silva 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:33:56 -0000

Hi Pedro,

> On 22. Apr 2019, at 16:34, Pedro Igor Silva  wrote:
>=20
> Hi Torsten,
>=20
> Great article, thanks for sharing it.

my pleasure :-)

>=20
> We have been working on a solution for fine-grained authorization =
using OAuth2 but specific for first-party applications where the granted =
permissions/scopes depend on the policies associated with the =
resources/scopes a client is trying to access. We don't have extensions =
to the authorization endpoint but a specific grant type for this purpose =
on the token endpoint.
>=20
> The solution is similar to the Lodging Intent Pattern but also based =
on specific parts of UMA and ACE.
>=20
> Basically, when a client first tries to access a protected resource =
the RS will respond with all the information the client needs to obtain =
a valid token from the AS. The information returned by the RS can be a =
signed/encrypted JWT or just a reference that later the AS can use to =
actually fetch the information. With this information in hands, clients =
can then approach the AS in order to obtain an access token with the =
permissions to access the protected resource.
>=20
> The general idea is to empower RSs so that they can communicate to the =
AS how access to their resources should be granted as well as decoupling =
clients and RSs so that clients don't need to know the constraints =
imposed by the RS to their protected resources (e.g. scopes).=20

Sounds very much like UMA2. The difference I see is the RS needs to be =
heavily involved in the authorization process (whereas the approaches I =
discussed leave it passive). How would you handle the use cases I =
described? So for example, how would you construct the JWT for the =
signature use case? I=E2=80=99m asking because the signing case uses =
more data in the authorization process and might bundle the request to =
sign multiple documents, even if the first signing request would only =
need the hashes or even just a single hash of a document.=20

>=20
> I've started to write a document with this idea in mind and I'm happy =
to share it with you and see what you think.
>=20

Look forward to reading your article.=20

best regards,
Torsten.

> Best regards.
> Pedro Igor
>=20
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt =
 wrote:
> Hi all,=20
>=20
> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20
>=20
> I look forward to getting your feedback.
>=20
> kind regards,
> Torsten.=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Apr 22 09:35:37 2019
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 9784812006A for ; Mon, 22 Apr 2019 09:35:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t02habEuf14w for ; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 2CA16120052 for ; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
Received: by mail-vs1-f46.google.com with SMTP id o10so6544816vsp.12 for ; Mon, 22 Apr 2019 09:35:31 -0700 (PDT)
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=HWX2VLzW8+vPBaq4AStUPGNzvegrQ/STgh677g3s4j8=; b=hUAQwO5pg2tdK7jcEcknAjytb1i8Cv7ivD+PV+5cViZ/QfsNdYPCaJw7H6+pncURur XW76ChUo88O5r5hLhlItWwhpoWA1FGRJrTCefNDuYBaUkPfzuvqPQ8o/0g7pD168UtfD SpZTbAqjcjOBLlxJc4sWgIVrOEqOEhoqed0UfqjBLz/PWFRFJXbgpkvrpzsmhA+JoRyB 2hlzpjNkaF7QpKDbWGl529XnwKnJtgFzNjs+X3sGbW65Ez/5wAqBrxiIDCTj9AfM9HaI UlZyEjfiHh0RddbUwVSmFM7Gt/egKxp9945sChKRvHt05rN0/aq/nb8bwaLRJ+16/goE c6Aw==
X-Gm-Message-State: APjAAAXW69lmH5aB+HspEcs6nOALljqPoRkbvhaklEsGTGHADYK4/tYs 3oltcm47B+mUIjsd3xSQJzoR6ssl03WdLDhL7vKuaQ==
X-Google-Smtp-Source: APXvYqzTUdzjwC5cw/PPmuBTHKKQHmOCHG86eQHWGvQUMXbihgAEq+mXPt7IVlmh+6Yhr/9lMwBOi0AWEbV615I6Bu8=
X-Received: by 2002:a67:7b53:: with SMTP id w80mr10790913vsc.144.1555950929782;  Mon, 22 Apr 2019 09:35:29 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
In-Reply-To: <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 13:35:18 -0300
Message-ID: 
To: Jim Manico 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000754be70587210e16"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:35:36 -0000

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

Yeah, I did.

XACML is a good standard, even better after v3. We do have options to
leverage XACML policy language model to write policies, but protocol-wise,
something on top of OAuth, would be very nice. As an authorization
framework, fine-grained/contextual authorization seems to be a natural
addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM Jim Manico  wrote:

> Have you looked at other standards that address find grained access
> control like NIST ABAC or XACML? This is a somewhat solved issue and I
> wonder if previous work can be leveraged.
>
> A basic string =E2=80=9Cscope=E2=80=9D is certainly not enough to represe=
nt and transport
> complex authorization policy. I would imagine that something closer to
> XACML would work.
>
> --
> Jim Manico
> @Manicode
>
> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  wrote:
>
> Hi Torsten,
>
> Great article, thanks for sharing it.
>
> We have been working on a solution for fine-grained authorization using
> OAuth2 but specific for first-party applications where the granted
> permissions/scopes depend on the policies associated with the
> resources/scopes a client is trying to access. We don't have extensions t=
o
> the authorization endpoint but a specific grant type for this purpose on
> the token endpoint.
>
> The solution is similar to the Lodging Intent Pattern but also based on
> specific parts of UMA and ACE.
>
> Basically, when a client first tries to access a protected resource the R=
S
> will respond with all the information the client needs to obtain a valid
> token from the AS. The information returned by the RS can be a
> signed/encrypted JWT or just a reference that later the AS can use to
> actually fetch the information. With this information in hands, clients c=
an
> then approach the AS in order to obtain an access token with the
> permissions to access the protected resource.
>
> The general idea is to empower RSs so that they can communicate to the AS
> how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints impose=
d
> by the RS to their protected resources (e.g. scopes).
>
> I've started to write a document with this idea in mind and I'm happy to
> share it with you and see what you think.
>
> Best regards.
> Pedro Igor
>
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> torsten@lodderstedt.net > wrote:
>
>> Hi all,
>>
>> I just published an article about the subject at:
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-r=
e-think-oauth-scopes-2326e2038948
>> 
>>
>>
>> I look forward to getting your feedback.
>>
>> kind 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
>
>

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


Yeah, I did.

XACML is a good standard, =
even better after v3. We do have options to leverage XACML policy language =
model to write policies, but protocol-wise, something on top of OAuth, woul=
d be very nice. As an authorization framework, fine-grained/contextual auth=
orization seems to be a natural addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM Jim Man=
ico <jim@manicode.=
com> wrote:
Have you looked at other standards that address find g=
rained access control like NIST ABAC or XACML? This is a somewhat solved is=
sue and I wonder if previous work can be leveraged.=C2=A0

A basic string =E2=80=9Cscope=E2=80=9D is certainly not enough to represe=
nt and transport complex authorization policy. I would imagine that somethi=
ng closer to XACML would work.

--
Ji=
m Manico
@Manicode

On Apr 22, 201=
9, at 9:34 AM, Pedro Igor Silva <psilva@redhat.com> wrote:

Hi Torsten,

Great article, thanks=
 for=C2=A0sharing it.

We have been working on a so=
lution for fine-grained authorization using OAuth2 but specific for first-p=
arty applications where the granted permissions/scopes depend on the polici=
es associated with the resources/scopes a client is trying to access. We do=
n't have extensions to the authorization endpoint but a specific grant =
type for this purpose on the token endpoint.

The s=
olution is similar to the=C2=A0Lodging Intent Pattern but also based on spe=
cific parts of UMA and ACE.

Basically, when a clie=
nt first tries to access a protected resource the RS will respond with all =
the information the client needs to obtain a valid token from the AS. The i=
nformation returned by the RS can be a signed/encrypted JWT or just a refer=
ence that later the AS can use to actually fetch the information. With this=
 information in hands, clients can then approach the AS in order to obtain =
an access token with the permissions to access the protected resource.

The general idea is to empower RSs so that they can co=
mmunicate to the AS how access to their resources should be granted as well=
 as decoupling clients and RSs so that clients don't need to know the c=
onstraints imposed by the RS to their protected resources (e.g. scopes).=C2=
=A0

I've started to write a document with this=
 idea in mind and I'm happy to share it with you and see what you think=
.

Best regards.
Pedro Igor

On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.=
net> wrote:
Hi all, 



I just published an article about the subject at: https://medium.com/=
oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2=
326e2038948=C2=A0 



I look forward to getting your feedback.



kind 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=



--000000000000754be70587210e16--


From nobody Mon Apr 22 09:51:54 2019
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 E905D120122; Mon, 22 Apr 2019 09:51:51 -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.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <155595191187.21170.12146041222268036294@ietfa.amsl.com>
Date: Mon, 22 Apr 2019 09:51:51 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-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: Mon, 22 Apr 2019 16:51:52 -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-00.txt
	Pages           : 12
	Date            : 2019-04-22

Abstract:
   This specification defines a profile for issuing OAuth2 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-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-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 Mon Apr 22 09:58:42 2019
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 757EB120261 for ; Mon, 22 Apr 2019 09:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 zEHwY2aEhkI5 for ; Mon, 22 Apr 2019 09:58:26 -0700 (PDT)
Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (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 71755120091 for ; Mon, 22 Apr 2019 09:58:26 -0700 (PDT)
Received: by mail-vk1-f181.google.com with SMTP id q189so2534591vkq.11 for ; Mon, 22 Apr 2019 09:58:26 -0700 (PDT)
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=/cdjuO3zjjO8Nw9GiGqmTn6y5eSob/Bsjv2lFeEm2co=; b=kXgW+K3LBfmJTojBVnyGiI0Zr9QXNHaxbEha2iZbyM+h0T4ndBeWmhPqxBaEobsMuU gf/xoWUIDUT7KcVM7Q1o+TOiVgS0L0WQW4zmMZk+Ee8icr9aD5TBRR4i2xhAjsmQ2qZY L6AdfpUI2Yim8nlY5bKA3EtyhotGqe9qaTvoRhWtpJbjefkgRzHZu5u/rqupJqQ2s0Wm Hzs2EXCZO+xpNwCOj9lwZPMK/4H30LU6A9Sj5o4Ohsk4sMV5paTptw+zQ/rxLTa4lJPM OYm+37+je6FLXZX463hrHh4niFwq7nQP6vrIPHW/AOrTN2aTH09Djn8sncdFe/Qu7dwa +RPQ==
X-Gm-Message-State: APjAAAUPRvOV7RPnlQfUjF6zPMQxObfnj+SPHAo/GA4WKIDJOaRdv0wS OWlHj2od4fQN/Kr9U+83+UPQqwBKUjslx++3s3Pgtg==
X-Google-Smtp-Source: APXvYqxCbhmXpFgo68ofpoVGD58fTfbQvMcMHg7Akf3E6UvGtsMNRr1EFYs+/hnWei6z9M54DVw/7uz79DfS6e1Qsao=
X-Received: by 2002:ac5:cac5:: with SMTP id m5mr10430498vkl.50.1555952305291;  Mon, 22 Apr 2019 09:58:25 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>
In-Reply-To: <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 13:58:14 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000071e53105872160c6"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 16:58:33 -0000

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

On Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> > On 22. Apr 2019, at 16:34, Pedro Igor Silva  wrote:
> >
> > Hi Torsten,
> >
> > Great article, thanks for sharing it.
>
> my pleasure :-)
>
> >
> > We have been working on a solution for fine-grained authorization using
> OAuth2 but specific for first-party applications where the granted
> permissions/scopes depend on the policies associated with the
> resources/scopes a client is trying to access. We don't have extensions t=
o
> the authorization endpoint but a specific grant type for this purpose on
> the token endpoint.
> >
> > The solution is similar to the Lodging Intent Pattern but also based on
> specific parts of UMA and ACE.
> >
> > Basically, when a client first tries to access a protected resource the
> RS will respond with all the information the client needs to obtain a val=
id
> token from the AS. The information returned by the RS can be a
> signed/encrypted JWT or just a reference that later the AS can use to
> actually fetch the information. With this information in hands, clients c=
an
> then approach the AS in order to obtain an access token with the
> permissions to access the protected resource.
> >
> > The general idea is to empower RSs so that they can communicate to the
> AS how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints impose=
d
> by the RS to their protected resources (e.g. scopes).
>
> Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I=E2=80=99m asking because the signing case uses more=
 data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes o=
r
> even just a single hash of a document.
>

Yes, it does. Like I mentioned, the model is based on UMA (Permission
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
talked with UMA WG in the past about this solution and how we extended the
specs to solve this type of problem.

By being active during the authorization process the RS is in control over
additional claims that should be considered by the policies when making
decisions about the resources/scopes a client/user can access. Where the
information could be obtained from different sources such as the current
HTTP request or internally/externally to the RS.

We did not have much demand for addressing the signature use case, but use
cases similar to the "payment" use case. As I mentioned, the model I'm
talking about is not based on user consent. But considering that you can
also pass any information to the AS, you should be able to let users to
authorize the creation of signatures for one or more documents.


>
> >
> > I've started to write a document with this idea in mind and I'm happy t=
o
> share it with you and see what you think.
> >
>
> Look forward to reading your article.
>
> best regards,
> Torsten.
>
> > Best regards.
> > Pedro Igor
> >
> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> > Hi all,
> >
> > I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
> >
> > I look forward to getting your feedback.
> >
> > kind regards,
> > Torsten.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>

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




On =
Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pedro,



> On 22. Apr 2019, at 16:34, Pedro Igor Silva <psilva@redhat.com> wrote:

> 

> Hi Torsten,

> 

> Great article, thanks for sharing it.



my pleasure :-)



> 

> We have been working on a solution for fine-grained authorization usin=
g OAuth2 but specific for first-party applications where the granted permis=
sions/scopes depend on the policies associated with the resources/scopes a =
client is trying to access. We don't have extensions to the authorizati=
on endpoint but a specific grant type for this purpose on the token endpoin=
t.

> 

> The solution is similar to the Lodging Intent Pattern but also based o=
n specific parts of UMA and ACE.

> 

> Basically, when a client first tries to access a protected resource th=
e RS will respond with all the information the client needs to obtain a val=
id token from the AS. The information returned by the RS can be a signed/en=
crypted JWT or just a reference that later the AS can use to actually fetch=
 the information. With this information in hands, clients can then approach=
 the AS in order to obtain an access token with the permissions to access t=
he protected resource.

> 

> The general idea is to empower RSs so that they can communicate to the=
 AS how access to their resources should be granted as well as decoupling c=
lients and RSs so that clients don't need to know the constraints impos=
ed by the RS to their protected resources (e.g. scopes). 



Sounds very much like UMA2. The difference I see is the RS needs to be heav=
ily involved in the authorization process (whereas the approaches I discuss=
ed leave it passive). How would you handle the use cases I described? So fo=
r example, how would you construct the JWT for the signature use case? I=E2=
=80=99m asking because the signing case uses more data in the authorization=
 process and might bundle the request to sign multiple documents, even if t=
he first signing request would only need the hashes or even just a single h=
ash of a document. 

Yes, it does. Like =
I mentioned, the model is based on UMA (Permission Ticket/API) as well as A=
CE (Unauthorized Resource Request Message). I had talked with UMA WG in the=
 past about this solution and how we extended the specs to solve this type =
of problem.

By being active during the authorizati=
on process the RS is in control over additional claims that should be consi=
dered by the policies when making decisions about the resources/scopes a cl=
ient/user can access. Where the information could be obtained from differen=
t sources such as the current HTTP request or internally/externally to the =
RS.

We did not have much demand for addressing the=
 signature use case, but use cases similar to the "payment" use c=
ase. As I mentioned, the model I'm talking about is not based on user c=
onsent. But considering that you can also pass any information to the AS, y=
ou should be able to let users to authorize the creation of signatures for =
one or more documents.
=C2=A0



> 

> I've started to write a document with this idea in mind and I'=
m happy to share it with you and see what you think.

> 



Look forward to reading your article. 



best regards,

Torsten.



> Best regards.

> Pedro Igor

> 

> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.net&=
gt; wrote:

> Hi all, 

> 

> I just published an article about the subject at: https://medium.=
com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scop=
es-2326e2038948=C2=A0 

> 

> I look forward to getting your feedback.

> 

> kind regards,

> Torsten. 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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






--00000000000071e53105872160c6--


From nobody Mon Apr 22 10:18:45 2019
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 4B09C1200CC for ; Mon, 22 Apr 2019 10:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 S3ew-Y1ZSA94 for ; Mon, 22 Apr 2019 10:18:40 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (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 A1F8C120052 for ; Mon, 22 Apr 2019 10:18:40 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIcaT-0001qk-BP; Mon, 22 Apr 2019 19:18:37 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Mon, 22 Apr 2019 19:18:36 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net> 
To: Pedro Igor Silva 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 17:18:43 -0000

Hi Pedro,

>=20
> > The general idea is to empower RSs so that they can communicate to =
the AS how access to their resources should be granted as well as =
decoupling clients and RSs so that clients don't need to know the =
constraints imposed by the RS to their protected resources (e.g. =
scopes).=20
>=20
> Sounds very much like UMA2. The difference I see is the RS needs to be =
heavily involved in the authorization process (whereas the approaches I =
discussed leave it passive). How would you handle the use cases I =
described? So for example, how would you construct the JWT for the =
signature use case? I=E2=80=99m asking because the signing case uses =
more data in the authorization process and might bundle the request to =
sign multiple documents, even if the first signing request would only =
need the hashes or even just a single hash of a document.=20
>=20
> Yes, it does. Like I mentioned, the model is based on UMA (Permission =
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I =
had talked with UMA WG in the past about this solution and how we =
extended the specs to solve this type of problem.
>=20
> By being active during the authorization process the RS is in control =
over additional claims that should be considered by the policies when =
making decisions about the resources/scopes a client/user can access. =
Where the information could be obtained from different sources such as =
the current HTTP request or internally/externally to the RS.

The problem from my perspective (and my understanding of UMA) is the RS =
does not have any information about the context of the request. For =
example, the client might be calling a certain resource (list of =
accounts) and immediately afterwards wants to obtain the balances and =
initiate a payment. I think the UMA case the RS either predicts this =
based on policy or past behaviour of the client OR the client will need =
to issue several token requests. That might not be a problem in 1st =
party scenarios but it is in 3rd party scenarios if the AS gathers =
consent.=20

>=20
> We did not have much demand for addressing the signature use case, but =
use cases similar to the "payment" use case. As I mentioned, the model =
I'm talking about is not based on user consent.

Right, you mentioned it is intended to be used for 1st parties only.=20

> But considering that you can also pass any information to the AS, you =
should be able to let users to authorize the creation of signatures for =
one or more documents.

I think the client needs to pass this information, which brings us back =
to the original question of my article.=20

best regards.=20
Torsten.=20

> =20
>=20
> >=20
> > I've started to write a document with this idea in mind and I'm =
happy to share it with you and see what you think.
> >=20
>=20
> Look forward to reading your article.=20
>=20
> best regards,
> Torsten.
>=20
> > Best regards.
> > Pedro Igor
> >=20
> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt =
 wrote:
> > Hi all,=20
> >=20
> > I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20
> >=20
> > I look forward to getting your feedback.
> >=20
> > kind regards,
> > Torsten.=20
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Mon Apr 22 10:31:11 2019
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 1E1C0120108 for ; Mon, 22 Apr 2019 10:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 f6fWuMjyPS9e for ; Mon, 22 Apr 2019 10:31:06 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (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 26275120044 for ; Mon, 22 Apr 2019 10:31:06 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIcmT-0007h8-VA; Mon, 22 Apr 2019 19:31:01 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
Date: Mon, 22 Apr 2019 19:31:00 +0200
Cc: Pedro Igor Silva , oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DD843A8-403B-4833-9C4C-B05BEAD68571@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <981DFB7E-4EA6-4C66-8B78-F6FE3AC2B712@manicode.com>
To: Jim Manico 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 17:31:09 -0000

Hi Jim,=20

thanks for pointing this out.=20

Basically, what I=E2=80=99m proposing is not a new language for =
describing authorization policies. It=E2=80=99s more like the container =
to carry the data needed to inform the user about the intention of the =
client to the authorisation server. This container may contain anything =
- preferable expressed as JSON :-). But let=E2=80=99s ignore this for a =
moment.=20

As OAuth is about delegating access rights to a client, the question is =
whether XAML could express delegation as well. If that=E2=80=99s the =
case and the AS maintains the permissions of its users as XAML policy =
one could potentially express the requested permissions as a subset of =
the users permissions.=20

In the (consumer) use cases I=E2=80=99m typically dealing with, the =
user=E2=80=99s permission is determined by possession. So a user is in =
possession of an email account because it signed up for that service =
(and potentially pays for it). My feeling is XAML is more targeted =
towards enterprise use cases.=20

best regards,
Torsten.=20

> On 22. Apr 2019, at 18:10, Jim Manico  wrote:
>=20
> Have you looked at other standards that address find grained access =
control like NIST ABAC or XACML? This is a somewhat solved issue and I =
wonder if previous work can be leveraged.=20
>=20
> A basic string =E2=80=9Cscope=E2=80=9D is certainly not enough to =
represent and transport complex authorization policy. I would imagine =
that something closer to XACML would work.
>=20
> --
> Jim Manico
> @Manicode
>=20
> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  =
wrote:
>=20
>> Hi Torsten,
>>=20
>> Great article, thanks for sharing it.
>>=20
>> We have been working on a solution for fine-grained authorization =
using OAuth2 but specific for first-party applications where the granted =
permissions/scopes depend on the policies associated with the =
resources/scopes a client is trying to access. We don't have extensions =
to the authorization endpoint but a specific grant type for this purpose =
on the token endpoint.
>>=20
>> The solution is similar to the Lodging Intent Pattern but also based =
on specific parts of UMA and ACE.
>>=20
>> Basically, when a client first tries to access a protected resource =
the RS will respond with all the information the client needs to obtain =
a valid token from the AS. The information returned by the RS can be a =
signed/encrypted JWT or just a reference that later the AS can use to =
actually fetch the information. With this information in hands, clients =
can then approach the AS in order to obtain an access token with the =
permissions to access the protected resource.
>>=20
>> The general idea is to empower RSs so that they can communicate to =
the AS how access to their resources should be granted as well as =
decoupling clients and RSs so that clients don't need to know the =
constraints imposed by the RS to their protected resources (e.g. =
scopes).=20
>>=20
>> I've started to write a document with this idea in mind and I'm happy =
to share it with you and see what you think.
>>=20
>> Best regards.
>> Pedro Igor
>>=20
>> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt =
 wrote:
>> Hi all,=20
>>=20
>> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20
>>=20
>> I look forward to getting your feedback.
>>=20
>> kind regards,
>> 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


From nobody Mon Apr 22 10:51:45 2019
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 5F2B8120272 for ; Mon, 22 Apr 2019 10:51:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ip3ju464jmiQ for ; Mon, 22 Apr 2019 10:51:41 -0700 (PDT)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 DD8CB12012C for ; Mon, 22 Apr 2019 10:51:40 -0700 (PDT)
Received: by mail-vs1-f44.google.com with SMTP id t23so6686388vso.10 for ; Mon, 22 Apr 2019 10:51:40 -0700 (PDT)
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=zJ2SYtc7iFSrLoEUmpx6m9gsiBv9baih3ODKZSixgE4=; b=rZanUEbJvhokVk27nSAUcdrsKY6Z69w2vL6qCmzgrMcXukCNStuM4t2Q5v0a8KoWdd vGcPx6kdI2b1Z98hsHIIMI22oyg/84r7CPxDdmRC4f2p0+Oo4VJGJNkicgb3Tm3Jd75q x6Sd1qIUA+tRAulFoVzWzY4uZvsJ4eAEoUGsmGPhaQyG64JG27q0hur4Pjt7JdaqK5Qy yQCDj3dTULs5D2vlTvl8n7ky2lHDoX4KdPntQ00Bhu2KcYitcmcOaUzxvPQ7fh8oi6z1 YTDRDUP36kpt74kbg4cF4CV8HAJw/J50rptFSA1m2yGeIkmUweOVKwBNCmKhsvvyJnAL GOWA==
X-Gm-Message-State: APjAAAU35yGgM5EIbm/IUtVTB0Po6HV8dOFGk448WdLQnlqHLWjClRRh EcxE7VF5dFSqxuw0XYjzyMJC+2Joqhp1POVa2g0Avhb3FAU=
X-Google-Smtp-Source: APXvYqx+pDqHLdNtHOR6FbOMP/GPoFsGo14UPLDLy8tCZW7SLneIrI6tJaGUm07KpzLRV2tRoKp64rp5KHps0XuhMAE=
X-Received: by 2002:a67:7b53:: with SMTP id w80mr11030071vsc.144.1555955499711;  Mon, 22 Apr 2019 10:51:39 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>  
In-Reply-To: 
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 14:51:28 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000d8e5500587221eec"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 17:51:44 -0000

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

On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> >
> > > The general idea is to empower RSs so that they can communicate to th=
e
> AS how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints impose=
d
> by the RS to their protected resources (e.g. scopes).
> >
> > Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I=E2=80=99m asking because the signing case uses more=
 data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes o=
r
> even just a single hash of a document.
> >
> > Yes, it does. Like I mentioned, the model is based on UMA (Permission
> Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
> talked with UMA WG in the past about this solution and how we extended th=
e
> specs to solve this type of problem.
> >
> > By being active during the authorization process the RS is in control
> over additional claims that should be considered by the policies when
> making decisions about the resources/scopes a client/user can access. Whe=
re
> the information could be obtained from different sources such as the
> current HTTP request or internally/externally to the RS.
>
> The problem from my perspective (and my understanding of UMA) is the RS
> does not have any information about the context of the request. For
> example, the client might be calling a certain resource (list of accounts=
)
> and immediately afterwards wants to obtain the balances and initiate a
> payment. I think the UMA case the RS either predicts this based on policy
> or past behaviour of the client OR the client will need to issue several
> token requests. That might not be a problem in 1st party scenarios but it
> is in 3rd party scenarios if the AS gathers consent.
>

Yeah, we are talking about different use cases. But they are still quite
related in regards to enriching authorization decisions. it would be nice
to have something in OAuth that could address both 1st and 3rd party use
cases. As I said before, the model I'm talking about is kind of a 1st party
Lodging_Intent.

Just to clarify, UMA does not cover the scenario I'm talking about although
it provides a very good ground for extensions like this. It is not part of
UMA scope. It provides much more than that too ...


>
> >
> > We did not have much demand for addressing the signature use case, but
> use cases similar to the "payment" use case. As I mentioned, the model I'=
m
> talking about is not based on user consent.
>
> Right, you mentioned it is intended to be used for 1st parties only.
>
> > But considering that you can also pass any information to the AS, you
> should be able to let users to authorize the creation of signatures for o=
ne
> or more documents.
>
> I think the client needs to pass this information, which brings us back t=
o
> the original question of my article.
>
> best regards.
> Torsten.
>
> >
> >
> > >
> > > I've started to write a document with this idea in mind and I'm happy
> to share it with you and see what you think.
> > >
> >
> > Look forward to reading your article.
> >
> > best regards,
> > Torsten.
> >
> > > Best regards.
> > > Pedro Igor
> > >
> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> > > Hi all,
> > >
> > > I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
> > >
> > > I look forward to getting your feedback.
> > >
> > > kind regards,
> > > Torsten.
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>

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




On Mon, Apr 22, 2019=
 at 2:18 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pedro,



> 

> > The general idea is to empower RSs so that they can communicate t=
o the AS how access to their resources should be granted as well as decoupl=
ing clients and RSs so that clients don't need to know the constraints =
imposed by the RS to their protected resources (e.g. scopes). 

> 

> Sounds very much like UMA2. The difference I see is the RS needs to be=
 heavily involved in the authorization process (whereas the approaches I di=
scussed leave it passive). How would you handle the use cases I described? =
So for example, how would you construct the JWT for the signature use case?=
 I=E2=80=99m asking because the signing case uses more data in the authoriz=
ation process and might bundle the request to sign multiple documents, even=
 if the first signing request would only need the hashes or even just a sin=
gle hash of a document. 

> 

> Yes, it does. Like I mentioned, the model is based on UMA (Permission =
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had t=
alked with UMA WG in the past about this solution and how we extended the s=
pecs to solve this type of problem.

> 

> By being active during the authorization process the RS is in control =
over additional claims that should be considered by the policies when makin=
g decisions about the resources/scopes a client/user can access. Where the =
information could be obtained from different sources such as the current HT=
TP request or internally/externally to the RS.



The problem from my perspective (and my understanding of UMA) is the RS doe=
s not have any information about the context of the request. For example, t=
he client might be calling a certain resource (list of accounts) and immedi=
ately afterwards wants to obtain the balances and initiate a payment. I thi=
nk the UMA case the RS either predicts this based on policy or past behavio=
ur of the client OR the client will need to issue several token requests. T=
hat might not be a problem in 1st party scenarios but it is in 3rd party sc=
enarios if the AS gathers consent. 

Yea=
h, we are talking about different use cases. But they are still quite relat=
ed in regards to enriching authorization decisions. it would be nice to hav=
e something in OAuth that could address both 1st and 3rd party use cases. A=
s I said before, the model I'm talking about is kind of a 1st party Lod=
ging_Intent.

Just to clarify, UMA does not cover t=
he scenario I'm talking about although it provides a very good ground f=
or extensions like this. It is not part of UMA scope. It provides much more=
 than that too ...
=C2=A0



> 

> We did not have much demand for addressing the signature use case, but=
 use cases similar to the "payment" use case. As I mentioned, the=
 model I'm talking about is not based on user consent.



Right, you mentioned it is intended to be used for 1st parties only. 



> But considering that you can also pass any information to the AS, you =
should be able to let users to authorize the creation of signatures for one=
 or more documents.



I think the client needs to pass this information, which brings us back to =
the original question of my article. 



best regards. 

Torsten. 



>=C2=A0 

> 

> > 

> > I've started to write a document with this idea in mind and I=
'm happy to share it with you and see what you think.

> > 

> 

> Look forward to reading your article. 

> 

> best regards,

> Torsten.

> 

> > Best regards.

> > Pedro Igor

> > 

> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.n=
et> wrote:

> > Hi all, 

> > 

> > I just published an article about the subject at: https://me=
dium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth=
-scopes-2326e2038948=C2=A0 

> > 

> > I look forward to getting your feedback.

> > 

> > kind regards,

> > Torsten. 

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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


> 






--000000000000d8e5500587221eec--


From nobody Mon Apr 22 10:54:41 2019
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 95C8E12012C for ; Mon, 22 Apr 2019 10:54:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 f1kV8Kh1kgtO for ; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (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 6D289120128 for ; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
Received: by mail-ua1-f41.google.com with SMTP id l17so3862750uar.4 for ; Mon, 22 Apr 2019 10:54:37 -0700 (PDT)
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=yna0lhrJfcWLRb7FyB6+9LjNA8EtnitkHVQN3/TWmBo=; b=uQUvJxU4k6YejxhUGCkrKcDLcwRKCUpEQ8YTu281qRXmHCzbOIM9wURLzqk7OQYz1P 9bH1O0bwdpGR35Z7WWC2dl1AED77fQ5MVV8l5kKj3D2tASV5W8NI3IogfLUwKdHYQMc8 3PNwhM2toMjJvdgOakxxtMfee3wdahIzFHXp5upGt4Ok2VIdjsUMaW6HSrwbNjg5uNkZ EMWID2FRPlNIe6Tshr5bMv6Ya20ZiH7CwFFSw0eKUl65hZ4HLXWC4s9QWqK8rQrFjdqA 2haphQoVcXe1O2ACmuiwpfY6gblNgOw23b14sTEaZvZXq908Fi5StZBI8q9jxCpQA+1w tYZg==
X-Gm-Message-State: APjAAAUR8/7npIcCZIuHU9Kf0yVYLYbdTSek09fYo6/yDctZtbEdPZ+i R48uaxabv38OMIS3bCt29CZdep7vgE9UFJhtzJWZwIvr
X-Google-Smtp-Source: APXvYqx6Bt6nXp5NT4k2/p1TU25ChhitYHNCsyeDqfJJY6CO2bccSa66e/kXRo/gF2WL7Z+Q1Yh5Dgo7CyTZLscgKiE=
X-Received: by 2002:ab0:6803:: with SMTP id z3mr1171645uar.87.1555955676308; Mon, 22 Apr 2019 10:54:36 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>   
In-Reply-To: 
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 14:54:25 -0300
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000005f843905872229f5"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 17:54:41 -0000

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

Sorry. I mean, UMA provides much more than this 1st party authorization
flow I'm talking about ....

On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva  wrote:

>
>
> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi Pedro,
>>
>> >
>> > > The general idea is to empower RSs so that they can communicate to
>> the AS how access to their resources should be granted as well as
>> decoupling clients and RSs so that clients don't need to know the
>> constraints imposed by the RS to their protected resources (e.g. scopes)=
.
>> >
>> > Sounds very much like UMA2. The difference I see is the RS needs to be
>> heavily involved in the authorization process (whereas the approaches I
>> discussed leave it passive). How would you handle the use cases I
>> described? So for example, how would you construct the JWT for the
>> signature use case? I=E2=80=99m asking because the signing case uses mor=
e data in
>> the authorization process and might bundle the request to sign multiple
>> documents, even if the first signing request would only need the hashes =
or
>> even just a single hash of a document.
>> >
>> > Yes, it does. Like I mentioned, the model is based on UMA (Permission
>> Ticket/API) as well as ACE (Unauthorized Resource Request Message). I ha=
d
>> talked with UMA WG in the past about this solution and how we extended t=
he
>> specs to solve this type of problem.
>> >
>> > By being active during the authorization process the RS is in control
>> over additional claims that should be considered by the policies when
>> making decisions about the resources/scopes a client/user can access. Wh=
ere
>> the information could be obtained from different sources such as the
>> current HTTP request or internally/externally to the RS.
>>
>> The problem from my perspective (and my understanding of UMA) is the RS
>> does not have any information about the context of the request. For
>> example, the client might be calling a certain resource (list of account=
s)
>> and immediately afterwards wants to obtain the balances and initiate a
>> payment. I think the UMA case the RS either predicts this based on polic=
y
>> or past behaviour of the client OR the client will need to issue several
>> token requests. That might not be a problem in 1st party scenarios but i=
t
>> is in 3rd party scenarios if the AS gathers consent.
>>
>
> Yeah, we are talking about different use cases. But they are still quite
> related in regards to enriching authorization decisions. it would be nice
> to have something in OAuth that could address both 1st and 3rd party use
> cases. As I said before, the model I'm talking about is kind of a 1st par=
ty
> Lodging_Intent.
>
> Just to clarify, UMA does not cover the scenario I'm talking about
> although it provides a very good ground for extensions like this. It is n=
ot
> part of UMA scope. It provides much more than that too ...
>
>
>>
>> >
>> > We did not have much demand for addressing the signature use case, but
>> use cases similar to the "payment" use case. As I mentioned, the model I=
'm
>> talking about is not based on user consent.
>>
>> Right, you mentioned it is intended to be used for 1st parties only.
>>
>> > But considering that you can also pass any information to the AS, you
>> should be able to let users to authorize the creation of signatures for =
one
>> or more documents.
>>
>> I think the client needs to pass this information, which brings us back
>> to the original question of my article.
>>
>> best regards.
>> Torsten.
>>
>> >
>> >
>> > >
>> > > I've started to write a document with this idea in mind and I'm happ=
y
>> to share it with you and see what you think.
>> > >
>> >
>> > Look forward to reading your article.
>> >
>> > best regards,
>> > Torsten.
>> >
>> > > Best regards.
>> > > Pedro Igor
>> > >
>> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
>> torsten@lodderstedt.net> wrote:
>> > > Hi all,
>> > >
>> > > I just published an article about the subject at:
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-r=
e-think-oauth-scopes-2326e2038948
>>
>> > >
>> > > I look forward to getting your feedback.
>> > >
>> > > kind regards,
>> > > Torsten.
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oauth
>> >
>>
>>

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


Sorry. I mean, UMA provides much more than this 1st party =
authorization flow I'm talking about ....=C2=A0

On Mon, Apr 22, 2019 at =
2:51 PM Pedro Igor Silva <psilva@re=
dhat.com> wrote:


On Mon, Apr =
22, 2019 at 2:18 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pedro,



> 

> > The general idea is to empower RSs so that they can communicate t=
o the AS how access to their resources should be granted as well as decoupl=
ing clients and RSs so that clients don't need to know the constraints =
imposed by the RS to their protected resources (e.g. scopes). 

> 

> Sounds very much like UMA2. The difference I see is the RS needs to be=
 heavily involved in the authorization process (whereas the approaches I di=
scussed leave it passive). How would you handle the use cases I described? =
So for example, how would you construct the JWT for the signature use case?=
 I=E2=80=99m asking because the signing case uses more data in the authoriz=
ation process and might bundle the request to sign multiple documents, even=
 if the first signing request would only need the hashes or even just a sin=
gle hash of a document. 

> 

> Yes, it does. Like I mentioned, the model is based on UMA (Permission =
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had t=
alked with UMA WG in the past about this solution and how we extended the s=
pecs to solve this type of problem.

> 

> By being active during the authorization process the RS is in control =
over additional claims that should be considered by the policies when makin=
g decisions about the resources/scopes a client/user can access. Where the =
information could be obtained from different sources such as the current HT=
TP request or internally/externally to the RS.



The problem from my perspective (and my understanding of UMA) is the RS doe=
s not have any information about the context of the request. For example, t=
he client might be calling a certain resource (list of accounts) and immedi=
ately afterwards wants to obtain the balances and initiate a payment. I thi=
nk the UMA case the RS either predicts this based on policy or past behavio=
ur of the client OR the client will need to issue several token requests. T=
hat might not be a problem in 1st party scenarios but it is in 3rd party sc=
enarios if the AS gathers consent. 

Yea=
h, we are talking about different use cases. But they are still quite relat=
ed in regards to enriching authorization decisions. it would be nice to hav=
e something in OAuth that could address both 1st and 3rd party use cases. A=
s I said before, the model I'm talking about is kind of a 1st party Lod=
ging_Intent.

Just to clarify, UMA does not cover t=
he scenario I'm talking about although it provides a very good ground f=
or extensions like this. It is not part of UMA scope. It provides much more=
 than that too ...
=C2=A0



> 

> We did not have much demand for addressing the signature use case, but=
 use cases similar to the "payment" use case. As I mentioned, the=
 model I'm talking about is not based on user consent.



Right, you mentioned it is intended to be used for 1st parties only. 



> But considering that you can also pass any information to the AS, you =
should be able to let users to authorize the creation of signatures for one=
 or more documents.



I think the client needs to pass this information, which brings us back to =
the original question of my article. 



best regards. 

Torsten. 



>=C2=A0 

> 

> > 

> > I've started to write a document with this idea in mind and I=
'm happy to share it with you and see what you think.

> > 

> 

> Look forward to reading your article. 

> 

> best regards,

> Torsten.

> 

> > Best regards.

> > Pedro Igor

> > 

> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.n=
et> wrote:

> > Hi all, 

> > 

> > I just published an article about the subject at: https://me=
dium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth=
-scopes-2326e2038948=C2=A0 

> > 

> > I look forward to getting your feedback.

> > 

> > kind regards,

> > Torsten. 

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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


> 








--0000000000005f843905872229f5--


From nobody Mon Apr 22 11:19:06 2019
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 A2F7812013A for ; Mon, 22 Apr 2019 11:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 44zTGMzeePLd for ; Mon, 22 Apr 2019 11:19:01 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 DA2E4120092 for ; Mon, 22 Apr 2019 11:19:00 -0700 (PDT)
Received: from [80.187.108.203] (helo=[10.17.208.76]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIdWr-0001cn-Jt; Mon, 22 Apr 2019 20:18:57 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-0781F1FE-1CA2-4D7C-B882-441FF9F5106C; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: 
Date: Mon, 22 Apr 2019 20:18:55 +0200
Cc: oauth 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>    
To: Pedro Igor Silva 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 18:19:05 -0000

--Apple-Mail-0781F1FE-1CA2-4D7C-B882-441FF9F5106C
Content-Type: multipart/alternative;
	boundary=Apple-Mail-35A2C2F3-A7CA-4042-9AEF-E0ADCEB40B0A
Content-Transfer-Encoding: 7bit


--Apple-Mail-35A2C2F3-A7CA-4042-9AEF-E0ADCEB40B0A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 22.04.2019 um 19:54 schrieb Pedro Igor Silva :
>=20
> Sorry. I mean, UMA provides much more than this 1st party authorization fl=
ow I'm talking about ....=20

got it ;-)

>=20
>> On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva  wrot=
e:
>>=20
>>=20
>>> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt  wrote:
>>> Hi Pedro,
>>>=20
>>> >=20
>>> > > The general idea is to empower RSs so that they can communicate to t=
he AS how access to their resources should be granted as well as decoupling c=
lients and RSs so that clients don't need to know the constraints imposed by=
 the RS to their protected resources (e.g. scopes).=20
>>> >=20
>>> > Sounds very much like UMA2. The difference I see is the RS needs to be=
 heavily involved in the authorization process (whereas the approaches I dis=
cussed leave it passive). How would you handle the use cases I described? So=
 for example, how would you construct the JWT for the signature use case? I=E2=
=80=99m asking because the signing case uses more data in the authorization p=
rocess and might bundle the request to sign multiple documents, even if the f=
irst signing request would only need the hashes or even just a single hash o=
f a document.=20
>>> >=20
>>> > Yes, it does. Like I mentioned, the model is based on UMA (Permission T=
icket/API) as well as ACE (Unauthorized Resource Request Message). I had tal=
ked with UMA WG in the past about this solution and how we extended the spec=
s to solve this type of problem.
>>> >=20
>>> > By being active during the authorization process the RS is in control o=
ver additional claims that should be considered by the policies when making d=
ecisions about the resources/scopes a client/user can access. Where the info=
rmation could be obtained from different sources such as the current HTTP re=
quest or internally/externally to the RS.
>>>=20
>>> The problem from my perspective (and my understanding of UMA) is the RS d=
oes not have any information about the context of the request. For example, t=
he client might be calling a certain resource (list of accounts) and immedia=
tely afterwards wants to obtain the balances and initiate a payment. I think=
 the UMA case the RS either predicts this based on policy or past behaviour o=
f the client OR the client will need to issue several token requests. That m=
ight not be a problem in 1st party scenarios but it is in 3rd party scenario=
s if the AS gathers consent.=20
>>=20
>> Yeah, we are talking about different use cases. But they are still quite r=
elated in regards to enriching authorization decisions. it would be nice to h=
ave something in OAuth that could address both 1st and 3rd party use cases. A=
s I said before, the model I'm talking about is kind of a 1st party Lodging_=
Intent.
>>=20
>> Just to clarify, UMA does not cover the scenario I'm talking about althou=
gh it provides a very good ground for extensions like this. It is not part o=
f UMA scope. It provides much more than that too ...
>> =20
>>>=20
>>> >=20
>>> > We did not have much demand for addressing the signature use case, but=
 use cases similar to the "payment" use case. As I mentioned, the model I'm t=
alking about is not based on user consent.
>>>=20
>>> Right, you mentioned it is intended to be used for 1st parties only.=20
>>>=20
>>> > But considering that you can also pass any information to the AS, you s=
hould be able to let users to authorize the creation of signatures for one o=
r more documents.
>>>=20
>>> I think the client needs to pass this information, which brings us back t=
o the original question of my article.=20
>>>=20
>>> best regards.=20
>>> Torsten.=20
>>>=20
>>> > =20
>>> >=20
>>> > >=20
>>> > > I've started to write a document with this idea in mind and I'm happ=
y to share it with you and see what you think.
>>> > >=20
>>> >=20
>>> > Look forward to reading your article.=20
>>> >=20
>>> > best regards,
>>> > Torsten.
>>> >=20
>>> > > Best regards.
>>> > > Pedro Igor
>>> > >=20
>>> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt  wrote:
>>> > > Hi all,=20
>>> > >=20
>>> > > I just published an article about the subject at: https://medium.com=
/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2=
326e2038948 =20
>>> > >=20
>>> > > I look forward to getting your feedback.
>>> > >=20
>>> > > kind regards,
>>> > > Torsten.=20
>>> > > _______________________________________________
>>> > > OAuth mailing list
>>> > > OAuth@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/oauth
>>> >=20
>>>=20

--Apple-Mail-35A2C2F3-A7CA-4042-9AEF-E0ADCEB40B0A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 22.04.2019 um 19:54 schrieb Pedro Igor Silva &=
lt;psilva@redhat.com>:

Sorry. I mea=
n, UMA provides much more than this 1st party authorization flow I'm talking=
 about .... 

got it ;-)

=


On Mon, Apr 22, 2019 at 2:51 PM Pedro Ig=
or Silva <psilva@redhat.com> w=
rote:


On Mon, Apr 22, 2019 at 2:18 PM To=
rsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pedro,



> 

> > The general idea is to empower RSs so that they can communicate to=
 the AS how access to their resources should be granted as well as decouplin=
g clients and RSs so that clients don't need to know the constraints imposed=
 by the RS to their protected resources (e.g. scopes). 

> 

> Sounds very much like UMA2. The difference I see is the RS needs to be h=
eavily involved in the authorization process (whereas the approaches I discu=
ssed leave it passive). How would you handle the use cases I described? So f=
or example, how would you construct the JWT for the signature use case? I=E2=
=80=99m asking because the signing case uses more data in the authorization p=
rocess and might bundle the request to sign multiple documents, even if the f=
irst signing request would only need the hashes or even just a single hash o=
f a document. 

> 

> Yes, it does. Like I mentioned, the model is based on UMA (Permission T=
icket/API) as well as ACE (Unauthorized Resource Request Message). I had tal=
ked with UMA WG in the past about this solution and how we extended the spec=
s to solve this type of problem.

> 

> By being active during the authorization process the RS is in control o=
ver additional claims that should be considered by the policies when making d=
ecisions about the resources/scopes a client/user can access. Where the info=
rmation could be obtained from different sources such as the current HTTP re=
quest or internally/externally to the RS.



The problem from my perspective (and my understanding of UMA) is the RS does=
 not have any information about the context of the request. For example, the=
 client might be calling a certain resource (list of accounts) and immediate=
ly afterwards wants to obtain the balances and initiate a payment. I think t=
he UMA case the RS either predicts this based on policy or past behaviour of=
 the client OR the client will need to issue several token requests. That mi=
ght not be a problem in 1st party scenarios but it is in 3rd party scenarios=
 if the AS gathers consent. 

Yeah, we ar=
e talking about different use cases. But they are still quite related in reg=
ards to enriching authorization decisions. it would be nice to have somethin=
g in OAuth that could address both 1st and 3rd party use cases. As I said be=
fore, the model I'm talking about is kind of a 1st party Lodging_Intent.

Just to clarify, UMA does not cover the scenario I'm t=
alking about although it provides a very good ground for extensions like thi=
s. It is not part of UMA scope. It provides much more than that too ...
 



> 

> We did not have much demand for addressing the signature use case, but u=
se cases similar to the "payment" use case. As I mentioned, the model I'm ta=
lking about is not based on user consent.



Right, you mentioned it is intended to be used for 1st parties only. 



> But considering that you can also pass any information to the AS, you s=
hould be able to let users to authorize the creation of signatures for one o=
r more documents.



I think the client needs to pass this information, which brings us back to t=
he original question of my article. 



best regards. 

Torsten. 



>  

> 

> > 

> > I've started to write a document with this idea in mind and I'm ha=
ppy to share it with you and see what you think.

> > 

> 

> Look forward to reading your article. 

> 

> best regards,

> Torsten.

> 

> > Best regards.

> > Pedro Igor

> > 

> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> > Hi all, 

> > 

> > I just published an article about the subject at: https://mediu=
m.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-sco=
pes-2326e2038948  

> > 

> > I look forward to getting your feedback.

> > 

> > kind regards,

> > Torsten. 

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.org=


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








=

--Apple-Mail-35A2C2F3-A7CA-4042-9AEF-E0ADCEB40B0A--

--Apple-Mail-0781F1FE-1CA2-4D7C-B882-441FF9F5106C
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDIyMTgxODU2WjAvBgkqhkiG9w0BCQQxIgQg
eBbDfvEXhJZp3C2u1JW4LH4/HL/WGMkpry6SrOjyI9swgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACnB86dMKGsyrYLM
FGh0Ijf0HomexWNE0es7DE/PG0H1aEmJZGmw8++p/o5B9UXY+NKr4Nv7qRUz/S7yE/aQ9JiIuC0C
2whRI9xx/90GHkaASIbKojBU9qsbfKDs6XyYO1ton4APxfJiwDSWo+OLX9AJyYj6a7GbD4rx1Rq3
fKRKGWPmsh6Wr03G18L6M7CculK4KIKUVygPy2rQY4UZWkjQC67uPverzdGxQXZt5o8TYwJ2DJSH
usWvoOjyAvSS5hiPa3UCqdxkqDEovjael1FnWLNRPV1ZLWiKaLQhoh+aL6Tvs0WN5HddDx8sftie
RiO/yLxilk1SQIoeH1cdfhwAAAAAAAA=

--Apple-Mail-0781F1FE-1CA2-4D7C-B882-441FF9F5106C--


From nobody Mon Apr 22 11:35:54 2019
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 8454E12014A for ; Mon, 22 Apr 2019 11:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GetXeKkLK-bH for ; Mon, 22 Apr 2019 11:35:51 -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 85D841200B2 for ; Mon, 22 Apr 2019 11:35:51 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id c3so2836005iok.6 for ; Mon, 22 Apr 2019 11:35:51 -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=Vs2xvoFxiH9vfTYrRKYak3Orccjmx7F67G3bWkyxcNc=; b=uz34P/B+yAFie/HzYsKEQRjMDH4jLZ4tvNEQAH3p8QyxZQQ3qkbZJQUDJdeKgBY8mq A2He9KpCCmFngwRDSHfdxArWkC11E3eNhPynlROeYyBUI19yIOqIRqwqZ+Dx42EnUaet /O6IwzrpFV/RugGHr5FMwS1jfD7fsPyjBuP2EfRJV9ZYzm9UNti+Pi3UFCfrYEDcwGbE 7w9S7GEBBcDOljKSzgEH91ZgznifUGAv2Agjv2sCtXFm3iza6+YCbY6qbseg5FEhVemR QhNDVPIJyce/X0OmqxPqTqwVfQBkVXOY1wjt4GIFt2AX86bDin2ICgIOisOsOTmUXKFI UDzA==
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=Vs2xvoFxiH9vfTYrRKYak3Orccjmx7F67G3bWkyxcNc=; b=pE+tIVAfoL1LyIiuuRZRxlA1vC2nZGTqJzpUgL9ZeFOtZ+t5KjiVY/iNK158PMkYVE 2Rv1eVzOnH8ZWtosQBnsVR3/D/kSE5kmmiMY0I3F9ZWfzc7pwggnWPAI9GFU3VV2LqRn FT0BDvzHmvDbbxsPA7jqrXtINHehJlUYAd6a7/dWJLcum1sGJfS1UvjfOfn20aErZyP9 NRhdvSGw7uLtJrYQUsbcaML4U9d/D4d0QaqF0lJvw8bJ4hxFA8fZ9sfOgxzpoprPitxs Ry6bc2PZglErVmbw0zwdr33AN6CSQA9OAGHbXQf1EKhKedpPTvI3uAKUZZ7R3X5afwZa jy7Q==
X-Gm-Message-State: APjAAAVKlk5lDUI7QUzZ/ZCRapSFBBrdIfa/xP41xa4BzepIAzEXK3Co F6iZ2uLiPRtGceSnyJ9rBxdQ6Sgt/lnNWNWhwcPKZtKg
X-Google-Smtp-Source: APXvYqzO8AwGl9sCeuuw0asirNF+ATGOPysXKc0zO6BxckCuWjsW4AOan6TCtG9xbSBmB5McDFh5ti+/vqqssHjXEXw=
X-Received: by 2002:a5d:88ca:: with SMTP id i10mr13430644iol.261.1555958150756;  Mon, 22 Apr 2019 11:35:50 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Sascha Preibisch 
Date: Mon, 22 Apr 2019 11:34:45 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 18:35:54 -0000

Thank you for the article, Torsten!

I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:
>
> Hi all,
>
> I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Mon Apr 22 12:04:04 2019
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 A42771202CC for ; Mon, 22 Apr 2019 12:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DvyHQSW_BmPT for ; Mon, 22 Apr 2019 12:04:01 -0700 (PDT)
Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (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 EFBBD1200E9 for ; Mon, 22 Apr 2019 12:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1555959840; bh=GRSKeTrhahn7XNpiE2Vzxq1o5Z/O5xdQLEWrBC3j1K4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=l/2aGW6weKmzz7B2yGuAVrnhNuUKAiIwklUJuVOOOFYDmKmmozMxmCj2d/LzRDlb41iwpBMveSbjzWM1mlnrk4l8TLqyBZ7ZAlMDJvQ89v5bVbzaxSSBPaENX+onHMrrH5vc11TObw9RH8677BXz2pKmksle5fV7jv/Y0NnHCU5tSBR2uuuPYUfT+fzoskzOCYWa46yktzhTI/7EBwUTwZdpEO6zzE+V7NBHr69q2wqSrHZLwQ1L5HfOA1m8L3ScA01cDWZ0jBdryeCzNNq/bahp6cBekDEq8gg7/AjUT2Pz/4OvD+7QyAyTSv4RJiTcKrGTL3QdqKvqmtrVPKJ1dw==
X-YMail-OSG: G5fno4EVM1mKvzLlPm2.AqzKvS2U8SHO0rOV.GZO8VhKCatO6XkbudL1TAVXM07 haM.1_uwxSM7SW9wrph0TRrLU88xAOlxczaYSeis1ychQS6lV00lJY86xAVh5HXb8Y2dAhyW5NXz Xp7Rmc6lBWTQICP0djTNAS6r77AnCHpWoTOfUGv7M_9qkciDFPCWrJVJK_Een_EmKieQbNlhgzpt 8xpkmAFfx_pPIpyM_OBMyoGRe5O15NgdA2EigsD1qQC8SeXNBcYmfkuEbvhRgnIRfOncJF2w1Bpf uQqryWJZs.49SW8LKtvAn4X9bVFheSpKylPF.xjOp3Nuzt6P.RDI9wFwXd2a5j.6cx1eWn4tElSR ETSx09x9r9UuHVYJ6oL6ma3GGQFl2XXpG9_AQKxdjTM54jtRmuJYs5QG7KLkwgnofOfxJX.jz7U_ 5JfTUKkNcQGfl3pLQW1TKiL7B6a3QhLOpTeCVe6f_4KmDndjRaXuQBe6KOUVnN3BmhZP2jS88xBV wzkdVm_Mmzk3xvqXKHFR9D6R27fTKNl2msmrSrGz4AIK.3BH_jdgD2i8xvu2sZFVGrxxha_5vzpk x0dQDTKYpb6HpsmJzFX.yDFLwjiv7dKsfJdqGQW6w4sXc1w6FXjsHKd.zgSo3eiRo837apJJJMXr o7SAqHhslb7IbhBfJJ2dJYSH9SW4SOAZ8yqSwhhKdMcaM._1BcDKMMVJSgzl7cjkV4HQiw3avBCl bHEErbPEbbO.pVVPSl7qISkMINXhG6HvB2olNgekvzDIV8L0D7sWzhhmIVsY_nTd28PITOwDKXDJ WHSwY8TN1YnTcepB9fcnd25iRYWKzKFIjzLKSuxGWHpFQIp1cpARMWJjxmn_fs57qWZ9VH3fmvOJ 42ri7aXS_oYvLFShgMgrQ5uQAsvybW95CfEgJzEAsDSl8P024Muda_2_3VHpq5h5NNs26ghwbrp_ bOBMNo.iQEAoP6AHV3VeWgvNKIy7Q4wGR1rjLLM4cOmr35rEWThwWYQa6NORxeeNCKjr.2hdCwCi 0yPogrPqE8q.8TRdTO_ta.y02sZWjfWSkzB2NJo9woujzP8knQK2t6ol8o3GWRDuOlsRyzrMILSv 0sQ5tMk.u11HvynEm4JEYhXA-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 22 Apr 2019 19:04:00 +0000
Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.130.101]) ([184.165.8.97]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 16d9096f5b98410da78d7c1feb52d8cf;  Mon, 22 Apr 2019 19:03:58 +0000 (UTC)
To: Torsten Lodderstedt , Pedro Igor Silva 
Cc: oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
Date: Mon, 22 Apr 2019 15:03:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B0A643BD2B36C04136FB6042"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 19:04:03 -0000

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

Speaking just to the UMA side of things...

...it's possible in UMA 2 for the client to request additional scopes 
when interacting with the token endpoint specifically to address cases 
where the client knows it's going to make the following requests and 
wants to obtain a token with sufficient privilege for those requests. 
This requires a fair amount of knowledge by the client of the ecosystem 
but that is sometimes the case and hence this capability exists :)

On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
> The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent.


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


  
    
  
  
    Speaking just to the UMA
      side of things... 

      

      ...it's possible in UMA 2 for the client to request additional
      scopes when interacting with the token endpoint specifically to
      address cases where the client knows it's going to make the
      following requests and wants to obtain a token with sufficient
      privilege for those requests. This requires a fair amount of
      knowledge by the client of the ecosystem but that is sometimes the
      case and hence this capability exists :)

    

    
On 4/22/19 1:18 PM, Torsten Lodderstedt
      wrote:

    

    

      
The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent. 

    

    

  


--------------B0A643BD2B36C04136FB6042--


From nobody Mon Apr 22 12:36:35 2019
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 2EBE5120123 for ; Mon, 22 Apr 2019 12:36:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 E8KF1rMymdQD for ; Mon, 22 Apr 2019 12:36:32 -0700 (PDT)
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 9237012014E for ; Mon, 22 Apr 2019 12:36:24 -0700 (PDT)
Received: by mail-vs1-f41.google.com with SMTP id e2so6851693vsc.13 for ; Mon, 22 Apr 2019 12:36:24 -0700 (PDT)
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=2imgW72nJKPdiQdcHMoJBkGY26JkmtNYApFbwKUfnaA=; b=Qlu0QrKpAAuFyyPDvMiWZUYsX8sLShhIn1dfTP5YTfNL3FRoXCutPLsShjhPO/rlcG BfiglLscU3D3236FI4Rv+f5Vh4VuXJFad+JvQPWrSHqMa3zfmWRYrNr24ouvcysV0gt1 QjR/7B+/Wra7JLUOsbOgqf5otC+YrWHG7TBLO7rVsB6Ra7BWPRFzqb9QpTP1G2twni9d KQbveBEpDkVmHyBwuq4OGk3XXm9+Q+58xqyY1hWx77uZ1VoOeeBwOcNXQ8q2U7IwMaTS gbKljT/erhv/F7SGqMoqE/8GGMuftZuixcJ7Q872ZahINfnPlAN4MzJ8X+SSSi7hTr3p Zr9w==
X-Gm-Message-State: APjAAAWeM78ZBxWKIqyLnF7Ghsxa7jiAnPYZkN84XzB0itC2i4WNxNtA Z/gi+blhg9xlK+2QbYZ2ZSrh8i/USxldzxMNGKFV7g==
X-Google-Smtp-Source: APXvYqxr7tvylbh9P73dd3KKEarS0tPoqnSv0I8XyDVVMHBwhAuIFsRe3eHdWfRZMLMYD8z+myIWTE3ka7mUZKLlWrw=
X-Received: by 2002:a67:7b53:: with SMTP id w80mr11367640vsc.144.1555961783457;  Mon, 22 Apr 2019 12:36:23 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>   <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
In-Reply-To: <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
From: Pedro Igor Silva 
Date: Mon, 22 Apr 2019 16:36:12 -0300
Message-ID: 
To: George Fletcher 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="00000000000063372f058723954d"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2019 19:36:35 -0000

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

I think this knowledge by clients of the ecosystem is something that a
transactional authorization could avoid. Both UMA and ACE have solutions
that make clients really dumb about what they need to send to the AS in
regards to scopes. IMO, the RS should have the possibility to tell clients
the scope they need, making a lot easier to change RS's access constraints
as well as pushing contextual information that could eventually enrich the
authorization process.

On Mon, Apr 22, 2019 at 4:04 PM George Fletcher  wrote:

> Speaking just to the UMA side of things...
>
> ...it's possible in UMA 2 for the client to request additional scopes whe=
n
> interacting with the token endpoint specifically to address cases where t=
he
> client knows it's going to make the following requests and wants to obtai=
n
> a token with sufficient privilege for those requests. This requires a fai=
r
> amount of knowledge by the client of the ecosystem but that is sometimes
> the case and hence this capability exists :)
>
> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>
> The problem from my perspective (and my understanding of UMA) is the RS d=
oes not have any information about the context of the request. For example,=
 the client might be calling a certain resource (list of accounts) and imme=
diately afterwards wants to obtain the balances and initiate a payment. I t=
hink the UMA case the RS either predicts this based on policy or past behav=
iour of the client OR the client will need to issue several token requests.=
 That might not be a problem in 1st party scenarios but it is in 3rd party =
scenarios if the AS gathers consent.
>
>
>

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


I think this knowledge by clients of the ecosystem is=
 something that a transactional authorization could avoid. Both UMA and ACE=
 have solutions that make clients really dumb about what they need to send =
to the AS in regards to scopes. IMO, the RS should have the possibility to =
tell clients the scope they need, making a lot easier to change RS's ac=
cess constraints as well as pushing contextual information that could event=
ually enrich the authorization process.=C2=A0

On Mon, Apr 22, 2019 at 4:=
04 PM George Fletcher <gffletch@aol.=
com> wrote:

 =20
   =20
 =20
  

    Speaking just to the UMA
      side of things... 

      

      ...it's possible in UMA 2 for the client to request additional
      scopes when interacting with the token endpoint specifically to
      address cases where the client knows it's going to make the
      following requests and wants to obtain a token with sufficient
      privilege for those requests. This requires a fair amount of
      knowledge by the client of the ecosystem but that is sometimes the
      case and hence this capability exists :)

    

    
On 4/22/19 1=
:18 PM, Torsten Lodderstedt
      wrote:

    

    

      
The problem =
from my perspective (and my understanding of UMA) is the RS does not have a=
ny information about the context of the request. For example, the client mi=
ght be calling a certain resource (list of accounts) and immediately afterw=
ards wants to obtain the balances and initiate a payment. I think the UMA c=
ase the RS either predicts this based on policy or past behaviour of the cl=
ient OR the client will need to issue several token requests. That might no=
t be a problem in 1st party scenarios but it is in 3rd party scenarios if t=
he AS gathers consent. 

    

    

  





--00000000000063372f058723954d--


From nobody Mon Apr 22 22:04:37 2019
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 9BF811203C9 for ; Mon, 22 Apr 2019 22:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Y27UA_nAIAAY for ; Mon, 22 Apr 2019 22:04:32 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 897191203C7 for ; Mon, 22 Apr 2019 22:04:32 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hInbY-0003Wk-4A; Tue, 23 Apr 2019 07:04:28 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-609F5A27-AAC3-4091-858F-13BF7C395337; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
Date: Tue, 23 Apr 2019 07:04:27 +0200
Cc: Pedro Igor Silva , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>   <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 05:04:36 -0000

--Apple-Mail-609F5A27-AAC3-4091-858F-13BF7C395337
Content-Type: multipart/alternative;
	boundary=Apple-Mail-8CAAF929-4BC4-4E52-8ECA-36BF5643A8FC
Content-Transfer-Encoding: 7bit


--Apple-Mail-8CAAF929-4BC4-4E52-8ECA-36BF5643A8FC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Does UMA use the standard scope parameter?

> Am 22.04.2019 um 21:03 schrieb George Fletcher :
>=20
> Speaking just to the UMA side of things...=20
>=20
> ...it's possible in UMA 2 for the client to request additional scopes when=
 interacting with the token endpoint specifically to address cases where the=
 client knows it's going to make the following requests and wants to obtain a=
 token with sufficient privilege for those requests. This requires a fair am=
ount of knowledge by the client of the ecosystem but that is sometimes the c=
ase and hence this capability exists :)
>=20
>> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>> The problem from my perspective (and my understanding of UMA) is the RS d=
oes not have any information about the context of the request. For example, t=
he client might be calling a certain resource (list of accounts) and immedia=
tely afterwards wants to obtain the balances and initiate a payment. I think=
 the UMA case the RS either predicts this based on policy or past behaviour o=
f the client OR the client will need to issue several token requests. That m=
ight not be a problem in 1st party scenarios but it is in 3rd party scenario=
s if the AS gathers consent.=20
>=20

--Apple-Mail-8CAAF929-4BC4-4E52-8ECA-36BF5643A8FC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Does UMA use the standard scope parameter?

Am 22.04.2019 um 21:03 schrieb George Fletcher <gffletch@aol.com>:


  
    
  
  
    Speaking just to the UMA
      side of things... 

      

      ...it's possible in UMA 2 for the client to request additional
      scopes when interacting with the token endpoint specifically to
      address cases where the client knows it's going to make the
      following requests and wants to obtain a token with sufficient
      privilege for those requests. This requires a fair amount of
      knowledge by the client of the ecosystem but that is sometimes the
      case and hence this capability exists :)

    

    
On 4/22/19 1:18 PM, Torsten Lodderstedt
      wrote:

    

    

      
The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent. 

    

    

  



--Apple-Mail-8CAAF929-4BC4-4E52-8ECA-36BF5643A8FC--

--Apple-Mail-609F5A27-AAC3-4091-858F-13BF7C395337
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDIzMDUwNDI3WjAvBgkqhkiG9w0BCQQxIgQg
dEZaPY2vsoeVignV1vez1OuqDR+Odq0kAip5qOqC8WIwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACJdUxp3ttsPKseF
xFksCNcAc/hltSvSvNrHJDDo5I7jH0Doul952TTkfhf+ZT071ZA4hY8mSDUvFIIbC+y4DgLusE1W
1HXYqAU9BRDy28ZeW8+CzUmzv3vq1/QVtD2eeYxBidkT8A6OgF0n8qezHva1euPYgN1twUWX2k8T
Ylms3FDpkF6ezhTGDnJOEzd9vOF4bvszA9FOL/pIjmSXo12N5Zn0TeP2lX2bBAB7OscV98lb9ojN
oD/4HnXwTvVul5DlhYhOb1hFgmiRUY5XJr+LIZFr3UoY0tZcVK22XoHu2pPIMGaUyZFDK+o0KToP
Z2jQ7i36P/Lz+WkOm0RTJU4AAAAAAAA=

--Apple-Mail-609F5A27-AAC3-4091-858F-13BF7C395337--


From nobody Mon Apr 22 22:06:32 2019
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 556CB1203D3 for ; Mon, 22 Apr 2019 22:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0mD3paRFqGRp for ; Mon, 22 Apr 2019 22:06:28 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) (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 8D58D1203D2 for ; Mon, 22 Apr 2019 22:06:27 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hIndR-0007em-J9; Tue, 23 Apr 2019 07:06:25 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-64310AD6-C40D-420D-B3A3-C05A9FD1012D; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: 
Date: Tue, 23 Apr 2019 07:06:24 +0200
Cc: oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Sascha Preibisch 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 05:06:30 -0000

--Apple-Mail-64310AD6-C40D-420D-B3A3-C05A9FD1012D
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Sascha,

> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
>=20
> Thank you for the article, Torsten!

my pleasure :-)=20

>=20
> I like that 'scope' is out of the game for these kinds of authorizations.
>=20
> What I can see for the general use case is a required identifier
> within the 'structures_scope' document that identifies the profile it
> should be used for.

What does profile mean in this context?

best regards,
Torsten.
>=20
> Thank you,
> Sascha
>=20
> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> :
>>=20
>> Hi all,
>>=20
>> I just published an article about the subject at: https://medium.com/oaut=
h-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2=
038948
>>=20
>> I look forward to getting your feedback.
>>=20
>> kind regards,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-64310AD6-C40D-420D-B3A3-C05A9FD1012D
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDIzMDUwNjI0WjAvBgkqhkiG9w0BCQQxIgQg
QAyut1SUo+2rh8xqmsRaWg/a2Qv9CscjQEr3YM8xBVwwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBADz0qKtkkSM6D/zg
B/E8WvvDHnuVyVHU2wZa/7zYE7NeV4wd7T9+XPvGzO7YqaPJtAEcg8Mp0/RzS6unlQ13/59bpudT
zopF4hp5lrnXbQzc1DODus77xcRR/piQ2XWF+1CU/ne0y/nQYm8FbocFQUI3nYjkilg+VyKXPqkt
LX59eB5es0RnDlZFq2fk5Xp3WD+bqaL7owq8J5LowWl8M3L9kLoYXVjdelfZhsvSJV9rAViKDbIy
LPvUpcczoaQlbuE1jev8AotqhUoRJOmk5U3RyoeCq+CTcnF5xmbPK1D+s5OYvJ67WQ2vvBprxnEP
Mh227Q8bS4J37NGJgVzWCfkAAAAAAAA=

--Apple-Mail-64310AD6-C40D-420D-B3A3-C05A9FD1012D--


From nobody Mon Apr 22 22:24:13 2019
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 973A11201B4 for ; Mon, 22 Apr 2019 22:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YvTnr91uXAkU for ; Mon, 22 Apr 2019 22:24:09 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 0E8B012004C for ; Mon, 22 Apr 2019 22:24:09 -0700 (PDT)
Received: from [80.187.108.203] (helo=[10.17.208.76]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hInuY-00085g-68; Tue, 23 Apr 2019 07:24:06 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-4815A822-015E-4123-AA94-56ACDB8168FC; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <7bca0d14-8644-ef2b-c33a-bd874fe8fb6c@connect2id.com>
Date: Tue, 23 Apr 2019 07:24:05 +0200
Cc: oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <3F8277DE-270F-4883-93AB-0F58CE6FCDE8@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> <7bca0d14-8644-ef2b-c33a-bd874fe8fb6c@connect2id.com>
To: Vladimir Dzhuvinov 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 05:24:12 -0000

--Apple-Mail-4815A822-015E-4123-AA94-56ACDB8168FC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Thanks for sharing this recommendation!

> Am 21.04.2019 um 22:41 schrieb Vladimir Dzhuvinov :
>=20
> The proposed structured_scope fits nicely into the JSON object format of
> the request object.
>=20
> At present for similar cases we recommend developers to encode the scope
> value into a URI with query string parameters, e.g.
>=20
> https://scopes.myapp.com/sign?credentialID=3Dqes_eidas&documentDigests.has=
h=3DsTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI&documentDigests.label=3DMobi=
le%20Subscription%20Contract&hashAlgorithmOID=3D2.16.840.1.101.3.4.2.1
>=20
>> On 20/04/2019 21:21, Torsten Lodderstedt wrote:
>> Hi all,=20
>>=20
>> I just published an article about the subject at: https://medium.com/oaut=
h-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2=
038948 =20
>>=20
>> I look forward to getting your feedback.
>>=20
>> kind regards,
>> Torsten.=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-4815A822-015E-4123-AA94-56ACDB8168FC
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDIzMDUyNDA1WjAvBgkqhkiG9w0BCQQxIgQg
xRtXv2Rvo+uTXcj7pYM9Gx6DlV76GxDjvdZxDQoyQtAwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBACGLGezWDGErOhFg
eAe4NJibZ06z2ykgAZ5zchHJ4PUugK/t87UC4FoOwqGCoZU4iyLQbyvgpawKmyLtzaBD0m28eq/O
7oow8xsjbtzvOcXHbEIbe8TZ2Wny0YMA4IKpGQOyySLLGXf9yEtB8ANbLZD6DNqvAt4RKENFQCiq
lmeyoOEuUmwkPX9PTeag/xrXcbjRMQTvJ/8huYhfbm0vIVNwc47fyZDbGFnjf59Hhgs8tamt1bkl
IjIoQrcRHluVmhJ9PQkd75J/BxOj7LtCQ7JVuHkNYGcWoEr9fs3yAHhzGzToduaeRRkEVoSFnNqv
bZ9lEKmWvY8pwDRfrQoxkr4AAAAAAAA=

--Apple-Mail-4815A822-015E-4123-AA94-56ACDB8168FC--


From nobody Tue Apr 23 04:19:18 2019
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 42281120045 for ; Tue, 23 Apr 2019 04:19:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPPpj2A5g8Za for ; Tue, 23 Apr 2019 04:19:14 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0: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 411CB12016C for ; Tue, 23 Apr 2019 04:19:13 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id s24so12399653otk.13 for ; Tue, 23 Apr 2019 04:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wf30DyiLsxCdn+pmMuLMXSJsV+xO4O6M1YPHfLnDN1M=; b=irJRq5SW5zzkXWTgTT9wieSWLAgri5eAREGxCdz5WYEsRYJYTm84oZ1fH1tOx1uW+e bZQmVvyRrliiDTyMlDylw4HF+MUro9hpUPrL8/sj3JkqTM9kMFhbSIRx+SsqqfRWwmB3 p9f27XOEfV9RA3ib/7alebI7xBr/e+CeF6yuBSgbDxxBnVpLIdL/XFCM9QSANfwcTmO/ JaxRRs3hPJHVq0PQQ8q4FuOyCqG5jM5rjUHdErM/V4y8j3eDDcvRBgoiayc8ajsSwCg9 jiI9+KqLbTyOwj6/64XoNxYDFe7Y9hXoZAlB+OquK1pj7Ze0Z+5ia+gV8BjPH6jTSPFd +iGw==
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=wf30DyiLsxCdn+pmMuLMXSJsV+xO4O6M1YPHfLnDN1M=; b=eKbbIkhUuXUyf+TdjRBjMaQilHXqt3V11Dubi0vOHWvrUmQTemdykaQX9xQVpQTto/ 9XeuYmYhucQDd4wz/RDf58FNzTlt1ivIHmElyUGv5OQsJS/QCWDbO3xLNiGk6JBSgd8d gea3gTaAGh94xZ41to744wr6qpHLakJQnEOIsH5fLSjRhtYyd8z+H8ErGAQ/rLEh4q1T Gajd0Vla/hXxzV31RaJTyxFlWBkpLy/23TP9vytX7laSd+yOoP+vpu8FyK0ZNI96HeBr VuwBr/ZEpl4g8A3sM7YCRuu0oZM7dDN8RbrIfiHcUfYcPEksGZegAIh0wjUNhW+YukVj b46Q==
X-Gm-Message-State: APjAAAXPlZVKTydJksmGkSMYJZYZLPyqR+CWm1t1gRL7BDNLryynAqLL MVTzpeY07zFeualvx0DoHiyzWAPjRHJpWRyuz4I8550BNxI=
X-Google-Smtp-Source: APXvYqx71a49dziqUYWkG9rNRBScQSjoz5aG1slyp8kKRKe4fcO84XHLbslw0PeWF0ufybDJn18SIbotemw9AXrosFY=
X-Received: by 2002:a9d:5a02:: with SMTP id v2mr14684079oth.70.1556018352834;  Tue, 23 Apr 2019 04:19:12 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  
In-Reply-To: 
From: Steinar Noem 
Date: Tue, 23 Apr 2019 13:19:01 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000002f5bb6058730c19b"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 11:19:17 -0000

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

Ah, I hadn't considered the OpenId Connect/claims connection. At one point
we actually considered using the private_key_jwt client secret to transport
"claims" from the client to the AS - so we were happy to learn about the
JAR spec.

In my opinion TLS is good enough, but some security analysts and data
protection officers in the health sector may not agree with me :)
Our main use case for OAuth is interoperability between businesses on a
national level (hospitals, primary health care etc), where a health
personel requests information about a patient in a different legal entity
(business) than where they are employed.
It's a complex domain, in certain cases the combination of two personal
identifiers can be considered sensitive alone (e.g. a psychiatrist and
patient combination). But, we have seen a "softening" of the requirements
for confidentiality - so hopefully signatures will be sufficient..

- S

man. 22. apr. 2019 kl. 18:29 skrev Torsten Lodderstedt <
torsten@lodderstedt.net>:

> HI Steinar,
>
> > On 22. Apr 2019, at 10:38, Steinar Noem  wrote:
> >
> > Hi Torsten, thank you for writing this clarifying article :)
>
> Pleasure :-)
>
> >
> > In the health sector in Norway we are facing similar challenges
> regarding the need for contextual information.
> > At the time, our planned solution is to package this information as
> custom claims in request objects - e.g.: =E2=80=9Chelse:client/claims/xxx=
x=E2=80=9D,
>
> and do not forget: claims in a request object means you force your client
> and AS to turn on OpenID Connect for your requests (scope openid, ID Toke=
n,
> ...) even if you =E2=80=9Cjust=E2=80=9D want to authorise API access.
>
> > but after reading your article I realize that the structured scope
> approach makes a lot more sense and, as you stated in the article, pushin=
g
> the request objects mitigates the issues with request-size and complexity
> on the client side.
> > In our case we may also have a requirement to encrypt the pushed reques=
t
> object due to potential sensitive content.
>
> TLS is not enough?
>
> kind regards,
> Torsten.
>
> >
> > - Steinar
> >
> >
> > l=C3=B8r. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <
> torsten@lodderstedt.net>:
> > Hi all,
> >
> > I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
> >
> > I look forward to getting your feedback.
> >
> > kind regards,
> > Torsten.
> > _______________________________________________
> > 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 |
>
>

--=20
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

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


Ah, I hadn't considered the OpenId Connect/claims=
 connection. At one point we actually considered using the private_key_jwt =
client secret to transport "claims" from the client to the AS - s=
o we were happy to learn about the JAR spec.

In my=
 opinion TLS is good enough, but some security analysts and data protection=
 officers in the health sector may not agree with me :)
Our main =
use case for OAuth is interoperability between businesses on a national lev=
el (hospitals, primary health care etc), where a health personel requests i=
nformation about a patient in a different legal entity (business) than wher=
e they are employed.
It's a complex domain, in certain cases =
the combination of two personal identifiers can be considered sensitive alo=
ne (e.g. a psychiatrist and patient combination). But, we have seen a "=
;softening" of the requirements for confidentiality - so hopefully sig=
natures will be sufficient..

- S

man. 22. apr. 2019=
 kl. 18:29 skrev Torsten Lodderstedt <torsten@lodderstedt.net>:
HI Steinar,



> On 22. Apr 2019, at 10:38, Steinar Noem <steinar@udelt.no> wrote:

> 

> Hi Torsten, thank you for writing this clarifying article :)



Pleasure :-)



> 

> In the health sector in Norway we are facing similar challenges regard=
ing the need for contextual information.

> At the time, our planned solution is to package this information as cu=
stom claims in request objects - e.g.: =E2=80=9Chelse:client/claims/xxxx=E2=
=80=9D,



and do not forget: claims in a request object means you force your client a=
nd AS to turn on OpenID Connect for your requests (scope openid, ID Token, =
...) even if you =E2=80=9Cjust=E2=80=9D want to authorise API access. 



> but after reading your article I realize that the structured scope app=
roach makes a lot more sense and, as you stated in the article, pushing the=
 request objects mitigates the issues with request-size and complexity on t=
he client side.

> In our case we may also have a requirement to encrypt the pushed reque=
st object due to potential sensitive content.



TLS is not enough?



kind regards,

Torsten. 



> 

> - Steinar

> 

> 

> l=C3=B8r. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <torsten@lodderstedt.=
net>:

> Hi all, 

> 

> I just published an article about the subject at: https://medium.=
com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scop=
es-2326e2038948=C2=A0 

> 

> I look forward to getting your feedback.

> 

> kind regards,

> Torsten. 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> -- 

> Vennlig hilsen

> 

> Steinar Noem

> Partner Udelt AS

> Systemutvikler

>=C2=A0 

> | steinar@udelt.=
no | hei@udelt.no=
=C2=A0 | +47 955 21 620 | www.udelt.no | 






-- 
Vennlig hilsen=


Steinar Noem
Partner Udelt AS
Systemutvikler<=
/div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n=
o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.=
no=C2=A0|=C2=A0


--0000000000002f5bb6058730c19b--


From nobody Tue Apr 23 04:32:29 2019
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 4929B12033E for ; Tue, 23 Apr 2019 04:32:27 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZH64ma1kZCbw for ; Tue, 23 Apr 2019 04:32:25 -0700 (PDT)
Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 24F61120045 for ; Tue, 23 Apr 2019 04:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556019144; bh=huUOC5O97QsvQkGlhgw2hYeV+/kIBGIozJKVamw2fH0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=advU92qeuoLRqN/DPvkm/1PJhgWLJcL4XXGJ2YfQ15j62pbLtRfkHaylEw+LZMT1XuWOSrWUnxvu2CJ+4pazMenxOh83CFcwEYnCG12qCyQLWCd3ETms4v9DYwMmzfCL3S9FPkPqb1w86Hh6Y5+QZivixS3Hs0DEElh7vhqqrGHoaxqFzHkEDpshb6kyjSQy396JcOttWYx5MtwG5IQJnTHPh9mk7wvU1dknrMt8B2sqdwT7t/kRmqsu3Wlz6ofsZBe/zpUmmDZbOzXhEVr9t6GPeEVVw2rfQbJl2/L79KVyHi3Pa+Bno6lwappu8+uAnogM5J/ExZ8JzjYeNAP0vg==
X-YMail-OSG: uQj2ZscVM1lS4SM5UwWsz1K0BHWrcqArm07zcXg1ZAn6uV.2lf6rx.IxOUwC33U 6dq02ARqb8vUrcxWZoI11mX9ywu0GQxfr17fmcQDsy7H3wTmToff4z_JP5XcT9gA1z1LL2UrToJF 1mhuSfr2hVWZ23UDChPncE08uCFaGthHnPFdUBXBXub9frgOPGf0wR3xVMP8YHEqUlb8K.xLvOkV JYWezob2lKODJ8lzpAYg1rtUugF1WUrsEhJXqry9_WJtL8RKk5luJ2KMILmLtzzf3kUyuZFzko5Z qFLKeRgLACdDYeTncd9eR8YdGYhdwWE8HJpDeirWrDpr41xi19nGmBGxUDwAfAZckUMfhvez5xFd WvP8boaA0EIh6._2Hj8mIixu.KL7UTACN7Z99.Tq_GUg3Rr6lxE1RMHp7NNYEN5DtrHl_YKvq9Bb QBlTNb_x.v20nSvYAhpDlQRJe2zOcq5KiBliniTA3.PmKQ9omgJcZo_kEfo2hNQXH43NauoLX2kU fw2uOzS_aChfj1n7sVv2QKr0btoWlO1mZJepjzGn9QwxTN.upOEB94xbvgDszcByPHNpSI.t.HoU OzmTcayIA_7TULxWFafIVBnEPntWprvHLMLN2e5dzEzp9iAzY6Xz1CPN3dhOWeEF3fgmFO8h1QiN 6XMS6S03U2azdfkmlwgvkLEykYL45hy7TwPHNALZ17Ls_RfhI2UXJeKtBE3EVb0nCeRGmCO44tTE Ylkcnw_50elCFwBTWJpv.aSt.TuoDVGrwdI1WGnPddOTPMRoICbHul50XI2opDitXj87cubUCLjk oR8A2IAUqSo7VdwwhXk9FnLewXXJTSgq8hhEm0xXKebyIsGN7uxeYizPNqaUTl.AGR8pQt4_YHFN HidSBtyaFHijH7f2OuNZhfyHJIMqtmFSFHJ6VC7LBtFSNfw2W64Ct9qGDhQLBFkEErKiCNX.mtci pOoa7HMub.YlA1FdPRuj0PTzhZ2XkReZI5Gk5K1f6YFjBFvlbn2UtkR3uwi9DJUC1x6gjY1WgCLG jChRjH_PuxUA2uBCPOawdLbzOaj3svoYFbKmgNZmDLapFEDGcaYKLbrUyw5EaLmjNGyALiHp2lqt h3fJ2MncrxJqCzJ7Ri4z7_rvgdxXrqB3hvCbABw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Apr 2019 11:32:24 +0000
Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.130.101]) ([184.165.8.97]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6ca11eb9e404b53fccbf11c0966c32eb;  Tue, 23 Apr 2019 11:32:23 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: Pedro Igor Silva , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>   <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Tue, 23 Apr 2019 07:32:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------73129D378A24826BDE652009"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 11:32:27 -0000

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

Yes, from 3.3.1 of the UMA OAuth2 grant...

scope
    OPTIONAL. A string of space-separated values representing requested
    scopes. For the authorization server to consider any requested scope
    in its assessment, the client MUST have pre-registered the same
    scope with the authorization server. The client should consult the
    resource server's API documentation for details about which scopes
    it can expect the resource server's initial returned permission
    ticket to represent as part of the authorization assessment (see
    Section 3.3.4
    ).

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization

On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:
> Does UMA use the standard scope parameter?
>
> Am 22.04.2019 um 21:03 schrieb George Fletcher  >:
>
>> Speaking just to the UMA side of things...
>>
>> ...it's possible in UMA 2 for the client to request additional scopes 
>> when interacting with the token endpoint specifically to address 
>> cases where the client knows it's going to make the following 
>> requests and wants to obtain a token with sufficient privilege for 
>> those requests. This requires a fair amount of knowledge by the 
>> client of the ecosystem but that is sometimes the case and hence this 
>> capability exists :)
>>
>> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>>> The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent.
>>


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


  
    
  
  
    Yes, from 3.3.1 of the UMA
      OAuth2 grant...

    

      
scope

      
OPTIONAL. A string of space-separated values representing
        requested scopes. For the authorization server to consider any
        requested scope in its assessment, the client MUST have
        pre-registered the same scope with the authorization server. The
        client should consult the resource server's API documentation
        for details about which scopes it can expect the resource
        server's initial returned permission ticket to represent as part
        of the authorization assessment (see Section 3.3.4).

    
    
https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization

    

    
On 4/23/19 1:04 AM, Torsten Lodderstedt
      wrote:

    

    

      
      
Does UMA use the standard scope parameter?

      


        Am 22.04.2019 um 21:03 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          Speaking just to the
            UMA side of things... 

            

            ...it's possible in UMA 2 for the client to request
            additional scopes when interacting with the token endpoint
            specifically to address cases where the client knows it's
            going to make the following requests and wants to obtain a
            token with sufficient privilege for those requests. This
            requires a fair amount of knowledge by the client of the
            ecosystem but that is sometimes the case and hence this
            capability exists :)

          

          
On 4/22/19 1:18 PM, Torsten
            Lodderstedt wrote:

          

          

            
The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent. 

          

          

        

      

    

    

  


--------------73129D378A24826BDE652009--


From nobody Tue Apr 23 04:33:32 2019
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 63261120049 for ; Tue, 23 Apr 2019 04:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d44lezP6e773 for ; Tue, 23 Apr 2019 04:33:27 -0700 (PDT)
Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 A9F681201EF for ; Tue, 23 Apr 2019 04:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556019204; bh=J45ltvZo9XpFa/m9ZQCNGCDT37oh1rykGy0J93rR/do=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=cI0qskMfRC+G1k6Kg8a6Jl/0GInmS9FfpR+IhkyWNYCK8HDOujbHjj2hhBfy0uCCRx1aqd89H7u+8YVEjigSz68iRHpGHD1YWjV4rPHXeHd9muClv4poZdeh5N5nMuY9a6yppyTHvdS0V1yIw5svi1UoJIaGg7TwWvyU2iin4H3RJqKBvUNuSoF4g+GDvOqkbGEkiUupqyzhAgTjAIOVNlA3QVbpXQXgrHLEwAfscdtSNxQ/NEjL260CWuyjeCA7llnwjWZCQ4yzd87t9PBJQ8DLatVesFiQlYoI62BRnaP/PWQMovA7wDsQ9uV9kC8uK3VyrSk3RMn7Z4u7KntAgQ==
X-YMail-OSG: CyZkfF8VM1mXI05MIDAUkQgswTz9eaV.ya1GBq1GYt1fSsa7CFoMUL4IN4__VRt INcaxcX47b9Pi4OzT5yFkR4Hyw0HGNc4wB0THOWF3VfDOS6cDvIs_yyRScxIM8J5zGKeP2xe0XC0 fsK03ERx3F7BgCOtpWy4qZY8HmqNWzmszMyquU5z5rDiTXzqfusYLzCUosufJObkKey2ioE8amGg _TJVjkclMgcpaC5V0nkb4_JH.PuLhq22erSLOeE57hbHQBOMPKNwNHI9Yee.QB1Hg8a_YS9eTmt6 A4s2ljS2t4OJ.dhBkeard9jtTIbb.lJ27ea.Bpr0TXreH3FMcuIrjFvtq6WNMi2.VBCvFrFnp.dU w5K1WSFGd1wzI1CZXECNQVvH0PyEUA0CvYRwMcpO1Lb6u.xCZAbuwcsAcZEMzCsLM.GFi3CS7Fjm 1ZVwYBn_3aAzMPiEsyPkLfSgeikXpN7mWbGMY6RTqwDmGNMkySn5xnyqCfwwa5e3r9VCqKTLDZaS o1O_u4NzCZbU1eVqFMfckD7Kqa.IiHFJlUmqn7VZ8yejyjk8IHTLcKFZLxyOMJ0.DmbHshQL7jzQ dSc9RD3Z__erZ6NbhRtMdtILFP0jslLlYu0TiOpE8L6Ex7dYygdS_LWgTbF2ebnw_Nt2FJEuZP7M CvotG4u0qLml5v1EL6mUqURVBcvupQg2KRxC6ip.R7hh_DsFkBH1nu7xjqqp9BqYdShhq95a5x7B xCmTjnVZVayuaSIPFbsp6xEezxUwd8IRRW3ndeMchdsPCQGysxrY623nbdYe9qlaDKtZDFkmxRTV 6GpUn8hT1B3z.tQPfITZmKRHId1xA8dHKF8j5jrahPNcOSfphTlZ8H1UNIHc.ytO09WQKOcx3Lk5 xqKkwqn9GW0ReKUg7IQ24Buof9m0Y.UNuurRf.XRQnxqv4_lTMT6k0zpI9VBOAvQPr6bLvdQY4Qx QkwQH9AYLihXrYmf_rKlU5xR9qv__HnHKE_sMRRvUP77Wyxzf16c60onfe27f4ODdUixYdLk.AhM nihjl9_y9uwU.6gLuajRB2JQ9OiwgMvD0CKID09oV2VhJBVGdlRcWvB3b02iTn9ejYRaBnuMXTHV 8XCEra4uoRwPIugIqRpbu_hxedmMXBE3E2Is8Wg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Apr 2019 11:33:24 +0000
Received: from nat-vpn-users2.cfw-a-gci.net.buffalo.office.oath (EHLO [172.135.130.101]) ([184.165.8.97]) by smtp407.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bf97ab0bfffcd458df8bb70ac799e258;  Tue, 23 Apr 2019 11:33:21 +0000 (UTC)
To: Pedro Igor Silva 
Cc: Torsten Lodderstedt , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <2261EA43-063D-4EA5-A55B-15235D5E525E@lodderstedt.net>   <7483a5f0-b3c1-c944-02fa-79e5a1ecc490@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <8387b896-fa89-940f-6dc3-95bd04388bab@aol.com>
Date: Tue, 23 Apr 2019 07:33:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------14622AB43B5C75BEE25533A0"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 11:33:31 -0000

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

I can see use cases where both approaches are useful. I was just 
pointing out that while the RS might not be told the context of the 
request from the client's perspective, the client still knows it's own 
context and can leverage that with UMA at the RS to reduce the need to 
request multiple tokens (which is the issue I understood Torsten to be 
making).

I would also say that in UMA there is some desire to reduce the work the 
RS has to do as well where in Torsten's use case, the RS may be managing 
all the responsibility (for good or ill:)

On 4/22/19 3:36 PM, Pedro Igor Silva wrote:
> I think this knowledge by clients of the ecosystem is something that a 
> transactional authorization could avoid. Both UMA and ACE have 
> solutions that make clients really dumb about what they need to send 
> to the AS in regards to scopes. IMO, the RS should have the 
> possibility to tell clients the scope they need, making a lot easier 
> to change RS's access constraints as well as pushing contextual 
> information that could eventually enrich the authorization process.
>
> On Mon, Apr 22, 2019 at 4:04 PM George Fletcher  > wrote:
>
>     Speaking just to the UMA side of things...
>
>     ...it's possible in UMA 2 for the client to request additional
>     scopes when interacting with the token endpoint specifically to
>     address cases where the client knows it's going to make the
>     following requests and wants to obtain a token with sufficient
>     privilege for those requests. This requires a fair amount of
>     knowledge by the client of the ecosystem but that is sometimes the
>     case and hence this capability exists :)
>
>     On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>>     The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent.
>


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


  
    
  
  
    I can see use cases where both approaches are useful. I was just
    pointing out that while the RS might not be told the context of the
    request from the client's perspective, the client still knows it's
    own context and can leverage that with UMA at the RS to reduce the
    need to request multiple tokens (which is the issue I understood
    Torsten to be making).

    

    I would also say that in UMA there is some desire to reduce the work
    the RS has to do as well where in Torsten's use case, the RS may be
    managing all the responsibility (for good or ill:)

    

    
On 4/22/19 3:36 PM, Pedro Igor Silva
      wrote:

    

    

      
      

        
I think this knowledge by clients of the ecosystem is
          something that a transactional authorization could avoid. Both
          UMA and ACE have solutions that make clients really dumb about
          what they need to send to the AS in regards to scopes. IMO,
          the RS should have the possibility to tell clients the scope
          they need, making a lot easier to change RS's access
          constraints as well as pushing contextual information that
          could eventually enrich the authorization process. 

        

        

        

          
On Mon, Apr 22, 2019 at 4:04
            PM George Fletcher <gffletch@aol.com> wrote:

          

          

            
 Speaking just to the UMA side of things... 

                

                ...it's possible in UMA 2 for the client to request
                additional scopes when interacting with the token
                endpoint specifically to address cases where the client
                knows it's going to make the following requests and
                wants to obtain a token with sufficient privilege for
                those requests. This requires a fair amount of knowledge
                by the client of the ecosystem but that is sometimes the
                case and hence this capability exists :)

              

              
On
                4/22/19 1:18 PM, Torsten Lodderstedt wrote:

              

              

                
The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent. 

              

              

            

          

        

      

    

    

  


--------------14622AB43B5C75BEE25533A0--


From nobody Tue Apr 23 08:15:56 2019
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 B71EC1203ED for ; Tue, 23 Apr 2019 08:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EVGE4CZ4Rj63 for ; Tue, 23 Apr 2019 08:15:50 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25AE1203F7 for ; Tue, 23 Apr 2019 08:15:50 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id q19so722900itk.3 for ; Tue, 23 Apr 2019 08:15:50 -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=E2pwetC3gmph2XYKzseQJb1Btq3Ec7uflL0s+eN9+TY=; b=VJXBQG69pOYvR7g1nvl9u1kXy3sAnEappddWlu+wizDQ+QsvvYsodIObsNcR+U4Kzj hz+4uUV4V9qLXKfKgReT8FEcnB9K+d/xhM1HKuHG1SvzU6ULFULr+DcdXEdza37mdtum CXGCRiUgyO2DkbUv3L8bfjBYZ40GVfZ9RSFKgEG4g8e/p/OfZ4XCQGIcTKsYzegmjGvE fiNGaKeFzFtWL+9gzAEuKJG0PETqGAqViWv+tTtGrNfjRtC8e/nvPMANNilN4fNq0e5R gJOlPGgqiDbDEuCkOVnRCWOoVsM1go1QMKt6l1C6EHta1IkTEuAlOr4RhHufROotyNon jdrw==
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=E2pwetC3gmph2XYKzseQJb1Btq3Ec7uflL0s+eN9+TY=; b=QEMXKTSDM7EtSH3qaB/P5ksoXBNEi/aY3nISOPacpDF28KewcYcTrBwsopknXGj+V/ KtYl4nePaESjFLyt9s9vz9fpL8KfmuqKUHsVU1HiUbaxmVm+KGem7eY0Vd7h9h/eHwRE 4LcEgYee2lC+lZ4jlfHuTtHQWIAauq0QCKeVe+MFngRmEPZlUwO/1nSPBAzAjLJ3ycaZ 7jJOzjAJTmAVjqMbqi5R9kaDpV16ua2mNJnlQir5Xzr0TD9399ZpvodP2nkavK9mGcHJ uXV6lSAxuPGneqwWIMHohl05VgsBVepsishGYdNmSndITdaN57qkNQCUHle/dPNrY+CD rgnQ==
X-Gm-Message-State: APjAAAUpCgAz2XanL7pftERvOx8N10tZt+RD8Wx9IabL3sZruk5RDYHI uHVRKZzzJTg51k4dcqq7aNKW/ExGgM/0TZ+lHHur78jCh/1QMQ==
X-Google-Smtp-Source: APXvYqwUirBpCTptZ6rC0YimNiQZoxplOCysdbbUtj4YKZm4FLbH+6jjgm3tBOrsiwNaGPk5NYyluC8/BYmrkVzy1QU=
X-Received: by 2002:a24:9414:: with SMTP id j20mr2373913ite.91.1556032549877;  Tue, 23 Apr 2019 08:15:49 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>
In-Reply-To: <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>
From: Sascha Preibisch 
Date: Tue, 23 Apr 2019 08:14:44 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 15:15:53 -0000

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:
>
> Hi Sascha,
>
> > Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
> >
> > Thank you for the article, Torsten!
>
> my pleasure :-)
>
> >
> > I like that 'scope' is out of the game for these kinds of authorizations.
> >
> > What I can see for the general use case is a required identifier
> > within the 'structures_scope' document that identifies the profile it
> > should be used for.
>
> What does profile mean in this context?
>
> best regards,
> Torsten.
> >
> > Thank you,
> > Sascha
> >
> > Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> > :
> >>
> >> Hi all,
> >>
> >> I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
> >>
> >> I look forward to getting your feedback.
> >>
> >> kind regards,
> >> Torsten.
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Apr 24 10:08:40 2019
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 DDECA1203CE for ; Wed, 24 Apr 2019 10:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 B02CDqk_hBea for ; Wed, 24 Apr 2019 10:08:34 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 D6A91120226 for ; Wed, 24 Apr 2019 10:08:28 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hJLNi-0006yJ-7x; Wed, 24 Apr 2019 19:08:26 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Wed, 24 Apr 2019 19:08:25 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net> 
To: Sascha Preibisch 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2019 17:08:39 -0000

Hi Sascha,

I see. I assume every element within the structured scope element to be =
an independent scope (value) object and intended to use the name of that =
object as kind of content type definition.=20

In my last example, the scope is defined as=20

   "structured_scope":{ =20
      "sign":{ =20
         "credentialID":"qes_eidas",
         "documentDigests":[ =20
            { =20
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{ =20
         "type":"sepa-credit-transfer",
         "instructedAmount":{ =20
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{ =20
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{ =20
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means =E2=80=9Csign" and =E2=80=9Cpayment" would determine the =
scheme of the respective object.=20

What do you think?

best regards,=20
Torsten.=20

> On 23. Apr 2019, at 17:14, Sascha Preibisch =
 wrote:
>=20
> Hi Torsten!
>=20
> If 'structured_scope' would become a generic field for application
> specific content, I believe an indicator for the type of content would
> be needed on the long run. That is what I meant my 'profile'. I hope
> this helps!
>=20
> Thank you,
> Sascha
>=20
> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
> :
>>=20
>> Hi Sascha,
>>=20
>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch =
:
>>>=20
>>> Thank you for the article, Torsten!
>>=20
>> my pleasure :-)
>>=20
>>>=20
>>> I like that 'scope' is out of the game for these kinds of =
authorizations.
>>>=20
>>> What I can see for the general use case is a required identifier
>>> within the 'structures_scope' document that identifies the profile =
it
>>> should be used for.
>>=20
>> What does profile mean in this context?
>>=20
>> best regards,
>> Torsten.
>>>=20
>>> Thank you,
>>> Sascha
>>>=20
>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>> :
>>>>=20
>>>> Hi all,
>>>>=20
>>>> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948
>>>>=20
>>>> I look forward to getting your feedback.
>>>>=20
>>>> kind regards,
>>>> Torsten.
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Apr 25 00:27:17 2019
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 7A1E1120155 for ; Thu, 25 Apr 2019 00:27:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WjO1_clixoEq for ; Thu, 25 Apr 2019 00:27:09 -0700 (PDT)
Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (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 2009312002E for ; Thu, 25 Apr 2019 00:27:08 -0700 (PDT)
From: Jaap Francke 
To: "oauth@ietf.org" 
Thread-Topic: Transaction Authorization with OAuth (Torsten Lodderstedt)
Thread-Index: AQHU+zhINZZlusRlskuXC59Zp2p6Ig==
Date: Thu, 25 Apr 2019 07:27:05 +0000
Message-ID: <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>
References: 
In-Reply-To: 
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.17.5.138]
Content-Type: multipart/alternative; boundary="_000_74A378B3B81A4199938BE576FD1AA66Ciwelcomecom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
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, 25 Apr 2019 07:27:14 -0000

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

SGkgVG9yc3RlbiBhbmQgb3RoZXJzLA0KDQpJIGp1c3QgcmVhZCB5b3VyIGJsb2cgLSBoYXZpbmcg
4oCcd2UgbmVlZCB0byByZS10aGluayBPQXV0aCBzY29wZXPigJ0gaW4gdGhlIHRpdGxlIGltbWVk
aWF0ZWx5IGRyZXcgbXkgYXR0ZW50aW9uLg0KSSBmaW5kIHRoaXMgaW50ZXJlc3Rpbmcgc2luY2Ug
SeKAmW0gc3RydWdnbGluZyB3aXRoIHRoZSBjb25jZXB0IG9mIHNjb3BlcyBmcm9tIHRpbWUtdG8t
dGltZS4NCknigJlsbCBoYXZlIHRvIHJlYWQgdGhlIGJsb2cgYSBmZXcgdGltZXMgbW9yZSB0byBn
ZXQgYSBnb29kIHVuZGVyc3RhbmRpbmcsIGJ1dCBJIHdvdWxkIGxpa2UgdG8gc2hhcmUgc29tZSBv
ZiBteSB0aG91Z2h0cyBvbiBzY29wZXMuDQoNCkkgYmVsaWV2ZSB0aGUgT0F1dGggc2NvcGUgY29u
Y2VwdCBoYXMgaXTigJlzIGxpbWl0YXRpb25zIG5vdCBvbmx5IGZvciB0cmFuc2FjdGlvbnMgYnV0
IGFsc28gZm9yIHRoZSBtb3JlIHRyYWRpdGlvbmFsIOKAmHJlc291cmNl4oCZIGNvbmNlcHQuDQpS
RkMgNjc0OSBkZWZpbmVzIHNjb3BlcyBhcyBmb2xsb3dzOg0KIlRoZSB2YWx1ZSBvZiB0aGUgc2Nv
cGUgcGFyYW1ldGVyIGlzIGV4cHJlc3NlZCBhcyBhIGxpc3Qgb2Ygc3BhY2UtDQogICBkZWxpbWl0
ZWQsIGNhc2Utc2Vuc2l0aXZlIHN0cmluZ3MuICBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBieSB0
aGUNCiAgIGF1dGhvcml6YXRpb24gc2VydmVyLiAgSWYgdGhlIHZhbHVlIGNvbnRhaW5zIG11bHRp
cGxlIHNwYWNlLWRlbGltaXRlZA0KICAgc3RyaW5ncywgdGhlaXIgb3JkZXIgZG9lcyBub3QgbWF0
dGVyLCBhbmQgZWFjaCBzdHJpbmcgYWRkcyBhbg0KICAgYWRkaXRpb25hbCBhY2Nlc3MgcmFuZ2Ug
dG8gdGhlIHJlcXVlc3RlZCBzY29wZS7igJ0NCg0KSSBzZWUgMiBhc3BlY3RzIGluIHRoaXMgZGVm
aW5pdGlvbjoNCi0gaG93IHRoZSBzdHJpbmdzIHNob3VsZCBsb29rIGxpa2UgaXMgYmV5b25kIHRo
ZSBzY29wZSBvZiB0aGUgUkZDDQotIGVhY2ggc3RyaW5nIGFkZHMgYW4gYWRkaXRpb25hbCBhdXRo
b3Jpc2F0aW9uDQoNClNjb3BlcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGFjY2Vzc190b2tlbnMsIHdo
aWNoIHR5cGljYWxseSBhcmUgYmVhcmVyIHRva2VucyBhcyBkZWZpbmVkIGJ5IFJGQyA2NzUwIGFz
Og0KICAgICAgQSBzZWN1cml0eSB0b2tlbiB3aXRoIHRoZSBwcm9wZXJ0eSB0aGF0IGFueSBwYXJ0
eSBpbiBwb3NzZXNzaW9uIG9mDQogICAgICB0aGUgdG9rZW4gKGEgImJlYXJlciIpIGNhbiB1c2Ug
dGhlIHRva2VuIGluIGFueSB3YXkgdGhhdCBhbnkgb3RoZXINCiAgICAgIHBhcnR5IGluIHBvc3Nl
c3Npb24gb2YgaXQgY2FuLiAgVXNpbmcgYSBiZWFyZXIgdG9rZW4gZG9lcyBub3QNCiAgICAgIHJl
cXVpcmUgYSBiZWFyZXIgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBjcnlwdG9ncmFwaGljIGtleSBt
YXRlcmlhbA0KICAgICAgKHByb29mLW9mLXBvc3Nlc3Npb24pLuKAnQ0KDQpUaGlzIGltcGxpZXMg
dGhhdCBldmVyeSBzY29wZSB2YWx1ZSBzaG91bGQgZnVsbHkgZGVzY3JpYmUgdGhlIGF1dGhvcmlz
YXRpb24gdGhhdCBpcyBnaXZlbi4gSW4gbXkgdmlldyB0aGF0IGlzIHJhcmVseSBkb25lLCB3aGlj
aCBpcyB0aGUgbWFpbiByZWFzb24gd2h5IEkgZmluZCBteXNlbGYgc3RydWdnbGluZyB3aXRoIHNj
b3BlLWNvbmNlcHQuDQoNCkhlcmUgd2UgaGF2ZSBhIGNvbGxlY3Rpb24gb2YgZXhhbXBsZXMsIHdo
aWNoIGRlbW9uc3RyYXRlIHRvIG1lIHRoYXQgZXZlcnlvbmUgaXMgaW52ZW50aW5nIHRoZWlyIG93
biB3aGVlbHMgYWNjb3JkaW5nIHRvIHRoZWlyIHNwZWNmaWMgbmVlZHM6DQpodHRwczovL2JyYW5k
dXIub3JnL29hdXRoLXNjb3BlDQpodHRwczovL2FwaS5zbGFjay5jb20vZG9jcy9vYXV0aC1zY29w
ZXMNCg0KSW4gdmFyaW91cyBvdGhlciAoZHJhZnQpIHN0YW5kYXJkcyBJIHNlZSBiaXRzIGFuZCBw
aWVjZXMgdGhhdCBzZWVtIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4NCg0KSW4gVU1BIGFuIGF1dGhv
cmlzYXRpb24gaXMgY29uY2VwdHVhbGx5IGJyb2tlbiBkb3duIGludG86DQotIHN1YmplY3QgLT4g
cmVxdWVzdGluZyBwYXJ0eQ0KLSB2ZXJicyAtPiBzY29wZXMgb2YgYWNjZXNzDQotIG9iamVjdCAt
PiByZXNvdXJjZSBzZXQuDQpJIGxpa2UgdGhpcyBsaW5lIG9mIHRoaW5raW5nIGFuZCB0ZXJtaW5p
bG9neS4gIEhvd2V2ZXIsIGlmIGFjY2Vzc190b2tlbnMgYXJlIGJlYXJlciB0b2tlbnMsIEkgdGhp
bmsg4oCZc3ViamVjdOKAmSBpcyB0aGUgYmVhcmVyIG9mIHRoZSB0b2tlbi4NCg0KDQpUaGUgbW9z
dCBjb21tb24gcHJhY3RpY2UsIEkgdGhpbmssIGlzIHRvIHVzZSBPSURD4oCZcyBJRFRva2VucyB0
byBjb250YWluIGEgc2V0IG9mIGNsYWltcyB0aGF0IHNjb3BlIHRoZSBzY29wZSBvZiB0aGUgc2Nv
cGUgOi0pLg0KDQpJIG1lYW4gdGhhdCB0aGUgY2xhaW1zIGluIHRoZSBJRC1Ub2tlbnMgYXJlIHVz
ZWQgdG8gc2NvcGUgdGhlIG9iamVjdHMgYXMgd2VsbCBhcyB0aGUgdmVyYnMvc2NvcGVzIG9mIGFj
Y2Vzcy4NCg0KVGhlIGNvcmUgaW50ZW50aW9uIGJlaGluZCBJRC10b2tlbiBpcyB0byBwcm92aWRl
IGluZm9ybWF0aW9uIGFib3V0IHRoZSBhdXRoZW50aWNhdGVkIHVzZXIgYW5kIG5vdCBuZWNlc3Nh
cmlseSBhYm91dCB0aGUgcmVzb3VyY2VzIHRoYXQgYXJlIGFjY2Vzc2VkLiBJbiBwcmFjdGljZSwg
Y2xhaW1zIGFib3V0IHRoZSBhdXRoZW50aWNhdGVkIHVzZXJzIGluZGljYXRlIHdoaWNoIHJlc291
cmNlcyAocGhvdG9zKSBjYW4gYmUgYWNjZXNzZWQgYXQgdGhlIHJlc291cmNlIHNlcnZlci4NCg0K
DQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMg0KDQppcyB0aGF0IHRo
ZSBvYmplY3QvcmVzb3VyY2UgYXNwZWN0IG9mIGF1dGhvcmlzYXRpb24gaXMgdGFrZW4gc29tZXdo
YXQgb3V0IG9mIHRoZSBzY29wZSBhbmQgcHV0IGludG8gYSBkZWRpY2F0ZWQgcGFyYW1ldGVyLiBB
bHRob3VnaCAodXNpbmcgdGhlIGV4YW1wbGUgZnJvbSBSRkMgNjc0OSkgdGhlIHJlc291cmNlIHBh
cmFtZXRlciBpbmRpY2F0ZXMgdGhlIHJlc291cmNlIHNlcnZlciAob3IgYXBwbGljYXRpb24sDQoN
CiAgIEFQSSwgZXRjLikgcmF0aGVyIHRoYW4gYW4gaW5kaXZpZHVhbCByZXNvdXJjZSB0aGF0IGlz
IHN0b3JlZCBhdCB0aGUgcmVzb3VyY2Ugc2VydmVyLiBTbyBhZGRpdGlvbmFsIHNjb3Bpbmcgb2Yg
b2JqZWN0L3Jlc291cmNlIHNldCBpcyBzdGlsbCBuZWVkZWQgaW4gYWRkaXRpb24gdG8gdGhlIHJl
c291cmNlIHBhcmFtZXRlci4NCg0KDQpGdXJ0aGVybW9yZSwgaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2VjdXJpdHktdG9waWNzLTEyIG1ha2VzIHNvbWUgaW50
ZXJlc3Rpbmcgc3RhdGVtZW50cyB0aGF0IGFyZSByZWxldmFudCBpbiBteSB2aWV3Og0KVGhlIHNl
Y3Rpb24gb24gQWNjZXNzIFRva2VuIHByaXZpbGVnZSByZXN0cmljdGlvbiBzYXlzICJhY2Nlc3Mg
dG9rZW5zIFNIT1VMRCBiZSByZXN0cmljdGVkIHRvIGNlcnRhaW4gcmVzb3VyY2VzDQoNCiAgIGFu
ZCBhY3Rpb25zIG9uIHJlc291cmNlIHNlcnZlcnMgb3IgcmVzb3VyY2VzLuKAnSBTbyB0aGUgT0F1
dGggc2NvcGUtc3RyaW5nIHN0aWxsIG5lZWRzIHRvIHNvbWVob3cgaW5kaWNhdGUgdGhlIHJlc291
cmNlLXNjb3BlIG9mIHRoZSBwcml2aWxlZ2UgdGhhdCBpcyBjb21tdW5pY2F0ZWQuDQoNCg0KIiBU
aGUgY2xpZW50IG5lZWRzIHRvIHRlbGwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhdCB3aGlj
aCBVUkwgaXQNCg0KICAgd2lsbCB1c2UgdGhlIGFjY2VzcyB0b2tlbiBpdCBpcyByZXF1ZXN0aW5n
LiAgSXQgY291bGQgdXNlIHRoZQ0KICAgbWVjaGFuaXNtIHByb3Bvc2VkIFtJLUQuaWV0Zi1vYXV0
aC1yZXNvdXJjZS1pbmRpY2F0b3JzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0xMiNyZWYtSS1ELmlldGYtb2F1dGgtcmVzb3VyY2Ut
aW5kaWNhdG9ycz5dIG9yIGVuY29kZSB0aGUNCiAgIGluZm9ybWF0aW9uIGluIHRoZSBzY29wZSB2
YWx1ZS7igJ0NCg0KDQpJ4oCZbSBub3Qgc3VyZSB3aGljaCBwb2ludCBJ4oCZbSB0cnlpbmcgdG8g
bWFrZTsgaSBndWVzcyB0aGUgbmVlZCBmb3Igc3RhbmRhcmRpc2F0aW9uIGhvdyB0byB1c2UgYW5k
IGRlZmluZSBPQXV0aC1zY29wZXMuDQoNCkkgbGlrZSB0aGUgTG9kZ2luZyBJbnRlbnQgUGF0dGVy
biBhbmQgbmVlZCB0byBkbyBzb21lIG1vcmUgcmVhZGluZy90aGlua2luZyBhYm91dCB0aGUgc3Ry
dWN0dXJlZC1zY29wZSBhbmQgcHVzaGVkIHJlcXVlc3Qgb2JqZWN0cy4NCg0KSSBmZWVsIHRoZXNl
IGNvbmNlcHRzIGFyZSBub3Qgb25seSByZWxldmFudCBmb3IgYXV0aG9yaXNhdGlvbiBvZiB0cmFu
c2FjdGlvbnMsIGJ1dCBhbHNvIGZvciBhbnkgYWNjZXNzIHRoYXQgbmVlZHMgYXV0aG9yaXNhdGlv
bi4NCg0KDQpJ4oCZbSBub3Qgc3VyZSBpZiBpIGV4cHJlc3MgbXlzZWxmIGNsZWFybHksIG5ldmVy
dGhlbGVzcyBhbnkgZmVlZGJhY2sgaXMgd2VsY29tZSwgaWYgbm90IGFsb25lIHRvIGdldCBteSB1
bmRlcnN0YW5kaW5nIG9mIHRoZSB2YXJpb3VzIGNvbmNlcHRzIG9uIGEgaGlnaGVyIGxldmVsLg0K
DQoNClRoYW5rcyBpbiBhZHZhbmNlLCBraW5kIHJlZ2FyZHMNCg0KDQpKYWFwDQoNCg0KDQoNCg0K
DQoNCk1lc3NhZ2U6IDENCkRhdGU6IFdlZCwgMjQgQXByIDIwMTkgMTk6MDg6MjUgKzAyMDANCkZy
b206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+DQpUbzogU2FzY2hhIFByZWliaXNjaCA8c2FzY2hhcHJl
aWJpc2NoQGdtYWlsLmNvbTxtYWlsdG86c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbT4+DQpDYzog
b2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBUcmFuc2FjdGlvbiBBdXRob3JpemF0aW9uIHdpdGggT0F1dGgNCk1lc3Nh
Z2UtSUQ6IDwyOTk3QjU1MC1DODJCLTREM0EtOTYzOS0xNUEwMDRGMkY2QzVAbG9kZGVyc3RlZHQu
bmV0PG1haWx0bzoyOTk3QjU1MC1DODJCLTREM0EtOTYzOS0xNUEwMDRGMkY2QzVAbG9kZGVyc3Rl
ZHQubmV0Pj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtOA0KDQpIaSBT
YXNjaGEsDQoNCkkgc2VlLiBJIGFzc3VtZSBldmVyeSBlbGVtZW50IHdpdGhpbiB0aGUgc3RydWN0
dXJlZCBzY29wZSBlbGVtZW50IHRvIGJlIGFuIGluZGVwZW5kZW50IHNjb3BlICh2YWx1ZSkgb2Jq
ZWN0IGFuZCBpbnRlbmRlZCB0byB1c2UgdGhlIG5hbWUgb2YgdGhhdCBvYmplY3QgYXMga2luZCBv
ZiBjb250ZW50IHR5cGUgZGVmaW5pdGlvbi4NCg0KSW4gbXkgbGFzdCBleGFtcGxlLCB0aGUgc2Nv
cGUgaXMgZGVmaW5lZCBhcw0KDQogICJzdHJ1Y3R1cmVkX3Njb3BlIjp7DQogICAgICJzaWduIjp7
DQogICAgICAgICJjcmVkZW50aWFsSUQiOiJxZXNfZWlkYXMiLA0KICAgICAgICAiZG9jdW1lbnRE
aWdlc3RzIjpbDQogICAgICAgICAgIHsNCiAgICAgICAgICAgICAgImhhc2giOg0KICAgICAgICAg
ICAgICAgICJzVE9nd09tKzQ3NGdGajBxMHgxaVNOc3BLcWJjc2U0SWVpcWxEZy9IV3VJPSIsDQog
ICAgICAgICAgICAgICJsYWJlbCI6Ik1vYmlsZSBTdWJzY3JpcHRpb24gQ29udHJhY3QiDQogICAg
ICAgICAgIH0NCiAgICAgICAgXSwNCiAgICAgICAgImhhc2hBbGdvcml0aG1PSUQiOiIyLjE2Ljg0
MC4xLjEwMS4zLjQuMi4xIg0KICAgICB9LA0KICAgICAicGF5bWVudCI6ew0KICAgICAgICAidHlw
ZSI6InNlcGEtY3JlZGl0LXRyYW5zZmVyIiwNCiAgICAgICAgImluc3RydWN0ZWRBbW91bnQiOnsN
CiAgICAgICAgICAgImN1cnJlbmN5IjoiRVVSIiwNCiAgICAgICAgICAgImFtb3VudCI6IjEyMy41
MCINCiAgICAgICAgfSwNCiAgICAgICAgImRlYnRvckFjY291bnQiOnsNCiAgICAgICAgICAgImli
YW4iOiJERTQwMTAwMTAwMTAzMzA3MTE4NjA4Ig0KICAgICAgICB9LA0KICAgICAgICAiY3JlZGl0
b3JOYW1lIjoiTWVyY2hhbnQxMjMiLA0KICAgICAgICAiY3JlZGl0b3JBY2NvdW50Ijp7DQogICAg
ICAgICAgICJpYmFuIjoiREUwMjEwMDEwMDEwOTMwNzExODYwMyINCiAgICAgICAgfSwNCiAgICAg
ICAgInJlbWl0dGFuY2VJbmZvcm1hdGlvblVuc3RydWN0dXJlZCI6Im5ldyBTbWFydHBob25lIg0K
ICAgICB9DQoNClRoaXMgbWVhbnMgP3NpZ24iIGFuZCA/cGF5bWVudCIgd291bGQgZGV0ZXJtaW5l
IHRoZSBzY2hlbWUgb2YgdGhlIHJlc3BlY3RpdmUgb2JqZWN0Lg0KDQpXaGF0IGRvIHlvdSB0aGlu
az8NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KT24gMjMuIEFwciAyMDE5LCBhdCAxNzox
NCwgU2FzY2hhIFByZWliaXNjaCA8c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbTxtYWlsdG86c2Fz
Y2hhcHJlaWJpc2NoQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBUb3JzdGVuIQ0KDQpJZiAnc3Ry
dWN0dXJlZF9zY29wZScgd291bGQgYmVjb21lIGEgZ2VuZXJpYyBmaWVsZCBmb3IgYXBwbGljYXRp
b24NCnNwZWNpZmljIGNvbnRlbnQsIEkgYmVsaWV2ZSBhbiBpbmRpY2F0b3IgZm9yIHRoZSB0eXBl
IG9mIGNvbnRlbnQgd291bGQNCmJlIG5lZWRlZCBvbiB0aGUgbG9uZyBydW4uIFRoYXQgaXMgd2hh
dCBJIG1lYW50IG15ICdwcm9maWxlJy4gSSBob3BlDQp0aGlzIGhlbHBzIQ0KDQpUaGFuayB5b3Us
DQpTYXNjaGENCg0KQW0gTW8uLCAyMi4gQXByLiAyMDE5IHVtIDIyOjA2IFVociBzY2hyaWViIFRv
cnN0ZW4gTG9kZGVyc3RlZHQNCjx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3Rl
bkBsb2RkZXJzdGVkdC5uZXQ+PjoNCg0KSGkgU2FzY2hhLA0KDQpBbSAyMi4wNC4yMDE5IHVtIDIw
OjM0IHNjaHJpZWIgU2FzY2hhIFByZWliaXNjaCA8c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbTxt
YWlsdG86c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbT4+Og0KDQpUaGFuayB5b3UgZm9yIHRoZSBh
cnRpY2xlLCBUb3JzdGVuIQ0KDQpteSBwbGVhc3VyZSA6LSkNCg0KDQpJIGxpa2UgdGhhdCAnc2Nv
cGUnIGlzIG91dCBvZiB0aGUgZ2FtZSBmb3IgdGhlc2Uga2luZHMgb2YgYXV0aG9yaXphdGlvbnMu
DQoNCldoYXQgSSBjYW4gc2VlIGZvciB0aGUgZ2VuZXJhbCB1c2UgY2FzZSBpcyBhIHJlcXVpcmVk
IGlkZW50aWZpZXINCndpdGhpbiB0aGUgJ3N0cnVjdHVyZXNfc2NvcGUnIGRvY3VtZW50IHRoYXQg
aWRlbnRpZmllcyB0aGUgcHJvZmlsZSBpdA0Kc2hvdWxkIGJlIHVzZWQgZm9yLg0KDQpXaGF0IGRv
ZXMgcHJvZmlsZSBtZWFuIGluIHRoaXMgY29udGV4dD8NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rl
bi4NCg0KVGhhbmsgeW91LA0KU2FzY2hhDQoNCkFtIFNhLiwgMjAuIEFwci4gMjAxOSB1bSAxMToy
MSBVaHIgc2NocmllYiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo8dG9yc3RlbkBsb2RkZXJzdGVkdC5u
ZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj46DQoNCkhpIGFsbCwNCg0KSSBqdXN0
IHB1Ymxpc2hlZCBhbiBhcnRpY2xlIGFib3V0IHRoZSBzdWJqZWN0IGF0OiBodHRwczovL21lZGl1
bS5jb20vb2F1dGgtMi90cmFuc2FjdGlvbi1hdXRob3JpemF0aW9uLW9yLXdoeS13ZS1uZWVkLXRv
LXJlLXRoaW5rLW9hdXRoLXNjb3Blcy0yMzI2ZTIwMzg5NDgNCg0KSSBsb29rIGZvcndhcmQgdG8g
Z2V0dGluZyB5b3VyIGZlZWRiYWNrLg0KDQpraW5kIHJlZ2FyZHMsDQpUb3JzdGVuLg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg
bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNClN1YmplY3Q6IERpZ2VzdCBGb290ZXINCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQpFbmQgb2YgT0F1dGggRGlnZXN0LCBWb2wgMTI2LCBJc3N1ZSA1OA0KKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K

--_000_74A378B3B81A4199938BE576FD1AA66Ciwelcomecom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXY+SGkgVG9yc3RlbiBhbmQgb3RoZXJzLDwv
ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBqdXN0IHJlYWQgeW91ciBi
bG9nIC0gaGF2aW5nIOKAnHdlIG5lZWQgdG8gcmUtdGhpbmsgT0F1dGggc2NvcGVz4oCdIGluIHRo
ZSB0aXRsZSBpbW1lZGlhdGVseSBkcmV3IG15IGF0dGVudGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXY+
SSBmaW5kIHRoaXMgaW50ZXJlc3Rpbmcgc2luY2UgSeKAmW0gc3RydWdnbGluZyB3aXRoIHRoZSBj
b25jZXB0IG9mIHNjb3BlcyBmcm9tIHRpbWUtdG8tdGltZS48L2Rpdj4NCjxkaXY+SeKAmWxsIGhh
dmUgdG8gcmVhZCB0aGUgYmxvZyBhIGZldyB0aW1lcyBtb3JlIHRvIGdldCBhIGdvb2QgdW5kZXJz
dGFuZGluZywgYnV0IEkgd291bGQgbGlrZSB0byBzaGFyZSBzb21lIG9mIG15IHRob3VnaHRzIG9u
IHNjb3Blcy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgYmVsaWV2
ZSB0aGUgT0F1dGggc2NvcGUgY29uY2VwdCBoYXMgaXTigJlzIGxpbWl0YXRpb25zIG5vdCBvbmx5
IGZvciB0cmFuc2FjdGlvbnMgYnV0IGFsc28gZm9yIHRoZSBtb3JlIHRyYWRpdGlvbmFsIOKAmHJl
c291cmNl4oCZIGNvbmNlcHQuPC9kaXY+DQo8ZGl2PlJGQyA2NzQ5IGRlZmluZXMgc2NvcGVzIGFz
IGZvbGxvd3M6PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z
dHlsZTogaXRhbGljOyIgY2xhc3M9IiI+JnF1b3Q7VGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJh
bWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlzdCBvZiBzcGFjZS08L3NwYW4+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7IiBjbGFzcz0iIj4mbmJz
cDsmbmJzcDsgZGVsaW1pdGVkLCBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdzLiZuYnNwOyBUaGUgc3Ry
aW5ncyBhcmUgZGVmaW5lZCBieSB0aGU8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFu
IHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIuJm5ic3A7IElmIHRoZSB2YWx1ZSBjb250YWlucyBtdWx0aXBsZSBzcGFj
ZS1kZWxpbWl0ZWQ8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250
LXN0eWxlOiBpdGFsaWM7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgc3RyaW5ncywgdGhlaXIgb3Jk
ZXIgZG9lcyBub3QgbWF0dGVyLCBhbmQgZWFjaCBzdHJpbmcgYWRkcyBhbjwvc3Bhbj48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiIGNsYXNzPSIi
PiZuYnNwOyZuYnNwOyBhZGRpdGlvbmFsIGFjY2VzcyByYW5nZSB0byB0aGUgcmVxdWVzdGVkIHNj
b3BlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyIgY2xhc3M9IiI+4oCd
PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRh
bGljOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyIgY2xhc3M9IiI+SSBzZWUgMiBhc3Bl
Y3RzIGluIHRoaXMgZGVmaW5pdGlvbjo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFu
IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IiBjbGFzcz0iIj4tIGhvdyB0aGUgc3RyaW5ncyBz
aG91bGQgbG9vayBsaWtlIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIFJGQzwvc3Bhbj48L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsiIGNsYXNz
PSIiPi0gZWFjaCBzdHJpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIGF1dGhvcmlzYXRpb248L3NwYW4+
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7IiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+U2NvcGVz
IGFyZSBhc3NvY2lhdGVkIHdpdGggYWNjZXNzX3Rva2Vucywgd2hpY2ggdHlwaWNhbGx5IGFyZSBi
ZWFyZXIgdG9rZW5zIGFzIGRlZmluZWQgYnkgUkZDIDY3NTAgYXM6PC9kaXY+DQo8ZGl2Pg0KPGRp
diBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyIgY2xhc3M9IiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgc2VjdXJpdHkgdG9rZW4gd2l0aCB0aGUgcHJv
cGVydHkgdGhhdCBhbnkgcGFydHkgaW4gcG9zc2Vzc2lvbiBvZjwvc3Bhbj48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiIGNsYXNzPSIiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgdG9rZW4gKGEgJnF1b3Q7YmVhcmVyJnF1b3Q7
KSBjYW4gdXNlIHRoZSB0b2tlbiBpbiBhbnkgd2F5IHRoYXQgYW55IG90aGVyPC9zcGFuPjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyIgY2xhc3M9
IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcnR5IGluIHBvc3Nlc3Npb24gb2Yg
aXQgY2FuLiZuYnNwOyBVc2luZyBhIGJlYXJlciB0b2tlbiBkb2VzIG5vdDwvc3Bhbj48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiIGNsYXNzPSIi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlIGEgYmVhcmVyIHRvIHByb3Zl
IHBvc3Nlc3Npb24gb2YgY3J5cHRvZ3JhcGhpYyBrZXkgbWF0ZXJpYWw8L3NwYW4+PC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7IiBjbGFzcz0iIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHByb29mLW9mLXBvc3Nlc3Npb24pLjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyIgY2xhc3M9IiI+4oCdPC9zcGFuPjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyIgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz
dHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyIgY2xhc3M9IiI+VGhpcyBpbXBsaWVzIHRoYXQgZXZl
cnkgc2NvcGUgdmFsdWUgc2hvdWxkIGZ1bGx5IGRlc2NyaWJlIHRoZSBhdXRob3Jpc2F0aW9uIHRo
YXQgaXMgZ2l2ZW4uIEluIG15IHZpZXcgdGhhdCBpcyByYXJlbHkgZG9uZSwgd2hpY2ggaXMgdGhl
IG1haW4gcmVhc29uIHdoeSBJIGZpbmQgbXlzZWxmIHN0cnVnZ2xpbmcgd2l0aCBzY29wZS1jb25j
ZXB0Ljwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6
IG5vcm1hbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsiIGNsYXNzPSIiPkhlcmUgd2Ug
aGF2ZSBhIGNvbGxlY3Rpb24gb2YgZXhhbXBsZXMsIHdoaWNoIGRlbW9uc3RyYXRlIHRvIG1lIHRo
YXQgZXZlcnlvbmUgaXMgaW52ZW50aW5nIHRoZWlyIG93biB3aGVlbHMgYWNjb3JkaW5nIHRvIHRo
ZWlyIHNwZWNmaWMgbmVlZHM6PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJo
dHRwczovL2JyYW5kdXIub3JnL29hdXRoLXNjb3BlIiBjbGFzcz0iIj5odHRwczovL2JyYW5kdXIu
b3JnL29hdXRoLXNjb3BlPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczov
L2FwaS5zbGFjay5jb20vZG9jcy9vYXV0aC1zY29wZXMiIGNsYXNzPSIiPmh0dHBzOi8vYXBpLnNs
YWNrLmNvbS9kb2NzL29hdXRoLXNjb3BlczwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHZhcmlvdXMgb3RoZXIgKGRyYWZ0KSBz
dGFuZGFyZHMgSSBzZWUgYml0cyBhbmQgcGllY2VzIHRoYXQgc2VlbSB0byBhZGRyZXNzIHRoaXMg
aXNzdWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SW4gVU1BIGFuIGF1dGhvcmlzYXRpb24gaXMgY29uY2Vw
dHVhbGx5IGJyb2tlbiBkb3duIGludG86PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gc3ViamVjdCAt
Jmd0OyByZXF1ZXN0aW5nIHBhcnR5PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gdmVyYnMgLSZndDsg
c2NvcGVzIG9mIGFjY2VzczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIG9iamVjdCAtJmd0OyByZXNv
dXJjZSBzZXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgbGlrZSB0aGlzIGxpbmUgb2YgdGhpbmtp
bmcgYW5kIHRlcm1pbmlsb2d5LiAmbmJzcDtIb3dldmVyLCBpZiBhY2Nlc3NfdG9rZW5zIGFyZSBi
ZWFyZXIgdG9rZW5zLCBJIHRoaW5rIOKAmXN1YmplY3TigJkgaXMgdGhlIGJlYXJlciBvZiB0aGUg
dG9rZW4uPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTog
MTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVm
b3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdp
ZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+VGhlIG1vc3QgY29tbW9u
IHByYWN0aWNlLCBJIHRoaW5rLCBpcyB0byB1c2UgT0lEQ+KAmXMgSURUb2tlbnMgdG8gY29udGFp
biBhIHNldCBvZiBjbGFpbXMgdGhhdCBzY29wZSB0aGUgc2NvcGUgb2YgdGhlIHNjb3BlIDotKS4m
bmJzcDs8L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl
OiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1i
ZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsg
d2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj5JIG1lYW4gdGhhdCB0
aGUgY2xhaW1zIGluIHRoZSBJRC1Ub2tlbnMgYXJlIHVzZWQgdG8gc2NvcGUgdGhlIG9iamVjdHMg
YXMgd2VsbCBhcyB0aGUgdmVyYnMvc2NvcGVzIG9mIGFjY2Vzcy48L2ZvbnQ+PC9wcmU+DQo8cHJl
IGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6
IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFu
dC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0i
SGVsdmV0aWNhIiBjbGFzcz0iIj5UaGUgY29yZSBpbnRlbnRpb24gYmVoaW5kIElELXRva2VuIGlz
IHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBhbmQg
bm90IG5lY2Vzc2FyaWx5IGFib3V0IHRoZSByZXNvdXJjZXMgdGhhdCBhcmUgYWNjZXNzZWQuIElu
IHByYWN0aWNlLCBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlcnMgaW5kaWNhdGUg
d2hpY2ggcmVzb3VyY2VzIChwaG90b3MpIGNhbiBiZSBhY2Nlc3NlZCBhdCB0aGUgcmVzb3VyY2Ug
c2VydmVyLiA8L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1z
aXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVh
ay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczog
Mjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj48YnIgY2xhc3M9
IiI+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTog
MTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVm
b3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdp
ZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+TXkgdW5kZXJzdGFuZGlu
ZyBvZiB0aGlzIGRyYWZ0IDwvZm9udD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyIiBjbGFzcz0iIj5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0
b3JzLTAyPC9hPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTog
MTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVm
b3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdp
ZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+aXMgdGhhdCB0aGUgb2Jq
ZWN0L3Jlc291cmNlIGFzcGVjdCBvZiBhdXRob3Jpc2F0aW9uIGlzIHRha2VuIHNvbWV3aGF0IG91
dCBvZiB0aGUgc2NvcGUgYW5kIHB1dCBpbnRvIGEgZGVkaWNhdGVkIHBhcmFtZXRlci4gQWx0aG91
Z2ggKHVzaW5nIHRoZSBleGFtcGxlIGZyb20gUkZDIDY3NDkpIHRoZSByZXNvdXJjZSBwYXJhbWV0
ZXIgaW5kaWNhdGVzIHRoZTwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7
IiBjbGFzcz0iIj48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPiByZXNvdXJjZSBzZXJ2
ZXIgKG9yIGFwcGxpY2F0aW9uLDwvZm9udD48L3NwYW4+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdw
YWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu
LWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6
IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBj
bGFzcz0iIj4gICBBUEksIGV0Yy4pIHJhdGhlciB0aGFuIGFuIGluZGl2aWR1YWwgcmVzb3VyY2Ug
dGhhdCBpcyBzdG9yZWQgYXQgdGhlIHJlc291cmNlIHNlcnZlci4gU28gYWRkaXRpb25hbCBzY29w
aW5nIG9mIG9iamVjdC9yZXNvdXJjZSBzZXQgaXMgc3RpbGwgbmVlZGVkIGluIGFkZGl0aW9uIHRv
IHRoZSByZXNvdXJjZSBwYXJhbWV0ZXIuPC9mb250PjwvcHJlPg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RnVydGhlcm1vcmUs
Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtc2VjdXJpdHktdG9waWNzLTEyIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MtMTI8L2E+Jm5ic3A7bWFrZXMgc29t
ZSBpbnRlcmVzdGluZyBzdGF0ZW1lbnRzIHRoYXQgYXJlIHJlbGV2YW50IGluIG15IHZpZXc6PC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBzZWN0aW9uIG9uIEFjY2VzcyBUb2tlbiBwcml2aWxlZ2Ug
cmVzdHJpY3Rpb24gc2F5cyAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7
IG9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPmFjY2VzcyB0b2tlbnMgU0hPVUxEIGJl
IHJlc3RyaWN0ZWQgdG8gY2VydGFpbiByZXNvdXJjZXM8L3NwYW4+PC9kaXY+DQo8cHJlIGNsYXNz
PSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsg
bWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdh
dHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0
aWNhIiBjbGFzcz0iIj4gICBhbmQgYWN0aW9ucyBvbiByZXNvdXJjZSBzZXJ2ZXJzIG9yIHJlc291
cmNlcy7igJ0gU28gdGhlIE9BdXRoIHNjb3BlLXN0cmluZyBzdGlsbCBuZWVkcyB0byBzb21laG93
IGluZGljYXRlIHRoZSByZXNvdXJjZS1zY29wZSBvZiB0aGUgcHJpdmlsZWdlIHRoYXQgaXMgY29t
bXVuaWNhdGVkLjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250
LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJy
ZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5z
OiAyOyB3aWRvd3M6IDI7Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPjxiciBjbGFz
cz0iIj48L2ZvbnQ+PC9wcmU+DQo8ZGl2IGNsYXNzPSIiPiZxdW90OzxzcGFuIHN0eWxlPSJmb250
LXNpemU6IDEzLjMzMzNweDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+IFRoZSBj
bGllbnQgbmVlZHMgdG8gdGVsbCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGF0IHdoaWNoIFVS
TCBpdDwvc3Bhbj48L2Rpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6
IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJyZWFrLWJl
Zm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAyOyB3
aWRvd3M6IDI7Ij4gICB3aWxsIHVzZSB0aGUgYWNjZXNzIHRva2VuIGl0IGlzIHJlcXVlc3Rpbmcu
ICBJdCBjb3VsZCB1c2UgdGhlDQogICBtZWNoYW5pc20gcHJvcG9zZWQgWzxhIGhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0x
MiNyZWYtSS1ELmlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycyIgdGl0bGU9IiZxdW90O1Jl
c291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMCZxdW90OyIgY2xhc3M9IiI+SS1ELmlldGYt
b2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9yczwvYT5dIG9yIGVuY29kZSB0aGUNCiAgIGluZm9ybWF0
aW9uIGluIHRoZSBzY29wZSB2YWx1ZS7igJ08L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0
eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t
OiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs
OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij48YnIgY2xhc3M9IiI+PC9wcmU+DQo8cHJlIGNsYXNz
PSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsg
bWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdh
dHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0
aWNhIiBjbGFzcz0iIj5J4oCZbSBub3Qgc3VyZSB3aGljaCBwb2ludCBJ4oCZbSB0cnlpbmcgdG8g
bWFrZTsgaSBndWVzcyB0aGUgbmVlZCBmb3Igc3RhbmRhcmRpc2F0aW9uIGhvdyB0byB1c2UgYW5k
IGRlZmluZSBPQXV0aC1zY29wZXMuPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg
c3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0
b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt
YWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9
IiI+SSBsaWtlIHRoZSBMb2RnaW5nIEludGVudCBQYXR0ZXJuIGFuZCBuZWVkIHRvIGRvIHNvbWUg
bW9yZSByZWFkaW5nL3RoaW5raW5nIGFib3V0IHRoZSBzdHJ1Y3R1cmVkLXNjb3BlIGFuZCBwdXNo
ZWQgcmVxdWVzdCBvYmplY3RzLjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0
eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t
OiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs
OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIi
PkkgZmVlbCB0aGVzZSBjb25jZXB0cyBhcmUgbm90IG9ubHkgcmVsZXZhbnQgZm9yIGF1dGhvcmlz
YXRpb24gb2YgdHJhbnNhY3Rpb25zLCBidXQgYWxzbyBmb3IgYW55IGFjY2VzcyB0aGF0IG5lZWRz
IGF1dGhvcmlzYXRpb24uPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9
ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw
eDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9y
cGhhbnM6IDI7IHdpZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJn
aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250
LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxmb250
IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+SeKAmW0g
bm90IHN1cmUgaWYgaSBleHByZXNzIG15c2VsZiBjbGVhcmx5LCBuZXZlcnRoZWxlc3MgYW55IGZl
ZWRiYWNrIGlzIHdlbGNvbWUsIGlmIG5vdCBhbG9uZSB0byBnZXQgbXkgdW5kZXJzdGFuZGluZyBv
ZiB0aGUgdmFyaW91cyBjb25jZXB0cyBvbiBhIGhpZ2hlciBsZXZlbC48L2ZvbnQ+PC9mb250Pjwv
cHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu
LWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6
IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBj
bGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9mb250PjwvZm9u
dD48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h
cmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1
cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxmb250IGZhY2U9IkhlbHZldGlj
YSIgY2xhc3M9IiI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+VGhhbmtzIGluIGFkdmFuY2UsIGtp
bmQgcmVnYXJkczwvZm9udD48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHls
ZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFn
ZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7
Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPjxmb250IHNpemU9IjIiIGNsYXNzPSIi
PjxiciBjbGFzcz0iIj48L2ZvbnQ+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg
c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6
IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dz
OiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0iIj48Zm9udCBzaXplPSIyIiBjbGFz
cz0iIj5KYWFwPC9mb250PjwvZm9udD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMz
cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBh
Z2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2lkb3dzOiAy
OyI+PGJyIGNsYXNzPSIiPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQt
c2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJl
YWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6
IDI7IHdpZG93czogMjsiPjxiciBjbGFzcz0iIj48L3ByZT4NCjwvZGl2Pg0KPGRpdj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1lc3NhZ2U6IDE8YnIg
Y2xhc3M9IiI+DQpEYXRlOiBXZWQsIDI0IEFwciAyMDE5IDE5OjA4OjI1ICYjNDM7MDIwMDxiciBj
bGFzcz0iIj4NCkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0
b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgY2xhc3M9IiI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8
L2E+Jmd0OzxiciBjbGFzcz0iIj4NClRvOiBTYXNjaGEgUHJlaWJpc2NoICZsdDs8YSBocmVmPSJt
YWlsdG86c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbSIgY2xhc3M9IiI+c2FzY2hhcHJlaWJpc2No
QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KQ2M6IG9hdXRoICZsdDs8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnIg
Y2xhc3M9IiI+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUcmFuc2FjdGlvbiBBdXRob3JpemF0
aW9uIHdpdGggT0F1dGg8YnIgY2xhc3M9IiI+DQpNZXNzYWdlLUlEOiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOjI5OTdCNTUwLUM4MkItNEQzQS05NjM5LTE1QTAwNEYyRjZDNUBsb2RkZXJzdGVkdC5uZXQi
IGNsYXNzPSIiPjI5OTdCNTUwLUM4MkItNEQzQS05NjM5LTE1QTAwNEYyRjZDNUBsb2RkZXJzdGVk
dC5uZXQ8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjs8c3Bh
biBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+
DQpjaGFyc2V0PXV0Zi04PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGkgU2FzY2hhLDxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgc2VlLiBJIGFzc3VtZSBldmVyeSBlbGVtZW50
IHdpdGhpbiB0aGUgc3RydWN0dXJlZCBzY29wZSBlbGVtZW50IHRvIGJlIGFuIGluZGVwZW5kZW50
IHNjb3BlICh2YWx1ZSkgb2JqZWN0IGFuZCBpbnRlbmRlZCB0byB1c2UgdGhlIG5hbWUgb2YgdGhh
dCBvYmplY3QgYXMga2luZCBvZiBjb250ZW50IHR5cGUgZGVmaW5pdGlvbi4NCjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCkluIG15IGxhc3QgZXhhbXBsZSwgdGhlIHNjb3BlIGlzIGRlZmlu
ZWQgYXMgPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7JnF1b3Q7c3Ry
dWN0dXJlZF9zY29wZSZxdW90Ozp7ICZuYnNwOzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZxdW90O3NpZ24mcXVvdDs6eyAmbmJzcDs8YnIgY2xhc3M9IiI+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtjcmVk
ZW50aWFsSUQmcXVvdDs6JnF1b3Q7cWVzX2VpZGFzJnF1b3Q7LDxiciBjbGFzcz0iIj4NCiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2RvY3VtZW50
RGlnZXN0cyZxdW90OzpbICZuYnNwOzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3sgJm5ic3A7PGJy
IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7aGFzaCZxdW90Ozo8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVv
dDtzVE9nd09tJiM0Mzs0NzRnRmowcTB4MWlTTnNwS3FiY3NlNEllaXFsRGcvSFd1ST0mcXVvdDss
PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7bGFiZWwmcXVv
dDs6JnF1b3Q7TW9iaWxlIFN1YnNjcmlwdGlvbiBDb250cmFjdCZxdW90OzxiciBjbGFzcz0iIj4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO308YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDtdLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2hhc2hBbGdvcml0aG1PSUQmcXVvdDs6JnF1
b3Q7Mi4xNi44NDAuMS4xMDEuMy40LjIuMSZxdW90OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO30sPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7JnF1b3Q7cGF5bWVudCZxdW90Ozp7ICZuYnNwOzxiciBjbGFzcz0iIj4NCiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O3R5cGUmcXVv
dDs6JnF1b3Q7c2VwYS1jcmVkaXQtdHJhbnNmZXImcXVvdDssPGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7aW5zdHJ1Y3Rl
ZEFtb3VudCZxdW90Ozp7ICZuYnNwOzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2N1cnJl
bmN5JnF1b3Q7OiZxdW90O0VVUiZxdW90Oyw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDth
bW91bnQmcXVvdDs6JnF1b3Q7MTIzLjUwJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fSw8YnIgY2xhc3M9IiI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtkZWJ0b3JB
Y2NvdW50JnF1b3Q7OnsgJm5ic3A7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7aWJhbiZx
dW90OzomcXVvdDtERTQwMTAwMTAwMTAzMzA3MTE4NjA4JnF1b3Q7PGJyIGNsYXNzPSIiPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fSw8YnIgY2xhc3M9
IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVv
dDtjcmVkaXRvck5hbWUmcXVvdDs6JnF1b3Q7TWVyY2hhbnQxMjMmcXVvdDssPGJyIGNsYXNzPSIi
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7
Y3JlZGl0b3JBY2NvdW50JnF1b3Q7OnsgJm5ic3A7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1
b3Q7aWJhbiZxdW90OzomcXVvdDtERTAyMTAwMTAwMTA5MzA3MTE4NjAzJnF1b3Q7PGJyIGNsYXNz
PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fSw8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmcXVvdDtyZW1pdHRhbmNlSW5mb3JtYXRpb25VbnN0cnVjdHVyZWQmcXVvdDs6JnF1b3Q7
bmV3IFNtYXJ0cGhvbmUmcXVvdDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDt9PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBtZWFucyA/c2lnbiZx
dW90OyBhbmQgP3BheW1lbnQmcXVvdDsgd291bGQgZGV0ZXJtaW5lIHRoZSBzY2hlbWUgb2YgdGhl
IHJlc3BlY3RpdmUgb2JqZWN0Lg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hhdCBk
byB5b3UgdGhpbms/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KYmVzdCByZWdhcmRzLCA8
YnIgY2xhc3M9IiI+DQpUb3JzdGVuLiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyMy4gQXByIDIwMTksIGF0IDE3OjE0LCBT
YXNjaGEgUHJlaWJpc2NoICZsdDs8YSBocmVmPSJtYWlsdG86c2FzY2hhcHJlaWJpc2NoQGdtYWls
LmNvbSIgY2xhc3M9IiI+c2FzY2hhcHJlaWJpc2NoQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIFRvcnN0ZW4hPGJyIGNsYXNzPSIiPg0KPGJy
IGNsYXNzPSIiPg0KSWYgJ3N0cnVjdHVyZWRfc2NvcGUnIHdvdWxkIGJlY29tZSBhIGdlbmVyaWMg
ZmllbGQgZm9yIGFwcGxpY2F0aW9uPGJyIGNsYXNzPSIiPg0Kc3BlY2lmaWMgY29udGVudCwgSSBi
ZWxpZXZlIGFuIGluZGljYXRvciBmb3IgdGhlIHR5cGUgb2YgY29udGVudCB3b3VsZDxiciBjbGFz
cz0iIj4NCmJlIG5lZWRlZCBvbiB0aGUgbG9uZyBydW4uIFRoYXQgaXMgd2hhdCBJIG1lYW50IG15
ICdwcm9maWxlJy4gSSBob3BlPGJyIGNsYXNzPSIiPg0KdGhpcyBoZWxwcyE8YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpUaGFuayB5b3UsPGJyIGNsYXNzPSIiPg0KU2FzY2hhPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KQW0gTW8uLCAyMi4gQXByLiAyMDE5IHVtIDIyOjA2IFVociBz
Y2hyaWViIFRvcnN0ZW4gTG9kZGVyc3RlZHQ8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFp
bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiBjbGFzcz0iIj50b3JzdGVuQGxvZGRlcnN0ZWR0
Lm5ldDwvYT4mZ3Q7OjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz
PSIiPjxiciBjbGFzcz0iIj4NCkhpIFNhc2NoYSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BbSAyMi4wNC4yMDE5IHVtIDIwOjM0
IHNjaHJpZWIgU2FzY2hhIFByZWliaXNjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhc2NoYXByZWli
aXNjaEBnbWFpbC5jb20iIGNsYXNzPSIiPnNhc2NoYXByZWliaXNjaEBnbWFpbC5jb208L2E+Jmd0
Ozo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFuayB5b3UgZm9yIHRoZSBhcnRpY2xl
LCBUb3JzdGVuITxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCm15
IHBsZWFzdXJlIDotKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkkgbGlrZSB0aGF0ICdzY29wZScgaXMg
b3V0IG9mIHRoZSBnYW1lIGZvciB0aGVzZSBraW5kcyBvZiBhdXRob3JpemF0aW9ucy48YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGF0IEkgY2FuIHNlZSBmb3IgdGhlIGdlbmVyYWwgdXNl
IGNhc2UgaXMgYSByZXF1aXJlZCBpZGVudGlmaWVyPGJyIGNsYXNzPSIiPg0Kd2l0aGluIHRoZSAn
c3RydWN0dXJlc19zY29wZScgZG9jdW1lbnQgdGhhdCBpZGVudGlmaWVzIHRoZSBwcm9maWxlIGl0
PGJyIGNsYXNzPSIiPg0Kc2hvdWxkIGJlIHVzZWQgZm9yLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx
dW90ZT4NCjxiciBjbGFzcz0iIj4NCldoYXQgZG9lcyBwcm9maWxlIG1lYW4gaW4gdGhpcyBjb250
ZXh0PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmJlc3QgcmVnYXJkcyw8YnIgY2xhc3M9
IiI+DQpUb3JzdGVuLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz
PSIiPjxiciBjbGFzcz0iIj4NClRoYW5rIHlvdSw8YnIgY2xhc3M9IiI+DQpTYXNjaGE8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbSBTYS4sIDIwLiBBcHIuIDIwMTkgdW0gMTE6MjEgVWhy
IHNjaHJpZWIgVG9yc3RlbiBMb2RkZXJzdGVkdDxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJt
YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3Rl
ZHQubmV0PC9hPiZndDs6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KSGkgYWxsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N
CkkganVzdCBwdWJsaXNoZWQgYW4gYXJ0aWNsZSBhYm91dCB0aGUgc3ViamVjdCBhdDogPGEgaHJl
Zj0iaHR0cHM6Ly9tZWRpdW0uY29tL29hdXRoLTIvdHJhbnNhY3Rpb24tYXV0aG9yaXphdGlvbi1v
ci13aHktd2UtbmVlZC10by1yZS10aGluay1vYXV0aC1zY29wZXMtMjMyNmUyMDM4OTQ4IiBjbGFz
cz0iIj4NCmh0dHBzOi8vbWVkaXVtLmNvbS9vYXV0aC0yL3RyYW5zYWN0aW9uLWF1dGhvcml6YXRp
b24tb3Itd2h5LXdlLW5lZWQtdG8tcmUtdGhpbmstb2F1dGgtc2NvcGVzLTIzMjZlMjAzODk0ODwv
YT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGxvb2sgZm9yd2FyZCB0byBnZXR0aW5n
IHlvdXIgZmVlZGJhY2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Ka2luZCByZWdhcmRz
LDxiciBjbGFzcz0iIj4NClRvcnN0ZW4uPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNz
PSIiPk9BdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js
b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xh
c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGNsYXNzPSIiPk9BdXRoQGll
dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQpFbmQgb2YgT0F1dGggRGlnZXN0LCBWb2wgMTI2LCBJc3N1ZSA1ODxiciBjbGFzcz0iIj4NCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_74A378B3B81A4199938BE576FD1AA66Ciwelcomecom_--


From nobody Thu Apr 25 08:04:08 2019
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 9D27D12030E for ; Thu, 25 Apr 2019 08:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 pJLuFZpkNomZ for ; Thu, 25 Apr 2019 08:03:57 -0700 (PDT)
Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 B0A6E1201EC for ; Thu, 25 Apr 2019 08:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556204635; bh=4DXbiKJor+8J1LfmhS2hXlQbfHRA225PbW1LoVx2wPs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=X8MdTc6w8W/yl6MzMI2K1glRnZHFSo5zn1S9qoV5i2hwAldyuSWgBoNpkqG2TTNV7MNkCUMXGp9uHTlA0FjF9EOeFCcbgsiavrOml96R9Mbd0PO7T5DXaDGsXZHdDVF6wuokTqza6loqeJ4HMX5W8x6aIGKD0kYefJLIXSvLb+y5rfi+Kucj0mjAPwaeIDyDVvqKV+5Jd2VvdVFcQyOo7XHTwpuwCJzPio/VAXcXtntlrWUZkNUw+PNweqNhL/iBWfS6H+QOLVMRfABlyw+jNv7ADEuf1ZRyPoW6C6dRWt0wud6eBGzY7+mOMh81fdmFX1d2/qVrZ8MuX+s81pnm0Q==
X-YMail-OSG: wGBNAAIVM1m5VHZ7BsO8e5UF7HQm7TTVuvjMEnQzFXBC9jm66O9tLiDARQzGc.o ogM3vGAIei9qidgmaFGYizDCc1MIAkmrqfP89Tt4UnCIYXop1AUOCvJiuMcftWrI53K9AlMKy57b 7tb_4vXBT98v5kROkKVN6ppWNLUQwf2aaKUOWolAkptnchE3PORg3QsIWUaKRmh1U5b6CdXIQSvG 484TGXH_1vSNLdBiV_dCjgQdlW2my7.I0FyD3TB1XD6JvDlK9xsMoHnNW.fDJyiHn35mEuN_QiUK nqmlt5yJr.TLwwiOSuBsxTX6UqqbaWVRgh8sE73E8towXjG4SE5inx4SKAZaKcngPv3sCILi_Pso 8ZSGuMzgsEVsB802fb.6L0ZS9wCRNzDs1ow6dHe87KZjS4i5xg.qbvfNN29BNafIhqIuts.IeQs5 fUAFLL4sxe9qvODFibgrF7Gy2RKXJaDZw1jQuCK7HVT_2k9PeTVSIEITIfzOqGOpsTAPRfKuCIbA Ol8C75nHRy794DVR8deAzc981hGvbXF1bN_zYvPcmCpJCWymEVScBTPto8cV90YU3m_1jhnz_OhN SsdT3.zQY2Gt6ON0tJo1bSzs.iqz4WP90OebLK9_ulMQaJxaJZinZSpnjQZE7D4Ef_UDtplj5qBP YgLj1RYYWMBnehrgkmHXZBc6Soe__km1RjznxIvnruQW4QGNmwFTM3i2.uG_cU7pMiwCPe7FOTtL 9Y5KxLzhJRyftRuES89xm520jHqpS.8IsVG8ofmhn_ktJmkhIBAu97zn6mKM0l9Qbkg4Euz9X9En oMG9Tm0P51GL82rJ16OVgHTYqt5Z.LmjZ2iEdt5NKev9JDnoOmhfkr5uaw_N.UTjwTNeBsp5iuUk HE9_lpXApDik64N4U4bgWvIMvuhnOdv7OnSrSenKWgeZsUx0ec_b1MpjFvfyiL.uCoOdwQBk1sHp y.y2HTpw81SpvPymfhtYuB_OgeoJU6VfoYMlHtd3Rletg90U9J_AoXmIS0XQiiiPaGUjNPdgisXb _Hsk6w9MV2gvUO54CxpFKNbb8KL4hvfkfSy2nO4paVl6AgJQX_vs9NR_9uJybJU7t.wLp4cIUkg- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Apr 2019 15:03:55 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp409.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c5cfcfeccccd246a4f7fd575f97a68e3;  Thu, 25 Apr 2019 15:03:52 +0000 (UTC)
To: Torsten Lodderstedt , Sascha Preibisch 
Cc: oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>
Date: Thu, 25 Apr 2019 11:03:51 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------E90FE0AEE83E5E1684A14CAC"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2019 15:04:07 -0000

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

A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction requirements.

2. The schemas are going to be very ecosystem specific, correct?

On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
> Hi Sascha,
>
> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition.
>
> In my last example, the scope is defined as
>
>     "structured_scope":{
>        "sign":{
>           "credentialID":"qes_eidas",
>           "documentDigests":[
>              {
>                 "hash":
>                   "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>                 "label":"Mobile Subscription Contract"
>              }
>           ],
>           "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>        },
>        "payment":{
>           "type":"sepa-credit-transfer",
>           "instructedAmount":{
>              "currency":"EUR",
>              "amount":"123.50"
>           },
>           "debtorAccount":{
>              "iban":"DE40100100103307118608"
>           },
>           "creditorName":"Merchant123",
>           "creditorAccount":{
>              "iban":"DE02100100109307118603"
>           },
>           "remittanceInformationUnstructured":"new Smartphone"
>        }
>
> This means ???sign" and ???payment" would determine the scheme of the respective object.
>
> What do you think?
>
> best regards,
> Torsten.
>
>> On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:
>>
>> Hi Torsten!
>>
>> If 'structured_scope' would become a generic field for application
>> specific content, I believe an indicator for the type of content would
>> be needed on the long run. That is what I meant my 'profile'. I hope
>> this helps!
>>
>> Thank you,
>> Sascha
>>
>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>> :
>>> Hi Sascha,
>>>
>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
>>>>
>>>> Thank you for the article, Torsten!
>>> my pleasure :-)
>>>
>>>> I like that 'scope' is out of the game for these kinds of authorizations.
>>>>
>>>> What I can see for the general use case is a required identifier
>>>> within the 'structures_scope' document that identifies the profile it
>>>> should be used for.
>>> What does profile mean in this context?
>>>
>>> best regards,
>>> Torsten.
>>>> Thank you,
>>>> Sascha
>>>>
>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>> :
>>>>> Hi all,
>>>>>
>>>>> I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>
>>>>> I look forward to getting your feedback.
>>>>>
>>>>> kind 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


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


  
    
  
  
    A couple of thoughts...

      

      1. It doesn't feel like these are scopes (at least not as scope is
      defined by RFC 6749). It feels like they are more transaction
      requirements.

      

      2. The schemas are going to be very ecosystem specific, correct?

    

    
On 4/24/19 1:08 PM, Torsten Lodderstedt
      wrote:

    

    

      
Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 



      

        
On 23. Apr 2019, at 17:14, Sascha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


        

          
Hi Sascha,



          

            
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


          

          
my pleasure :-)



          

            
I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


          

          
What does profile mean in this context?

best regards,
Torsten.


          

            
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


            

              
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind 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


    

    

  


--------------E90FE0AEE83E5E1684A14CAC--


From nobody Thu Apr 25 10:54:59 2019
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 B3541120227 for ; Thu, 25 Apr 2019 10:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wVyh5ymM8g5Y for ; Thu, 25 Apr 2019 10:54:52 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 C39471201C7 for ; Thu, 25 Apr 2019 10:54:51 -0700 (PDT)
Received: from [89.248.140.15] (helo=[10.22.54.142]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hJia8-0006ls-Q9; Thu, 25 Apr 2019 19:54:49 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-0F1CB29C-FB6C-47DC-BB58-591919E8FA1E; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>
Date: Thu, 25 Apr 2019 19:54:47 +0200
Cc: Sascha Preibisch , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2019 17:54:56 -0000

--Apple-Mail-0F1CB29C-FB6C-47DC-BB58-591919E8FA1E
Content-Type: multipart/alternative;
	boundary=Apple-Mail-D8E08792-8D9D-4393-8BB1-E5FE03744F85
Content-Transfer-Encoding: 7bit


--Apple-Mail-D8E08792-8D9D-4393-8BB1-E5FE03744F85
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 25.04.2019 um 17:03 schrieb George Fletcher :
>=20
> A couple of thoughts...
>=20
> 1. It doesn't feel like these are scopes (at least not as scope is defined=
 by RFC 6749). It feels like they are more transaction requirements.

What=E2=80=99s the difference? In my opinion, if you authorize a transaction=
 it=E2=80=99s the same. Moreover, in other use cases (account information) i=
t a complex requirement for a potentially long lasting grant.

In both cases, they describe the request power of the token =3D=3D it=E2=80=99=
s scope.

>=20
> 2. The schemas are going to be very ecosystem specific, correct?

API (e.g. all psd2 standards), ecosystem, single deployment - just like =E2=80=
=9Etraditional=E2=80=9C scope values

>=20
>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>> Hi Sascha,
>>=20
>> I see. I assume every element within the structured scope element to be a=
n independent scope (value) object and intended to use the name of that obje=
ct as kind of content type definition.=20
>>=20
>> In my last example, the scope is defined as=20
>>=20
>>    "structured_scope":{ =20
>>       "sign":{ =20
>>          "credentialID":"qes_eidas",
>>          "documentDigests":[ =20
>>             { =20
>>                "hash":
>>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>                "label":"Mobile Subscription Contract"
>>             }
>>          ],
>>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>       },
>>       "payment":{ =20
>>          "type":"sepa-credit-transfer",
>>          "instructedAmount":{ =20
>>             "currency":"EUR",
>>             "amount":"123.50"
>>          },
>>          "debtorAccount":{ =20
>>             "iban":"DE40100100103307118608"
>>          },
>>          "creditorName":"Merchant123",
>>          "creditorAccount":{ =20
>>             "iban":"DE02100100109307118603"
>>          },
>>          "remittanceInformationUnstructured":"new Smartphone"
>>       }
>>=20
>> This means ???sign" and ???payment" would determine the scheme of the res=
pective object.=20
>>=20
>> What do you think?
>>=20
>> best regards,=20
>> Torsten.=20
>>=20
>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch =
 wrote:
>>>>=20
>>>> Hi Torsten!
>>>>=20
>>>> If 'structured_scope' would become a generic field for application
>>>> specific content, I believe an indicator for the type of content would
>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>> this helps!
>>>>=20
>>>> Thank you,
>>>> Sascha
>>>>=20
>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>> :
>>>> Hi Sascha,
>>>>=20
>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
>>>>>>=20
>>>>>> Thank you for the article, Torsten!
>>>>> my pleasure :-)
>>>>>=20
>>>>> I like that 'scope' is out of the game for these kinds of authorizatio=
ns.
>>>>>=20
>>>>> What I can see for the general use case is a required identifier
>>>>> within the 'structures_scope' document that identifies the profile it
>>>>> should be used for.
>>>> What does profile mean in this context?
>>>>=20
>>>> best regards,
>>>> Torsten.
>>>>> Thank you,
>>>>> Sascha
>>>>>=20
>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>> :
>>>>>> Hi all,
>>>>>>=20
>>>>>> I just published an article about the subject at: https://medium.com/=
oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948
>>>>>>=20
>>>>>> I look forward to getting your feedback.
>>>>>>=20
>>>>>> kind 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

--Apple-Mail-D8E08792-8D9D-4393-8BB1-E5FE03744F85
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



Am 25.04.2019 um 17:03 schrieb George Fletcher &=
lt;gffletch@aol.com>:


 =20
    
 =20
 =20
    A couple of thoughts...

      

      1. It doesn't feel like these are scopes (at least not as scope is
      defined by RFC 6749). It feels like they are more transaction
      requirements.

What=E2=80=99=
s the difference? In my opinion, if you authorize a transaction it=E2=80=99s=
 the same. Moreover, in other use cases (account information) it a complex r=
equirement for a potentially long lasting grant.

In both c=
ases, they describe the request power of the token =3D=3D it=E2=80=99s scope=
.


      

      2. The schemas are going to be very ecosystem specific, correct?

API (e.g. all psd2 standards), e=
cosystem, single deployment - just like =E2=80=9Etraditional=E2=80=9C scope v=
alues


    

    
On 4/24/19 1:08 PM, Torsten Lodderstedt
      wrote:

    

    

      
Hi Sascha,

I see. I assume every element within the structured scope element to be an i=
ndependent scope (value) object and intended to use the name of that object a=
s kind of content type definition.=20

In my last example, the scope is defined as=20

   "structured_scope":{ =20
      "sign":{ =20
         "credentialID":"qes_eidas",
         "documentDigests":[ =20
            { =20
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{ =20
         "type":"sepa-credit-transfer",
         "instructedAmount":{ =20
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{ =20
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{ =20
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respec=
tive object.=20

What do you think?

best regards,=20
Torsten.=20



      

        
On 23. Apr 2019, at 17:14, Sa=
scha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
&=
lt;torsten@lodderstedt.net>:


        

          
Hi Sascha,



          

            
Am 22.04.2019 um 20:34 sc=
hrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


          

          
my pleasure :-)



          

            
I like that 'scope' is ou=
t of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


          

          
What does profile mean in t=
his context?

best regards,
Torsten.


          

            
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
&=
lt;torsten@lodderstedt.net>:


            

              
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/t=
ransaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e203894=
8

I look forward to getting your feedback.

kind regards,
Torsten.
_______________________________________________
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


=

--Apple-Mail-D8E08792-8D9D-4393-8BB1-E5FE03744F85--

--Apple-Mail-0F1CB29C-FB6C-47DC-BB58-591919E8FA1E
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDI1MTc1NDQ3WjAvBgkqhkiG9w0BCQQxIgQg
ItIUYi3puNtDBfFxS9k7ks9k2Ild4j1IqZtdZsg/xE8wgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAA0olS46yTEn8LJC
n+qXahYvQKhbkKiW/Y0GPmenPVicDuh/cc9m8kRAtWub/JGstZ/jXlPjEvAInEkoPY6ndwSa82G+
PBxHqhS2qPgWqxSj4C819uYhN9ewFL5GsEe8XKnEYlG7u1FVldLwCJ/2RGGVaOXm5ex/aPqSJ2W1
Zg3hWHFrLA/8MBhMjAjViAzzXnL7Xb9C7KSG7Mt0u4uh5p5PnWCwmhlsBQU2KGCCU/wQXYz3sa3A
I/F5wh/Tnc678WLtL73B0uZ5c3Ci892RVcaugw6WJzjs0Y4zRe3S12o1EShVzWvYGstv4Sssghol
znv4S1o1teKc8GKxX/NBCCQAAAAAAAA=

--Apple-Mail-0F1CB29C-FB6C-47DC-BB58-591919E8FA1E--


From nobody Thu Apr 25 14:36:32 2019
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 429431201B8 for ; Thu, 25 Apr 2019 14:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0AGz535aRuK for ; Thu, 25 Apr 2019 14:36:28 -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 2396B120025 for ; Thu, 25 Apr 2019 14:36:28 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id h18so1304706wml.1 for ; Thu, 25 Apr 2019 14:36:28 -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=GmQz6wzdubKaV3pzQosPrsgiu12J8D9IapqltxwzV+Q=; b=VMEGcKISk5wJIXbXYMK7XpDORUUt77XqglPv+gRbF/jyvfMSBXPbbJQ8zOpdjkXcbz 9UCwoOUg79W866gF7T8ycu1s8tAti/zk0KHrhwgKhkSR84qb0Crj05BZAh2Irzdg9Uuu 8ncfquYZntNy7kUGW5mYswye1Tp7u0kj6A2cQvXjJU2Qr3oUySqhMak+CGoCdTKJ8N+G 1uh4hBzDmBO1GfhFbXCvqI2LjFvkB+/yXF5Ao41fkqf5rlIV2eHQ/mzcNstWmOizWTSo Ms5X7+0EKYaKjSN15UfgPmRdoZt0PrNHzfy4Ge81+vyO+q+2rbIKAGdy6xt6hPx8ccut /P2Q==
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=GmQz6wzdubKaV3pzQosPrsgiu12J8D9IapqltxwzV+Q=; b=UaVmQ/7oVN9EXl7ct8/rm8ima8u8sS6hLfIWk8YUlxoyPWrpf0nQ/a9j2YdQc8l6HH qSs2F/wrx5arp9ONG/WDXfNnh4PmUfpW/SVDeSUmMQe7No4NUNjen78MqcQ1Uiy3E5BJ Mb1ftoSWdX4fqe3NCNSnakzgghNCs9tzR7F6EPSQq+l2Ky1l8gLXqFOOZGo/pcKzM+3r DMeIU0pq2mpjD0NKYgfgf1Zbpv/pNN51ceYh9MJpljk//QzmAP7LdIc849VbAnvy0FpZ MaGUkAPqDZff39KaXGkc4Db1PzM7g1FA0AcmbYYYHGpIY225JxGgTqkvmroHaCKLE3ud F1TQ==
X-Gm-Message-State: APjAAAWnbmdL/CwUTesZYimTmlUXkKOtNVOMsQKJxcahyYK956MNgx19 gcvNgvtp2HvbaUMaZnUK8aB3kYsCldYE6KPvbMn/0Q6R6aM=
X-Google-Smtp-Source: APXvYqyluBVKdEUaPUHyX8Fi+lwtiC0WTyHtFRZqDtqUgIGFyoQK7i4KHl5pV96ElBBG9MosxrKokIoEhXHddIp9TVs=
X-Received: by 2002:a7b:c769:: with SMTP id x9mr5245037wmk.103.1556228186337;  Thu, 25 Apr 2019 14:36:26 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
In-Reply-To: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
From: Sascha Preibisch 
Date: Thu, 25 Apr 2019 14:35:15 -0700
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2019 21:36:30 -0000

Torsten,

I think that works in most cases if you look at it that way.

It is just that elements such as 'iban' are practically unknown here
in Canada for example. This means, there needs to be a differentiator
that tells a client that one payment may be of type 'payment_eu' and
in the other case 'payment_ca'. Actually .... now I see the 'type'
element. With that, 'payment + type' would provide that information.

The only thing I would look into would be a change in the document
hierarchy to simply parsing of it. Potentially multiple payments could
be submitted at once also by adding a 'payments' root element:

{
"payment": {
"sepa-credit-transfer": {
"instructedAmount": {
"currency": "EUR",
"amount": "123.50"
},
"debtorAccount": {
"iban": "DE40100100103307118608"
},
"creditorName": "Merchant123",
"creditorAccount": {
"iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "new Smartphone"
}
}
}

But generally, the 'structured_scope' is a good concept I think.

Thanks again, Torsten,

Sascha

Am Mi., 24. Apr. 2019 um 10:08 Uhr schrieb Torsten Lodderstedt
:
>
> Hi Sascha,
>
> I see. I assume every element within the structured scope element to be a=
n independent scope (value) object and intended to use the name of that obj=
ect as kind of content type definition.
>
> In my last example, the scope is defined as
>
>    "structured_scope":{
>       "sign":{
>          "credentialID":"qes_eidas",
>          "documentDigests":[
>             {
>                "hash":
>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>                "label":"Mobile Subscription Contract"
>             }
>          ],
>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>       },
>       "payment":{
>          "type":"sepa-credit-transfer",
>          "instructedAmount":{
>             "currency":"EUR",
>             "amount":"123.50"
>          },
>          "debtorAccount":{
>             "iban":"DE40100100103307118608"
>          },
>          "creditorName":"Merchant123",
>          "creditorAccount":{
>             "iban":"DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured":"new Smartphone"
>       }
>
> This means =E2=80=9Csign" and =E2=80=9Cpayment" would determine the schem=
e of the respective object.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 23. Apr 2019, at 17:14, Sascha Preibisch =
 wrote:
> >
> > Hi Torsten!
> >
> > If 'structured_scope' would become a generic field for application
> > specific content, I believe an indicator for the type of content would
> > be needed on the long run. That is what I meant my 'profile'. I hope
> > this helps!
> >
> > Thank you,
> > Sascha
> >
> > Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
> > :
> >>
> >> Hi Sascha,
> >>
> >>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
> >>>
> >>> Thank you for the article, Torsten!
> >>
> >> my pleasure :-)
> >>
> >>>
> >>> I like that 'scope' is out of the game for these kinds of authorizati=
ons.
> >>>
> >>> What I can see for the general use case is a required identifier
> >>> within the 'structures_scope' document that identifies the profile it
> >>> should be used for.
> >>
> >> What does profile mean in this context?
> >>
> >> best regards,
> >> Torsten.
> >>>
> >>> Thank you,
> >>> Sascha
> >>>
> >>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> >>> :
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I just published an article about the subject at: https://medium.com=
/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-=
2326e2038948
> >>>>
> >>>> I look forward to getting your feedback.
> >>>>
> >>>> kind regards,
> >>>> Torsten.
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Fri Apr 26 00:47:54 2019
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 CAE001201D1 for ; Fri, 26 Apr 2019 00:47:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 uRu2Sz_zxMBn for ; Fri, 26 Apr 2019 00:47:50 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 14DA61201BA for ; Fri, 26 Apr 2019 00:47:50 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id j20so2321108edq.10 for ; Fri, 26 Apr 2019 00:47:49 -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=2yZP2JOdCCa3zeK2I8LP1PdRpY7esjOhlXrwqVarhxk=; b=iyYihrsiz7NNA54UmQal5WsZuxx/rNDeq2bluuZdwCUoT/1btcjackMFNQwE+spxih KBgvdfMKL2vqQVKw3iu3GjBoCGHicVnkXT35NLD4PpqNqc4W5HidEwV3aID147kPUOi+ tG0zZElzanu7paYv2uA5JQrZmSY/JRwke1BgH6pqXICy+nv9Tzd2dBxz4EgUdWnIqaX0 lfp08x7BzwX0dGhd6Iz1vbCd8TfDgp4+Bvmu88XPQ82LF2wMJCWFGF1YxEHvHQPK4Dtx icAswq/t+Wu4mL7dpCyZkDN3bRMwt0oifpTtXxMmEPz6P666iFxH2WOu5RWnPjx/6fM8 WjQA==
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=2yZP2JOdCCa3zeK2I8LP1PdRpY7esjOhlXrwqVarhxk=; b=jexZ9e7xX9UwIwIHt4PPD9Bn+ayoFeAMwNunG/v51vCvDl8Lo89jWF5L/LlyFvByPJ GSa8pVGrgcMaCd36HEjFDdtHtR0gBB4N7PTrVP8bfaEuTwPyD4iiJW8OaybynJNMZEGt /TERHHjOAPDYsnHZTopskMm0S5NMs1goRskNof7DlCp6inwekt851ZX5ZzCQgiBy8PFt ZRTsBOszG4dI1SZQJnJJxga649JkrwPYP0vDm6b4fuCo4WTlQeg0jlnFytQRX3O+ac3L Crcva7ly6bL4yeg4j5RoZ5F4+AnxakeCdFEtnStl7ocVa06xI4H+WPPjb9FGGu4pFX8N kI6w==
X-Gm-Message-State: APjAAAXvj+fF0iCSLpS+PInsBUO4y/uPFZWsAPHNlaVcm2QATlYOaCdl lkVUit7G52PdAL+lqSVfu6ku09+h4tva2cMOs4xx6xKupLkvvg==
X-Google-Smtp-Source: APXvYqxQsiFzD32We1HQ3VhqbIdwfVpX9NjnlcFjPiL0AVQlPnnajih/ThUkALeITfIuf8xKZ2h25HovqB1ASYsHmDA=
X-Received: by 2002:a50:fc99:: with SMTP id f25mr26026149edq.237.1556264868566;  Fri, 26 Apr 2019 00:47:48 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Takahiko Kawasaki 
Date: Fri, 26 Apr 2019 16:47:37 +0900
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000aaf18905876a2608"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2019 07:47:53 -0000

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

Dear Torsten,

I was impressed with your article. It describes considerations points very
well that implementers of leading-edge authorization servers will
eventually face or have already faced.

It seems to me that the mechanism of "structured_scope" can be positioned
as a more generic mechanism whose usage doesn't necessarily have to be
limited to scopes. I mean that the mechanism can be used to include any
arbitrary dynamic structured data in an authorization request. So, if there
were something I might be able to propose additionally, I would suggest
renaming "structured_scope" to a more generic name.

Best Regards,
Takahiko Kawasaki
Representative director, Authlete, Inc.

2019=E5=B9=B44=E6=9C=8821=E6=97=A5(=E6=97=A5) 3:21 Torsten Lodderstedt :

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Dear Torsten,
=


I was impressed with your article. It describes conside=
rations points very well that implementers of leading-edge authorization se=
rvers will eventually face or have already faced.

=
It seems to me that the mechanism of "structured_scope" can be po=
sitioned as a more generic mechanism whose usage doesn't necessarily ha=
ve to be limited to scopes. I mean that the mechanism can be used to includ=
e any arbitrary dynamic structured data in an authorization request. So, if=
 there were something I might be able to propose additionally, I would sugg=
est renaming "structured_scope" to a more generic name.

Best Regards,
Takahiko Kawasaki
Represe=
ntative director, Authlete, Inc.

2019=E5=B9=B44=E6=9C=8821=E6=97=
=A5(=E6=97=A5) 3:21 Torsten Lodderstedt <torsten@lodderstedt.net>:
Hi all, 



I just published an article about the subject at: https://medium.com/o=
auth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948=C2=A0 



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000aaf18905876a2608--


From nobody Fri Apr 26 03:52:01 2019
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 B8F711200A4 for ; Fri, 26 Apr 2019 03:51:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 9blmrzzt-oJp for ; Fri, 26 Apr 2019 03:51:57 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (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 CC9B9120033 for ; Fri, 26 Apr 2019 03:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/SkvzENdQPU+2a8e3WQdQ6ndrLAyaM4giJGONx3GfTc=; b=f09C2Ii7V/KNOKg79yFLdBA8L2JWDFVvo8zBayXARlul5eiC4sJDK8DHPCP/AXFr/cYYCI414tx9pe6s6+PzGcV/nZUyHQngde9e1aD8BrjupmT9MAky7nnL6WyujYl4yfxWge1g+85sOVJyWfrElCkCep+g7sengya/fH709Zs=
Received: from DB8PR08MB3980.eurprd08.prod.outlook.com (20.179.12.87) by DB8PR08MB5003.eurprd08.prod.outlook.com (10.255.16.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Fri, 26 Apr 2019 10:51:54 +0000
Received: from DB8PR08MB3980.eurprd08.prod.outlook.com ([fe80::8958:ef04:f5d4:837d]) by DB8PR08MB3980.eurprd08.prod.outlook.com ([fe80::8958:ef04:f5d4:837d%3]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 10:51:54 +0000
From: Luca Arnaboldi 
To: "oauth@ietf.org" 
Thread-Topic: Formal analysis of draft-ietf-oauth-pop-key-distribution
Thread-Index: AQHU/BpqKPkcnHWaK0OaLJqnsHk3QA==
Date: Fri, 26 Apr 2019 10:51:53 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Luca.Arnaboldi@arm.com; 
x-originating-ip: [128.240.225.113]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e8fae1a-7c7b-47f3-0d35-08d6ca353203
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB8PR08MB5003; 
x-ms-traffictypediagnostic: DB8PR08MB5003:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(39860400002)(366004)(40434004)(78124002)(199004)(189003)(5640700003)(7696005)(6436002)(2351001)(53936002)(71200400001)(71190400001)(99286004)(64756008)(66556008)(66476007)(66446008)(66066001)(55016002)(14454004)(33656002)(74316002)(6916009)(25786009)(6606003)(316002)(7736002)(966005)(76116006)(72206003)(66946007)(73956011)(54896002)(102836004)(6506007)(2501003)(52536014)(97736004)(186003)(26005)(81156014)(86362001)(1730700003)(5660300002)(81166006)(508600001)(8676002)(6306002)(19627405001)(256004)(476003)(14444005)(5024004)(68736007)(9686003)(486006)(2906002)(3846002)(6116002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR08MB5003; H:DB8PR08MB3980.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hUm+ohVdctI0SbA2jRY3zj7Y5ThUgZCsYsAAJJCELSv3NEsjGkWk7OTMov5tcsvwNrJbr+JNSF7TAU1FJqKCkf9Raaev+uRSni93HiJWjSPreWCORwlnRhHNbRV3IHKzJjPVnlsGZdd9jf/vsihfGCn4GzA1J+WAYesz1i54FQpzZE4CMtaWyQHviOeSW14Kfd+Gcxpm/Pu+H2008HHbEAL1YrWltKNpMOaOuqb7ogAgstn6JOvfEXNET2Esxlg0jSMYj9Qye4DEb1aqQAjksqyx4WLuRkNISAY4+O6TY6wxexexo4ucfAAXRdmYbZGaMbp+fTb9goyZP6c7FBfz37J2/jZ24ztErpctIqzmK5/VU327phwkS3JLaODM5+1kc/Ir3S82ESwlGn1AIfltvmwoPJ78tfoBzPz9ANam2Tc=
Content-Type: multipart/alternative; boundary="_000_DB8PR08MB39801EF8D75849CE0BC571678E3E0DB8PR08MB3980eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e8fae1a-7c7b-47f3-0d35-08d6ca353203
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 10:51:53.8810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5003
Archived-At: 
Subject: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution
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, 26 Apr 2019 10:52:00 -0000

--_000_DB8PR08MB39801EF8D75849CE0BC571678E3E0DB8PR08MB3980eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

* I spoke with Hannes after the IETF meeting in Prague and he expressed the=
 need to enhance our formal analysis (as presented at the OAuth Security Wo=
rkshop) to verify whether it is necessary to demonstrate possession of the =
private key by the client to the authorization server.


* The analysis checked whether it was necessary for a proof of possession t=
o be performed between the client and AS to ensure security. The result was=
 that even without verification by the AS the client would not be able to a=
ccess the resource from the RS without possessing the secret key associated=
 to the token (assuming the check is done correctly by the RS).

Tamarin model for specific example with proofs available at : https://githu=
b.com/Yiergot/ACE-OAuth-FormalModel


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_DB8PR08MB39801EF8D75849CE0BC571678E3E0DB8PR08MB3980eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












* I spoke with Hannes after the IETF meeting in Prague and he expresse=
d the need to enhance our formal analysis (as presented at the OAuth Securi=
ty Workshop) to verify whether it is necessary to demonstrate possession of=
 the private key by the client to
 the authorization server. 





* The analysis checked whether it was necessary for a proof of possession t=
o be performed between the client and AS to ensure security. The result was=
 that even without verification by the AS the client would not be able to a=
ccess the resource from the RS without
 possessing the secret key associated to the token (assuming the check is d=
one correctly by the RS).



Tamarin model for specific example with proofs available at : https://githu=
b.com/Yiergot/ACE-OAuth-FormalModel







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_DB8PR08MB39801EF8D75849CE0BC571678E3E0DB8PR08MB3980eurp_--


From nobody Fri Apr 26 07:07:00 2019
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 5EA3312046D for ; Fri, 26 Apr 2019 07:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, 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 EgAPnsNeAA9g for ; Fri, 26 Apr 2019 07:06:46 -0700 (PDT)
Received: from mail-vk1-f194.google.com (mail-vk1-f194.google.com [209.85.221.194]) (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 644E1120431 for ; Fri, 26 Apr 2019 07:06:45 -0700 (PDT)
Received: by mail-vk1-f194.google.com with SMTP id q189so782489vkq.11 for ; Fri, 26 Apr 2019 07:06:45 -0700 (PDT)
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=sDEYgiBKgnkM74KWTz5MyD7g9lIXIc0vtFT/KSqjtqY=; b=Z0KEb78g+DdDws9tHyzxxml/kAhrfc8gPBgWOAtZfKukT2q22Vdix+i/GpOxqloKBk q7kUd3zYwVNhVEHOD53Oz8Ck4AptYSog6fuX+eTkJjDI/HaW1uqCPb5WfocUGEjFc0Ss 3nGZuMYDuOwRQH3aghII2pzi7yWSGxu/9CcbVaH/K7V90T2ltvKS9EW6yLQzPWFnW38q 2V2h0aHGoR3BUKY0Xtyr5y6+LdbEJsvQlMNXW99lamqgugCUpBPnjxfgdUDgD07upGw6 v/dUr4Fu3nRiCsqsgeLxkLC0MKDley5u7oblcurnzuQR7E1oFHwlaEdTr45/6/KG/B3+ 8dnQ==
X-Gm-Message-State: APjAAAVEsWM+bn7hmP0hnsnseZZ4k6YOxMEnhHnIhsK++OQ4O1Nor1lW zleoeU6QcQHziRDNGiDmJboQ743cIXwdSQ0o4g86AinagvQ=
X-Google-Smtp-Source: APXvYqynyzVwKD+bUK8eUjydIsh9AV2w2K5qLcn28pZ8F8hY2jgHrhB97+quJDVJ93wJSHv9E51Z1w2PnvG3v9+I8Rg=
X-Received: by 2002:ac5:cb09:: with SMTP id r9mr5485724vkl.18.1556287604179; Fri, 26 Apr 2019 07:06:44 -0700 (PDT)
MIME-Version: 1.0
References:  <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>
In-Reply-To: <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>
From: Pedro Igor Silva 
Date: Fri, 26 Apr 2019 11:06:33 -0300
Message-ID: 
To: Jaap Francke 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d0e47c05876f7116"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
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, 26 Apr 2019 14:06:59 -0000

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

Hi Jaap,

Very good points. I have the same opinion about what you said about the
meaning of scopes (and how people are actually using them), the
resource-scope relationship and the importance of a standardized way of
doing this form of authorization to address different use cases, not only
delegation. Like George said in one of his messages, both 1st and 3rd party
use cases could be considered by a solution like that.

I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the client
does not yet have a bearer token or the bearer token is lacking the
required scopes/permissions. The resource server responds with:

*HTTP/1.1 403 Unauthorized *
*WWW-Authenticate: Bearer realm=3D"example",
error=3D"invalid_token",
claim_token=3D"accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"*

The claim_token response parameter returned by the resource server
represents all the security constraints (e.g.: scopes) and information
(e.g.: contextual) that the client needs in order to obtain a valid access
token from the AS. This token can be built by the RS or even use some
endpoint at the AS, as UMA does. It can be just a reference token too.

#2) Client obtains an access token from the token endpoint at the AS:

*POST /as/token.oauth2 HTTP/1.1*
*Host: as.example.com *
*Content-Type: application/x-www-form-urlencoded*
*grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission*
*&resource=3Dhttps%3A%2F%2Fbackend.example.com
%2Fapi%20*
*&claim_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token_type=3Durn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_to=
ken*

The example above shows a client request to the token endpoint when the
client already has an access token and wants a new token with permissions
to access a resource.

#3) Just like any other OAuth grant type, the token endpoint responds to
the client as follows (success):

*HTTP/1.1 200 OK*
*Content-Type: application/json;charset=3DUTF-8*
*Cache-Control: no-store*
*Pragma: no-cache*

*{*
*"access_token":"2YotnFZFEjr1zCsicMWpAA"*
*"token_type":"example",*
*"expires_in":3600,*
*"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"*
*} *

#4) Clients can now access protected resources using the access token with
all permissions granted by the server

It is not coincidence the similarities with and the usage of specs/drafts
like token exchange, resource-indicator, UMA, Lodging Intent Pattern, or
even ACE's "AS Request Creation Hints" message. The point I would like to
make is that we could leverage the standards/specs that exist today to
address the problem without reinventing the wheel.

There are very interesting things in UMA specs that can be used here too,
such as the possibility to perform incremental authorization or token
upgrade, etc.

Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke  wrote:

> Hi Torsten and others,
>
> I just read your blog - having =E2=80=9Cwe need to re-think OAuth scopes=
=E2=80=9D in the
> title immediately drew my attention.
> I find this interesting since I=E2=80=99m struggling with the concept of =
scopes
> from time-to-time.
> I=E2=80=99ll have to read the blog a few times more to get a good underst=
anding,
> but I would like to share some of my thoughts on scopes.
>
> I believe the OAuth scope concept has it=E2=80=99s limitations not only f=
or
> transactions but also for the more traditional =E2=80=98resource=E2=80=99=
 concept.
> RFC 6749 defines scopes as follows:
> "The value of the scope parameter is expressed as a list of space-
>    delimited, case-sensitive strings.  The strings are defined by the
>    authorization server.  If the value contains multiple space-delimited
>    strings, their order does not matter, and each string adds an
>    additional access range to the requested scope.=E2=80=9D
>
> I see 2 aspects in this definition:
> - how the strings should look like is beyond the scope of the RFC
> - each string adds an additional authorisation
>
> Scopes are associated with access_tokens, which typically are bearer
> tokens as defined by RFC 6750 as:
>       A security token with the property that any party in possession of
>       the token (a "bearer") can use the token in any way that any other
>       party in possession of it can.  Using a bearer token does not
>       require a bearer to prove possession of cryptographic key material
>       (proof-of-possession).=E2=80=9D
>
> This implies that every scope value should fully describe the
> authorisation that is given. In my view that is rarely done, which is the
> main reason why I find myself struggling with scope-concept.
>
> Here we have a collection of examples, which demonstrate to me that
> everyone is inventing their own wheels according to their specfic needs:
> https://brandur.org/oauth-scope
> https://api.slack.com/docs/oauth-scopes
>
> In various other (draft) standards I see bits and pieces that seem to
> address this issue.
>
> In UMA an authorisation is conceptually broken down into:
> - subject -> requesting party
> - verbs -> scopes of access
> - object -> resource set.
> I like this line of thinking and terminilogy.  However, if access_tokens
> are bearer tokens, I think =E2=80=99subject=E2=80=99 is the bearer of the=
 token.
>
> The most common practice, I think, is to use OIDC=E2=80=99s IDTokens to c=
ontain a set of claims that scope the scope of the scope :-).
>
> I mean that the claims in the ID-Tokens are used to scope the objects as =
well as the verbs/scopes of access.
>
> The core intention behind ID-token is to provide information about the au=
thenticated user and not necessarily about the resources that are accessed.=
 In practice, claims about the authenticated users indicate which resources=
 (photos) can be accessed at the resource server.
>
>
> My understanding of this draft https://tools.ietf.org/html/draft-ietf-oau=
th-resource-indicators-02
>
> is that the object/resource aspect of authorisation is taken somewhat out=
 of the scope and put into a dedicated parameter. Although (using the examp=
le from RFC 6749) the resource parameter indicates the resource server (or =
application,
>
>    API, etc.) rather than an individual resource that is stored at the re=
source server. So additional scoping of object/resource set is still needed=
 in addition to the resource parameter.
>
>
>
> Furthermore,
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 makes
> some interesting statements that are relevant in my view:
> The section on Access Token privilege restriction says "access tokens
> SHOULD be restricted to certain resources
>
>    and actions on resource servers or resources.=E2=80=9D So the OAuth sc=
ope-string still needs to somehow indicate the resource-scope of the privil=
ege that is communicated.
>
>
> " The client needs to tell the authorization server, at which URL it
>
>    will use the access token it is requesting.  It could use the
>    mechanism proposed [I-D.ietf-oauth-resource-indicators ] or encode the
>    information in the scope value.=E2=80=9D
>
>
> I=E2=80=99m not sure which point I=E2=80=99m trying to make; i guess the =
need for standardisation how to use and define OAuth-scopes.
>
> I like the Lodging Intent Pattern and need to do some more reading/thinki=
ng about the structured-scope and pushed request objects.
>
> I feel these concepts are not only relevant for authorisation of transact=
ions, but also for any access that needs authorisation.
>
>
> I=E2=80=99m not sure if i express myself clearly, nevertheless any feedba=
ck is welcome, if not alone to get my understanding of the various concepts=
 on a higher level.
>
>
> Thanks in advance, kind regards
>
>
> Jaap
>
>
>
>
>
>
>
>
> Message: 1
> Date: Wed, 24 Apr 2019 19:08:25 +0200
> From: Torsten Lodderstedt 
> To: Sascha Preibisch 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
> Message-ID: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
> Content-Type: text/plain; charset=3Dutf-8
>
> Hi Sascha,
>
> I see. I assume every element within the structured scope element to be a=
n
> independent scope (value) object and intended to use the name of that
> object as kind of content type definition.
>
> In my last example, the scope is defined as
>
>   "structured_scope":{
>      "sign":{
>         "credentialID":"qes_eidas",
>         "documentDigests":[
>            {
>               "hash":
>                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>               "label":"Mobile Subscription Contract"
>            }
>         ],
>         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>      },
>      "payment":{
>         "type":"sepa-credit-transfer",
>         "instructedAmount":{
>            "currency":"EUR",
>            "amount":"123.50"
>         },
>         "debtorAccount":{
>            "iban":"DE40100100103307118608"
>         },
>         "creditorName":"Merchant123",
>         "creditorAccount":{
>            "iban":"DE02100100109307118603"
>         },
>         "remittanceInformationUnstructured":"new Smartphone"
>      }
>
> This means ?sign" and ?payment" would determine the scheme of the
> respective object.
>
> What do you think?
>
> best regards,
> Torsten.
>
> On 23. Apr 2019, at 17:14, Sascha Preibisch 
> wrote:
>
> Hi Torsten!
>
> If 'structured_scope' would become a generic field for application
> specific content, I believe an indicator for the type of content would
> be needed on the long run. That is what I meant my 'profile'. I hope
> this helps!
>
> Thank you,
> Sascha
>
> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
> :
>
>
> Hi Sascha,
>
> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch  >:
>
> Thank you for the article, Torsten!
>
>
> my pleasure :-)
>
>
> I like that 'scope' is out of the game for these kinds of authorizations.
>
> What I can see for the general use case is a required identifier
> within the 'structures_scope' document that identifies the profile it
> should be used for.
>
>
> What does profile mean in this context?
>
> best regards,
> Torsten.
>
>
> Thank you,
> Sascha
>
> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> :
>
>
> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 126, Issue 58
> **************************************
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Hi Jaap,

Ve=
ry good points. I have the same opinion about what you said about the meani=
ng of scopes (and how people are actually using them), the resource-scope r=
elationship and the importance of a standardized way of doing this form of =
authorization to address different use cases, not only delegation. Like Geo=
rge said in one of his messages, both 1st and 3rd party use cases could be =
considered by a solution like that.

I would love t=
o see something based on OAuth like this:

#1)=
 Client tries to access a protected resource. At this point, the client doe=
s not yet have a bearer token or the bearer token is lacking the required s=
copes/permissions. The resource server responds with:

<=
div>HTTP/1.1 403 Unauthorized=C2=A0
WWW-Authenticate: B=
earer realm=3D"example", error=3D"invalid_token",=C2=A0=
claim_token=3D"accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"=
;

The claim_token response parameter retur=
ned by the resource server represents all the security constraints (e.g.: s=
copes) and information (e.g.: contextual) that the client needs in order to=
 obtain a valid access token from the AS. This token can be built by the RS=
 or even use some endpoint at the AS, as UMA does. It can be just a referen=
ce token too.

#2) Client obtains an access token f=
rom the token endpoint at the AS:

POST /as=
/token.oauth2 HTTP/1.1
Host:=C2=A0as.example.com
Content-Ty=
pe: application/x-www-form-urlencoded
grant_type=3Durn%3Ai=
etf%3Aparams%3Aoauth%3Agrant-type%3Apermission
&resour=
ce=3Dhttps%3A%2F%2Fbackend.example.com%2Fapi%20
&claim_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subj=
ect_token=3DaccVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&a=
mp;subject_token_type=3Durn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_t=
oken

The example above shows a client re=
quest to the token endpoint when the client already has an access token and=
 wants a new token with permissions to access a resource.

#3) Just like any other OAuth grant type, the token endpoint respon=
ds to the client as follows (success):

HTT=
P/1.1 200 OK
Content-Type: application/json;charset=3DUTF-=
8
Cache-Control: no-store
Pragma: no-cach=
e

{
"access_to=
ken":"2YotnFZFEjr1zCsicMWpAA"
"token_t=
ype":"example",
"expires_in":3600=
,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA&q=
uot;
}=C2=A0

#4)=
 Clients can now access protected resources using the access token with all=
 permissions granted by the server

It is not coinc=
idence the similarities with and the usage of specs/drafts like token excha=
nge, resource-indicator, UMA,=C2=A0Lodging Intent Pattern,=C2=A0or even ACE's &qu=
ot;AS Request Creation Hints" message. The point I would like to make =
is that we could leverage the standards/specs that exist today to address t=
he problem without reinventing the wheel.

Th=
ere are very interesting things in UMA specs that can be used here too, suc=
h as the possibility to perform incremental authorization or token upgrade,=
 etc.

Regards.
Pedro Igor

On Thu, Apr 25,=
 2019 at 4:27 AM Jaap Francke <jaap.francke=3D40iwelcome.com@dmarc.ietf.org&=
gt; wrote:







Hi Torsten and others,







I just read your blog - having =E2=80=9Cwe need to re-think OAuth scop=
es=E2=80=9D in the title immediately drew my attention.=C2=A0


I find this interesting since I=E2=80=99m struggling with the concept =
of scopes from time-to-time.


I=E2=80=99ll have to read the blog a few times more to get a good unde=
rstanding, but I would like to share some of my thoughts on scopes.







I believe the OAuth scope concept has it=E2=80=99s limitations not onl=
y for transactions but also for the more traditional =E2=80=98resource=E2=
=80=99 concept.


RFC 6749 defines scopes as follows:




"The value of the scope paramet=
er is expressed as a list of space-


=C2=A0=C2=A0 delimited, case-sensiti=
ve strings.=C2=A0 The strings are defined by the


=C2=A0=C2=A0 authorization server.=
=C2=A0 If the value contains multiple space-delimited


=C2=A0=C2=A0 strings, their order do=
es not matter, and each string adds an


=C2=A0=C2=A0 additional access range=
 to the requested scope.=E2=80=9D<=
/span>







I see 2 aspects in this definition:<=
/span>


- how the strings should look like i=
s beyond the scope of the RFC


- each string adds an additional aut=
horisation









Scopes are associated with access_tokens, which typically are bearer t=
okens as defined by RFC 6750 as:




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A sec=
urity token with the property that any party in possession of


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the t=
oken (a "bearer") can use the token in any way that any other


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 party=
 in possession of it can.=C2=A0 Using a bearer token does not


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requi=
re a bearer to prove possession of cryptographic key material


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (proo=
f-of-possession).=E2=80=9D<=
/div>






This implies that every scope value =
should fully describe the authorisation that is given. In my view that is r=
arely done, which is the main reason why I find myself struggling with scop=
e-concept.







Here we have a collection of example=
s, which demonstrate to me that everyone is inventing their own wheels acco=
rding to their specfic needs:









In various other (draft) standards I see bits and pieces that seem to =
address this issue.









In UMA an authorisation is conceptually broken down into:


- subject -> requesting party


- verbs -> scopes of access


- object -> resource set.


I like this line of thinking and terminilogy.=C2=A0 However, if access=
_tokens are bearer tokens, I think =E2=80=99subject=E2=80=99 is the bearer =
of the token.











The most common p=
ractice, I think, is to use OIDC=E2=80=99s IDTokens to contain a set of cla=
ims that scope the scope of the scope :-).=C2=A0


I mean that the c=
laims in the ID-Tokens are used to scope the objects as well as the verbs/s=
copes of access.


The core intentio=
n behind ID-token is to provide information about the authenticated user an=
d not necessarily about the resources that are accessed. In practice, claim=
s about the authenticated users indicate which resources (photos) can be ac=
cessed at the resource server. 





My understanding =
of this draft https://tools.ietf.org/html/dra=
ft-ietf-oauth-resource-indicators-02


is that the objec=
t/resource aspect of authorisation is taken somewhat out of the scope and p=
ut into a dedicated parameter. Although (using the example from RFC 6749) t=
he resource parameter indicates the resource server (or application,=



   API, etc.) rat=
her than an individual resource that is stored at the resource server. So a=
dditional scoping of object/resource set is still needed in addition to the=
 resource parameter.


















Furthermore,=C2=A0https://tools.ietf.org/html/draft=
-ietf-oauth-security-topics-12=C2=A0makes some interesting statements t=
hat are relevant in my view:


The section on Access Token privilege restriction says "access tokens SHOULD be restricted to certain re=
sources


   and actions on=
 resource servers or resources.=E2=80=9D So the OAuth scope-string still ne=
eds to somehow indicate the resource-scope of the privilege that is communi=
cated.





" The client needs to tell th=
e authorization server, at which URL it


   will use the access token it is request=
ing.  It could use the
   mechanism proposed [I-D.ietf-oaut=
h-resource-indicators] or encode the
   information in the scope value.=E2=80=9D





I=E2=80=99m not s=
ure which point I=E2=80=99m trying to make; i guess the need for standardis=
ation how to use and define OAuth-scopes.


I like the Lodgin=
g Intent Pattern and need to do some more reading/thinking about the struct=
ured-scope and pushed request objects.


I feel these conc=
epts are not only relevant for authorisation of transactions, but also for =
any access that needs authorisation.





I=E2=80=99m not sure=
 if i express myself clearly, nevertheless any feedback is welcome, if not =
alone to get my understanding of the various concepts on a higher level.





Thanks in advance, k=
ind regards





Jaap




































Message: 1

Date: Wed, 24 Apr 2019 19:08:25 +0200

From: Torsten Lodderstedt <torsten@lodderstedt.net>

To: Sascha Preibisch <saschapreibisch@gmail.com>

Cc: oauth <oauth@iet=
f.org>

Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth

Message-ID: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodders=
tedt.net>

Content-Type: text/plain; 
charset=3Dutf-8



Hi Sascha,



I see. I assume every element within the structured scope element to be an =
independent scope (value) object and intended to use the name of that objec=
t as kind of content type definition.




In my last example, the scope is defined as 



=C2=A0=C2=A0"structured_scope":{ =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"sign":{ =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"credentialID":&q=
uot;qes_eidas",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"documentDigests"=
:[ =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<=
br>
=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"hash":

=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"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D&q=
uot;,

=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"label":"Mobile Subscription Contract"

=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"hashAlgorithmOID"=
;:"2.16.840.1.101.3.4.2.1"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0},

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"payment":{ =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"type":"sepa=
-credit-transfer",

=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=C2=A0=C2=A0=C2=A0=C2=A0"cur=
rency":"EUR",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"amo=
unt":"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=C2=A0=C2=A0=C2=A0=C2=A0"debtorAccount":{=
 =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"iba=
n":"DE40100100103307118608"

=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"creditorName":&q=
uot;Merchant123",

=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0"iba=
n":"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=C2=A0=C2=A0=C2=A0=C2=A0"remittanceInformation=
Unstructured":"new Smartphone"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}



This means ?sign" and ?payment" would determine the scheme of the=
 respective object.




What do you think?



best regards, 

Torsten. 




On 23. Apr 2019, at 17:14, Sascha Preibisch <<=
a href=3D"mailto:saschapreibisch@gmail.com" target=3D"_blank">saschapreibis=
ch@gmail.com> wrote:



Hi Torsten!



If 'structured_scope' would become a generic field for application<=
br>
specific content, I believe an indicator for the type of content would

be needed on the long run. That is what I meant my 'profile'. I hop=
e

this helps!



Thank you,

Sascha



Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt

<torsten@lo=
dderstedt.net>:




Hi Sascha,




Am 22.04.2019 um 20:34 schrieb Sascha Preibisch &=
lt;saschapre=
ibisch@gmail.com>:



Thank you for the article, Torsten!





my pleasure :-)






I like that 'scope' is out of the game for these kinds of authoriza=
tions.



What I can see for the general use case is a required identifier

within the 'structures_scope' document that identifies the profile =
it

should be used for.





What does profile mean in this context?



best regards,

Torsten.




Thank you,

Sascha



Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt

<torsten@lo=
dderstedt.net>:




Hi all,



I just published an article about the subject at: 
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-t=
hink-oauth-scopes-2326e2038948



I look forward to getting your feedback.



kind regards,

Torsten.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth















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



Subject: Digest Footer



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





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



End of OAuth Digest, Vol 126, Issue 58

**************************************














_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000d0e47c05876f7116--


From nobody Fri Apr 26 07:17:49 2019
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 67FA1120453 for ; Fri, 26 Apr 2019 07:17:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wzxrMzccOG-x for ; Fri, 26 Apr 2019 07:17:34 -0700 (PDT)
Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 DD1AF120447 for ; Fri, 26 Apr 2019 07:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556288252; bh=De1zCG/2WbYCTqKRd5ahfKbQeuoZyg848jby/xQs5pw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=I1pjUwHR2MrqNLsMMqGtS2N9oAW1hEf8ibhKo6Df6GL+njtNVGvm5XXkWBrAux/R/FY26iup5pNsr56H5rdZd/R3LfmpKsYIVcuLqMNzU+ZFm21eir4L78t0ldiqWlC6LEicoMpGb/Okkq5RJg/5BT0Vm+grG53pgF8AfzdgoL2MtzpsGfhl2+9xJZy5S+UtvmpwPagdDIEFDwc+WQYVQmZUJJC/Fx0mXadUU3LVNkrM4C1LgTXwOdt9d6ONUBKTZg/XUiA71lBkej4YkrXBBXl6spX/62msejZ6Uk5T0mrnO2KZYpO2GznXd+fJ+2R8W/PzOiN0Bo3dfboGvHv80w==
X-YMail-OSG: hwrfwjEVM1kwNMdYZjjlUJ_CxscxuoKPyPRV9_8cn5yP1ax5YkjUr5dSLpGCv2V pOBNJeNYf6h6iVzowtJSIEPmzXzOI.9cjBykOCskUjPihI5KIIuKYesdDOBjgZ70qU5ghqyQ1sqS 6re4EXwOrqqiCm4bSUlGkFM10bVpDmoSvzzLhAAUzKUzObREA3CtYMMeegGpxN4snrbcd1HeKvY4 JNqCyv8hPoAtdFGfx.Aqr7JI4WNOYFQDqhmZYL0AO2kUDSKXR4RCuRRnc6bN.LlXam3NECzbCv82 Ip4vGubZZ9c1_8pgGfjpK3KoGXFnppfWuZ0iDL18k7RqiVXYQvDGniXU42z2PqswfDbH62O85UFH 6.lfl8EHT6XXpJbHTSupjZTLrxIEzJBRzxRtUt9abHPlXdoEOdySSiBZuNTaN2tnPCcGziDJJ_M4 dhDPDRXJbtpNygT2a_oiLCBB9KJpNeB82o55GOExJ_yb4d.NSTS_xoQg.ppaOAd.juzF2u65uxa_ dsgmYmnpnGULWHP9cE.EEhNG1DRKjAqbfrf9wYpggBTINssb3Fu6rRY3.cft.Z3hCt39zkaYeU5k NMnKTvd4L0HvDvB62G5rBjO8Se.KTkQjmsVFIEzMtKhqykHnraG8fAowrqQqs.ecZxIbtxg0RERL D8HmpLlm6h8WPKznqWbTJqAXloQDaUs0EukpsuOZdoRoJq.Ko6CIZOcsa0NmS7WnkQP8ccLEs3Fq C3UR.pjAhtvZNqtJqA4PUKIFKpWxo_wJKnurYzvOthrCDrLO8EAiBGPIvaBlBvMSCLkBFYtI7CAK CnllADONYSBuQYBUsQWYIC1kqg6iS32wCNG86hiY8d7ggTADvnXDoV6tGc70QjUmnqDu7nPKfgZk XWMUusKxhnrh9.rd1CV1DjFuNjWQCwDNWwLEWxv2TPyYIgR9trprlCPlAWICLX0wIfsxWBqDJhj8 ZmxD6ZNQxjkro0zFOc00AiYW_qBp9f1xFD7ex3sM_r9K86Z9zqNccsr3de6H8xOQf31dxOAGGU3D dFBRqevNc3bToPT3VZoyMKHy1racuYILvSLkVrgIYmY_0i7ubW1XUYHvbSc4xuZ0q0r87wpLnJsi 1NGx1NfKyBg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Apr 2019 14:17:32 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 01f5d52cb073ab53fb0403f6a1bb1ab8;  Fri, 26 Apr 2019 14:17:27 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: Sascha Preibisch , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
Date: Fri, 26 Apr 2019 10:17:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F18232DABEF90B539B745C18"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2019 14:17:48 -0000

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



On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>
>
> Am 25.04.2019 um 17:03 schrieb George Fletcher  >:
>
>> A couple of thoughts...
>>
>> 1. It doesn't feel like these are scopes (at least not as scope is 
>> defined by RFC 6749). It feels like they are more transaction 
>> requirements.
>
> What???s the difference? In my opinion, if you authorize a transaction 
> it???s the same. Moreover, in other use cases (account information) it a 
> complex requirement for a potentially long lasting grant.
>
> In both cases, they describe the request power of the token == it???s scope.
I guess I look at scope as "authorized to transfer" maybe something like 
"authorized to transfer up to 10K". However the details of which account 
to take the money from and the account of where to put the money are not 
aspects of the scope but rather restrictions on the transaction.

It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent from 
the user to perform that transaction... but I don't think the details of 
the transaction should be considered scope(s).

For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".
>
>>
>> 2. The schemas are going to be very ecosystem specific, correct?
>
> API (e.g. all psd2 standards), ecosystem, single deployment - just 
> like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should convey 
the client is authorized to perform a set of actions (capabilities) and 
then the API parameters define the exact details of that particular 
transaction.
>
>>
>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>> Hi Sascha,
>>>
>>> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition.
>>>
>>> In my last example, the scope is defined as
>>>
>>>     "structured_scope":{
>>>        "sign":{
>>>           "credentialID":"qes_eidas",
>>>           "documentDigests":[
>>>              {
>>>                 "hash":
>>>                   "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>>>                 "label":"Mobile Subscription Contract"
>>>              }
>>>           ],
>>>           "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>        },
>>>        "payment":{
>>>           "type":"sepa-credit-transfer",
>>>           "instructedAmount":{
>>>              "currency":"EUR",
>>>              "amount":"123.50"
>>>           },
>>>           "debtorAccount":{
>>>              "iban":"DE40100100103307118608"
>>>           },
>>>           "creditorName":"Merchant123",
>>>           "creditorAccount":{
>>>              "iban":"DE02100100109307118603"
>>>           },
>>>           "remittanceInformationUnstructured":"new Smartphone"
>>>        }
>>>
>>> This means ???sign" and ???payment" would determine the scheme of the respective object.
>>>
>>> What do you think?
>>>
>>> best regards,
>>> Torsten.
>>>
>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:
>>>>
>>>> Hi Torsten!
>>>>
>>>> If 'structured_scope' would become a generic field for application
>>>> specific content, I believe an indicator for the type of content would
>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>> this helps!
>>>>
>>>> Thank you,
>>>> Sascha
>>>>
>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>> :
>>>>> Hi Sascha,
>>>>>
>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:
>>>>>>
>>>>>> Thank you for the article, Torsten!
>>>>> my pleasure :-)
>>>>>
>>>>>> I like that 'scope' is out of the game for these kinds of authorizations.
>>>>>>
>>>>>> What I can see for the general use case is a required identifier
>>>>>> within the 'structures_scope' document that identifies the profile it
>>>>>> should be used for.
>>>>> What does profile mean in this context?
>>>>>
>>>>> best regards,
>>>>> Torsten.
>>>>>> Thank you,
>>>>>> Sascha
>>>>>>
>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>> :
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I just published an article about the subject at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>>>
>>>>>>> I look forward to getting your feedback.
>>>>>>>
>>>>>>> kind 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
>>


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


  
    
  
  
    

    

    
On 4/25/19 1:54 PM, Torsten Lodderstedt
      wrote:

    

    

      
      


      

      


        Am 25.04.2019 um 17:03 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          A couple of
            thoughts...

            

            1. It doesn't feel like these are scopes (at least not as
            scope is defined by RFC 6749). It feels like they are more
            transaction requirements.

          

      

      


      

      What???s the difference? In my opinion, if you authorize a
      transaction it???s the same. Moreover, in other use cases (account
      information) it a complex requirement for a potentially long
      lasting grant.
      


      

      
In both cases, they describe the request power of the token
        == it???s scope.

      

    

    I guess I look at scope as "authorized to transfer" maybe something
    like "authorized to transfer up to 10K". However the details of
    which account to take the money from and the account of where to put
    the money are not aspects of the scope but rather restrictions on
    the transaction. 

    

    It may be fine to have a model where the client tells the AS what
    transaction it wants to perform for the purpose of getting consent
    from the user to perform that transaction... but I don't think the
    details of the transaction should be considered scope(s).

    

    For me.. scope is a capability the client is authorized to
    perform... "send an Instant message", or "read a buddy list".

    

      

        


          

            
 

                2. The schemas are going to be very ecosystem specific,
                correct?

              

          

          


          

          
API (e.g. all psd2 standards), ecosystem, single
            deployment - just like ???traditional??? scope values

        

      

    

    Again, I would want the transaction requirements to be part of the
    API not part of the scope. In my mind, the authorization token
    should convey the client is authorized to perform a set of actions
    (capabilities) and then the API parameters define the exact details
    of that particular transaction.

    

      

        


          

            
 

              
On 4/24/19 1:08 PM, Torsten
                Lodderstedt wrote:

              

              

                
Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 



                

                  
On 23. Apr 2019, at 17:14, Sascha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                  

                    
Hi Sascha,



                    

                      
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


                    

                    
my pleasure :-)



                    

                      
I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


                    

                    
What does profile mean in this context?

best regards,
Torsten.


                    

                      
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                      

                        
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind 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


              

              

            

          

        

      

    

    

  


--------------F18232DABEF90B539B745C18--


From nobody Fri Apr 26 07:35:23 2019
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 2D3061201D9 for ; Fri, 26 Apr 2019 07:35:21 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cSJokrv3oU4R for ; Fri, 26 Apr 2019 07:35:18 -0700 (PDT)
Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 1076112014B for ; Fri, 26 Apr 2019 07:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556289316; bh=0quAIiMDwkYML0udi5X5fekpzClzAfmr+ZAeoSvOIg0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hNkFjVY/nTSN5aEaH935p7kTLhsdhAyZWw2Wiohv2M2RiG3kJzGXIh9+MkQoNq/Ohw3wX7YS74GhcaJfyVMMi/BycOw4bzo/9hBoufgQOX/Xf98a5+BUOWH72VFazcaJcC9nuOtu9Ujk9xCzIHJva2Dr0JSAHGnlKWcKefXeUvo1FhRxhfAA6ixHhH8+i3GJkgosxlhFpg/JVd3iH0B6ytQE4JzPwUv9g0yisn11gdviQ+HoV52bJs8g4OnFPgFio6HRrj3jmQIwugC14NbI+nQ7pYLjSczpg0zKOEo5bSWn2h2Q69ik5LNGj0bha6YQR4t6Tv6+wHim2te2AtOXQw==
X-YMail-OSG: 6rTjoh8VM1lkgC3hiitrGH72wsWJUuAWj1e.J_ymovqE3_R4kQrRALi8TBQwhD3 psbMueqMfQJmRo6DCID9ss69QNi2klgilY.ugX0A4scSaBU7wGJgabRGGa9ig_UdVZ8s0nQKJJmI iQ.qg1JOCL3uHpm.ng1ThIDILQf8ttz1ymFvyQoIM71zp9rP.CrVeasEiu.YF5bnhn45EnzpN8Nh skF0Rv0sMW7JHv2X3YGQhDKnkZOKUdWnmxrweWl1YISjog7XBtEPnn33UOBWCN0EZSFBao22retP 9OBlLqrf_0qasb2Bl.tCkQAjnfymu0SXmz1DNhxtfEQhuvbRkLVrQ_ebo._1ceUa7skZkAQE6gzs Fp9sjZo7hnWXaFPZjyYgwC1netE9i_pZobwMTZJXTESEhanpjasiL_aDpYR_Mtg9rONAFA6oH1mQ 2Y71XYBffdMxeMjjgvzeKVV_gQRTHnjhRomHFDcwRZuigKw30WC8ctvxV0LblCdbTDwhBhw4KsKe TDTumI1Njn_gKASi2oicY4hQKlYUTXXIR95fpzZUzhJ0GrkvZTYXcvIkRpwJlVy9DJQZO1T_gKOi gcnEsJnC8W_2w8RvWN5L.T.mFobC1l7T6Bf5W8zC5yeii_tyHVlbteNYLPSGiZp4SS7NP7Jy2wtw hVOQ268PsDadlSY8YGFE0zTrFS58dQIw1OEh7EAC4yBUs_vMdeacsd0iS4ao2BzueJLd4sWTYAKz nucoF5w4LkCOzrjJRw4HhZbmUEbMa7.n3tTrYhkTt80BQLXoWg3NpRnl0w9H4vusWS9d6ASwtGFQ LclrS2N4EtyzoJesVfHzRjkozqXIfHGyP2fPi73j4YSleKf.hjexrACFtRDqNQ00WGjaUtRljIwV Vpg1OWH4y92eHIEsx3squZEvwJ4mGru0CLMmmw3ii1vC3FGEn2onE.J0Rq8W7_0CQpOb4fejq1YF TKNnBqV3Y5i3nznTcdVb44zQ9tfGLrkycotmyvS_.VrP_btknwCwlNEO6.m2iUZoDJNT93mCxc92 vnmi.8dMIX2lTja6UNX9qmntzQevjx8IX0pNQt.D1ClC0NXZcgBj_QWZwba00N6EPv786XI7u8nB bF8nvPO6ohhoe6jy6og--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Apr 2019 14:35:16 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b95448e4e409b19859d2c1fabdee4ec7;  Fri, 26 Apr 2019 14:35:13 +0000 (UTC)
To: George Fletcher , Torsten Lodderstedt 
Cc: Sascha Preibisch , oauth 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <291d464d-ce6c-52ea-302f-d57cecd0b973@aol.com>
Date: Fri, 26 Apr 2019 10:35:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
Content-Type: multipart/alternative; boundary="------------C8A04C82F3021361EADAFF86"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2019 14:35:21 -0000

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

Look at this in more detail... what about calling it 
"transactional_scope" instead of "structured_scope" as the scope is 
specific to an individual transaction and not applicable across 
transactions. That would then separate it from the more capability based 
'scope' provided by OAuth2.

In this context I like the pushed-request-object method as the resource 
server is going to need to pull the same transactional requirements when 
it receives the access token.

Thanks,
George

On 4/26/19 10:17 AM, George Fletcher wrote:
>
>
> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>
>>
>> Am 25.04.2019 um 17:03 schrieb George Fletcher > >:
>>
>>> A couple of thoughts...
>>>
>>> 1. It doesn't feel like these are scopes (at least not as scope is 
>>> defined by RFC 6749). It feels like they are more transaction 
>>> requirements.
>>
>> What???s the difference? In my opinion, if you authorize a 
>> transaction it???s the same. Moreover, in other use cases (account 
>> information) it a complex requirement for a potentially long lasting 
>> grant.
>>
>> In both cases, they describe the request power of the token == it???s 
>> scope.
> I guess I look at scope as "authorized to transfer" maybe something 
> like "authorized to transfer up to 10K". However the details of which 
> account to take the money from and the account of where to put the 
> money are not aspects of the scope but rather restrictions on the 
> transaction.
>
> It may be fine to have a model where the client tells the AS what 
> transaction it wants to perform for the purpose of getting consent 
> from the user to perform that transaction... but I don't think the 
> details of the transaction should be considered scope(s).
>
> For me.. scope is a capability the client is authorized to perform... 
> "send an Instant message", or "read a buddy list".
>>
>>>
>>> 2. The schemas are going to be very ecosystem specific, correct?
>>
>> API (e.g. all psd2 standards), ecosystem, single deployment - just 
>> like ???traditional??? scope values
> Again, I would want the transaction requirements to be part of the API 
> not part of the scope. In my mind, the authorization token should 
> convey the client is authorized to perform a set of actions 
> (capabilities) and then the API parameters define the exact details of 
> that particular transaction.
>>
>>>
>>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>>> Hi Sascha,
>>>>
>>>> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition.
>>>>
>>>> In my last example, the scope is defined as
>>>>
>>>>     "structured_scope":{
>>>>        "sign":{
>>>>           "credentialID":"qes_eidas",
>>>>           "documentDigests":[
>>>>              {
>>>>                 "hash":
>>>>                   "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>>>>                 "label":"Mobile Subscription Contract"
>>>>              }
>>>>           ],
>>>>           "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>>        },
>>>>        "payment":{
>>>>           "type":"sepa-credit-transfer",
>>>>           "instructedAmount":{
>>>>              "currency":"EUR",
>>>>              "amount":"123.50"
>>>>           },
>>>>           "debtorAccount":{
>>>>              "iban":"DE40100100103307118608"
>>>>           },
>>>>           "creditorName":"Merchant123",
>>>>           "creditorAccount":{
>>>>              "iban":"DE02100100109307118603"
>>>>           },
>>>>           "remittanceInformationUnstructured":"new Smartphone"
>>>>        }
>>>>
>>>> This means ???sign" and ???payment" would determine the scheme of the respective object.
>>>>
>>>> What do you think?
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:
>>>>>
>>>>> Hi Torsten!
>>>>>
>>>>> If 'structured_scope' would become a generic field for application
>>>>> specific content, I believe an indicator for the type of content would
>>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>>> this helps!
>>>>>
>>>>> Thank you,
>>>>> Sascha
>>>>>
>>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>>> :
>>>>>> Hi Sascha,
>>>>>>
>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:
>>>>>>>
>>>>>>> Thank you for the article, Torsten!
>>>>>> my pleasure :-)
>>>>>>
>>>>>>> I like that 'scope' is out of the game for these kinds of authorizations.
>>>>>>>
>>>>>>> What I can see for the general use case is a required identifier
>>>>>>> within the 'structures_scope' document that identifies the profile it
>>>>>>> should be used for.
>>>>>> What does profile mean in this context?
>>>>>>
>>>>>> best regards,
>>>>>> Torsten.
>>>>>>> Thank you,
>>>>>>> Sascha
>>>>>>>
>>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>>> :
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I just published an article about the subject at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>>>>
>>>>>>>> I look forward to getting your feedback.
>>>>>>>>
>>>>>>>> kind 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
>>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Look at this in more
      detail... what about calling it "transactional_scope" instead of
      "structured_scope" as the scope is specific to an individual
      transaction and not applicable across transactions. That would
      then separate it from the more capability based 'scope' provided
      by OAuth2.

      

      In this context I like the pushed-request-object method as the
      resource server is going to need to pull the same transactional
      requirements when it receives the access token.

      

      Thanks,

      George

    

    
On 4/26/19 10:17 AM, George Fletcher
      wrote:

    

    

      
      

      

      
On 4/25/19 1:54 PM, Torsten
        Lodderstedt wrote:

      

      

        
        


        

        


          Am 25.04.2019 um 17:03 schrieb George Fletcher <gffletch@aol.com>:

          

        

        

          

            
            A couple of
              thoughts...

              

              1. It doesn't feel like these are scopes (at least not as
              scope is defined by RFC 6749). It feels like they are more
              transaction requirements.

            

        

        


        

        What???s the difference? In my opinion, if you authorize a
        transaction it???s the same. Moreover, in other use cases
        (account information) it a complex requirement for a potentially
        long lasting grant.
        


        

        
In both cases, they describe the request power of the token
          == it???s scope.

        

      

      I guess I look at scope as "authorized to transfer" maybe
      something like "authorized to transfer up to 10K". However the
      details of which account to take the money from and the account of
      where to put the money are not aspects of the scope but rather
      restrictions on the transaction. 

      

      It may be fine to have a model where the client tells the AS what
      transaction it wants to perform for the purpose of getting consent
      from the user to perform that transaction... but I don't think the
      details of the transaction should be considered scope(s).

      

      For me.. scope is a capability the client is authorized to
      perform... "send an Instant message", or "read a buddy list".

      

        

          


            

              

                  

                  2. The schemas are going to be very ecosystem
                  specific, correct?

                

            

            


            

            
API (e.g. all psd2 standards), ecosystem, single
              deployment - just like ???traditional??? scope values

          

        

      

      Again, I would want the transaction requirements to be part of the
      API not part of the scope. In my mind, the authorization token
      should convey the client is authorized to perform a set of actions
      (capabilities) and then the API parameters define the exact
      details of that particular transaction.

      

        

          


            

              

                

                
On 4/24/19 1:08 PM, Torsten
                  Lodderstedt wrote:

                

                

                  
Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 



                  

                    
On 23. Apr 2019, at 17:14, Sascha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                    

                      
Hi Sascha,



                      

                        
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


                      

                      
my pleasure :-)



                      

                        
I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


                      

                      
What does profile mean in this context?

best regards,
Torsten.


                      

                        
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                        

                          
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind 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


                

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------C8A04C82F3021361EADAFF86--


From nobody Fri Apr 26 07:41:16 2019
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 44BDC12014B for ; Fri, 26 Apr 2019 07:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_MIME_MALF=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=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 4b46xgHjOs0Q for ; Fri, 26 Apr 2019 07:41:10 -0700 (PDT)
Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (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 8E9621201E8 for ; Fri, 26 Apr 2019 07:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556289668; bh=kPLfVi5ZFPlIeG/2Fzp2DuwjNN9uvRrPWK2FqHwt/aE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ox51KfFhsKcHHnSJjbkhzPX6AGqOvpThApdw1XVvyv2AepqSmr1MabsIkKr5E0njrpX1bQZcMpSxUTCRY91dwp0cla1vS+NS695K+24rg8XaM5JnrjB1l9SRuQCQOeGEx/tXXCODk6e1pFE5H7BqwMx5ZxFR1PGhDOd1Egzt1tRJRUZK1jEcGwCeRZN69Xt/W9UlXfduQAon/AVPnPzz7zRF0gq8EKawYllhsBZ2Orsv9QTZIwwH5Gyg9MN7gZlraGIhc3b86Q0Mc7RTSLJ5/QpOBafzudtuUE6DiYn4unat7VYD89hRLLz0w1vEplUSK0GtgXGk15ciuTI4O7f7Jw==
X-YMail-OSG: NHExNMAVM1kS7hTLw2fq0U18a.wNacmS__2T69u13c9GZWsMUybgU1SV6Ol5aGt RJjkF4e9QUygaaOPZyYiGaDdOWBBF0FDQMuRfqXjdUua7faNANPlNcR8b7lWY0COoQ0W4wYprxjs jrOtE66j.w5q7fLUE1KI2gESQU3hcVehRk54KacCC80hhJT99Sfd9b1y7BU1i3opxbYdLtEEn4Wy wDfthLxZZ9_3LqQ8_ozXPS4XNp0btfnMuZntBfqbKD9eD5IjwtTRi2dsfXhg09TeIPP444ie0r3R o5SvxbRvxBBwVZupDp5Nbkwjc4hJ90c.uh8MxNYHE3FtGmTPdSOFEEiZ6utfCO7xr_CHKUVeS8_U TuX79et.Qav.9zv6Be68tVBe7wQl3OeAMG552VmdZu0mqjggPSNzGxdUvvbHLIabA_n6JGi_EePC pUwgK..8SDV3zvatOgZSXZsrODvQQwhw3xBYriLtOjiykbeOAxXbdo2KAuKSgRXLA.I2Yjs1Qu1Q 5EXFfOC9.n5hNIXKGjSpLHhw.WRRUm5ZWAJMdTUpZe2M574qeASriVrecZC9tPgccojnWhqvillD _X2eelN509Otcs7AuHlBleIoE_RJBa1tDWp3XS2dq00W2MrCoxuz5mt_niO5P62j27xSdHYGwsTQ FmuQ9iKXwyaitEcc4UvybIcFg5tFAx2adFL32OEyz.NRB2qdanIH4PZj6IBQKNIY7rtbZBBqHTRe yhysIOxXAYcs_qEwovyjm7TFhROWbwocC_Haqhi.KQdGgQZ26HVVnr708vIw1z47ZoReoxELqoN6 nxUodYiCvCFORpupBYRk5uQgqG9iucaEiFTxngrmAPtBdsVWnRs9dRw6XO6h_XEKkmfCM8sk6Mgj rxBfOrEVwtS1U4zNa0R7bGy30spmbsJrXXvLjgqTvNaf7iKFI4serJaAhJLXwTKpmL5jplETO_C5 2.wPsE0tKjHYcZ0f_s0.rQgzNAIkihRVO9pYKXLc1vdhx6cuLIqX8UuuKWmkl1fTrrVQob92luKT V6uRkmbcdTnyWsc6Vrm_d_70psa.jcQMf6kJyjRXfSgc1z0cMBkd.9JfZyo9s_PS_E0jVyH9oXLx bbBhj
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Apr 2019 14:41:08 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 117f979ec380d8fbfb0630ec1b121fad;  Fri, 26 Apr 2019 14:41:04 +0000 (UTC)
To: Pedro Igor Silva , Jaap Francke 
Cc: "oauth@ietf.org" 
References:  <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <1099fde4-1bca-d521-30cb-65bf834d0d86@aol.com>
Date: Fri, 26 Apr 2019 10:41:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0DB23682520317FFB6E88CC3"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
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, 26 Apr 2019 14:41:15 -0000

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

I agree that we definitely need better definition and guidance around 
scopes and authorized access patterns.

I think what is unique about what Torsten is proposing is that in his 
case he wants to authorize an individual transaction (not a set of 
transactions). Normally, with scopes and access tokens the goal is to 
get an access token that can perform a number of transactions with a 
restricted set of capabilities.

I think we need to separate the concept of transactional authorization 
from capability authorization.

On 4/26/19 10:06 AM, Pedro Igor Silva wrote:
> Hi Jaap,
>
> Very good points. I have the same opinion about what you said about 
> the meaning of scopes (and how people are actually using them), the 
> resource-scope relationship and the importance of a standardized way 
> of doing this form of authorization to address different use cases, 
> not only delegation. Like George said in one of his messages, both 1st 
> and 3rd party use cases could be considered by a solution like that.
>
> I would love to see something based on OAuth like this:
>
> #1) Client tries to access a protected resource. At this point, the 
> client does not yet have a bearer token or the bearer token is lacking 
> the required scopes/permissions. The resource server responds with:
>
> /HTTP/1.1 403 Unauthorized /
> /WWW-Authenticate: Bearer realm="example", error="invalid_token", 
> *claim_token*="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"/
>
> The claim_token response parameter returned by the resource server 
> represents all the security constraints (e.g.: scopes) and information 
> (e.g.: contextual) that the client needs in order to obtain a valid 
> access token from the AS. This token can be built by the RS or even 
> use some endpoint at the AS, as UMA does. It can be just a reference 
> token too.
>
> #2) Client obtains an access token from the token endpoint at the AS:
>
> /POST /as/token.oauth2 HTTP/1.1/
> /Host: as.example.com /
> /Content-Type: application/x-www-form-urlencoded/
> /grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission/
> /&resource=https%3A%2F%2Fbackend.example.com 
> %2Fapi%20/
> /&*claim_token*=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
> /&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
> /&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token/
>
> The example above shows a client request to the token endpoint when 
> the client already has an access token and wants a new token with 
> permissions to access a resource.
>
> #3) Just like any other OAuth grant type, the token endpoint responds 
> to the client as follows (success):
>
> /HTTP/1.1 200 OK/
> /Content-Type: application/json;charset=UTF-8/
> /Cache-Control: no-store/
> /Pragma: no-cache/
> /
> /
> /{/
> /"access_token":"2YotnFZFEjr1zCsicMWpAA"/
> /"token_type":"example",/
> /"expires_in":3600,/
> /"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"/
> /} /
> /
> /
> #4) Clients can now access protected resources using the access token 
> with all permissions granted by the server
>
> It is not coincidence the similarities with and the usage of 
> specs/drafts like token exchange, resource-indicator, UMA, Lodging 
> Intent Pattern,??or even ACE's "AS Request Creation Hints" message. The 
> point I would like to make is that we could leverage the 
> standards/specs that exist today to address the problem without 
> reinventing the wheel.
>
> There are very interesting things in UMA specs that can be used here 
> too, such as the possibility to perform incremental authorization or 
> token upgrade, etc.
>
> Regards.
> Pedro Igor
>
> On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke 
>  > wrote:
>
>     Hi Torsten and others,
>
>     I just read your blog - having ???we need to re-think OAuth scopes???
>     in the title immediately drew my attention.
>     I find this interesting since I???m struggling with the concept of
>     scopes from time-to-time.
>     I???ll have to read the blog a few times more to get a good
>     understanding, but I would like to share some of my thoughts on
>     scopes.
>
>     I believe the OAuth scope concept has it???s limitations not only
>     for transactions but also for the more traditional ???resource??? concept.
>     RFC 6749 defines scopes as follows:
>     "The value of the scope parameter is expressed as a list of space-
>     ???? delimited, case-sensitive strings.?? The strings are defined by the
>     ???? authorization server.?? If the value contains multiple
>     space-delimited
>     ???? strings, their order does not matter, and each string adds an
>     ???? additional access range to the requested scope.???
>
>     I see 2 aspects in this definition:
>     - how the strings should look like is beyond the scope of the RFC
>     - each string adds an additional authorisation
>
>     Scopes are associated with access_tokens, which typically are
>     bearer tokens as defined by RFC 6750 as:
>     ?????????? A security token with the property that any party in
>     possession of
>     ?????????? the token (a "bearer") can use the token in any way that any
>     other
>     ?????????? party in possession of it can.?? Using a bearer token does not
>     ?????????? require a bearer to prove possession of cryptographic key
>     material
>     (proof-of-possession).???
>
>     This implies that every scope value should fully describe the
>     authorisation that is given. In my view that is rarely done, which
>     is the main reason why I find myself struggling with scope-concept.
>
>     Here we have a collection of examples, which demonstrate to me
>     that everyone is inventing their own wheels according to their
>     specfic needs:
>     https://brandur.org/oauth-scope
>     https://api.slack.com/docs/oauth-scopes
>
>     In various other (draft) standards I see bits and pieces that seem
>     to address this issue.
>
>     In UMA an authorisation is conceptually broken down into:
>     - subject -> requesting party
>     - verbs -> scopes of access
>     - object -> resource set.
>     I like this line of thinking and terminilogy. However, if
>     access_tokens are bearer tokens, I think ???subject??? is the bearer
>     of the token.
>
>     The most common practice, I think, is to use OIDC???s IDTokens to
>     contain a set of claims that scope the scope of the scope :-).
>
>     I mean that the claims in the ID-Tokens are used to scope the
>     objects as well as the verbs/scopes of access.
>
>     The core intention behind ID-token is to provide information about
>     the authenticated user and not necessarily about the resources
>     that are accessed. In practice, claims about the authenticated
>     users indicate which resources (photos) can be accessed at the
>     resource server.
>
>     My understanding of this draft
>     https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
>
>     is that the object/resource aspect of authorisation is taken
>     somewhat out of the scope and put into a dedicated parameter.
>     Although (using the example from RFC 6749) the resource parameter
>     indicates theresource server (or application,
>
>     API, etc.) rather than an individual resource that is stored at
>     the resource server. So additional scoping of object/resource set
>     is still needed in addition to the resource parameter.
>
>
>
>     Furthermore,
>     https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12??makes
>     some interesting statements that are relevant in my view:
>     The section on Access Token privilege restriction says "access
>     tokens SHOULD be restricted to certain resources
>
>     and actions on resource servers or resources.??? So the OAuth
>     scope-string still needs to somehow indicate the resource-scope of
>     the privilege that is communicated.
>
>     "The client needs to tell the authorization server, at which URL it
>
>         will use the access token it is requesting.  It could use the
>         mechanism proposed [I-D.ietf-oauth-resource-indicators  ] or encode the
>         information in the scope value.???
>
>     I???m not sure which point I???m trying to make; i guess the need for
>     standardisation how to use and define OAuth-scopes.
>
>     I like the Lodging Intent Pattern and need to do some more
>     reading/thinking about the structured-scope and pushed request
>     objects.
>
>     I feel these concepts are not only relevant for authorisation of
>     transactions, but also for any access that needs authorisation.
>
>     I???m not sure if i express myself clearly, nevertheless any
>     feedback is welcome, if not alone to get my understanding of the
>     various concepts on a higher level.
>
>     Thanks in advance, kind regards
>
>     Jaap
>
>
>
>
>
>
>>     Message: 1
>>     Date: Wed, 24 Apr 2019 19:08:25 +0200
>>     From: Torsten Lodderstedt >     >
>>     To: Sascha Preibisch >     >
>>     Cc: oauth >
>>     Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
>>     Message-ID: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net
>>     >
>>     Content-Type: text/plain;charset=utf-8
>>
>>     Hi Sascha,
>>
>>     I see. I assume every element within the structured scope element
>>     to be an independent scope (value) object and intended to use the
>>     name of that object as kind of content type definition.
>>
>>     In my last example, the scope is defined as
>>
>>     ????"structured_scope":{
>>     ??????????"sign":{
>>     ????????????????"credentialID":"qes_eidas",
>>     ????????????????"documentDigests":[
>>     ??????????????????????{
>>     ????????????????????????????"hash":
>>     ????????????????????????????????"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>>     ????????????????????????????"label":"Mobile Subscription Contract"
>>     ??????????????????????}
>>     ????????????????],
>>     ????????????????"hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>     ??????????},
>>     ??????????"payment":{
>>     ????????????????"type":"sepa-credit-transfer",
>>     ????????????????"instructedAmount":{
>>     ??????????????????????"currency":"EUR",
>>     ??????????????????????"amount":"123.50"
>>     ????????????????},
>>     ????????????????"debtorAccount":{
>>     ??????????????????????"iban":"DE40100100103307118608"
>>     ????????????????},
>>     ????????????????"creditorName":"Merchant123",
>>     ????????????????"creditorAccount":{
>>     ??????????????????????"iban":"DE02100100109307118603"
>>     ????????????????},
>>     ????????????????"remittanceInformationUnstructured":"new Smartphone"
>>     ??????????}
>>
>>     This means ?sign" and ?payment" would determine the scheme of the
>>     respective object.
>>
>>     What do you think?
>>
>>     best regards,
>>     Torsten.
>>
>>>     On 23. Apr 2019, at 17:14, Sascha Preibisch
>>>     >
>>>     wrote:
>>>
>>>     Hi Torsten!
>>>
>>>     If 'structured_scope' would become a generic field for application
>>>     specific content, I believe an indicator for the type of content
>>>     would
>>>     be needed on the long run. That is what I meant my 'profile'. I hope
>>>     this helps!
>>>
>>>     Thank you,
>>>     Sascha
>>>
>>>     Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>     >:
>>>>
>>>>     Hi Sascha,
>>>>
>>>>>     Am 22.04.2019 um 20:34 schrieb Sascha Preibisch
>>>>>     >:
>>>>>
>>>>>     Thank you for the article, Torsten!
>>>>
>>>>     my pleasure :-)
>>>>
>>>>>
>>>>>     I like that 'scope' is out of the game for these kinds of
>>>>>     authorizations.
>>>>>
>>>>>     What I can see for the general use case is a required identifier
>>>>>     within the 'structures_scope' document that identifies the
>>>>>     profile it
>>>>>     should be used for.
>>>>
>>>>     What does profile mean in this context?
>>>>
>>>>     best regards,
>>>>     Torsten.
>>>>>
>>>>>     Thank you,
>>>>>     Sascha
>>>>>
>>>>>     Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>     >:
>>>>>>
>>>>>>     Hi all,
>>>>>>
>>>>>>     I just published an article about the subject at:
>>>>>>     https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>>     
>>>>>>
>>>>>>     I look forward to getting your feedback.
>>>>>>
>>>>>>     kind regards,
>>>>>>     Torsten.
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     OAuth@ietf.org 
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     ------------------------------
>>
>>     Subject: Digest Footer
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     ------------------------------
>>
>>     End of OAuth Digest, Vol 126, Issue 58
>>     **************************************
>
>     _______________________________________________
>     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


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


  
    
  
  
    I agree that we definitely
      need better definition and guidance around scopes and authorized
      access patterns. 

      

      I think what is unique about what Torsten is proposing is that in
      his case he wants to authorize an individual transaction (not a
      set of transactions). Normally, with scopes and access tokens the
      goal is to get an access token that can perform a number of
      transactions with a restricted set of capabilities.

      

      I think we need to separate the concept of transactional
      authorization from capability authorization.

    

    
On 4/26/19 10:06 AM, Pedro Igor Silva
      wrote:

    

    

      
      

        

          
Hi Jaap,

          


          

          
Very good points. I have the same opinion about what you
            said about the meaning of scopes (and how people are
            actually using them), the resource-scope relationship and
            the importance of a standardized way of doing this form of
            authorization to address different use cases, not only
            delegation. Like George said in one of his messages, both
            1st and 3rd party use cases could be considered by a
            solution like that.

          


          

          
I would love to see something based on OAuth like this:

          


          

          

            
#1) Client tries to access a protected resource. At
              this point, the client does not yet have a bearer token or
              the bearer token is lacking the required
              scopes/permissions. The resource server responds with:

            


            

            
HTTP/1.1 403 Unauthorized??

            
WWW-Authenticate: Bearer realm="example",
                error="invalid_token",??claim_token="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"

            

            


            

            
The claim_token response parameter returned by the
              resource server represents all the security constraints
              (e.g.: scopes) and information (e.g.: contextual) that the
              client needs in order to obtain a valid access token from
              the AS. This token can be built by the RS or even use some
              endpoint at the AS, as UMA does. It can be just a
              reference token too.

            


            

            
#2) Client obtains an access token from the token
              endpoint at the AS:

            


            

            

              
POST /as/token.oauth2 HTTP/1.1

              
              
Content-Type: application/x-www-form-urlencoded

              
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission

              
&resource=https%3A%2F%2Fbackend.example.com%2Fapi%20

              
&claim_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC

              
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC

              
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

            

            


            

            
The example above shows a client request to the token
              endpoint when the client already has an access token and
              wants a new token with permissions to access a resource.

            


            

            
#3) Just like any other OAuth grant type, the token
              endpoint responds to the client as follows (success):

            


            

            

              
HTTP/1.1 200 OK

              
Content-Type: application/json;charset=UTF-8

              
Cache-Control: no-store

              
Pragma: no-cache

              


                

              
{

              
"access_token":"2YotnFZFEjr1zCsicMWpAA"

              
"token_type":"example",

              
"expires_in":3600,

              
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

              
}??

            

            


              

            
#4) Clients can now access protected resources using
              the access token with all permissions granted by the
              server

            


            

            
It is not coincidence the similarities with and the
              usage of specs/drafts like token exchange,
              resource-indicator, UMA,??Lodging
                Intent Pattern,??or even ACE's "AS Request
              Creation Hints" message. The point I would like to make is
              that we could leverage the standards/specs that exist
              today to address the problem without reinventing the
              wheel.

          

          


          

          
There are very interesting things in UMA specs that can
            be used here too, such as the possibility to perform
            incremental authorization or token upgrade, etc.

          


          

          
Regards.

          
Pedro Igor

          

          

            
On Thu, Apr 25, 2019 at
              4:27 AM Jaap Francke <jaap.francke=40iwelcome.com@dmarc.ietf.org>
              wrote:

            

            

              

                
Hi Torsten and others,

                


                

                
I just read your blog - having ???we need to re-think
                  OAuth scopes??? in the title immediately drew my
                  attention.??

                
I find this interesting since I???m struggling with
                  the concept of scopes from time-to-time.

                
I???ll have to read the blog a few times more to get
                  a good understanding, but I would like to share some
                  of my thoughts on scopes.

                


                

                
I believe the OAuth scope concept has it???s
                  limitations not only for transactions but also for the
                  more traditional ???resource??? concept.

                
RFC 6749 defines scopes as follows:

                

                  
"The value of the
                      scope parameter is expressed as a list of space-

                  
???? delimited,
                      case-sensitive strings.?? The strings are defined
                      by the

                  
???? authorization
                      server.?? If the value contains multiple
                      space-delimited

                  
???? strings, their
                      order does not matter, and each string adds an

                  
???? additional
                      access range to the requested scope.???

                  


                    

                  
I see 2 aspects
                      in this definition:

                  
- how the strings
                      should look like is beyond the scope of the RFC

                  
- each string
                      adds an additional authorisation

                  


                    

                

                
Scopes are associated with access_tokens, which
                  typically are bearer tokens as defined by RFC 6750 as:

                

                  
?????????? A security
                      token with the property that any party in
                      possession of

                  
?????????? the token
                      (a "bearer") can use the token in any way that any
                      other

                  
?????????? party in
                      possession of it can.?? Using a bearer token does
                      not

                  
?????????? require a
                      bearer to prove possession of cryptographic key
                      material

                  
??????????
                      (proof-of-possession).???

                  


                    

                  
This implies that
                      every scope value should fully describe the
                      authorisation that is given. In my view that is
                      rarely done, which is the main reason why I find
                      myself struggling with scope-concept.

                  


                    

                  
Here we have a
                      collection of examples, which demonstrate to me
                      that everyone is inventing their own wheels
                      according to their specfic needs:

                  
                  
                  


                  

                  
In various other (draft) standards I see bits and
                    pieces that seem to address this issue.

                  


                  

                  

                    
In UMA an authorisation is conceptually broken
                      down into:

                    
- subject -> requesting party

                    
- verbs -> scopes of access

                    
- object -> resource set.

                    
I like this line of thinking and terminilogy.??
                      However, if access_tokens are bearer tokens, I
                      think ???subject??? is the bearer of the token.

                  

                  


                  

                  

                    
The most common practice, I think, is to use OIDC???s IDTokens to contain a set of claims that scope the scope of the scope :-).??

                    
I mean that the claims in the ID-Tokens are used to scope the objects as well as the verbs/scopes of access.

                    
The core intention behind ID-token is to provide information about the authenticated user and not necessarily about the resources that are accessed. In practice, claims about the authenticated users indicate which resources (photos) can be accessed at the resource server. 

                    



                    
My understanding of this draft https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

                    
is that the object/resource aspect of authorisation is taken somewhat out of the scope and put into a dedicated parameter. Although (using the example from RFC 6749) the resource parameter indicates the resource server (or application,

                    
   API, etc.) rather than an individual resource that is stored at the resource server. So additional scoping of object/resource set is still needed in addition to the resource parameter.

                    


                    

                  

                  

                    


                    

                  

                  
Furthermore,??https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12??makes
                    some interesting statements that are relevant in my
                    view:

                  
The section on Access Token privilege restriction
                    says "access
                      tokens SHOULD be restricted to certain resources

                  
   and actions on resource servers or resources.??? So the OAuth scope-string still needs to somehow indicate the resource-scope of the privilege that is communicated.

                  



                  
" The client
                      needs to tell the authorization server, at which
                      URL it

                  
   will use the access token it is requesting.  It could use the
   mechanism proposed [I-D.ietf-oauth-resource-indicators] or encode the
   information in the scope value.???

                  

                  
I???m not sure which point I???m trying to make; i guess the need for standardisation how to use and define OAuth-scopes.

                  
I like the Lodging Intent Pattern and need to do some more reading/thinking about the structured-scope and pushed request objects.

                  
I feel these concepts are not only relevant for authorisation of transactions, but also for any access that needs authorisation.

                  



                  
I???m not sure if i express myself clearly, nevertheless any feedback is welcome, if not alone to get my understanding of the various concepts on a higher level.

                  



                  
Thanks in advance, kind regards

                  



                  
Jaap

                  


                  

                  

                  

                

                


                

                


                

                


                

                


                  

                    

                      
Message: 1

                        Date: Wed, 24 Apr 2019 19:08:25 +0200

                        From: Torsten Lodderstedt <torsten@lodderstedt.net>

                        To: Sascha Preibisch <saschapreibisch@gmail.com>

                        Cc: oauth <oauth@ietf.org>

                        Subject: Re: [OAUTH-WG] Transaction
                        Authorization with OAuth

                        Message-ID: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>

                        Content-Type: text/plain; 
                        charset=utf-8

                        

                        Hi Sascha,

                        

                        I see. I assume every element within the
                        structured scope element to be an independent
                        scope (value) object and intended to use the
                        name of that object as kind of content type
                        definition.
                        

                        

                        In my last example, the scope is defined as 

                        

                        ????"structured_scope":{ ??

                        ??????????"sign":{ ??

                        ????????????????"credentialID":"qes_eidas",

                        ????????????????"documentDigests":[ ??

                        ??????????????????????{ ??

                        ????????????????????????????"hash":

????????????????????????????????"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",

                        ????????????????????????????"label":"Mobile Subscription
                        Contract"

                        ??????????????????????}

                        ????????????????],

????????????????"hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"

                        ??????????},

                        ??????????"payment":{ ??

                        ????????????????"type":"sepa-credit-transfer",

                        ????????????????"instructedAmount":{ ??

                        ??????????????????????"currency":"EUR",

                        ??????????????????????"amount":"123.50"

                        ????????????????},

                        ????????????????"debtorAccount":{ ??

                        ??????????????????????"iban":"DE40100100103307118608"

                        ????????????????},

                        ????????????????"creditorName":"Merchant123",

                        ????????????????"creditorAccount":{ ??

                        ??????????????????????"iban":"DE02100100109307118603"

                        ????????????????},

                        ????????????????"remittanceInformationUnstructured":"new
                        Smartphone"

                        ??????????}

                        

                        This means ?sign" and ?payment" would determine
                        the scheme of the respective object.
                        

                        

                        What do you think?

                        

                        best regards, 

                        Torsten. 

                        

                        
On 23. Apr 2019, at
                          17:14, Sascha Preibisch <saschapreibisch@gmail.com>
                          wrote:

                          

                          Hi Torsten!

                          

                          If 'structured_scope' would become a generic
                          field for application

                          specific content, I believe an indicator for
                          the type of content would

                          be needed on the long run. That is what I
                          meant my 'profile'. I hope

                          this helps!

                          

                          Thank you,

                          Sascha

                          

                          Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb
                          Torsten Lodderstedt

                          <torsten@lodderstedt.net>:

                          


                            Hi Sascha,

                            

                            
Am 22.04.2019 um
                              20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

                              

                              Thank you for the article, Torsten!

                            

                            

                            my pleasure :-)

                            

                            


                              I like that 'scope' is out of the game for
                              these kinds of authorizations.

                              

                              What I can see for the general use case is
                              a required identifier

                              within the 'structures_scope' document
                              that identifies the profile it

                              should be used for.

                            

                            

                            What does profile mean in this context?

                            

                            best regards,

                            Torsten.

                            


                              Thank you,

                              Sascha

                              

                              Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb
                              Torsten Lodderstedt

                              <torsten@lodderstedt.net>:

                              


                                Hi all,

                                

                                I just published an article about the
                                subject at: 
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

                                

                                I look forward to getting your feedback.

                                

                                kind regards,

                                Torsten.

_______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

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

                              

                            

                          

                        

                        

                        

                        

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

                        

                        Subject: Digest Footer

                        

                        _______________________________________________

                        OAuth mailing list

                        OAuth@ietf.org

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

                        

                        

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

                        

                        End of OAuth Digest, Vol 126, Issue 58

                        **************************************

                      

                    

                  

                

                

              

              _______________________________________________

              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


    

    

  


--------------0DB23682520317FFB6E88CC3--


From nobody Fri Apr 26 10:57:51 2019
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 F0F87120320 for ; Fri, 26 Apr 2019 10:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 ZkKU5CNFfEdY for ; Fri, 26 Apr 2019 10:57:42 -0700 (PDT)
Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 6095C12030F for ; Fri, 26 Apr 2019 10:57:42 -0700 (PDT)
Received: by mail-it1-x12e.google.com with SMTP id a190so7219206ite.4 for ; Fri, 26 Apr 2019 10:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OjjVhIC3eY70rwew+HY/NFryiNttM2qXMahjc5S0hYw=; b=Ese3C1blwpldIkjYcPJwn7YKr8yz+azuoGD+ZCLYT8RGIRBDczYracefu3akdBECq4 cI3++G6Tz4LvgvwPvfEHA5piCSOTOlHFVZ8nllYvP2X6Iiq98N6MDNiGvAJ0HyqkX/24 RVQbbcrQio/cnWcMIj3mZxG+Xq3q1VFofOjYw=
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=OjjVhIC3eY70rwew+HY/NFryiNttM2qXMahjc5S0hYw=; b=NXcrjYFXImU6gTEXrCGwZ4kShnOsTu4dD8XkYP3mFAwgbBRfM1G+wbOnlQewriCgy8 FaGw27scyxG/Ri+n96P/V+9jsXhT7xVc+soH2g+Gtc+24AAFi8q09SOuPka+xz/U/NDN lEQ4JoFaqgUPXjFU9++bgWI+sHs7PSBBX5m/bJHCAyjV0ko4Kk6V8IFyaIKbg6GGqWon ivYQFkCjuRi1YRUXV5KtwUcIizgbNzMlIzOrkmbMOwvPIwktbNjt7OLITDNVxYsmAAKV 9sDk2B/egURglwxASD2DMZim2hPwMDSYtmCJz/HX5ri6ixwvPn4y2jWno2TWZZ3qyyZW 6zIQ==
X-Gm-Message-State: APjAAAXTNoCB680GKYtWXTjjjvsJjsJBWfxGcz1kcN7rsNCnO2bq6DOS CYlN2rCRDVNKLsMVhtUQ4anZBVWipKfUMdk38UA5zcqblUD81w1P+AFjE+rgteXP2IROLKP2bg1 1vS6spdrcgAOGN6MiBbc=
X-Google-Smtp-Source: APXvYqykY/Aj2vs8mYSAlH4d5wU2BhJdH7Ked3t2FbD7RUYGcd2ItHUmNlCjCOq4zbKje9C7s2PMU3blnu252qHOAk0=
X-Received: by 2002:a24:2fc9:: with SMTP id j192mr9220893itj.45.1556301461556;  Fri, 26 Apr 2019 10:57:41 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
In-Reply-To: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>
From: Brian Campbell 
Date: Fri, 26 Apr 2019 11:57:14 -0600
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000c7ab1f058772abb2"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2019 17:57:50 -0000

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

One thing that I think is missing from the article in the discussion of
pros and cons is that in many cases a large or even voluminous request can
be sent via auto submitting form post (like
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the
other way around from client to AS with the auth request), which doesn't
then run into the same URI size problem.

>From a prospective standardization standpoint, there are really two
distinct concepts in the article. One is the "Pushed Request Object" and
the other the "Structured Scope". They are certainly complementary things
but each could also be useful and used independently of one another. So I'd
argue that they should be developed independently too.



On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re=
-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> _______________________________________________
> 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._

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


One thing that I th=
ink is missing from the article in the discussion of pros and cons is that =
in many cases a large or even voluminous request can be sent via auto submi=
tting form post (like https://openid.net/specs/oauth-=
v2-form-post-response-mode-1_0.html but the other way around from clien=
t to AS  with the auth request), which doesn't then run into the same U=
RI size problem. 

From a prospective standardi=
zation standpoint, there are really two distinct concepts in the article. O=
ne is the "Pushed Request Object" and the other the "Structu=
red Scope". They are certainly complementary things but each could als=
o be useful and used independently of one another. So I'd argue that th=
ey should be developed independently too. 



On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <torsten@lodderst=
edt.net> wrote:
Hi all, 



I just published an article about the subject at: https://medium.com/o=
auth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948=C2=A0 



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

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.
--000000000000c7ab1f058772abb2--


From nobody Fri Apr 26 12:23:54 2019
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 85CDC120117 for ; Fri, 26 Apr 2019 12:23:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvLQ7wNRz-Ro for ; Fri, 26 Apr 2019 12:23:49 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0: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 E010B1200EA for ; Fri, 26 Apr 2019 12:23:48 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id a6so3823982oie.5 for ; Fri, 26 Apr 2019 12:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FkFe5nYK3jxoEj0Scb8Pz0rF7wUQWUEnynxdBazW6uQ=; b=QnfSSalED6gWdUKe+dsqmHLC4v4mRd5ULSzqwZvBA5gjAzIeIXkmb4iSh8ts6AEmxG 073URX+9SYJmy/7UpPlDhlG4e0kmY2BIZnPjkDdyH4fr4nbdOkK3YOyRtA9pA6T3fNbH QzSkWVBpXqpjWufvRRT1R6dXvI0d4ahA/NUT3jcFSIkri4noIlCDDuWBKq6l5N8FTJs5 3FFQJI2zoQI8sgrs4ZfZG+sxFQRRdaVDKE9IRmEPEViTQJoecXzCuTm+Gk14wl2C7WT2 7f80H4mXzggRNqygR8XppCNqSE+yPRgWYKj9ihlB08H0Jjh5J+/NyLgaJWq121RuhVcf 0KWA==
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=FkFe5nYK3jxoEj0Scb8Pz0rF7wUQWUEnynxdBazW6uQ=; b=ff03WlZlWTrycG+ITj6dSDUrVnuZmb/R3R2Eh2UQw6MgEOTRPU2OeuVGOwSaZiwUiM giR9NlyrITwJE97qrHuENm2IoUovPF6xmm9wLAYtqK2VQBXx0hpu+D84r3ReaLeYTYkK fIE6kdLCoBuwL8vl3VawAE00EBKaJyEGjwpehG2tYIvnREi+NFGcpJ4LoFVKCpJywJsm UGjXHMjSlAawRyC1RRHkzSStBLo4ZcFxRCkCbhdlHQXrKU2jgBsc9Y2OQfPww6AuIJVh 2/dY0Fd4JYfij9btv4YgRLBLxq+lpPrRTYZ+w32UGzKCuvr25D4abOWcxCsAzEky/uGs f/UA==
X-Gm-Message-State: APjAAAXib9mWjgIa/lX6BDYJLBIN2Yvk94favn+GioFDjb/jq26lQDdl CODpYPWMNVw/cf1WWWSLC4caTbv19oxprUA9wUS6ItK0Z28rFg==
X-Google-Smtp-Source: APXvYqy/2kaJpKd2A5LnMV3nTVT1S8OKaJfFYP9I8ncM671KHgx341taTKMVTItwjpEzTtwYAgAEwyO5CKGDy1HD8iU=
X-Received: by 2002:aca:df55:: with SMTP id w82mr8213483oig.113.1556306627442;  Fri, 26 Apr 2019 12:23:47 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
In-Reply-To: 
From: Steinar Noem 
Date: Fri, 26 Apr 2019 21:23:30 +0200
Message-ID: 
To: Brian Campbell 
Cc: Torsten Lodderstedt , oauth 
Content-Type: multipart/alternative; boundary="000000000000b0d48a058773df27"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2019 19:23:53 -0000

--000000000000b0d48a058773df27
Content-Type: text/plain; charset="UTF-8"

I do not have the depth of understanding of OAuth as you guys, so forgive
me if I'm missing the discussion completely.

For me this sort of boils down to how we establish trust between the
different roles in OAuth. For an API the trust lies between the AS and
itself. The API may have no trust in the clients directly, but relies on
the AS to provide the user consent, client authentication but also e.g. the
use of request objects. At least in my domain, the API might not trust
"claims" as parameters in a request from the client, but will trust the
"claims" in an access token.
In my domain the trust established between the client and the AS is an
important part of the ability to interact across security domains. It also
provides a way for us to establish domain standards for representing
different types of authoritative information.
For instance, we have a legal requirement to log certain types of
information about the user when exchanging sensitive information. This
information is usually tied to a OAuth scope, e.g. "get patient records".
The suggested use of "structured_scope" not only gives us an opportunity to
convey contextual information that can be shown in the user consent,  it
also gives us a way of enforcing national domain-specific standards of
expressing different types of information tied to the scope (e.g.
prescription, sick note, patient records etc) which would make
interoperability within the health sector easier.
Also, the health sector in Norway has a strict legislation regarding
privacy and patient rights,, so we would actually log the issued access
tokens with structured_scopes to fulfil some of the legal requirements.

Personally I'm not sure what makes more sense, the "structured_scope" or
"transaction_scope" name - but "transaction_scope" is more semantically
loaded.
I also agree with mr. Campbell that the concepts should be treated
separately.

Steinar


fre. 26. apr. 2019 kl. 19:58 skrev Brian Campbell :

> One thing that I think is missing from the article in the discussion of
> pros and cons is that in many cases a large or even voluminous request can
> be sent via auto submitting form post (like
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but
> the other way around from client to AS with the auth request), which
> doesn't then run into the same URI size problem.
>
> From a prospective standardization standpoint, there are really two
> distinct concepts in the article. One is the "Pushed Request Object" and
> the other the "Structured Scope". They are certainly complementary things
> but each could also be useful and used independently of one another. So I'd
> argue that they should be developed independently too.
>
>
>
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> I just published an article about the subject at:
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>> 
>>
>>
>> I look forward to getting your feedback.
>>
>> kind regards,
>> Torsten.
>> _______________________________________________
>> 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
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |

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


I do not have the depth of understan=
ding of OAuth as you guys, so forgive me if I'm missing the discussion =
completely.

For me this sort of boils down to how =
we establish trust between the different roles in OAuth. For an API the tru=
st lies between the AS and itself. The API may have no trust in the clients=
 directly, but relies on the AS to provide the user consent, client authent=
ication but also e.g. the use of request objects. At least in my domain, th=
e API might not trust "claims" as parameters in a request from th=
e client, but will trust the "claims" in an access token.
In my domain the trust established between the client and the AS is an i=
mportant part of the ability to interact across security domains. It also p=
rovides a way for us to establish domain standards for representing differe=
nt types of authoritative information.
For instance, we have a le=
gal requirement to log certain types of information about the user when exc=
hanging sensitive information. This information is usually tied to a OAuth =
scope, e.g. "get patient records".=C2=A0
The suggested =
use of "structured_scope" not only gives us an opportunity to con=
vey contextual information that can be shown in the user consent,=C2=A0 it =
also gives us a way of enforcing national domain-specific standards of expr=
essing different types of information tied to the scope (e.g. prescription,=
 sick note, patient records etc) which would make interoperability within t=
he health sector easier.
Also, the health sector in Norway has a =
strict legislation regarding privacy and patient rights,, so we would actua=
lly log the issued access tokens with structured_scopes to fulfil some of t=
he legal requirements.

Personally I'm not sure=
 what makes more sense, the "structured_scope" or "transacti=
on_scope" name - but "transaction_scope" is more semanticall=
y loaded.
I also agree with mr. Campbell that the concepts should=
 be treated separately.

<mvh>Steinar</mvh=
>


fre. 26. apr. 2019 kl. 19:58 skrev Brian Cam=
pbell <bcampbell=3D=
40pingidentity.com@dmarc.ietf.org>:
One thing that I think is missing from the article in the discussio=
n of pros and cons is that in many cases a large or even voluminous request=
 can be sent via auto submitting form post (like http=
s://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the =
other way around from client to AS  with the auth request), which doesn'=
;t then run into the same URI size problem. 

F=
rom a prospective standardization standpoint, there are really two distinct=
 concepts in the article. One is the "Pushed Request Object" and =
the other the "Structured Scope". They are certainly complementar=
y things but each could also be useful and used independently of one anothe=
r. So I'd argue that they should be developed independently too. 
=




On Sat, Apr 20, 2019 at 12:21 PM =
Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all, 



I just published an article about the subject at: https://medium.com/=
oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2=
326e2038948=C2=A0 



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

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 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




-- 
Vennlig hilsen=


Steinar Noem
Partner Udelt AS
Systemutvikler<=
/div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n=
o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.=
no=C2=A0|=C2=A0


--000000000000b0d48a058773df27--


From nobody Sat Apr 27 20:57:40 2019
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 43D991200E6 for ; Sat, 27 Apr 2019 20:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7xrEVuTyW5aA for ; Sat, 27 Apr 2019 20:57: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 0385A120048 for ; Sat, 27 Apr 2019 20:57:37 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3S3vWCA024923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Apr 2019 23:57:34 -0400
Date: Sat, 27 Apr 2019 22:57:32 -0500
From: Benjamin Kaduk 
To: Luca Arnaboldi 
Cc: "oauth@ietf.org" 
Message-ID: <20190428035731.GE60332@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.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution
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, 28 Apr 2019 03:57:39 -0000

On Fri, Apr 26, 2019 at 10:51:53AM +0000, Luca Arnaboldi wrote:
> * I spoke with Hannes after the IETF meeting in Prague and he expressed the need to enhance our formal analysis (as presented at the OAuth Security Workshop) to verify whether it is necessary to demonstrate possession of the private key by the client to the authorization server.
> 
> 
> * The analysis checked whether it was necessary for a proof of possession to be performed between the client and AS to ensure security. The result was that even without verification by the AS the client would not be able to access the resource from the RS without possessing the secret key associated to the token (assuming the check is done correctly by the RS).

My apologies for not checking the model directly (I'm on a plane), but I'll
note that we have seen similar PoP scenarios in other protocols where a
misbehaving client will deliberately try to bind the (valid) key from
another party to a token it authorizes, which can sometimes result in the
other party taking actions different from the ones they intended.  So I'd
suggest being careful about what scope of attacks are considered.

Thanks,

Ben


From nobody Sat Apr 27 21:08:31 2019
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 EE7EE1200B1 for ; Sat, 27 Apr 2019 21:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x3KmcsmGwWgC for ; Sat, 27 Apr 2019 21:08:27 -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 8AC03120048 for ; Sat, 27 Apr 2019 21:08:26 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3S48Laq027230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 00:08:23 -0400
Date: Sat, 27 Apr 2019 23:08:21 -0500
From: Benjamin Kaduk 
To: Torsten Lodderstedt 
Cc: Sascha Preibisch , oauth 
Message-ID: <20190428040821.GF60332@kduck.mit.edu>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Apr 2019 04:08:29 -0000

On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote:
> Hi Sascha,
> 
> I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 
> 
> In my last example, the scope is defined as 
> 
>    "structured_scope":{  
>       "sign":{  
>          "credentialID":"qes_eidas",
>          "documentDigests":[  
>             {  
>                "hash":
>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>                "label":"Mobile Subscription Contract"
>             }
>          ],
>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>       },
>       "payment":{  
>          "type":"sepa-credit-transfer",
>          "instructedAmount":{  
>             "currency":"EUR",
>             "amount":"123.50"
>          },
>          "debtorAccount":{  
>             "iban":"DE40100100103307118608"
>          },
>          "creditorName":"Merchant123",
>          "creditorAccount":{  
>             "iban":"DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured":"new Smartphone"
>       }
> 
> This means “sign" and “payment" would determine the scheme of the respective object. 
> 
> What do you think?

I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the
"typ" header, and all the reasoning we have to do about different types of
tokens (not) being replayable at a different endpoint and being interpreted
wrongly.

-Ben


From nobody Mon Apr 29 05:29:29 2019
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 9D450120315 for ; Mon, 29 Apr 2019 05:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Y4mu9ge128A5 for ; Mon, 29 Apr 2019 05:29:26 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE47112012B for ; Mon, 29 Apr 2019 05:29:26 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 42411B81DDA; Mon, 29 Apr 2019 05:29:16 -0700 (PDT)
To: dick.hardt@gmail.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: bcampbell@pingidentity.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20190429122916.42411B81DDA@rfc-editor.org>
Date: Mon, 29 Apr 2019 05:29:16 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)
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, 29 Apr 2019 12:29:29 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5708

--------------------------------------
Type: Editorial
Reported by: Brian Campbell 

Section: 3.1 and 3.2

Original Text
-------------
Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
MUST NOT be included more than once.

Corrected Text
--------------
Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
defined by this specification MUST NOT be included more than once.

Notes
-----
Adds the text "defined by this specification" to the last sentence to clarify that the restriction only applies to parameters defined in RFC 6749 and not to unrecognized parameters or parameters defined by extension.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Apr 29 05:34:42 2019
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 AD38912012B for ; Mon, 29 Apr 2019 05:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 mtpB9BJeqSZG for ; Mon, 29 Apr 2019 05:34:37 -0700 (PDT)
Received: from mail-it1-x12a.google.com (mail-it1-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 C272E1200A1 for ; Mon, 29 Apr 2019 05:34:37 -0700 (PDT)
Received: by mail-it1-x12a.google.com with SMTP id a190so15840551ite.4 for ; Mon, 29 Apr 2019 05:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xoE+oBeJ2v/vD9Emhn2/SaLUnf/R5S8jgUU+lW6QXic=; b=oZo/BFh7BhILFmHLqoQaAEBNgK3xzlVEVI8dW0IIfSn/I2ctGqTvu29DnFi05J8O08 grSaJCuDiRL8gVZM4hIbpq8qQkr5R7NbPrRv4N3lKGbU8FolbkX5q6vUNerCoVDPsSkD tM8Ai9LKTykNgnpr7fs4DpfGuj5I+sx1K5Ybs=
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=xoE+oBeJ2v/vD9Emhn2/SaLUnf/R5S8jgUU+lW6QXic=; b=t+8PmrUp6Uk9f9ayOpYtzPYuQnbj0YBx4CNLHKMTcNoBofrTcb8YKyR1VkNn8GZmFi JY0JQWU79Yi/RXt+oOQmCtXMEVf6NthSfM3FtJrWaYMK65pWKetTjFuTGGhtU/XqDo1v OPudNnkndMMY2i1KODi98pe0fvboP8vwcYZ73LRwzMjeVw7PAw+J+UfvSUTmcglaY4kf YyIHLWGN3DL7Ve7O8LuqkqUvcelIc6PK/siDaiPwEq4f020GXvz0EKGSWnK1UGSV7NIs MaGisoz2U2mQ1ZoEeahUmfj51Iob34LjoBeYPCRIq+yGBpTWTZ5EytWzMAMsg9Igo9yi gyAA==
X-Gm-Message-State: APjAAAWL1z/ZVjPYz6j5fQq5Scp+5xokQui2QhYWWxLz84gHgNOFUmBd tndXWlST/dvaj3LKLTfNkpxAWlF4K46PuIO/EOOewEarliZSOJ3hsK5w57Y1SW3YZuq9pzQadgM U3khROX4vFXrMlQ==
X-Google-Smtp-Source: APXvYqzhJ6/pKITAX5Uqz/JLfMf4z99rHSihOmk1WpdHYwAbw2mTMKvE7O7y21gf75LfYtYptfaTdZjyR+HVgd0ZOhk=
X-Received: by 2002:a02:6411:: with SMTP id t17mr33783174jac.90.1556541277015;  Mon, 29 Apr 2019 05:34:37 -0700 (PDT)
MIME-Version: 1.0
References: <87199072-428b-035b-8072-311735c08e6a@connect2id.com>   
In-Reply-To: 
From: Brian Campbell 
Date: Mon, 29 Apr 2019 06:34:10 -0600
Message-ID: 
To: Thomas Broyer 
Cc: Vladimir Dzhuvinov , "" 
Content-Type: multipart/alternative; boundary="000000000000e52d2d0587aa81ad"
Archived-At: 
Subject: Re: [OAUTH-WG] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?
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, 29 Apr 2019 12:34:41 -0000

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

Errata 5708 has been reported attempting to clarify the situation.

https://www.rfc-editor.org/errata/eid5708

On Mon, Apr 22, 2019 at 9:53 AM Thomas Broyer  wrote:

> And the root issue is that it *is* subject to interpretation.
>
> Parameters sent without a value MUST be treated as if they were
>    omitted from the request.  The authorization server MUST ignore
>    unrecognized request parameters.  Request and response parameters
>    MUST NOT be included more than once.
>
>
> The first sentence clearly applies to all parameters, whether recognized =
or not.
>
> It's unfortunately not clear to what the third applies, but BECAUSE it ca=
n be understood as applying to unrecognized parameters as well, I think it =
SHOULD be interpreted that way (until an errata clarifies the situation)
>
>
> Le lun. 22 avr. 2019 17:39, Brian Campbell  a
> =C3=A9crit :
>
>> My interpretation of RFC6749's =E2=80=9CRequest and response parameters =
MUST NOT
>> be included more than once" is that it is applicable only to the paramet=
ers
>> defined therein. Which (conveniently but defensibly) allows for extensio=
ns
>> like resource indicators and token exchange to have multiple instances o=
f a
>> parameter value without having to invent some new scheme to encode or
>> delimit multiple values.
>>
>> On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer  wrote=
:
>>
>>> RFC6749 makes it clear that =E2=80=9CRequest and response parameters MU=
ST NOT be
>>> included more than once.=E2=80=9D
>>> So:
>>>  * multi-valued request params shouldn't exist ("scope" is a single
>>> string value with a specific format, as a space-separated list of scope=
s)
>>>  * resource indicators draft violates RFC6749 by explicitly allowing
>>> multiple "resource" params; and RFC6749-compliant server is free to rej=
ect
>>> such a request with an invalid_request error, meaning that resource
>>> indicators breaks interoperability (clients can only send multi resourc=
e
>>> params to servers they know won't reject them with invalid_request as
>>> they're allowed to by RC6749).
>>> One could interpret that stance in RFC6749 as applying only to those
>>> params defined in this spec, but it's not explicitly said, so it could =
be
>>> interpreted as applying to any parameter, including extensions (like
>>> resource indicators) or unrecognized (and therefore ignored) parameters=
..
>>>
>>> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
>>> vladimir@connect2id.com> wrote:
>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>>>>
>>>> How should multi-valued request params be expressed in the JWT claims
>>>> set? As values in a JSON array?
>>>>
>>>>      {
>>>>       "iss": "s6BhdRkqt3",
>>>>       "aud": "https://server.example.com" =
,
>>>>       "response_type": "code id_token",
>>>>       "client_id": "s6BhdRkqt3",
>>>>       "redirect_uri": "https://client.example.org/cb" ,
>>>>       "scope": "openid",
>>>>       "state": "af0ifjsldkj",
>>>>       "some-query-param": [ "val-1", "val-2" ]
>>>>      }
>>>>
>>>> Apart from custom params, the resource indicators spec also suggests
>>>> that such situations can occur:
>>>>
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#se=
ction-2
>>>>
>>>> Thanks,
>>>>
>>>> Vladimir
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>> --
>>> Thomas Broyer
>>> /t=C9=94.ma.b=CA=81wa.je/ 
>>> _______________________________________________
>>> 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._

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


Errata =
5708 has been reported attempting to clarify the situation. 


On Mon, Apr 22, 2019 at 9:53 AM Thomas Broyer <t.broyer@gmail.com> wrote:
And the root iss=
ue is that it *is* subject to interpretation.

Parameters sent without a value MUST be treated as if they were
   omitted from the request.  The authorization server MUST ignore
   unrecognized request parameters.  Request and response parameters
   MUST NOT be included more than once.

The first sentence clearly applies to all parameters, =
whether recognized or not.
It's unfortunately not clear to what the third applies, but BECAUS=
E it can be understood as applying to unrecognized parameters as well, I th=
ink it SHOULD be interpreted that way (until an errata clarifies the situat=
ion)

Le lun. 22 avr. 2019 17:39, Brian Campbell <bcampbell@pingidentity.=
com> a =C3=A9crit=C2=A0:
My interpretation of RFC6749's =E2=80=
=9CRequest and response parameters MUST NOT be included more than once"=
; is that it is applicable only to the parameters defined therein. Which (c=
onveniently but defensibly) allows for extensions like resource indicators =
and token exchange to have multiple instances of a parameter value without =
having to invent some new scheme to encode or delimit multiple values.=C2=
=A0 

On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer <t.broyer@gmail.co=
m> wrote:
RFC6749 makes it clear that =E2=80=9CReq=
uest and response parameters MUST NOT be included more than once.=E2=80=9D<=
/div>
So:
=C2=A0* multi-valued request params shouldn't e=
xist ("scope" is a single string value with a specific format, as=
 a space-separated list of scopes)
=C2=A0* resource indicators dr=
aft violates RFC6749 by explicitly allowing multiple "resource" p=
arams; and RFC6749-compliant server is free to reject such a request with a=
n invalid_request error, meaning that resource indicators breaks interopera=
bility (clients can only send multi resource params to servers they know wo=
n't reject them with invalid_request as they're allowed to by RC674=
9).
One could interpret that stance in RFC6749 as applying only t=
o those params defined in this spec, but it's not explicitly said, so i=
t could be interpreted as applying to any parameter, including extensions (=
like resource indicators) or unrecognized (and therefore ignored) parameter=
s..

On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <vladi=
mir@connect2id.com> wrote:

 =20

   =20
 =20
  

    
https://tools.ietf.org/html/draft-ietf-oa=
uth-jwsreq-17#section-4

    
How should multi-valued request params be expressed in the JWT
      claims set? As values in a JSON array?

    
     {
      "iss": "s6BhdRkqt3",
      "aud": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "some-query-param": [ "val-1", "val-2" =
]
     }

    
Apart from custom params, the resource indicators spec also
      suggests that such situations can occur:

    
https://tools.ietf.org/html/dr=
aft-ietf-oauth-resource-indicators-02#section-2

    

    
Thanks,

    
Vladimir

  


_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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




-- 
Thomas Broyer
/t=C9=94.ma.b=CA=81wa=
.je/

_______________________________________________

OAuth mailing list

OAut=
h@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.
--000000000000e52d2d0587aa81ad--


From nobody Tue Apr 30 03:08:41 2019
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 168E912029C for ; Tue, 30 Apr 2019 03:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eEbuF2wxUd62 for ; Tue, 30 Apr 2019 03:08:37 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) (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 C72C612028A for ; Tue, 30 Apr 2019 03:08:36 -0700 (PDT)
Received: from [80.187.87.51] (helo=[10.158.82.179]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLPgf-00063x-6x; Tue, 30 Apr 2019 12:08:33 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-354EB0D8-A84B-44BF-AD60-004F980C1843; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <20190428040821.GF60332@kduck.mit.edu>
Date: Tue, 30 Apr 2019 12:08:32 +0200
Cc: Sascha Preibisch , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <20190428040821.GF60332@kduck.mit.edu>
To: Benjamin Kaduk 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 10:08:40 -0000

--Apple-Mail-354EB0D8-A84B-44BF-AD60-004F980C1843
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk :
>=20
>> On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote:
>> Hi Sascha,
>>=20
>> I see. I assume every element within the structured scope element to be a=
n independent scope (value) object and intended to use the name of that obje=
ct as kind of content type definition.=20
>>=20
>> In my last example, the scope is defined as=20
>>=20
>>   "structured_scope":{ =20
>>      "sign":{ =20
>>         "credentialID":"qes_eidas",
>>         "documentDigests":[ =20
>>            { =20
>>               "hash":
>>                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>               "label":"Mobile Subscription Contract"
>>            }
>>         ],
>>         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>      },
>>      "payment":{ =20
>>         "type":"sepa-credit-transfer",
>>         "instructedAmount":{ =20
>>            "currency":"EUR",
>>            "amount":"123.50"
>>         },
>>         "debtorAccount":{ =20
>>            "iban":"DE40100100103307118608"
>>         },
>>         "creditorName":"Merchant123",
>>         "creditorAccount":{ =20
>>            "iban":"DE02100100109307118603"
>>         },
>>         "remittanceInformationUnstructured":"new Smartphone"
>>      }
>>=20
>> This means =E2=80=9Csign" and =E2=80=9Cpayment" would determine the schem=
e of the respective object.=20
>>=20
>> What do you think?
>=20
> I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the=

> "typ" header, and all the reasoning we have to do about different types of=

> tokens (not) being replayable at a different endpoint and being interprete=
d
> wrongly.

While I agree with the need to use the typ header, I don=E2=80=99t see a dir=
ect relationship to my proposal as it is about specifying the intended scope=
 of tokens but not the token format itself. Can you explain your thoughts in=
 more detail?

kind regards,
Torsten.

>=20
> -Ben

--Apple-Mail-354EB0D8-A84B-44BF-AD60-004F980C1843
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDMwMTAwODMyWjAvBgkqhkiG9w0BCQQxIgQg
d81RNUyd69Ej+llQF8uRg78MbZxpAgm6ocbzO0aihbswgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBANIHOod4USzfpTF9
JvIGVRD2LputFK2wHZ40Bfaamf+0fRJ35ytrZnuIhm+U4TNpxy/MF8CHkLOV/eHmxqAgNlkQFphO
31Mn0w4DhNUdHqnrK0zs4EZX69ssKY1uk3SqHdf9UUQ4PvD3ILRVVGmnFL3jFl6cujFFwCxfMwbq
+FaJAzAflJbpPPp9KkL2BXkn5IPQ/CcTI8RDH9pKFaerY+l6McjHUVNbqHZC8+gHzdojbsXSyozH
lPsZL4UScOo6lugF5Kpm/wvOcrAYdHQHnzGvm3IYL3sgWlxasgyrYu9iCSUd7zchMIB+nPwB87zr
UypBek2bfKNhwQNNhZQ7kKMAAAAAAAA=

--Apple-Mail-354EB0D8-A84B-44BF-AD60-004F980C1843--


From nobody Tue Apr 30 03:24:58 2019
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 22A761202A6 for ; Tue, 30 Apr 2019 03:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 t7sYJ6N9PvmS for ; Tue, 30 Apr 2019 03:24:55 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 0F8D21202A4 for ; Tue, 30 Apr 2019 03:24:55 -0700 (PDT)
Received: from [80.187.87.51] (helo=[10.158.82.179]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLPwR-0001Q1-G2; Tue, 30 Apr 2019 12:24:51 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-ACB54420-3875-4603-AF63-07312015A08C; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: 
Date: Tue, 30 Apr 2019 12:24:50 +0200
Cc: oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <0D21D79B-58A2-4193-B022-C77B739962C2@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Takahiko Kawasaki 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 10:24:57 -0000

--Apple-Mail-ACB54420-3875-4603-AF63-07312015A08C
Content-Type: multipart/alternative;
	boundary=Apple-Mail-FDF14A7C-E604-44CA-86CB-D9E2CF71240E
Content-Transfer-Encoding: 7bit


--Apple-Mail-FDF14A7C-E604-44CA-86CB-D9E2CF71240E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear Taka,

thanks for your feedback.

How would this more generic mechanism differ from the JSON-based request obj=
ect? I personally would advocate to use both, structured scope & pushed requ=
est object, to together.

best regards,
Torsten.

> Am 26.04.2019 um 09:47 schrieb Takahiko Kawasaki :
>=20
> Dear Torsten,
>=20
> I was impressed with your article. It describes considerations points very=
 well that implementers of leading-edge authorization servers will eventuall=
y face or have already faced.
>=20
> It seems to me that the mechanism of "structured_scope" can be positioned a=
s a more generic mechanism whose usage doesn't necessarily have to be limite=
d to scopes. I mean that the mechanism can be used to include any arbitrary d=
ynamic structured data in an authorization request. So, if there were someth=
ing I might be able to propose additionally, I would suggest renaming "struc=
tured_scope" to a more generic name.
>=20
> Best Regards,
> Takahiko Kawasaki
> Representative director, Authlete, Inc.
>=20
> 2019=E5=B9=B44=E6=9C=8821=E6=97=A5(=E6=97=A5) 3:21 Torsten Lodderstedt :
>> Hi all,=20
>>=20
>> I just published an article about the subject at: https://medium.com/oaut=
h-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2=
038948 =20
>>=20
>> I look forward to getting your feedback.
>>=20
>> kind regards,
>> Torsten.=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-FDF14A7C-E604-44CA-86CB-D9E2CF71240E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Dea=
r Taka,

thanks for your fee=
dback.

How would this more g=
eneric mechanism differ from the JSON-based request object? I personally wou=
ld advocate to use both, structured scope & pushed request object, to to=
gether.

best regards,
=

Torsten.
Dear Torsten,

I was impressed with your article. It describes consideratio=
ns points very well that implementers of leading-edge authorization servers w=
ill eventually face or have already faced.

It seems=
 to me that the mechanism of "structured_scope" can be positioned as a more g=
eneric mechanism whose usage doesn't necessarily have to be limited to scope=
s. I mean that the mechanism can be used to include any arbitrary dynamic st=
ructured data in an authorization request. So, if there were something I mig=
ht be able to propose additionally, I would suggest renaming "structured_sco=
pe" to a more generic name.

Best Regards,
Takahiko Kawasaki
Representative director, Authlete, Inc.

2019=E5=B9=B44=E6=9C=8821=E6=97=A5(=E6=97=A5) 3:21 Torsten Lodderstedt &l=
t;torsten@lodderstedt.net>=
:
Hi all, 



I just published an article about the subject at: https://medium.com/oaut=
h-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2=
038948  



I look forward to getting your feedback.



kind regards,

Torsten. 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




=

--Apple-Mail-FDF14A7C-E604-44CA-86CB-D9E2CF71240E--

--Apple-Mail-ACB54420-3875-4603-AF63-07312015A08C
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDMwMTAyNDUwWjAvBgkqhkiG9w0BCQQxIgQg
l5ljE3MJxSGpg6gzso9/ySXRc3u6E4AAdLQSM9kAyygwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAFZt2uct8LDGVDl7
jKsqLM0KGjQyxJUmOh2oQpDdxGJRTHCG+qmUxMnGnuPOCaY62QJYXipt0PeHp59O+sWwU85sDnqb
JZ1WAyljVqpUcsRgbxec3/qNAq5JEGSMdhhC5v/gR7Uj42ZuJpnVMGQqM9PUuXUZ7OLMi3so5KN/
skciUJUGJc79xFgL5X1gfLxtDMxfMm2h8VBKYENvuH7DPrWeZzDmSAyupJ5O3V2q1G3RpF6lqNLP
w0vKD09VJT8kGve5yGzLEMJh+bks6/IhkHGy1RwybYcomA6VaSehzKZjVun7EF1GfvkdPU/BooXI
uyk3YVmey9SOi7lDIJw04OsAAAAAAAA=

--Apple-Mail-ACB54420-3875-4603-AF63-07312015A08C--


From nobody Tue Apr 30 03:26:55 2019
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 E51841202A6 for ; Tue, 30 Apr 2019 03:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 x58ijM7isMj4 for ; Tue, 30 Apr 2019 03:26:52 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) (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 E3C3E1200E3 for ; Tue, 30 Apr 2019 03:26:51 -0700 (PDT)
Received: from [80.187.87.51] (helo=[10.158.82.179]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLPyL-0006RE-HM; Tue, 30 Apr 2019 12:26:49 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-F30C473D-834A-48B7-9CFF-F1271B4F58C2; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: 
Date: Tue, 30 Apr 2019 12:26:48 +0200
Cc: oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <81033006-C36E-4F4F-89D5-AC9188218833@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> 
To: Sascha Preibisch 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 10:26:54 -0000

--Apple-Mail-F30C473D-834A-48B7-9CFF-F1271B4F58C2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sascha,

I see the challenge, thanks!

Potentially, one would need to have a more explicit typing support (schemes?=
) and use the name of the individual elements just as names, e.g. payment1, p=
ayment2.

best regards,
Torsten.

> Am 25.04.2019 um 23:35 schrieb Sascha Preibisch :
>=20
> Torsten,
>=20
> I think that works in most cases if you look at it that way.
>=20
> It is just that elements such as 'iban' are practically unknown here
> in Canada for example. This means, there needs to be a differentiator
> that tells a client that one payment may be of type 'payment_eu' and
> in the other case 'payment_ca'. Actually .... now I see the 'type'
> element. With that, 'payment + type' would provide that information.
>=20
> The only thing I would look into would be a change in the document
> hierarchy to simply parsing of it. Potentially multiple payments could
> be submitted at once also by adding a 'payments' root element:
>=20
> {
> "payment": {
> "sepa-credit-transfer": {
> "instructedAmount": {
> "currency": "EUR",
> "amount": "123.50"
> },
> "debtorAccount": {
> "iban": "DE40100100103307118608"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
> "iban": "DE02100100109307118603"
> },
> "remittanceInformationUnstructured": "new Smartphone"
> }
> }
> }
>=20
> But generally, the 'structured_scope' is a good concept I think.
>=20
> Thanks again, Torsten,
>=20
> Sascha
>=20
> Am Mi., 24. Apr. 2019 um 10:08 Uhr schrieb Torsten Lodderstedt
> :
>>=20
>> Hi Sascha,
>>=20
>> I see. I assume every element within the structured scope element to be a=
n independent scope (value) object and intended to use the name of that obje=
ct as kind of content type definition.
>>=20
>> In my last example, the scope is defined as
>>=20
>>   "structured_scope":{
>>      "sign":{
>>         "credentialID":"qes_eidas",
>>         "documentDigests":[
>>            {
>>               "hash":
>>                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>               "label":"Mobile Subscription Contract"
>>            }
>>         ],
>>         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>      },
>>      "payment":{
>>         "type":"sepa-credit-transfer",
>>         "instructedAmount":{
>>            "currency":"EUR",
>>            "amount":"123.50"
>>         },
>>         "debtorAccount":{
>>            "iban":"DE40100100103307118608"
>>         },
>>         "creditorName":"Merchant123",
>>         "creditorAccount":{
>>            "iban":"DE02100100109307118603"
>>         },
>>         "remittanceInformationUnstructured":"new Smartphone"
>>      }
>>=20
>> This means =E2=80=9Csign" and =E2=80=9Cpayment" would determine the schem=
e of the respective object.
>>=20
>> What do you think?
>>=20
>> best regards,
>> Torsten.
>>=20
>>> On 23. Apr 2019, at 17:14, Sascha Preibisch  w=
rote:
>>>=20
>>> Hi Torsten!
>>>=20
>>> If 'structured_scope' would become a generic field for application
>>> specific content, I believe an indicator for the type of content would
>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>> this helps!
>>>=20
>>> Thank you,
>>> Sascha
>>>=20
>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>> :
>>>>=20
>>>> Hi Sascha,
>>>>=20
>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
>>>>>=20
>>>>> Thank you for the article, Torsten!
>>>>=20
>>>> my pleasure :-)
>>>>=20
>>>>>=20
>>>>> I like that 'scope' is out of the game for these kinds of authorizatio=
ns.
>>>>>=20
>>>>> What I can see for the general use case is a required identifier
>>>>> within the 'structures_scope' document that identifies the profile it
>>>>> should be used for.
>>>>=20
>>>> What does profile mean in this context?
>>>>=20
>>>> best regards,
>>>> Torsten.
>>>>>=20
>>>>> Thank you,
>>>>> Sascha
>>>>>=20
>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>> :
>>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> I just published an article about the subject at: https://medium.com/=
oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-23=
26e2038948
>>>>>>=20
>>>>>> I look forward to getting your feedback.
>>>>>>=20
>>>>>> kind regards,
>>>>>> Torsten.
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20

--Apple-Mail-F30C473D-834A-48B7-9CFF-F1271B4F58C2
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDMwMTAyNjQ4WjAvBgkqhkiG9w0BCQQxIgQg
crWBhDy0b5SSiaq6olmJMecIM3JgwjLE6hjrhQR9jLAwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBAD5KQUZSRSr/srsf
+x/1BAH/doU5Mw7Q/FTOLWvCNqGNS+CzHsVb11SRkx1SjW2t3PnjKhcqHecUADuLs/x1VhlplSIU
12tUTRpzYYEKEgww6F//q8lzcJGbz/g9kqPjOAovREKF+AI8ZNBChMkpNen8+g2QDAhtq1jvbgAe
3jcMX0H30mHt8JjLLYPMJnVZPT0tXZTxEmVqtSoG/Z691gtGfmDMYRTp6/qJstNNXb2eUBLATFwH
z6WQeEgKWAAn+D2oFlXASIrzAts9DHyimBFlc+Q9IFVojtouumwWaM54bo2YAXZZe8fSHhrAH3aQ
+tfk5mZTNj2GVZgs5zNgg88AAAAAAAA=

--Apple-Mail-F30C473D-834A-48B7-9CFF-F1271B4F58C2--


From nobody Tue Apr 30 03:39:59 2019
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 230F51202A1 for ; Tue, 30 Apr 2019 03:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AsKwEAvARDOT for ; Tue, 30 Apr 2019 03:39:55 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) (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 A4A12120130 for ; Tue, 30 Apr 2019 03:39:54 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.105]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLQAx-0007KB-QB; Tue, 30 Apr 2019 12:39:51 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-B61BB958-A3E7-48F7-8DE9-40580FDA51B3; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
Date: Tue, 30 Apr 2019 12:39:48 +0200
Cc: Sascha Preibisch , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <2EDD8634-20D1-40DE-AA0D-A64AB6AEA539@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 10:39:57 -0000

--Apple-Mail-B61BB958-A3E7-48F7-8DE9-40580FDA51B3
Content-Type: multipart/alternative;
	boundary=Apple-Mail-C4FC7FA5-49F2-4B2A-B0B2-27B307609F15
Content-Transfer-Encoding: 7bit


--Apple-Mail-C4FC7FA5-49F2-4B2A-B0B2-27B307609F15
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



> Am 26.04.2019 um 16:17 schrieb George Fletcher :
>=20
>=20
>=20
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>=20
>>=20
>> Am 25.04.2019 um 17:03 schrieb George Fletcher :
>>=20
>>> A couple of thoughts...
>>>=20
>>> 1. It doesn't feel like these are scopes (at least not as scope is defin=
ed by RFC 6749). It feels like they are more transaction requirements.
>>=20
>> What???s the difference? In my opinion, if you authorize a transaction it=
???s the same. Moreover, in other use cases (account information) it a compl=
ex requirement for a potentially long lasting grant.
>>=20
>> In both cases, they describe the request power of the token =3D=3D it???s=
 scope.
> I guess I look at scope as "authorized to transfer" maybe something like "=
authorized to transfer up to 10K". However the details of which account to t=
ake the money from and the account of where to put the money are not aspects=
 of the scope but rather restrictions on the transaction.=20
>=20
> It may be fine to have a model where the client tells the AS what transact=
ion it wants to perform for the purpose of getting consent from the user to p=
erform that transaction... but I don't think the details of the transaction s=
hould be considered scope(s).
>=20
> For me.. scope is a capability the client is authorized to perform... "sen=
d an Instant message", or "read a buddy list".
>>=20
>>>=20
>>> 2. The schemas are going to be very ecosystem specific, correct?
>>=20
>> API (e.g. all psd2 standards), ecosystem, single deployment - just like ?=
??traditional??? scope values
> Again, I would want the transaction requirements to be part of the API not=
 part of the scope. In my mind, the authorization token should convey the cl=
ient is authorized to perform a set of actions (capabilities) and then the A=
PI parameters define the exact details of that particular transaction.

I understand your sentiments. How would you envision to ask a user for conse=
nt about those details if this consent is required by law?

>>=20
>>>=20
>>>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>>> Hi Sascha,
>>>>=20
>>>> I see. I assume every element within the structured scope element to be=
 an independent scope (value) object and intended to use the name of that ob=
ject as kind of content type definition.=20
>>>>=20
>>>> In my last example, the scope is defined as=20
>>>>=20
>>>>    "structured_scope":{ =20
>>>>       "sign":{ =20
>>>>          "credentialID":"qes_eidas",
>>>>          "documentDigests":[ =20
>>>>             { =20
>>>>                "hash":
>>>>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>>>                "label":"Mobile Subscription Contract"
>>>>             }
>>>>          ],
>>>>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>>       },
>>>>       "payment":{ =20
>>>>          "type":"sepa-credit-transfer",
>>>>          "instructedAmount":{ =20
>>>>             "currency":"EUR",
>>>>             "amount":"123.50"
>>>>          },
>>>>          "debtorAccount":{ =20
>>>>             "iban":"DE40100100103307118608"
>>>>          },
>>>>          "creditorName":"Merchant123",
>>>>          "creditorAccount":{ =20
>>>>             "iban":"DE02100100109307118603"
>>>>          },
>>>>          "remittanceInformationUnstructured":"new Smartphone"
>>>>       }
>>>>=20
>>>> This means ???sign" and ???payment" would determine the scheme of the r=
espective object.=20
>>>>=20
>>>> What do you think?
>>>>=20
>>>> best regards,=20
>>>> Torsten.=20
>>>>=20
>>>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:
>>>>>>=20
>>>>>> Hi Torsten!
>>>>>>=20
>>>>>> If 'structured_scope' would become a generic field for application
>>>>>> specific content, I believe an indicator for the type of content woul=
d
>>>>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>>>>> this helps!
>>>>>>=20
>>>>>> Thank you,
>>>>>> Sascha
>>>>>>=20
>>>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>>>> :
>>>>>> Hi Sascha,
>>>>>>=20
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
>>>>>>>>=20
>>>>>>>> Thank you for the article, Torsten!
>>>>>>> my pleasure :-)
>>>>>>>=20
>>>>>>> I like that 'scope' is out of the game for these kinds of authorizat=
ions.
>>>>>>>=20
>>>>>>> What I can see for the general use case is a required identifier
>>>>>>> within the 'structures_scope' document that identifies the profile i=
t
>>>>>>> should be used for.
>>>>>> What does profile mean in this context?
>>>>>>=20
>>>>>> best regards,
>>>>>> Torsten.
>>>>>>> Thank you,
>>>>>>> Sascha
>>>>>>>=20
>>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>>> :
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> I just published an article about the subject at: https://medium.co=
m/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-=
2326e2038948
>>>>>>>>=20
>>>>>>>> I look forward to getting your feedback.
>>>>>>>>=20
>>>>>>>> kind 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
>=20

--Apple-Mail-C4FC7FA5-49F2-4B2A-B0B2-27B307609F15
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit




Am 26.04.2019 um 16:17 schrieb George Fletcher <gffletch@aol.com>:


  
    
  
  
    

    

    
On 4/25/19 1:54 PM, Torsten Lodderstedt
      wrote:

    

    

      
      


      

      


        Am 25.04.2019 um 17:03 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          A couple of
            thoughts...

            

            1. It doesn't feel like these are scopes (at least not as
            scope is defined by RFC 6749). It feels like they are more
            transaction requirements.

          

      

      


      

      What???s the difference? In my opinion, if you authorize a
      transaction it???s the same. Moreover, in other use cases (account
      information) it a complex requirement for a potentially long
      lasting grant.
      


      

      
In both cases, they describe the request power of the token
        == it???s scope.

      

    

    I guess I look at scope as "authorized to transfer" maybe something
    like "authorized to transfer up to 10K". However the details of
    which account to take the money from and the account of where to put
    the money are not aspects of the scope but rather restrictions on
    the transaction. 

    

    It may be fine to have a model where the client tells the AS what
    transaction it wants to perform for the purpose of getting consent
    from the user to perform that transaction... but I don't think the
    details of the transaction should be considered scope(s).

    

    For me.. scope is a capability the client is authorized to
    perform... "send an Instant message", or "read a buddy list".

    

      

        


          

            
 

                2. The schemas are going to be very ecosystem specific,
                correct?

              

          

          


          

          
API (e.g. all psd2 standards), ecosystem, single
            deployment - just like ???traditional??? scope values

        

      

    

    Again, I would want the transaction requirements to be part of the
    API not part of the scope. In my mind, the authorization token
    should convey the client is authorized to perform a set of actions
    (capabilities) and then the API parameters define the exact details
    of that particular transaction.

I understand your sentiments. How would you envision to ask a user for consent about those details if this consent is required by law?


    

      

        


          

            
 

              
On 4/24/19 1:08 PM, Torsten
                Lodderstedt wrote:

              

              

                
Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means ???sign" and ???payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 



                

                  
On 23. Apr 2019, at 17:14, Sascha Preibisch <saschapreibisch@gmail.com> wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                  

                    
Hi Sascha,



                    

                      
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <saschapreibisch@gmail.com>:

Thank you for the article, Torsten!


                    

                    
my pleasure :-)



                    

                      
I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.


                    

                    
What does profile mean in this context?

best regards,
Torsten.


                    

                      
Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<torsten@lodderstedt.net>:


                      

                        
Hi all,

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind 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


              

              

            

          

        

      

    

    

  



--Apple-Mail-C4FC7FA5-49F2-4B2A-B0B2-27B307609F15--

--Apple-Mail-B61BB958-A3E7-48F7-8DE9-40580FDA51B3
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCn8w
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBUUwggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJ
KoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD
T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAe
Fw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5A
bG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9
SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkFFZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHB
qVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8v
tTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9vXloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHc
kVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZ
eYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7Gfx
wqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7GSji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAM
BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhC
AQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6
Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB
LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVu
QGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcv
jCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7IS
YQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXoIarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy
4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvNVmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxv
T5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4
ImVnZ6WvgzGCA88wggPLAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8
BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAh3cjdwfbVS49xtpMKQd5tjANBglghkgBZQMEAgEFAKCCAfMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDMwMTAzOTQ4WjAvBgkqhkiG9w0BCQQxIgQg
tg8R7uUXzyZxwdjmoKcrZbEQmFiOEbLQthdYQRYIQg4wgcEGCSsGAQQBgjcQBDGBszCBsDCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0
MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
QTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEBAQUABIIBALLgVEjyNIz8GCbQ
d9DqzCcLnhvp0O9SyUOCFqS4lJfu2UWUZod6N44tq1a1XxbUXzKXXBehNoWvr7tcuJujLPoJMWFB
y8VScOCxbBoafXXCxK+KeyMxGhBNk/QZ3bWDFxVndbFei2r2kS/96GwFp5ycADb9PcAKxIxCgaoT
TA1KhwTVY3cYymQoQMPBhtswp0+hEVi+MCXMnp8p91cP8iug7qQywCE6WCBngcwq2zdZmyPBTgaM
m2l4cpTh8JiUzlnnIc3lvME1F+xvUEFTwjfVVjwpD6PJUGjomMXAS+7aRV9bPF2dFVaKHf+d1vU8
Ljgl8HzxzhKkgDA/MqATw9UAAAAAAAA=

--Apple-Mail-B61BB958-A3E7-48F7-8DE9-40580FDA51B3--


From nobody Tue Apr 30 04:01:20 2019
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 98EE31202C7 for ; Tue, 30 Apr 2019 04:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tQMqwkmHHyoE for ; Tue, 30 Apr 2019 04:01:15 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.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 5376B1202B9 for ; Tue, 30 Apr 2019 04:01:15 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLQVb-0001ac-BP; Tue, 30 Apr 2019 13:01:11 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: <291d464d-ce6c-52ea-302f-d57cecd0b973@aol.com>
Date: Tue, 30 Apr 2019 13:01:10 +0200
Cc: George Fletcher , Sascha Preibisch , oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <707FDD72-A3CA-4BB3-8DA1-A2093813EF08@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <776A61E6-226C-434F-8D7E-AFF4D2E423E9@lodderstedt.net>  <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net> <119b93cb-d6c3-18dc-3e10-9ba087e0817e@aol.com>  <8c2187bd-3d17-9c9c-2b3c-6f9193ebdcbd@aol.com> <291d464d-ce6c-52ea-302f-d57cecd0b973@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 11:01:18 -0000

> On 26. Apr 2019, at 16:35, George Fletcher  wrote:
>=20
> Look at this in more detail... what about calling it =
"transactional_scope" instead of "structured_scope" as the scope is =
specific to an individual transaction and not applicable across =
transactions. That would then separate it from the more capability based =
'scope' provided by OAuth2.

There are cases, where the scope/token is applicable across multiple =
requests for a longer period. A request for access to account =
information service, for example, would look like this:

{ =20
   "access":{ =20
      "balances":[ =20
         { =20
            "iban":"DE40100100103307118608"
         },
         { =20
            "iban":"DE02100100109307118603"
         }
      ],
      "transactions":[ =20
         { =20
            "iban":"DE40100100103307118608"
         }
      ]
   },
   "recurringIndicator":true,
   "validUntil":"2017-11-01",
   "frequencyPerDay":"4"
}

>=20
> In this context I like the pushed-request-object method as the =
resource server is going to need to pull the same transactional =
requirements when it receives the access token.

All in one place :-)

best,
Torsten.=20

>=20
> Thanks,
> George
>=20
> On 4/26/19 10:17 AM, George Fletcher wrote:
>>=20
>>=20
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>>=20
>>>=20
>>> Am 25.04.2019 um 17:03 schrieb George Fletcher :
>>>=20
>>>> A couple of thoughts...
>>>>=20
>>>> 1. It doesn't feel like these are scopes (at least not as scope is =
defined by RFC 6749). It feels like they are more transaction =
requirements.
>>>=20
>>> What???s the difference? In my opinion, if you authorize a =
transaction it???s the same. Moreover, in other use cases (account =
information) it a complex requirement for a potentially long lasting =
grant.
>>>=20
>>> In both cases, they describe the request power of the token =3D=3D =
it???s scope.
>> I guess I look at scope as "authorized to transfer" maybe something =
like "authorized to transfer up to 10K". However the details of which =
account to take the money from and the account of where to put the money =
are not aspects of the scope but rather restrictions on the transaction.=20=

>>=20
>> It may be fine to have a model where the client tells the AS what =
transaction it wants to perform for the purpose of getting consent from =
the user to perform that transaction... but I don't think the details of =
the transaction should be considered scope(s).
>>=20
>> For me.. scope is a capability the client is authorized to perform... =
"send an Instant message", or "read a buddy list".
>>>=20
>>>>=20
>>>> 2. The schemas are going to be very ecosystem specific, correct?
>>>=20
>>> API (e.g. all psd2 standards), ecosystem, single deployment - just =
like ???traditional??? scope values
>> Again, I would want the transaction requirements to be part of the =
API not part of the scope. In my mind, the authorization token should =
convey the client is authorized to perform a set of actions =
(capabilities) and then the API parameters define the exact details of =
that particular transaction.
>>>=20
>>>>=20
>>>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>>>>> Hi Sascha,
>>>>>=20
>>>>> I see. I assume every element within the structured scope element =
to be an independent scope (value) object and intended to use the name =
of that object as kind of content type definition.=20
>>>>>=20
>>>>> In my last example, the scope is defined as=20
>>>>>=20
>>>>>    "structured_scope":{ =20
>>>>>       "sign":{ =20
>>>>>          "credentialID":"qes_eidas",
>>>>>          "documentDigests":[ =20
>>>>>             { =20
>>>>>                "hash":
>>>>>                  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>>>>                "label":"Mobile Subscription Contract"
>>>>>             }
>>>>>          ],
>>>>>          "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>>>>       },
>>>>>       "payment":{ =20
>>>>>          "type":"sepa-credit-transfer",
>>>>>          "instructedAmount":{ =20
>>>>>             "currency":"EUR",
>>>>>             "amount":"123.50"
>>>>>          },
>>>>>          "debtorAccount":{ =20
>>>>>             "iban":"DE40100100103307118608"
>>>>>          },
>>>>>          "creditorName":"Merchant123",
>>>>>          "creditorAccount":{ =20
>>>>>             "iban":"DE02100100109307118603"
>>>>>          },
>>>>>          "remittanceInformationUnstructured":"new Smartphone"
>>>>>       }
>>>>>=20
>>>>> This means ???sign" and ???payment" would determine the scheme of =
the respective object.=20
>>>>>=20
>>>>> What do you think?
>>>>>=20
>>>>> best regards,=20
>>>>> Torsten.=20
>>>>>=20
>>>>>=20
>>>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch =

>>>>>>  wrote:
>>>>>>=20
>>>>>> Hi Torsten!
>>>>>>=20
>>>>>> If 'structured_scope' would become a generic field for =
application
>>>>>> specific content, I believe an indicator for the type of content =
would
>>>>>> be needed on the long run. That is what I meant my 'profile'. I =
hope
>>>>>> this helps!
>>>>>>=20
>>>>>> Thank you,
>>>>>> Sascha
>>>>>>=20
>>>>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>>>>>=20
>>>>>> 
>>>>>> :
>>>>>>=20
>>>>>>> Hi Sascha,
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch =

>>>>>>>> :
>>>>>>>>=20
>>>>>>>> Thank you for the article, Torsten!
>>>>>>>>=20
>>>>>>> my pleasure :-)
>>>>>>>=20
>>>>>>>=20
>>>>>>>> I like that 'scope' is out of the game for these kinds of =
authorizations.
>>>>>>>>=20
>>>>>>>> What I can see for the general use case is a required =
identifier
>>>>>>>> within the 'structures_scope' document that identifies the =
profile it
>>>>>>>> should be used for.
>>>>>>>>=20
>>>>>>> What does profile mean in this context?
>>>>>>>=20
>>>>>>> best regards,
>>>>>>> Torsten.
>>>>>>>=20
>>>>>>>> Thank you,
>>>>>>>> Sascha
>>>>>>>>=20
>>>>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>>>>>=20
>>>>>>>> 
>>>>>>>> :
>>>>>>>>=20
>>>>>>>>> Hi all,
>>>>>>>>>=20
>>>>>>>>> I just published an article about the subject at:=20
>>>>>>>>> =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> I look forward to getting your feedback.
>>>>>>>>>=20
>>>>>>>>> kind regards,
>>>>>>>>> Torsten.
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>>=20
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>>=20
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>>=20
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Tue Apr 30 04:03:27 2019
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 7A1BF12008C for ; Tue, 30 Apr 2019 04:03: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fryn69NUE9_C for ; Tue, 30 Apr 2019 04:03:23 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (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 208931202A9 for ; Tue, 30 Apr 2019 04:03:23 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLQXg-0001Ad-Iq; Tue, 30 Apr 2019 13:03:20 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: 
Date: Tue, 30 Apr 2019 13:03:19 +0200
Cc: oauth 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4303D8E2-DC2A-4359-B07D-6078E8FD6FFD@lodderstedt.net>
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net> 
To: Brian Campbell 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 11:03:26 -0000

> On 26. Apr 2019, at 19:57, Brian Campbell  =
wrote:
>=20
> One thing that I think is missing from the article in the discussion =
of pros and cons is that in many cases a large or even voluminous =
request can be sent via auto submitting form post (like =
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but =
the other way around from client to AS with the auth request), which =
doesn't then run into the same URI size problem.=20

Thanks for pointing this out! Is the response mode often used in the =
wild for OAuth?

>=20
> =46rom a prospective standardization standpoint, there are really two =
distinct concepts in the article. One is the "Pushed Request Object" and =
the other the "Structured Scope". They are certainly complementary =
things but each could also be useful and used independently of one =
another. So I'd argue that they should be developed independently too.

I agree. I=E2=80=99m considering two separate drafts.

>=20
>=20
>=20
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt =
 wrote:
> Hi all,=20
>=20
> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948 =20
>=20
> I look forward to getting your feedback.
>=20
> kind regards,
> Torsten.=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.


From nobody Tue Apr 30 04:33:37 2019
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 0B03212008C for ; Tue, 30 Apr 2019 04:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rDPlaPHTnRsg for ; Tue, 30 Apr 2019 04:33:31 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) (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 E240812024C for ; Tue, 30 Apr 2019 04:33:30 -0700 (PDT)
Received: from [84.158.239.111] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hLR0o-0000Vn-8r; Tue, 30 Apr 2019 13:33:26 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Torsten Lodderstedt 
In-Reply-To: <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>
Date: Tue, 30 Apr 2019 13:33:25 +0200
Cc: "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <69A297E4-F173-42D5-B2BC-B87825CBAEE5@lodderstedt.net>
References:  <74A378B3-B81A-4199-938B-E576FD1AA66C@iwelcome.com>
To: Jaap Francke 
X-Mailer: Apple Mail (2.3445.104.8)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)
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, 30 Apr 2019 11:33:36 -0000

Hi Jaap,

thanks for sharing your thoughts with us.

> On 25. Apr 2019, at 09:27, Jaap Francke =
 wrote:
>=20
> Hi Torsten and others,
>=20
> I just read your blog - having =E2=80=9Cwe need to re-think OAuth =
scopes=E2=80=9D in the title immediately drew my attention.=20
> I find this interesting since I=E2=80=99m struggling with the concept =
of scopes from time-to-time.
> I=E2=80=99ll have to read the blog a few times more to get a good =
understanding, but I would like to share some of my thoughts on scopes.
>=20
> I believe the OAuth scope concept has it=E2=80=99s limitations not =
only for transactions but also for the more traditional =E2=80=98resource=E2=
=80=99 concept.
> RFC 6749 defines scopes as follows:
> "The value of the scope parameter is expressed as a list of space-
>    delimited, case-sensitive strings.  The strings are defined by the
>    authorization server.  If the value contains multiple =
space-delimited
>    strings, their order does not matter, and each string adds an
>    additional access range to the requested scope.=E2=80=9D
>=20
> I see 2 aspects in this definition:
> - how the strings should look like is beyond the scope of the RFC
> - each string adds an additional authorisation
>=20
> Scopes are associated with access_tokens, which typically are bearer =
tokens as defined by RFC 6750 as:
>       A security token with the property that any party in possession =
of
>       the token (a "bearer") can use the token in any way that any =
other
>       party in possession of it can.  Using a bearer token does not
>       require a bearer to prove possession of cryptographic key =
material
>       (proof-of-possession).=E2=80=9D
>=20
> This implies that every scope value should fully describe the =
authorisation that is given.

I couldn=E2=80=99t agree more :-)=20

One subtle difference: I would state the "authorization asked for=E2=80=9D=
. Why this differentiation? In the implementations I was responsible for =
in the past (consumer facing services), the scope value always indicated =
the service the client wanted to access BUT the access tokens typically =
carried the user id and user claims needed to authorize the call (on =
behalf of the resource owner) with the RS. Scope values or parts of it =
could have been added to the tokens as well. But the point want to get =
across is, the scope pass into an authorization transaction might get =
transformed in some other data in the token.

> In my view that is rarely done, which is the main reason why I find =
myself struggling with scope-concept.

The scope parameter was kept very generic and simple in RFC 6749 in =
order to not limit implementors and keep implementation complexity low. =
The concept was ok at that time (2012!) but is longer suitable for =
current use cases and the fact clients want to access more than a single =
service using a certain grant.=20

>=20
> Here we have a collection of examples, which demonstrate to me that =
everyone is inventing their own wheels according to their specfic needs:
> https://brandur.org/oauth-scope
> https://api.slack.com/docs/oauth-scopes
>=20
> In various other (draft) standards I see bits and pieces that seem to =
address this issue.
>=20
> In UMA an authorisation is conceptually broken down into:
> - subject -> requesting party
> - verbs -> scopes of access
> - object -> resource set.
> I like this line of thinking and terminilogy.  However, if =
access_tokens are bearer tokens, I think =E2=80=99subject=E2=80=99 is =
the bearer of the token.

I would argue the bearer is acting on behalf of the subject. Even in =
case of sender-constraint tokens (or PoP tokens), it=E2=80=99s not =
necessarily the user (resource owner) interacting with the service. The =
proof material just confirms that the legit client uses the token.=20

>=20
> The most common practice, I think, is to use OIDC=E2=80=99s IDTokens =
to contain a set of claims that scope the scope of the scope :-).=20

Never seen that. Can you share examples?

> I mean that the claims in the ID-Tokens are used to scope the objects =
as well as the verbs/scopes of access.
> The core intention behind ID-token is to provide information about the =
authenticated user and not necessarily about the resources that are =
accessed. In practice, claims about the authenticated users indicate =
which resources (photos) can be accessed at the resource server.=20
>=20
> My understanding of this draft =
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
> is that the object/resource aspect of authorisation is taken somewhat =
out of the scope and put into a dedicated parameter. Although (using the =
example from RFC 6749) the resource parameter indicates the resource =
server (or application,
>    API, etc.) rather than an individual resource that is stored at the =
resource server. So additional scoping of object/resource set is still =
needed in addition to the resource parameter.

Resource indicators is an incremental extension to OAuth allowing =
issuance of RS-specific access tokens based on the same grant (audience =
restriction and so on). It was possible before, e.g. by using scope =
values to represent RSs, but there was no standardised way to indicate =
the intended RS to the AS. I learned this made it difficult for OAuth =
products to support per RS access tokens based on the same grant.=20

>=20
>=20
> Furthermore, =
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 makes =
some interesting statements that are relevant in my view:
> The section on Access Token privilege restriction says "access tokens =
SHOULD be restricted to certain resources
>    and actions on resource servers or resources.=E2=80=9D So the OAuth =
scope-string still needs to somehow indicate the resource-scope of the =
privilege that is communicated.

Well, there needs to be a way to indicate the RS (or resource) the =
client wants to interact with. Resource indicators is one way. I =
definitely envision to have this feature in structured scopes. Resource =
indicators is a bit limited since resource URI and requested permissions =
(scope) are kept separate. But =E2=80=9Cread=E2=80=9D might have a =
different meaning at different resources. =20

That=E2=80=99s why the structured scope will allow the client to =
indicate the resource along with the requested permission on that =
particular resource.

Here is an example:
{ =20
   "structured_scope":{ =20
      "email":{ =20
         "server":"imap.example.com",
         "actions":[ =20
            "read"
         ]
      },
      "cloud":{ =20
         "server":"https://webdav.example.com",
         "actions":[ =20
            "read",
            "write"
         ]
      }
   }
}



>=20
> " The client needs to tell the authorization server, at which URL it
>    will use the access token it is requesting.  It could use the
>    mechanism proposed [
> I-D.ietf-oauth-resource-indicators
> ] or encode the
>    information in the scope value.=E2=80=9D
>=20
>=20
> I=E2=80=99m not sure which point I=E2=80=99m trying to make; i guess =
the need for standardisation how to use and define OAuth-scopes.
> I like the Lodging Intent Pattern and need to do some more =
reading/thinking about the structured-scope and pushed request objects.
> I feel these concepts are not only relevant for authorisation of =
transactions, but also for any access that needs authorisation.

I agree again :-) A structured scope draft should definitely not limit =
the mechanism to transaction authorization.=20

>=20
> I=E2=80=99m not sure if i express myself clearly, nevertheless any =
feedback is welcome, if not alone to get my understanding of the various =
concepts on a higher level.

Thanks a lot for your feedback. It was very helpful to direct further =
work. I hope you will stay involved!

best regards,
Torsten.=20

>=20
> Thanks in advance, kind regards
>=20
> Jaap
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> Message: 1
>> Date: Wed, 24 Apr 2019 19:08:25 +0200
>> From: Torsten Lodderstedt 
>> To: Sascha Preibisch 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
>> Message-ID: <2997B550-C82B-4D3A-9639-15A004F2F6C5@lodderstedt.net>
>> Content-Type: text/plain;  charset=3Dutf-8
>>=20
>> Hi Sascha,
>>=20
>> I see. I assume every element within the structured scope element to =
be an independent scope (value) object and intended to use the name of =
that object as kind of content type definition.=20
>>=20
>> In my last example, the scope is defined as=20
>>=20
>>   "structured_scope":{ =20
>>      "sign":{ =20
>>         "credentialID":"qes_eidas",
>>         "documentDigests":[ =20
>>            { =20
>>               "hash":
>>                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=3D",
>>               "label":"Mobile Subscription Contract"
>>            }
>>         ],
>>         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>>      },
>>      "payment":{ =20
>>         "type":"sepa-credit-transfer",
>>         "instructedAmount":{ =20
>>            "currency":"EUR",
>>            "amount":"123.50"
>>         },
>>         "debtorAccount":{ =20
>>            "iban":"DE40100100103307118608"
>>         },
>>         "creditorName":"Merchant123",
>>         "creditorAccount":{ =20
>>            "iban":"DE02100100109307118603"
>>         },
>>         "remittanceInformationUnstructured":"new Smartphone"
>>      }
>>=20
>> This means ?sign" and ?payment" would determine the scheme of the =
respective object.=20
>>=20
>> What do you think?
>>=20
>> best regards,=20
>> Torsten.=20
>>=20
>>> On 23. Apr 2019, at 17:14, Sascha Preibisch =
 wrote:
>>>=20
>>> Hi Torsten!
>>>=20
>>> If 'structured_scope' would become a generic field for application
>>> specific content, I believe an indicator for the type of content =
would
>>> be needed on the long run. That is what I meant my 'profile'. I hope
>>> this helps!
>>>=20
>>> Thank you,
>>> Sascha
>>>=20
>>> Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
>>> :
>>>>=20
>>>> Hi Sascha,
>>>>=20
>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch =
:
>>>>>=20
>>>>> Thank you for the article, Torsten!
>>>>=20
>>>> my pleasure :-)
>>>>=20
>>>>>=20
>>>>> I like that 'scope' is out of the game for these kinds of =
authorizations.
>>>>>=20
>>>>> What I can see for the general use case is a required identifier
>>>>> within the 'structures_scope' document that identifies the profile =
it
>>>>> should be used for.
>>>>=20
>>>> What does profile mean in this context?
>>>>=20
>>>> best regards,
>>>> Torsten.
>>>>>=20
>>>>> Thank you,
>>>>> Sascha
>>>>>=20
>>>>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
>>>>> :
>>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> I just published an article about the subject at: =
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-=
think-oauth-scopes-2326e2038948
>>>>>>=20
>>>>>> I look forward to getting your feedback.
>>>>>>=20
>>>>>> kind regards,
>>>>>> Torsten.
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> ------------------------------
>>=20
>> Subject: Digest Footer
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> ------------------------------
>>=20
>> End of OAuth Digest, Vol 126, Issue 58
>> **************************************
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Apr 30 09:56:07 2019
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 EC4A31202CE for ; Tue, 30 Apr 2019 09:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=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 M-K3xhL2UPpW for ; Tue, 30 Apr 2019 09:56:02 -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 98D2C12029C for ; Tue, 30 Apr 2019 09:56:02 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id m14so1902669ion.13 for ; Tue, 30 Apr 2019 09:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cIdnW9q/HYynV5S1inGIDj9D331e71Y2TEC6BPfHcg4=; b=ejozrTSlYfbMWfCGetKVS3u7WiTtpw95OmGdB02Pr8cwGTu31dLTCxwxen0/gQhcaB BhGAM487pkPrSvP7b0AtgJvJ4MbfyvJuqn2qSucjgA67gUv/sUVoBOPnT2rEfyPT8EtN J5lS/ClOcMmLSYmuTmTLqbfSejMPlpHQkWkmw=
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=cIdnW9q/HYynV5S1inGIDj9D331e71Y2TEC6BPfHcg4=; b=gGjRUrYCdGsf87RVolTT8iCfrp/AO5hlb3TdlXnpXV1AgIbSo5Z5YKVlgYb/k91qVg PLfAUsBv6NjDdrOtaAcJhXOyZRjQL0iH9vYsRyF1fepKcUSKzFgSOl+/p2wecm+towA3 USI2oRI6eFo0p7+5I4WTA8tKYGCQjzID2zFfq4SUISZ9vGpKfK0Glw54y2bypnzhYYU7 9HzNp+4ZbjEiRThJ2CZvGVLEQgedka9212kFN0xzcc4PtAimvqt9XpxoyQRd821/VPX7 V++XO4lMjq5dkWMBTCHPn8HNORQZX9cTeY5cnLJSNpqbGO/vtVfLMMAQGPPRUIRYg/hH hpdQ==
X-Gm-Message-State: APjAAAWEXBsFRf9A2OWM86DQ5uQgSr/9ELveyBsKoIadvpIwLSI1mtw1 aj8DL4p0ywv5WS/433mLufPTtbnAXaDofJH2lR+SPkRcbBDreBmzyJI7snuR6UN2FIVAkupVnKM ajFGo0GsaQQHvgg==
X-Google-Smtp-Source: APXvYqxzSnZJvHVa8s43ZBjw/7KIiRI4cvaMULN3zdyDxuAkMpA6lCfOb++ydAuLF219WohXFt2VlUlcmjv66/GYNuY=
X-Received: by 2002:a5d:9a05:: with SMTP id s5mr569172iol.238.1556643361638; Tue, 30 Apr 2019 09:56:01 -0700 (PDT)
MIME-Version: 1.0
References: <8E2628D6-282A-4284-97E3-94466D71A75A@lodderstedt.net>  <4303D8E2-DC2A-4359-B07D-6078E8FD6FFD@lodderstedt.net>
In-Reply-To: <4303D8E2-DC2A-4359-B07D-6078E8FD6FFD@lodderstedt.net>
From: Brian Campbell 
Date: Tue, 30 Apr 2019 10:55:35 -0600
Message-ID: 
To: Torsten Lodderstedt 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000009cdb2a0587c246e9"
Archived-At: 
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2019 16:56:05 -0000

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

On Tue, Apr 30, 2019 at 5:03 AM Torsten Lodderstedt 
wrote:

>
>
> > On 26. Apr 2019, at 19:57, Brian Campbell 
> wrote:
> >
> > One thing that I think is missing from the article in the discussion of
> pros and cons is that in many cases a large or even voluminous request ca=
n
> be sent via auto submitting form post (like
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but
> the other way around from client to AS with the auth request), which
> doesn't then run into the same URI size problem.
>
> Thanks for pointing this out! Is the response mode often used in the wild
> for OAuth?
>

It's not really a "response mode" for sending the request but the idea is
basically the same just going the other direction. The possibility is
implied by the text near the end of
https://tools.ietf.org/html/rfc6749?#section-3.1 that says,

  'The authorization server MUST support the use of the HTTP "GET"
   method [RFC2616] for the authorization endpoint and MAY support the
   use of the "POST" method as well.'

I know our AS will happily accept POST at the authorization endpoint and I
suspect many others will too. But I don't have any data how often it is
used in the wild for 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._

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






On Tue, Apr 30, 2019 at 5:03 AM Torsten Lodderstedt <torsten@lodderstedt.n=
et> wrote:
bcampbell@pingidentity.com> =
wrote:

> 

> One thing that I think is missing from the article in the discussion o=
f pros and cons is that in many cases a large or even voluminous request ca=
n be sent via auto submitting form post (like https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.h=
tml but the other way around from client to AS with the auth request), =
which doesn't then run into the same URI size problem. 



Thanks for pointing this out! Is the response mode often used in the wild f=
or OAuth?

It's not really a "r=
esponse mode" for sending the request but the idea is basically the sa=
me just going the other direction. The possibility is implied by the text n=
ear the end of https://tools.ietf.org/html/rfc6749?#section-3.1 that says,
=

=C2=A0 'The authorization server MUST support the use of=
 the HTTP "GET"
=C2=A0=C2=A0 method [RFC2616] for the authoriz=
ation endpoint and MAY support the
=C2=A0=C2=A0 use of the "POST&qu=
ot; method as well.'

I know our AS will happil=
y accept POST at the authorization endpoint and I suspect many others will =
too. But I don't have any data how often it is used in the wild for OAu=
th.
=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.
--0000000000009cdb2a0587c246e9--